AWS Lambda 기반 애플리케이션에서 관찰 가능성을 높이는 잘 알려지지 않은 두 가지 방법

마이크로서비스 환경에서 일해 본 적이 있다면 모니터링과 관찰 가능성이 얼마나 중요한지 알고 있을 것입니다. 모든 중단은 "살인 미스터리"로 바뀔 수 있으며 개발자는 정확히 무엇이 잘못되었고 어떻게 예방할 수 있었는지 알아내는 데 상당한 시간을 할애합니다.

이 블로그 게시물은 AWS Lambda 관련 "살인 미스터리"를 간단한 로그 확인으로 전환하는 데 사용할 수 있는 잘 알려지지 않은 두 가지 기술을 보여주는 것을 목표로 합니다.

SDK 작업 로깅

수행하는 모든 SDK 작업을 기록하는 것은 Lambda 함수 내에서 진행되는 작업을 정확하게 명확하게 파악할 수 있는 쉬운 방법일 수 있습니다. 하지만 이 방법은 신중하게 사용해야 합니다. 트래픽이 충분히 높으면 상당한 CloudWatch 비용이 발생할 수 있습니다. 이러한 상황에서는 로그 샘플링을 조사할 수 있습니다.

내가 익숙한 AWS-SDK(Node.js 및 Go SDK)를 사용하면 어디에서나 로그 문으로 코드를 오염시키지 않고도 이러한 로깅을 사용할 수 있습니다. 주어진 SDK 인스턴스에 로거를 전달하기만 하면 됩니다.

다음은 로거를 사용하여 Node.js AWS-SDKDocumentClient를 계측하는 예입니다.

import { DocumentClient } from "aws-sdk/clients/dynamodb";
import pino from "pino";

const logger = pino();

const db = new DocumentClient({
  logger: {
    /**
     * The implementation is dependant on the logger itself.
     * In a real-world scenario you most likely want to also log the `requestId` or `X-Ray traceId`.
     */
    log: message => {
      logger.info({}, message);
    }
  }
});

다음은 DynamoDB 테이블에 항목을 추가하여 생성된 샘플 로그 메시지입니다.



프로덕션 설정에서는 민감한 정보가 포함될 수 있는 필드를 수정해야 할 가능성이 높습니다. 그런 경우에는 redact의 pino 구성 옵션을 살펴보십시오.

클라이언트 측 모니터링 켜기

최근에야 Client Side Monitoring 기능을 발견했습니다. CSM을 활성화하면 SDK 호출이 지정된 호출에 대한 메타데이터를 UDP 끝점에 푸시합니다( IP is configurable ). 메타데이터는 호출 내용이 아니라 작업 자체(수행된 API 호출의 종류, 대기 시간 및 유사한 정보)에 집중합니다.

다음은 CSM에서 생성한 예제 이벤트입니다.

{
  "Version": 1,
  "ClientId": "",
  "Type": "ApiCallAttempt",
  "Service": "S3",
  "Api": "ListObjectsV2",
  "Timestamp": 1590430065174,
  "AttemptLatency": 243,
  "Fqdn": "s3.amazonaws.com",
  "UserAgent": "aws-cli/1.18.51 Python/3.7.6 Darwin/19.4.0 botocore/1.16.1",
  "AccessKey": "ASIAXXXXXXXXXXXXXXXX",
  "Region": "us-east-1",
  "SessionToken": "XXX",
  "HttpStatusCode": 301,
  "XAmzRequestId": "0000000000000000",
  "XAmzId2": "XXX",
  "AwsException": "PermanentRedirect",
  "AwsExceptionMessage": "The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint."
}

보시다시피 이벤트는 SDK 호출에서 생성된 로그와 매우 다릅니다.

왜 CSM을 활성화해야 합니까?

IAM 정책 범위 지정

Lambdas(및 기타 컴퓨팅)의 맥락에서 최소 권한 액세스 원칙을 적용하는 것은 보안 관점에서 중요합니다. 내 관점에서 CSM은 AWS-SDK 호출의 맥락에서 이러한 원칙을 준수하도록 보장하는 이상적인 메커니즘입니다.

CSM을 활성화하고 몇 가지 워크로드(이상적으로는 종단 간 또는 통합 테스트)를 통해 AWS Lambda를 실행한 다음 수집된 메타데이터를 기반으로 함수에 대한 최소 권한을 추론할 수 있습니다.

해당 영역에서 대부분의 작업이 이미 완료된 것으로 나타났습니다. 출시iam-live 및 iam-live lambda extension . 이러한 도구를 사용하면 앞서 설명한 프로세스를 쉽게 수행할 수 있습니다. 기존 스택에 연결하기만 하면 됩니다.

보안 모니터링

CSM은 애플리케이션이 수행할 수 있는 비정상적인 동작을 모니터링하는 데 사용할 수 있습니다. AWS CloudTrial은 대부분의 경우 중요한 옵션이지만 모든 AWS 이벤트가 여기에 있는 것은 아닙니다. CSM과 AWS CloudTrial을 모두 사용하면 AWS CloudTrial만 사용할 때보다 보안 축에 대해 훨씬 더 많은 가시성을 얻을 수 있습니다.

궁금한 경우 AWS CloudTrial과 CSM을 모두 활용하여 서로를 보완할 수 있는 방법은 무엇입니까? checkout this great article on cloudonaut.io

요약

제 생각에는 AWS Lambda 기반 AWS 애플리케이션에서 관찰 가능성을 높이는 두 가지 잘 알려지지 않은 방법이었습니다.
이 블로그를 작성하는 동안 내가 한 것처럼 새로운 것을 배웠기를 바랍니다.

당신은 트위터에서 나를 찾을 수 있습니다 -

시간 내 주셔서 감사합니다.