• 원래 영어로 읽었었다.
• [[observability-engineering]]
• 아무래도 번역된걸 읽으면 다른 느낌일수도 있어서 다시 읽는다.

Part 1. 관찰 가능성으로 가는 길

Chatper 1. 관찰 가능성이란?

1.1. 관찰 가능성의 수학적 정의

• 관찰가능성: 외부출력으로부터 시스템 내부의 상태를 얼마나 잘 추론할 수 있는 것인지를 축정하는 것

1.2. 소프트웨어 시스템에 대한 관찰 가능성 적용

• 소프트웨어 어플리케이션이 관찰 가능성을 갖도록 하기 위해 알아햐하는 것:
  • 어플리케이션 내부 동작을 이해해야 한다.
  • 전혀 보지 못했거나, 예상하지 못했던 시스템 상태 등 어플리케이션이 가질 수 있는 시스템 상태를 알고 있어야한다.
  • 코드에 대한 이해 없이 외부 도구를 이용해 관찰하고 쿼리하는 것만으로도 내부 동작 및 시스템 상태를 이해랄 수 있어야 한다.
  • 별도의 코드를 추가하지 않더라도 내부 상태를 이해할수 있어야한다. (코드를 추가해야 내부 상태를 이해할 수 있다면 어플리케이션에 대한 선행지식이 필요하다는 것을 의미한다.)

1.3. 소프트웨어를 위한 관찰 가능성에 대한 잘못된 특성화

• 소프트웨어 시스템이 관찰 가능성을 갖도록 하기 위해 특정한 도구를 채택할 필요는 없다. 하지만, 관찰 가능성을 향상시키기 위해 데이터를 효율적으로 수집하여 문제점을 효과적으로 디버그하는 방법을 발전시켜야한다.

1.4. 왜 지금 관찰가능성인가?

• 기존의 접근방식은 사후 대응적이다.
• 모니터링만으로는 소프트웨어 개발자들의 시스템을 완전히 살펴볼 수 없다.
• 모니터링에서는 개발자들은 성능 임계치를 설정한다. 이는 시간이 지나면서, 임계치에 다가간 수치들을 제거하거나(e.g. 응답시간에 대한 임계치가 100ms 일때, 수치가 90ms 쯤 되면 이를 낮추려고 노력한다.), 임계치를 조정하거나(e.g. 100 ms 였던것을 300ms, 600ms 점점 올린다. 포인트는 이러한 조정이 근거가 떨어지고 감에 의한것들) 쓸데없는 신호들(e.g. 진짜로 특정 API 요청에 대한 응답시간이 유저에게 치명적인가에 대한 고민이 없을수 있다.)에 대해 호들값을 떤다.

1.4.1. 이것이 정말 최선의 방법인가?

• 모니터링 관행은 시스템에 대한 많은 암묵적 가정으로 수행되었다.
• 시스템은 점점 추상적이고 복잡해지면서 내재된 한계에 부딧히게 되었다.

1.4.2 메트릭과 모니터링이 충분하지 않은 경우

• 많은 복잡한 부가 요소들은 메트릭을 기반으로 만들어졌다.:
  • 시계열 데이터베이스와 통계분석,
  • 그래프 라이브러리와 매혹적인 대시보드
  • 온콜 로테이션 체계, 운영팀, 에스컬레이션 정책
• 시스템의 복잡도가 높아짐에 따라, 저수준 명령어로 다시 돌아가게 되었다.
• 현대적 시스템의 실제 상황:
  • 어플리케이션은 많은 서비스로 구성된다.
  • Polypglot persitence 방식(필요에 따라 적절한 데이터베이스와 스토리지를 선택하는 방식)
  • Infra 는 역동적이며 탄력적이다.
  • 광범위하며 느슨하게 연결된 서비스들이 있고, 대부분 통제 범위 밖
  • 엔지니어는 아주 작은 이슈라도 빠르게 수정하고 프로덕션에 배포하여 사용자에게 영향을 주지않으려고 함.
  • 자동계측으로는 복잡한 시스템 내에서 발생하는 일을 완전히 이해하기에 충분하지 않다.
  • 소프트웨어 엔지니어들은 프로덕션 환경에서 운영중인 자신의 코드를 가지고 있으며, 배포시 발생할 수 있는 성능 변화를 미리 계측하고 싶어한다.
  • 신뢰성은 오류 계산, 서비스 품질, 사용자 경험을 복합적으로 고려하며 사용자에게 부정적인 영향을 줄이도록 하고, 이러한 탄력성을 구축하는 동시에 일정하면서도 지속적으로 성능 저하를 허용하는 것에 초점이 맞춰져 있다.:
    • 이게 좀 어렵게 써져있는데,
    • 에러 budget 을 정하고, 이러한 수준까지는 성능 저하를 허용하여서 개발자가 탄력적으로 개발할수 있게하고, 어느 수준이 될 경우에는 이러한 에러를 줄이기 위해서 노력해야한다는 것을 의미하고
    • 신뢰성 측정은 이러한 것에 도움을 줘야한다는 뜻으로 해석된다.
    • 더 자세한건 SRE 책을 참조하자.
  • 수많은 요소들(디멘젼)이 상관관계를 가지며 분석해야한다.

1.5. 메트릭을 이요한 디버깅과 관찰 가능성을 이요한 디버깅

• 직관적인 접근방법은 이전에 겪었던 문제의 변형이거나 연장선 상에 있는 것 같이 예측 가능할 때만 유효한다.
• 현대적인 분산 시스템 아키텍처는 그 누구도 예측할 수 없고 이전에 경험해보지 못했던 새로운 방식으로 실패하는 것으로 악명이 높다.
• 모니터링이 알려진 불확실성에 대한 것이라면, 관찰가능성은 알려지지 않은 불확실성에 대한 것이다.

1.5.1. 카디널리티의 역할

• 메트릭 기반의 도구들은 주어진 합리적인 스케일에서 낮은 카디널리티를 갖는 디멘션만 다룰수 있다.
• 메트릭은 아래 2가지 특성을 가지게 된다.:
  • 조사하는 동안 잠재적인 문제의 근원을 파악하기 위해 반드시 확인되어야만 하는 추가 질문을 결정한다. 즉, 메트릭을 설정하고 문제 재발을 기다려야한다.
  • 둘쨰, 추가 질문을 대답하기 위해서는 또다른 메트릭들이 필요하므로, 모든 새로운 방식에 따라 비용이 선형적으로 증가한다.

1.5.2. 디멘셔널리티의 역할

• 카디널리티: 데이터 값의 고유성
• 디메셔널리티: 데이터의 키 개수에 관한 것

1.6. 관찰 가능성을 이용한 디버깅

• 관찰 가능성 도구들은 높은 카디널리티와 높은 디멘셔널리티에 대해 쿼리할 수 있도록 설계되어 있다.
• 관찰 가능한 시스템의 핵심은 시스템을 개방형 방식으로 계속해서 탐색할 수 있는가 이다.
• 모니터링은 사후 대응적으로 접근한다.
• 엔지니어들은 예측할 수 없는 실패 상황에 대해 강한 반감을 가진다.
• 하드웨어, 인프라 문제는 개발자가 만든 코드나 사용자로 인해 발생한 문제에 비해 상대적으로 간단하다.
• 이러한 점이 모노리식 환경이나 아주 간단한 아키텍쳐를 다루는 사람들조차 모니터링보다 관찰 가능성을 선호하게 되는지를 말한다.

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

• 관찰가능하다: 상태를 이해하기 위해 새로운 코드를 배포하는 일 없이도 시스템의 상태를 이해할 수 있을때
• 예측 불가한 장애 모드는 종종 발생하지만 거의 반복되지 않는다는 특징이 있다.:
  • Available, Reliable, Capable 한 모니터링 대시보드를 만들기가 어렵다.

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

2.1. 모니터링 데이터를 활용한 디버깅

• 메트릭에서는 시스템은 이분법적이다. 알림을 보내냐, 보내지 않느냐.
• 데시보드가 처음 만들어질때는 걱정할 시스템 메트릭이 얼마 없지만, 시간이 지나면서 점점 추가되고, 현대적인 서비스는 하나의 화면에 표기할수 없을 정도로 많은 메트릭을 수집한다.
• 필요한 조건을 정의하여, 디버깅하거나 대시보드를 만들기 위해서 선견지명이 필요하다. 이는 사용자에게 부담이 된다.
• 근본적으로, 메트릭을 이용해 새로운 시스템애 관한 통찰력을 갖는 것은 태생적으로 사후 대응적인 접근이 될 수밖에 없다.
• 이러한 제약사항을 바탕으로 트러블슈팅 하는 것에 너무 익숙해져있다.

2.1.1. 대시보드를 이용한 문제 해결

2.1.2. 직관을 통한 문제 해결의 한계

• 충분하지 않은 상관관계
• 드릴다운 되지 않음
• 도구의 춘추 전국 시대

2.1.3. 사후 대응적일 수 밖에 없는 기존 모니터링

• 프로덕션 환경에서 문제가 발생했을 때, 실제 눈에 보이는 시스템 정보의 조각들로부터 어디를 조사해야 할지를 결정하고 있는가? 아니면 문제점을 찾기 위해 직감을 따르고 잇는가? 혹은 지난번에 문제를 찾아냈던 곳을 들여다보고 있는가?
• 시스템에 대한 전문성과 이전에 발생했던 문제들에 의존하고 잇는가? 문제 분석을 위해 트러블슈팅 도구를 이용할 때 탐색적으로 증거를 찾고 있는가? 아니면 가설을 증명하기 위해 노력하고 있는가?
• 종종 직감에 따라 해결책을 정하고, 그 해결책이 맞는 답인지 확인하기 위해 적용해 보는 경우가 얼마나 많은가? 확인된 가정이 문제의 원인이 아니고 증상 혹은 결과라서 실제 문제는 해결하지 못하는 경우가 있는가?
• 트러블슈팅 도구가 여러분의 의문점에 대해 정확한 답변을 주고 올바른 해결책으로 이끌어 주는가? 아니면 실제로 필요한 답을 얻기 위해 도구가 제시한 해결책을 시스템에 대한 전문성을 바탕으로 원하는 답을 얻기 위해 한 번 더 해석하는가?
• 관찰된 내용 간의 관계를 연결 짓고, 서로 다른 데이터 소스들 사이에 문맥을 전달하기 위해 자신의 의존한 트러블슈팅 도구에서 다른 도구로 전환하는 횟수가 얼마나 되는가?
• 무엇보다도 팀 내의 최고 디버거는 가장 오래한 근무한 사람인가? 이는 시스템에 대한 지식 대부분은 도구와 같이 대중적인 방법에 의한 것이 아니라 개인적인 실무 경험을 바탕으로 얻은 것이라는 것을 알려주는 결정적인 증거이지 않는가?

2.2. 관찰 가능성을 통한 더 나은 디버깅

• 관찰 가능성 도구를 사용하는 팀 내의 최고 디버거는 가장 호기심이 많은 엔지니어이다.
• 디버깅하를 하는 과정에서 메트릭을 보다가 로그러 넘어갈때 문맥을 넘어가야하고, 트레이스를 볼때 또 한번 그래야한다. 이러한 과정에서 사람은 실수를 하게 되고 다수의 데이터소스와 출처를 다루는 것에 어려움을 겪을 수 있다.
• 관찰 가능성 도구는 이러한 문맥을 추출해 하나의 도구에서 제공한다.

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

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

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

• https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
• 클라우드 네이티브: 탄력적이고 관리가능하며, 관찰 가능한 느슨한 연결된 시스템을 가능하게 해준다. 견고한 자동화 기능과 함께 사용하면, 엔지니어는 최소한의 노력만으로도 영향이 큰 변경을 자주 그리고 예측 가능하게 수행할 수 있게 된다.

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

• 클라우드 네이티브에서 언급된 기술:
  • 컨테이너, 서비스 메시, 마이크로서비스, 불변 인프라
• 분산 트레이싱을 이용해 개별 요청의 처리 단계를 나누고 시가고하할 수 있기 때문에 특정 요청의 실행에 영향을 미치는 복잡한 종속 관계만 이해하면 된다.
• 관찰 가능성은, 시스템의 복잡도와 관계 없이 일관되고 합리적인 방식으로 디버깅할 수 있도록 공유문맥을 제공한다.

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

• SLO, error budgets 를 통해서 서비스를 관리하는데 중점을 둔다.

• 원인 중심의 모니터링에서 증상 중심의 모니터링으로 변화한다는 것은 알려진 장애 모드를 나열하는 기존의 접근 방법 대신 실제 사례에서 경험한 실패를 설명할수 있는 능력이 필요하다는 것을 의미한다.

• SRE 는 관찰 가능성, 피쳐 플래깅, 지속적인 검증, 사고 분석과 같은 엔지니어링 기술을 제공한다.

• 카오스 엔지니어링과 지속적인 검증

• 피쳐 플래깅

• 점진적인 출시 패턴

• 사고 분석과 비난하지 않는 회고

Part 2. 관찰 가능성 기초

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

• 예전 방식에서는 메트릭을 만들고, 어떠한 새로운 질문에 대한 답을 찾기 위해 새롭게 미리 사용자 정의 메트릭을 정의해야만 한다.
• 관찰 가능성에서는 상위 수준의 집계된 성능 데이터부터, 개별 요청에서 사용된 원천 데이터까지 시스템을 반복적으로 탐색할 수 있어야한다.
• 정형화된 이벤트를 통해 어떠한 정보든 담을 수 있도록 해야한다.

5.1. 정형화된 이벤트를 이용한 디버깅

• 어떠한 요청을 처리하기 위해, 고유 ID, 변수 값, 헤더, 요청에 포함된 모든 매개 변수, 실행 시간, 호출된 원격 서비스, 원격 서비스 수행에 소요된 시간 혹은 나중에 디버깅할 때 도움이 될 수 있는 문맥에 관한 다른 정보들
• 종류: 런타임 정보, 요청 정보
• 이벤트에 추가할 수 있는 세부 정보의 양에는 사실상 제한이 없어야 한다.

5.2. 메트릭을 기본 구성 요소로 사용하기 어려운 이유

• 메트릭 기반에서는 단서를 제공할수는 있지만, 세부정보를 담기 어렵다.
• 이벤트 기반에서는 더 작은 단위로 분류되고, 다양한 관점을 보여줄 수 있다.
• 사전에 정의된 기간에 대하여 미리 정의한 관계를 수치화한 메트릭은 시스템의 단일 속성에 한정된 좁은 시야의 뷰만을 제공한다. 제약사항이 너무 많다.

5.3. 기존 로그를 기본 구성 요소로 사용하기 어려운 이유

5.3.1. 비정형 로그

• 기존의 로그는 사람이 읽을 수 있도록 만들어졌기 때문에 정형화되어 있지 않았다.
• 현대적인 시스템에서는 로그가 중앙의 집계기로 전달되어 대규모로 구축된 스토리지 백엔드 시스템에 저장된다.
• 로그파서는 정형화되지 않은 수백만 라인의 로그를 검색할 수 있고, 이러한 로그 파서는 로그데이터를 정보의 조각으로 나누고 그룹화를 해야한다.
• 이 과정에서 정형화되지 않은 데이터들이 혼재되어 있다면 파싱이 복잡해진다.

5.3.2. 정형화된 로그

• 각 메시지에 요청 ID 와 같은 공통 필드를 포함시켜두면 좋다.
• Observability 의 목표가 시스템의 내부 상태를 이해하기 위해 이벤트 데이터로부터 여러가지 방법을 이용해 정보를 얻어내는것이니 기계가 읽을 수 있는 형식의 데이터여야 한다.

5.4. 디버깅 시 유용한 이벤트

• 알려져 있거나 예상 가능한 필드뿐만 아니라 임의의 필드 값도 저장할 수 있도록 이벤트의 범위가 넓어야 한다.

요약

• 관찰 가능성의 기본 구성요소는 임의로 확대 가능한 정형화된 이벤트이다.
• 정형화된 이벤트는 충분한 공간(Cardinality 측면)을 가져야한다.
• 메트릭은 하나의 시스템 속성에 대한 하나의 좁은 관점만 제공하고, 미리 정의되어야하기 때문에 기본 구성 요소로 역할을 수행하기 힘들다.
• 비정형 로그는 컴퓨터가 활용하기 어렵다. 정형화된 이벤트를 사용하자.

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

• 분산 추적: 서로 연관된 일련의 이벤트 집합이다.

6.1. 분산 추적이란 무엇이고 왜 중요한가?

• 분산 추적은 어플리케이션을 구성하는 다양한 서비스가 처리하는 단일 요청 혹은 추적의 진행상황을 따라가는 방법이다.
• 구글의 2010 Dapper 에 관환 논문을 발표한 이후 분산추적의 인기가 높아지기 시작했다.:
  • twitter: zipkin
  • uber: jeager
  • honeycomb: lightstep
• 분산 추적은 분산 시스템의 다양한 서비스와 컴포넌트 간의 관계를 명확하게 보여주기 때문에 이용해 볼만한 가치가 있다.

6.2. 추적을 구성하는 컴포넌트

• 워터폴 차트:
  • trace span, root span, parent-child
• 필수 구성요소:
  • trace id
  • span id
  • parent id
  • timestamp
  • duration time
• 있으면 효과적인 tag:
  • service name
  • span name

6.3. 어렵게 추적 계측하기

• 손으로 하나하나 하기
• 이때 W3C와 B3 에서 규정한 표준을 따라야한다.

6.4. 추적 스팬에 사용자 정의 필드 추가하기

6.5. 이벤트를 추적으로 연결하기

• OpenTelemetry 쓰세요

Chapter 7. OpenTelemetry를 이용한 계측

7.1. 계측이란?

7.2. 오픈 계측 표준

• OpenTelemetry

7.3. 코드를 이용한 계측

• OpenTelemetry 개념:
  • API: 개발자가 계측의 세부적인 구현을 신경쓰지 않더라도, 코드를 계측 할 수 있도록 해주는 OTel 라이브러리의 규격이다.
  • SDK: OTel 을 구현하는 컴포넌트로 상태를 추적하고 전송할 데이터를 정리한다.
  • Tracer: 프로세스 내의 Active span 을 추적하는 SDK 의 컴포넌트, span에 attribute, event 를 추가하고 추적 완료 시 span을 종료시킨다.
  • Meter: 프로세스에 대해 보고 가능한 metric 을 주적하는 sdk 컴포넌트이다. 현재 메트릭에 값을 추가하거나 주기적으로 값을 추출한다.
  • Context Propagation: Request 에 포함된 W3C 의 TraceContext 또는 B3M과 같은 문맥을 역질렬화하는 SDK의 필수적인 기능이다. 프로세스 내에서 현재 요청의 문맥이 무엇인지 추적하고, 추적 정보를 새로운 서비스로 전달하기 위해 직렬화한다.
  • Exporter: 메모리에 적재된 Otel 객체를 지정된 저장소로 전달 가능하도록 적절한 형식으로 변환하는 SDK 플러그인이다.
  • Collector: 원격 측적 데이터를 수신 및 처리하여 하나 이상의 지정된 목적지로 전달한다. 일반적으로 프록시 혹은 사이드카로 실행되는 독립적인 바이너리 프로세스 형태이다.

7.3.1. 자동 계측 시작하기

• Go 에서는 명시적인 형식 안정성과 컴파일 타임 설정 사용이 필수이기 때문에 자동 계측을 위한 설정도 명시적이여야한다.
• Java, .Net 은 런타임에 별도로 동작하는 OpenTelemetry Agent 를 연결해 자동 계측을 수행할 수 있다.

7.3.2. 사용자 정의 계측 추가하기

• 추적 스팬의 시작과 끝
  • Otel 에서는 context 라는 용어를 사용할때는 용어의 의미가 혼용되지 않도록 주의해야한다.:
    • 문맥은 서비스의 이벤트와 관련된 사정이나 상황을 일컫는 논리적 용어인 동시에 추적 스팬의 문맥처럼 특정한 형식을 갖는 문맥을 뜻하기도 한다.
• 이벤트에 다양한 필드 추가하기
• 프로세스 범주의 메트릭 기록

7.3.3. 백엔드 시스템으로 계측 데이터 전송하기

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

• 가설 주도 디버깅
• 관찰 가능성 기반의 디버깅은 프로덕션 환경의 코드를 확인하는데 있어 가장 호기심이 많거나 부지런한 사람이 답을 찾을 수 있다는 특징을 갖는다.

8.1. 알려진 조건 기반의 디버깅

• root cause 를 찾고 runbook 을 작성하도록 독려하고, 대시보드 제작을 하게 한다.
• 하지만, 현대 시스템은 동일한 방식으로 두번 실패하는 경우는 드물다. 그리고 만약 그렇다면, 런북이 아닌 자동 복구 가능을 구성하는 것이 더 좋은 수단이다.
• 런북은 다음 스프린트에서 문제가 수정되기 전까지, 다른 엔지니어가 문제를 완화시킬 수 있게 해줄뿐이다.:
  • 발생할 수 있는 모든 시스템 에러와 해결책이 담긴 문서는 금방 outdated 되거나 잘못된 내용을 담게 된다.

8.2. 디버깅의 제1원칙

• 제1원칙: 시스템에 대한 어떠한 가정도 하지 않고, 가설을 만들고 검증하고 무효화해야한다.
• 직감으로 문제 원인을 찾아내는 것은 시스템의 복잡도가 올라가고 가용한 해답의 수가 급증하고 있기 때문에 점차 비실용적인 일이 되어가고 있다.
• 관찰가능성의 진짜 힘은 이슈를 디버깅하기 전에 많은 것을 미리 파악하지 못했어도 괜찮다는 것이다.

8.2.1. 핵심 분석 루프 사용하기

8.2.2. 핵심 분석 루프의 무차별 대입 자동화

• 관찰 가능성 도구는 숫자 처리에 관한 작업 대부분을 자동화할 수 있어야 하지만, 수동으로 핵심 분석 루프를 수행하는 것조차 관찰 가능성의 기본적인 구성 요소 도움 없이는 획득하기 어렵다.

8.3. AIOps 의 약속에 대한 오해

• 복잡한 소프트웨어 성능 이슈의 대부분은 사람만의 힘으로 해결할수 없지만, AIOps를 Silver bullet 으로 여기는 것도 잘못되었다.

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

9.1. 모니터링이 적합한 사례

• 모니터링과 메트릭은 알려진 장애모드에 대한 새로운 조건을 보고하도록 최적화 되어 있다. 즉, Known-Unknwon 을 찾아내도록 설계되어 있다.

9.2. 관찰 가능성이 적합한 사례

• 관찰 가능성 사례는 엔지니어들이 코드를 배포할 때마다 항상 코드를 살펴보고, 프로덕션 환경에서 동작하고 있는 코드를 매일 탐색할 것을 권장한다.

9.3. 대상 시스템, 소프트웨어에 따른 고려사항

• 베어메탈 인프라에서는 시스템과 소프트웨어의 경계가 뚜렷하였으나, 현대적인 시스템에서는 구분이 명확하지 않아졌다.
• 모니터링과 관찰 가능성이라는 접근 방법은 공존 가능하다.

9.4. 조직의 요구사항 평가

• 베어메탈일 경우: 저수준의 하드웨어 성능을 조사해줄수 있는 모니터링 필요
• 인프라를 클라우드 같은 곳에 위탁한 경우: 기존 모니터링 솔루션은 거의 필요 없다.

9.4.1. 무시할수 없는 인프라 모니터링

• CPU 사용률, 메모리 점유율, 디스크 사용량과 같은 고수준의 인프라 메트릭은 물리적인 성능 한계를 나타내는 지표이기 때문에 가치가 있다. 일종의 조기 경보 신호이다.

Part 3. 팀을 위한 관찰 가능성

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

10.1. 커뮤니티 그룹 참여하기

10.2. 가장 큰 고민거리에서 시작하기

• 관찰 가능성 도입을 추진하는 가장 빠른 방법은 프로덕션 서비스에 대한 관리 책임을 맡고 있는 팀의 가장 큰 고민을 해결하는 것이다.
• 이렇게 함으로써 관찰 가능성의 가치를 빠르게 보여주고, 도입을 반대하는 사람들을 제압하고, 추가 지원을 받을 수 있게 될 것이며 더 나아가 관찰 가능성 적용에 탄력을 받을 수 있게 된다.

10.3 구축보다 구매

• 가장 좋은 방법은 OTel 을 사용해서 어플리케이션을 계측한다.
• Prometheus: 메트릭 기반의 한계
• ELK 스택: 로그 저장소와 쿼리 솔루션 제공제 중점:
  • 평문 로그를 기반으로 이슈와 관련 있는 패턴을 분석하고 식별해 내는 것은 로그 기반 솔루션에서는 부담스럽다.
• Jeager: 이벤트 기반의 분산 추적도구
• 관찰 가능성은 높은 디멘셔널리티와 높은 카디널리티 필드를 통해 시스템 상태를 디버깅할 수 있는 능력이 필요하다.
• 관찰 가능성 도입 과정에서 가장 중요한 것은 빠르게 의사 결정을 하고 프로세스 초기에 관찰가능성의 가치를 보여주는 것이다.

10.4. 반복을 통한 계측 구체화

• 온콜 엔지니어가 프로덕션 서비스에서 발생한 문제에 대해 연락 받았을 때, 가장 먼저 해야하는 작업은 새로운 도구를 사용해 문제가 발생한 어플리케이션 영역을 계측하는 것이다.

10.5. 기존의 노력을 최대한 활용하기

• 새로운 기술의 도입을 막는 큰 장벽 중 하나는 매몰 비용에 대한 잘못된 인식 혹은 오류이다.
• 관찰 가능성 이니셔티브를 강화할 수 있는 다른 작업에도 관심을 기울여야 한다.:
  • ELK 스택 전체 혹은 Logstash 를 단독으로 사용하고 있다면 입력 스트림을 두 번째 목적지로도 보내도록 코드 조각을 추가하는 것은 어려운 작업이 아니다. 입력 스트림을 관찰 가능성 도구로 전송한다.
  • 정형화된 로그를 이용하고 있다면 로그 이벤트에 고유 ID 를 추가하여 이벤트가 전체 스택에 전파되는 동안 고유 ID를 유지하도록 한다.
  • OTel 이나 APM 솔루션을 이용한다.
  • 기존 모니터링 대시보드에서 가장 유용했던 쿼리를 참고하여 새로운 관찰 가능성 도구의 대시보드에서 다시 만들어본다.

10.6. 관찰 가능성 적용의 최종 관문

• 관찰가능성을 도입하고, 문제들이 해결되면서 관찰 가능성을 마무리 짓는 것에 대한 우선순위가 자연스럽게 낮아진다.
• 관찰 가능성 도입을 마무리 하기 위해서는 이슈가 발생할때마다 목표를 설정하고, 해커톤같은걸 여는 것을 고려해볼수 있다.

Chapter 11. 관찰 가능성 주도 개발

11.1. 테스트 주도 개발

• TDD 가 강력한 이유는 매번 동일한 방식으로 테스트를 실행하기 때문이다.
• 프로덕션에서는 문제가 발생할때를 대비할 수 있게해주지는 못한다. 결국 소프트웨어 동작은 사용자들과 상호작용하면서 발생하기 때문이다.
• 관찰 가능성은 이러한 버그를 빠르게 찾도록 도와준다.

11.2. 개발 생애주기 내에서의 관찰 가능성

• 관찰 가능성과 더 좋은 소프트웨어 코드를 작성하는 것과 직접적인 관련은 없을수 있지만, 신속한 디버깅을 위해서는 이 두가지를 연결할 수 있어야한다.

11.3. 디버그 지점의 결정

• 관찰 가능성을 처음 접하는 사람들이 자주하는 실수: 매우 상세한 로그를 남긴다.
• 너무 많은 로그는 오히려 비현실적이다. 관찰가능성은 근본적으로 코드의 로직을 디버깅 하는 것이 아니다.
• 관찰 가능성은 시스템 내에서 디버깅해야하는 지점을 좁힌다.:
  • 어떤 컴포넌트, 지연 발생 지점, 데이터 일부에 문제가 생긴 지점, 가장 많은 처리 시간이 소요되는 구간, 대기시간이 균등한지, 문제를 겪고 있는 특정 사용자 그룹이 있는지 등
• 버그 발생 지점을 찾았다면, 관찰가능성이 아닌 디버거나 프로파일러를 사용하여서 해결해야한다.

11.4. 마이크로서비스 시대의 디버깅

• 디버거는 네트워크를 건너는 서비스 간의 호출을 디버깅할수는 없다.

11.5. 계측이 관찰 가능성 도입을 촉진하는 방법

• 관찰 가능성을 잘 활용하기 위해서는 계측이 필수적이다.
• 소프트웨어 엔지니어를 온콜 업무에 투입하여 계측을 계속 보강하는 피드백 루프를 만드는 것이 좋다.:
  • 코드를 배포하는 것과 에러를 감지하는 것의 간극을 줄여야한다.
• 코드 오너십을 부여하기 위해서는 에러 피드백 루프에 들어있어야한다.

11.6. 관찰 가능성의 조기 투입

• 엉망진창의 현실
• 엔지니어는 언제라도 배포하고 변화를 일으킬수 있어야한다.
• 관찰 가능성은 예상치 못한 동작으로 전체 구조가 깨져버릴 수 있다는 두려움을 없애준다.

11.7. 소프트웨어 배포 가속화를 위한 관찰 가능성 활용

• feature flag 나 progressive delivery 같은 배포와 릴리스를 분리해주는 패턴은 새로운 기능을 천천히 프로덕션 확경에 제공되게 해주므로써 엔지니어가 새로운 기능의 성능을 관찰하고 이해할 수 있게 해준다.
• 속도와 품질 사이에는 트레이드 오프가 있다는게 일반적 인식이다. 하지만, 두 관계는 미신일수도 있다. 느리게 움직이는 팀에서는 실패가 더 잦아지는 경향이 있고 복구하는데 필요한 실질적인 시간도 길어진다.
• 인지하지 못하는 이슈(설정 조율, 의도적인 서비스 품질 하락), 점진적인 변경사항 배포에 대한 제어권이 없음 등은 변경을 중지하게 하고 추가 배포를 막는다.
• 엔지니어링 팀이 건강하고 효율적으로 운영되는지를 나타내는 핵심 메트릭은 코드 작성 후 프로덕션 환경까지 배포되는데 얼미나 시간이 걸리는가에 대한 메트릭이다.
• 프로적션 환경에 배포 속도를 높이는 방법:
  • 연관된 변경들을 하나의 머지로 만들어서 하나씩 배포한다. 너무 많은 것들이 한번에 배포되면, 무언가 문제가 생겼을때 원인을 파악하는데 몇 시간 또는 며칠이 소요될수 있다.
  • 경력이 많은 엔지니어를 할당하여 배포 프로세스와 코드에 실질적인 엔지니어링 역량을 쏟아야한다. 배포 파이프라인은 일부 엔지니어나 특정 팀의 소유물이 되어서는 안된다.

Chapter 12. 신뢰성을 위한 SLO 의 활용

12.1. 전통적 모니터링 접근 방법이 낳은 알람에 대한 피로감

• “발생 가능성이 있는” 대상에 대한 측정치를 수집하는 것은 어렵지 않지만, 대응법을 구체적으로 안내하기 어렵고 대응이 필요한지 조차 확실하지 않다. 즉, 의미 있는 알람보다는 오탐일 가능성이 높다.
• 자연스럽게 일탈의 정상화가 일어나게 된다.
• 장애 리뷰 미팅에서는 문제 예방을 위해 알람을 생성하는 경우가 종종 있다. 이는 다음 장애 때 더 많은 알람을 만들어낼 뿐이다.
• 이는 엔지니어가 어떤 알림이 중요하고 어떤 것이 중요하지 않은지를 판단해야하는 부담을 지속적으로 증가 시킨다.

12.2. 알려진 무지만을 위한 임계치 기반의 알람

• 고장은 자동으로 복구되도록 되어야한다.
• 자동으로 고쳐진 고장에 대해서 평일 업무 시간 중에 디버깅해야한다.
• 좋은 알람이란:
  • 사용자 영향을 긴급하게 반응해야하고,
  • 행동을 취할수 있으며
  • 기존에 발견되지 않은 새로운 것이여야하며
  • 기계적인 대응보다는 조사를 통해 원인을 밝혀내야한다
• 알림에 대한 조건:
  • 서비스에 대한 사용자 경험이 낮아진 상태임을 알려주는 신뢰할 수 있는 지표 기반이여야한다.
  • 해결할수 있는 알람이여야한다.

12.3. 중요한 것은 사용자 경험이다.

• 분산 시스템 환경에서 고장은 불가피하다.

12.4. SLO란 무엇인가?

• SLO: service-level objectives

12.4.1. SLO 기반의 신뢰성 있는 알람

• 시간 기반의 SLO: 5분 동안 99p 의 지연시간이 300 ms 이하

• 이벤트 기반의 SLO: 주어진 시간내의 300ms 이내에 처리된 이벤트의 비중

• 시간 기반과 이벤트 기반의 차이: 시간 버킷을 이용해서 미리 집계되었는지

• 기존 모니터링은 원인 기반 접근 방법을 사용하기 때문에, 비정상적인 원인들(#threads, exception count)이 감지되면 사용자가 의도지 창ㄴㅎ은 경험을 하고 있다고 안내한다.

• SLO 기반에서는 알람이 발생한 이후에 새로운 계측을 추가하지 않고도 조사 가능해야한다.

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

13.1. 오류 예산이 소진되기 전에 경고 하기

• error budget 은 허용할수 있는 시스템 불가용성의 최대값
• 효과적인 소진 알람은 미래의 특정 시점에 시스템에 남아 있는 잔여 오류 예산을 예측할 수 있어야한다.

13.2. 슬라이딩 윈도우를 이용한 시간 범위 설정

• 대부분의 SLO의 경우 30일 윈도우를 사용하는 것이 일반적이다.:
  • 너무 짧으면 신뢰성에 대하여 사용자와 엔지니어간 불일치가 생기며, 제품 계획 주기와 잘 맞지 않게 된다.
  • 너무 길면 단기간에 오류예산을 빠르게 소진했더라도 기술적으로 SLO를 준수한것이 되어버리고, 사고가 빠르게 해결되지 않게될수 있다.

13.3. 오류 예산 소진 알람 생성을 위한 예측

• 오류 예산이 완전히 소진된다면?:

  • 새로운 기능 개발 대신 서비스 안정성 확보 업무를 높은 운선순위를 부여한다.

• 팀의 사기를 안정적이고 지속해서 유지하는 데에는 영웅주의보다는 계획과 예측이 더 적절하다.

• 오류 예산 소진율을 추적하고 급격한 변화를 감시해야한다.

• 소진 예상 알람을 이용하기 위해서는 Lookahead window 와 baseline window(or loopback)를 고려해야한다.

13.3.1. Lookahead window

• 예산 소진율 기반의 미래 예측
• 단기 오류 예산 소진 알람
• 문맥 기반의 소진 알람

13.3.2. Baseline window

13.3.3. SLO 소진 알람 대응하기

13.4. 관찰 가능성 데이터와 시계열 데이터를 이용한 SLO 측정의 차이

• SLO 를 위해 시계열 데이터를 사용하는 것은 생각보다 복잡하다.
• 시계열 데이터 보다는 이벤트 데이터를 사용하면 완화 효과를 얻을 수 있다.

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

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

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

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

• 현실에서 DIY 는 구매보다 비용이 더 많이 든다.
• 구매하기로 결정한 이후에도 스스로 해결책을 만들고 싶다는 충동이 생길수 있다.

15.2. 자체 구축 비용

15.2.1. 무료 소프트웨어 사용의 숨겨진 비용

• “맥주처럼 무료인가? 아니면 강아지처럼 자유로운가?”:
  • 맥주는 처음 마실때 비용을 지불해야하지만, 더이상 마시자 않으면 비용이 들지 않는다. 하지만 강아지는 계속 신경쓰고 챙겨야만 잘 키울 수 있다.

15.2.2. 자체 구축의 장점

• 내부의 전문가를 양성할 수 있다.
• 관찰 가능성은 조직에 경쟁 우위를 제공해준다. 조직의 관행과 문화를 반영하면서도 조직의 기존 지식을 적극 활용할 수 있는 솔루션을 개발할 수 있다.
• 비지니스에 적합하도록 커스터마이장할 수 있다.

15.2.3. 자체 구축의 위험성

• 비지니스가 직접 구축한 솔루션이 준비될때까지 여유가 있는가
• 초기 버전의 내부 도구를 만들기 위해서 큰 노력을 기울이지만 한번 만들어진 도구의 지속적인 유지보수 대신 다음 프로젝트를 시도하고, 내부적으로 구축한 솔루션을 포기하는 경우도 종종 생긴다.

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

15.3.1. 상용 소프트웨어 도입의 숨겨진 재무적 비용

• 현재 사용방식에서 발생하고 있는 실제 비용을 확인해야한다.

15.3.2. 상용 소프트웨어 도입의 숨겨진 비재무적 비용

• 시간
• OTel 로 락인을 피하자.

15.3.3. 상용 소프트웨어 도입의 이점

• 해당 분야의 전문가와 그와 관련된 경험을 획득
• 일반적인 오픝소스 솔루션보다 간소화된 사용자 경험

15.3.4. 상용 소프트웨어 구매의 위험성

• 장기적으로 내부적으로 관찰 가능성에 대한 전문성을 키우지 못할수도 있다.

15.4. 자체 구축과 상용 소프트웨어 도입은 옳고 그름의 문제가 아니다.

• 회사에서 직접 구축할 필요가 없는 대부분의 것은 구매하고 꼭 필요한 것들만 직접 구축함으로써 투자 비용을 점진적으로 줄여나가야한다.

개인의견

• 저자가 아무래도 Honeycomb 출신이다보니, 상용 소프트웨어 도입을 권장하는 것같다.
• Datadog, Splunk 와 같은 상용 소프트웨어를 사용해본다면, 실제로는 Metric 도 매우 재한적으로 사용하게 되고, Log, Trace 도 그렇게 된다. 왜냐하면 저장하는 양에 비례하여 비용이 증가하는 플랜이 많은데, 이는 개발자가 소극적으로 Log, Trace 를 저장하게 된다.
• 물론, 자체 구축이라고 이러한 문제가 해결되는 것은 아니다. 하지만, 어느 정도 규모가 있는 회사이고 비지니스에서 이를 기다릴수 있다면 자체 구축하는 것은 나쁜 선택은 아니라고 생각한다. 혹은 하이브리드로 사용하는 것도 좋은 선택이 될 수 있다.
• 지금은 상용 소프트웨어, 오픈소스 상관없이 OTel 을 지원하는 시대가 되었다. OTel 을 통해 개발자들에게는 일관적인 경험을 하게 해주고, 관리자들은 뒤쪽에서 다양한 솔루션을 적절히 사용하는 방향도 좋다고 생각한다.
• 예를 들어, Datadog 은 custom metrics, custom events 에 대해서는 별도의 가격 플랜을 가지고 있고, 이게 좀 사악하다고 생각하는데, OTel 로 수집은 일괄적으로 하고 중간 Pipeline 상에서 Datadog 과 자체 구축한 솔루션(e.g. mimir, loki, tempo, grafana 조합)으로 제공하는것도 좋은 선택이다.:
  • mimir, loki, tempo 를 운영하는 것은 고통스러운 일일수도 있다. 천천히 경험을 쌓을수 있게 부분적으로 도입하여 노하우를 쌓으면서 확장하는게 좋다고 생각한다.

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

16.1. 관찰 가능성을 위한 기능적 요구사항

• 높은 카디널리티와 디멘셔널리티 데이터 분석 가능
• 쿼리 시간 수초 이내
• 내구성과 신뢰성

16.1.1. 관찰 가능성에 부적합한 시계열 데이터베이스

• 제한된 양의 카디널리티와 디멘셔널리티

16.1.2. 다른 데이터 저장소 후보들

• 장기적으로는 SigNoz 처럼 Apache Druid 와 같은 Columnar Store 를 채택해야한다.

16.1.3. 데이터 스토리지 전략

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

• Sampling 을 사용해 Resource consumption 과 Data Fidelity 사이의 트레이드 오프를 찾아야한다.

17.1. 데이터 수집을 정제하기 위한 샘플링

• 대다수의 애플리케이션에서 발생하는 이벤트는 대부분 성공한 이벤트로 사실상 동일하다.
• 관찰 가능성 데이터로 모든 이벤트를 전송하는 것은 분명한 낭비이다.
• 효과적인 디버깅을 위해서는 나쁜 이벤트와 비교할 수 있는 좋은 혹은 정상적으로 성공 처리된 이벤트의 대표적인 샘플이 필요하다.
• 메트릭: 주어진 기간 동안의 모든 이벤트를 시스템 상태에 대한 대략적인 표현으로 축소해버리는 미리 집계된 데이터
• 샘플링: 메트릭과는 다르게 카디널리티를 보존할수 있다. (대표적인 이벤트를 적절히 고르면 된다.)

17.2. 샘플링에 대한 다양한 접근 방법

17.2.1. 고정 확률 샘플링

• 고정 확률 샘플링이 효과적으로 동작하지 않는 경우:
  • 성공한 요청보다 실패한 요청에 대해 더 많은 관심을 갖고 있는 경우
  • 일부 고객이 아주 많은 트래픽을 보내고 있는 상황에서 모든 고객이 좋은 사용자 경험을 하고 있는지 확인하고 싶은 경우
  • 서버에 트래픽이 폭증하더라도 백엔드 분석 시스템이 안정적으로 동작하길 바라는 경우

17.2.2. 최신 트래픽 볼륨 기반의 샘플링

17.2.3. 이벤트 콘텐츠(키) 기반 샘플링

• 이벤트의 특정 필드, 키를 기반으로 샘플링:
  • e.g. HTTP status code, API Endpoint:
    • 오류가 발생한 이벤트가 성공한 이벤트보다 더 중요할 경우
    • 주문 확인 이벤트보다 신규 주문 이벤트가 더 중요하다.
    • 무료 고객의 이벤트보다 유료 고객에게 영향을 줄 수 있는 이벤트가 훨씬 중요하다.

17.2.4. 키, 메서드 조합을 통한 샘플링

• 트래픽의 콘텐츠를 예측하기 어렵다면 인입되는 각 이벤트로부터 키 혹은 여러 키의 조합을 식별한 다음, 각 키에 대한 최근 확인된 트래픽 규모를 바탕으로 동적인 샘플링 비율 조절이 가능하다.

17.2.5. 동적 샘플링 옵션

17.2.6. 추적에 대한 샘플링 결정 시점

• Tail-based sampling:
  • 모든 추적을 수집하기 위해서는 모든 스팬이 버퍼에 먼저 기록되어야 한다. 이는 현실 프로덕션에서는 불가능하다. 따라서 버퍼링 기반의 샘플링 기술은 일반적으로 외부 컬렉터 측의 로직으로 구현하는 경우가 많다.

17.3. 샘플링 전략의 코드화

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

18.1. 원격 측정 파이프라인의 속성

18.1.1. 라우팅

18.1.2. 보안과 규제 준수

• PII(Personally Identifiable Information)
• GDPR(General Data Protection Regulation)

18.1.3. 워크로드의 격리

• 대량의 로그를 만들어내는 어플리케이션과 그렇지 않은 애플리케이션이 서로 영향을 주지 않도록 하고 싶을 수 있다.

18.1.4. 데이터 버퍼링

• 원격 측정 데이터의 규모는 갑작스럽게 큰 폭으로 증가할수 있다.
• 버퍼링이 필수적이며, 슬랙에서는 이를 위해서 Kafka 를 광범위하게 사용하고 있다.

18.1.5. 용량 관리

• 용량 계획이나 비용통제를 위해 원격 측정 정보의 성격이나 분류에 따라 할당량을 지정하고 처리율 제한이나 샘플링 혹은 대기열을 적용하는 경우가 많다.

• 처리율 제한

• 샘플링

• 대기열

18.1.6. 데이터 필터링 및 증강

• 메트릭을 수집할때 엔지니어의 실수로 사용자 ID 나 IP 주소와 같이 높은 카디널리티의 필두가 추가되어 카디널리티 폭발이 일어날수 있다.
• 로그 저장소는 민감한 데이터를 저장하기 위한 목적으로 구축된 것이 아니기 때문에 PII 나 보안 토큰이 포함된 데이터를 필터링하거나 URL을 검사할 필요가 있다.
• 원격 측정 파이프라인은 데이터 필터링 외에도 원격 측정 데이터를 강화하여 수집된 정보의 활용도를 높일 수 있다.

18.1.7. 데이터 변환

• 일반적으로 원격 측정 벡엔드 시스템은 개별적이고 고유한 API를 갖고 있으며 표준 패턴이 없다.

18.1.8 데이터 품질과 일관성 보장

• 데이터 품질을 보장하기 위해 시간값이 현재와 크게 차이가 나는 경우는 데이터를 삭제한다.
• 파이프라인은 로그를 사용하기 위해 다음과 같은 작업을 수행할 수 있다.:
  • 정형화되지 않은 로그로부터 특정한 필드를 추출하여 정형화된 데이터로 변환한다.
  • 개인 식별 정보나 민감한 정보가 포함된 로그데이터를 감지하여 수정하거나 필터링한다.
  • 맥스마인드와 같은 위치 정보 데이터베이스를 이용해 IP주소를 위도, 경도 정보로 변환한다.
  • 데이터가 존재하고 특정한 필드가 특정한 형식을 가졌는지 확인하기 위해 로그 데이터의 스키마를 확인한다.
  • 가치가 낮은 정제되지 않은 로그가 백엔드 시스템으로 전송되지 않도록 필터링한다.

18.2 원격 측정 파이프라인의 관리 자세히보기

18.3. 원격 측정 파이프라인 관리 시 당면 과제

• 성능, 정확성, 신뢰성, 가용성

18.3.1. 성능

• 파이프라인에서 처리하기 버거운 대량의 어플리케이션 로그가 생성되는 경우 로그 파이프라인의 성능이 떨어질 수 있으며 확장이 필요할 수 있다.

18.3.2. 정확성

• 파이프라인은 다양한 컴폰넌트로 구성되어 있기 때문에 파이프라인이 정상적으로 동작하고 있는지 판단하기 어렵다.
• 파이프라인에서 발생하는 오류와 데이터 품질 이슈를 모니터링 해야한다.

18.3.3. 가용성

18.3.4. 신뢰성

• 새로운 버전의 컴포넌트를 배포하는 동안 파이프라인이 일정한 지연시간을 유지하면서도 최대 처리량을 넘지 않도록 유지하는 것은 쉬운 일이 아니다.
• 가용량까지 부하가 차오른 컴포넌트는 전체 파이프라인을 느리게 만드는 병목지점이 될 수 있다.

18.3.5. 격리

• 동일한 클러스터 내에 대규모의 로그와 메트릭을 생성하는 사용자와 그렇지 않은 사용자가 함께 배치되면, 클러스터가 포화되면서 나머지 사용자들까지 가용성 문제를 겪을수 있다.

18.3.6. 데이터 신선도

• 원격 측정 파이프라인은 고성능과 정확성, 신뢰성을 보장하는 것 이외에도 실시간으로 동작할수 있어야한다.
• 프로메테우스 등, 메트릭은 보통 일정한 주기로 수집되어서 데이터의 신선도 측정에 사용할 수 있다.
• logs, traces 등에서는 일정 주기를 갖는 적당한 데이터 소스를 찾기 어렵다.
• 슬랙에서는 로그에 대한 데이터 신선도 측정을 위해 로그 스트림에 분당 N개의 메시지를 전송하도록 비율을 고정한 synthetic log를 추가했다.
• 이러한 synthetic log 는 사용자들의 로그 쿼리 작업이 방해받지 않도록 합성 데이터가 특정한 값을 갖거나 쉽게 필터링될 수 있도록 신경써야한다.

18.4. 사례 연구: 슬랙에서의 원격 측정 관리

18.5. 오픈소스 대안들

• 관찰가능성 초기에는 원격 측정 파이프라인을 구성하기 위한 특별한 도구가 존재하지 않았다.:
  • rsyslog 와 같은 도구를 사용했다.
• 시간이 흐르면서:
  • logging: timber, logstash, filebeat, fluentd, rsylog
  • metric: preometheus, prometheus push gateway, m3 aggregator
  • tracing: refinery

Part 5. 관찰 가능성 문화의 확산

Chapter 19. 관찰 가능성 비지니스 사례

19.1. 변화에 대한 사후 대응적인 접근 방법

• 단순한 시스템에서 발생하는 현상은 아키텍처의 세부적인 사항까지 잘 알고 있는 엔지니어가 원인을 쉽게 추론해 낼 수 있다.
• 사후 대응적으로 움직이는 조직에 근본적인 변화를 도입하는것은 의도치 않은 결과를 초래할 수 있기 때문에 신중해야만 한다. 성급하게 중요한 비지니스 문제를 해결하기 위해 지나치게 단순한 접근 방법을 선택하게 되면 의미 있는 결과물을 만드는 것이 어려워질 수 있다.
• 결국은 시스템을 개선하는 방향으로 결과가 나와야한다. 누군가의 책임이 아니다.
• 시스템에 대한 관찰 가능성이 확보되지 못했을때 발생할 수 있는 시나리오:
  • 내부적으로 버그를 감지하고 해결하기 전에 프로덕션 서비스에서 고객이 치명적인 버그를 발견하고 보고하는 경우
  • 경미한 사고가 발생했을 때 이를 감지하고 복구하는데 너무 많은 시간이 소요되어 종종 장기적인 서비스 장애로 이어지는 경우
  • 문제를 분류하고 살펴보는 것보다 새로운 문제가 쌓이는 속도가 빨라서, 사고 및 버그 해결이 필요한 조사 대상 백로그가 계속 늘어나고 있는 경우
  • 고장에 대한 수정 작업처럼 운영 업무에 투입되는 시간이 새로운 기능을 개발하고 제공하는 데 할애하는 시간보다 큰 경우
  • 지원팀이 확인하고 재현하거나 해결하지 못한 반복적인 성능 저하로 인해 고객의 서비스 만족도가 낮은 경우
  • 엔지니어링팀이 다양한 서비스 상호간의 동작을 파악하는 것과 같이 예상치 못한 대규모의 작업을 처리하느라 새로운 기능의 릴리스가 몇주 또는 몇 달씩 지연되는 경우

19.2. 관찰 가능성의 투자 수익률

• 연구에 따른 관찰 가능성의 이득 네가지 관점:
  • 더 높은 매출 증가
  • 빠른 사고 대응을 통한 비용 절감
  • 장애 회피를 통한 비용 절감
  • 직원 이직 감소를 통한 비용 절감

19.3. 변경에 대한 적극적인 접근 방법

• 시스템에 관찰 가능성을 도입하도록 만드는 초기 비지니스 사례:
  • 관찰 가능성은 기존 모니터링 도구로는 발견하기 힘든 개별 사용자의 이슈를 찾아내는 방법을 제공하여 장애 인지 시간을 줄이게 해주고, 이러한 초기 도입 성과가 증명되고 나면 더 많은 관찰 가능성을 도입할 수 있게 된다.
  • 온콜 업무의 주요 스트레스중 하나인 이슈 판별에 대한 부담이 감소하기 때문에 질적 향상을 체감할 수 있게 된다.
  • 개별 사용자 요청의 성능과 병목 현상의 원인을 이해하는 과정에서 얻을 수 있다. 이를 통해 서비스 최적화를 위한 최선의 방법이 무엇인지를 빠르게 이해할 수 있다.

19.4. 사례로서의 관찰 가능성 소개

• 관찰 가능성의 목표:
  • 엔지니어링팀이 시스템에 대해 개발, 운영, 디버깅 및 보고를 할 수 있게 해주는 것.
• 잘 동작하는 관찰 가능성은 엔지니어들이 프로덕션 환경에서 이슈를 탐지하고 해결하는데 도움이 될 수 있는 질문을 하도록 격려하고 실시간 비지니스 인텔리전스 관련 질문에도 답변을 할수 있게 해준다.
• 팀 간의 핸드오프, 과도한 수작업, 런북, 어림짐작, 비지니스 목표에 영향을 줄 수 있는 시스템 상태에 대한 외부의 관점에 대한 의존성을 없애는데 도움이된다.

19.5. 적절한 도구를이용한 관찰 가능성 실천

19.5.1. 계측

• OpenTelemetry

19.5.2. 데이터 저장소와 분석

• 상용 솔루션:
  • Honeycomb, Lightstep, New Relic, Splunk, Datadog
• 오픈소스:
  • Prometheus, Grafana, Jaeger
  • Cassandra, elasticSearch, M3, InfluxDB
  • ELK

19.5.3. 도구의 출신

19.6. 충분한 관찰 가능성을 확보했는지 인식하기

• 관찰 가능성이 “만족스러운” 수준에 올라 다른 문제에 우선권을 줄 수 있게 되는 시점을 파악하는 것도 쉽지 않다.
• 관찰 가능성은 애플리케이션에 대한 다른 요구사항들과 경쟁관계에 있다.
• 관찰 가능성 없이 맹목적으로 업무를 수행하면, 과도한 재작업이 발견된다.

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

20.1. 비엔지니어링 관찰 가능성 요구사항의 식별

• 관찰 가능성이 지원할 수 있는 비지니스 사례:

  • 새로운 기능 채택 현황에 대한 이해
  • 새로운 고객의 성공적인 제품 사용 트렌드 파악
  • 서비스 상태 페이지를 이용하여 서비스 가용성 정보를 고객과 내부 지원팀에 정확하게 전달
  • 장단기 신뢰성 트렌드의 이해
  • 적극적인 이슈 해결
  • 빠르고 신뢰할 수 있는 방식으로 고객에게 기능 제공

• 조직 전반에 걸쳐 관찰 가능성 채택을 촉진하는 가장 좋은 방법은 관찰 가능성의 도입으로 큰 효용을 얻는 주변 팀을 만나보는 것이다.

20.2. 실무에서 관찰 가능성 조력자 만들기

20.2.1. 고객 지원팀

20.2.2. 고객 성공팀과 제품팀

20.2.3. 영업팀과 경영팀

20.3. ???

20.4. 관찰 가능성 도구와 비지니스 인텔리전스 도구의 차이점

20.4.1. 쿼리 실행 시간

• 관찰 가능성 도구는 짧게는 1초 미만, 길어도 수초 이내에 쿼리를 수행할 수 있을 정도로 빠르게 동작해야한다.
• 관찰 가능성의 핵심 원칙은 탐색 가능성
• BI는 보고서를 실행하거나 반복적으로 사용되는 복잡한 쿼리 작성에 최적화

20.4.2. 정확도

• 반복 조사가 필요한 경우 1분동안 100% 데이터를 스켄하는 것 대신 1초간 99.5%의 결과를 스캔하는 것이 더 좋다.
• BI 도구와 비지니스 데이터 웨어하우스는 샘플링이나 거의 정확한 접근 방법은 모두 금지되어있다.

20.4.3. 최신성

• 관찰 가능성 도구는 최신성에 강한 편향이 있다.
• BI 도구는 데이터를 처리하는데 시간이 더 걸리는 것은 보통 문제되지 않는다.

20.4.4. 데이터 구조

• 관찰 가능성 워크로드의 스키마느 사후에 추론되어야하고 새로운 디멘션을 보내거나 기존 디멘션의 전송을 중지함으로 변경할수 있어야한다.
• BI 도구는 구조회되지 않은 데이터를 정형화하고 쿼리 가능한 형태로 바꾼다. BI 데이터 웨어하우스는 정형화된 스키마나 사전에 정의된 스키마 없이는 통제하기 어려운 혼란에 빠질 수 있다.

20.4.5. 시간 범위

• 관찰가능성은 추적은 초단위, 길어야 분단위
• BI 는 장기적인 처리가 필요하거나 완료까지는 짧게는 며칠 길게는 몇 주가 걸릴 수도 있다.

20.4.6. 일시성

• 디버깅 데이터는 본질적으로 비지니스 데이터에 비해 일시적일 수 밖에 없다.

20.5. 실무에서 관찰 가능성과 BI 도구 함께 사용하기

• BI 도구는 다양한 형태, 주단위 월단위
• BI는 집계된 메트릭에 의존하기 때문에
• 관찰 가능성 도구는 엔지니어와 경영진까지 이해할수 있는 수준으로 서비스나 API 같은 수준에서 데이터를 확인한다.

Chapter 21. 관찰 가능성 성숙도 모델

21.1 성숙도 모델에 대한 기본적인 이해

• 성숙도 모델은 조직의 관행을 모델링하고 목표를 평가할때도 도움이 된다.
• 단, 성숙도 모델은 모든 조직에 일률적으로 적용할수는 없다.
• 지속적으로 개선해야한다.

21.2. 관찰 가능성 성숙도 모델이 필요한 이유

• 소프트웨어의 개발 및 운영과 관련하여 엔지니어링팀이 높은 생산성을 갖도록 하는 방법이 공식적으로 문서화되어 있는 경우는 많지 않다.
• 관찰 가능성을 적용했을 때 프로덕션 환경과 상호작용 하는 것에 대한 자신감이 증가하고, 새로운 제품 기능의 개발에도 더 많은 시간을 할애할수 있게 되는 것 같은 경향이 나타났다.

21.3. 관찰 가능성 성숙도 모델

• 엔지니어링 조직의 목표:
  • 지속 가능한 시스템과 삶의 질
  • 고객 만족도 증대를 통한 비지니스 요구사항 대응

21.4. 관찰 가능성 성숙도 모델의 기능들

• ‘완료’ 지점은 없다.
• 실용적인 관점에서 봤을때 문화로서 자리잡고 시스템적으로 지원되기 시작했다면 성숙도의 상위 수준에 도달했다는 좋은 신호라고 생각해도 무방하다.

21.4.1. 시스템 실패에 대한 탄력성

• 탄력성: 지원하는 시스템에 대해 서비스를 복구하고 사용자 영향을 최소화하려는 적응 능력

• 긴급 대응은 확장 가능하고 신뢰성 있는 서비스를 위해 필수적이다.

• 팀이 잘하고 있다면:

  • 시스템 가동시간이 비지니스 목표에 부합하며 지속적으로 개선되고 있다.
  • 알람에 대한 온콜 대응은 효율적으로 동작하며, 발생한 알람이 무시되지 않는다.
  • 온콜 담당자가 과도하게 스트레스 받지 않고, 필요한 경우 엔지니어는 추가 교대 근무를 수행하기도 한다.
  • 엔지니어들이 추가 근무를 하거나 과도하게 스트레스 받지 않으면서 사고를 처리할 수 있다.

• 팀이 일을 잘 못하고 있다면:

  • 온콜 순환 업무를 위해 많은 추가 시간과 비용이 지출된다.
  • 사고가 자주 발생하고 장기화된다.
  • 온콜 담당자가 알람 피로에 시달리거나 실제 고장에 대한 알람을 받지 못한다.
  • 사고 대응 인력이 이슈 진단에 어려움을 겪는다.
  • 일부 팀 구성원들이 과도하게 비상 상황에 투입된다.

• 관찰 가능성과의 관계:

  • 알람으로 인한 피로도를 줄이려면 알람은 관련성이 높고, 집중적이면서도 실행가능한 것이여야 한다.
  • 오류 예산과 고객의 요구사항 사이에는 명확한 관계가 존재해야한다.
  • 사고가 발생했을때 상황을 설명해줄수 있는 이벶트가 제공되면, 사고 담당자가 효과적으로 문제를 해결할 수 있어야한다.
  • 아주 높은 카디널리티의 데이터를 조사하고 즉석에서 빠르게 결과를 집계하하여 오류 원인을 정확하게 파악할 수 있어야한다.

21.4.2. 완성도 높은 코드의 배포

• 코드의 가독성이나 기존의 검증 기술도 유용하지만, 실제 프로덕션의 혼란스러운 조건에서는 아무런 검증도 하지 못한다.

• 코드의 품질은 고객과 비지니스에 중요한 영향을 끼치는 운영과 확장성을 검증하는 방식으로 측정되어야 한다.

• 팀이 일을 잘하고 있다면:

  • 코드는 안정적이고 프로덕션 환경에서 버그가 거의 발견되지 않으면서 장애가 적게 발생한다.
  • 팀은 코드가 프로뎍ㅅ션 환경에 배포된 후 지원보다는 고객 솔루션에 초점을 맞춘다.
  • 엔지니어는 코드의 생애주기(개발부터 프로덕션 릴리스까지)동안 시점에 관계없이 발견한 문제점을 디버깅하는 것이 직관적이라는 것을 알게 된다.
  • 발생한 이슈는 격리되어 연쇄적인 실패를 촉발하지 않으면서도 수정될 수 있다.

• 팀이 일을 잘 못하고 있다면:

  • 고객 지원에 많은 비용이 소모된다.
  • 엔지니어링 시간의 상당 부분이 새로운 기능 개발이 아니라 버그 수정에 투입되고 있다.
  • 배포로 인한 위험 부담으로 새로운 기능의 배포를 꺼리는 경우가 많다.
  • 이슈를 식별하거나 실패 사례를 재현하고 수정하는 데 너무 오랜 시간이 소소요된다.
  • 개발자들이 릴리스 된 코드의 안정성에 대해 자신감이 없다.

• 관찰 가능성과의 관계:

  • 코드를 모니터링하고 추적하면 언제 어떻게 프로세스가 실패하는지 쉽게 볼수 있다.
  • 고품질의 관찰 가능성은 여러대의 서버에서도 동일한 도구를 이용하여 디버깅할수 있게 해준다.

21.4.3. 소프트웨어 복잡도와 기술 부채의 관리

• 팀이 일을 잘하고 있다면:

  • 엔지니어는 업무 시간의 대부분을 핵심 비지니스 목표를 진척시키는데 사용한다.
  • 버그 수정이나 다른 사후 대응적인 작업에는 팀 전체 시간의 일부분만을 사용한다.
  • 엔지니어는 코드의 어느 부분을 수정해야하는지 찾지 못하고 헤매느라 시간을 낭비하지 않는다.

• 팀이 일을 잘 못하고 있다면:

  • 확장 제한에 걸리거나 예상치 못한 상황을 만났을 때 코드와 시스템을 재구축하느라 엔지니어링 시간을 낭비한다.
  • 팀이 잘못된 것을 고치거나 무언가를 수정하기 위해 잘못된 방법을 선택함으로써 주의가 산만해진다.
  • 엔지니어가 국지적인 변경으로부터 종종 통제하기 어려운 파급효과를 경험한다.
  • 엔지니어들은 소위 유령의 묘지(= 어떤 일이 발생할지는 잘 모르겠고 위험을 감수하고 싶지 않아 아무도 손대지 않는 것)라 불리는 효과로 인해 코드 변경을 두려워 한다.

• 관찰 가능성과의 관계:

  • 시간 낭비 없이 시스템의 종단 간 성능을 이해하고 실패와 성능 저하를 디버깅할 수 있게 해준다.
  • 이슈를 처리하는 엔지니어는 시스템의 알려지지 않은 부분을 탐색할때 관찰가능성을 통해 올바른 경로를 쉽게 찾을 수 있어야한다.

21.4.4. 예측 가능한 릴리스

• 팀이 일을 잘하고 있다면:

  • 릴리스 주기가 비지니스 요구사항과 고객의 기대를 충족한다.
  • 코드 작성 후 빠르게 프로덕션 환경에 배포된다. 엔지니어는 작성한 코드에 대한 코드리뷰가 완료되고 제어 조건을 만족하면 체크인 후 직접 배포할 수 있다.
  • 배포 없이도 특정한 코드 경로를 활성화하거나 비활성화할 수 있다.
  • 배포와 롤백이 빠르다.

• 팀이 일을 잘 못하고 있다면:

  • 간헐적으로 릴리스될 뿐만 아니라 릴리스 시 사람의 개입이 많이 필요하다.
  • 한번에 많은 변경 사항들이 배포된다.
  • 릴리스는 특정한 순서로 이루어져야만 한다.
  • 영업팀이 특정 릴리스 계획에 관여하여 기능 릴리스에 대한 약속을 통제해야만 한다.
  • 특정한 날짜나 시간에는 배포하지 않는다. 제대로 관리되지 않는 릴리스 주기로 인해 업무 외 시간의 삶의 질이 떨어지기 때문이다.

• 관찰 가능성과의 관계:

  • 빌드 및 릴리스하는 과정에 관찰 가능성을 통해 빌드 및 릴리스하는 과정에 발생하는 에러나 시험 도중 발생하는 성능 저하를 확인할 수 있다.

• 이전 빌드ID와 새로운 빌드ID를 구분하여 나란히 분석할 수 있게 해준다.

• 배포 간 일관성 있고 원할하게 프로덕션 성능이 제공되고 있는지 검증하거나 새로운 코드가 의도된 동작을 하는지를 살펴볼 수 있다.

21.4.5. 사용자 동작의 이해

• 팀이 일을 잘하고 있다면:

  • 계측을 쉽게 추가하거나 증강할 수 있다.
  • 개발자가 고객 성과와 시스템 활용/비용에 대한 핵심 성과 지표에 쉽게 접근할 수 있고 나란히 시각화할 수 있다.
  • 피쳐 플래그 혹은 비슷한 기능을 이용해 기능의 완전한 릴리스 전에 소규모 사용자를 대상으로 빠르고 반복적으로 기능을 제공할 수 있다.
  • 프로덕트 매니저는 사용자 피드백과 행동에 관한 유용한 뷰를 얻을 수 있다.
  • 제품의 시장 적합성을 쉽게 달성할 수 있다.

• 팀이 일을 잘 못하고 있다면:

  • 프로덕트 매니저가 다음에 진행해야할 일에 관한 의사결정에 필요한 충분한 데이터를 확보하지 못한다.
  • 개발자들은 자신의 직업이 고객이나 시장에 아무런 영향을 주지 못한다고 느낀다.
  • 제품 기능이 과도하게 늘어나거나 합리적이지 않은 방식으로 설계되고, 제품의 생애주기가 끝나가는 시점에도 고객으로부터 아무런 피드백을 받지 못한다.
  • 제품의 시장 적합성을 달성하지 못한다.

• 관찰 가능성과의 관계:

  • 관찰가능성은 필요한 데이터를 생산하고 개방형 질문을 하도록 유도하며 이 과정을 반복적으로 수행할 수 있게 해준다
  • 이벤트 주도 데이터 분석이 제공하는 일정 수준의 가시성과 예측 가능한 릴리스 흐름을 모두 관찰 가능성을 통해 얻을 수 있게 해준다.

21.5. 조직을 위한 관찰 가능성 성숙도 모델 적용

• 성숙한 관찰 가능성 관행을 만드는 과정은 선형적으로 진행되지 않는다.
• 각각의 기능을 검토하고 우선순위를 정할 때, 팀 내에서 이러한 변화를 주도하는 책임자가 누구인지 명확하게 식별할 필요가 있다.

Chapter 22. 관찰 가능성의 미래

• 관찰가능성: 소프트웨어의 상태와 관계없이 높은 카디널리티와 많은 디멘션을 가진 원격 측정 데이터를 이용하거나 임의로 필요에 맞게 세분화할 수 있고, 핵심 분석 루프를 통해 정확한 이슈 지점을 미리 정의하거나 예측하지 않고도 빠르게 격리하고 디버깅할 수 있다면, 관찰 가능성을 확보하는 것이다.

22.1. 관찰 가능성의 과거와 현재

• 과거에는 OpenTelemetry 가 초창기여서 개방형 표준을 사용할 이유가 없었다.
• 지금은 굳이 이를 설명할 필요가 없고, 어느정도 공감대가 생겼다.

22.2

22.3. 관찰 가능성의 미래

• 앞으로 최소 3년은 Otel 과 관찰 가능성을 떼어놓고 생각하기 어려워질것이다.
• 프론트엔드 어플리케이션에도 관찰가능성이 점차 확산 될 것이다.:
  • RUM과 Synthetic monitoring
• Otel 의 자동 계측이 여러 공급 업체의 라이브러리와 에이전트가 제공하는 수준까지 따라올것으로 예상된다.