AWS Lambda 함수 작업을 위한 모범 사례

AWS Lambda 함수 작업을 위한 모범 사례

다음은 AWS Lambda 사용을 위한 권장 모범 사례예요:

주제

출처: AWS Lambda 개발자 안내서

본문

함수 코드

실행 환경 재사용을 활용해서 함수 성능을 개선하세요. SDK 클라이언트와 데이터베이스 연결을 함수 핸들러 밖에서 초기화하고, 정적 자산을 로컬 /tmp 디렉터리에 캐시하세요. 함수의 동일 인스턴스가 처리하는 후속 호출은 이러한 리소스를 재사용할 수 있어요. 이렇게 하면 함수 실행 시간을 줄여 비용을 절약할 수 있어요.

호출 간 잠재적 데이터 유출을 피하려면 실행 환경을 사용해서 사용자 데이터, 이벤트, 보안 영향이 있는 기타 정보를 저장하지 마세요. 함수가 핸들러 내 메모리에 저장할 수 없는 변경 가능한 상태에 의존한다면 사용자별로 별도의 함수나 함수 버전을 만드는 것을 고려하세요.

지속 연결을 유지하려면 keep-alive 지시문을 사용하세요. Lambda는 시간이 지나면 유휴 연결을 정리해요. 함수 호출 시 유휴 연결을 재사용하려고 하면 연결 오류가 발생해요. 지속 연결을 유지하려면 런타임과 연결된 keep-alive 지시문을 사용하세요. 예시는 Node.js에서 Keep-Alive로 연결 재사용을 참고하세요.

함수에 운영 매개변수를 전달하려면 환경 변수를 사용하세요. 예를 들어 Amazon S3 버킷에 쓰는 경우 쓰는 버킷 이름을 하드코딩하는 대신 환경 변수로 버킷 이름을 구성하세요.

Lambda 함수에서 재귀 호출을 피하세요. 함수가 자기 자신을 호출하거나 함수를 다시 호출할 수 있는 프로세스를 시작하는 방식이에요. 이로 인해 의도하지 않은 함수 호출 양과 비용 상승이 발생할 수 있어요. 의도하지 않은 호출 양이 보이면 코드를 업데이트하는 동안 함수에 대한 모든 호출을 제한하도록 함수의 예약 동시성을 즉시 0으로 설정하세요.

Lambda 함수 코드에서 문서화되지 않은 비공개 API를 사용하지 마세요. AWS Lambda 관리형 런타임의 경우 Lambda는 Lambda 내부 API에 보안 및 기능 업데이트를 주기적으로 적용해요. 이러한 내부 API 업데이트는 이전 버전과 호환되지 않을 수 있어 함수가 비공개 API에 의존하면 호출 실패 같은 의도하지 않은 결과가 발생할 수 있어요. 공개적으로 사용 가능한 API 목록은 API 참조를 참고하세요.

멱등 코드를 작성하세요. 함수에 대한 멱등 코드를 작성하면 중복 이벤트가 동일하게 처리되도록 보장돼요. 코드는 이벤트를 제대로 검증하고 중복 이벤트를 우아하게 처리해야 해요. 자세한 내용은 Lambda 함수를 멱등으로 만들려면 어떻게 하나요?를 참고하세요.

참고 Powertools for AWS Lambda를 사용해서 함수를 멱등으로 만들 수 있어요. 자세한 내용은 다음을 참고하세요: Python - Idempotency utility TypeScript - Idempotency utility Java - Idempotency utility .NET - Idempotency utility

언어별 코드 모범 사례는 다음 섹션을 참고하세요:

함수 구성

Lambda 함수에 대한 성능 테스트는 최적의 메모리 크기 구성을 선택하도록 하는 데 중요한 부분이에요. 메모리 크기를 늘리면 함수에 사용 가능한 CPU도 동일하게 증가해요. 함수의 메모리 사용량은 호출별로 결정되며 Amazon CloudWatch에서 볼 수 있어요. 각 호출 시 아래와 같이 REPORT: 항목이 만들어져요:

REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3	Duration: 12.34 ms	Billed Duration: 100 ms Memory Size: 128 MB	Max Memory Used: 18 MB

Max Memory Used: 필드를 분석하면 함수에 더 많은 메모리가 필요한지, 아니면 함수의 메모리 크기를 과도하게 프로비저닝했는지 확인할 수 있어요.

함수에 맞는 올바른 메모리 구성을 찾으려면 오픈소스 AWS Lambda Power Tuning 프로젝트를 사용하는 것을 권장해요. 자세한 내용은 GitHub의 AWS Lambda Power Tuning을 참고하세요.

함수 성능을 최적화하려면 Advanced Vector Extensions 2(AVX2)를 사용할 수 있는 라이브러리를 배포하는 것도 권장해요. 이를 통해 머신러닝 추론, 미디어 처리, 고성능 컴퓨팅(HPC), 과학 시뮬레이션, 금융 모델링을 포함한 까다로운 워크로드를 처리할 수 있어요. 자세한 내용은 AVX2로 더 빠른 AWS Lambda 함수 만들기를 참고하세요.

Lambda 함수를 부하 테스트해서 최적의 시간 초과 값을 결정하세요. 함수가 실행되는 시간을 분석하는 것은 종속 서비스에 예상보다 함수의 동시성을 높일 수 있는 문제가 있는지 더 잘 파악하는 데 중요해요. 이는 특히 Lambda 함수가 Lambda의 확장을 처리하지 못할 수 있는 리소스에 네트워크 호출을 할 때 중요해요. 애플리케이션 부하 테스트에 대한 자세한 내용은 AWS의 분산 부하 테스트를 참고하세요.

IAM 정책을 설정할 때 가장 제한적인 권한을 사용하세요. Lambda 함수가 필요로 하는 리소스와 작업을 이해하고 실행 역할을 이러한 권한으로 제한하세요. 자세한 내용은 AWS Lambda에서 권한 관리를 참고하세요.

Lambda 할당량을 잘 알아두세요. 런타임 리소스 한도를 결정할 때 페이로드 크기, 파일 디스크립터, /tmp 공간이 자주 간과돼요.

더 이상 사용하지 않는 Lambda 함수를 삭제하세요. 그렇게 하면 사용하지 않는 함수가 배포 패키지 크기 제한에 무의미하게 포함되지 않아요.

이벤트 소스로 Amazon Simple Queue Service를 사용한다면 함수의 예상 호출 시간 값이 큐의 Visibility Timeout 값을 초과하지 않는지 확인하세요. 이는 CreateFunction과 UpdateFunctionConfiguration 모두에 적용돼요.

  • CreateFunction의 경우 AWS Lambda는 함수 생성 프로세스를 실패시켜요.
  • UpdateFunctionConfiguration의 경우 함수가 중복 호출될 수 있어요.

함수 확장성

업스트림 및 다운스트림 처리량 제약을 잘 알아두세요. Lambda 함수는 부하에 따라 원활하게 확장되지만 업스트림·다운스트림 종속성은 동일한 처리량 기능을 갖지 않을 수 있어요. 함수가 확장될 수 있는 최대치를 제한해야 한다면 함수에 예약 동시성을 구성할 수 있어요.

스로틀 내성을 구축하세요. 트래픽이 Lambda의 확장 속도를 초과해서 동기 함수가 스로틀링되는 경우 다음 전략을 사용해서 스로틀 내성을 개선할 수 있어요:

  • 타임아웃, 재시도, 지터가 있는 백오프를 사용하세요. 이러한 전략을 구현하면 재시도된 호출이 매끄럽게 처리되어 초 단위로 확장할 수 있도록 돕고 최종 사용자 스로틀링을 최소화해요.
  • 프로비저닝된 동시성을 사용하세요. 프로비저닝된 동시성은 Lambda가 함수에 할당하는 사전 초기화된 실행 환경의 수예요. Lambda는 사용 가능할 때 프로비저닝된 동시성을 사용해서 들어오는 요청을 처리해요. Lambda는 필요하다면 프로비저닝된 동시성 설정을 넘어 함수를 확장할 수도 있어요. 프로비저닝된 동시성을 구성하면 AWS 계정에 추가 비용이 발생해요.

지표 및 경보

Lambda 함수 코드 내에서 지표를 만들거나 업데이트하는 대신 CloudWatch 지표와 함께 Lambda 사용 및 CloudWatch 경보를 사용하세요. Lambda 함수의 상태를 추적하는 훨씬 더 효율적인 방법이며 개발 프로세스 초기에 문제를 잡을 수 있게 해줘요. 예를 들어 Lambda 함수 호출의 예상 기간에 기반한 경보를 구성해서 함수 코드로 인한 병목 현상이나 대기 시간을 해결할 수 있어요.

Embedded Metric Format(EMF)을 사용해 사용자 지정 지표를 비동기식으로 내보내세요. CloudWatch에 동기 API 호출을 하는 대신 EMF를 사용해서 함수의 로그를 통해 지표를 내보내세요. 이 접근 방식은 대기 시간을 줄이고 성능을 개선해요.

Powertools for AWS Lambda의 Metrics 유틸리티는 EMF 포맷팅을 자동으로 처리해요. 자세한 내용은 Powertools for AWS Lambda 문서의 Python, TypeScript, Java, .NET Metrics 유틸리티를 참고하세요. EMF를 사용해 지표 형식 로그를 생성하는 방법은 Amazon CloudWatch 사용 설명서의 임베디드 지표 형식으로 로그 게시를 참고하세요.

더 나은 관측성을 위해 구조화된 JSON 로깅을 사용하세요. 구조화된 로깅을 사용하면 함수의 로그를 더 쉽게 검색·필터링·분석할 수 있어요. Powertools for AWS Lambda의 Logger 유틸리티를 사용해서 로그를 JSON으로 자동 포맷하는 것을 고려하세요. 자세한 내용은 Powertools for AWS Lambda 문서의 Python, TypeScript, Java, .NET Logger 유틸리티를 참고하세요.

로깅 라이브러리와 AWS Lambda 지표 및 차원을 사용해서 앱 오류(예: ERR, ERROR, WARNING)를 잡으세요.

AWS Cost Anomaly Detection을 사용해서 계정의 비정상적인 활동을 감지하세요. Cost Anomaly Detection은 오탐 경보를 최소화하면서 비용과 사용량을 지속적으로 모니터링하기 위해 머신러닝을 사용해요. Cost Anomaly Detection은 최대 24시간 지연이 있는 AWS Cost Explorer의 데이터를 사용해요.

결과적으로 사용량 발생 후 이상 현상을 감지하는 데 최대 24시간이 걸릴 수 있어요. Cost Anomaly Detection을 시작하려면 먼저 Cost Explorer에 가입해야 해요. 그런 다음 Cost Anomaly Detection에 액세스하세요.

스트림 작업

다양한 배치 및 레코드 크기로 테스트해서 각 이벤트 소스의 폴링 빈도가 함수가 작업을 완료할 수 있는 속도에 맞게 조정되도록 하세요. CreateEventSourceMapping BatchSize 매개변수는 각 호출 시 함수로 보낼 수 있는 최대 레코드 수를 제어해요. 배치 크기가 클수록 더 많은 레코드 집합에 걸쳐 호출 오버헤드를 더 효율적으로 흡수해서 처리량을 높일 수 있는 경우가 많아요.

기본적으로 Lambda는 레코드를 사용할 수 있는 즉시 함수를 호출해요. Lambda가 이벤트 소스에서 읽는 배치에 레코드가 하나만 있으면 Lambda는 함수에 레코드를 하나만 보내요. 소수의 레코드로 함수를 호출하지 않으려면 배칭 창을 구성해서 이벤트 소스가 최대 5분 동안 레코드를 버퍼링하도록 지시할 수 있어요. 함수를 호출하기 전에 Lambda는 전체 배치를 모으거나, 배칭 창이 만료되거나, 배치가 6MB의 페이로드 한도에 도달할 때까지 이벤트 소스에서 레코드를 계속 읽어요. 자세한 내용은 배칭 동작을 참고하세요.

경고 Lambda 이벤트 소스 매핑은 각 이벤트를 최소 한 번 처리하며 레코드의 중복 처리가 발생할 수 있어요. 중복 이벤트와 관련된 잠재적 문제를 피하려면 함수 코드를 멱등으로 만들 것을 강력히 권장해요. 자세한 내용은 AWS Knowledge Center의 Lambda 함수를 멱등으로 만들려면 어떻게 하나요를 참고하세요.

스트림 처리를 위해 부분 배치 응답을 활성화하세요. Kinesis나 DynamoDB Streams 같은 스트림에서 레코드 배치를 처리할 때 부분 배치 응답을 활성화해서 Lambda가 전체 배치 대신 실패한 레코드만 재시도하도록 하세요. 이렇게 하면 처리 효율이 개선되고 불필요한 재처리가 줄어들어요. 선택적으로 Powertools for AWS Lambda의 Batch 유틸리티를 사용해서 배치 처리 패턴을 단순화할 수 있어요.

참고 배치 처리에 Powertools for AWS Lambda를 사용할 수 있어요. 자세한 내용은 다음을 참고하세요: Python - Batch Processing TypeScript - Batch Processing Java - Batch Processing .NET - Batch Processing

샤드를 추가해서 Kinesis 스트림 처리 처리량을 늘리세요. Kinesis 스트림은 하나 이상의 샤드로 구성돼요. Lambda가 Kinesis에서 데이터를 읽을 수 있는 속도는 샤드 수에 따라 선형적으로 확장돼요.

샤드 수를 늘리면 최대 동시 Lambda 함수 호출 수가 직접 늘어나고 Kinesis 스트림 처리 처리량이 증가할 수 있어요. 샤드와 함수 호출 간의 관계에 대한 자세한 내용은 스트림 폴링 및 배칭을 참고하세요. Kinesis 스트림의 샤드 수를 늘린다면 데이터에 좋은 파티션 키를 선택했는지(참고: 파티션 키) 확인해서 관련 레코드가 동일한 샤드에 모이고 데이터가 잘 분산되도록 하세요.

IteratorAge에 Amazon CloudWatch를 사용해서 Kinesis 스트림이 처리되고 있는지 확인하세요. 예를 들어 최대 설정 30000(30초)으로 CloudWatch 경보를 구성하세요.

보안 모범 사례

AWS Security Hub CSPM을 사용해서 보안 모범 사례와 관련된 AWS Lambda 사용을 모니터링하세요. Security Hub CSPM은 보안 컨트롤을 사용해서 리소스 구성을 평가하고, 다양한 규정 준수 프레임워크를 준수하도록 돕는 보안 표준을 평가해요. Security Hub CSPM을 사용해 Lambda 리소스를 평가하는 방법에 대한 자세한 내용은 AWS Security Hub CSPM 사용 설명서의 AWS Lambda 컨트롤을 참고하세요.

Amazon GuardDuty Lambda Protection을 사용해서 Lambda 네트워크 활동 로그를 모니터링하세요. GuardDuty Lambda protection은 AWS 계정에서 Lambda 함수가 호출될 때 잠재적 보안 위협을 식별하는 데 도움을 줘요. 예를 들어 함수 중 하나가 암호화폐 관련 활동과 연결된 IP 주소를 조회하는 경우가 있어요. GuardDuty는 Lambda 함수가 호출될 때 생성되는 네트워크 활동 로그를 모니터링해요. 자세한 내용은 Amazon GuardDuty 사용 설명서의 Lambda protection을 참고하세요.

더 알아보기 (Learn more)

이 주제는 AWS Lambda 함수 작업을 위한 모범 사례를 설명해요. 각 영역에 대한 구체적인 지침은 Lambda 개발자 안내서의 관련 주제를 참고하세요.