Lambda 배포 파일을 가볍게 만든 이유

AWS 실전 운영 시리즈 3/12

Lambda는 배포가 단순하다.

코드를 zip으로 묶고 update-function-code를 실행하면 된다.

하지만 Python Lambda에서 엑셀 생성 라이브러리나 데이터베이스 드라이버를 함께 넣기 시작하면 배포 파일이 금방 무거워진다.

작은 코드 하나를 고쳤을 뿐인데 매번 큰 zip 파일을 만들고 올려야 한다면 배포가 느려지고 실수 가능성도 커진다.

그래서 Lambda Layer를 사용해 함수 코드와 의존성을 분리했다.

문제 상황

운영 콘솔에는 리포트 파일을 생성하는 Lambda가 있었다.

이 함수는 단순 API 응답만 하는 것이 아니라 다음 작업을 했다.

• 데이터베이스 조회
• 엑셀 파일 생성
• object storage 업로드
• 작업 상태 갱신

Python 코드 자체는 크지 않았다.

하지만 엑셀 생성 라이브러리와 DB 드라이버 같은 의존성이 필요했다.

모든 의존성을 함수 zip에 포함하면 배포 파일이 커지고, 코드만 바뀌어도 전체 패키지를 다시 올려야 했다.

Lambda Layer란 무엇인가

Lambda Layer는 함수 코드와 별도로 배포하는 공용 파일 묶음이다.

보통 다음을 넣는다.

• Python 패키지
• 공통 라이브러리
• binary dependency
• 여러 함수가 공유하는 코드

함수는 실행 시 Layer를 함께 mount해서 사용할 수 있다.

구조를 단순화하면 이렇다.

Lambda function code
  -> lambda_function.py

Lambda Layer
  -> pymysql
  -> xlsxwriter
  -> other dependencies

함수 코드는 가볍게 유지하고, 무거운 의존성은 Layer에 둔다.

배포 단위도 이렇게 나뉜다.

핵심은 코드 변경과 런타임 의존성 변경을 같은 배포로 묶지 않는 것이다. 매번 전체 라이브러리를 다시 올리지 않아도 되면 배포가 빨라지고, 실패했을 때 되돌릴 범위도 작아진다.

코드 배포와 의존성 배포를 나누기

Layer를 쓰는 가장 큰 장점은 배포 단위를 나누는 것이다.

일상적인 배포에서는 코드만 바뀐다.

• API 분기 수정
• 쿼리 조건 수정
• 응답 형식 수정
• 오류 처리 수정

이때 의존성은 바뀌지 않는다.

따라서 함수 코드만 압축해서 배포하면 된다.

zip lambda-function-code-only.zip lambda_function.py
aws lambda update-function-code \
  --function-name report-api-function \
  --zip-file fileb://lambda-function-code-only.zip

의존성이 바뀔 때만 Layer를 새로 만든다.

이렇게 하면 배포가 빨라지고, 변경 범위도 명확해진다.

배포 안정성 측면의 장점

Layer는 단순히 zip 크기를 줄이는 기능이 아니다.

배포 안정성에도 도움이 된다.

함수 코드와 의존성을 함께 묶으면 매 배포마다 런타임 환경 전체가 바뀔 수 있다.

반면 Layer를 고정하면 코드 변경 배포의 영향 범위가 줄어든다.

예를 들어 엑셀 생성 라이브러리 버전은 그대로 두고, 리포트 조건만 수정할 수 있다.

이 차이는 운영 중 중요하다.

문제가 생겼을 때 "코드가 문제인지, 의존성 버전이 문제인지" 구분하기 쉬워진다.

Layer를 쓸 때 조심할 점

Layer도 관리 대상이다.

다음은 주의해야 한다.

• 런타임 Python 버전과 Layer 빌드 환경이 맞는가
• 필요한 패키지가 올바른 경로에 들어 있는가
• 함수에 Layer가 연결되어 있는가
• 여러 Layer의 순서가 충돌하지 않는가
• Layer 버전을 바꿨을 때 기존 함수가 영향받지 않는가

특히 런타임 버전이 중요하다.

Python 3.9용으로 만든 Layer를 다른 런타임에서 그대로 쓰면 문제가 날 수 있다.

내부 운영 문서에는 Layer 이름, ARN, 포함 패키지, 적용 함수, 교체 절차를 남겨야 한다.

코드만 압축하는 배포

Layer를 적용한 뒤에는 함수 코드만 압축한다.

예를 들어 다음처럼 단순해진다.

zip lambda-function-code-only.zip lambda_function.py

이 파일에는 site-packages나 무거운 라이브러리가 들어가지 않는다.

이 방식은 배포 속도뿐 아니라 실수 방지에도 좋다.

누군가 로컬 환경의 불필요한 파일을 zip에 포함할 가능성이 줄어든다.

언제 Layer가 필요할까

모든 Lambda에 Layer가 필요한 것은 아니다.

다음 조건이면 검토할 만하다.

• 함수 zip이 커지고 있다.
• 무거운 라이브러리를 사용한다.
• 여러 함수가 같은 의존성을 쓴다.
• 코드 변경과 의존성 변경을 분리하고 싶다.
• 배포 속도가 느려지고 있다.
• zip 크기 제한에 가까워지고 있다.

반대로 작은 함수 하나에 의존성이 거의 없다면 Layer 없이 단순 배포가 더 낫다.

Layer도 결국 관리해야 할 리소스이기 때문이다.

Layer와 컨테이너 이미지 방식

Lambda는 zip 배포 외에 컨테이너 이미지 방식도 지원한다.

의존성이 매우 크거나 OS 수준 패키지가 많다면 컨테이너 이미지가 나을 수 있다.

하지만 작은 운영 콘솔의 Python Lambda에서는 zip + Layer 조합이 충분했다.

선택 기준은 이렇다.

방식	적합한 경우
zip only	작은 함수, 의존성 적음
zip + Layer	의존성은 있지만 코드 배포를 가볍게 유지하고 싶음
container image	OS 패키지, 큰 의존성, 복잡한 런타임 필요

처음부터 가장 무거운 방식을 쓸 필요는 없다.

운영 문서에 남길 것

Layer를 쓰면 문서화가 중요하다.

다음 항목을 남겨야 한다.

• 어떤 Layer가 필요한가
• 어떤 패키지가 들어 있는가
• 어떤 함수에 연결되어 있는가
• Layer를 제거하면 어떤 기능이 실패하는가
• 코드 배포와 Layer 배포 절차가 어떻게 다른가
• 새 버전 Layer를 적용한 뒤 검증할 API는 무엇인가

특히 "Layer를 삭제하면 엑셀 생성이 실패한다" 같은 운영 주의사항은 HANDOVER에 적어야 한다.

정리

Lambda 배포 파일을 가볍게 만든 이유는 단순히 용량을 줄이기 위해서가 아니다.

운영 배포의 변경 범위를 줄이기 위해서다.

함수 코드는 자주 바뀐다.

의존성은 자주 바뀌지 않는다.

이 둘을 같은 zip에 묶으면 매번 큰 배포가 된다.

Layer로 분리하면 코드만 빠르게 배포하고, 런타임 의존성은 별도로 관리할 수 있다.

작은 Lambda라도 운영 중이라면 배포 단위를 나누는 것이 안정성에 도움이 된다.

함께 볼 GitHub 저장소

• aws-console-operations-notes