비밀번호

커뮤니티2

  • 맑음속초16.7맑음북춘천11.0맑음철원10.8맑음동두천13.3맑음파주12.5맑음대관령9.6맑음춘천10.8맑음백령도14.8맑음북강릉16.8맑음강릉19.0맑음동해17.1맑음서울14.0맑음인천13.6맑음원주13.0맑음울릉도15.5맑음수원12.6맑음영월10.7맑음충주9.8맑음서산12.7맑음울진18.0맑음청주14.0맑음대전12.9맑음추풍령12.0맑음안동12.3맑음상주14.3맑음포항17.8맑음군산11.5맑음대구12.9맑음전주11.6맑음울산16.2맑음창원13.0맑음광주13.5맑음부산16.4맑음통영13.7맑음목포12.8맑음여수15.1맑음흑산도13.3맑음완도12.1맑음고창9.9맑음순천8.6맑음홍성12.5맑음서청주9.5맑음제주14.0맑음고산13.7맑음성산12.2맑음서귀포14.4맑음진주10.9맑음강화10.9맑음양평12.1맑음이천11.5맑음인제9.6맑음홍천10.4맑음태백12.8맑음정선군8.2맑음제천8.6맑음보은8.9맑음천안9.0맑음보령12.9맑음부여10.4맑음금산8.7맑음세종11.5맑음부안12.2맑음임실8.1맑음정읍9.5맑음남원9.4맑음장수6.9맑음고창군10.7맑음영광군10.8맑음김해시13.8맑음순창군9.2맑음북창원14.5맑음양산시12.8맑음보성군12.2맑음강진군10.0맑음장흥9.1맑음해남9.7맑음고흥10.0맑음의령군10.8맑음함양군11.0맑음광양시14.6맑음진도군10.1맑음봉화8.7맑음영주12.4맑음문경13.5맑음청송군11.7맑음영덕16.2맑음의성9.5맑음구미11.5맑음영천15.0맑음경주시10.6맑음거창8.4맑음합천11.5맑음밀양12.6맑음산청10.6맑음거제12.8맑음남해14.5맑음북부산12.1
  • 2024.05.10(금)

데이터 엔지니어링데이터 엔지니어링

[AWS] - Large Dependencies with AWS Lambda

간단한 서비스를 배포하기 위해 AWS를 사용하던 도중, Fast API와 같은 서비스가 아닌 최소한의 로직만을 품은 서비스를 배포해야하는 상황이 자주 발생하였다.

 

Screenshot 2024-04-01 at 11.13.34 AM.png

 

개발 싸이클의 최소화를 위해 AWS Lambda를 사용하여 서비스를 배포하며 겪은 시행착오와 해결 방법을 회고하고자 한다.

 

데이터 분석을 위한 이 서비스는 로우데이터를 가공하고 변형하여 Graph 형태 (https://en.wikipedia.org/wiki/Graph_theory)로 변환하고, GPT를 활용한 보조를 포함한 서비스이다.

 

이를 위한 requirements는 아래와 같다

 

Screenshot 2024-04-01 at 10.54.20 AM.png

 

위의 패키지들을 로컬과 개발 서버에서 사용하는데에는 문제가 없지만 AWS Lambda에서는 중요한 문제가 발생했다. 해당 문제는 다음과 같다 해당 서비스에 사용하는 dependency가 lambda 에서 허용하는 용량을 초과함 (un-zipped 250mb)

시도 방법은, Custom Dependencies를 간단하게 설치할수 있도록 S3에 해당 디펜던시들을 zip 파일로 업로드 하였으나, 위와 같은 문제에 직면하였다.

 

두번째 시도 방법은 zip파일이 아닌 Layer를 쌓는 방법으로 하였다.

초기에는 모든 dependencies를 layer로 만들었으나, layer 생성에 필요한 용량이 초과되어 다른 전략을 세웠다.

 

위의 dependencies에서 연관 있는 패키지들만을 사용하여 여러개의 layer를 만들어 lambda에 적용하는 방법을 시도 하였다.

 

layer-1 : pandas, numpy, scipy

layer-2 : plotly

layer-3 : tqdm, pydot, networkx

layer-4 : langchain, langchain-openai, wandb

layer-5: requests, boto3

 

그러나, 3번째 레이어까지 추가 하였을때 zip으로 package를 적용하는것과 동일하게 용량초과로 lambda가 만들어지지 않았다.

 

가장 간단한 방법 2가지가 실패하여, 마지막 수단으로 Lambda를 Docker Image를 사용하여 구동하는 방법으로 실행하였다.

 

AWS Lambda with Container Image

 

해당 방법은 AWS Lambda 콘솔에서 코드를 작성하던 일련의 과정을 개발 환경에서 구성후에 완성된 Image를 배포하는 식으로 진행 된다.

 

이후 docker 명령어를 통해 컨테이너를 빌드하고, 공식문서에 참조 되어 있는 Test Image를 통해 로컬에서 테스트를 진행하였다.

 

 

테스트가 성공되어 AWS의 ECR로 컨테이너를 푸시해주고, 해당 Image로 Lambda를 생성 및 테스트를 진행한다.

그러나 콘솔에서 테스트를 진행해보니 Error가 발생하였고, Cloud Watch로 확인을 진행하였다.

 

Log를 확인해보니, 기본적으로 AWS Lambda의 구동은 timout=3초로 설정되어 있어, 구성된 Image의 테스트 시간을 통해 timeout 시간과 memory 사이즈를 조절하여 배포 작업을 완료 하였다.

 

 

이후 일련의 과정, 

[Lambda 코드 작성] -> [Docker파일 작성 ] -> [로컬 테스트] -> [ECR 푸시] -> [Lambda 서비스 업데이트] 에서, 로컬 테스트, ECR 푸시, 서비스 업데이트는 사내 저장소인 git-lab의 CI/CD를 통해 자동 배포 되도록 하여 코드 수정시 사내서버에서 이미지 빌드 및 테스트를 진행하고 ECR로 푸시와 함께 AWS의 Lambda 서비스를 새로운 이미지로 업데이트가 자동으로 이루어지도록 하였다.

 

추가적으로, 개발은 arm64환경을 사용하나, 개발 서버는 x86_64 환경임으로, AWS Lambda를 구성할때 해당 CPU 아키텍처를 잘 선택해야 한다.

 

현재 배포된 서비스는 멀티빌드를 진행하지 않기에 개발서버에서 빌드되는 x86_64로 AWS Lambda를 구동중이다.

첨부파일
  • Screenshot 2024-04-01 at 11.13.34 AM.png(136.7KB)

전체댓글0

검색결과는 총 12건 입니다.    글쓰기
1