# Lambda의 이벤트 소스 매핑 문제 해결
<a name="troubleshooting-event-source-mapping"></a>

[이벤트 소스 매핑](invocation-eventsourcemapping.md)과 관련된 Lambda의 문제는 여러 서비스에서의 디버깅을 포함하므로 더 복잡할 수 있습니다. 또한 이벤트 소스 동작은 정확히 어떤 이벤트 소스가 사용되었는지에 따라 달라질 수 있습니다. 이 섹션에서는 이벤트 소스 매핑과 관련된 일반적인 문제를 나열하고, 이를 식별하고 해결하는 방법에 대한 지침을 제공합니다.

**참고**  
이 섹션에서는 Amazon SQS 이벤트 소스를 예시로 사용하지만, 이 원칙은 Lambda 함수에 대한 메시지를 대기열에 추가하는 다른 이벤트 소스 매핑에도 적용됩니다.

## 스로틀링 식별 및 관리
<a name="esm-throttling"></a>

Lambda에서 스로틀링은 함수 또는 계정의 동시성 한도에 도달하면 발생합니다. Amazon SQS 대기열에서 메시지를 읽는 Lambda 함수가 있는 다음 예제를 생각해 보겠습니다. 이 Lambda 함수는 30초 간접 호출을 시뮬레이션하며 배치 크기는 1입니다. 즉, 함수는 30초마다 1개의 메시지만 처리합니다.

```
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}
```

간접 호출 시간이 길어지면 메시지가 처리되는 속도보다 더 빠르게 대기열에 도착하기 시작합니다. 계정의 예약되지 않은 동시성이 100인 경우 Lambda는 최대 100개의 동시 실행으로 스케일 업된 다음 스로틀링이 발생합니다. 함수에 대해 CloudWatch 지표에서 이 패턴을 볼 수 있습니다.

![\[디버깅 운영 그림 10\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-10.png)


함수에 대한 CloudWatch 지표에는 오류가 표시되지 않지만 **동시 실행** 차트에는 최대 동시성인 100에 도달한 것으로 표시됩니다. 따라서 **스로틀링** 차트는 스로틀링이 발생한 것을 보여줍니다.

CloudWatch 경보를 사용하고 함수에 대한 스로틀링 지표가 0보다 클 때마다 경보를 설정하여 스로틀링을 감지할 수 있습니다. 스로틀링 문제를 파악한 후에는 몇 가지 해결 옵션이 있습니다.
+ 이 리전의 AWS Support에서 동시성 증가를 요청합니다.
+ 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다.
+ 함수의 배치 크기를 늘려 간접 호출할 때마다 더 많은 메시지가 처리되도록 합니다.

## 처리 함수에서의 오류
<a name="esm-processing-function"></a>

처리 함수에서 오류가 발생하면 Lambda는 메시지를 SQS 대기열로 반환합니다. Lambda는 함수의 규모 조정을 방지하여 대규모 오류를 방지합니다. CloudWatch의 다음 SQS 지표는 대기열 처리 관련 문제를 나타냅니다.

![\[디버깅 운영 그림 11\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-11.png)


특히 가장 오래된 메시지의 수명과 표시되는 메시지 수가 모두 늘어나는 반면, 삭제되는 메시지는 없습니다. 대기열은 계속 증가하지만 메시지는 처리되지 않습니다. Lambda 처리 함수에 대한 CloudWatch 지표에서도 문제가 있음을 나타냅니다.

![\[디버깅 운영 그림 12\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-12.png)


**오류 수** 지표는 0이 아니고 증가하지만 **동시 실행**은 줄어들고 스로틀링은 중지됩니다. 이는 Lambda가 오류로 인해 함수 스케일 업을 중지했음을 보여줍니다. 함수의 CloudWatch 로그는 오류 유형에 대한 세부 정보를 제공합니다.

오류를 유발하는 함수를 식별한 다음, 오류를 찾아 해결함으로써 이 문제를 해결할 수 있습니다. 오류를 수정하고 새 함수 코드를 배포한 후에는 CloudWatch 지표에 처리 복구가 표시되어야 합니다.

![\[디버깅 운영 그림 13\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-13.png)


여기서 **오류 수** 지표는 0으로 감소하고 **성공률** 지표는 100%로 돌아갑니다. Lambda 서비스는 **동시 실행** 그래프에 표시된 것처럼 함수 스케일 업을 다시 시작합니다.

## 역압 식별 및 처리
<a name="esm-backpressure"></a>

이벤트 생산자가 Lambda 함수에서 처리할 수 있는 것보다 빠른 속도로 SQS 대기열에 대한 메시지를 지속적으로 생성하는 경우 역압이 발생합니다. 이 경우 SQS 모니터링에는 표시되는 대략적인 메시지 수와 함께 가장 오래된 메시지의 수명이 선형적으로 증가하는 것을 보여주어야 합니다. CloudWatch 경보를 사용하여 대기열의 역압을 감지할 수 있습니다.

역압을 해결하는 단계는 워크로드에 따라 달라집니다. Lambda 함수로 처리 능력 및 처리량을 높이는 것이 주요 목표인 경우 다음과 같은 몇 가지 옵션이 있습니다.
+ AWS Support에서 이 특정 리전의 동시성 증가를 요청합니다.
+ 함수의 배치 크기를 늘려 간접 호출할 때마다 더 많은 메시지가 처리되도록 합니다.