단일 서버(Monolithic) 환경에서는 서버에 직접 접속해 로그 파일을 열어보면 그만이었지만, 언제든 죽고 재생성되는 K8s 환경에서는 불가능한 방식입니다. 이번 글에서는 클라우드 네이티브 환경의 필수 요소인 옵저버빌리티(Observability)와, 이를 고도화하는 AIOps 트렌드에 대해 다룹니다.1. 모니터링(Monitoring)을 넘어 옵저버빌리티(Observability)로단순한 '모니터링'과 '옵저버빌리티(관측성)'는 미묘하지만 큰 차이가 있습니다.모니터링: 시스템이 "언제(When)" 망가졌는지, 즉 CPU 사용률이 90%를 넘었는지 등 미리 정의된 임계치를 감시합니다.옵저버빌리티: 시스템이 "왜(Why)" 망가졌는지, 즉 분산된 마이크로서비스 환경에서 외부 요청이 내부의 어떤 서비스들을..

- W3C Trace Context란?현대의 마이크로서비스 아키텍처(MSA) 환경에서 하나의 사용자 요청은 수많은 서비스를 넘나듭니다. 이때 가장 큰 골칫거리 중 하나는 "이 요청이 대체 어디서 병목이 걸렸는가?"를 찾아내는 것입니다. 이러한 분산 추적 컨텍스트를 서비스 간에 끊김 없이 전파하기 위해 등장한 HTTP 및 메시징 헤더의 국제 표준, W3C Trace Context에 대해 깊이 알아보겠습니다.쉽게 말해, 이 규약은 "A 서비스에서 B 서비스로 넘어가는 네트워크 요청이 전체 트랜잭션 중 어디에 속하는지 알려주는 범용 명함"과 같습니다. 현재 옵저버빌리티 생태계의 사실상 표준인 OpenTelemetry에서도 기본 프로토콜로 채택하고 있습니다.1. 왜 필요해졌을까? : "헤더 파편화"의 종식이 W..

- Tempo: 100% 샘플링을 실현한 분산 트레이싱과 MSA 병목 추적메트릭(Mimir)을 통해 장애의 '발생'을 인지하고, 로그(Loki)를 통해 에러의 '원인'을 파악하는 과정까지 살펴보았습니다. 이제 관측성의 마지막 퍼즐이자, 거대한 마이크로서비스 아키텍처(MSA) 환경에서 가장 까다로운 질문인 "도대체 수많은 서비스 중 어디서 병목이 발생했는가?"를 해결할 차례입니다.이번 포스팅에서는 LGTM 스택의 'T'를 담당하며 분산 트레이싱 백엔드의 새로운 패러다임을 제시한 Tempo(템포)에 대해 깊이 파헤쳐 보겠습니다.1. 분산 트레이싱의 딜레마: '샘플링(Sampling)의 저주'하나의 사용자 요청이 API 게이트웨이를 거쳐 Auth, Payment, Inventory, Database 등 수십 ..