당신의 모니터링 테스트 전략이 혼돈인가요?

Source: Dev.to

죄송합니다만, 번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

Introduction

요즘 많은 클라우드 구현에서는 AWS Lambda와 API Gateway와 같은 서버리스 아키텍처를 사용하여 서버를 관리하지 않고도 마이크로서비스나 기타 비즈니스 로직 기능을 제공합니다.
이 패턴은 성숙했으며, 서버리스 코드가 기대대로 동작하도록 보장하기 위한 다양한 도구와 접근 방식이 풍부합니다. 로컬에서 개발·테스트하고, 파이프라인을 통해 배포하며, 비정상적인 코드 배포 위험을 최소화할 수 있습니다.

팀과 작업할 때 저는 다음과 같은 모범 사례를 권장합니다:

• CI/CD를 통한 Lambda 배포.
• 로그 보존 기간 설정.
• 오류, 실패 또는 타임아웃을 포착하기 위한 모니터링 활성화.

코드 기능 테스트(행복한 경로 테스트)는 간단하지만, 우리 모니터링이 실제로 관심 있는 이벤트를 포착하는지와 문제가 감지될 때 알람이 정상적으로 발생하는지를 테스트하는 것은 더 복잡할 수 있습니다.

또한 불행한 경로를 테스트해야 합니다: 오류가 발생했을 때 시스템이 어떻게 동작하는지. 규제 산업에서는 테스트가 재현 가능하고 감사 가능해야 하는데, 오류를 수동으로 도입하면 이것이 어려워집니다. 코드에 직접 테스트 훅(if TEST then … 등)을 추가하면 비즈니스 로직이 오염되므로 피해야 합니다.

Chaos Engineering이 도움이 될 수 있습니다. 저는 이전에 AWS Fault Injection Simulator (FIS) 를 사용해 “Chaos Engineering as a Service”를 제공하는 방법에 대해 글을 썼습니다. 서버에 혼돈을 적용하는 것은 쉽습니다(예: SSH 접속 후 CPU 부하 추가, 네트워크 제한). 하지만 서버리스 워크로드에 적용하는 것은 명확하지 않았습니다—그런데 re:Invent 2024에서 AWS가 Lambda용 새로운 FIS 기능을 발표하면서 상황이 바뀌었습니다.

새로운 Lambda‑FIS 기능

FIS는 이제 Lambda 함수를 교란시키는 세 가지 방법을 지원합니다:

1. Delay – 함수 시작을 지연시킵니다.
2. Force – 함수가 오류를 발생하도록 강제합니다.
3. Modify – 함수가 반환하는 응답을 수정합니다.

이 기능을 사용하려면 네 가지 설정 단계를 수행해야 합니다:

1. Add a Lambda Layer – FIS가 Lambda 런타임과 상호 작용할 수 있도록 Lambda 레이어를 추가합니다.

2. Create an S3 bucket – FIS와 레이어 간에 구성 및 런타임 데이터를 전달하기 위한 S3 버킷을 생성합니다.

3. Add environment variables – Lambda 구성에 환경 변수를 추가합니다:

   AWS_FIS_CONFIGURATION_LOCATION   # S3 bucket (and optional prefix)
   AWS_LAMBDA_EXEC_WRAPPER          # Executable within the layer, e.g. /opt/aws-fis/bootstrap

4. Grant the Lambda’s execution role – 버킷 내용 읽기 및 나열 권한을 Lambda 실행 역할에 부여합니다.

전체 내용은 다음을 참조하십시오: AWS documentation.

Source: …

실험 템플릿 정의

Lambda에 FIS 레이어를 구성한 후, 실험 템플릿을 통해 무엇을 테스트할지 정의합니다. 템플릿은 여러 구성 요소로 이루어지며, 여기서는 다음 두 가지에 집중합니다:

예시 템플릿 (YAML)

Description: "Inject latency, errors, and 4xx responses into tagged Lambdas"
Targets:
  MyLambdas:
    ResourceType: "aws:lambda:function"
    ResourceArns:
      - "arn:aws:lambda:{{region}}:{{account}}:function:*"
    SelectionMode: "ALL"
    Filters:
      - Tags:
          my-chaos-tag: "true"
Actions:
  Delay:
    ActionId: "aws:fis:lambda:delay"
    Parameters:
      duration: "30s"
  Error:
    ActionId: "aws:fis:lambda:error"
    Parameters:
      errorType: "Runtime"
  Response:
    ActionId: "aws:fis:lambda:response"
    Parameters:
      statusCode: "404"

그런 다음 my-chaos-tag=true 태그가 붙은 모든 Lambda에 대해 실험을 실행할 수 있습니다.

예상 모니터링 결과

모니터링을 활성화한 후(예: CloudWatch 대시보드) 아래 스크린샷과 유사한 패턴을 확인할 수 있습니다.

베이스라인 (혼돈 없음)

+-------------------+-------------------+-------------------+
| Invocations       | Duration (ms)    | Error Count       |
+-------------------+-------------------+-------------------+
| steady line       | flat line        | zero              |
+-------------------+-------------------+-------------------+

실험 중

이러한 변화는 자동으로 나타나며—코드 수정이나 수동 인프라 조정이 필요하지—반복 가능하고 감사 가능한 실험을 제공합니다.

Repository & Deployment

제가 직접 시도해 볼 수 있도록 모든 것이 포함된 GitHub 저장소를 만들었습니다:

• CloudFormation 템플릿 – 다음을 배포합니다:
  • FIS 레이어가 사전 구성된 예제 Lambda.
  • Lambda를 호출할 API Gateway.
  • 샘플 CloudWatch 대시보드.
  • FIS 실험 템플릿.
• 배포 및 사용 방법에 대한 안내.

🔗 Repository:

스택이 완료되면 API Gateway URL이 출력됩니다.

Simple Load‑Generator Script

#!/usr/bin/env bash
# Continuous calls to the API Gateway to generate baseline traffic
while :; do
    curl -s "" &
    sleep 0.5
done

1. 스크립트를 실행하여 기준 트래픽을 생성합니다.
2. FIS 실험 템플릿을 시작합니다.
3. 위에서 설명한 대시보드 변화를 관찰합니다.

결론

서버리스 워크로드를 모니터링할 때는 “괜찮을 거야”라는 가정에 의존하기보다 형식적이고 반복 가능한 테스트 접근 방식을 채택해야 합니다. AWS FIS와 Lambda 레이어를 함께 사용하면 다음을 할 수 있습니다:

• 애플리케이션 코드를 건드리지 않고 지연, 오류 및 응답 변화를 주입합니다.
• 감사 가능하고 재현 가능한 카오스 실험을 생성합니다.
• 모니터링, 알림 및 대시보드가 예상대로 동작하는지 검증합니다.

한 번 시도해 보세요—컴플라이언스 감사자와 (당신의) 온‑콜 엔지니어가 고마워 할 겁니다!

테스트 프로세스에 카오스 엔지니어링 도입하기

Lambda 전용 테스트를 사용하면 구성에 대한 수동 조작이나 침입적인 if TEST then … 코드 블록에서 벗어나 카오스 엔지니어링을 테스트 프로세스의 필수 요소로 채택할 수 있습니다.

왜 이런 접근 방식을 취해야 할까요?

• 모니터링 검증 – 실제 문제가 발생했을 때 대시보드와 알림이 이를 보여주는지 확인합니다.
• 탄력성 감사 – 이해관계자에게 우리 모니터링 접근 방식이 견고하고 목적에 부합한다는 반복 가능한 문서화된 증거를 제공합니다.
• 코드 간소화 – 코드를 비즈니스 가치에 집중하도록 유지하고 단위 테스트 부담을 줄입니다.

카오스를 수용하면 모니터링이 정상 작동함을 입증하고 팀에게 필요할 때 필요한 개요를 제공할 수 있습니다. 이는 일요일 새벽 3시에 깨어나는 상황을 피하게 해줍니다.

그러니 주저하지 말고 테스트에 카오스를 도입하세요—팀이 분명히 감사할 것입니다!