# 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 런타임](lambda-managed-instances-java-runtime.md) 설명서를 참조하세요.
### 상태 격리 문제(Node.js 런타임)
**문제:** Node.js 함수가 다른 요청의 데이터를 반환하거나 데이터 손상이 발생합니다.
**원인:** 전역 변수는 동일한 작업자 스레드에서의 동시 간접 호출 간에 공유됩니다. 비동기 작업에서 제어가 가능하면 다른 간접 호출에서 공유 상태를 수정할 수 있습니다.
**해결 방법:**
+ 모든 요청별 상태에 `@aws/lambda-invoke-store` 설치 및 사용
+ 전역 변수를 `InvokeStore.set()` 및 `InvokeStore.get()`으로 바꾸기
+ 요청 ID와 함께 `/tmp`에서 고유한 파일 이름 사용
+ 환경 변수 대신 `InvokeStore.getXRayTraceId()`를 사용하여 트레이스 ID 액세스
자세한 지침은 [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) 설명서를 참조하세요.
### 파일 충돌(Python 런타임)
**문제:** Python 함수가 `/tmp`의 파일에서 잘못된 데이터를 읽습니다.
**원인:** 여러 프로세스에서 `/tmp` 디렉터리를 공유합니다. 동일한 파일에 대한 동시 쓰기는 데이터를 손상시킬 수 있습니다.
**해결 방법:**
+ 요청 ID와 함께 고유한 파일 이름 사용: `/tmp/request_{context.request_id}.txt`
+ 공유 파일에 대해 `fcntl.flock()`으로 파일 잠금 사용
+ 사용 후 `os.remove()`를 사용하여 임시 파일 정리
자세한 지침은 [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) 설명서를 참조하세요.
## 성능 문제
### 높은 메모리 사용률
**문제:** 함수의 메모리 사용률이 높거나 메모리 부족 오류가 발생합니다.
**원인:** Python의 각 동시 요청이 자체 메모리 공간이 있는 별도의 프로세스에서 실행됩니다. 총 메모리 사용량은 프로세스당 메모리와 동시 프로세스를 곱한 값과 같습니다.
**해결 방법:**
+ CloudWatch에서 `MemoryUtilization` 지표 모니터링
+ 메모리 사용량이 함수의 메모리 제한에 가까워지면 `MaxConcurrency` 설정 감소
+ 더 높은 동시성을 지원하도록 함수 메모리 할당 증가
+ 초기화 도중 대신 온디맨드 방식으로 데이터를 로드하여 메모리 사용량 최적화
### 일관적이지 않은 성능
**문제:** 함수 성능이 간접 호출마다 크게 다릅니다.
**원인:** Lambda에서 가용성에 따라 다른 인스턴스 유형을 선택하거나 함수가 리소스 가용성이 다양한 인스턴스에서 실행 중일 수 있습니다.
**해결 방법:**
+ **허용되는 인스턴스 유형 지정:** 특정 성능 요구 사항이 있는 경우 Lambda가 선택할 수 있는 인스턴스 유형을 제한하도록 용량 공급자에서 허용되는 인스턴스 유형을 구성합니다.
+ **인스턴스 수준 지표 모니터링:** 용량 공급자 수준에서 `CPUUtilization` 및 `MemoryUtilization` 지표를 추적하여 리소스 제약을 식별합니다.
+ **용량 지표 검토:** `vCPUAvailable` 및 `MemoryAvailable`을 확인하여 인스턴스에서 충분한 리소스를 사용할 수 있는지 확인합니다.
## 용량 공급자 문제
### 함수 버전이 ACTIVE 상태가 되지 않음
**문제:** 게시 후에도 함수 버전이 보류 상태로 유지됩니다.
**원인:** Lambda가 관리형 인스턴스를 시작하고 실행 환경을 시작합니다. 이 프로세스는 특히 새 용량 공급자의 첫 번째 함수 버전에서는 시간이 걸립니다.
**해결 방법:**
Lambda에서 초기화 프로세스가 완료될 때까지 기다립니다. Lambda는 기본적으로 AZ 복원력을 위해 인스턴스 3개를 시작하고 실행 환경 3개를 시작한 다음 함수 버전을 ACTIVE로 표시합니다. 일반적으로 몇 분 정도 걸립니다.
### 용량 공급자 삭제 불가
**문제:** 용량 공급자를 삭제하려고 할 때 오류가 발생합니다.
**원인:** 함수 버전이 연결된 용량 공급자는 삭제할 수 없습니다.
**해결 방법:**
1. `ListFunctionVersionsByCapacityProvider` API에서 용량 공급자를 사용하여 모든 함수 버전을 식별합니다.
1. 해당 함수 버전을 삭제 또는 업데이트하여 용량 공급자 연결을 제거합니다.
1. 용량 공급자 삭제를 다시 시도합니다.
### 함수 게시 중 발생하는 일반적인 오류 메시지
**문제:** 함수를 게시할 때 "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/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 탐색 창에서 **엔드포인트**를 선택합니다.
1. **엔드포인트 생성**을 선택합니다.
1. **서비스 범주(Service category)**에서 **AWS 서비스**를 선택합니다.
1. **서비스 이름**에서 `com.amazonaws.region.logs`(`region`을 해당 AWS 리전으로 교체)를 선택합니다.
1. **VPC**에서 용량 공급자에서 사용되는 VPC를 선택합니다.
1. **서브넷**에서 엔드포인트 네트워크 인터페이스를 생성하려는 서브넷을 선택합니다. 고가용성을 위해 여러 가용 영역의 서브넷을 선택합니다.
1. **보안 그룹**에서 함수의 보안 그룹 중 인바운드 HTTPS 트래픽(포트 443)을 허용하는 보안 그룹을 선택합니다.
1. 엔드포인트에 대해 **프라이빗 DNS**를 활성화합니다.
1. **엔드포인트 생성**을 선택합니다.
**옵션 2: 인터넷 게이트웨이를 사용하는 퍼블릭 서브넷**
용량 공급자가 퍼블릭 서브넷을 사용하는 경우 다음 사항을 확인합니다.
1. 인터넷 게이트웨이가 VPC에 연결됨
1. 라우팅 테이블이 `0.0.0.0/0` 트래픽을 인터넷 게이트웨이로 라우팅
1. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용
**옵션 3: NAT 게이트웨이를 사용하는 프라이빗 서브넷**
용량 공급자가 프라이빗 서브넷을 사용하는 경우 다음 사항을 확인합니다.
1. 퍼블릭 서브넷에 NAT 게이트웨이 존재
1. 프라이빗 서브넷 라우팅 테이블이 `0.0.0.0/0` 트래픽을 NAT 게이트웨이로 라우팅
1. 퍼블릭 서브넷 라우팅 테이블이 `0.0.0.0/0` 트래픽을 인터넷 게이트웨이로 라우팅
1. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용
VPC 연결 옵션에 대한 자세한 지침은 [Lambda 관리형 인스턴스의 VPC 연결](lambda-managed-instances-networking.md)을 참조하세요.
### 동시 요청과 로그의 상호 연관에 대한 어려움
**문제:** 서로 다른 요청의 로그가 인터리브되어 개별 요청을 추적하기 어렵습니다.
**원인:** 여러 동시 시스템에서 로그 인터리브는 자연스러운 동작입니다.
**해결 방법:**
+ **JSON 형식의 구조화된 로깅 사용:** 모든 로그 문에 요청 ID 포함
+ **Java:** `ThreadContext`와 함께 Log4j를 사용하여 요청 ID 자동 포함
+ **Node.js:** JSON 형식과 함께 `console.log()`를 사용하고 `InvokeStore.getRequestId()` 포함
+ **Python:** 표준 로깅 모듈을 JSON 형식과 함께 사용하고 `context.request_id` 포함
자세한 지침은 런타임별 설명서 페이지를 참조하세요.
## 추가 도움말 받기
이러한 해결 방법을 시도한 후에도 문제가 계속 발생하는 경우:
1. **CloudWatch 지표 검토:** 용량 공급자 및 실행 환경 지표를 확인하여 리소스 제약 조건 또는 규모 조정 문제를 식별합니다.
1. **AWS CloudTrail 로그 확인:** CloudTrail 로그에서 API 호출 및 오류에 대한 자세한 정보를 검토합니다.
1. **AWS Support에 문의:** 문제를 해결할 수 없는 경우 AWS Support에 용량 공급자 구성, 함수 구성 및 발생하는 특정 오류 메시지와 관련된 세부 정보를 문의합니다.
## 다음 단계
+ [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기
+ [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기
+ [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토
+ [CloudWatch 지표](lambda-managed-instances-monitoring.md)를 사용하여 Lambda 관리형 인스턴스 모니터링
+ [Lambda 관리형 인스턴스 모범 사례](lambda-managed-instances-best-practices.md) 검토