[서평] 데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링, 관찰 가능성의 시스템 구축과 문화 확산을 위한 가이드

아마도 클라우나 애플리케이션, 플랫폼 솔루션을 다루거나 관심있는 사람들이라면 2022년부터 관찰가능성(Observability) 얘기를 많이 들었을것이다. 실제 모니터링이나 플랫폼 솔루션, 퍼블릭 클라우드를 사용하는 사용자들이라면 더 많은 정보를 가지고 있을 것이다.

 

실제, 글로벌업체들 중  관찰가능성(Observability) 솔루션 43개에 대한 마켓포지션은 아래 그림처럼 다이나트레이스, IBM, 데이타독, New Relic등이 앞서가고 있다는 평가이다.(출처: g2.com)

 

마침 한빛미디어에서 “ 데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링” 이라는 책을 통해  관찰가능성(Observability) 에 대한 내용을 깊이 이해할 수 있는 기회가 되어 공유해 본다.

 

 

목차는 다음과 같다.

 

PART 1 관찰 가능성으로 가는 길

 

chapter 1 관찰 가능성이란?

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

chapter 3 관찰 가능성 없이 확장하며 배운 교훈

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

 

PART 2 관찰 가능성 기초

chapter 5 정형화된 이벤트: 관찰 가능성의 기본 구성 요소

chapter 6 이벤트를 추적으로 연결하기

chapter 7 Opentelemetry를 이용한 계측

chapter 8 관찰 가능성 확보를 위한 이벤트 분석

chapter 9 관찰 가능성과 모니터링의 공존

 

PART 3 팀을 위한 관찰 가능성

chapter 10 관찰 가능성 사례 적용하기

chapter 11 관찰 가능성 주도 개발

chapter 12 신뢰성을 위한 SLO의 활용

chapter 13 SLO 기반 알람 대응과 디버깅

chapter 14 관찰 가능성과 소프트웨어 공급망

 

PART 4 규모에 맞는 관찰 가능성 시스템 구축

chapter 15 투자 회수 관점에서 본 구축과 구매

chapter 16 효율적인 데이터 스토리지

chapter 17 샘플링: 비용과 정확성 모두를 위한 선택

chapter 18 파이프라인을 이용한 원격 측정 관리

 

PART 5 관찰 가능성 문화의 확산

chapter 19 관찰 가능성 비즈니스 사례

chapter 20 관찰 가능성의 이해관계자와 조력자

chapter 21 관찰 가능성 성숙도 모델

chapter 22 관찰 가능성의 미래

 

개인적으로는 관찰가능성이 모니터링과의 차이점을 이해할 수 있도록 설명했던 Part1과 최근 국내 엔지니어들이 많이 사용하는 Opentelemetry를 설명한 Chatper7, 그리고, 이번에 처음 알게된 SLO을 이해하고 이를 기반으로 예산부문까지도 파악할 수 있었던 Chatper 12, 13, 그리고, 슬랙의 실사례를 통해 이해를 도왔던 Chapter14, ROI 측면의 이해를 하게 된 chatper15장도 좋았다. 아무래도 관찰가능성(Observability)에 대해서 처음 접하다보니 전체적인 이해측면에서 골고루 도움이 되긴 하였다.

 

만약, 관찰가능성(Observability) 관련 일을 하고 있고, 비지니스를 고려한다면 Part4가 조금더 도움이 될 것이고, 실제 현장에서 DeoOps나 Platform 엔지니어, 또는 개발자라면 Part2와 Part3가 도움이 될 것이다. 

 

앞서 목차관련 언급 중 인상 깊었던 부분들 중에 일부는 정리해보았다.

 

1. ‘관찰가능성(Observability)' 정의

• 시스템의 상태가 얼마나 새롭고 이상한지와 관계없이 그 상태를 얼마나 잘 이해하고 설명할 수 있는 지를 측정하는 척도
• 현대적인 소프트웨어 시스템에서의 관찰 가능성은 사람들이 어떻게 상호 작용하는지와 동시에 복잡한 시스템을 이해하는 것으로 사람과 기술사이의 상호 작용을 식별하고 어떻게 복잡한 시스템이 함께 동작하는지를 이해할 수 있어야 한다.
• 높은 카디널리티와 높은 디멘셔널리티에 대해 쿼리할 수 있도록 특별히 설계되고, 탐색 가능성을 지원할 수 있도록 도구화 되어 있어야함

2. “왜 지금 관찰 가능성인가"

• 하드웨어와 소프트웨어 코드 사이의 간극을 이애하기 위한 최선의 방식이었던 기존의 모니터링 접근 방법은 마이크로서비스 아키텍처와 같은 다양한 복잡성을 갖는 현대의 분산시스템 구조에 맞지 않음
• 컨테이너 오케스트레이션 플랫폼의 부상, 마이크로서비스로의 전환, 폴리글랏 퍼시스턴스, 서비스 메시의 도입, 인스턴스 오토스케일링, 서버리스 컴퓨팅, 람다, SaaS기반 애플리케이션 도구 등 서비스 아키텍처와 네트워크 아키텍처, 클라우드 네이티브 시스템 구조의 복잡도 증가

* 모니터링의 한계

모니터링과 메트릭 기반 도구의 한계	현대적 시스템의 실제 상황
모놀리식 애플리케이션 하나의 데이터 저장소 상주메모리, CPU평균 부하와 같은 저수준 시스템 메트릭만 사용  컨테이너, 가상머신(VM), 베어메탈서버 기반의 애플리케이션 코드 디버깅을 위한 주요 정보의 원천인 시스템 메트릭과 계측된 메트릭 정적이면서 오랫동안 실행되는 노드, 컨테이너, 호스트 모니터링 문제 발생 이후에만 시스템 분석을 수행하는 엔지니어 운영자 필요에 의해 제공되는 대시보드와 원격측정 정보  블랙박스 애플리케이션 형태로 로컬 애플리케이션을 검사하는 방식의 모니터링 가동시간과 실패예방 주안점인 모니터링 매우 제한적이거나 매우 적은수의 디멘션 사이에서만 이뤄지는 상관관계 검사	많은 서비스로 구성되는 애플리케이션 폴리글랏 퍼시스턴스 방식 역동적이며 탄력적인 용량 관리가 되는 인프라 스트럭쳐 구조 광범위하면서도 느슨한 연결 구조이면서 통제범위 밖에 있는 서비스들 작인 이슈라도 빠른 발견과 사용자에게 영향을 주지않도록 프러덕션 호나경에 배포된 코드가 만드는 변화를 지속 관찰해야 하는 엔지니어 자동 계측만으로는 복잡한 시스템내에서 발생하는 일을 완전히 이해하기 충분하지 않은 구조 프로덕션 환경에서 운영중인 자신의 코드, 미리 코드를 계측하고 배포시 발생할 수 있는 성능 변화를 면밀히 살피는 엔지니어들 오류예산, 서비스 품질, 사용자 경험과 같은 요소를 통해 사용자 영향을 최소화하는 탄력성을 구축하면서 성능 저하를 허용하는 신뢰성 수많은 디멘션이 일어나는 상관관계 분석

• 카디널리티(Cardinality)

: 한 집합에 포함된 데이터 값의 고유성

: 낮은 카디널리티는 열의 데이터값 집합에 중복된 값이 많다는 것 의미

: 높은 카디널리티는 열의 데이터값 집합에 고유한 값들이 많다는 것 의미

• 디멘션널리티(Deimentionality)

: 데이터의 키 개수에 관한 것

데이터가 많은 디멘션을 갖고 있을수록 애플리케이션 동작에 숨겨져 있거나 파악하기 어려운 패턴을 찾을수 있는 가능성이 높아짐

3. 관찰가능성의 중요성

• 문제 해결 속도 증가: 시스템의 내부 상태를 쉽게 파악할 수 있으므로, 문제 발생 시 원인을 신속하게 찾고 해결할 수 있다.
• 성능 최적화: 메트릭스를 통해 성능 문제를 조기에 감지하고, 최적화할 수 있다.
• 신뢰성 향상: 시스템의 상태를 지속적으로 모니터링하고, 문제가 발생하기 전에 예방 조치를 취할 수 있다.
• 비즈니스 연속성 보장: 시스템 장애로 인한 비즈니스 손실을 최소화하고, 안정적인 서비스 운영을 유지할 수 있다.

** SLO(Service-Level Objectives) 사용자 경험을 신뢰할 수 있는 지표를 활용해 서비스 가용성 측면에 합의된 계량화된 목표 설정. 서비스지표(SLI:Service-Level Indicators):시간 기반 측정과 이벤트 기반의 측정 증상 기반의 알람으로 사용자가 영향 받고 있거나 조치해야 하는 것에 대하여 알림 장애인지와 별개로 모든 문제의 원인 파악을 위한 대응이 가능할 수 있도록 관찰 가능성 필요. 즉, 프러덕션 시스템이 충분히 디버깅 가능한 상태여야 함.

특히, SLO를 이용한 예산의 추이(?) 예측을 통해 TCO/ROI를 추적하는 부분은 매우 인상적이었다.

 

4. 관찰가능성(Observability) 도구와 기술

• 로그 관리 도구: ELK 스택(Elasticsearch, Logstash, Kibana), Splunk
• 메트릭스 수집 및 모니터링 도구: Prometheus, Grafana, Datadog
• 분산 추적 도구: Jaeger, Zipkin, OpenTelemetry

5.  관찰가능성의 ROI분석 방법

• 자체 구축 비용

• 무료 소프트웨어 사용의 숨겨진 비용: 오픈소스 사용시 엔지니어 비용
• 장점: 합리적 비용, 내부 전문가 양성, 경쟁 우위
• 단점: 제품 관리 전문 지식 및 역량과 관련된 위험, 내부 전문가 필요, 기회 비용, 지속적인 지원과 유지보수 필요

• 상용 소프트웨어 실제 도입 비용

• 숨겨진 재무적 비용: 좌석당, 호스트당, 서비스당, 쿼리당 등의 종량 과금 가격 체계 / 미래 사용량에 대한 예측 불가능성 
• 숨겨진 비재무적 비용: 시간, 공급업체 락인, 
• 장점: 짧은 구축 시간, 간소화, 공급업체의 소프트웨어 유지보수와 지원
• 단점: 책임 전가, 내부 전문성 결여

 

6. 적용 사례

• 슬랙

 

 

이 그림은 슬랙이 2019년도에 발생한 느린 시스템 처리속도 유발하는 깃의 대용량파일스토리지 이슈를 찾아낼때 이러한 형태의 디멘션 조합을 통해서 해결한 것으로 개발자가 깃허브에 코드를 푸쉬한 뒤 시작되는 시험수행을 간단히 도식화한 그림이다. 

 

그리고, DevOps와 AIops와의 상관관계에 대한 이해가 필요하여 좀 더 찾아보았다.

** DevOps와의 상관관계 DevOps는 개발(Development)과 운영(Operations)을 결합하여 소프트웨어 개발 및 배포 프로세스를 자동화하고, 협업을 촉진하는 방법론입니다. DevOps와 관찰가능성의 상관관계는 다음과 같습니다: 지속적 모니터링: DevOps에서는 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인을 통해 지속적인 소프트웨어 배포가 이루어집니다. 이 과정에서 관찰가능성은 시스템의 상태를 모니터링하고, 배포 후 발생할 수 있는 문제를 빠르게 감지하고 해결하는 데 도움을 줍니다. 빠른 피드백 루프: 관찰가능성은 시스템에서 발생하는 다양한 이벤트와 메트릭스를 실시간으로 제공하여, 개발팀과 운영팀이 신속하게 피드백을 받을 수 있도록 합니다. 이를 통해 빠른 문제 해결과 지속적인 개선이 가능합니다. 자동화와 통합: 관찰가능성 도구는 DevOps 파이프라인과 통합되어 로그, 메트릭스, 트레이싱 데이터를 자동으로 수집하고 분석합니다. 이는 DevOps 환경에서의 자동화 수준을 높이고, 운영 효율성을 극대화합니다.

**AIops와의 상관관계 AIops는 AI(Artificial Intelligence)를 활용하여 IT 운영을 자동화하고, 문제를 예측 및 해결하는 접근 방식이다. 데이터 기반 예측: AIops는 관찰가능성을 통해 수집된 로그, 메트릭스, 트레이싱 데이터를 분석하여 시스템의 이상 징후를 조기에 감지하고, 잠재적인 문제를 예측합니다. 이는 운영 효율성을 높이고, 시스템 장애를 미리 방지할 수 있다. 자동화된 문제 해결: AIops는 머신러닝 알고리즘을 사용하여 반복적인 문제 해결 과정을 자동화한다. 관찰가능성을 통해 수집된 데이터를 기반으로, AIops는 문제 발생 시 자동으로 대응하고 해결책을 실행한다. 인사이트 제공: AIops는 관찰가능성 데이터를 분석하여 시스템 성능 및 안정성에 대한 인사이트를 제공한다. 이를 통해 운영팀은 시스템을 최적화하고, 성능 병목 현상을 제거할 수 있다.

 

마지막으로, 각 챕처가 끝날때마다 요약이 있어서 한번더 정리하는데 좋았다. 다만, 편집 측면에서 서술형보다는 단답형으로 했으면 어땠을까 하는 아쉬움이 있다.

이번에도 새로운 내용을 배울 수 있게 해 준 한빛미디어에 감사하다.

* 이 글은  "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."