동시성(Concurrency) 모니터링

동시성(Concurrency) 모니터링

Lambda는 함수의 동시성을 모니터링하는 데 도움을 주는 Amazon CloudWatch 지표를 내보내요. 이 항목은 이러한 지표와 해석 방법을 설명해요.

출처: AWS Lambda 개발자 안내서

본문

Topics(주제)

일반 동시성 지표

다음 지표로 Lambda 함수의 동시성을 모니터링하세요. 각 지표의 세분성(granularity)은 1분이에요.

  • ConcurrentExecutions – 특정 시점의 활성 동시 호출 수예요. Lambda는 모든 함수, 버전, 별칭에 대해 이 지표를 내보내요. Lambda 콘솔의 모든 함수에 대해 Monitoring(모니터링) 탭의 Metrics 아래에서 ConcurrentExecutions 그래프가 기본으로 표시돼요. 이 지표는 MAX로 봐요.

  • UnreservedConcurrentExecutions – 예약되지 않은 동시성(unreserved concurrency)을 사용하는 활성 동시 호출 수예요. Lambda는 리전의 모든 함수에 걸쳐 이 지표를 내보내요. 이 지표는 MAX로 봐요.

  • ClaimedAccountConcurrency – 온디맨드 호출에 사용할 수 없는 동시성의 양이에요. ClaimedAccountConcurrency는 UnreservedConcurrentExecutions + 할당된 동시성(총 예약 동시성 + 총 프로비저닝된 동시성)과 같아요. ClaimedAccountConcurrency가 계정 동시성 한도를 초과하면 더 높은 계정 동시성 한도를 요청할 수 있어요.

    이 지표는 MAX로 봐요. 자세한 내용은 ClaimedAccountConcurrency 지표 작업을 참고하세요.

프로비저닝된 동시성 지표

프로비저닝된 동시성(provisioned concurrency)을 사용하는 Lambda 함수를 모니터링하려면 다음 지표를 사용하세요. 각 지표의 세분성은 1분이에요.

  • ProvisionedConcurrentExecutions – 프로비저닝된 동시성으로 호출을 활발히 처리 중인 실행 환경 인스턴스 수예요. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전과 별칭에 대해 이 지표를 내보내요. 이 지표는 MAX로 봐요.

ProvisionedConcurrentExecutions는 할당한 총 프로비저닝된 동시성 수와 같지 않아요. 예를 들어 함수 버전에 프로비저닝된 동시성 100단위를 할당했다고 가정해 보세요. 어느 1분 동안 그 100개 실행 환경 중 최대 50개가 동시에 호출을 처리했다면 MAX(ProvisionedConcurrentExecutions) 값은 50이에요.

  • ProvisionedConcurrencyInvocations – Lambda가 프로비저닝된 동시성을 사용해 함수 코드를 호출한 횟수예요. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전과 별칭에 대해 이 지표를 내보내요. 이 지표는 SUM으로 봐요.

ProvisionedConcurrencyInvocations는 ProvisionedConcurrentExecutions와 다른데, ProvisionedConcurrencyInvocations는 총 호출 수를 세는 반면 ProvisionedConcurrentExecutions는 활성 환경 수를 세기 때문이에요. 이 차이를 이해하려면 다음 시나리오를 생각해 보세요:

ProvisionedConcurrencyInvocations와 ProvisionedConcurrentExecutions 비교.

이 예제에서 분당 1회 호출을 받고 각 호출 완료에 2분이 걸린다고 가정해 보세요. 각 주황색 가로 막대는 단일 요청을 나타내요. 이 함수에 프로비저닝된 동시성 10단위를 할당해 각 요청이 프로비저닝된 동시성으로 실행된다고 가정해 보세요.

0분과 1분 사이에 Request 1이 들어와요. 1분 시점에 MAX(ProvisionedConcurrentExecutions) 값은 1인데, 지난 1분 동안 최대 1개의 실행 환경이 활성 상태였기 때문이에요. SUM(ProvisionedConcurrencyInvocations) 값도 1인데, 지난 1분 동안 새 요청 1개가 들어왔기 때문이죠.

1분과 2분 사이에 Request 2가 들어오고 Request 1은 계속 실행돼요. 2분 시점에 MAX(ProvisionedConcurrentExecutions) 값은 2인데, 지난 1분 동안 최대 2개의 실행 환경이 활성 상태였기 때문이에요. 하지만 SUM(ProvisionedConcurrencyInvocations) 값은 1인데, 지난 1분 동안 새 요청은 1개만 들어왔기 때문이에요. 이 지표 동작은 예제 끝까지 계속됩니다.

  • ProvisionedConcurrencySpilloverInvocations – 모든 프로비저닝된 동시성이 사용 중일 때 Lambda가 표준(예약 또는 비예약) 동시성으로 함수를 호출한 횟수예요. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전과 별칭에 대해 이 지표를 내보내요. 이 지표는 SUM으로 봐요. ProvisionedConcurrencyInvocations + ProvisionedConcurrencySpilloverInvocations 값은 총 함수 호출 수(즉 Invocations 지표)와 같아야 해요.

    ProvisionedConcurrencyUtilization – 사용 중인 프로비저닝된 동시성의 백분율(즉 ProvisionedConcurrentExecutions 값을 총 할당된 프로비저닝된 동시성으로 나눈 값)이에요. Lambda는 프로비저닝된 동시성이 구성된 각 함수 버전과 별칭에 대해 이 지표를 내보내요. 이 지표는 MAX로 봐요.

예를 들어 함수 버전에 프로비저닝된 동시성 100단위를 프로비저닝했다고 가정해 보세요. 어느 1분 동안 그 100개 실행 환경 중 최대 60개가 동시에 호출을 처리했다면 MAX(ProvisionedConcurrentExecutions) 값은 60이고, MAX(ProvisionedConcurrencyUtilization) 값은 0.6이에요.

ProvisionedConcurrencySpilloverInvocations 값이 높으면 함수에 추가 프로비저닝된 동시성을 할당해야 할 수 있음을 나타내요. 또는 미리 정의된 임계값을 기반으로 프로비저닝된 동시성의 자동 스케일링을 처리하도록 Application Auto Scaling을 구성할 수도 있어요.

반대로 ProvisionedConcurrencyUtilization 값이 지속적으로 낮으면 함수에 프로비저닝된 동시성을 과다 할당했을 수 있음을 나타내요.

ClaimedAccountConcurrency 지표 작업

Lambda는 ClaimedAccountConcurrency 지표로 계정이 온디맨드 호출에 쓸 수 있는 동시성의 양을 결정해요. Lambda는 다음 공식으로 ClaimedAccountConcurrency를 계산해요:

ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)

UnreservedConcurrentExecutions는 비예약 동시성을 사용하는 활성 동시 호출 수예요. 할당된 동시성(allocated concurrency)은 다음 두 부분의 합이에요(RC를 "예약 동시성", PC를 "프로비저닝된 동시성"이라고 할 때):

  • 리전의 모든 함수에 걸친 총 RC.
  • RC를 사용하지 않는, 리전에서 PC를 사용하는 모든 함수에 걸친 총 PC.

참고
함수에 RC보다 많은 PC를 할당할 수 없어요. 따라서 함수의 RC는 항상 PC보다 크거나 같아요. PC와 RC를 모두 가진 그러한 함수의 할당된 동시성 기여분을 계산할 때 Lambda는 둘 중 최대값인 RC만 고려해요.

Lambda는 온디맨드 호출에 쓸 수 있는 동시성의 양을 결정할 때 ConcurrentExecutions가 아니라 ClaimedAccountConcurrency 지표를 사용해요. ConcurrentExecutions 지표는 활성 동시 호출 수를 추적하는 데 유용하지만 항상 실제 동시성 가용성을 반영하진 않아요. Lambda가 가용성을 결정할 때 예약 동시성과 프로비저닝된 동시성도 고려하기 때문이에요.

ClaimedAccountConcurrency를 설명하기 위해, 함수 전반에 걸쳐 대부분 사용되지 않는 많은 예약 동시성과 프로비저닝된 동시성을 구성한 시나리오를 고려해 보세요. 다음 예제에서 계정 동시성 한도가 1,000이고 계정에 function-orange와 function-blue라는 두 개의 주요 함수가 있다고 가정해 보세요. function-orange에 예약 동시성 600단위를 할당합니다. function-blue에 프로비저닝된 동시성 200단위를 할당해요. 시간이 지나면서 추가 함수를 배포하고 다음 트래픽 패턴을 관찰한다고 가정해 보세요:

Lambda가 ClaimedAccountConcurrency를 결정하는 방식을 보여주는 그래프.

이전 다이어그램에서 검은색 선은 시간에 따른 실제 동시성 사용을, 빨간색 선은 시간에 따른 ClaimedAccountConcurrency 값을 나타내요. 이 시나리오 내내 함수 전반의 실제 동시성 사용률이 낮음에도 ClaimedAccountConcurrency는 최소 800이에요. function-orange와 function-blue에 동시성 800단위를 할당했기 때문이죠. Lambda 관점에서 이 동시성을 "청구(claimed)"했으므로 다른 함수에는 200단위의 동시성만 남게 돼요.

이 시나리오에서 ClaimedAccountConcurrency 공식의 할당된 동시성은 800이에요. 그러면 다이어그램의 여러 지점에서 ClaimedAccountConcurrency 값을 유도할 수 있어요:

  • t1에서 ClaimedAccountConcurrency는 800(800 + 0 UnreservedConcurrentExecutions)이에요.
  • t2에서 ClaimedAccountConcurrency는 900(800 + 100 UnreservedConcurrentExecutions)이에요.
  • t3에서 ClaimedAccountConcurrency는 다시 900(800 + 100 UnreservedConcurrentExecutions)이에요.

CloudWatch에서 ClaimedAccountConcurrency 지표 설정

Lambda는 ClaimedAccountConcurrency 지표를 CloudWatch에 내보내요. 다음 공식처럼 이 지표를 SERVICE_QUOTA(ConcurrentExecutions) 값과 함께 사용해 계정의 동시성 사용률 백분율을 얻을 수 있어요:

Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%

다음 스크린샷은 CloudWatch에서 이 공식을 그래프로 그리는 방법을 보여줘요. 녹색 claim_utilization 선은 약 40%인 이 계정의 동시성 사용률을 나타내요:

CloudWatch에서 ClaimedAccountConcurrency 지표 사용.

이전 스크린샷에는 동시성 사용률이 70%를 초과할 때 ALARM 상태가 되는 CloudWatch 알람도 포함되어 있어요. ClaimedAccountConcurrency 지표를 이와 유사한 알람과 함께 사용하면 더 높은 계정 동시성 한도를 요청해야 할 때를 선제적으로 파악할 수 있어요.

더 알아보기 (Learn more)

  • 일반 동시성 지표(ConcurrentExecutions 등)와 프로비저닝된 동시성 지표, 그리고 ClaimedAccountConcurrency 공식과 CloudWatch 알람 활용을 익혀 보세요.