AWS Summit Seoul 2023 첫 방문: DevOps의 이야기
안녕하세요. SpoonRadio SRE팀(DevOps)에서 근무하고 있는 Daniel(남태윤)입니다. 이번 AWS Summit 2023은 코로나 엔데믹 후 열린 만큼 다양한 볼거리가 있었습니다. Megazone Cloud, Datadog, Slack 등 여러 업체에서 제공하는 서비스를 살펴볼 수 있었고, AWS SnowBall Edge를 이용해 농구 모션을 분석하는 이벤트에도 참여할 수 있었습니다.
하지만 AWS Summit의 가장 큰 장점은 AWS 강연 및 사용 사례를 들어볼 수 있다는 것인데요. 개인적으로 여러 섹션 중 가장 인상 깊었던 “Global Scale Service의 중앙 집중식 Observability 구축하기”를 공유하고자 합니다.
Observability란?
Observability는 사전적 정의로는 “관찰할 수 있음”, “식별 가능성”, “주목할 만함” 이라고 합니다. 그럼 S/W에서 해당 개념을 처음 도입한 사람은 누구일까요? “Rudolf E. Kálmán” 엔지니어라고 하는데요. Ruldolf가 Observability 개념을 도입 하면서 정의한 내용은 아래와 같습니다.
오직 시스템의 외부 출력만을 이용해서 시스템의 현재 상태를 이해할 수 있는 능력
the ability to understand the current state of a system using only its external outputs.
해당 개념을 기반으로 AWS에서도 “Observability는 시스템 내부의 현재 상태를 잘 이해할 수 있도록 시스템 외부로 효과적인 정보를 전달하는 것"이라고 말합니다.
Monitoring vs Observability
설명한 Observability를 처음 들었을 때 Monitoring과 동일한 개념이 아닌가 싶습니다. 하지만 AWS에서는 명확하게 차이점이 있다고 설명합니다.
< AWS 발표내용 中 >
‘Monitoring’은 어디에 문제가 생겼는지 알 수 있지만, ‘Observability’는 무엇이 문제를 일으켰는지 파악하고, 현재 시스템 상태가 최종 사용자에게 어떤 영향을 주고 있는지 알게 되는 것
좀 더 구체적으로 설명하자면
- Monitoring : 어떤 것이 문제인지 이미 정립되어 있다. 특정 지표나 이벤트 추적. 사전에 정의된 지표를 사용하여 시스템 상태를 평가하고 일정 수준 이상으로 기준치를 넘을 경우 경고를 발생시키거나 조치를 취하도록 설정한다.
- Observability : 시스템 내부 상태를 이해하기 위해 로그, 추적, 이벤트 등을 한곳에 모아서 분석한다. 정보들의 맥락과 연관성을 파악할 수 있어야 한다. 즉, 복잡한 시스템 내부의 상호작용과 원인 결과를 이해하는데 중점을 둔다.
최근 많은 기업들이 MSA 아키텍처를 도입 하면서 Observability 개념이 점차 부각되었다고 생각합니다. 기존에는 한개 리소스에서 모니터링 및 로그 수집으로 시스템 상태를 파악 할 수 있었습니다. 하지만, MSA로 서비스가 분리됨으로써 리소스 관리 포인트가 늘어났고 종합적으로 살펴볼 수 있는 Observability 필요하지 않았을까 생각합니다.
Observability 기본 구성 요소
Observability를 구성하기 위해서는 3가지 구성 요소가 필요합니다.
- Logs : 로그는 시스템의 이벤트 및 활동에 대한 기록입니다. 로그는 시간, 이벤트 유형, 관련 데이터 등을 기록하여 시스템의 작동 상태를 추적하고 이해하는 데 도움을 줍니다.
- Metric : 지표는 시스템의 상태를 측정하고 모니터링하기 위한 수치적인 값입니다.
- Trace : 트레이스는 시스템 내에서 특정 이벤트의 전체적인 흐름과 연관된 단계들을 추적하는 데 사용됩니다. 주로 분산 시스템에서 사용되며, 여러 컴포넌트 간의 상호작용을 추적하여 복잡한 문제의 원인을 분석하는 데 도움을 줍니다.
이제 Observability에서 전반적으로 알아봤으니 실제 도입한 사례를 알아보겠습니다.
“Full-Stack Observability”를 향한 여정
삼성에서는 RCS(Rich Communication Service) 메세지 서비스를 제공하고 있습니다. 해당 서비스는 MAU가 3100만을 넘을만큼 매우 많은 사용자들이 사용하고있어 Observability 도입이 필요했습니다.
Prometheus 도입
삼성에서는 초기에 Prometheus를 도입했습니다. Prometheus는 시계열 DB(TSDB, Time Series Database)라는 점과 Target Resource 정보를 HTTP Pull 방식으로 정보를 수집해서 불필요한 트래픽을 방지 할 수 있습니다.
하지만 Local Storage로 인한 Metrics 장기 보관에 어려움이있고, Prometheus의 read가 많을 경우 CPU 사용량이 증가하며, Clustering을 지원하지 않아 HA 구성이 어렵다는 단점이 있습니다.
Thanos 도입
이전에 언급한 대로, Prometheus는 우수한 모니터링 시스템이지만 결정적으로 클러스터링 구조를 지원하지 않습니다. 이로 인해 애플리케이션의 확장성과 고가용성에 제한이 생깁니다. 그러나 Thanos의 사이드카(Side Car) 패턴을 이용하면 Prometheus의 한계를 극복할 수 있습니다.
하지만 Thanos 단점은 리소스 사용량이 높을 경우 Scale-Out 되지 않으며, Down Sampling을 위한 보존 주기 및 저장공간 사이즈 등 리소스에 대해서 지속적인 관리가 필요합니다.
AMP(Amazon Managed Service for Prometheus) 도입
Thanos에서는 Scale-Out이 지원되지 않아 삼성에서는 최근 AMP(Amazon Managed Service for Prometheus)를 도입했습니다. AMP를 도입함으로써 리소스 Scale-Out / In 에 따라 운영 지표를 자동으로 확장 및 축소가 가능합니다. 또한 AWS 보안 서비스와 통합되어 데이터에 빠르고 안전하게 접근이 가능함으로써 효율적인 운영이 가능합니다.
마치며
해당 섹션을 통해 Observability에 대한 전반적인 이해를 높이고, 글로벌 서비스에서 어떻게 적용하고 있는지 알 수 있었습니다. 특히 삼성의 경우 Prometheus, Thanos, AMP 순서대로 Observability를 고도화하고 차후 아마존에서 관리하는 OpenTelemetry. 즉, ADOT 방향성도 엿볼 수 있었습니다.
DevOps에서도 OpenTelemetry 도입을 계획하고 있는만큼 개인적으로 차후 업무 진행 시 보다 낮은 허들로 빠르게 실행 할 수 있을거라 기대됩니다.
