수년째 참여하고 있는 인프라 스터디에서 그룹스터디하면서 읽은 책이다. 이 책은 트위터에서 Daniel Lee님이 추천해 줘서 위시리스트에 담고 있었는데 스터디 주제를 찾다가 이 책을 선정했다. 아무래도 원서라서 은근히 미루게 되어 안 읽게 되는데 그룹스터디로 하면 끝까지 읽을 수 있다.

5월 23일에 스터디를 시작해서 매주 하면서 이번 주까지 했으니 거의 6개월 스터디를 했다. 스터디는 좋았지만 그래도 6개월은 꽤 길긴 하다. 항상 더 빨리 끝내고 싶지만, 또 스터디를 하다 보면 진도 빼는 게 목적이 아니라 공부하는 게 목적이다 보니 이야기 나누고 질문하고 하다 보면 길어지기도 하고 해서 항상 5~6개월은 하게 되는 거 같다. 그래도 이제는 DeepL이 있어서 이전보다 훨씬 수월하게 원서로 스터디를 진행했다. 전에도 좀 이용하긴 했지만 아무래도 번역 품질이 좋아져서 후처리를 좀 덜 해도 되기도 하고 후처리를 안 해도 한국말은 좀 어색하지만, 대부분의 경우 무슨 말인지 이해는 할 수 있었다.

그리고 New Relic이나 Datadog등을 써보긴 했지만 옵저버빌리티 혹은 모니터링 시스템을 구축하는 역할은 아니라서 아주 자세히는 알지 못한다. PromQL도 잘 못 쓰는 사용자 정도의 느낌이지만 인프라 업무를 하다 보니 어느 정도의 관심은 있고 주워들은 것도 있는데 같이 스터디하시는 분들이 다양한 경험들이 있어서 그룹 스터디를 한 게 혼자 읽는 것 보다 더 도움이 됐다.

이 책은 옵저버빌리티 솔루션인 honeycomb.io의 Charity Majors, Liz Fong-Jones, George Miranda 세 명이 쓴 책으로 옵저버빌리티 솔루션을 만들면서 그동안 했던 많은 고민의 결과를 담은게 이 책이라고 생각한다.

Charity Majors는 honeycomb.io의 공동창업자이기도 한데 책에도 나오지만 2011년에 모바일 개발자에게 백엔드를 제공해 주는 Backend as a Service(BaaS)로 출시된 Parse에서 일했는데 Parse 특성상 한 사용자가 갑자기 서버 리소스를 다 먹거나 문제를 일으키거나 할 때 문제를 파악하면서 옵저버빌리티에 관심을 가지게 되었고 Parse가 Facebook에 인수되어 Facebook에서 일하면서 거의 모든 데이터를 다 넣어놓고 탐색하는 Scuba를 쓰면서 옵저버빌리티에 대한 많은 생각을 가지게 되고 결국 창업까지 이어지고 이 책까지 나오게 된다.

아무래도 모니터링이나 옵저버빌리티를 고민하고 있거나 구축하는 사람들에게 도움이 될 책이라고 생각한다. 어떤 면에서는 너무 이상적인 얘기를 한다는 느낌이 들 수도 있지만 앞으로 우리가 준비해야 할 옵저버빌리티는 이래야 한다고 방향성을 제시한다는 점에서 꽤 좋았고 저자들이 많은 경험이 있기 때문에 기술적으로 고려해야 할 부분도 잘 짚어주고 있어서 도움이 많이 되었다.

Part 1. The Path to Observability

데이터베이스의 맥락에서 카디널리티는 집합에 포함된 데이터 값의 고유성을 나타냅니다. 낮은 카디널리티는 열의 집합에 중복된 값이 많다는 것을 의미합니다. 높은 카디널리티는 열에 완전히 고유한 값이 많이 포함되어 있음을 의미합니다. 단일 값을 포함하는 열은 항상 가능한 가장 낮은 카디널리티를 갖습니다. 고유 ID를 포함하는 열은 항상 가능한 가장 높은 카디널리티를 갖습니다.

카디널리티는 옵저버빌리티에 중요한데, 카디널리티가 높은 정보는 거의 항상 시스템을 디버깅하거나 이해하기 위해 데이터를 식별하는 데 가장 유용하기 때문입니다.

안타깝게도 메트릭 기반 툴링 시스템은 카디널리티가 낮은 차원만 합리적인 규모로 처리할 수 있습니다. 비교할 호스트가 수백 개에 불과하더라도 메트릭 기반 시스템에서는 카디널리티 키 공간의 한계에 부딪히지 않고는 호스트 이름을 식별 태그로 사용할 수 없습니다.

옵저버빌리티란 새로운 코드를 배포하지 않고도 시스템이 아무리 새롭거나 기괴한 상태에 빠질 수 있는 모든 상태를 이해하고 설명할 수 있다는 것을 의미합니다.

이 책 전체적으로 높은 카디널리티를 엄청나게 강조하고 있다. 지금 사용하는 모니터링 시스템(이 책에서는 모니터링과 옵저버빌리티를 구분한다)에서는 카니널리티가 낮기 때문에 더 자세하게 파악하기가 어려운데 카디널리티를 높게 할 수 있으면 시스템의 더 자세한 내용을 관측할 수 있다.

기존 모니터링 도구는 이전에 알려진 오류 조건의 존재 여부를 나타내는 알려진 임곗값(threshold)에 대해 시스템 조건을 확인하는 방식으로 작동합니다. 이는 이전에 발생한 장애 모드를 식별하는 데만 효과적이기 때문에 근본적으로 사후 대응적인 접근 방식입니다.
반면, 옵저버빌리티 도구는 반복적인 탐색 조사를 통해 성능 문제가 발생할 수 있는 위치와 이유를 체계적으로 파악할 수 있습니다. 옵저버빌리티는 이전에 알려졌거나 알려지지 않은 모든 장애 모드를 식별하기 위한 사전 예방적 접근 방식을 가능하게 합니다.

메트릭은 일반적으로 종합적으로 볼 때 더 유용합니다. 추세 이해하기 메트릭 값을 이해하면 소프트웨어 성능에 영향을 미치는 시스템 동작에 대한 인사이트를 얻을 수 있습니다. 모니터링 시스템은 메트릭을 수집, 집계 및 분석하여 사람이 알고 싶어하는 추세를 나타내는 알려진 패턴을 선별합니다.

기존 모니터링과 옵저버빌리티를 구분해서 얘기하고 있는데 옵저버빌리티를 그래서 어떻게 이렇게 할 수 있느냐를 떠나서 모노리스로 서버 한 대가 있다면 큰 상관이 없겠지만 마이크로서비스로 서비스가 많이 떠 있다면 모니터링 자체가 상당히 어려워지기 때문에 이 내용에 동의하는 편이다. 오류가 증가하거나 레이턴시가 증가할 때 연쇄적으로 발생할 가능성이 높기 때문에 어디가 원인이고 어디가 영향받은 것인지 파악하는 것도 쉽지 않은 일이다.

그 임곗값이 정확히 어디인지는 사람이 결정합니다.

모니터링 기반 접근 방식에서는 팀에서 가장 오래 근무한 엔지니어가 팀에서 가장 뛰어난 디버거이자 최후의 디버거인 경우가 많기 때문에 연공서열이 지식의 핵심이라는 생각에 초점을 맞추는 경우가 많습니다

옵저버빌리티 도구를 사용하면 팀에서 가장 뛰어난 디버거는 일반적으로 가장 호기심이 많은 엔지니어입니다. 옵저버빌리티를 실천하는 엔지니어는 탐색적인 질문을 통해 시스템을 조사하고, 발견한 답을 사용하여 더 개방적인 질문을 할 수 있는 능력을 갖추고 있습니다

프로덕션 환경에서 알려진 임곗값을 초과하는 시스템 상태의 엣지 케이스를 찾는 모니터링 알림은 엄청난 수의 오탐, 오탐, 무의미한 노이즈를 생성합니다. 알림은 사용자 경험에 직접적인 영향을 미치는 증상에만 집중하여 더 적은 수의 알림을 트리거하는 모델로 전환되었습니다.

매트릭의 임곗값 설정도 메인 서비스 한두 개로 운영한다면 계속 운영하면서 조정하면 가능하지만 수십 개 수백 개가 된다면 이마저도 쉽지 않은 일이다.

수동으로 해결해야 하고 런북에 정의할 수 있는 알려진 반복 장애는 더 이상 일반적이지 않습니다. 서비스 장애는 이러한 모델에서 알려진 반복 장애를 자동으로 복구할 수 있는 모델로 전환되었습니다. 자동으로 복구할 수 없어 알림이 트리거되는 장애는 대응하는 엔지니어가 새로운 문제에 직면하게 될 가능성이 높습니다.

최근에 많이 생각하는 일이긴 하다. 장애 대응을 문서로 만들 수 있다면 보통 자동화 처리하는 게 편하고(대표적으로 Kubernetes에서 컨테이너가 죽으면 리스타트하는 걸 들 수 있다) 결국 장애에서 문서화를 한다는 것은 사람이 판단할 수 있는 정보를 넣어야 하는데 이런 걸 결국 문서화가 어렵다. 장애 대응 문서를 그대로 따라 하면 해결이 된다면 굳이 사람이 할 필요가 있는가?

기존 접근 방식의 한계는 무엇보다도 사전 프로덕션 강화에 중점을 둔다는 점입니다. 그런 다음 남은 관심은 생산 시스템에 집중하는 데 투입됩니다. 프로덕션에서 안정적인 서비스를 구축하려면 이러한 순서를 바꿔야 합니다.
최신 시스템에서는 엔지니어링에 대한 관심과 툴링의 대부분을 무엇보다도 프로덕션 시스템에 집중해야 합니다. 남은 관심의 주기는 스테이징 및 사전 프로덕션 시스템에 적용되어야 합니다. 스테이징 시스템에도 가치가 있습니다. 하지만 이는 본질적으로 부차적인 것입니다.
스테이징 시스템은 프로덕션이 아닙니다. 프로덕션에서 일어나는 일을 결코 복제할 수 없습니다. 사전 프로덕션 시스템의 무균 실험실 환경은 실제 유료 서비스 사용자가 실제 환경에서 코드를 테스트하는 것과 동일한 조건을 모방할 수 없습니다. 그런데도 많은 팀이 여전히 프로덕션을 유리성으로 취급합니다.

이건 꽤 급진적인 생각으로 느껴졌는데 생각해 보면 의미 있는 부분인 것 같다. 결국 가장 안전하게 하려면 사전 프로덕션 검증을 강화해야 하고 많은 기법이 여기에 초점이 맞춰져 있지만 시스템이 복잡해질수록 제대로 된 검증하기는 점점 어려워진다. 카오스 엔지니어링이 프로덕션에서 카오스를 만들었고 당시에도 급진적이라고 생각하면서도 멋지다고 생각했는데 아직 경험치가 부족하니 여전히 프로덕션은 좀 무섭게 느껴지는 것 같다. 이런 부분에서 생각의 전환을 할 필요가 있어 보인다.

우리 팀은 회고전을 실행하여 문제를 분석하고, 미래의 우리 자신에게 문제를 처리하는 방법을 알려주는 런북을 작성하고, 다음번에 그 문제를 즉시 드러낼 수 있는 사용자 지정 대시보드(한두 개)를 만든 다음, 문제가 해결된 것으로 간주하고 넘어가곤 했습니다.

이 부분은 자주 하는 행동이라 뜨끔하면서 반성하게 되었다.

저는 소프트웨어 업계에서 영웅 문화의 이러한 측면을 강조하고 싶습니다. 램프 스택 스타일의 모놀리식 시스템에서 최후의 디버거는 일반적으로 시스템을 처음부터 구축한, 가장 오래 근무한 사람이 맡습니다. 가장 연차가 높은 엔지니어가 최후의 에스컬레이션 지점입니다. 이들은 가장 많은 상처 조직과 가장 많은 중단 목록을 가지고 있으며, 필연적으로 문제를 해결하기 위해 뛰어들어야 하는 사람들입니다.
그 결과 이 영웅들은 진정한 휴가를 결코 가질 수 없습니다. 하와이로 신혼여행을 가던 중 새벽 3시에 호출을 받았는데, 몽고DB가 어떻게든 Parse API 서비스를 중단시켰기 때문이었습니다. 제 상사였던 CTO는 정말 미안해했습니다. 하지만 사이트는 다운되어 있었습니다. 한 시간 넘게 다운된 상태였는데 아무도 그 이유를 알아내지 못했습니다. 그래서 저를 호출했습니다. 네, 저는 불평했습니다. 하지만 마음 깊은 곳에서는 은근히 기분이 좋았습니다. 제가 필요했거든요. 제가 필요했으니까요.

2013년 Facebook이 Parse를 인수한 후, 저는 Facebook이 대부분의 실시간 분석에 사용하는 데이터 관리 시스템인 Scuba를 알게 되었습니다. 이 빠르고 확장 가능한 분산형 인메모리 데이터베이스는 초당 수백만 개의 행(이벤트)을 수집합니다. 실시간 데이터를 메모리에 완전히 저장하고 쿼리를 처리할 때 수백 대의 서버에 걸쳐 집계합니다. 제 경험은 거칠었습니다. 저는 Scuba의 사용자 환경이 매우 추악하고 심지어 적대적이라고 생각했습니다. 하지만 시스템 문제 해결에 대한 저의 접근 방식을 완전히 바꿔놓은 한 가지 뛰어난 기능이 있었으니, 바로 무한히 높은 카디널리티의 차원에 대해 거의 실시간으로 데이터를 슬라이스하고 주사위를 던질 수 있게 해준다는 것이었습니다.

Part 2. Fundamentals of Observability

메트릭이란 시스템 상태를 나타내기 위해 수집된 스칼라값을 의미하며, 이러한 숫자를 그룹화하고 검색하기 위해 선택적으로 태그가 추가될 수 있습니다. 메트릭은 소프트웨어 시스템에 대한 전통적인 모니터링의 기반이 되어 왔습니다

메트릭의 근본적인 한계는 사전 집계된 측정값(pre-aggregated measure)이라는 점입니다. 메트릭에 의해 생성된 수치는 미리 정의된 기간의 시스템 상태에 대한 집계된 보고서를 반영합니다.

메트릭은 모두 서로 연결되지 않은 별개의 측정값으로, 동일한 요청에 속하는 메트릭을 정확히 재구성하는 데 필요한 연결 조직과 세분성이 부족합니다.

메트릭은 미리 정의된 기간의 사전 정의된 관계를 종합적으로 수치로 표현한 것으로, 하나의 시스템 속성에 대한 좁은 관점의 하나에 불과합니다. 메트릭의 세부 수준이 너무 높고 시스템 상태를 다른 보기로 표시하는 기능이 너무 경직되어 있어 옵저버빌리티를 달성하기 어렵습니다. 메트릭은 옵저버빌리티의 기본 구성 요소로 사용하기에는 너무 제한적입니다.

옵저버빌리티 도구가 조사자에게 유용하려면 카디널리티가 높은 쿼리를 지원할 수 있어야 합니다. 최신 시스템에서는 새로운 문제를 디버깅하는 데 가장 유용한 많은 차원이 높은 카디널리티를 가지고 있습니다. 또한 깊이 숨겨진 문제를 찾기 위해 이러한 높은 카디널리티 차원을 함께 묶어(즉, 고차원성) 조사해야 하는 경우가 많습니다. 문제를 디버깅하는 것은 종종 건초 더미에서 바늘을 찾는 것과 같습니다. 높은 카디널리티와 고차원성은 매우 복잡한 분산 시스템 건초 더미에서 매우 세밀한 바늘을 찾을 수 있게 해주는 기능입니다.

메트릭의 연결성이 필요하다는 것에는 동의한다. 물론 대부분 높은 카디널리티가 도움 된다는 것에도 동의할 것으로 생각한다. 높은 카니널리티를 담으면 메트릭 서버가 버티지 못해서 그렇지...

분산 트레이싱(distributed tracing)은 애플리케이션을 구성하는 다양한 서비스에서 처리되는 단일 요청(trace라고 함)의 진행 상황을 추적하는 방법입니다. 이러한 의미에서 트레이싱은 "분산"되어 있으며, 그 기능을 수행하기 위해 단일 요청이 프로세스, 머신, 네트워크 경계를 넘나들어야 하는 경우가 많기 때문입니다.

모니터링 및 옵저버빌리티 커뮤니티는 공급업체 종속 문제를 해결하기 위해 수년 동안 여러 오픈 소스 프로젝트를 만들어 왔습니다. 2016년과 2017년에 각각 클라우드 네이티브 컴퓨팅 재단 산하의 OpenTracing과 Google이 후원하는 OpenCensus가 등장했습니다. 이 경쟁적인 개방형 표준은 가장 널리 사용되는 프로그래밍 언어용 라이브러리 세트를 제공하여 원격 분석 데이터를 수집하여 사용자가 선택한 백엔드로 실시간으로 전송할 수 있도록 했습니다. 결국 2019년, 두 그룹이 힘을 합쳐 CNCF 산하의 OpenTelemetry 프로젝트를 결성했습니다.

분산 트레이싱은 알지는 꽤 되었지만 나도 그렇게 제대로 하기는 쉽지 않다. 물론 모든 기술이 그렇듯이 가까이서 기술적인 한계와 현실을 이해할수록 더 어렵게 느껴지긴 한다. OpenTelemetry은 최근에 조금씩 관심을 가지고 있는데 결국 OpenTelemetry로 가긴 하겠지만 긍정적인 미래와 걱정에 대한 생각이 둘다 있긴 하다.

런북을 만드는 데 소요되는 시간이 대부분 낭비된다는 주장은 처음에는 다소 가혹해 보일 수 있습니다. 분명히 말씀드리자면, 특정 서비스의 요구 사항과 그 출발점을 팀에 빠르게 안내하기 위한 문서가 필요합니다.

그러나 가능한 모든 시스템 오류와 해결 방법을 포함하는 살아있는 문서를 유지하는 것은 쓸데없고 위험한 일입니다. 이러한 유형의 문서는 금방 부실해질 수 있으며, 잘못된 문서는 문서가 없는 것보다 더 위험할 수 있습니다. 빠르게 변화하는 시스템에서는 엔지니어의 의도(엔지니어가 이름을 지정하고 수집하기로 한 치수는 무엇인가?)와 프로덕션의 실시간 최신 상태 정보가 결합하여 있기 때문에 계측 자체가 최고의 문서가 되는 경우가 많습니다.

문서에 대한 생각은 꽤 동의하는 편이다.

옵저버빌리티의 진정한 힘은 문제를 디버깅하기 전에 너무 많은 것을 미리 알 필요가 없다는 것입니다. 시스템에 익숙하지 않은 경우에도 체계적이고 과학적으로 한 단계씩 단계를 밟아 단서를 따라 체계적으로 답을 찾을 수 있어야 합니다. 무언의 신호를 유추하거나, 과거의 상처 조직에 의존하거나, 익숙한 기지를 발휘하여 순식간에 올바른 결론에 도달하는 마법은 체계적이고 반복할 수 있으며 검증할 수 있는 프로세스로 대체됩니다.

결국 이 책에서 얘기하는 것은 드릴다운 할 수 있어야 한다는 것이다. 예를 들어 특정 서비스에서 레이턴시가 갑자기 튀기 시작했을 때 메트릭은 그냥 레이턴시 평균이 튀었다는 것만 알려주지만 높은 카디널리티로 다양한 정보를 담아서 모든 메트릭 간에 연결할 수 있어야 한다는 것이다. 그래서 레이턴시가 튀었을 때 클릭해서 더 자세히 들어가서 이게 특정 서버에서 발생하는지, 특정 존에서만 발생하는지, 특정 API에서 발생하는지를 구분해서 볼 수 있어야 문제를 발견할 수 있다는 것인데 동의한다.

그리고 서버의 디스크나 하드웨어 등 시스템은 모니터링으로 파악하고 애플리케이션은 옵저버빌리티로 접근해야 한다는 부분도 수긍되었다.

Part 3. Observability for Teams

이를 위한 가장 좋은 방법은 OpenTelemetry를 사용하여 애플리케이션을 계측하는 것입니다(7장 참조). OTel을 사용하면 다른 공급업체의 독점 에이전트나 라이브러리만큼 빠르고 쉽지는 않지만, 느리고 사용하기 어려운 것도 아닙니다. 처음부터 이 작업을 수행하는 데 필요한 약간의 사전 시간 투자는 나중에 여러 솔루션을 사용해 보고 어떤 솔루션이 가장 적합한지 확인하기로 할 때 큰 도움이 될 것입니다.

이 책은 2022년 6월에 나왔고 지금과 마찬가지로 OpenTelemetry는 아직 초기 단계(내 개인 생각이다.)라고 할 수 있는데 요즘 분위기와 마찬가지로 OpenTelemetry의 미래를 아주 긍정적으로 보고 있고 분산 트레이스에서 OpenTelemetry이 해결책이 될 것으로 보고 계속 OpenTelemetry를 강조하고 있다.

가장 큰 문제점에서 시작하는 것과 마찬가지로, 옵저버빌리티 도구를 직접 구축할지 아니면 상용 솔루션을 구입할지 결정하는 것은 투자 수익률(ROI)을 신속하게 입증하는 것입니다.

새로운 기술을 채택하는 데 있어 큰 장벽 중 하나는 매몰 비용 오류입니다. 개인과 조직은 이전에 투자한 시간, 비용, 노력의 결과로 행동이나 노력을 지속할 때 매몰 비용 오류를 범합니다.

사서 쓰냐? 만들어서 쓰냐는 어려운 부분인데 꽤 여러 관점도 다뤄주어서 좋았다. 물론 모니터링은 간단하지 않으므로 조직이 작을 때는 그냥 사서 쓰고 조직이 커지면서 구축을 고민해야 한다고 생각하긴 한다.

옵저버빌리티는 코드 로직을 디버깅하기 위한 것이 아닙니다. 옵저버빌리티는 시스템에서 디버깅에 필요한 코드를 찾을 수 있는 위치를 파악하기 위한 것입니다. 옵저버빌리티 도구는 문제가 발생할 수 있는 위치를 신속하게 좁혀서 도움을 줍니다.

관찰 가능성 중심 개발을 통해 엔지니어링 팀은 유리 성을 인터랙티브한 놀이터로 바꿀 수 있습니다. 프로덕션 환경은 고정된 것이 아니라 변화무쌍하며, 엔지니어는 어떤 게임에도 자신 있게 뛰어들어 승리를 거둘 수 있는 역량을 갖춰야 합니다. 그러나 옵저버빌리티를 SRE, 인프라 엔지니어 또는 운영팀의 영역으로만 간주하지 않을 때만 가능합니다. 소프트웨어 엔지니어는 옵저버빌리티를 채택하고 개발 관행에 적용하여 프로덕션에 변경을 가하는 것에 대한 두려움의 사이클을 풀어야 합니다.

소프트웨어 업계에서는 일반적으로 속도와 품질 간에 상충 관계가 발생한다는 인식이 있습니다. 즉, 소프트웨어를 빠르게 릴리스하거나 고품질 소프트웨어를 릴리스할 수는 있지만 둘 다 릴리스할 수는 없다는 것입니다. "Accelerate: Building and Scaling High Performing Technology Organizations”의 핵심 내용은 이러한 역관계는 잘못된 상식이라는 것입니다. 우수한 성과를 내는 기업에서는 속도와 품질이 함께 상승하며 서로를 강화합니다. 속도가 빨라지면 장애가 더 작아지고 발생 빈도가 줄어들며, 장애가 발생하더라도 복구하기가 더 쉬워집니다. 반대로 다음과 같은 팀의 경우 느리게 움직이는 팀은 실패가 더 자주 발생하고 복구하는 데 훨씬 더 오래 걸리는 경향이 있습니다.

옵저버빌리티가 해결해야 하는 부분과 옵저버빌리티를 통해서 개발과 운영의 관행도 바꿔줄 수 있다는 부분은 꽤 좋았고 앞으로 옵저버빌리티의 미래에 대해서도 많은 인사이트를 얻을 수 있었다.

CPU 사용률의 변화는 백업 프로세스가 실행 중이거나 가비지 컬렉터가 정리 작업을 수행하거나 시스템에서 다른 현상이 발생할 수도 있는 지표일 수 있습니다. 즉, 이러한 상태들은 우리가 실제로 관심을 가지는 문제뿐만 아니라 시스템의 다양한 요소들을 반영할 수 있습니다. 이러한 측정치를 기반으로 경고를 발생시키면 하드웨어 기반의 단순 측정치로 인해 오류가 발생할 확률이 높아집니다. 이러한 경험이 있는 엔지니어링 팀들은 이러한 유형의 경고를 무시하거나 억제하는 경향이 있으며, "그 경고 걱정하지 마세요; 우리는 이 프로세스가 가끔 메모리가 부족해질 때가 있다는 걸 알고 있습니다."와 같은 문구를 자주 사용합니다.

오류가 발생할 가능성이 높은 경고에 익숙해지는 것은 알려진 문제이자 위험한 관행입니다. 다른 산업에서는 이러한 문제를 "비정상적 허용(Normalization of Deviance)"이라고 합니다.

신뢰성 있는 서비스를 제공하려면 팀은 신뢰성이 떨어지거나 노이즈가 발생하는 경고를 제거해야 합니다. 그러나 많은 팀은 이러한 불필요한 방해를 제거하는 데 두려움을 느낍니다. 이러한 경고를 제거함으로써 서비스 저하에 대해 배우는 방법이 없다는 우려가 종종 우세합니다. 그러나 이러한 전통적인 경고 유형은 알려진 미지수(known-unknowns)만 감지하는 데 도움이 됩니다.

우리는 경고 기준을 두 부분의 하위 집합으로 정의합니다.
첫째, 경고는 서비스의 사용자 경험이 저하된 상태를 신뢰성 있게 반영해야 합니다.
둘째, 경고는 해결할 수 있어야 합니다.
경고에 대응하여 디버깅하고 조치하는 데 체계적인 방법(단순 반복적인 자동화가 아닌)이 있어야 하며, 대응자가 올바른 조치 방법을 추측하지 않아도 되어야 합니다. 이 두 가지 조건이 충족되지 않는다면 구성한 경고는 더 이상 의도한 목적을 달성하지 못하는 것입니다.

전통적인 메트릭 기반의 모니터링 접근 방식은 정적인 임곗값을 사용하여 최적의 시스템 상태를 정의하는 데 의존합니다. 그러나 현대 시스템의 성능은 인프라 수준에서도 서로 다른 워크로드 하에서 동적으로 변할 수 있습니다. 정적인 임곗값은 사용자 경험에 미치는 영향을 모니터링하는 데 적합하지 않습니다.

동의하는 부분이다. 요즘 업무를 하면서도 생각하지만 경고는 상당히 조심스럽게 접근해야 한다고 보는 편이다.(그래서 지금 하고 있는 업무에서도 경고를 아직까지 만들지 못하고 있다.) 경고는 신뢰성 있어야 하고 액션 가능해야 한다. 간단해 보이지만 아주 쉽지 않고 때문에는 알림을 끄는 기능도 필요해 지는데 이 끄는 기능도 결국 많이 꺼지면 신뢰성의 문제가 생겨서 쉽지 않다. 현실 구현을 제외하고 방향성에는 아주 동의한다.

SLOs는 경고의 범위를 사용자들이 서비스를 체험하는 데 영향을 미치는 증상만을 고려하도록 좁힙니다.

"무엇(what)"과 "왜(why)"를 분리하는 것은 최대한 신호를 극대화하고 노이즈를 최소화하는 좋은 모니터링 작성에서 가장 중요한 차이 중 하나입니다.

SLO를 설명하면서 얘기한 부분이 흥미로웠고 스터디에서도 여기서 많은 논의를 했는데 내가 이해한 핵심은 What과 Why를 구분하라는 것이다. 경고를 SLO로만 해야 하는데 이는 What을 알려주라는 것이고 Why는 옵저버빌리티 시스템에 들어와서 파악할 수 있게 제공해야 한다는 것이다.

Slack CI의 주요 과제는 복잡성이었습니다. E2E 테스트의 실패는 코드 베이스, 인프라 및 플랫폼 런타임 변경사항이 복잡하게 상호작용한 결과일 수 있습니다. 2020년에 웹 앱 개발자의 단일 커밋에 대하여, 저희 CI 파이프라인은 30개 이상의 테스트 스위트를 GitHub를 통해 실행합니다. 이 파이프라인은 3개의 플랫폼 팀(퍼포먼스, 백엔드, 프론트엔드)과 20개의 다양한 요구사항과 전문 분야가 있는 팀/서비스에 의해 만들어졌습니다. 2020년 중반에 이르러 CI 인프라가 한계에 도달하기 시작했습니다. 테스트 실행이 월별로 10%씩 증가하면서 테스트 실행을 위해 여러 다운스트림 서비스를 확장하는 데 어려움을 겪었습니다.

Slack의 게스트 챕터가 몇 편 나오는데 CI에서 옵저버빌리티를 사용해서 단계별 성능, 오류 문제를 옵저버빌리티를 사용해서 가시성을 높인 부분이 흥미로웠다. 그동안 옵저버빌리티를 서비스 위주로만 생각해서 이런 식의 적용은 미처 생각해 보지 못했다.

Part 4. Observability at Scale

사람들은 일반적으로 자신의 시간 가격을 고려하는 데 익숙하지 않습니다. 인프라를 가동하고 소프트웨어를 구성하는 데 한 시간이 걸리면 DIY 솔루션은 본질적으로 무료인 것처럼 느껴집니다.

오픈소스를 가져가다 구축할 때 흔히들 하는 실수.

옵저버빌리티는 조직의 경쟁 우위입니다. 자체 옵저버빌리티 솔루션을 구축하면 자체 관행과 문화에 깊이 뿌리내리고 기존 기관의 지식을 활용하는 솔루션을 개발할 수 있습니다. 많은 워크플로우 및 구현과 함께 작동하도록 설계된 일반적인 사전 구축 소프트웨어를 사용하는 대신, 자체 규칙에 따라 비즈니스의 맞춤형 부분과 긴밀하게 통합되도록 솔루션을 사용자 지정할 수 있습니다.

자체 옵저버빌리티 솔루션을 구축하기로 할 때는 조직의 능력과 상용 시스템보다 더 나은 것을 개발할 수 있는 가능성을 모두 현실적으로 고려하는 것이 중요합니다. 조직 전체에서 채택을 장려하는 데 필요한 사용자 인터페이스, 워크플로우 유연성 및 속도를 갖춘 시스템을 제공할 수 있는 조직적 전문성을 갖추고 있습니까? 그렇지 않다면 솔루션의 단점과 해결 방법을 잘 알고 있는 사람들 외에는 널리 채택되지 않는 솔루션에 시간과 비용을 투자하고 비즈니스 기회를 잃게 될 가능성이 높습니다.

상용 솔루션의 또 다른 숨겨진 비용은 시간입니다. 예, 기성 솔루션을 구매하면 가치 실현 시간을 단축할 수 있습니다. 하지만 이 경로를 선택할 때는 벤더 종속이라는 숨겨진 함정에 유의해야 합니다.

옵저버빌리티 도구에 있어 구축 또는 구매라는 선택은 잘못된 이분법입니다. 선택은 단순히 구축 또는 구매로만 제한되지 않습니다. 세 번째 옵션은 구매 후 구축하는 것입니다. 실제로 이 책의 저자는 대부분의 조직에 이 접근 방식을 권장합니다. 내부 기회비용을 최소화하고 조직의 고유한 요구 사항에 맞는 솔루션을 구축할 수 있습니다.

나에게 16장 Efficient Data Storage는 가장 재밌는 부분 중 하나였다. 데이터 스토리지에 대해 많이 생각한 적이 없긴 한데 결국 책에서 얘기하는 높은 카디널리티를 고차원으로 모든 메트릭을 저장하려면 스토리지가 문제가 된다. 앞부분 읽으면서는 이런 마법의 스토리지가 있다고? 하는 느낌으로 읽을 때도 있지만 여기서 현실적으로 어떤 스토리지가 있고 각 스토리지의 장단점, 옵저버빌리티를 하려면 어떤 부분은 잘 되지만 어떤 부분에서 한계가 있는지를 잘 설명해 주고 있다. 결국 하이브리드 형을 제안하긴 하는데 현재의 기술적 상황을 잘 지적해 주었다는 느낌이 들었다.

Part 5. Spreading Observability Culture

옵저버빌리티의 목표는 엔지니어링 팀이 시스템을 개발, 운영, 철저하게 디버그하고 보고할 수 있는 역량을 제공하는 것입니다. 팀은 시스템 동작을 더 잘 이해하기 위해 시스템에 대해 임의의 질문을 함으로써 호기심을 탐구할 수 있는 권한을 부여받아야 합니다. 팀원들이 도구와 경영진의 지원을 통해 능동적으로 시스템을 조사할 수 있도록 인센티브를 제공해야 합니다.

데브옵스 관행이 계속해서 주류로 자리 잡으면서, 미래 지향적인 엔지니어링 리더십 팀은 엔지니어링 팀과 운영팀 사이의 장벽을 제거합니다. 이러한 인위적인 장벽을 제거하면 팀이 소프트웨어 개발과 운영에 대해 더 많은 주인의식을 가질 수 있습니다. 옵저버빌리티는 대기 경험이 부족한 엔지니어가 장애가 발생하는 위치와 장애를 완화하는 방법을 더 잘 이해할 수 있도록 지원하여 소프트웨어 개발과 운영 사이의 인위적인 벽을 허물어뜨립니다.

팀이 옵저버빌리티의 이점을 누리게 되면, 프로덕션의 이해와 운영에 대한 신뢰 수준이 높아질 것입니다. 해결되지 않은 '미스터리' 인시던트의 비율이 줄어들고 조직 전체에서 인시던트를 감지하고 해결하는 데 걸리는 시간이 단축될 것입니다. 그러나 이 시점에서 성공을 측정할 때 자주 저지르는 실수는 탐지된 전체 인시던트 수와 같은 얕은 메트릭에 지나치게 집착하는 것입니다.

옵저버빌리티에 대한 전체적인 생각의 틀을 잡게 해준 좋은 책이라고 생각하고 저자들이 옵저버빌리티에 대해 정말 오래 고민했다는 것도 느낄 수 있었다. 그래서 이 책이 서비스 홍보 책은 아니지만, 또 전혀 아니라고 할 수도 없기에 Honeycomb.io를 한번 써보고 싶다는 생각이 들었다. 가볍게 적용해 볼 옵저버빌리티가 있다면 테스트 삼아 한번 써볼 것 같긴 하다. 물론 개인적으로는 책 초반에 배경 설명이 좀 길고 반복되는 느낌이라서 좀 더 짧은 분량으로도 저자들의 의도를 잘 전달할 수 있지 않았을까 하는 생각도 든다.

[Book] Observability Engineering

댓글