Lambda Managed Instances 문제 해결

Lambda Managed Instances 문제 해결 (Troubleshooting Lambda Managed Instances)

Lambda Managed Instances를 사용할 때 발생할 수 있는 문제와 해결 방법을 설명합니다.

출처: AWS Lambda 개발자 안내서

본문

제한 및 확장 문제

간헐적인 제한

문제: 정상 운영 중에 제한 오류(HTTP 429)가 발생합니다.

원인: Lambda Managed Instances는 이미 진행 중인 호출을 보호하기 위해 새 호출을 거부할 수 있습니다. 실행 환경의 사용률이 지속적으로 높으면 새 호출이 제한될 수 있습니다.

해결 방법:

• 확장 메트릭 모니터링 — Throttle Reasons 그래프를 검토해 제한과 용량 확장 문제의 원인을 이해합니다. 다음 예제에서는 높은 CPU가 제한을 일으키고 있습니다.
• 함수 구성 검토 — 함수 메모리와 vCPU 설정이 다중 동시 실행을 지원하는지 확인합니다. 필요하면 함수 메모리나 vCPU 할당을 늘리세요. ExecutionEnvironmentVCPUUtilization이 높으면 함수당 vCPU를 더 추가해 보세요.

aws lambda update-function \
  --function-name my-function \
  ...
  --memory-size 8192

ExecutionEnvironmentMemoryUtilization이 높으면 vCPU당 메모리를 더 추가해 보세요:

aws lambda update-function \
  --function-name my-function \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0
    }
  }'

확장 중 제한

문제: 트래픽이 급격히 증가할 때 제한 오류(HTTP 429)가 발생합니다.

원인: Lambda Managed Instances는 CPU 리소스 사용률과 다중 동시성 포화를 기반으로 비동기적으로 확장합니다. 트래픽이 5분 이내에 두 배 이상 늘어나면 Lambda가 수요를 충족하기 위해 인스턴스와 실행 환경을 확장하면서 제한이 발생할 수 있습니다.

해결 방법:

• 대상 리소스 사용률 조정 — 트래픽 패턴이 예측 가능한 워크로드라면 트래픽 급증에 대비한 여유(headroom)를 유지하도록 더 낮은 대상 리소스 사용률을 설정하세요.

aws lambda create-capacity-provider \
  --name my-capacity-provider \
  ...
  --capacity-provider-scaling-config '{
    "ScalingMode": "Manual",
    "ScalingPolicies": [
      {
        "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization",
        "TargetValue": 30.0
      }
    ]
  }'

• 용량 사전 워밍 — 계획된 트래픽 증가를 위해 PutFunctionScalingConfig API를 사용해 추가 용량을 사전에 워밍하세요.

aws lambda put-function-scaling-config \
  --function-name my-function \
  --qualifier 1 \
  --function-scaling-config '{
    "MinExecutionEnvironments": 100
  }'

느린 축소

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

원인: Lambda Managed Instances는 가용성을 유지하고 성능에 영향을 줄 수 있는 급격한 용량 변화를 피하기 위해 점진적으로 축소합니다.

해결 방법: 이는 예상된 동작입니다. Lambda는 안정성을 보장하기 위해 인스턴스를 보수적으로 축소합니다. CloudWatch 메트릭을 모니터링해 실행 중인 인스턴스 수를 추적하세요.

동시성 문제

낮은 동시성의 실행 환경이 제한을 경험

문제: 사용 가능한 용량이 있는데도 함수가 제한을 경험합니다.

원인: 최대 동시성이 매우 낮은 실행 환경은 효과적으로 확장하기 어려울 수 있습니다. Lambda Managed Instances는 다중 동시 애플리케이션용으로 설계되었습니다.

해결 방법:

• 최대 동시성 증가 — 함수 호출이 CPU를 거의 사용하지 않으면 최대 동시성 설정을 vCPU당 최대 64까지 늘리세요.

aws lambda update-function \
  --function-name ordering-api-backend \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "PerExecutionEnvironmentMaxConcurrency": 32
    }
  }'

• 함수 코드 최적화 — 호출당 CPU 소비를 줄여 더 높은 동시성을 가능하게 하도록 함수 코드를 검토하세요.
• 함수 메모리 및 vCPU 조정 — 함수가 여러 동시 호출을 처리할 수 있는 충분한 리소스가 있는지 확인하세요.

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

문제: Java 함수가 부하 시 잘못된 결과를 생성하거나 경쟁 조건(race condition)을 경험합니다.

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

해결 방법:

• 카운터에 기본 유형 대신 AtomicInteger 또는 AtomicLong 사용
• HashMap을 ConcurrentHashMap으로 교체
• Collections.synchronizedList()로 ArrayList 래핑
• 요청별 상태에 ThreadLocal 사용
• 환경 변수가 아닌 Lambda Context 객체에서 추적 ID 액세스

자세한 지침은 Lambda Managed Instances용 Java 런타임 문서를 참조하세요.

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

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

원인: 전역 변수는 같은 워커 스레드의 동시 호출 간에 공유됩니다. 비동기 작업이 제어를 양보하면 다른 호출이 공유 상태를 수정할 수 있습니다.

해결 방법:

• 모든 요청별 상태에 @aws/lambda-invoke-store 설치 및 사용
• 전역 변수를 InvokeStore.set() 및 InvokeStore.get()으로 교체
• 요청 ID가 있는 고유한 파일 이름을 /tmp에서 사용
• 환경 변수 대신 InvokeStore.getXRayTraceId()로 추적 ID 액세스

자세한 지침은 Lambda Managed Instances용 Node.js 런타임 문서를 참조하세요.

파일 충돌 (Python 런타임)

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

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

해결 방법:

• 요청 ID가 있는 고유한 파일 이름 사용: /tmp/request_{context.request_id}.txt
• 공유 파일에 fcntl.flock()으로 파일 잠금 사용
• 사용 후 os.remove()로 임시 파일 정리

자세한 지침은 Lambda Managed Instances용 Python 런타임 문서를 참조하세요.

성능 문제

높은 메모리 사용률

문제: 함수가 높은 메모리 사용률 또는 메모리 부족 오류를 경험합니다.

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

해결 방법:

• CloudWatch에서 MemoryUtilization 메트릭 모니터링
• 메모리 사용량이 함수의 메모리 한도에 가까워지면 MaxConcurrency 설정 줄이기
• 더 높은 동시성을 지원하도록 함수 메모리 할당 늘리기
• 초기화 중이 아닌 필요할 때 데이터를 로드해 메모리 사용량 최적화

비일관적인 성능

문제: 호출 간에 함수 성능이 크게 달라집니다.

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

해결 방법:

• 허용된 인스턴스 유형 지정 — 특정 성능 요구 사항이 있으면 용량 제공자에서 허용된 인스턴스 유형을 구성해 Lambda가 선택할 수 있는 인스턴스 유형을 제한하세요.
• 인스턴스 수준 메트릭 모니터링 — 용량 제공자 수준에서 CPUUtilization 및 MemoryUtilization을 추적해 리소스 제약을 식별하세요.
• 용량 메트릭 검토 — vCPUAvailable 및 MemoryAvailable을 확인해 인스턴스에 충분한 리소스가 있는지 확인하세요.

용량 제공자 문제

함수 버전이 ACTIVE가 되지 않음

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

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

해결 방법: Lambda가 초기화 프로세스를 완료할 때까지 기다리세요. Lambda는 AZ 복원력을 위해 기본적으로 3개의 인스턴스를 시작하고 함수 버전을 ACTIVE로 표시하기 전에 3개의 실행 환경을 시작합니다. 이는 일반적으로 몇 분이 걸립니다.

용량 제공자를 삭제할 수 없음

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

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

해결 방법:

1. ListFunctionVersionsByCapacityProvider API로 용량 제공자를 사용하는 모든 함수 버전을 식별하세요.
2. 해당 함수 버전을 삭제하거나 업데이트해 용량 제공자 연결을 제거하세요.
3. 용량 제공자 삭제를 다시 시도하세요.

함수 게시 중 일반 오류 메시지

문제: 함수 게시 시 "Internal error occurred during publishing" 같은 일반 오류 메시지가 발생합니다.

해결 방법:

• IAM 권한 확인 — 사용하려는 용량 제공자에 대해 lambda:PassCapacityProvider 권한이 있는지 확인하세요.
• 용량 제공자 구성 검증 — GetCapacityProvider API로 용량 제공자가 ACTIVE 상태인지 확인하세요.
• VPC 구성 검토 — 용량 제공자에 지정된 서브넷과 보안 그룹이 올바르게 구성되고 액세스 가능한지 확인하세요.
• AWS CloudTrail 로그 확인 — 실패한 작업에 대한 상세 오류 정보를 CloudTrail 로그에서 검토하세요.

모니터링 및 관찰 가능성 문제

CloudWatch 메트릭 누락

문제: 용량 제공자 또는 함수에 대해 예상한 메트릭이 CloudWatch에 표시되지 않습니다.

원인: 메트릭은 1분 간격으로 게시됩니다. 새 용량 제공자나 함수는 즉시 메트릭을 사용할 수 없을 수 있습니다.

해결 방법: 함수 버전 게시 후 메트릭이 CloudWatch에 나타나기를 기대하기 전에 최소 5~10분 기다리세요. 올바른 네임스페이스(AWS/Lambda)와 차원(CapacityProviderName, FunctionName, InstanceType)을 보고 있는지 확인하세요.

CloudWatch 로그를 찾을 수 없음

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

원인: Lambda Managed Instances는 사용자 VPC에서 실행되며 CloudWatch Logs로 로그를 보내려면 네트워크 연결이 필요합니다. 올바른 VPC 연결 구성이 없으면 함수가 CloudWatch Logs 서비스 엔드포인트에 도달할 수 없습니다.

해결 방법: 함수가 CloudWatch Logs로 로그를 보낼 수 있도록 VPC 연결을 구성하세요. 세 가지 옵션이 있습니다:

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

1. console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
2. 탐색 창에서 Endpoints(엔드포인트) 를 선택합니다.
3. Create endpoint(엔드포인트 생성) 을 선택합니다.
4. Service category(서비스 범주) 에서 AWS services 를 선택합니다.
5. Service name 에서 com.amazonaws.region.logs를 선택합니다(region을 AWS 리전으로 교체).
6. VPC 에서 용량 제공자가 사용하는 VPC를 선택합니다.
7. Subnets(서브넷) 에서 엔드포인트 네트워크 인터페이스를 만들 서브넷을 선택합니다. 고가용성을 위해 여러 가용 영역의 서브넷을 선택하세요.
8. Security groups(보안 그룹) 에서 함수의 보안 그룹으로부터 인바운드 HTTPS 트래픽(포트 443)을 허용하는 보안 그룹을 선택합니다.
9. 엔드포인트에 대해 Private DNS 를 활성화합니다.
10. Create endpoint 를 선택합니다.

옵션 2: 인터넷 게이트웨이가 있는 공용 서브넷

용량 제공자가 공용 서브넷을 사용하면 다음을 확인하세요:

• 인터넷 게이트웨이가 VPC에 연결되어 있음
• 라우트 테이블이 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 라우팅함
• 보안 그룹이 포트 443의 아웃바운드 HTTPS 트래픽을 허용함

옵션 3: NAT 게이트웨이가 있는 프라이빗 서브넷

용량 제공자가 프라이빗 서브넷을 사용하면 다음을 확인하세요:

• 공용 서브넷에 NAT 게이트웨이가 존재함
• 프라이빗 서브넷 라우트 테이블이 0.0.0.0/0 트래픽을 NAT 게이트웨이로 라우팅함
• 공용 서브넷 라우트 테이블이 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 라우팅함
• 보안 그룹이 포트 443의 아웃바운드 HTTPS 트래픽을 허용함

VPC 연결 옵션에 대한 자세한 지침은 Lambda Managed Instances용 VPC 연결을 참조하세요.

동시 요청의 로그 연관 어려움

문제: 서로 다른 요청의 로그가 섞여 개별 요청을 추적하기 어렵습니다.

원인: 로그 인터리빙은 다중 동시 시스템에서 예상되고 표준적인 동작입니다.

해결 방법:

• JSON 형식의 구조화된 로깅 사용: 모든 로그 문에 요청 ID 포함
• Java: 요청 ID를 자동으로 포함하도록 Log4j와 ThreadContext 사용
• Node.js: JSON 형식으로 console.log()를 사용하고 InvokeStore.getRequestId() 포함
• Python: JSON 형식의 표준 logging 모듈을 사용하고 context.request_id 포함

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

추가 도움말 얻기

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

• CloudWatch 메트릭 검토 — 용량 제공자 및 실행 환경 메트릭을 확인해 리소스 제약이나 확장 문제를 식별하세요.
• AWS CloudTrail 로그 확인 — API 호출과 오류에 대한 상세 정보를 CloudTrail 로그에서 검토하세요.
• AWS 지원 문의 — 문제를 해결할 수 없으면 용량 제공자 구성, 함수 구성, 발생하는 특정 오류 메시지에 대한 세부 정보와 함께 AWS Support에 문의하세요.

다음 단계

• Lambda Managed Instances용 용량 제공자에 대해 알아보기
• Lambda Managed Instances 확장 이해
• Java, Node.js, Python에 대한 런타임별 안내서 검토
• CloudWatch 메트릭으로 Lambda Managed Instances 모니터링
• Lambda Managed Instances 모범 사례 검토

더 알아보기 (Learn more)

• Lambda Managed Instances 개요
• 용량 제공자 구성
• Lambda Managed Instances VPC 연결