기술나눔

Apache DolphinScheduler를 사용하여 빅 데이터 플랫폼을 구축 및 배포하고 AWS에 작업을 제출하는 실무 경험

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

작가에 대해

리칭왕 - Cisco 소프트웨어 개발 엔지니어

소개

안녕하세요 여러분, 제 이름은 Cisco의 소프트웨어 개발 엔지니어인 Li Qingwang입니다. 우리 팀은 거의 3년 동안 Apache DolphinScheduler를 사용하여 자체 빅 데이터 일정 관리 플랫폼을 구축해 왔습니다. 초기 버전 2.0.3부터 현재까지 우리는 커뮤니티와 함께 ​​성장해 왔습니다. 오늘 여러분과 공유한 기술 아이디어는 버전 3.1.1을 기반으로 한 2차 개발이며, 커뮤니티 버전에는 포함되지 않은 몇 가지 새로운 기능을 추가했습니다.

오늘은 Apache DolphinScheduler를 사용하여 빅 데이터 플랫폼을 구축하고 작업을 AWS에 제출 및 배포하는 방법과 프로세스 중에 직면한 몇 가지 문제와 솔루션을 공유하겠습니다.

아키텍처 설계 및 조정

처음에는 API, Alert 및 Zookeeper(ZK), Master, Worker와 같은 구성 요소를 포함한 모든 서비스가 Kubernetes(K8s)에 배포됩니다.

파일

빅데이터 처리 업무

Spark, ETL, Flink 등의 작업에 대한 2차 개발을 수행했습니다.

  • ETL 작업: 우리 팀은 사용자가 ETL 작업을 빠르게 생성할 수 있는 간단한 드래그 앤 드롭 도구를 개발했습니다.
  • 스파크 지원 : 초기 버전에서는 Yarn에서 실행되는 Spark만 지원했고, 2차 개발을 통해 K8s에서도 실행되도록 했습니다. 최신 버전의 커뮤니티는 현재 K8s에서 Spark를 지원합니다.
  • *Flink 보조 개발: 마찬가지로 Flink On K8s 스트리밍 작업을 추가하고 SQL 작업 및 Python 작업 On K8s에 대한 지원도 추가했습니다.

AWS에서의 지원 작업

비즈니스가 확장되고 데이터 정책이 필요해짐에 따라 우리는 다양한 지역에서 데이터 작업을 실행해야 하는 과제에 직면하게 되었습니다. 이를 위해서는 여러 클러스터를 지원할 수 있는 아키텍처를 구축해야 합니다. 다음은 당사의 솔루션 및 구현 프로세스에 대한 자세한 설명입니다.

파일

현재 아키텍처는 여러 클러스터를 관리하는 단일 Apache DolphinScheduler 서비스인 중앙 집중식 제어 엔드포인트로 구성됩니다. 이러한 클러스터는 현지 데이터 정책 및 격리 요구 사항을 준수하기 위해 EU, 미국 등 다양한 지역에 분산되어 있습니다.

건축적 조정

이러한 요구를 충족하기 위해 우리는 다음과 같은 조정을 했습니다.

  • Apache DolphinScheduler 서비스를 중앙에서 관리하세요.: DolphinScheduler 서비스는 여전히 자체 구축된 Cisco Webex DC에 배포되어 관리 중앙 집중화 및 일관성을 유지합니다.
  • AWS EKS 클러스터 지원 : 동시에 여러 AWS EKS 클러스터를 지원하도록 아키텍처 기능을 확장했습니다. 이러한 방식으로 EKS 클러스터에서 실행 중인 작업에 대한 새로운 비즈니스 요구 사항은 다른 Webex DC 클러스터의 작동 및 데이터 격리에 영향을 주지 않고 충족될 수 있습니다.

파일

이러한 설계를 통해 우리는 데이터 격리 및 정책 준수를 보장하면서 다양한 비즈니스 요구 사항과 기술적 과제에 유연하게 대응할 수 있습니다.

다음으로 Cisco Webex DC에서 작업을 실행할 때 Apache DolphinScheduler의 기술 구현 및 리소스 종속성을 처리하는 방법을 소개합니다.

파일

리소스 종속성 및 스토리지

모든 작업이 Kubernetes(K8s)에서 실행되므로 다음을 수행하는 것이 중요합니다.

도커 이미지
  • 저장 위치: 이전에는 모든 Docker 이미지가 Cisco의 Docker 저장소에 저장되었습니다.
  • 이미지 관리: 이러한 이미지는 우리가 실행하는 다양한 서비스와 작업에 필요한 운영 환경과 종속성을 제공합니다.
리소스 파일 및 종속성
  • Jar 패키지 및 구성 파일 등: Amazon S3 Bucket을 리소스 스토리지 센터로 사용하여 사용자의 Jar 패키지와 가능한 종속 구성 파일을 저장합니다.
  • 보안자원 관리: 데이터베이스 비밀번호, Kafka 암호화 정보, 사용자 종속 키 등이 포함됩니다. 이러한 민감한 정보는 Cisco의 Vault 서비스에 저장됩니다.

보안 액세스 및 권한 관리

S3 버킷에 액세스하려면 AWS 자격 증명을 구성하고 관리해야 합니다.

IAM 계정 구성
  • 자격 증명 관리: IAM 계정을 사용하여 액세스 키 및 비밀 키를 포함한 AWS 리소스에 대한 액세스를 관리합니다.
  • K8s 통합: 이러한 자격 증명 정보는 Kubernetes Secret에 저장되며 S3 버킷에 안전하게 액세스하기 위해 Api-Service에서 참조됩니다.
  • 권한 제어 및 리소스 격리: IAM 계정을 통해 세분화된 권한 제어를 구현하여 데이터 보안 및 비즈니스 규정 준수를 보장할 수 있습니다.

IAM 계정 액세스 키 만료 문제 및 대책

IAM 계정을 사용하여 AWS 리소스를 관리하는 과정에서 액세스 키 만료 문제에 직면하게 됩니다. 우리가 이 문제를 어떻게 해결하고 있는지 자세히 알아보세요.

액세스 키 만료 문제
  • 주요 기간: IAM 계정의 AWS 키는 시스템의 보안을 강화하기 위해 일반적으로 90일마다 자동으로 만료되도록 설정됩니다.
  • 임무 영향: 키가 만료되면 이러한 키를 사용하여 AWS 리소스에 액세스하는 모든 작업을 수행할 수 없으므로 비즈니스 연속성을 유지하려면 적시에 키를 업데이트해야 합니다.

이러한 상황에 대응하여 작업을 정기적으로 다시 시작하고 해당 모니터링을 설정합니다. 만료 시간 전에 AWS 계정에 문제가 있는 경우 해당 개발자에게 일부 처리를 수행하도록 알려야 합니다.

AWS EKS 지원

비즈니스가 AWS EKS로 확장됨에 따라 기존 아키텍처와 보안 조치를 일련의 조정해야 합니다. 파일

예를 들어 방금 언급한 Docker 이미지처럼 이전에는 Cisco의 자체 Docker 저장소에 넣었으므로 이제 Docker 이미지를 ECR에 넣어야 합니다. 파일

다중 S3 버킷 지원

AWS 클러스터의 분산된 특성과 다양한 비즈니스의 데이터 격리 요구 사항으로 인해 다양한 클러스터의 데이터 스토리지 요구 사항을 충족하려면 여러 S3 버킷을 지원해야 합니다. 파일

  • 클러스터와 버킷 간의 대응: 각 클러스터는 해당 S3 버킷에 액세스하여 데이터 지역성과 규정 준수를 보장합니다.
  • 전략 수정: 여러 S3 버킷에서 데이터 읽기 및 쓰기를 지원하려면 스토리지 액세스 정책을 조정해야 합니다. 다양한 비즈니스 당사자가 해당 S3 버킷에 액세스해야 합니다.

비밀번호 관리 도구 변경 사항

보안을 강화하기 위해 Cisco의 자체 구축 Vault 서비스에서 AWS의 Secrets Manager(ASM)로 마이그레이션했습니다.

  • ASM의 사용: ASM은 AWS 리소스의 암호 및 키를 관리하기 위한 보다 통합된 솔루션을 제공합니다.

Pod의 보안을 강화하기 위해 IAM 역할 및 서비스 계정을 사용하는 방법을 채택했습니다.

  • IAM 역할 및 정책 생성: 먼저 IAM 역할을 생성하고 필요한 권한만 부여되도록 필요한 정책을 여기에 바인딩합니다.
  • K8s 서비스 계정 바인딩: 그런 다음 Kubernetes 서비스 계정을 생성하고 이를 IAM 역할과 연결합니다.
  • 포드 권한 통합: 포드를 실행할 때 포드를 서비스 계정에 연결하면 포드는 IAM 역할을 통해 필요한 AWS 자격 증명을 직접 얻을 수 있으므로 필요한 AWS 리소스에 액세스할 수 있습니다.

이러한 조정은 시스템의 확장성과 유연성을 향상할 뿐만 아니라 전반적인 보안 아키텍처를 강화하여 AWS 환경에서의 운영이 효율적이고 안전하도록 보장합니다. 동시에 키 자동 만료 및 다시 시작해야 하는 이전 문제도 방지됩니다.

자원 관리 및 저장 프로세스 최적화

배포 프로세스를 단순화하기 위해 보조 전송을 거치는 대신 Docker 이미지를 ECR에 직접 푸시할 계획입니다.

  • 직접 밀어: Docker 이미지가 빌드된 후 ECR에 직접 푸시되도록 현재 패키징 프로세스를 수정하여 시간 지연과 잠재적인 오류 지점을 줄입니다.
변경 구현
  • 코드 레벨 조정: 여러 S3 클라이언트를 지원할 수 있도록 DolphinScheduler 코드를 수정하고 여러 S3Client에 대한 캐시 관리를 추가했습니다.
  • 자원 관리 UI 조정: 사용자가 인터페이스를 통해 작업을 위해 다른 AWS 버킷 이름을 선택할 수 있습니다.
  • 리소스 액세스: 수정된 Apache DolphinScheduler 서비스는 이제 여러 S3 버킷에 액세스할 수 있으므로 서로 다른 AWS 클러스터 간의 데이터를 유연하게 관리할 수 있습니다.

AWS 리소스의 관리 및 권한 격리

AWS Secrets Manager(ASM) 통합

AWS Secrets Manager를 지원하도록 Apache DolphinScheduler를 확장하여 사용자가 다양한 클러스터 유형에서 암호를 선택할 수 있도록 했습니다.

파일

ASM 기능 통합
  • 사용자 인터페이스 개선: DolphinScheduler의 사용자 인터페이스에는 다양한 비밀 유형의 표시 및 선택 기능이 추가되었습니다.
  • 자동 키 관리: 런타임 중에 사용자가 선택한 시크릿을 저장하는 파일 경로를 실제 Pod 환경 변수에 매핑하여 키의 안전한 사용을 보장합니다.

동적 리소스 구성 및 초기화 서비스(Init Container)

AWS 리소스를 보다 유연하게 관리하고 초기화하기 위해 Init Container라는 서비스를 구현했습니다.

파일

  • 리소스 풀: Init Container는 Pod가 실행되기 전에 사용자가 구성한 S3 리소스를 자동으로 가져와 지정된 디렉터리에 배치합니다.
  • 키 및 구성 관리: 구성에 따라 Init Container는 ASM에서 비밀번호 정보를 확인하고 가져온 다음 이를 파일에 저장하고 Pod에서 사용할 수 있도록 환경 변수를 통해 매핑합니다.

리소스 생성 및 관리에 Terraform 적용

Terraform을 통해 AWS 리소스의 구성 및 관리 프로세스를 자동화하여 리소스 할당 및 권한 설정을 단순화했습니다.

파일

  • 자동 리소스 구성: Terraform을 사용하여 S3 Bucket 및 ECR Repo와 같은 필수 AWS 리소스를 생성합니다.
  • IAM 정책 및 역할 관리: 각 사업부가 필요한 리소스에 온디맨드 방식으로 액세스할 수 있도록 IAM 정책과 역할을 자동으로 생성합니다.

권한 격리 및 보안

우리는 정교한 권한 격리 전략을 사용하여 다양한 사업부가 독립적인 네임스페이스에서 작동하도록 보장하고 리소스 액세스 충돌과 보안 위험을 방지합니다.

구현 세부정보
  • 서비스 계정 생성 및 바인딩: 각 사업부별로 독립적인 서비스 계정을 생성하고 이를 IAM 역할에 바인딩합니다.
  • 네임스페이스 격리: 각 서비스 계정 작업은 지정된 네임스페이스 내의 IAM 역할을 통해 해당 AWS 리소스에 액세스합니다.

파일

클러스터 지원 및 권한 제어 개선

클러스터 유형 확장

새 필드를 추가했습니다. cluster type, 표준 Webex DC 클러스터 및 AWS EKS 클러스터를 포함할 뿐만 아니라 보안 요구 사항이 더 높은 특정 클러스터도 지원하는 다양한 유형의 K8S 클러스터를 지원합니다.

파일

클러스터 유형 관리
  • 클러스터 유형 필드:소개됨cluster type분야에서 다양한 K8S 클러스터에 대한 지원을 쉽게 관리하고 확장할 수 있습니다.
  • 코드 수준 사용자 정의: 특정 클러스터의 고유한 요구 사항에 대해 코드 수준 수정을 통해 이러한 클러스터에서 작업을 실행할 때 보안 및 구성 요구 사항이 충족되도록 할 수 있습니다.

강화된 권한 제어 시스템(인증 시스템)

우리는 프로젝트, 리소스 및 네임스페이스 간의 권한 관리를 포함하여 세분화된 권한 제어를 위해 특별히 인증 시스템을 개발했습니다.

권리관리 기능
  • 프로젝트 및 리소스 권한: 사용자는 프로젝트 차원을 통해 권한을 제어할 수 있습니다. 프로젝트 권한이 있으면 해당 프로젝트의 모든 리소스에 액세스할 수 있습니다.
  • 네임스페이스 권한 제어: 특정 팀이 지정된 네임스페이스에서만 해당 프로젝트의 작업을 실행할 수 있도록 하여 실행 리소스 격리를 보장합니다.

예를 들어 팀 A는 A 네임스페이스에서 특정 프로젝트 작업만 실행할 수 있습니다. 예를 들어 사용자 B는 사용자 A의 네임스페이스에서 작업을 실행할 수 없습니다.

AWS 리소스 관리 및 권한 적용

우리는 인증 시스템과 기타 도구를 사용하여 AWS 리소스의 권한과 액세스 제어를 관리함으로써 리소스 할당을 더욱 유연하고 안전하게 만듭니다.

파일

  • 여러 AWS 계정 지원: 인증 시스템에서는 여러 AWS 계정을 관리하고 S3 Bucket, ECR, ASM 등 다양한 AWS 리소스를 바인딩할 수 있습니다.
  • 리소스 매핑 및 권한 적용: 사용자는 기존 AWS 리소스를 매핑하고 시스템에서 권한을 신청할 수 있으므로 작업 실행 시 액세스해야 하는 리소스를 쉽게 선택할 수 있습니다.

서비스 계정 관리 및 권한 바인딩

서비스 계정 및 해당 권한을 더 잘 관리하기 위해 다음 기능을 구현했습니다.

파일

서비스 계정 바인딩 및 관리
  • 서비스 계정의 유일한 차이점: 고유성을 보장하기 위해 특정 클러스터, 네임스페이스 및 프로젝트 이름을 통해 서비스 계정을 바인딩합니다.
  • 권한 바인딩 인터페이스: 사용자는 인터페이스에서 S3, ASM 또는 ECR과 같은 특정 AWS 리소스에 서비스 계정을 바인딩하여 권한을 정확하게 제어할 수 있습니다.

파일

운영 및 리소스 동기화 단순화

방금 말했지만 실제 작업은 사용자에게 상대적으로 간단합니다. 전체 애플리케이션 프로세스는 실제로 AWS 환경에서 Apache DolphinScheduler의 사용자 경험을 더욱 향상시키기 위해 일련의 작업을 수행했습니다. 운영 절차를 단순화하고 자원 동기화 기능을 향상시키기 위한 조치입니다.

파일

요약해 보겠습니다.

단순화된 사용자 인터페이스

DolphinScheduler에서 사용자는 작업이 실행되는 특정 클러스터 및 네임스페이스를 쉽게 구성할 수 있습니다.

클러스터 및 네임스페이스 선택
  • 클러스터 선택: 작업을 제출할 때 사용자는 작업을 실행할 클러스터를 선택할 수 있습니다.
  • 네임스페이스 구성: 선택한 클러스터에 따라 사용자는 작업이 실행되는 네임스페이스도 지정해야 합니다.
서비스 계정 및 리소스 선택
  • 서비스 계정 표시: 선택한 프로젝트, 클러스터, 네임스페이스에 따라 해당 서비스 계정이 페이지에 자동으로 표시됩니다.
  • 리소스 액세스 구성: 사용자는 드롭다운 목록을 통해 서비스 계정과 연결된 S3 버킷, ECR 주소 및 ASM 키를 선택할 수 있습니다.

미래 전망

현재 디자인과 관련하여 사용자 제출을 개선하고 운영 및 유지 관리를 용이하게 하기 위해 최적화하고 개선할 수 있는 일부 영역이 아직 남아 있습니다.

  • 이미지 푸시 최적화: 특히 EKS 관련 이미지 수정의 경우 Cisco의 전송 패키징 프로세스를 건너뛰고 패키지를 ECR에 직접 푸시하는 것을 고려하십시오.
  • 원클릭 동기화 기능: 반복 업로드 작업을 줄이기 위해 사용자가 리소스 패키지를 S3 버킷에 업로드하고 확인란을 선택하면 자동으로 다른 S3 버킷에 동기화할 수 있는 원클릭 동기화 기능을 개발할 계획입니다.
  • 인증 시스템에 자동으로 매핑: Terraform을 통해 Aws 리소스가 생성되면 시스템은 사용자가 리소스를 수동으로 입력하는 것을 방지하기 위해 이러한 리소스를 권한 관리 시스템에 자동으로 매핑합니다.
  • 권한 제어 최적화: 자동화된 리소스 및 권한 관리를 통해 사용자 작업이 더욱 단순해지고 설정 및 관리의 복잡성이 줄어듭니다.

이러한 개선 사항을 통해 사용자는 Webex DC 또는 EKS에서 Apache DolphinScheduler를 사용하여 작업을 보다 효율적으로 배포하고 관리하는 동시에 리소스 관리 효율성과 보안을 향상시킬 수 있을 것으로 기대합니다.

이 글은 작성자입니다 벨루가 오픈 소스 기술 출판 지원 가능!