이 발표 자료는 ‘OpenTelemetry: 분산 시스템 시대의 관측성을 위한 단 하나의 표준’이라는 제목 아래, 클라우드 네이티브 환경에서 데이터 수집과 관측성의 표준을 제시하는 OpenTelemetry의 모든 것을 다루고 있습니다. 핵심 메시지는 다음과 같습니다.

• 전통적인 모니터링의 한계 극복: 기존의 모니터링 방식으로는 현대의 복잡한 분산 시스템, 특히 클라우드 네이티브 환경에서 발생하는 문제의 원인을 파악하고 시스템 전체를 이해하는 데 어려움이 있습니다.
  

• Observability의 중요성 강조: 클라우드 네이티브 환경에서는 시스템의 외부 출력만으로 내부 상태를 파악하는 능력, 즉 관측성(Observability)이 필수적입니다. 이는 문제의 근본 원인을 식별하고 성능을 최적화하며 사용자 경험을 개선하는 데 핵심적인 역할을 합니다.
  

• OpenTelemetry의 표준 역할 제시: OpenTelemetry는 로그(Logs), 메트릭(Metrics), 트레이스(Traces)라는 세 가지 핵심 관측성 요소를 통합적으로 수집하고 표준화하여 복잡한 분산 시스템에서 종합적인 관측성을 제공하는 솔루션입니다. 이를 통해 파편화된 모니터링 도구들을 통합하고 일관된 데이터 수집 방식을 제공함으로써 Observability를 강화합니다.
  

이 자료는 다음과 같은 분들에게 특히 유용하며, 꼭 참고해야 할 이유가 명확합니다.

• 클라우드 네이티브 환경 도입을 고려하는 IT 의사결정자: 마이크로서비스 아키텍처(MSA), 쿠버네티스(Kubernetes)와 같은 클라우드 네이티브 기술 스택으로의 전환을 계획하고 있다면, 기존 모니터링 방식으로는 해결할 수 없는 새로운 과제에 직면하게 됩니다. 이 자료는 클라우드 네이티브 환경의 복잡성을 이해하고, Observability가 왜 필수적인 요소인지 명확하게 제시하여 전략적인 의사결정을 돕습니다.

• MSA 및 쿠버네티스 운영 담당자: 분산 시스템 환경에서 서비스 간의 복잡한 상호작용과 수많은 컴포넌트들을 효과적으로 모니터링하고 문제 발생 시 신속하게 원인을 파악하는 것은 매우 중요합니다. 이 자료는 Observability의 핵심 요소인 로그, 메트릭, 트레이스의 개념을 명확히 설명하고, 이들이 어떻게 상호 보완적으로 작동하여 시스템 상태를 정확하게 파악하게 돕는지 보여줍니다.

• 전통적인 모니터링 방식의 한계를 느끼는 분들: 기존의 서버 및 애플리케이션 모니터링 방식으로는 “왜 이런 문제가 발생했는지”, “전체 시스템에 어떤 영향을 미치는지”와 같은 질문에 답하기 어렵습니다. 이 자료는 이러한 한계를 명확히 지적하고, Observability라는 새로운 접근 방식이 어떻게 이러한 문제들을 해결할 수 있는지 구체적인 예시와 함께 설명합니다.

• OpenTelemetry에 대한 이해가 필요한 개발자 및 아키텍트: Observability 구현의 표준으로 떠오르는 OpenTelemetry에 대한 기본적인 이해는 클라우드 네이티브 애플리케이션 개발 및 운영에 필수적입니다. 이 자료는 OpenTelemetry가 제공하는 통합된 데이터 수집 방식과 표준화의 이점을 설명하며, 실제 도입을 위한 첫 걸음을 떼는 데 도움을 줍니다.
  

결론적으로, 이 자료는 클라우드 네이티브 시대를 맞이하여 시스템의 안정성과 성능을 보장하고, 궁극적으로는 비즈니스 연속성을 확보하기 위한 핵심적인 통찰을 제공합니다. 단순히 기술적인 설명을 넘어, 비즈니스 가치 창출의 관점에서 Observability의 중요성을 강조하고 있기 때문에, 현대 IT 시스템 운영의 방향성을 설정하는 데 큰 도움이 될 것입니다.

먼저 전통적 모니터링의 접근은 CPU·메모리·에러율 같은 개별 지표나 로그 이벤트를 임계치 기반으로 경보하는 데 초점을 맞춥니다. 문제는 마이크로서비스·서버리스·오토스케일링이 일상화된 오늘날, 사건의 원인이 서비스 경계 사이를 넘나드는 호출 경로에 숨어 있다는 점입니다. 동일 증상이더라도 원인 위치와 시간적 상관관계가 매번 달라지는 비결정성 탓에, 단일 지표·로그는 “왜 지금 여기가 느려졌는가”를 설명하기 어렵습니다. 이 간극을 메우기 위해 관측성은 시스템 내부 상태를 외부로 드러나는 신호(telemetry)를 통해 추론 가능하게 만드는 능력으로 정의되고, 그 중심에 분산 트레이싱이 놓입니다. 트레이싱은 요청이 서비스 경계를 건너며 생성하는 스팬(Span)들을 컨텍스트 전파로 연결해 전체 호출 그래프를 복원하므로, 지표·로그로는 놓치던 병목·재시도 루프·다운스트림 지연을 원인-결과 사슬로 파악하게 합니다.

발표 자료는 먼저 전통적인 모니터링 방식의 세 가지 축을 설명합니다.

• 서비스 기동 상태: Health Check, Ping(ICMP), HTTP 등을 통해 서비스나 서버가 동작하는지 확인합니다. 주로 서버 가동/중지 상태나 네트워크 연결 가능성을 확인하는 데 사용됩니다.
• 리소스 건전성: CPU 사용률, 메모리 사용량, 디스크 공간, 네트워크 트래픽 등 리소스 지표를 사전에 정의된 임계값(Threshold)을 기준으로 모니터링하여 이상치 발견 시 경고를 발생시킵니다.
• 로그 파일 모니터링: 오류 로그 및 액세스 로그를 수집하고 분석하며, ‘Error’, ‘Failed’와 같은 키워드 및 패턴 기반 필터링을 통해 이벤트의 세부 정보 및 원인을 분석합니다.

그러나 이러한 전통적인 모니터링 방식은 현대의 복잡한 시스템에서는 다음과 같은 명확한 한계를 가집니다.

• 예상된 이벤트만 탐지: 사전에 정의된 규칙과 임계값 내에서만 이벤트를 감지할 수 있어, 서버 다운, 리소스 고갈과 같은 명시적인 오류는 파악 가능하지만, 미지의 문제나 예상치 못한 현상에는 대응하기 어렵습니다. “알 수 없는 문제를 파악할 수 없음”이 핵심적인 한계입니다.
• 원인 파악의 어려움: 이벤트 발생은 알 수 있지만, “왜 이런 일이 발생했는가?”에 대한 근본 원인 파악은 쉽지 않습니다. 특히 분산 시스템에서는 방대한 양의 로그를 분석해야 하며, 여러 서비스에 걸친 원인 추적은 매우 어렵고 시간이 오래 걸리거나 불가능할 수도 있습니다.
• 시스템 전체 구조 파악의 한계: 수집하는 지표나 로그만으로는 시스템 전체의 구조를 파악하기 어렵습니다. 각 서비스와 구성 요소 간의 연관 관계를 이해하기 힘들기 때문에, 문제가 발생했을 때 전체 시스템에 미치는 영향을 예측하거나 문제의 파급 효과를 파악하기 어렵습니다. “전체 시스템의 그림을 그리지 못함”이 중요한 포인트입니다.

발표 자료는 시스템 아키텍처가 어떻게 변화했는지 시각적으로 보여줍니다. 전통적인 모놀리식 시스템이 몇 개의 계층과 데이터베이스로 구성된 단순한 형태였다면, 클라우드 네이티브 환경에서는 수많은 마이크로서비스와 컨테이너, 서버리스 함수들이 복잡하게 얽혀 상호작용하는 분산 시스템으로 진화했습니다. 이러한 변화는 모니터링에 대한 근본적인 접근 방식의 변화를 요구합니다.

클라우드 네이티브 환경의 특징은 다음과 같습니다.

• 신뢰성 확보를 위한 텔레메트리 필요: 시스템의 복잡도가 증가함에 따라 신뢰성을 유지하기 위해 더 정교한 데이터(텔레메트리)가 필요합니다.
• 다양한 환경에서의 원격 측정: 특정 인프라에 국한되지 않고, 온프레미스, 퍼블릭 클라우드, 엣지 등 다양한 환경에서 원격 측정이 수행되어야 합니다.
• 세밀한 원격 측정 요구: 인스턴스 단위는 물론, 컨테이너나 함수 레벨에서도 세밀한 원격 측정이 요구됩니다.
• 복잡하고 다양한 거래 경로: 사용자 요청이 여러 서비스를 거쳐 처리되는 과정이 복잡하고 다양해져, 엔드-투-엔드(end-to-end) 가시성 확보가 어려워집니다.
• 다양한 데이터 활용 필요: 로그, 메트릭, 분산 추적(Distributed Tracing), 프로파일링 등 다양한 유형의 데이터를 통합적으로 활용하여 시스템을 이해해야 합니다.
• 상시적인 장애 발생 가능성: 복잡성 증가로 인해 장애 발생 가능성이 항상 존재하며, 이를 빠르게 감지하고 해결하는 능력이 중요해집니다.

핵심 메시지: 운영 판단에 필요한 정보를 얻으려면 애플리케이션부터 시스템 레벨까지 전 구간에서 다양한 텔레메트리 확보가 필수적입니다.

발표 자료는 “Observability = observe + capability”로 정의하며, “관측할 수 있는 능력”이라고 설명합니다. 핵심은 서버나 운영 환경에 직접 접속하지 않고, 시스템의 상태를 파악하는 것입니다. 이는 제어 이론에서 시스템의 내부 상태를 외부 출력만으로 추론할 수 있는 능력을 의미하는 ‘관측성’ 개념을 IT 시스템에 적용한 것입니다.

클라우드 네이티브 환경이 복잡하기 때문에 문제 원인을 파악하기 어렵고, 특정 노드의 문제뿐만 아니라 컨테이너 이미지 결함, 비정상적인 POD 동작, 서비스 연결 문제 등 다양한 문제가 발생할 수 있습니다. Observability는 이러한 복잡한 환경에서 시스템의 내부 상태를 외부에서 수집 가능한 데이터를 통해 이해하고 추론하는 능력을 의미합니다.

Observability는 세 가지 핵심 요소가 함께 동작하여 시스템 상태를 얻고 상황을 정확하게 파악합니다. 이를 “텔레메트리(Telemetry)”라고 부르며, 각 요소는 다음과 같습니다.

• 무슨 일이 일어나고 있는지? 에 대한 답을 제공합니다.
• 특정 시간 간격으로 모니터링 정보를 측정하고 통계화한 수치화된 데이터 포인트입니다.
• 예시: CPU 사용률, 메모리 사용량, 요청 처리량, 응답 시간 등.
• 용도: 추세 분석 및 알림 설정에 적합하며, 시스템의 전반적인 상태와 성능 지표를 파악하는 데 사용됩니다.

• 어디서 일어났는지? 에 대한 답을 제공합니다.
• 분산 시스템 전체에 걸친 요청의 흐름을 보여주며, 서비스 간의 호출 관계를 시각적으로 추적하여 호출의 시작부터 끝까지를 한눈에 볼 수 있게 합니다.
• 예시: 사용자 요청이 여러 마이크로서비스를 거쳐 최종 응답까지 도달하는 전체 경로.
• 용도: 서비스 간 호출 경로, 병목 현상 및 지연 식별, 엔드-투-엔드 성능 분석에 유용합니다. 트레이스는 여러 ‘Span’들의 묶음으로, 각 Span은 처리의 단위(예: 특정 함수 호출, DB 쿼리)를 나타냅니다.

• 무슨 일이 있었는지? 에 대한 답을 제공합니다.
• 시스템 내에서 발생한 이벤트를 타임스탬프와 함께 기록한 것입니다.
• 예시: 오류 메시지, 스택 트레이스, 상세한 컨텍스트 정보.
• 용도: 사후 분석에 유용하며, 특정 시점에 발생한 이벤트의 상세한 상황과 원인을 파악하는 데 사용됩니다.

이 세 가지 요소는 개별적으로도 중요하지만, 상호 연결될 때 진정한 Observability를 제공합니다. 예를 들어, 메트릭에서 비정상적인 CPU 사용량 증가를 감지하면, 해당 시점의 트레이스를 통해 어떤 서비스가 과도한 리소스를 사용했는지 파악하고, 그 트레이스와 연결된 로그를 통해 상세한 오류 메시지나 스택 트레이스를 확인하여 근본적인 원인을 깊이 있게 파악할 수 있습니다. 발표 자료의 12페이지와 13페이지는 이러한 세 요소의 상호 연결성을 강조하고 있습니다.

발표 자료는 Observability의 3요소를 구현하는 다양한 오픈소스 도구들을 소개합니다.

• Prometheus: 시계열 데이터베이스와 메트릭 수집 시스템.
• Grafana: 수집된 메트릭 데이터를 시각화하는 대시보드 도구.

• Jaeger, Zipkin: 분산 트레이싱을 위한 솔루션.
• EFK: 로그 수집, 저장, 시각화를 위한 스택이지만, 경우에 따라 트레이스 데이터도 처리 가능.

• Grafana Loki: 효율적인 로그 집계 시스템.
• EFK: 로그 관리의 대표적인 스택.

여기서 핵심은 OpenTelemetry입니다. OpenTelemetry는 이러한 파편화된 도구들 앞에서 표준화된 텔레메트리 데이터 수집 및 전송 방식을 제공하여, 특정 벤더나 도구에 종속되지 않고 일관된 Observability를 구축할 수 있도록 돕습니다.

발표 자료는 모니터링과 Observability의 가장 큰 차이점을 ‘불확실성 문제 해결’에서 찾습니다.

• 의존성: 시스템 컨텍스트와 숙련된 엔지니어의 경험에 크게 의존합니다.
• 조사 방식: 분산된 로그 확인, 코드 분석, 로컬 환경에서 재현 등 의존적이고 수동적인 조사 방식을 사용합니다.
• 비용 및 시간: ‘트라이 앤 에러(Try & Error)’ 방식으로 문제 해결에 많은 비용과 시간이 소요됩니다.

• 자동화된 분석: 텔레메트리 데이터를 기반으로 자동화된 분석을 수행합니다.
• 호출 간 관계 시각화: 트레이스를 통해 서비스 호출 간의 관계를 명확히 보여줍니다.
• 코드 레벨 오류 원인 파악: 로그 기반 상세 분석과 연계하여 코드 레벨의 오류 원인까지 파악할 수 있습니다.
• 결과 자동 제공: 에러 발생 시, 분석 도구에서 자동으로 관련 정보를 제공합니다.
• 효율성 증대: 경험 의존도가 낮아지고, 조사 비용과 시간이 크게 감소하여 문제 해결 효율성이 증대됩니다.

발표 자료는 마지막으로 분산 시스템 환경에서 Observability가 왜 필수적인지 다시 한번 강조합니다.

• 기존 시스템: 전통적인 3티어(WEB, WAS, DB)와 같이 비교적 심플한 구성에서는 장애 발생 시 원인을 비교적 용이하게 발견할 수 있습니다.
• 분산 시스템: 마이크로서비스가 느슨하게 결합된 분산 시스템은 구성이 매우 복잡하여 장애가 발생했을 때 발생 위치와 원인을 찾기 어렵습니다. 수많은 서비스 인스턴스 간의 상호작용은 예측 불가능하며, 특정 서비스의 장애가 전체 시스템에 어떤 파급 효과를 미치는지 파악하기 매우 어렵습니다.

이러한 분산 시스템의 복잡성 때문에, Observability의 세 가지 요소(로그, 메트릭, 트레이스)를 통합적으로 활용하여 시스템의 외부 출력만으로 내부 상태를 정확히 파악하고, 문제 발생 시 신속하게 원인을 추적하는 능력이 절대적으로 중요해집니다.

이 발표 자료는 클라우드 네이티브 환경으로의 전환이 가져오는 복잡성에 대한 명확한 이해를 바탕으로, Observability가 단순한 모니터링을 넘어선 필수적인 운영 패러다임임을 강조하고 있습니다. 특히 OpenTelemetry가 이러한 복잡성을 관리하고 시스템 가시성을 확보하는 데 핵심적인 표준 역할을 한다는 점을 이해하시면, 현대 IT 시스템의 설계 및 운영 전략을 수립하는 데 큰 도움이 될 것입니다.

• 오픈텔레메트리(OpenTelemetry)
• OpenTelemetry 란 무엇인가?
• [자료 다운로드] OpenTelemetry란 무엇인가?
• MSAP.ai 웨비나 – MSA 환경에는 왜 Observability가 필수인가