관찰 가능성은 복잡한 최신 시스템의 소프트웨어를 구축, 수정, 이해하는 데 매우 중요합니다. 관찰 가능성을 채택한 팀은 코드를 신속하고 자신 있게 배포할 수 있으며, 이상값과 비정상적인 동작을 식별하고, 모든 사용자의 경험을 훨씬 더 잘 이해할 수 있습니다.
이 책은 관찰 가능성의 개념과 중요성을 설명하며, 현대 소프트웨어 시스템 관리에서 왜 관찰 가능성이 필요한지를 다룹니다. 또한, 관찰 가능성과 모니터링의 차이점을 분석하고 각 접근 방식의 장단점을 비교합니다. OpenTelemetry와 같은 도구를 사용하여 관찰 가능성 시스템을 구현하고 데이터 기반 문제 해결 방법을 소개하며, 실제 사례에 어떻게 적용되는지도 알아봅니다. 마지막으로 관찰 가능성을 조직에 도입하고 확산시키는 사회적, 문화적 접근 방법에 대해 다룹니다.
관찰 가능성을 대규모 소프트웨어 관리에 적용하는 방법
복잡한 클라우드 네이티브 애플리케이션 및 시스템에서의 관찰 가능성 적용
관찰 가능성이 전체 소프트웨어 개발 생애주기에 미치는 영향
서비스 수준 목표(SLO)에 따른 관찰 가능성 활용 방법
문맥 기반의 시스템 디버깅과 유지 보수를 위한 고품질 코드를 생성하는 방법
풍부한 데이터 분석을 통해 해결하기 어려운 이슈를 디버깅하는 방법
저자소개
저자
채리티 메이저
허니컴의 공동 창립자이자 CTO이면서 『데이터베이스 신뢰성 엔지니어링』(에이콘, 2023)의 공동 저자이기도 합니다. 이전에는 Parse, 페이스북, Linden Lab 등에서 시스템 엔지니어, 엔지니어링 매니저로 근무했습니다.
저자
리즈 퐁 존스
개발자 애드보킷과 사이트 신뢰성 엔지니어로 업계에서 17년 이상 근무한 베테랑입니다. 허니컴에서 SRE와 관찰 가능성 커뮤니티의 애드보킷으로 활동 중입니다.
저자
조지 미란다
시스템 엔지니어였지만 현재는 허니컴에서 제품 마케터이자 시장 마케팅 전략 리더로 활동하고 있습니다. 15년 이상 금융 업계와 비디오 게임 업계에서 대규모 분산 시스템을 구축하는 일을 해왔습니다.
역자
노승헌
눈물 없이 볼 수 없는 한 편의 뮤직비디오 같은 인생을 만드느라 바쁜 센티멘털리스트. 삼성네트웍스, SK텔레콤, 아카마이 코리아를 거치면서 개발자, 프로젝트 매니저, 제품 오너, 솔루션 아키텍트 등 다양한 영역에서 자신을 시험해보고 있다. 현재는 라인플러스 Enablement Engineering 팀에서 LINE의 다양한 서비스가 쾌적한 사용자 경험을 제공할 수 있도록 이슈를 관찰하고 문제를 해결하는 역할을 수행하고 있다. 집필한 도서로 『나는 LINE 개발자입니다』(한빛미디어, 2019, 공저), 『슬랙으로 협업하기』(위키북스, 2017), 『소셜 네트워크로 세상을 바꾼 사람들』(길벗, 2013), 번역한 도서는 『데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링』(한빛미디어, 2024), 『관찰가능성 엔지니어링』(한빛미디어, 2023) 등이 있습니다.
chapter 1 관찰 가능성이란? _1.1 관찰 가능성의 수학적 정의 _1.2 소프트웨어 시스템에 대한 관찰 가능성 적용 _1.3 소프트웨어를 위한 관찰 가능성에 대한 잘못된 특성화 _1.4 왜 지금 관찰 가능성인가? __1.4.1 이것이 정말 최선의 방법인가? __1.4.2 메트릭과 모니터링이 충분하지 않은 이유 _1.5 메트릭을 이용한 디버깅과 관찰 가능성을 이용한 디버깅 __1.5.1 카디널리티의 역할 __1.5.2 디멘셔널리티의 역할 _1.6 관찰 가능성을 이용한 디버깅 _1.7 현대적인 시스템을 위한 관찰 가능성 요약
chapter 2 관찰 가능성과 모니터링의 디버깅은 어떻게 다를까? _2.1 모니터링 데이터를 활용한 디버깅 __2.1.1 대시보드를 이용한 문제 해결 __2.1.2 직관을 통한 문제 해결의 한계 __2.1.3 사후 대응적일 수밖에 없는 기존 모니터링 _2.2 관찰 가능성을 통한 더 나은 디버깅 요약
chapter 3 관찰 가능성 없이 확장하며 배운 교훈 _3.1 메타가 인수한 MBaaS 기업 Parse _3.2 Parse에서 경험했던 확장성 _3.3 현대적 시스템으로의 진화 _3.4 현대적 관행으로의 진화 _3.5 Parse의 전환 사례 요약
chapter 4 관찰 가능성은 어떻게 데브옵스, Sre, 클라우드 네이티브를 연결하는가 _4.1 클라우드 네이티브, 데브옵스, SRE에 대한 간단한 소개 _4.2 관찰 가능성: 디버깅의 과거와 오늘 _4.3 관찰 가능성을 통한 데브옵스와 SRE 프랙티스의 강화 요약
PART 2 관찰 가능성 기초
chapter 5 정형화된 이벤트: 관찰 가능성의 기본 구성 요소 _5.1 정형화된 이벤트를 이용한 디버깅 _5.2 메트릭을 기본 구성 요소로 사용하기 어려운 이유 _5.3 기존 로그를 기본 구성 요소로 사용하기 어려운 이유 __5.3.1 비정형 로그 __5.3.2 정형화된 로그 _5.4 디버깅 시 유용한 이벤트 속성 요약
chapter 6 이벤트를 추적으로 연결하기 _6.1 분산 추적이란 무엇이고 왜 중요한가? _6.2 추적을 구성하는 컴포넌트 _6.3 어렵게 추적 계측하기 _6.4 추적 스팬에 사용자 정의 필드 추가하기 _6.5 이벤트를 추적으로 연결하기 요약
chapter 7 Opentelemetry를 이용한 계측 _7.1 계측이란? _7.2 오픈 계측 표준 _7.3 코드를 이용한 계측 __7.3.1 자동 계측 시작하기 __7.3.2 사용자 정의 계측 추가하기 __7.3.3 백엔드 시스템으로 계측 데이터 전송하기 요약
chapter 8 관찰 가능성 확보를 위한 이벤트 분석 _8.1 알려진 조건 기반의 디버깅 _8.2 디버깅의 제1원칙 __8.2.1 핵심 분석 루프 사용하기 __8.2.2 핵심 분석 루프의 무차별 대입 자동화 _8.3 AIOps의 약속에 대한 오해 요약
chapter 9 관찰 가능성과 모니터링의 공존 _9.1 모니터링이 적합한 사례 _9.2 관찰 가능성이 적합한 사례 _9.3 대상 시스템, 소프트웨어에 따른 고려 사항 _9.4 조직의 요구사항 평가 __9.4.1 예외 무시할 수 없는 인프라 모니터링 __9.4.2 실전 예시 요약
PART 3 팀을 위한 관찰 가능성
chapter 10 관찰 가능성 사례 적용하기 _10.1 커뮤니티 그룹 참여하기 _10.2 가장 큰 고민거리에서 시작하기 _10.3 구축보다 구매 _10.4 반복을 통한 계측 구체화 _10.5 기존의 노력을 최대한 활용하기 _10.6 관찰 가능성 적용의 최종 관문 요약
chapter 11 관찰 가능성 주도 개발 _11.1 테스트 주도 개발 _11.2 개발 생애주기 내에서의 관찰 가능성 _11.3 디버그 지점의 결정 _11.4 마이크로서비스 시대의 디버깅 _11.5 계측이 관찰 가능성 도입을 촉진하는 방법 _11.6 관찰 가능성의 조기 투입 _11.7 소프트웨어 배포 가속화를 위한 관찰 가능성 활용 요약
chapter 12 신뢰성을 위한 SLO의 활용 _12.1 전통적 모니터링 접근 방법이 낳은 알람에 대한 피로감 _12.2 알려진 무지만을 위한 임계치 기반의 알람 _12.3 중요한 것은 사용자 경험이다 _12.4 SLO란 무엇인가? __12.4.1 SLO 기반의 신뢰성 있는 알람 __12.4.2 사례 연구: SLO 기반의 알람 문화 변화 요약
chapter 13 SLO 기반 알람 대응과 디버깅 _13.1 오류 예산이 소진되기 전에 경고하기 _13.2 슬라이딩 윈도우를 이용한 시간 범위 설정 _13.3 오류 예산 소진 알람 생성을 위한 예측 __13.3.1 룩어헤드 윈도우 __13.3.2 베이스라인 윈도우 __13.3.3 SLO 소진 알람 대응하기 _13.4 관찰 가능성 데이터와 시계열 데이터를 이용한 SLO 측정의 차이 요약
chapter 14 관찰 가능성과 소프트웨어 공급망 _14.1 슬랙이 관찰 가능성을 도입한 이유 _14.2 계측: 공유 클라이언트 라이브러리와 디멘션 _14.3 사례 연구: 소프트웨어 공급망에 관찰 가능성 적용하기 __14.3.1 도구를 이용한 문맥의 이해 __14.3.2 실행 가능한 알람 내장하기 __14.3.3 변경사항 이해하기 요약
PART 4 규모에 맞는 관찰 가능성 시스템 구축
chapter 15 투자 회수 관점에서 본 구축과 구매 _15.1 관찰 가능성의 ROI 분석 방법 _15.2 자체 구축 비용 __15.2.1 무료 소프트웨어 사용의 숨겨진 비용 __15.2.2 자체 구축의 장점 __15.2.3 자체 구축의 위험성 _15.3 상용 소프트웨어 실제 도입 비용 __15.3.1 상용 소프트웨어 도입의 숨겨진 재무적 비용 __15.3.2 상용 소프트웨어 도입의 숨겨진 비재무적 비용 __15.3.3 상용 소프트웨어 도입의 이점 __15.3.4 상용 소프트웨어 구매의 위험성 _15.4 자체 구축과 상용 소프트웨어 도입은 옳고 그름의 문제가 아니다 요약
chapter 16 효율적인 데이터 스토리지 _16.1 관찰 가능성을 위한 기능적 요구사항 __16.1.1 관찰 가능성에 부적합한 시계열 데이터베이스 __16.1.2 다른 데이터 저장소 후보들 __16.1.3 데이터 스토리지 전략 _16.2 사례 연구: 허니컴 리트리버의 구현 __16.2.1 시간 단위로 데이터 파티셔닝하기 __16.2.2 세그먼트 내에 열별로 데이터 저장하기 __16.2.3 쿼리 작업 수행하기 __16.2.4 추적 쿼리하기 __16.2.5 실시간으로 데이터 쿼리하기 __16.2.6 티어링을 활용한 비용 효율적인 쿼리 처리 __16.2.7 병렬 처리를 통해 빠르게 만들기 __16.2.8 높은 카디널리티 다루기 __16.2.9 확장성과 내구성 전략 __16.2.10 효율적인 자체 데이터 스토어 구축을 위한 고려 사항 요약
chapter 17 샘플링: 비용과 정확성 모두를 위한 선택 _17.1 데이터 수집을 정제하기 위한 샘플링 _17.2 샘플링에 대한 다양한 접근 방법 __17.2.1 고정 확률 샘플링 __17.2.2 최신 트래픽 볼륨 기반의 샘플링 __17.2.3 이벤트 콘텐츠(키) 기반 샘플링 __17.2.4 키, 메서드 조합을 통한 샘플링 __17.2.5 동적 샘플링 옵션 선택 __17.2.6 추적에 대한 샘플링 결정 시점 _17.3 샘플링 전략의 코드화 __17.3.1 기본 시나리오 __17.3.2 고정 비율 샘플링 __17.3.3 샘플링 비율의 기록 __17.3.4 일관성 있는 샘플링 __17.3.5 목표 비율 샘플링 __17.3.6 하나 이상의 정적 샘플링 비율 사용하기 __17.3.7 키와 목표 비율을 이용한 샘플링 __17.3.8 많은 키를 지원하는 동적 비율 샘플링 __17.3.9 여러 가지 샘플링 방법의 동시 적용 요약
chapter 18 파이프라인을 이용한 원격 측정 관리 _18.1 원격 측정 파이프라인의 속성 __18.1.1 라우팅 __18.1.2 보안과 규제 준수 __18.1.3 워크로드의 격리 __18.1.4 데이터 버퍼링 __18.1.5 용량 관리 __18.1.6 데이터 필터링 및 증강 __18.1.7 데이터 변환 __18.1.8 데이터 품질과 일관성 보장 _18.2 원격 측정 파이프라인의 관리 자세히 살펴보기 _18.3 원격 측정 파이프라인 관리 시 당면 과제 __18.3.1 성능 __18.3.2 정확성 __18.3.3 가용성 __18.3.4 신뢰성 __18.3.5 격리 __18.3.6 데이터 신선도 _18.4 사례 연구: 슬랙에서의 원격 측정 관리 __18.4.1 메트릭 집계 __18.4.2 로그와 추적 이벤트 _18.5 오픈소스 대안들 _18.6 원격 측정 파이프라인 관리: 구축할 것인가 구매할 것인가 요약
PART 5 관찰 가능성 문화의 확산
chapter 19 관찰 가능성 비즈니스 사례 _19.1 변화에 대한 사후 대응적인 접근 방법 _19.2 관찰 가능성의 투자 수익률 _19.3 변경에 대한 적극적인 접근 방법 _19.4 사례로서의 관찰 가능성 소개 _19.5 적절한 도구를 이용한 관찰 가능성 실천 __19.5.1 계측 __19.5.2 데이터 저장소와 분석 __19.5.3 도구의 출시 _19.6 충분한 관찰 가능성을 확보했는지 인식하기 요약
chapter 20 관찰 가능성의 이해관계자와 조력자 _20.1 비엔지니어링 관찰 가능성 요구사항의 식별 _20.2 실무에서 관찰 가능성 조력자 만들기 __20.2.1 고객 지원팀 __20.2.2 고객 성공팀과 제품팀 __20.2.3 영업팀과 경영팀 _20.4 관찰 가능성 도구와 비즈니스 인텔리전스 도구의 차이점 __20.4.1 쿼리 실행 시간 __20.4.2 정확도 __20.4.3 최신성 __20.4.4 데이터 구조 __20.4.5 시간 범위 __20.4.6 일시성 _20.5 실무에서 관찰 가능성과 BI 도구 함께 사용하기 요약
chapter 21 관찰 가능성 성숙도 모델 _21.1 성숙도 모델에 대한 기본적인 이해 _21.2 관찰 가능성 성숙도 모델이 필요한 이유 _21.3 관찰 가능성 성숙도 모델 _21.4 관찰 가능성 성숙도 모델의 기능들 __21.4.1 시스템 실패에 대한 탄력성 __21.4.2 완성도 높은 코드의 배포 __21.4.3 소프트웨어 복잡도와 기술 부채의 관리 __21.4.4 예측 가능한 릴리스 __21.4.5 사용자 동작의 이해 _21.5 조직을 위한 관찰 가능성 성숙도 모델 적용 요약
chapter 22 관찰 가능성의 미래 _22.1 관찰 가능성의 과거와 현재 _22.2 보충 자료 _22.3 관찰 가능성의 미래
출판사리뷰
현대 소프트웨어 개발 및 관리의 핵심 전략과 도구
『데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링』은 관찰 가능성이 무엇인지, 관찰 가능한 시스템을 어떻게 식별하는지, 현대적인 소프트웨어 시스템을 관리할 때 관찰 가능성 기반의 디버깅이 적합한 이유를 알아봅니다. 그와 함께 관찰 가능성의 여러 가지 기술적 측면을 살펴보며, 기존 모니터링 체계와의 공존 방법에 대해 다룹니다. 또한 관찰 가능성을 처음 도입할 때 직면하게 되는 어려움과 일하는 방식의 변화 등 다양한 환경에서 겪게 되는 관찰 가능성의 사례와 문제점을 알아봅니다. 마지막으로, 관찰 가능성 문화를 조직에 채택하는 접근 방법을 논의하며, 조직 전반에 걸쳐 관찰 가능성 채택을 위해 이해해야 하는 문화적 메커니즘에 대해 설명합니다.
이 책은 관찰 가능성(observability) 엔지니어링을 주제로 하여, 단순한 모니터링과의 차이점을 심도 있게 탐구한다. 저자는 어떻게 관찰 가능성이 기술적 문제를 해결하고 시스템 이해를 증진시키는 데 중요한 역할을 하는지를 설명합니다. 특히 데이터독(Datadog)과 같은 도구를 사용하여 마이크로서비스와 분산 시스템을 효율적으로 모니터링하는 방법에 대해 설명하면서, 단순한 메트릭스로는 파악하기 어려운 복잡한 문제들을 어떻게 쉽게 발견하고 해결할 수 있는지를 보여준다.
이 책은 데브옵스 엔지니어 뿐만 아니라 백엔드 엔지니어에게도 유용하다. 저자는 이미 구축된 솔루션을 사용하는 것을 권장하지만, Pinpoint와 같은 강력한 무료 툴을 사용하는 방법도 제시한다. 이러한 툴들이 기술적으로 어떻게 작동하는지 이해한다면 사용자는 더 빠르게 적응하고 이를 효율적으로 활용할 수 있게 된다.
책은 신뢰할 수 있고 실행 가능한 알람 설정의 중요성을 강조하며, 이는 독자에게 많은 공감을 불러일으킨다. 전반적으로 이 책은 관찰 가능성의 중요성과 실행에 대한 실질적인 지식을 제공함으로써, 기술 스택을 최적화하려는 모든 개발자에게 필수적인 추천드리는 자료입니다.
이제는 데브옵스라는 직군에 대해서 널리 알려져 있긴 하지만, 불과 몇년전만 하더라도 데브옵스에 대한 정의와 도대체 하는 일이 뭔데? 라는 의견과, '그냥 잡부' 아니야? 라는 시각이 팽팽했었습니다. 마치 올라운드 플레이어 처럼 기업에서는 데브옵스 한명을 팀 단위로 생각하는 곳도 있었다고 합니다.
데브옵스의 정의를 설명하기 전에 모두 철학에 대해 먼저 설명하곤 합니다. AWS 문서에서도 데브옵스의 철학에 대하여 아래와 같이 설명하기도 합니다.
DevOps로 전환하기 위해서는 문화와 사고방식의 변화가 필요합니다. 간단하게 말하자면 DevOps는 기존에 사일로에 묶여 있던 개발과 운영이라는 두 팀 간의 장벽을 없애줍니다. 일부 조직에서는 개발팀과 운영팀이 나뉘어 있지 않고 엔지니어가 두 업무를 모두 수행할 수도 있습니다.
https://aws.amazon.com/ko/devops/what-is-devops/
이 책은 그런 데브옵스 엔지니어를 위하여 "관찰 가능성 엔지니어링"에 대하여 소개합니다
그렇다면 "관찰 가능성" 은 또 데브옵스가 세상에 등장했던 것 처럼 한번에 와닿지 않습니다.
이 책에서 설명하는 것은 " 보통 실제 사용자 환경에서 소프트웨어가 어떻게 동작하는지를 더 잘 이해하는 것에 중점을 두고 있다" 라고 합니다. 단순히 모니터링이나 시스템 원격 측정이 아닌 소프트웨어 시스템의 특성을 더 잘 이해하는 것에 중점을 두는 것 입니다.
프로그램이 그냥 잘 돌아가기만 하면 되는거 아닐까?를 넘어, 그보다 더 잘 돌아가게 하기 위한 여정이 이 책의 시작이라고 할 수 있겠습니다. 그렇기 때문에 이 책은 "이것이 정말 최선의 방법인가?"에 대해 독자에게 문제를 던집니다.
그리고 이를 위하여 이제는 대세가 된 오픈 텔레메트리 역시 개념적으로 잘 설명해주고 있습니다.
이 책은 관찰가능성이 단순한 모니터링을 넘어서서 시스템의 내부 상태를 깊이 이해할 수 있게 하는 개념임을 명확히 설명합니다. 물론 처음 접하는 사람에게는 어려운 개념과 철학적 접근이 다소 생소할 수도 있습니다. 하지만 나는 '데브옵스' 의 길을 걷는 사람들에게는 훌륭한 지침서가 되어줄 것이라 생각 됩니다.
이 책은 현대 소프트웨어 개발과 운영 환경에서 날로 그 중요성이 커지고 있는 '관찰 가능성(Observability)'에 대해 포괄적이고 심도 있게 다루고 있다. 총 5개의 PART로 구성된 이 책은 관찰 가능성의 기본 개념부터 실제 적용 방법, 그리고 조직 문화에 미치는 영향까지 광범위한 내용을 체계적으로 설명하고 있다.
개념의 명확한 정립
관찰 가능성의 개념을 명확히 정의하고, 기존의 모니터링과의 차이점을 상세히 설명하고 있어 관찰 가능성이 왜 현대 소프트웨어 시스템에서 필수적인지를 이해하는데 도움이 된다.
실용적인 접근
OpenTelemetry와 같은 실제 도구를 활용한 구현 방법을 상세히 다루고 있다.
현대적인 소프트웨어 개발 트렌드와의 연계
클라우드 네이티브 환경, 마이크로서비스 아키텍처 등 현대적인 소프트웨어 개발 트렌드와 관찰 가능성의 연관성을 잘 설명하고 있다. 관찰 가능성이 현대 소프트웨어 개발 생태계에서 어떤 역할을 하는지 이해할 수 있다.
데이터 기반 문제 해결 접근법 소개
관찰 가능성을 통해 수집된 데이터를 활용한 문제 해결 방법을 상세히 설명하고 있어 실제 상황에서 데이터를 어떻게 해석하고 활용할 수 있는지에 대한 아이디어를 얻을 수 있다.
SLO 개념
서비스 수준 목표(SLO)와 같은 실용적인 개념을 소개하고, 이를 관찰 가능성과 연계하여 설명하고 있다. 관찰 가능성이 실제 비즈니스 목표와 어떻게 연결되는지 이해하는데 도움이 되었다.
조직 문화와의 연계
관찰 가능성을 조직에 도입하고 확산시키는 방법에 대해 상세히 다루고 있다. 이는 기술적인 측면뿐만 아니라 조직 문화의 변화까지 고려한 포괄적인 접근 방식이다. 새로운 기술이나 방법론 등을 도입할 때는 조직에서 저항이 있을 수 밖에 없는데 이런 부분까지 고려한 점이 좋았다.
사례 연구의 풍부한 활용
Parse, 슬랙, 허니컴과 같은 실제 기업들의 사례를 통해 관찰 가능성의 실제 적용 사례와 그 효과를 통해 실제 기업에서 어떻게 적용되는지에 대해 이해할 수 있어 좋았다.
효율적인 데이터 스토리지, 샘플링 전략
관찰 가능성 시스템의 효율적인 데이터 관리와 처리에 대해 다루고 있다. 데이터 스토리지에 대한 요구사항을 분석하고, 시계열 데이터베이스의 한계점을 설명하며, 허니컴 리트리버 사례를 통해 효율적인 데이터 저장 및 쿼리 전략을 소개한다. 데이터 수집 최적화를 위한 다양한 샘플링 전략을 다루며, 고정 확률, 트래픽 기반, 콘텐츠 기반 등의 접근 방식과 이들의 코드 구현 방법을 설명한다. 원격 측정 파이프라인 관리에 초점을 맞추어, 파이프라인의 주요 속성과 관리 과제를 논의하고, 슬랙의 사례 연구를 통해 실제 적용 사례를 보여준다. 또한 오픈소스 대안과 구축 vs 구매 결정에 대한 고려사항을 제시한다. 이를 통해 대규모 관찰 가능성 시스템 구축에 필요한 핵심 기술적 고려사항들을 알아볼 수 있다.
앞으로의 전망 제시
관찰 가능성의 과거와 현재를 분석하고, 미래의 발전 방향에 대해서도 논의하고 있다. 이는 독자들이 장기적인 관점에서 관찰 가능성을 이해하는 데 도움을 준다.
비즈니스 가치
관찰 가능성이 단순히 기술적인 도구가 아니라 비즈니스에 실질적인 가치를 제공할 수 있음을 강조하고 있다. 기술 결정권자들에게 관찰 가능성 도입의 필요성을 설득하는 데 도움이 될것 같다.
목차. 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. 관찰 가능성의 미래 들어가며. 안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링이라는 책을 리뷰를 해보려고합니다. 필자도 현재 DevOps Engineer로 로 근무한지 꽤 됐습니다. 데브옵스의 범주가 워낙 넓고 각 회사마다의 일하는 문화도 상이한데요. 여러가지 분야가 있겠지만 SRE영역에 관심이 많습니다. SRE는 데브옵스를 구현하여 실제 운영상의 많은 부분 안정화에 기여하는 역할을 한다고 생각하고있습니다.
자연스럽게 서비스 안정화를 고려하다보니 모니터링, 로그 수집, 어플리케이션 성능영역에 관심이 많아졌습니다. 이 책은 필자가 궁금해하던 영역을 모두 해소하게 해주는 책인것 같습니다.
관측 가능성 이란 시스템 내부를 살펴보지 않고도 연관 정보많으로 문제를 예방하고, 문제 발생시에는 손쉽게 유발 원인을 찾아 나갈 수 있도록 보조하는 장칠라고 생각합니다.
그럼 본격적으로 각 장마다의 어떤 이야기를 담고 있는지 서평해보겠습니다.
Part 1. 관찰 가능성으로 가는 길 이 파트에서는 옵저버빌리티에 대한 개념영역이라고 보면 될것 같습니다. 처음 접하는 사람에게는 관찰 가능성이 어떤 의미인지를 알 수 있습니다.
관찰 가능성은 엔지니어가 원격 측정 데이터를 유연한 방법을 통해 자유자재로 다루도록 해줌으로써, 예상치 못한 방식으로 발생한 모든 이슈의 근본적인 원인을 찾을 수 있다라고 되어있습니다.
이 파트에서 카디널리티, 디멘셔널리티에 대해서도 설명을 하고 있습니다.
*카디널리티 : * 데이터베이스에서 카디널리티는 한 집합에 포함된 데이터 값의 고유성을 말합니다. 높은 카디널리티는 완전히 고유한 값들이 열에 많이 포함되어 있다는 것을 의미합니다.
디멘셔널리티 : 디멘셔널리티는 데이터의 키 개수에 관한 것입니다. 어떤 한 데이터에 대해서 시간, 앱, 호스트, 사용자, 엔드포인트, 상태로 정의된 스키마를 예로 들 수 있습니다.
Parse라고 하는 기업사례를 들어가며 관찰 가능성 없이 애플리케이션을 확장하며 배운 교육에 대해서도 기술하고있습니다. 직접적인 사례를 들어 설명하니 좀 더 와 닿는 부분이 있어서 좋았습니다.
Part2. 관찰 가능성 기초 이 파트에서는 기술적인 측면에서 관찰 가능성을 깊이 살펴보고 관찰 가능한 시스템에서 특정 요구사항이 필요한 이유를 세부적으로 기술하고 있습니다.
비정형, 정형 이벤트에 대해서 설명하고, 이러한 데이터 형식은 나중에 분석을 하근ㅇ하게 해주는 원격 측정 정보를 위한 기본 데이터 형식이라는것을 설명합니다.
필자가 특히나 관심있게 본 분산 추적 개념에 대해서도 소개를 합니다. 예제코드까지 첨부되어 설명을 이해하기 쉽게 기술해두었습니다. 그리고 이러한 분산 추적이 가능하게 도와주는 OpenTelemetry라는 라이브러리에 대해서도 소개를 하고 있습니다.
Part3. 팀을 위한 관찰 가능성 1-2파트까지는 관측 가능성의 개념, 기술적 이해 그리고 이슈를 디버깅할 수 있는 패턴에 대해서 기술했다면, 이 파트부터는 여러 조직의 관찰 가능성 도입을 촉진시킬 수 있는 사회적, 문화적 변화에 초점을 맞추어 기술하고있습니다.
관찰 가능성을 처음 도입할 떄 팀이 직면하는 여러가지 공통적인 어려움에 대해서 기술하고있습니다. 막상 이 책이 좋았던 점이 여기에 있습니다. 단순히 옵저버빌리티에 대해서 소개하는 것이 아니라 사례를 기반으로 설명하고있고 실질적인 적용에 대해서 설명을 하고 있습니다.
관찰 가능성을 적용한 이후에는 각 개발자 혹은 운영자 입장에서 일하는 방식의 변화까지도 일으킨다고 기술되어있습니다. 현대 어플리케이션에서는 이러한 내용이 반드시 필요로 하기에 좋은 내용으로 다가왔습니다.
특히 요즘 필자가 관심을 갖고 있는 서비스 수준 목표(SLO) 대해서도 설명을 해주고있습니다. SLO와 SLI에 대한 설명 그리고 Budget을 통한 알림 관리등에 대해서 실제로 적용해볼 만한 내용들이 다수 기재되어있어서 너무 도움이 많이 되었습니다.
Part4. 규모에 맞는 관찰 가능성 시스템 구축 이 파트에서는 관찰 가능성이 성공적으로 채택되어 적절한 규모로 적용되면 무슨일이 일어나는지에 대해서 소개하고있습니다. 관찰 가능성을 위한 솔루션들은 시중에 많이 나와있습니다. 물론 오픈소스로도 제공을 해주고있고 상용툴도 다수 존재합니다.
관찰 가능성 솔루션을 외부에서 구매할 것인지 아니면 직접 구축할 것인지 의사 결정을 내리는 과정에 대해서도 소개가 되어있습니다.
특히나 대규모로 관찰 가능성 시스템을 운영하면 수집되는 모든 정보들을 저장할 저장소를 구성하는 방법도 필요하고 많은 양의 원격 측정 데이터를 관리하는 부담도 있는데 이런부분들에 대해서도 해소할 방법에 대해서 소개가 잘 되어있다고 생각합니다.
Part 5. 관찰 가능성 문화의 확산 관찰 가능성의 이론부터 기술적 이해, 팀을 위한 관찰 가능성 그리고 규모에 맞는 시스템 구축까지 설명이 이어졌습니다. 이 파트에서는 마지막으로 관찰 가능성이란 하나의 기술 혹은 단어가 아닌 그 이상의 의미를 지니고 문화로 이해를 하고있습니다. 이러한 문화가 어떻게 조직내 전파가 될 수 있을지에 대해서 소개하고있습니다.
관찰 가능성의 관행을 채택했을 때의 이점을 소개하며 책의 내용은 마무리 됩니다.
마치며.. 필자가 데브옵스 엔지니어 이면서 동시에 SRE에 대해서 관심이 많아서인지 책의 기본적인 내용들은 무리 없이 읽을 수 있었습니다. 더군다나 사례기반으로 설명이 되어있고 중간 중간 각 기업들에 디테일한 내용까지 섞여있어서 이해하는데 많은 도움이 되었습니다.
다만, 실질적으로 관찰 가능성을 도입하고자 했을 때 명확한 지침이라던지 예시를 좀더 활용했다면 좋았을 것 같다는 생각을 했습니다. 다소 이론적인 부분도 있고 텍스트 위주의 설명이다보니 내용을 잘 모르는 독자에게는 어려움으로 다가갈수도 있다는 생각을 해봤습니다.
책을 모두 읽고 난 뒤에는 관찰 가능성에에 대해서 좀 더 이해할 수 있는 계기가 되었습니다.
본 포스팅은 “한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”
시스템 개발 후 유지보수를 위해 시스템 모니터링을 진행하는데 작년부터 관찰 가능성 모니터링, 관찰 가능성 엔지니어링이라는 이야기를 들어왔고 관련하여 몇권의 책을 읽어 보았는데 이번에 "데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 이라는 책을 읽어 보게 되었습니다.
우선 관찰 가능성 엔지니어링은 데브옵스, 클라우드 프로젝트에서 이야기가 들려오고 있고 적용에 대한 논의를 할 정도로 개발자 및 데브옵스 엔지니어도 알아야 할 사항이 되고 있는것 같습니다.
"데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 은 좀 난이도가 있는 책이라는 생각이 듭니다. 기본적인 용어나 기초적인 지식이 있지 않으면 조금 읽기 어려울 정도로 전문적인 용어 및 사례를 알기 어려울 수 있습니다. 하지만 시스템 개발을 해보았거나 TDD, 시스템 모니터링을 이해한다면 "데브 옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 은 관찰 가능성이 무엇이지 , 어떤 기술 및 컴포넌트가 있는지, 팀에게 어떤 영향을 줄 수 있는지 그리고 관찰 가능성 문화를 위해 무엇을 할 수 있는지를 경험 해 볼수 있습니다.
"데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 책은 5개의 PART에 22개의 CHAPTER로 구성되어 있습니다.
PART1. 관찰 가능성으로 가는길 관찰 가능성이 기본을 배울 수 있는 부분입니다. 관찰 가능성이 무엇이고 기존의 모니터링과 차이점을 설명하며 현재 시스템 운영에서 왜 관찰 가능성을 어떻게 사용하는지 확인할 수 있습니다.
PART2. 관찰 가능성 기초 이벤트를 연결하는 방법, 오픈 소스이자 공급 업체 독립적인 프로젝트인 OpenTelemetry를 배울 수 있으며 관찰가능성과 모니터링중에 어떤것이 현재 업무에 적합한지 확인할 수 있습니다.
PART3. 팀을 위한 관찰 가능성 관찰가능성 주도 개발 및 SLO의 활용 방법을 확인할 수 있습니다. 해당 내용에서는 모니터링의 알림 문제 및 개선 방향도 공부해 볼 수 있었습니다.
PART4. 규모에 맞는 관찰 가능성 시스템 구축 관찰가능성을 위한 기능적 요구사항 및 데이터 스토리지를 확인할 수 있습니다. 특히 해당 내용을 사례연구를 통해 확인할 수 있게 되어 있습니다. (사례연구 : 허니컴 리트리버의 구현)
PART5. 관찰 가능성 문화의 확산 관찰 가능성 이해관계자와 조력자에 대한 이야기와 관찰 가능성 성숙도 모델을 확인할 수 있습니다. 관찰 가능성은 문화이기때문에 다른 부서 및 사람과의 협의와 조력이 있어야 하는데 해당 장에서 관련 이야기를 확인할 수 있고 더 낳은 관찰 가능성을 만들기 위한 성숙도 모델의 기능등을 확인할 수 있습니다.
언급한 내용 말고도 관찰 가능성의 원리 및 기술, 가이드 등을 책 전반에 걸쳐서 확인할 수 있습니다.
"데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 책은 다음과 같은 분들이 읽어보면 좋을 것 같습니다. 1. 모니터링 업무를 진행하는 분 2. 데브업스 업무를 수행하는 분 3. 클라우드 업무를 수행하는 분 4. 여러 시스템의 연계 업무를 수행하는 분
개발 현실도 많이 바뀌었고 여러 시스템이 연계되고 있습니다. 이런 환경에 기존의 모니터링으로는 유지보수 및 문제점 원인을 정확히 확인할 수 없다고 생각합니다. 이런 환경에서 관찰 가능성이 나왔고 이제는 운영에서 관찰 가능성은 꼭 익혀야 하는 기술 및 문화가 아닐까 생각합니다.
관찰 가능성을 공부한다면 "데브옵스 엔지니어를 위한 실전 관찰 가능성 엔지니어링" 책을 읽어 보기를 추천합니다.
아마도 클라우나 애플리케이션, 플랫폼 솔루션을 다루거나 관심있는 사람들이라면 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는 관찰가능성 데이터를 분석하여 시스템 성능 및 안정성에 대한 인사이트를 제공한다. 이를 통해 운영팀은 시스템을 최적화하고, 성능 병목 현상을 제거할 수 있다.
마지막으로, 각 챕처가 끝날때마다 요약이 있어서 한번더 정리하는데 좋았다. 다만, 편집 측면에서 서술형보다는 단답형으로 했으면 어땠을까 하는 아쉬움이 있다.
이번에도 새로운 내용을 배울 수 있게 해 준 한빛미디어에 감사하다.
* 이 글은 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
저는 관찰 가능성을 metric, log, trace로 바라보는 설명으로 이해를 했는데 다른 정의에 대해서도 생각해보게 합니다. OpenTelemetry나 다른 툴을 사용하기 위한 개념 설명이나 관점을 기대하고 있는데 관찰 가능성을 성공적으로 도입하기 위해서 문화적인 과제도 동시에 존재한다는 말이 기억이 남습니다. 더 나은 사용자 경험과 팀을 위한 관찰 가능성에 대해 고민해볼 수 있었습니다.
뒤에는 허니컴 제품 위주의 설명이 다소 있어서 개인적으로 아쉬웠지만 특정 임계치를 기반으로 정상/비정상으로 구분하는 모니터링을 벗어나 로그, 메트릭 등을 어떻게 수집할 것인지 힌트를 얻을 수 있어 좋았습니다.
모니터링을 도입해보고 직접 팀에서 사용해본 경험이 있다면 더 와닿고 도움될 글일 것이라 생각합니다.
OpenTelemetry와 같은 오픈소스 이니셔티브에 대해 학습하면서 관찰 가능한 시스템에서 이슈의 원인을 찾기 위해 데이터 기반의 조사 프로세스를 배울 수 있고, 기존의 모니터링 방식에서 사용되는 직관에 의존한 조사 프로세스와 어떤 차이점이 있는지도 알아볼 수 있다. 또한 관찰 가능성을 기존의 모니터링 체계와 함께 활용하는 방법도 살펴본다.
프로덕션 환경의 소프트웨어를 관리하는 것은 팀플레이와 동일하기 때문에 관찰 가능성을 이용해 팀의 역동성을 높일 방법도 살펴본다. 어떻게 관찰 가능성이 비즈니스 프로세스에 적합한지 살펴보면서 소프트웨어 공급망에 미치는 영향과 숨겨진 위험요소에 대해 배울 수 있다. 또한 서비스 수준 목표를 이용하여 더 효율적인 알람을 발송하는 방법 및 관찰 가능성 데이터를 이용한 알람이 왜 실행 가능하고 디버깅 가능해야 하는지에 대한 기술적인 배경을 살펴볼 수 있다.
관찰 가능성의 의미와 기초부터 실제 팀과 규모에 맞는 관찰 가능성 시스템을 어떻게 구축하는지, 관찰 가능성 문화를 어떻게 만들어 나아가는지 차례대로 상세하게 설명하고 있다. 소프트웨어 엔지니어라면 이 책을 참고하여 팀의 개발 문화를 바꾸어 보는데 큰 도움이 될 것 같다.
책에서는 Observability 와 단순한 Monitoring 에 대한 차이점에 대해 반복적으로 강조한다.
회사에서 데이터독을 사용하면서 편리하게 구성되었다고 생각했던 부분들이 Observability 덕분이라는 점을 깨달았다.
최근에는 모놀리틱 환경보다는 마이크로 서비스와 같이 분산된 서비스를 다루는 환경을 구축하게 되는 경험을 많이 하게 된다.
책에서 강조하듯이 단순한 메트릭 정보들로는 이것이 무엇을 의미하는 지를 파악하고, 어떻게 대처해야 하는 지를 쉽게 알기 힘들다. 특히나 분산 시스템에서 업스트림 서비스에서 우리 서비스에 데이터를 잘못 전송하거나 이상하게 전송하고 있다는 등의 쉽게 파악하기 힘든 오류가 있는 경우는 단순한 메트릭 모니터링으로 잡아내기 굉장히 힘들다.
어떠한 컨텍스트에서 나온 정보인지를 파악하기 쉽도록 Observability 가 구성되어 있다면 개발자의 시간도 아낄 수 있고, 서비스의 문제도 빠르게 해결할 수 있다.
사실 데브옵스 엔지니어를 위한 이라는 제목이기 때문에, 백엔드 엔지니어인 내가 봐야할까? 라는 의문을 가졌었다.
실제로 내가 구축할만한 경우가 없을 뿐더러 책에서도 이미 구축된 솔루션을 사용하는 것을 더 추천하는 느낌이다.
심지어 무료로도 사용할 수 있는 강력한 툴인 Pinpoint 같은 것도 있다.
그럼에도 불구하고 이 책을 봐야하는 이유는 실제로 이런 Observability 관련 툴들이 어떤 원리로 구성되어 있을까를 고민해본다면 그렇지 않은 사람보다 더 쉽게 적응하고 활용할 수 있다고 생각한다.
책 내용은 전반적으로 괜찮은 내용이라고 생각한다. 특히 신뢰성있고 해결 가능한 알람을 주어야 한다는 부분은 많이 공감되었다.
프로덕트 운영을 하다 보면 서비스 품질을 유지하기 위해 항상 모니터링 알람에 신경을 써야 할때가 많다. 그러나 대부분의 모니터링은 사고가 먼저 있고 그로 인한 사후 대응성격의 산출물인 경우가 많다. 하지만 현대의 비즈니스는 복잡한 요구사항을 가지고 있고 그에 따라 서비스 아키텍처도 규모가 커지고 시스템끼리 의존성이 높아진다. 오늘날 이러한 아키텍처는 더이상 모니터링 만으로는 장애를 추적하기 힘들어지고 있다.
이 책은 그래서 기존의 메트릭을 기반으로한 모니터링과 달리 ‘관찰 가능성’이라는 주제를 가지고 모니터링과 관찰 가능성은 무엇이 다른지, 장애 추적을 위해 어떻게 계측을 해야 하는지, 그 성숙도를 어느정도로 가지고 가야 하는지에 대해 설명하고 있다.
우선 전반부에는 관찰 가능성에 대한 개념적 설명이 먼저 나온다. 앞서 설명했듯 모니터링이란 과거의 장애에 대한 사후 대응이며 그로인해 알려진 무지에 대해 찾아낼 수 있도록 특화되어 있다. 또, 직관에 의존하고 그렇기 때문에 예측을 위한 방법이 아니라고 설명한다. 관찰 가능성은 그보다 사용자 경험에 따라 측정하며 알려지지 않은 실패에 대해 발견할수 있도록 특화되어 있다. 높은 카디널리티와 디멘셔널리티를 가지고 질의를 통해 문맥을 파악하고 디버깅을 할 수 있도록 도와준다.
모니터링은 단순히 ‘CPU 사용량 높음’ 또는 ‘/api/order 404 에러’ 등 기존에 알고 있는 문제를 알리는것을 의미한다면 카디널리티를 가지는 관찰 가능성은 ‘서울에서 접속한 사람중 갤럭시를 사용중이며 안드로이드 14를 사용하면서 언어가 한글인데 앱을 수요일에 설치했고 ap-northeast-2 리전에 x5에 접근한 사용자’ 라는 질의를 할 수 있게 된다. 이렇게 되면 다양한 서비스가 처리하는 요청 혹은 추적의 진행상황을 따라갈 수 있게 된다. 그러므로 여러 서비스의 구성요소의 경계를 넘나드는 문제를 진단할수 있는 분산추적을 쉽게 할 수 있게되는 것이다.
따라서 이런 관찰 가능성을 적용하기 위해서는 소규모 어플리케이션, 또는 프로덕트의 작은 모듈 단위 보다는 큰 문제가 발생하는 상황부터 먼저 적용해야 효과가 있다고 한다. 저자는 나아가 개발 초반에 관찰 가능성을 위한 계측을 도입한다면 개발이 진행되면서 전체 프로덕트에 미치는 영향을 쉽게 고려하고 문제를 빠르게 파악할 수 있게 된다고 설명한다.
따라서 이러한 활동들은 SLO (서비스 수준 목표) 를 정하는데도 기반이 된다. 일반적인 메트릭이 아닌 ‘사용자 여정’과 같은 문맥이 있는 상황에서 장애를 예측할 수 있기 때문에 외부 사용자 경험이 받아들이기 힘든 수준까지 떨어지기 전에 문제를 식별하고 고칠수 있도록 한다. 책에서는 이 관찰 가능성을 기반으로 SLO 소진에 대한 시나리오, SLO 구축과 도입 비용, 관찰 가능성을 위한 스토리지 선택 방법, 추적에 대한 샘플링 기법에 대해서도 상세하게 설명한다. 마지막으로 이런 새 기법들이 늘 겪는 문제인 ‘조직에 안착시키기’에 대한 내용도 후반에 소개된다.
책을 읽는 과정에서는 다소 추상적이라고 느꼈는데, 한번 끝까지 읽어보고 나니 메트릭이 아닌 ‘문맥을 찾아 예측한다’는 관점이 나에겐 신선했다. 모놀로식보다 규모가 큰 마이크로 서비스 구성에서 서비스간 경계를 넘어서는 계측을 할 수 있다는점도 신기했다.
