중요한 것을 측정하기: AWS Lambda Powertools에 다중 차원 세트 추가
Source: Dev.to
죄송합니다만, 번역할 텍스트가 제공되지 않았습니다. 번역을 원하시는 전체 내용을 알려주시면 한국어로 번역해 드리겠습니다.
대부분의 프로덕션 시스템이 실패하는 이유는 메트릭이 부족해서가 아니라, 그들이 가지고 있는 메트릭이 현실을 평탄화하기 때문입니다.
시간이 지나면서 팀과 아키텍처 전반에 걸쳐 같은 패턴을 계속 목격했습니다:
- 엔지니어들은 대시보드가 풍부하지만, 사고 발생 시 간단한 질문에 답하는 데 어려움을 겪습니다.
- 데이터는 존재하지만, 의미 있는 차이를 가리는 방식으로 집계됩니다.
이것이 AWS Lambda Powertools for Python에 다중 차원 세트를 추가하게 만든 문제입니다.
실제 문제: 계측이 아닌 집계
**CloudWatch’s Embedded Metric Format (EMF)**는 오랫동안 차원(dimensions) 메트릭을 지원해 왔습니다. 이론적으로는 팀이 환경, 리전, 고객 유형, 배포 형태 등에 따라 메트릭을 슬라이스할 수 있게 합니다. 실제로는 대부분의 팀이 메트릭 전송당 하나의 집계 뷰만 선택해야 합니다.
지연 시간을 측정하려면 다음 중 하나를 선택해야 합니다:
service + region, 또는service + environment, 또는service + customer_type
하지만 다른 차원 조합을 사용해 같은 메트릭을 반복해서 전송하지 않는 한 한 번에 모두 측정할 수 없습니다.
이 트레이드오프가 문제인 이유
- 메트릭이 중복됩니다 – 동일한 값이 서로 다른 차원 집합으로 여러 번 전송됩니다.
- 코드가 장황하고 취약해집니다 – 새로운 집계 경로가 추가될 때마다 전송 로직이 늘어납니다.
- CloudWatch 비용이 증가합니다 – 차원 조합이 추가될 때마다 저장 및 수집 요금이 추가됩니다.
- 가장 필요할 때 중요한 집계 경로가 누락됩니다, 이는 사고 발생 시 가시성을 저하시킵니다.
결과는 단순한 비효율성을 넘어, 사고가 발생했을 때 신뢰성을 약화시킵니다.
패턴을 포착한 기능 요청
이 제한은 이론적인 것이 아니었습니다. 2025년 초, 커뮤니티 구성원이 AWS Lambda Powertools 저장소에 기능 요청을 열었습니다:
“동일한 Metrics 인스턴스에 다중 차원 세트 지원 추가”
(Issue #6198)
사용 사례
- 다중 지역 및 환경에 배포된 Lambda
- 환경, 지역, 그리고 두 가지 모두로 집계되어야 하는 메트릭
- 하나의 메트릭 값, 여러 의미 있는 뷰
요청에서는 중요한 사실도 강조했습니다: EMF 사양이 이미 이를 지원한다는 점. EMF의 Dimensions 필드는 배열의 배열로 정의되며, 각 내부 배열은 다른 집계 뷰를 나타냅니다. 다른 Powertools 런타임(TypeScript, Java, .NET)은 이미 이 기능을 제공하고 있었지만, Python은 제공하지 않았습니다.
Source: …
기능 요청에서 프로덕션‑레디 구현까지
유지보수 담당자들이 접근 방식에 합의한 뒤, 저는 Python 런타임용 이 기능을 구현하는 작업을 맡았습니다. 목표는 새로운 것을 발명하는 것이 아니라 다음을 달성하는 것이었습니다:
- Python을 EMF 사양에 맞추기.
- 다른 Powertools 런타임과 기능을 동등하게 만들기.
- 기존 사용자에게 자연스럽게 느껴지는 깔끔하고 직관적인 API 제공.
설계 원칙
코드를 건드리기 전에 몇 가지 제약 조건이 구현을 이끌었습니다:
- 하위 호환성 – 기존
add_dimension()동작은 그대로 유지되어야 합니다. - 명확한 사고 모델 – 숨겨진 부작용이나 모호한 API가 없어야 합니다.
- 사양에 맞는 출력 – 직렬화된 EMF는 CloudWatch 기대치와 일치해야 합니다.
- 프로덕션 안전성 – 호출 간 엄격한 검증 및 정리 수행.
최종 API
최종 설계는 TypeScript 구현에서 검증된 패턴을 그대로 따릅니다:
add_dimension()→ 주 차원 집합에 추가합니다.add_dimensions()→ 새로운 집계 뷰를 생성합니다.
사용 예시
from aws_lambda_powertools import Metrics
from aws_lambda_powertools.metrics import MetricUnit
metrics = Metrics(namespace="ServerlessAirline", service="booking")
# 추가 차원 집합 생성
metrics.add_dimensions({"environment": "prod", "region": "us-east-1"})
metrics.add_dimensions({"environment": "prod"})
metrics.add_dimensions({"region": "us-east-1"})
# 단일 메트릭 전송
metrics.add_metric(
name="SuccessfulRequests",
unit=MetricUnit.Count,
value=100,
)
단일 메트릭 전송만으로도 CloudWatch는 이제 다음과 같이 집계할 수 있습니다:
environment + regionenvironment만region만
중복 메트릭 없이, 병렬 파이프라인 없이, 추측 없이.
내부 변경 사항
구현에 다음과 같은 주요 업데이트가 도입되었습니다:
- Multiple dimension sets가 이제 내부에서 추적됩니다.
- EMF 직렬화가 업데이트되어 모든 차원 배열을 내보냅니다.
- Default dimensions가 자동으로 포함됩니다.
- CloudWatch의 30‑dimension 제한이 이제 적용됩니다.
- 중복 키는 결정적으로 처리됩니다 – “마지막 값이 승리” 방식.
- 차원 상태는 호출 사이에 안전하게 초기화됩니다.
테스트 커버리지
이번 변경에는 13개의 새로운 테스트가 포함되어 다음을 검증합니다:
| 영역 | 테스트 내용 |
|---|---|
| Multiple dimension set creation | 여러 차원 집합의 생성, 검색 및 직렬화. |
| Validation & edge cases | 중복 키 처리, 30‑dimension 제한 초과, 빈 입력 등 예외 상황 검증. |
| Integration with existing metrics | 기존 메트릭 기능(예: 카운터, 타이머)과의 상호 작용. |
| High‑resolution metrics compatibility | 고해상도 메트릭 데이터와 차원 처리가 정상 동작하는지 확인. |
모든 기존 테스트가 통과했으며, 코드 품질 검증도 성공했고, 유지보수 담당자들이 병합을 승인했습니다.
왜 이것이 프로덕션에서 중요한가
이 기능은 새로운 메트릭을 추가하는 것이 아니라 기존 메트릭을 더 정확하게 만듭니다. 팀이 발생 시점에 여러 집계 뷰를 표현할 수 있게 되면:
- 사고 대응이 빨라집니다
- 대시보드가 간단해집니다
- 알림이 더 정밀해집니다
- 엔지니어가 보는 것을 신뢰하게 됩니다
메트릭은 계약입니다.
사용자가 실제로 시스템을 경험하는 방식을 반영하지 못한다면, 메트릭은 조용히 실패합니다.
여러 차원 집합이 운영상의 문제를 완전히 없애지는 않지만, 많은 팀이 인식하지 못했던 맹점을 제거합니다.
전체 구현, 테스트 및 유지보수자 검토는 병합된 풀 리퀘스트에서 확인할 수 있습니다:
https://github.com/aws-powertools/powertools-lambda-python/pull/7848
공유 문제 해결로서의 오픈 소스
이 기여가 의미 있었던 이유는 단순히 코드 때문이 아니라—그 과정 때문이었습니다:
- 잘 문서화된 커뮤니티 기능 요청
- 런타임 전반에 걸친 유지관리자 협업
- 기존 사양과의 정렬
- 장기 유지 보수를 위해 설계된 솔루션
이것이 바로 최고의 오픈 소스이며, 반복되는 운영상의 고통을 공유 인프라로 전환합니다.
실제로 중요한 것 측정하기
Reliability isn’t about collecting more data; it’s about choosing the signals that deserve to exist.
신뢰성은 더 많은 데이터를 수집하는 것이 아니라, 존재할 가치가 있는 신호를 선택하는 것입니다.
This change helps teams measure systems the way users experience them — not just the way dashboards prefer. And that difference matters.
이 변화는 팀이 시스템을 사용자가 경험하는 방식대로 측정하도록 돕습니다 — 대시보드가 선호하는 방식만이 아니라. 그리고 그 차이가 중요합니다.
If you’re duplicating EMF emissions just to get different aggregation views, this should make your metrics simpler, clearer, and more reliable.
다양한 집계 뷰를 얻기 위해 EMF 방출을 복제하고 있다면, 이것이 메트릭을 더 간단하고 명확하며 신뢰할 수 있게 만들 것입니다.
If you run into edge cases, open an issue.
예외 상황에 직면하면 이슈를 열어 주세요.
That’s how this ecosystem keeps improving.
이것이 이 생태계가 지속적으로 개선되는 방식입니다.