Lambda Managed Instances 모범 사례

Lambda Managed Instances 모범 사례

용량 공급자 구성

신뢰 수준별로 용량 공급자를 분리하세요. 보안 요구 사항이 다른 워크로드를 위해 다른 용량 공급자를 만드세요. 용량 공급자는 보안 경계 역할을 하므로 같은 용량 공급자에 할당된 모든 함수는 서로 신뢰할 수 있어야 해요.

설명적인 이름을 사용하세요. 의도된 용도와 신뢰 수준을 명확히 나타내도록 용량 공급자의 이름을 지정하세요(예: production-trusted, dev-sandbox). 이렇게 하면 팀이 각 용량 공급자의 목적과 보안 자세를 이해할 수 있어요.

여러 가용 영역을 사용하세요. 용량 공급자를 만들 때 여러 가용 영역에 걸친 서브넷을 지정하세요. Lambda는 AZ 복원력을 위해 기본적으로 인스턴스 3개를 시작해서 함수의 고가용성을 보장해요.

출처: AWS Lambda 개발자 안내서

본문

인스턴스 유형 선택

Lambda가 인스턴스 유형을 선택하게 하세요. 기본적으로 Lambda는 워크로드에 가장 적합한 인스턴스 유형을 선택해요. 가능한 인스턴스 유형 수를 제한하면 가용성이 낮아질 수 있으므로 Lambda Managed Instances가 인스턴스 유형을 선택하게 하는 것을 권장해요.

특정 요구 사항에 대해 인스턴스 유형을 지정하세요. 특정 하드웨어 요구 사항이 있다면 허용 인스턴스 유형을 호환 가능한 인스턴스 목록으로 설정해요. 예:

  • 높은 네트워크 대역폭이 필요한 애플리케이션의 경우 여러 n 인스턴스 유형을 선택해요
  • 비용 제약이 있는 테스트·개발 환경의 경우 m7a.large 같은 더 작은 인스턴스 유형을 선택해요

함수 구성

적절한 메모리와 vCPU 설정을 선택하세요. 함수의 다중 동시 실행을 지원하는 메모리와 vCPU 구성을 선택해요. 지원되는 최소 함수 크기는 2GB와 1 vCPU예요.

  • Python 애플리케이션의 경우 Python이 다중 동시성을 처리하는 방식 때문에 더 높은 메모리-대-vCPU 비율(4:1 또는 8:1 같은)을 선택해요
  • CPU 집약적 작업이거나 IO가 적은 함수의 경우 vCPU를 둘 이상 선택해요
  • 웹 서비스나 배치 작업 같은 IO 중심 애플리케이션의 경우 다중 동시성이 가장 큰 이점을 제공해요

최대 동시성을 적절히 구성하세요. Lambda는 리소스 소비와 처리량의 균형을 맞춘 합리적인 최대 동시성 기본값을 선택해요. 함수의 리소스 사용량에 따라 이 설정을 조정해요:

  • 함수 호출이 CPU를 거의 사용하지 않는다면 최대 동시성을 늘려요(vCPU당 최대 64)
  • 애플리케이션이 많은 메모리를 소비하고 CPU를 거의 사용하지 않는다면 최대 동시성을 줄여요

동시성이 매우 낮은 실행 환경은 스로틀이 발생하고 확장이 어려울 수 있다는 점에 유의하세요.

장기 실행 함수

AWS Lambda Managed Instances의 함수는 비동기 호출과 이벤트 소스 매핑 호출의 경우 호출당 최대 90분(5,400초)까지 실행될 수 있어요. 단, Amazon MQ와 Amazon DocumentDB 이벤트 소스 매핑은 15분으로 제한돼요. 동기 호출과 함수 초기화 단계도 15분으로 유지돼요. 타임아웃 설정에 대한 자세한 내용은 Lambda 함수 타임아웃 구성을 참고하세요. 함수가 더 오래 실행될 수 있으므로 네트워크 연결과 자격 증명 같은 본질적으로 일시적인 구성 요소에 대해 다음 사항을 검토하세요.

유휴 연결 타임아웃을 수용하세요. Amazon RDS, Amazon ElastiCache, 외부 API 같은 다운스트림 서비스의 유휴 연결 타임아웃이 전체 함수 기간을 수용하는지 확인하세요. 함수가 NAT 게이트웨이를 통해 트래픽을 라우팅한다면 NAT 게이트웨이의 350초 유휴 타임아웃 후 유휴 연결이 끊기지 않도록 keep-alive 패킷을 보내세요.

DNS TTL 값을 존중하세요. 외부 호스트 이름을 확인할 때 DNS TTL 값을 존중하세요. AWS SDK는 이를 자동으로 처리하지만, 사용자 지정 HTTP 클라이언트는 TTL을 초과해 DNS 확인을 캐시할 수 있어요.

임시 자격 증명을 새로 고치세요. 함수가 임시 자격 증명이나 토큰을 획득한다면 전체 실행 기간 동안 유효한지 확인하거나 백그라운드에서 새로 고치세요.

멱등성을 위해 설계하세요. Lambda는 정확히 한 번(exactly-once) 처리를 보장하지 않아요. 함수가 더 오래 실행될수록 재시도와 중복 전달의 창이 커져요. Powertools for AWS Lambda를 사용해서 결제나 데이터베이스 쓰기 같은 작업에 멱등성을 구현해서 여러 번 실행되어도 같은 결과를 만들어내게 하세요. Lambda 내구성 함수를 사용하면 단계는 적어도 한 번(at-least-once) 실행 의미론을 가져요. 내구성 실행 SDK는 재생 중 완료된 단계를 건너뛰지만, 체크포인트 전에 실패한 단계는 다시 실행될 수 있어요. 실행 이름을 멱등성 키로 사용할 수 있어요.

더 긴 처리를 위해 이벤트 소스 매핑을 조정하세요. Amazon SQS의 경우 큐의 가시성 타임아웃을 함수 타임아웃의 최소 6배로 설정해서 함수가 스로틀될 때 Lambda가 배치를 재시도할 시간이 충분하게 하세요. Lambda는 이벤트 소스 매핑을 만들 때 이를 검증하지만, 나중에 불일치를 만드는 큐나 함수 변경을 막지는 않아요. Amazon Kinesis Data Streams와 Amazon DynamoDB Streams의 경우 배치당 더 긴 처리 시간을 고려해 최대 배치 창과 병렬화 계수를 구성하고, 전체 배치 대신 실패한 레코드만 재시도되도록 부분 배치 실패 보고를 활성화하세요.

확장 구성

적절한 대상 리소스 사용률을 설정하세요. 기본적으로 Lambda는 스로틀 없이 5분 내에 트래픽이 두 배로 늘어날 수 있는 충분한 헤드룸을 유지해요. 워크로드 특성에 따라 이를 조정해요:

  • 매우 안정적인 워크로드나 스로틀에 민감하지 않은 애플리케이션의 경우 목표를 높게 설정해서 더 높은 사용률과 더 낮은 비용을 달성해요
  • 잠재적 트래픽 급증이 있는 워크로드의 경우 추가 헤드룸을 유지하기 위해 리소스 목표를 낮게 설정해요

트래픽 성장을 계획하세요. 5분 내에 트래픽이 두 배 이상 증가하면 Lambda가 인스턴스와 실행 환경을 확장하는 동안 스로틀이 발생할 수 있어요. 빠른 확장 기간 동안 잠재적 스로틀을 처리하도록 애플리케이션을 설계하세요.

보안

PassCapacityProvider 권한에 최소 권한을 적용하세요. lambda:PassCapacityProvider 권한을 필요한 용량 공급자에 대해서만 부여해요. 리소스 수준 권한을 사용해서 사용자가 함수에 할당할 수 있는 용량 공급자를 제한하세요.

용량 공급자 사용을 모니터링하세요. AWS CloudTrail을 사용해서 용량 공급자 할당과 접근 패턴을 모니터링해요. 이는 무단 접근 시도를 식별하고 보안 정책 준수를 보장하는 데 도움이 돼요.

신뢰할 수 없는 워크로드를 분리하세요. 신뢰할 수 없는 워크로드 사이의 보안 격리를 위해 컨테이너에 의존하지 마세요. 상호 신뢰할 수 없는 워크로드를 분리하려면 다른 용량 공급자를 사용하세요.

비용 최적화

EC2 가격 옵션을 사용하세요. EC2 Savings Plans와 Reserved Instances를 활용해서 비용을 줄이세요. 이러한 가격 옵션은 기본 EC2 컴퓨팅에 적용되며(15% 관리 수수료는 할인되지 않음)요.

정상 상태 워크로드에 최적화하세요. Lambda Managed Instances는 예측 가능한 대량 트래픽을 가진 정상 상태 함수에 가장 적합해요. 버스트 트래픽 패턴의 경우 Lambda(기본값)가 더 비용 효율적일 수 있어요.

리소스 사용률을 모니터링하세요. CloudWatch 지표를 추적해서 CPU와 메모리 사용률을 이해하세요. 실제 사용 패턴에 따라 함수 메모리 할당과 인스턴스 유형 선택을 조정해서 비용을 최적화하세요.

모니터링 및 관측 가능성

용량 공급자 지표를 모니터링하세요. CPUUtilization, MemoryUtilization, vCPUAvailable, MemoryAvailable을 포함한 용량 공급자 수준 지표를 추적해서 워크로드에 충분한 리소스가 있는지 확인하세요.

실행 환경 지표를 모니터링하세요. ExecutionEnvironmentConcurrency와 ExecutionEnvironmentConcurrencyLimit을 포함한 실행 환경 수준 지표를 추적해서 확장 동작을 이해하고 잠재적 스로틀을 식별하세요.

CloudWatch 알람을 설정하세요. 주요 지표에 대한 CloudWatch 알람을 만들어 문제를 선제적으로 식별하세요:

  • 높은 CPU 또는 메모리 사용률
  • 낮은 가용 용량
  • 동시성 한도 접근

언어별 고려 사항

언어별 모범 사례를 따르세요. 각 프로그래밍 언어는 다중 동시성을 다르게 처리해요. 자세한 권장 사항은 언어별 가이드를 참고하세요:

  • Java: 스레드 안전 컬렉션, AtomicInteger, ThreadLocal을 요청별 상태에 사용해요
  • Node.js: 모든 요청별 상태에 InvokeStore를 사용하고 전역 변수를 피해요
  • Python: 요청 ID와 함께 /tmp에 고유한 파일 이름을 사용하고 프로세스 기반 메모리 격리를 고려해요
  • Rust: run 대신 concurrency-tokio 기능을 활성화한 run_concurrent를 사용해요. 핸들러는 Clone + Send여야 해요.

스레드 안전과 동시성 문제를 테스트하세요. 프로덕션에 배포하기 전에 동시 부하에서 함수의 스레드 안전 문제, 경합 조건, 적절한 상태 격리를 철저히 테스트하세요.

다음 단계

더 알아보기 (Learn more)

Lambda Managed Instances에 대한 자세한 내용은 Lambda Managed Instances를 참고하세요.