AWS Lambda 함수 작업의 모범 사례 - AWS Lambda
함수 코드함수 구성함수의 확장성지표 및 경보스트림 작업보안 모범 사례

AWS Lambda 함수 작업의 모범 사례

다음은 AWS Lambda 사용에 대한 권장 모범 사례입니다.

함수 코드

  • 실행 환경 재사용을 활용하여 함수 성능을 향상시킵니다. 함수 핸들러 외부에서 SDK 클라이언트 및 데이터베이스 연결을 초기화하고 정적 자산을 /tmp 디렉토리에 로컬로 캐시합니다. 동일한 함수 인스턴스에서 처리하는 후속 호출은 이러한 리소스를 재사용할 수 있습니다. 이를 통해 함수 실행 시간을 줄여 비용을 절감합니다.

    호출에서 발생할 수 있는 데이터 유출을 방지하려면 실행 환경을 사용하여 사용자 데이터, 이벤트 또는 보안과 관련된 기타 정보를 저장하지 마세요. 함수가 핸들러 내부 메모리에 저장할 수 없는 변경 가능한 상태에 의존하는 경우 각 사용자에 대해 별도의 함수 또는 별도의 함수 버전을 생성하는 것이 좋습니다.

  • 연결 유지 지시문을 사용하여 지속적인 연결을 유지하세요. Lambda는 시간이 지남에 따라 유휴 연결을 제거합니다. 함수를 호출할 때 유휴 연결을 재사용하려고 하면 연결 오류가 발생합니다. 지속적인 연결을 유지하려면 런타임과 관련된 연결 유지 지시문을 사용하세요. 예를 들어, Node.js에서 연결 유지를 이용해 연결 재사용을 참조하세요.

  • 환경 변수를 사용하여 함수에 운영 파라미터를 전달합니다. 예를 들어, Amazon S3 버킷에 기록하는 경우 기록하고 있는 버킷 이름을 하드 코딩하는 대신 환경 변수로 구성합니다.

  • Lambda 함수에서 함수가 자기 자신을 간접적으로 호출하거나 함수를 다시 간접적으로 호출할 수 있는 프로세스를 시작하는 재귀적 호출을 사용하지 마세요. 리커시브 코드를 사용할 경우, 의도하지 않은 함수 호출이 증가하고 비용이 상승할 수 있습니다. 의도치 않게 간접 호출이 대량으로 발생하는 경우 함수의 예약된 동시성을 즉시 0으로 설정하여 코드를 업데이트하는 동안 해당 함수에 대한 모든 간접 호출을 제한합니다.

  • Lambda 함수 코드에는 문서화되지 않은 비공개 API를 사용하지 마세요. AWS Lambda 관리형 런타임의 경우, Lambda는 주기적으로 보안 및 기능 업데이트를 Lambda의 내부 API에 적용합니다. 이러한 내부 API 업데이트는 이전 버전과 호환되지 않으므로 함수가 이러한 비공개 API에 종속성을 갖는 경우 호출 실패와 같은 의도하지 않은 결과를 초래할 수 있습니다. 공개적으로 사용 가능한 API의 목록은 API 레퍼런스를 참조하세요.

  • 멱등성 코드를 작성합니다. 함수에 멱등성 코드를 작성하면 중복 이벤트가 동일한 방식으로 처리됩니다. 코드는 이벤트를 올바르게 검증하고 중복 이벤트를 정상적으로 처리해야 합니다. 자세한 내용은 멱등성 Lambda 함수를 만들려면 어떻게 해야 합니까? 단원을 참조하십시오.

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

함수 구성

  • 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), 과학 시뮬레이션, 금융 모델링 등 까다로운 워크로드를 처리할 수 있습니다. 자세한 내용은 Creating faster AWS Lambda functions with AVX2를 참조하세요.

  • Lambda 함수를 로드 테스트하여 최적의 제한 시간 값을 확인합니다. 함수의 실행 시간을 분석하여 함수의 동시성을 기대 이상으로 높일 수 있는 종속성 서비스를 통해 문제를 더 효과적으로 확인하는 것이 중요합니다. 이는 Lambda 함수가 Lambda의 조정을 처리하지 못할 수 있는 리소스에 대한 네트워크 호출을 수행할 때 특히 중요합니다. 애플리케이션의 로드 테스트에 대한 자세한 내용은 AWS의 분산 로드 테스트를 참조하세요.

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

  • Lambda 할당량 단원의 내용을 숙지합니다. 페이로드 크기, 파일 설명자 및 /tmp 공간은 런타임 리소스 제한을 결정할 때 자주 간과됩니다.

  • 더 이상 사용하지 않는 Lambda 함수를 삭제합니다. 삭제하면 사용되지 않는 함수는 배포 패키지 크기 제한에 불필요하게 포함되지 않습니다.

  • 이벤트 소스로 Amazon Simple Queue Service를 사용하는 경우 함수의 예상 호출 시간 값이 대기열의 표시 제한 시간 값을 초과하지 않도록 합니다. 이는 CreateFunction 및 UpdateFunctionConfiguration 모두에 적용됩니다.

    • CreateFunction의 경우 AWS Lambda가 함수 생성 프로세스에 실패합니다.

    • UpdateFunctionConfiguration의 경우, 함수가 중복 호출될 수 있습니다.

함수의 확장성

  • 업스트림 및 다운스트림 처리량 제한 사항을 잘 알고 있어야 합니다. Lambda 함수는 로드에 따라 원활하게 규모를 조정할 수 있지만 업스트림 및 다운스트림 종속성의 처리량 용량이 동일하지 않을 수 있습니다. 함수의 규모 조정 가능 범위를 제한해야 하는 경우 함수에서 예약된 동시성을 구성할 수 있습니다.

  • 제한 허용치를 구축하세요. Lambda의 조정 속도를 초과하는 트래픽으로 인해 동기 함수에서 제한이 발생하는 경우 다음 전략을 사용하여 제한 허용치를 개선할 수 있습니다.

    • 시간 제한, 재시도, 지터가 포함된 백오프를 사용하세요. 이러한 전략을 구현하면 간접 호출의 재시도가 원활해지고 Lambda가 몇 초 내에 스케일 업하여 최종 사용자 제한을 최소화할 수 있습니다.

    • 프로비저닝된 동시성을 사용하세요. 프로비저닝된 동시성은 Lambda가 함수에 할당하는 사전 초기화된 실행 환경의 수입니다. Lambda는 가능한 경우 프로비저닝된 동시성을 사용하여 수신 요청을 처리합니다. 또한 필요한 경우 Lambda는 프로비저닝된 동시성 설정 이상으로 함수를 확장할 수도 있습니다. 프로비저닝된 동시성을 구성하는 경우 AWS 계정에 추가 요금이 부과됩니다.

지표 및 경보

  • Lambda 함수 코드 내에서 지표를 생성하거나 업데이트하는 대신 Lambda 함수에 대한 지표 보기 및 CloudWatch 경보를 사용합니다. 이는 Lambda 함수의 상태를 파악하는 훨씬 더 효율적인 방법이며, 개발 프로세스 초기에 문제를 파악할 수 있습니다. 예를 들어, 함수 코드로 인한 병목 현상이나 지연 시간을 해결하기 위해 예상되는 Lambda 함수 호출 소요 시간을 기준으로 경보를 구성할 수 있습니다.

  • 로깅 라이브러리 및 AWS Lambda 지표 및 차원을 사용하여 앱 오류를 파악합니다(ERR, ERROR, WARNING 등).

  • AWS Cost Anomaly Detection을 사용하여 계정에서 비정상적인 활동을 감지합니다. Cost Anomaly Detection은 기계 학습을 사용하여 비용과 사용량을 모니터링하고 오탐지 알림을 최소화합니다. Cost Anomaly Detection은 AWS Cost Explorer의 데이터를 사용하며, 최대 24시간의 지연이 있습니다. 따라서 사용량이 발생한 후 이상 탐지에 최대 24시간이 걸릴 수 있습니다. Cost Anomaly Detection을 시작하려면 먼저 Cost Explorer에 가입해야 합니다. 이후 Cost Anomaly Detection에 액세스합니다.

스트림 작업

  • 서로 다른 배치 및 레코드 크기로 테스트하여 각 이벤트 소스의 폴링 빈도를 조정하고 해당 함수가 얼마나 빨리 작업을 완료할 수 있는지 확인합니다. CreateEventSourceMapping BatchSize 파라미터는 각 호출에서 함수로 보낼 수 있는 최대 레코드 수를 제어합니다. 배치 크기가 클수록 더 큰 레코드 세트에서 호출 오버헤드를 더 효율적으로 수용하여 처리량을 늘릴 수 있습니다.

    기본적으로, Lambda는 레코드가 사용 가능하게 되는 즉시 함수를 호출합니다. Lambda가 이벤트 소스에서 읽는 배치에 하나의 레코드만 있는 경우, Lambda는 함수에 하나의 레코드만 전송합니다. 소수의 레코드로 함수를 호출하는 것을 피하려면 일괄 처리 기간을 구성하여 이벤트 소스가 최대 5분 동안 레코드를 버퍼링하도록 지정할 수 있습니다. 함수를 호출하기 전에 Lambda는 전체 배치가 수집되거나, 일괄 처리 기간이 만료되거나, 배치가 페이로드 한도인 6MB에 도달할 때까지 이벤트 소스에서 레코드를 계속 읽습니다. 자세한 내용은 일괄 처리 동작 단원을 참조하십시오.

    주의

    Lambda 이벤트 소스 매핑은 각 이벤트를 한 번 이상 처리하므로 레코드가 중복될 수 있습니다. 중복 이벤트와 관련된 잠재적 문제를 방지하려면 함수 코드를 멱등성으로 만드는 것이 좋습니다. 자세한 내용은 AWS 지식 센터의 멱등성 Lambda 함수를 만들려면 어떻게 해야 합니까?를 참조하세요.

  • 샤드를 추가하여 Kinesis 스트림 처리량을 늘립니다. Kinesis 스트림은 하나 이상의 샤드로 구성됩니다. Lambda가 Kinesis에서 데이터를 읽을 수 있는 속도는 샤드 수에 따라 선형적으로 조정됩니다. 샤드 수를 늘리면 Lambda 함수의 최대 동시 호출 수가 증가하고 Kinesis 스트림 처리량이 증가할 수 있습니다. 샤드와 함수 호출 간의 관계에 대한 자세한 내용은 폴링 및 배치 처리 스트림 섹션을 참조하세요. Kinesis 스트림에서 샤드 수를 늘리는 경우 데이터에 대해 적절한 파티션 키를 선택하여(파티션 키 참조) 관련 레코드가 동일한 샤드에서 끝나며 데이터가 잘 분산되도록 해야 합니다.

  • IteratorAge에 대해 Amazon CloudWatch를 사용하여 Kinesis 스트림이 처리 중인지 확인합니다. 예를 들어 최대 값을 30,000(30초)으로 설정하여 CloudWatch 경보를 구성합니다.

보안 모범 사례

  • AWS Security Hub을 사용하여 보안 모범 사례와 관련된 AWS Lambda의 사용량을 모니터링하십시오. Security Hub는 보안 제어를 사용하여 리소스 구성 및 보안 표준을 평가하여 다양한 규정 준수 프레임워크를 준수할 수 있도록 지원합니다. Security Hub를 사용하여 Lambda 리소스를 평가하는 방법에 대한 자세한 내용은 AWS Security Hub 사용 설명서의 AWS Lambda 제어를 참조하십시오.

  • Amazon GuardDuty Lambda 보호를 사용하여 Lambda 네트워크 활동 로그를 모니터링하세요. GuardDuty Lambda 보호를 사용하면 AWS 계정에서 Lambda 함수가 호출될 때 잠재적인 보안 위협을 식별하는 데 도움이 됩니다. 함수 중 하나가 가상 화폐와 관련된 활동과 연결된 IP 주소를 쿼리하는 경우를 예로 들 수 있습니다. GuardDuty는 Lambda 함수 호출 시 생성되는 네트워크 활동 로그를 모니터링합니다. 자세한 내용은 Amazon GuardDuty 사용 설명서의 Lambda 보호를 참조하세요.