AWS 풀 최초 경험 - 섹션 4 - 배포 및 포장

도전5:건조함 유지

당면 과제 6: 배포 및 패키지

이제 필요한 모든 구성 요소를 함께 배치합시다

각 데이터 원본에 대해 우리는 두 개의 변환 raw to refined과 refined to curated을 정의했다

AWS Glue는 하나의 .py 파일을 입구점으로 하고 나머지 파일은 일반적인 .py 파일이거나 .zip 또는 .whl 파일에 포함되어야 하며 작업마다 다른 요구가 있을 수 있습니다

AWS Glue의 또 다른 요구 사항은 입구점 스크립트 파일과 의존항이 S3에 업로드되어야 한다는 것입니다

그리고 S3에 업로드된 모든 내용도 쉼표로 구분된 S3 URL 목록의 형식으로 Terraform에 Terraform --extra-py-files의 형식으로 열거해야 한다. 예를 들어 s3://bucket/dep1.zip, s3://bucket/deb2.zip 또는 s3://bucket/dep1.whl, s3://bucket/deb2.whl

이 목록은 매우 동적일 수 있기 때문에 가능한 한 짧게 하는 것이 좋습니다.보시다시피 개발자는 많은 조작을 수행해야 하고, 여러 개의 작업을 개발하려면 많은 노력을 기울여야 합니다.그래서 다음과 같은 구조를 사용하기로 결정했습니다

/
├── glue/
│   ├── data_sources/
│   ├── ├── ds1/
│   │   └── ├── raw_to_refined/
│   │       │   ├── Makefile
│   │       │   ├── config.py
│   │       │   ├── raw_to_refined.py
│   │       │   └── requirements.txt
│   │       └── refined_to_curated/
│   │           ├── Makefile
│   │           ├── config.py
│   │           ├── another_dependency.py
│   │           ├── refined_to_curated.py
│   │           └── requirements.txt
│   └── shared/
│       └── glue_shared_lib/
│           ├── Makefile
│           ├── setup.py
│           ├── src
│           │   └── glue_shared/__init__.py
│           └── tests/
└── terraform/

위의 구조를 설명해 드리겠습니다

• /glue/ 모든python 코드 저장

• /glue/data_sources/ 각 데이터 원본의 작업 코드를 저장

• /glue/data_sources/ds1/ - 변환된 특정 데이터 원본을 포함하는 디렉터리

• /glue/data_sources/ds1/raw_to_refined과 /glue/data_sources/ds1/raw_to_refined
  
  이러한 변환의 내용은 이후 특정 AWS 접착 작업으로 배치됩니다

• /glue/shared/ - 접착제 간의 공유항목(작업, 파일 등) 포함

• /glue/shared/glue_shared_lib - 작업용 라이브러리로 설정 인터페이스 및 기타 유용한 기능 포함

• /terraform/은 접착 작업, IAM 역할, lambda 기능 등 배치에 필요한 모든 자원을 보유하고 있음

이제 구조를 알았으니 특정한 업무를 더 자세히 볼 수 있습니다

특수 매개 변수 접착 작업 구조

이것은 표준적인 청사진으로 내가 몇 개의 AWS 접착제 작업을 개발하고 배치하는 목적에 부합한다

ds1/
└── raw_to_refined/
   ├── Makefile
   ├── config.py
   ├── raw_to_refined.py
   └── requirements.txt

본 예에서 우리는 원시 구역에서 세분화 구역으로의 전환 작업을 연구하고 있다

• 
  

  Makefile - 여러 개의make목표를 포함하는데 이러한 목표의 명칭은 모든 작업에서 통용되고 clean, package, test, upload-job, upload, deploy은 모든 목표의 실현은 작업에 특정됩니다

  
  
  • clean - 로컬 임시 파일을 지웁니다.
  • package - PySpark 작업의 경우 종속성이 있는 .zip 파일을 만듭니다.Python 셸 작업에 대해 pip을 실행하고 모든 휠 파일을 다운로드합니다.
  • upload-job - S3-에 엔트리 포인트 스크립트를 업로드하여 파일에서 변경 사항이 발생하지 않도록 개발 프로세스 중에 빠르게 업데이트합니다.
  • upload - 모든 관련 파일 .zip, .whl 및 입구점 .py을 S3에 업로드합니다.
  • deploy - clean, package 및 upload 실행
    
  
  

• config.py - 구성 객체를 작성합니다.이것은 extra .py 파일로 잠시 후에 포장하여 의존항으로 사용합니다.시간을 절약하기 위해서,python 사전을 사용했지만, 작업이 날로 복잡해지면서, 더 좋은 방법을 만드는 데 시간을 들이는 것을 권장합니다.p>

• raw_to_refined.py - AWS Glue가 실행하는 주요 엔트리 포인트 파일입니다.이 파일을 의존 항목에서 코드를 실행하거나 변환 논리를 직접 실현할 수 있습니다.이 파일의 이름은 일부러 부모 디렉터리와 같으며, 나중에 설명할 것입니다

• requirements.txt - 표준 입니다. 이것은 매우 간단한 관리 의존 관계의 방법입니다

개발자로서 이 설정은 로컬 환경과 CI/CD를 사용하여 클라우드에서 작업을 실행하고 업데이트할 수 있는 충분한 유연성을 제공합니다.또 다른 장점은 PySpark와 풀이 로컬에서 작동하면 사용할 수 있다는 것이다

요구 사항 파일 지형 부분

Terraform을 통해 PySpark 작업을 배치하는 예입니다. Python 케이스 작업은 같은 과정을 따르지만 약간 다릅니다(잠시 후 언급)

Terraform을 통해 작업을 만들거나 업데이트하기 위해서Terraform 자원에 필요한 몇 가지 인자를 제공해야 합니다.게다가 우리의 업무가 기대하는 매개 변수

제공이 필요합니다:

• Command.ScriptLocation - ds1_raw_to_refined_job_script_location을 나타냅니다. - 이것은 우리의 입구 스크립트입니다

• DefaultArguments - 매핑 ds1_raw_to_refined_job_default_arguments을 나타냅니다. - 이것은 주 설정을 저장합니다

맵 --extra-py-files의 키 ds1_raw_to_refined_job_default_arguments은 쉼표로 구분된 S3 URL 문자열로 우리의 의존항을 가리킨다. 예를 들어 s3://bucket/dep1.zip,s3://bucket/deb2.zip

모든 추가 의존항은 .zip 파일에 넣을 수 있으며, 이 매개 변수의 모양을 얻으면 변경할 필요가 없습니다

이것은 잠재적인 인위적인 감독 문제, 특히 파이톤 셸 작업을 가져왔다.여기서 종속 항목은 휠이며 기본적으로 휠 이름은 버전 번호 numpy-1.19.0-cp36-cp36m-manylinux2010_x86_64.whl

그리고 requirements.txt 또는 작업 매개 변수의 변경 사항도Terraform 자원을 변경해야 합니다. 이 자원은 서로 다른 디렉터리에서 유지됩니다

저는 프로젝트 기간에 이 문제를 해결하지 못했지만 S3 메모리통에서 파일 형식으로 의존항 목록을 유지함으로써 이 문제를 피할 수 있습니다. 이 파일은 make 기간에 생성할 수 있습니다.그런 다음 Terraform에서 이 정보를 다운로드합니다.그러나 이러한 이론적 해결 방안은 계란 문제를 초래할 수 있으므로, 나는 AWS Glue가 의존 관계와 작업 설정을 유지할 수 있는 더 좋은 옵션을 가지고 싶다.전체 URL 대신 S3 접두사를 사용할 수 있도록 허용하는 것이 좋은 시작입니다

본고에서 예시한 코드는 제 GitHub 저장소 에서 찾을 수 있습니다