관찰 가능성으로 가는 길

이 문서를 Observability Engineering | 데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링을 공부하면서 내용을 정리한 것입니다.

목차

1. 관찰 가능성이란?

2. 관찰 가능성과 모니터링 디버깅은 어떻게 다를까?

3. 관찰 가능성은 어떻게 데브옵스, SRE, 클라우드 네이티브를 연결하는가?

관찰 가능성이란?

IT 업계에서의 관찰 가능성이란 제공하고 있는 어플리케이션 전반에 대한 범위를 통칭합니다.

기존에는 로그(Log), 매트릭(Metric), 트레이스(Trace)로 구성된 대쉬보드(Dashbaord)와 사후벅 알람 및 조치로 충분했습니다.

이는 분산 시스템이 도입된 현대화된 어플리케이션에서는 문제 예측, 예방, 해결에 도움이 되지 않았습니다. 따라서 높은 카디널리티(High Cardinality), 높은 디멘셔널리티(High Dimensionality), 탐색 가능성(Explorability)을 충족할 필요가 있습니다.

카디널리티(Cardinality), 43p

데이터베이스에서 카디널리티(Cardinality)는 한 집합에 포함된 데이터 값의 고유성을 나타냅니다.

• 낮은 카디널리티는 10의 데이터 값 집합에 중복된 값이 많음을 의미합니다.

• 높은 카디널리티는 10의 데이터 값 집합에 중복된 값이 적음을 타나냅니다.

예를 들어, 고정값과 고유키와 카디널리티의 연관성을 살펴보면 다음과 같습니다.

1. 고정값(e.g. 단일값, 상수)만 가지는 집합은 카디널리티가 높습니다.

2. 고유키(e.g. UUID)를 가지는 집합은 카디널리티가 낮습니다.

이러한 특징에서 보면 로그(Log)는 카디널리티가 높고 매트릭(Metric)은 카디널리티가 낮습니다.

디멘셔널리티(Dimensionality), 44p

데이터베이스에서 디멘셔널리티(Dimensionality)는 데이터가 얼마나 많은 K-차원(K-Dimension)으로 이루어졌는지를 나타냅니다.

예를 들어, 6-디멘션으로 정의된 이벤트 스키마가 있을 때는 더 자세한 세부 분석이 가능해집니다.

1. 시간(Timestamp)

2. 앱(Application)

3. 호스트(Hosts)

4. 사용자(User)

5. 앤드포인트(Endpoint)

6. 상태(Status)

관찰 가능성 도구와 카디널리티 & 디멘셔널리티

관찰 가능성 도구를 사용해서
원격 측정 데이터의 카디널리티 & 디멘셔널리티를 제한하는 대신 다음을 권장하고 있습니다.

1. 발생 가능한 모든 이벤트에 대해서 개발자들이 더 많은 원격 측정 데이터를 수집하자.

2. 해당 요청에 대한 전체 문맥을 전달하여 필요한 시점에 활용할 수 있도록 저장하자.

현대적인 시스템을 위한 관찰 가능성

분산 시스템에서는
예측 가능한 장애모드와 예측 불가능한 장애모드가 있습니다.

예측 불가능한 장애모드는 종종 발생하지만 거의 반복되지 않기 때문에,
아래를 충족시키는 것이 어렵습니다.

1. 프로덕션 어플리케이션의 동작 시관과 신뢰성을 보장한다.

2. 용납할 수 있는 성능 범위 내에서 동작하게 할 책임이 있는 엔지니어링 모니터링 대쉬보드 구성이 어렵다.

따라서 분산 시스템과 같이 현대화된 어플리케이션에 적합한 관찰 가능성을 구축하기 위해는 로그(Log), 매트릭(Metric), 트레이스(Trace)의 접근 방법이 아니라

높은 카디널리티(High Cardinality), 높은 디멘셔널리티(High Dimensionality), 탐색 가능성(Explorability)를 지원할 수 있어야 합니다.

관찰 가능성 ≠ 모니터링 디버깅

프로덕션의 문제를 해결하기 위해 전문 지식을 바탕으로
매트릭과 대시보드를 활용하는 모니터링 기반 디버깅 방법은 소프트웨어 산업에서 일반적으로 통용되는 사실입니다.

하지만 관찰 가능성은 탁월한 식별성을 목적으로
높은 카디널리티(High Cardinality), 높은 디멘셔널리티(High Dimensionality), 탐색 가능성(Explorability)를 사용하여 숨겨진 문제의 근원을 알 수 있게 도와줍니다.

모니터링 데이터를 통한 문제 해결

모니터링 시스템은
사람이 중요하다고 생각한 트렌드(Trand)를 감지하여 이분법(Binary) 사고를 합니다.

이를 위해 시계열 데이터와 이를 저장할 수 있는 시계열 데이터베이스를 사용합니다.

• 시계열 데이터(TSD, Time Series Dataa)

• 시계열 데이터베이스(TSDB, Time Series Database)

이를 일정 기간 집계하여 대시보드를 구성하여 아래와 같은 상황을 감지할 수 있습니다.

• 클러스터 전체의 CPU 사용율이 90%를 초과하는 경우

하지만 이 방법은 클러스터의 어떤 부분이 문제가 되는지와 같이 핵심적인 문제를 알려주지 않습니다. 따라서 CPU 사용율과 같은 매트릭 데이터에 의한 트러블 슈팅은 사후적인 대처방안에 불과합니다.

CPU 사용율이 치솟아야 문제를 알 수 있다는 것은,
CPU 사용율이 낮은 문제가 아닌 상황에서는 이를 감지할 수 없음을 나타냅니다.

대시보드를 통한 문제 해결

모니터링 시스템에서 수집한 데이터를 사람이 보기 좋게 수정한 것이 GUI입니다.

수십 개의 대시보드를 구성하고 이를 이용해서 장애를 감지할 수는 있지만,
실제로 어떤 프로세스가 문제를 일으키는 지는 엔지니어의 직관에 의존합니다.

하지만 직관은 엔지니어가 경험하지 못한 새로운 종류에서는 큰 도움이 되지 못합니다.

모니터링 & 대시보드의 비용 문제

더 세분화된 문제 해결을 위해서 매트릭 수집을 늘리는 것은 선형적으로 비용을 증가시킵니다.

따라서 비용 상의 한계를 고려하면 이런 해결 방법은 금방 한계를 마주합니다.

관찰 가능성은 어떻게 데브옵스, SRE, 클라우드 네이티브를 연결하는가?

관찰 가능성은
데브옵스, SRE, 클라우드 네이티브 변화의 일부이자 결과로 봐야 합니다.

시험 가능성(Testability)와 마찬가지로
관찰 가능성은 시험 가능성을 일회성으로 도입하는 것으로 끝나는 것이 아닌,
지속적인 투자가 필요합니다.

관찰 가능성(Observability)와 시험 가능성(Testability)이 커질수록
개발자 뿐만 아니라 시스템 최종 사용자에게 이점이 생깁니다.

클라우드 네이티브, 데브옵스, SRE에 대한 간단한 소개

1990년대부터 2000년대까지는 모놀리식(Monolithic), 워터풀(Waterfull)가 주류였습니다.

현대 개발팀 & 운영팀은 클라우드 네이티브(Cloud Native)와 애자일(Agile)을 많이 사용합니다.

이러한 방법론적 변화는 아래와 같은 장점을 불러왔습니다.

1. 다른 팀에 영향을 주지 않으면서 새로운 기능들을 자율적으로 출시하도록 서포트

2. 느슨한 결합(Loose Coupling)은 생산성 향상과 수익성 개선처럼 주요한 비즈니스적인 이점 창출

클라우드 네이티브 기술은
탄력적(Resilient)하고 관리 가능(Manageable)하며 관찰 가능한(Observable) 느슨하게 연결된(Loose Coupled) 시스템을 가능하게 해줍니다. 최종적으로 개발 속도를 단축하고 운영 가능성(Operability)을 강화시키려고 합니다.

데브옵스와 SRE는 모두
피드백 루프(Feedback Loops)를 단축하고 정의 및 실행 과정에서 작업 부담을 줄이려고 합니다.

• 데브옵스는 “더 좋게, 더 빠르게, 더 안전하게 그리고 더 행복하게”를 추구합니다.

• SRE는 시스템 엔지니어링과 소프트웨어 기술 세트를 결합하여 수작업 대신 소프트웨어 시스템을 개발함으로써 “복잡한 운영 상의 문제를 해결”합니다.

관찰 가능성: 디버깅의 과거와 오늘

관찰 가능성의 목표는
사람들이 시스템이나 애플리케이션의 내부 상태를 추론하는데 도움이 되는 일종에 자기 성찰을 제공하는 것입니다.

예를 들어,
로그(Log), 매트릭(Metric), 추적(Trace)를 디버깅 시그널로 사용할 수 있습니다.
하지만 관찰 가능성의 목표 자체가 어떻게 달성 되었는가는 중요하지 않습니다.

모놀리식 시스템에서는
상세한 어플리케이션 로그나 시스템 수준의 매트릭(e.g. CPU/Disk Usage)를 조합하여 적절한 관찰 가능성을 확보할 수 있습니다.

클라우드 네이티브에서 정의한 새로운 기술로는
컨테이너, 서비스 매쉬, 마이크로서비스, 불멸 인프라가 있습니다.

• 컨테이너(Container : 애플리케이션을 그 종속성과 함께 패키징하여 일관된 실행 환경을 제공하는 가상화 기술.

• 서비스 매쉬(Service Meshes) : 마이크로 서비스 간의 통신을 관리하고 보안을 강화하는 인프라 계층.

• 마이크로서비스(Microservices) : 독립적으로 배포 및 확장이 가능한 작은 서비스들로 구성된 소프트웨어 아키텍처 스타일.

• 불멸 인프라(Immutable Infrastructure) : 필요 시 자동으로 재배포 및 복구되어 가용성과 안정성을 극대화하는 인프라 구성 방식.

이런 기술들은
가상 머신, 모놀리식과 비교하였을 때 아래와 같은 문제가 생깁니다.

1. 마이크로서비스의 컨테이너 간의 상호 의존성으로 인해, 인지 복합성 증가

2. 컨테이너 재시작 이후 폐기된 일시적 상태 정보

3. 개별적으로 출시된 컴포넌트 사이의 버전 비호환성

비정상적인 이슈를 디버깅하기 위해서 시스템 내부로부터 문제를 감지하고 이해하도록 도와주는 새로운 능력이 필요합니다.

분산 추적(Distributed Tracing)과 같은 도구는
특정한 이벤트가 발생했을 때 시스템 내부의 상태를 포착하도록 해줍니다.

각 이벤트에 대해 키-값 쌍 형태로 여러 개의 문맥(Context) 정보를 추가함으로써
일반적으로는 숨겨져 있어 추론하기 어려웠던 시스템의 모든 부분에서 발생하는 일을 광범위하면서도 풍부하게 볼 수 있습니다.

예를 들어,
분산된 클라우드 네이티브 시스템에서는 여러 호스트 사이에서 발생한 이슈를
로그나 서로 연관성이 없는 시그널을 이용해서 디버깅하기 어렵습니다.

하지만 시그널의 조합을 활용하면,
시스템적으로 비정상적인 동작을 서비스 매트릭의 상위 레벨에서 부터 파고들어 가면서
어떤 호스트가 가장 밀집하게 관계되어 있는지 발견할 수 있을 때까지 반복할 수 있습니다.

즉, 관찰 가능성은 공유 문맥(Shared Context)을 제공하여 시스템의 복잡도와 관계 없이 일관되고 합리적인 방식으로 문제를 디버깅할 수 있게 해줍니다.

관찰 가능성을 통한 데브옵스와 SRE 프랙티스의 강화

프로덕션 시스템을 이해하고 복잡성을 길들이는 것은 데브옵스와 SRE 팀이 해야할 일입니다.
따라서 데브옵스와 SRE 팀이 만들어서 사용하는 시스템의 관찰 가능성을 챙기는 것은 자연스러운 일입니다.

SRE는 SLO와 예산에 따라 서비스를 관리하는데에 중점을 둡니다.

1. SLO(Service Level Objectives)

2. 예산(Error Budget)

원인 중심의 모니터링에서 증상 중심의 모니터링으로 변화하며,
기존의 실제 사례에서 경험한 실패를 설명할 수 있는 능력이 필요합니다.

데브옵스와 SRE 팀은
체계적으로 가설을 세우고 실제 시스템의 실패 상황과 완화 조치를 고민하는데 집중할 수 있습니다. 또한 이 과정들에서 피처 플래깅, 지속적인 검증, 사고 분석과 같은 엔지니어링 기술도 사용합니다.

1. 피처 플래깅(Feature Flagging)
   프로덕션 이전 단계 환경에서 꼼꼼하게 시험할 수 없었떤 기능 조합을 프로덕션에서 테스트할 수 있습니다.

2. 지속적인 검증(Continuous Verification)
   카나리 배포, 블루/그린 배포와 같은 패턴들은 출시 중단 시점을 효과적으로 결정하고
   예상과 다른 시스템 동작의 변화가 새로운 코드 출시의 결과인지 분석하기 위해 필요합니다.

3. 사고 분석(Incident Analysis)
   단순한 장애가 발생했을 때 기술적으로 시스템 내에서 무슨 일이 일어났을지 뿐만 아니라,
   운영자 입장에서 봤을 때 장애 시간 동안 발생했을 것이라고 추정한 일을 포함하여 사회 기술적 시스템에 대한 명확한 모델을 만들어야 합니다.