AWS X-Ray로 Lambda 함수 호출 시각화

AWS X-Ray를 사용해서 애플리케이션의 구성 요소를 시각화하고, 성능 병목을 식별하며, 오류가 발생한 요청을 문제 해결할 수 있어요. Lambda 함수가 X-Ray로 트레이스 데이터를 보내면 X-Ray가 데이터를 처리해서 서비스 맵과 검색 가능한 트레이스 요약을 생성해요.

Lambda는 X-Ray에 대해 Active와 PassThrough 두 가지 트레이싱 모드를 지원해요. Active 트레이싱을 사용하면 Lambda가 함수 호출에 대한 트레이스 세그먼트를 자동으로 생성해서 X-Ray로 보내요. 반면 PassThrough 모드는 트레이싱 컨텍스트를 다운스트림 서비스로 단순히 전파해요.

함수에 Active 트레이싱을 활성화했다면 Lambda는 샘플링된 요청에 대해 트레이스를 X-Ray로 자동으로 보내요. 일반적으로 Amazon API Gateway나 X-Ray SDK로 계측된 Amazon EC2에 호스팅된 애플리케이션 같은 업스트림 서비스가 들어오는 요청을 트레이스할지 결정한 다음, 그 샘플링 결정을 트레이싱 헤더로 추가해요. Lambda는 이 헤더를 사용해서 트레이스를 보낼지 결정해요. Amazon SQS 같은 업스트림 메시지 생산자의 트레이스는 다운스트림 Lambda 함수의 트레이스와 자동으로 연결되어 전체 애플리케이션의 종단 간(end-to-end) 뷰를 만들어요. 자세한 내용은 AWS X-Ray 개발자 안내서의 이벤트 기반 애플리케이션 트레이싱을 참고하세요.

참고(Note) X-Ray 트레이싱은 현재 Amazon Managed Streaming for Apache Kafka(Amazon MSK), 자체 관리형 Apache Kafka, ActiveMQ와 RabbitMQ를 사용하는 Amazon MQ, Amazon DocumentDB 이벤트 소스 매핑이 있는 Lambda 함수에서는 지원되지 않아요.

콘솔로 Lambda 함수에서 활성 트레이싱을 전환하려면 다음 단계를 따르세요.

활성 트레이싱 켜기

Lambda 콘솔의 Functions 페이지를 열어요.
함수를 선택해요.
Configuration을 선택한 다음 Monitoring and operations tools을 선택해요.
Additional monitoring tools에서 Edit을 선택해요.
CloudWatch Application Signals and AWS X-Ray에서 Lambda service traces에 대해 Enable을 선택해요.
Save를 선택해요.

함수는 트레이스 데이터를 X-Ray에 업로드할 권한이 필요해요. Lambda 콘솔에서 트레이싱을 활성화하면 Lambda가 함수의 실행 역할에 필요한 권한을 추가해요. 그렇지 않으면 AWSXRayDaemonWriteAccess 정책을 실행 역할에 추가해요.

X-Ray는 애플리케이션에 대한 모든 요청을 트레이스하지 않아요. X-Ray는 트레이싱이 효율적이면서 모든 요청을 대표적으로 샘플링하면서도, 그래도 모든 요청의 대표 샘플을 제공하도록 샘플링 알고리즘을 적용해요. 샘플링 비율은 초당 1개 요청 + 추가 요청의 5%예요. 함수에 대해 X-Ray 샘플링 비율을 구성할 수는 없어요.

출처: AWS Lambda 개발자 안내서

본문

X-Ray 트레이스 이해

X-Ray에서 트레이스(trace) 는 하나 이상의 서비스가 처리하는 요청에 대한 정보를 기록해요. Lambda는 트레이스당 2개의 세그먼트를 기록해서 서비스 그래프에 두 개의 노드를 만드는 데요. 아래 이미지가 이 두 노드를 강조해요.

왼쪽의 첫 번째 노드는 호출 요청을 받는 Lambda 서비스를 나타내요. 두 번째 노드는 특정 Lambda 함수를 나타내요.

Lambda 서비스에 대해 기록된 세그먼트 AWS::Lambda는 Lambda 실행 환경을 준비하는 데 필요한 모든 단계를 포함해요. 여기에는 MicroVM 스케줄링, 구성한 리소스로 실행 환경 만들기·동결 해제, 함수 코드와 모든 레이어 다운로드가 포함돼요.

AWS::Lambda::Function 세그먼트는 함수가 수행한 작업을 위한 것이에요.

참고(Note) AWS는 현재 Lambda 서비스를 변경하고 있어요. 이러한 변경 때문에 AWS 계정의 서로 다른 Lambda 함수가 생성하는 시스템 로그 메시지와 트레이스 세그먼트의 구조와 내용에 약간의 차이가 있을 수 있어요. 이 변경은 함수 세그먼트의 하위 세그먼트에 영향을 줘요. 다음 단락에서는 이러한 하위 세그먼트의 기존 형식과 새 형식을 모두 설명해요. 이 변경 사항은 앞으로 몇 주에 걸쳐 구현되며, 중국 및 GovCloud 리전을 제외한 모든 AWS 리전의 모든 함수가 새 형식의 로그 메시지와 트레이스 세그먼트를 사용하도록 전환될 예정이에요.

기존 스타일 AWS X-Ray Lambda 세그먼트 구조 AWS::Lambda 세그먼트의 기존 X-Ray 구조는 다음과 같아요.

이 형식에서 함수 세그먼트는 Initialization, Invocation, Overhead 하위 세그먼트를 가져요. SnapStart 전용으로 Restore 하위 세그먼트도 있어요(이 다이어그램에는 표시되지 않음).

Initialization 하위 세그먼트는 Lambda 실행 환경 라이프사이클의 초기화 단계를 나타내요. 이 단계에서 Lambda는 확장을 초기화하고, 런타임을 초기화하며, 함수의 초기화 코드를 실행해요.

Invocation 하위 세그먼트는 Lambda가 함수 핸들러를 호출하는 호출 단계를 나타내요. 이는 런타임과 확장 등록으로 시작해서 런타임이 응답을 보낼 준비가 될 때 끝나요.

(Lambda SnapStart 전용) Restore 하위 세그먼트는 Lambda가 스냅샷을 복원하고, 런타임을 로드하고, 복원 후 런타임 훅을 실행하는 데 걸리는 시간을 보여줘요. 스냅샷 복원 과정에는 MicroVM 외부에서 보내는 활동 시간이 포함될 수 있어요. 이 시간은 Restore 하위 세그먼트에 보고돼요. 스냅샷 복원을 위해 MicroVM 외부에서 보낸 시간은 청구되지 않아요.

Overhead 하위 세그먼트는 런타임이 응답을 보낸 시점과 다음 호출 신호 사이에 발생하는 단계를 나타내요. 이 시간 동안 런타임은 호출과 관련된 모든 작업을 마치고 샌드박스 동결을 준비해요.

중요(Important) X-Ray SDK를 사용해서 다운스트림 호출, 어노테이션, 메타데이터에 대한 추가 하위 세그먼트로 Invocation 하위 세그먼트를 확장할 수 있어요. 함수 세그먼트에 직접 접근하거나 핸들러 호출 범위 밖에서 수행된 작업을 기록할 수는 없어요.

Lambda 실행 환경 단계에 대한 자세한 내용은 Lambda 실행 환경 라이프사이클 이해를 참고하세요.

기존 스타일 X-Ray 구조를 사용한 예시 트레이스는 다음 다이어그램에 표시돼요.

예시에서 두 세그먼트를 주목하세요. 둘 다 my-function이라는 이름이지만, 하나는 AWS::Lambda origin이고 다른 하나는 AWS::Lambda::Function origin이에요. AWS::Lambda 세그먼트에 오류가 표시되면 Lambda 서비스에 문제가 있는 것이고, AWS::Lambda::Function 세그먼트에 오류가 표시되면 함수에 문제가 있는 것이에요.

참고(Note) 때때로 X-Ray 트레이스에서 함수 초기화와 호출 단계 사이에 큰 간격이 보일 수 있어요. 프로비저닝된 동시성을 사용하는 함수의 경우 Lambda가 호출에 앞서 함수 인스턴스를 미리 초기화하기 때문이에요. 예약되지 않은(온디맨드) 동시성을 사용하는 함수의 경우 Lambda는 호출이 없더라도 함수 인스턴스를 선제적으로 초기화할 수 있어요. 시각적으로 두 경우 모두 초기화와 호출 단계 사이에 시간 간격으로 나타나요.

새 스타일 AWS X-Ray Lambda 세그먼트 구조 AWS::Lambda 세그먼트의 새 X-Ray 구조는 다음과 같아요.

이 새 형식에서 Init 하위 세그먼트는 이전과 같이 Lambda 실행 환경 라이프사이클의 초기화 단계를 나타내요.

새 형식에는 호출 세그먼트가 없어요. 대신 고객 하위 세그먼트가 AWS::Lambda::Function 세그먼트에 직접 연결돼요. 이 세그먼트에는 다음 지표가 어노테이션으로 포함돼요.

aws.responseLatency - 함수가 실행되는 데 걸린 시간
aws.responseDuration - 응답을 고객에게 전송하는 데 걸린 시간
aws.runtimeOverhead - 런타임이 마치는 데 필요한 추가 시간
aws.extensionOverhead - 확장이 마치는 데 필요한 추가 시간

새 스타일 X-Ray 구조를 사용한 예시 트레이스는 다음 다이어그램에 표시돼요.

Lambda에서 트레이싱에 대한 언어별 소개는 다음 주제를 참고하세요.

활성 계측을 지원하는 전체 서비스 목록은 AWS X-Ray 개발자 안내서의 지원되는 AWS 서비스를 참고하세요.

Lambda의 기본 트레이싱 동작

Active 트레이싱을 켜지 않으면 Lambda는 기본적으로 PassThrough 트레이싱 모드를 사용해요.

PassThrough 모드에서 Lambda는 X-Ray 트레이싱 헤더를 다운스트림 서비스로 전달하지만 트레이스를 자동으로 보내지는 않아요. 트레이싱 헤더에 요청 샘플링 결정이 포함되어 있어도 마찬가지예요. 업스트림 서비스가 X-Ray 트레이싱 헤더를 제공하지 않으면 Lambda는 헤더를 생성하고 샘플링하지 않기로 결정해요. 다만 함수 코드에서 트레이싱 라이브러리를 호출해서 자체 트레이스를 보낼 수는 있어요.

참고(Note) 이전에는 Amazon API Gateway 같은 업스트림 서비스가 트레이싱 헤더를 추가하면 Lambda가 트레이스를 자동으로 보냈어요. 트레이스를 자동으로 보내지 않음으로써 Lambda는 중요하다고 생각하는 함수를 트레이스할 수 있는 제어권을 제공해요. 솔루션이 이 수동 트레이싱 동작에 의존한다면 Active 트레이싱으로 전환하세요.

실행 역할 권한

Lambda는 트레이스 데이터를 X-Ray로 보내기 위해 다음 권한이 필요해요. 이를 함수의 실행 역할에 추가해요.

이 권한은 AWSXRayDaemonWriteAccess 관리형 정책에 포함돼 있어요.

Lambda API로 `Active` 트레이싱 활성화

AWS CLI나 AWS SDK로 트레이싱 구성을 관리하려면 다음 API 작업을 사용해요.

다음 예시 AWS CLI 명령은 my-function이라는 함수에서 활성 트레이싱을 활성화해요.

aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active

트레이싱 모드는 함수 버전을 게시할 때 버전별 구성의 일부예요. 게시된 버전에서는 트레이싱 모드를 변경할 수 없어요.

CloudFormation으로 `Active` 트레이싱 활성화

CloudFormation 템플릿에서 AWS::Lambda::Function 리소스의 트레이싱을 활성화하려면 TracingConfig 속성을 사용해요.

예시 function-inline.yml – 트레이싱 구성

Resources:
  function:
    Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
    Properties:
      TracingConfig:
        Mode: Active
      ...

AWS Serverless Application Model(AWS SAM) AWS::Serverless::Function 리소스의 경우 Tracing 속성을 사용해요.

예시 template.yml – 트레이싱 구성

Resources:
  function:
    Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
    Properties:
      Tracing: Active
      ...

더 알아보기 (Learn more)

X-Ray로 Lambda 함수를 계측하는 방법은 AWS Lambda 개발자 안내서의 트레이싱 주제를 참고하세요.

AWS X-Ray로 Lambda 함수 호출 시각화