View a markdown version of this page

Lambda 관리형 인스턴스 문제 해결 - AWS Lambda
스로틀링 및 규모 조정 문제동시성 문제성능 문제용량 공급자 문제모니터링 및 관찰성 문제추가 도움말 받기다음 단계

Lambda 관리형 인스턴스 문제 해결

스로틀링 및 규모 조정 문제

스케일 업 도중 높은 오류율

문제: 트래픽이 빠르게 증가할 때 스로틀링 오류(HTTP 429)가 발생합니다.

원인: Lambda 관리형 인스턴스는 CPU 리소스 사용률 및 다중 동시성 포화에 따라 비동기식으로 규모가 조정됩니다. 5분 이내에 트래픽이 2배를 초과하는 경우 Lambda가 수요에 맞춰 인스턴스 및 실행 환경을 스케일 업함에 따라 스로틀링이 발생할 수 있습니다.

해결 방법:

  • 목표 리소스 사용률 조정: 워크로드에 예측 가능한 트래픽 패턴이 있는 경우 목표 리소스 사용률을 낮게 설정하여 트래픽 급증에 대한 추가 여유 공간을 유지합니다.

  • 용량 사전 워밍: 계획된 트래픽 증가의 경우 속도에 맞춰 조정이 이루어지도록 더 긴 기간 동안 트래픽을 점진적으로 증가시킵니다.

  • 조정 지표 모니터링: 스로틀링 오류 지표를 추적하여 스로틀링 및 용량 조정 문제의 원인을 파악합니다.

  • 함수 구성 검토: 함수 메모리 및 vCPU 설정이 다중 동시 실행을 지원해야 합니다. 필요한 경우 함수 메모리 또는 vCPU 할당을 늘립니다.

스케일 다운 속도 저하

문제: 트래픽이 감소한 후 인스턴스를 축소하는 데 시간이 오래 걸립니다.

원인: Lambda 관리형 인스턴스는 가용성을 유지하고 성능에 영향을 미칠 수 있는 급격한 용량 변경을 방지하기 위해 점진적으로 스케일 다운됩니다.

해결 방법:

이는 예상된 동작입니다. Lambda는 안정성 보장을 위해 인스턴스를 보수적으로 스케일 다운합니다. CloudWatch 지표를 모니터링하여 실행 중인 인스턴스 수를 추적합니다.

동시성 문제

동시성이 낮은 실행 환경에서 스로틀링 발생

문제: 사용 가능한 용량이 있더라도 함수에 스로틀링이 발생합니다.

원인: 최대 동시성이 매우 낮은 실행 환경은 효과적인 조정이 어려울 수 있습니다. Lambda 관리형 인스턴스는 다중 동시 애플리케이션용으로 설계되었습니다.

해결 방법:

  • 최대 동시성 증가: 함수 간접 호출에서 CPU를 거의 사용하지 않는 경우 최대 동시성 설정을 vCPU당 최대 64로 늘립니다.

  • 함수 코드 최적화: 함수 코드를 검토하여 간접 호출당 CPU 소비량을 줄이고 동시성을 높입니다.

  • 함수 메모리 및 vCPU 조정: 함수에 여러 개의 동시 간접 호출을 처리하기에 충분한 리소스가 있어야 합니다.

스레드 안전 문제(Java 런타임)

문제: Java 함수가 잘못된 결과를 생성하거나 로드 시 경합 상태가 발생합니다.

원인: 여러 스레드가 핸들러 메서드를 동시에 실행하며 공유 상태가 스레드 안전이 아닙니다.

해결 방법:

  • 기본 유형 대신 카운터에 AtomicInteger 또는 AtomicLong 사용

  • HashMap를 ConcurrentHashMap으로 바꿉니다.

  • Collections.synchronizedList()를 사용하여 ArrayList 래핑

  • 요청별 상태에 ThreadLocal 사용

  • 환경 변수가 아닌 Lambda 컨텍스트 객체에서 트레이스 ID에 액세스

자세한 지침은 Lambda 관리형 인스턴스용 Java 런타임 설명서를 참조하세요.

상태 격리 문제(Node.js 런타임)

문제: Node.js 함수가 다른 요청의 데이터를 반환하거나 데이터 손상이 발생합니다.

원인: 전역 변수는 동일한 작업자 스레드에서의 동시 간접 호출 간에 공유됩니다. 비동기 작업에서 제어가 가능하면 다른 간접 호출에서 공유 상태를 수정할 수 있습니다.

해결 방법:

  • 모든 요청별 상태에 @aws/lambda-invoke-store 설치 및 사용

  • 전역 변수를 InvokeStore.set() 및 InvokeStore.get()으로 바꾸기

  • 요청 ID와 함께 /tmp에서 고유한 파일 이름 사용

  • 환경 변수 대신 InvokeStore.getXRayTraceId()를 사용하여 트레이스 ID 액세스

자세한 지침은 Lambda 관리형 인스턴스용 Node.js 런타임 설명서를 참조하세요.

파일 충돌(Python 런타임)

문제: Python 함수가 /tmp의 파일에서 잘못된 데이터를 읽습니다.

원인: 여러 프로세스에서 /tmp 디렉터리를 공유합니다. 동일한 파일에 대한 동시 쓰기는 데이터를 손상시킬 수 있습니다.

해결 방법:

  • 요청 ID와 함께 고유한 파일 이름 사용: /tmp/request_{context.request_id}.txt

  • 공유 파일에 대해 fcntl.flock()으로 파일 잠금 사용

  • 사용 후 os.remove()를 사용하여 임시 파일 정리

자세한 지침은 Lambda 관리형 인스턴스용 Python 런타임 설명서를 참조하세요.

성능 문제

높은 메모리 사용률

문제: 함수의 메모리 사용률이 높거나 메모리 부족 오류가 발생합니다.

원인: Python의 각 동시 요청이 자체 메모리 공간이 있는 별도의 프로세스에서 실행됩니다. 총 메모리 사용량은 프로세스당 메모리와 동시 프로세스를 곱한 값과 같습니다.

해결 방법:

  • CloudWatch에서 MemoryUtilization 지표 모니터링

  • 메모리 사용량이 함수의 메모리 제한에 가까워지면 MaxConcurrency 설정 감소

  • 더 높은 동시성을 지원하도록 함수 메모리 할당 증가

  • 초기화 도중 대신 온디맨드 방식으로 데이터를 로드하여 메모리 사용량 최적화

일관적이지 않은 성능

문제: 함수 성능이 간접 호출마다 크게 다릅니다.

원인: Lambda에서 가용성에 따라 다른 인스턴스 유형을 선택하거나 함수가 리소스 가용성이 다양한 인스턴스에서 실행 중일 수 있습니다.

해결 방법:

  • 허용되는 인스턴스 유형 지정: 특정 성능 요구 사항이 있는 경우 Lambda가 선택할 수 있는 인스턴스 유형을 제한하도록 용량 공급자에서 허용되는 인스턴스 유형을 구성합니다.

  • 인스턴스 수준 지표 모니터링: 용량 공급자 수준에서 CPUUtilization 및 MemoryUtilization 지표를 추적하여 리소스 제약을 식별합니다.

  • 용량 지표 검토: vCPUAvailable 및 MemoryAvailable을 확인하여 인스턴스에서 충분한 리소스를 사용할 수 있는지 확인합니다.

용량 공급자 문제

함수 버전이 ACTIVE 상태가 되지 않음

문제: 게시 후에도 함수 버전이 보류 상태로 유지됩니다.

원인: Lambda가 관리형 인스턴스를 시작하고 실행 환경을 시작합니다. 이 프로세스는 특히 새 용량 공급자의 첫 번째 함수 버전에서는 시간이 걸립니다.

해결 방법:

Lambda에서 초기화 프로세스가 완료될 때까지 기다립니다. Lambda는 기본적으로 AZ 복원력을 위해 인스턴스 3개를 시작하고 실행 환경 3개를 시작한 다음 함수 버전을 ACTIVE로 표시합니다. 일반적으로 몇 분 정도 걸립니다.

용량 공급자 삭제 불가

문제: 용량 공급자를 삭제하려고 할 때 오류가 발생합니다.

원인: 함수 버전이 연결된 용량 공급자는 삭제할 수 없습니다.

해결 방법:

  1. ListFunctionVersionsByCapacityProvider API에서 용량 공급자를 사용하여 모든 함수 버전을 식별합니다.

  2. 해당 함수 버전을 삭제 또는 업데이트하여 용량 공급자 연결을 제거합니다.

  3. 용량 공급자 삭제를 다시 시도합니다.

함수 게시 중 발생하는 일반적인 오류 메시지

문제: 함수를 게시할 때 "Internal error occurred during publishing" 등의 일반 오류 메시지가 표시됩니다.

해결 방법:

  • IAM 권한 확인: 사용하려는 용량 공급자에 대해 lambda:PassCapacityProvider 권한이 있어야 합니다.

  • 용량 공급자 구성 확인: GetCapacityProvider API를 사용하여 용량 공급자가 ACTIVE 상태인지 확인합니다.

  • VPC 구성 검토: 용량 공급자에 지정된 서브넷 및 보안 그룹이 올바르게 구성되고 액세스 가능해야 합니다.

  • AWS CloudTrail 로그 확인: CloudTrail 로그에서 실패한 작업에 대한 자세한 오류 정보를 검토합니다.

모니터링 및 관찰성 문제

CloudWatch 지표 누락

문제: CloudWatch에서 용량 공급자 또는 함수에 대해 필요한 지표가 표시되지 않습니다.

원인: 지표가 5분 간격으로 게시됩니다. 새 용량 공급자 또는 함수에서 지표가 즉시 제공되지 않을 수 있습니다.

해결 방법:

함수 버전을 게시한 후 CloudWatch에 지표가 표시되기까지 최소 5~10분 정도 기다립니다. 올바른 네임스페이스(AWS/Lambda)와 차원(CapacityProviderName, FunctionName 또는 InstanceType)을 보고 있는지 확인합니다.

CloudWatch 로그 검색 불가

문제: 함수가 성공적으로 실행되지만 CloudWatch Logs에서 로그를 찾을 수 없습니다.

원인: Lambda 관리형 인스턴스는 VPC에서 실행되며 네트워크에 연결되어야 CloudWatch Logs로 로그를 전송할 수 있습니다. 적절한 VPC 연결 구성이 없으면 함수가 CloudWatch Logs 서비스 엔드포인트에 연결할 수 없습니다.

해결 방법:

함수가 CloudWatch Logs로 로그를 전송할 수 있도록 VPC 연결을 구성합니다. 여기에는 다음과 같은 3가지 옵션이 있습니다.

옵션 1: CloudWatch Logs용 VPC 엔드포인트(프로덕션에 권장)

  1. console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 엔드포인트를 선택합니다.

  3. 엔드포인트 생성을 선택합니다.

  4. 서비스 범주(Service category)에서 AWS 서비스를 선택합니다.

  5. 서비스 이름에서 com.amazonaws.region.logs(region을 해당 AWS 리전으로 교체)를 선택합니다.

  6. VPC에서 용량 공급자에서 사용되는 VPC를 선택합니다.

  7. 서브넷에서 엔드포인트 네트워크 인터페이스를 생성하려는 서브넷을 선택합니다. 고가용성을 위해 여러 가용 영역의 서브넷을 선택합니다.

  8. 보안 그룹에서 함수의 보안 그룹 중 인바운드 HTTPS 트래픽(포트 443)을 허용하는 보안 그룹을 선택합니다.

  9. 엔드포인트에 대해 프라이빗 DNS를 활성화합니다.

  10. 엔드포인트 생성을 선택합니다.

옵션 2: 인터넷 게이트웨이를 사용하는 퍼블릭 서브넷

용량 공급자가 퍼블릭 서브넷을 사용하는 경우 다음 사항을 확인합니다.

  1. 인터넷 게이트웨이가 VPC에 연결됨

  2. 라우팅 테이블이 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 라우팅

  3. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용

옵션 3: NAT 게이트웨이를 사용하는 프라이빗 서브넷

용량 공급자가 프라이빗 서브넷을 사용하는 경우 다음 사항을 확인합니다.

  1. 퍼블릭 서브넷에 NAT 게이트웨이 존재

  2. 프라이빗 서브넷 라우팅 테이블이 0.0.0.0/0 트래픽을 NAT 게이트웨이로 라우팅

  3. 퍼블릭 서브넷 라우팅 테이블이 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 라우팅

  4. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용

VPC 연결 옵션에 대한 자세한 지침은 Lambda 관리형 인스턴스의 VPC 연결을 참조하세요.

동시 요청과 로그의 상호 연관에 대한 어려움

문제: 서로 다른 요청의 로그가 인터리브되어 개별 요청을 추적하기 어렵습니다.

원인: 여러 동시 시스템에서 로그 인터리브는 자연스러운 동작입니다.

해결 방법:

  • JSON 형식의 구조화된 로깅 사용: 모든 로그 문에 요청 ID 포함

  • Java: ThreadContext와 함께 Log4j를 사용하여 요청 ID 자동 포함

  • Node.js: JSON 형식과 함께 console.log()를 사용하고 InvokeStore.getRequestId() 포함

  • Python: 표준 로깅 모듈을 JSON 형식과 함께 사용하고 context.request_id 포함

자세한 지침은 런타임별 설명서 페이지를 참조하세요.

추가 도움말 받기

이러한 해결 방법을 시도한 후에도 문제가 계속 발생하는 경우:

  1. CloudWatch 지표 검토: 용량 공급자 및 실행 환경 지표를 확인하여 리소스 제약 조건 또는 규모 조정 문제를 식별합니다.

  2. AWS CloudTrail 로그 확인: CloudTrail 로그에서 API 호출 및 오류에 대한 자세한 정보를 검토합니다.

  3. AWS Support에 문의: 문제를 해결할 수 없는 경우 AWS Support에 용량 공급자 구성, 함수 구성 및 발생하는 특정 오류 메시지와 관련된 세부 정보를 문의합니다.

다음 단계