[번역] 관찰 가능성, 3년을 돌아보며

May 1, 2021

원문: Observability — A 3-Year Retrospective

최근에 읽었던 글 중 가장 인상 깊었던 관찰 가능성(observability)에 관한 글을 번역하려고 합니다. 감사하게도 저자께서 흔쾌히 번역을 허락해주셨습니다.

개발 접근, 혹은 그보다 움직임(movement)이라고 할 수 있는 관찰 가능성은 이제 갓 3살 정도 됐으며, 이 분야의 초기 개척자 중 하나인 Charity Majors는 한 발짝 물러서 얼마나 멀리 왔는지 "관찰"하기로 했습니다. 이 글에서 그녀는 중요한 기여자들을 인용하며 왜 관찰 가능성이 생겼고, 왜 다른 접근과 방법은 부족한지 살펴봅니다. 그녀는 관찰 가능성을 도입하는 것은 복잡한 분산 시스템을 구축하고 유지하는 모든 엔지니어링 팀에게 중요하다고 설명합니다.


소프트웨어 엔지니어링의 다른 수많은 용어와 마찬가지로, "관찰 가능성"은 물리 분야(이 경우에는 제어 시스템 공학)에서 빌려온 용어입니다. 관찰 가능성은 제어 가능성과 수학적 쌍대관계(mathematical dual)에 있습니다.

조금 느슨하게 얘기하면, 이는 곧 시스템의 출력으로 전체 시스템의 동작을 확인할 수 있다는 것을 의미합니다. 만약 시스템이 관찰 가능하지 않은 상태라면, 이 말은 시스템의 상태 값 중 일부는 출력 센서를 통해 현재 상태를 확인할 수 없다는 뜻이기도 합니다.

관찰 가능성이 왜 단순히 제품 마케팅 용어가 아니라 의미 있는 기술 용어인지 알아보기 전에, 먼저 모니터링, 메트릭, 이벤트, 그리고 우리가 시스템을 인지하기 위해 했던 시도의 간략한 역사를 이해할 필요가 있습니다. 우린 왜 하필 관찰 가능성에 주목해야 하는지, 왜 지금인지 이해하기 위해 우선 어떻게 세상이 변해왔는지 이해해야 합니다.

터미널과 고급 프로그래밍 언어가 생긴 이래, 로그가 있었습니다. 무엇이 일어나고 있었는지 이해할 수 있게 도와주는, 사람이 읽을 수 있는 형태의 문자열 출력 말이죠. 다음은 단일 노드 성능을 이해하는 데 여전히 가장 좋은 방법인 초기 텍스트 기반 시스템 패키지들, sysstat, sar, iostat, netstat, mpstat 등이 등장했습니다. 그리고 1988년 (제가 알기로) 첫 번째 메트릭 기반의 원격 측정 시스템인 SNMPv1이 탄생했습니다.

메트릭은 80년대 이후를 지배해왔습니다. snmp, rrdtool, cacti, Ganglia, 유례없이 영향력 있는 Etsy statsd. 이들의 현대 계승자들로는 SignalFX, DataDog, Wavefront 등이 있습니다. 사용자 경험은 큰 발전을 이루었지만, 결국 이 모든 툴은 그룹화와 출처를 찾기 용이한 단일 숫자 형태가 기본이 되어왔습니다.

요청이 당신의 코드를 통과하면 요청이 완료되기 전에 수십 또는 수백 개의 메트릭이 — 빌드 ID, AWS 리전 등과 같은 태그가 달린 게이지, 카운터, CPU 사용량이나 메모리 크기, I/O 통계와 같은 숫자 — 발생할 수 있습니다. 일반적으로 메트릭은 기록될 때 집계되고, 시간에 지남에 따라 입상도(granularity)를 잃고 수집과 저장하기 아주 효율적인 형태가 됩니다. 메트릭은 여전히 당신의 인프라를 전체적인 동작의 관점에서 이해하기에 가장 중요한 방법이며, 아마 늘 그럴지도 모릅니다. 하지만 상술했듯 "입상도"를 잃는다는 사항을 잊지 마세요. 우린 이 지점으로 다시 돌아올 것이기 때문에 기억해 두는 것이 좋습니다; 메트릭은 관찰 가능성과 같지 않습니다.

2000년대 등장한 새로운 벤더: APM

약 10년 전, APM(Application Performance Management) 우산 아래 새로운 벤더들이 등장했습니다. NewRelic, AppDynamics, 그리고 다른 업체들은 애플리케이션을 잘 이해하려는 이들의 돈을 걷어갔습니다. 에이전트를 사용하는 대신 코드에 라이브러리를 설치해 요청을 추적하고, 언어와 요청에 특화된 보고를 해줍니다. 그들은 유용한 top-10 리스트를 만들어 엔드포인트, 쿼리, 등 성능 문제가 어디서 비롯됐는지 알려줍니다.

이러한 툴은 중요한 발전을 가져왔습니다. 이들은 여전히 대부분 메트릭 기반이었지만, 3인칭 관찰자에서 1인칭으로의 시점 전환은 당신의 소프트웨어와 그 동작에 대한 더 깊은 자기성찰을 가져왔습니다.

어느덧 툴은 먼 길을 왔습니다. 하지만 불과 5년 전, 제가 (이후에 Facebook에 인수되는) Parse에 있었을 때, 지속해서 다운되고 예측할 수 없는 공통 테넌트(co-tenancy) 문제로 고통받는 플랫폼을 고민하고 있었을 때, 이러한 툴들을 모두 사용해 보았지만 어느 것 하나도 시스템 성능과 안정성 문제를 해결하는 데는 도움이 되지 않았습니다. 다시 말하겠습니다: 어느 것 하나도 그들이 주장한 대로 동작하지 않았습니다. 이는 그들이 거짓말을 하거나, 그들 자신을 잘못 표현했기 때문이 아니라, 우리가 구축하고 있던 시스템의 종류가 이러한 툴들이 이해하려 했던 시스템과 근본적으로 달랐기 때문입니다. Parse는 많은 트렌드의 얼리 어답터였고 여전히 상대적으로 최첨단에 있으며, 그리고 점점 더 많은 사람이 제가 그 기간 겪었던 당혹감과 좌절감을 경험하고 있습니다. 한때 혁명적이었던 이 낡은 도구들은 더 이상 현재의 우리 시스템에서 동작하지 않습니다.

카디널리티와 복잡한 분산 시스템과의 관계

이유를 완전히 이해하려면 — 먼저 우리가 구축하는 오늘날의 시스템이 어떻게 (그리고 왜) 다른지 이해해야 하며, 그리고 그 핵심은 카디널리티라 부르는 것을 이해하는 것입니다.

카디널리티는 집합의 고유 항목 수를 나타냅니다. 고유 ID는 항상 가장 높은 카디널리티가 되고, 단일 값은 항상 가장 낮은 카디널리티가 됩니다. 1억 개의 사용자 명부가 있다면, 사회 보장 번호가 가능한 가장 높은 카디널리티를 가질 것이라고 확신할 수 있습니다. 이름과 성은 (동명이인이 있을 수 있기 때문에) 그보다는 낮지만, 꽤 높은 카디널리티입니다. 성별은 상당히 낮은 카디널리티이고, "종: 인간"은 아마도 가장 낮은 카디널리티가 될 것이며, 분명 기록하는 것도 귀찮은 일이겠죠.

높은 카디널리티 데이터에 접근할 수 없다면? 디버깅은 하늘에 맡겨요!

이게 왜 중요할까요? 높은 카디널리티 정보는 시스템을 디버깅하거나 이해하는 데 가장 유용한 데이터이기 때문입니다 (사용자 ID, 장바구니 ID, 요청 ID... 기본적으로 모든 ID와 인스턴스, 컨테이너, 빌드 번호, 스팬(span) ID 등). 고유 ID는 항상 주어진 건초 더미에서 각각의 바늘들을 식별하기에 가장 좋은 역할을 수행합니다.

그러나 메트릭 기반 도구 시스템은 카디널리티가 낮은 차원만 대규모로 처리할 수 있습니다. 호스트가 수백 개에 불과한 경우에도, 당신은 호스트 이름을 식별 태그로 넣을 수 없습니다. 그렇지 않으면, 카디널리티 키 공간이 사라질 테니까요. 마찬가지로, 메트릭 기반 도구로 질문하려는 모든 질문에 대해 미리 정해두어야 주어진 작성 시간 안에 답변을 작성할 수 있습니다. 이 말인즉슨,

  1. 무언가 일이 일어난 후에 새로운 질문을 하고 싶어도, 할 수 없습니다.
  2. 물어 볼 수 있길 바라는(!) 질문 수에 비례하여 비용은 상승합니다.

모놀리딕을 무수히 많은 서비스로 부풀렸을 때, 우린 디버거로 코드를 단계별로 실행할 수 있는 능력을 상실했습니다: 이제 네트워크를 넘나듭니다. 우리의 툴들은 여전히 이러한 극적인 변화에 맞서고 있습니다.

카디널리티가 높은 차원은 매우 드물었기 때문에, 오랫동안 이것은 그다지 중요한 문제가 아니었습니다. 일반적인 모놀리딕 시스템에서는 단일 앱 계층과 하나의 데이터베이스만 있었습니다. 모든 흥미로운 로직은 애플리케이션 코드 내부에 숨어있었고, gdb와 같은 디버거를 사용해 단계별로 실행할 수 있었습니다. 트러블슈팅할 때도 대시보드를 보고 직감적으로 3~5개의 모놀리딕 구성요소 중 어떤 요소에 결함이 있는지 알 수 있었죠.

이것은 점점 사실이 아니게 됐습니다. 지난 5년 이상의 모든 인프라/아키텍처 동향을 살펴보십시오. 컨테이너, 스케줄러, 마이크로서비스, 다중 언어(polyglot) 지속성, 메시 라우팅, 임시 오토스케일링 인스턴스, 서버리스, 람다 함수. 요청은 엣지 이후 20~30홉을 수행하거나 — 데이터베이스 쿼리를 계산하는 경우 몇 배를 수행할 수도 있습니다. 이제 시스템 디버깅에서 가장 어려운 점은 코드가 어떻게 동작하는 지가 아니라, 어디에 문제가 있는 코드가 있는지 시스템상에서 찾는 것입니다. 일반적으로 대시 보드나 서비스 맵만 보고 어떤 노드나 서비스 혹은 구성 요소가 느린지 확인할 수 없습니다. 이들은 다시 자기 자신으로 돌아가기 때문에 — 어떤 것의 속도가 느려지면, 모든 것의 속도가 느려집니다. 오늘날의 현대적 클라우드 네이티브 환경은 기본적으로 플랫폼입니다. 즉, 코드 "내부" 및 쿼리가 단일팀의 제어 아래에 있지 않을 수 있습니다.

모놀리딕을 무수히 많은 서비스로 부풀렸을 때, 우린 디버거로 코드를 단계별로 실행할 수 있는 능력을 상실했습니다: 이제 네트워크를 넘나듭니다. 우리의 툴들은 여전히 이러한 극적인 변화에 맞서고 있습니다.

Parse로 돌아가서, 사용자는 "Parse가 다운됐어!"라고 문의를 할 수 있습니다. 우리 모니터링 툴은 Parse가 다운되지 않았음을 분명히 보여줍니다. 그렇다면 사용자는 무얼 보고 다운됐다고 말하는 걸까요? 글쎄요, 우리는 조사를 위해 누군가를 붙이겠지만, 그것은 완전히 명확하지는 않았습니다; 개발자는 자신의 코드와 쿼리를 업로드할 수 있었고, 우리는 수십만 개의 다른 인접 앱과 공유되는 하드웨어에서 작동하도록 만들어야 했습니다. 따라서 문제는 아마 다음 중 하나였을 겁니다.

  1. 개발자들의 코드나 쿼리 변경
  2. 우리의 코드나 쿼리 변경
  3. 이 두 변경의 교집합
  4. 문의를 제기한 사용자와 리소스를 공유하는 사용자의 코드나 쿼리 변경
  5. 리소스를 공유하는 사용자에게 영향을 미치는 일부 우리의 코드나 쿼리 변경
  6. 이들의 교집합

아, 그리고 우리는 백만 개가 넘는 앱을 가지고 있었고, 그들 모두에 영향을 미치는 코드를 지속해서 제공했고, 그들 각각은 독자적인 전체 유저 생태계를 가지고 있었으며, 그들은 또 그들 자신의 사용자에게 지속해서 영향을 미치는 자체 코드를 제공했습니다.

그것 참 좋은 때였죠.

모니터링 툴은 안정적인 아는-모르는 것들(known-unknowns)과 비교적 적은 수 모르는-모르는 것들(unknown-unknowns)의 집합으로 이뤄진 시스템에서 효과적입니다. 모르는-모르는 것들이 대부분인 시스템의 경우, 모니터링 툴은 거의 쓸모 없었습니다. 우린 문자 그대로 손으로, 고통스럽게, 그리고 천천히 디버깅해야 했습니다. 사용자의 불만을 추적하거나, 실제로 "그들" 쪽에 있는 문제라고 결정하는 데까지 하루 이상이 걸리는 경우가 많았습니다. 마침내 우리를 구한 솔루션은 Parse가 인수된 후 사용하기 시작한 Facebook의 Scuba였습니다. 우린 Scuba에 데이터 셋을 공급하기 시작했고, 사용자 ID, 엔드 포인트, 쿼리 등 임시 차원별로 데이터를 분할 할 수 있었습니다. 이로 인해 문제를 식별하는 데까지 걸리는 시간은 하루에서 몇 분으로 줄었고 심지어 몇 초까지로 줄었습니다.

이 경험은 저에게 깊은 인상을 주었지만, 당시에는 이를 설명할 단어가 없었습니다. "관찰 가능성"이라는 용어를 우연히 발견하고, 그 유래를 알아보고 나서, 이해 가능한 소프트웨어 시스템을 구축하는 법에 대해 얼마나 많은 것을 가르쳐야 하는지 깨달았습니다.

현실에서의 관찰 가능성은 어떠한가?

기억의 길을 거슬러 올라, 다시금 정의를 살펴봅시다.

관찰 가능성은 시스템의 외부 출력에 대한 지식으로부터 시스템의 내부 상태를 얼마나 잘 추론할 수 있는지를 나타내는 척도입니다.

조금 느슨하게 얘기하면, 이는 곧 시스템의 출력으로 전체 시스템의 동작을 확인할 수 있다는 것을 의미합니다. 만약 시스템이 관찰 가능하지 않은 상태라면, 이 말은 시스템의 상태값 중 일부는 출력 센서를 통해 현재 상태를 확인할 수 없다는 뜻이기도 합니다

무슨 일이 일어나고 있는지 파악하기 위해 여러 대시보드를 살펴보는 것은, 무슨 일이 일어나는지 조사하고 이에 대해 추론하거나, 의미 있는 탐색 경로(breadcrumb)를 거슬러 올라가는 것이 아닙니다. 이는 과정을 뛰어넘고 단숨에 결론에 도달하는 것, 즉 단순한 추측(guess)입니다. 마치 전체 시스템이 여전히 큰 블랙박스로 되어 있고, 어떤 순서로 무슨 일이 일어났는지 추론할 정보가 없는 것과 같습니다. 머릿속 생각의 흐름은 아마도 다음과 같을 것입니다.

나는 오늘 오후 2시에 엣지에 오류가 급증하는 것을 보았다. 예기치 못한 일이고, 아마도 상황은 나쁘다. 이 특정 DB 클러스터의 오류가 급증하는 것과 관련이 있어 보인다. 지난번에 이런 일이 일어났을 때는 누군가 잠금 경쟁을 유발하는 실행 시간이 긴 쿼리를 실행하였던 것이 원인이었지. 내 가설을 검증하기 위해 실행 시간이 긴 쿼리와 그 쿼리가 실행된 시간대의 대기열 길이 증가를 확인해야지. 좋았어, 하나 찾았고 — 내 이론은 검증됐다.

논리의 비약과 머릿속 장애 기록에 얼마나 의존하고 있는지 보세요. 이상적으로, 가능한 해결책으로 즉시 뛰어가는 대신, 열린 마음으로 맨 위에서부터 시작합니다 — "무슨 일이 있었지?" 그리고 데이터 기반의 탐색 경로를 체계적으로 따라가면서 검증 가능한 솔루션으로 이동합니다. 마치 이렇게요:

나는 오늘 오후 2시에 엣지에 오류가 급증하는 것을 보았다. 한 번 살펴보자. 나는 복제 셋(replica set) 단위로 쪼개 보기로 했다. (엔드포인트, 사용자 또는 말 그대로 뭐든 지 가능하지만, 일단 복제 셋이라고 가정합시다.) 좋아, 복제 셋1에 오류가 급증했고, 그보다 훨씬 적은 수의 오류가 다른 두 복제 셋 4, 5에 있었다. 흥미로워. 대기열 길이는 에러가 늘어남에 따라 함께 서서히 늘어나는 것을 복제 셋 1에서 확인할 수 있었고, 그리고 4에서는 시간이 지나면서 위아래로 요동치고, 5에서는 작은 스파이크만 있다. 실행 시간이 긴 쿼리는 RS1에만 있고, 다른 둘에는 없다. EBS/IOPS의 일시적인 문제인지 궁금하군 — 그래서 나는 복제 셋 노드와 가용 존으로 쪼게 다른 가용 존에도 같은 증상이 있는지 확인하기로 했다. 좋아, 이건 아니고. 마이그레이션인가? 아냐, build_id가 변하지 않았어. 잠금 지속 시간을 합하고 이걸 user_id로 쪼개 누가 어떤 쿼리로 락을 걸고 있는지 보자 — 아! 이건 만료된 백그라운드 크론잡이 원인이로군! RS1에 오래된 데이터가 더 많기 때문에 RS4/5보다 더 오래 지속된 거야. 이런 식으로 잠금 경쟁이 일어나지 않도록 리워크를 진행하자.

저는 이것을 단계별로 가설을 좁혀나가는 길고, 고통스럽고, 수동적인 방법으로 설명하고 있습니다. 이러한 방식으로 디버깅하는 것에는 탐색 경로와 같이 여러 개의 작고 검증 가능한 가설이 차례대로 포함됩니다. 오직 카디널리티가 매우 높은 차원을 포함하여, 모든 차원으로 쪼갤 수 있을 때만 가능한 방법입니다. 오직 저장소에 기록을 쓰기 전에 미리 집계(aggregate)하지 않을 때만 가능한 방법이며, 사실, 모든 쿼리는 질문에 답하기 위한 읽기 시간에만 집계됩니다. 오직 요청과 작업 단위를 중심으로 적절한 추상화 수준에서 데이터를 수집할 때만 가능한 방법입니다 — 왜냐하면 요청은 사용자의 실제 경험에 매핑되기 때문입니다.

카디널리티 제한이 메트릭 기반 시스템의 유일한 문제는 아닙니다. 메트릭은 태그가 붙은 숫자에 불과합니다. 요청이 실행될 때 12개 혹은 100개의 메트릭이 작동할 수 있지만... 각각의 메트릭은 서로 연결이 끊어지게 되고 다시는 연결될 수 없습니다. 이는 해당 요청에 대한 모든 세부 정보와 컨텍스트를 결합하는 임의의 광범위한 이벤트와는 다릅니다. 많은 디버깅이 비정상적인 스파이크 혹은 다른 모양을 살펴본 후 오류가 가지는 특징(들)이나 이상치를 파악하는 과정으로 이루어져 있습니다. 이벤트의 결합 조직을 제거해냈다면 할 수 없는 일입니다; 그럼 할 수 있는 일은 추측뿐입니다. 이것은 디버깅이 아니고, 마술입니다.

반대로 이벤트를 사용하고 전체 컨텍스트를 전달함으로써, 시스템에 대한 어떤 질문이든 할 수 있고 내부 상태를 검사할 수 있고, 그리하여 시스템이 어떤 상태에 놓여져 있는지 이해할 수 있습니다 — 심지어 이전에 본 적도 생각해 본 적도 없는 상태일지라도! 상태를 다루기 위한 새 코드를 작성하지 않아도 시스템 내부에서 발생하는 모든 상태를 이해할 수 있습니다. 이것이 핵심입니다. 이것이 관찰 가능성입니다.

당신은 당신이 예측했고 알아봤던 것은 언제든 이해할 수 있습니다. 하지만 당신이 확인했다는 것은 예상 할 수 있다는 것을 의미합니다. (즉, 예상하지 못한 것은 알아볼 수도, 이해할 수도 없기 때문에) 체크메이트군요. 모니터링이 오랫동안 잘 작동해 온 이유는 시스템을 구성하는 대부분의 상태를 예측할 수 있었기 때문입니다. 커넥션이 가득 차고, CPU가 과부하 되고, 앱 용량을 추가하거나 데이터베이스를 조정해야 하는 일 등. 대부분을 예측할 수 있었지만, 나머지는 어려운 방법을 써야 찾을 수 있었습니다. 시스템은 상대적으로 안정적이었고, 예측할 수 없는 유일한 문제는 코드를 배포하는 그들 자신의 팀에 의해 유발되는 것이었고, 그래서 많은 팀이 배포를 두려워하는 것입니다.

어느 정도 관찰 가능한 시스템은 상태를 이해하기 위해 추측, 패턴 매치, 혹은 새로운 코드를 내보내는 등의 작업을 하지 않아도 새로운 내부 시스템 상태를 이해할 수 있습니다. 제게 있어, 이것은 제어 이론 개념을 소프트웨어 엔지니어링으로 확장하는 가장 유용한 방식입니다. 아는-모르는 시스템 상태와 모르는-모르는 시스템 상태의 비율은 대부분 후자로 기울어지고 있습니다. 모르는-모르는 것들은 이제 모니터링 대시보드가 지속 가동 시간, 안정성, 그리고 가용 성능을 사람에게 설명하는 능력을 추월하고 있습니다.

이는 단순한 원격 측정과 구별하고 또 보존해야 할 가치가 있는 기술적 구별인데, 모르는-모르는 상태를 이해하는 능력은 현재 많은 팀이 부족하고, 이로 인해 계속 피해를 보고 있기 때문입니다. 현대적 분산 시스템과 서비스의 플랫폼화에 따라, 모르는-모르는 것은 당신의 남은 생애 동안 처리해야 할 문제의 대부분이 될 것입니다. 그것들을 잘 설명하는 것은 가치 있는 일입니다. 이러한 솔루션에 대한 기술적 어휘를 보존해야 할 가치가 있습니다.

관찰 가능성과 그 선구자

지난 3년 동안 "관찰 가능성"이 빠르게 발전했다는 것은 의심의 여지가 없으며, 이는 부분적으로는 용어를 희석하고 실무자들을 혼란스럽게 하는 상당한 시도들에도 불구하고 많은 사람이 "움직임"에 뛰어들었기 때문입니다. 한 발 짝 밖으로 나가 시간순으로 시장에서 어떤 일이 일어났는지 살펴보겠습니다.

저는 소프트웨어의 맥락에서 관찰 가능성을 언급한 최초의 사람이 아닙니다. 이 용어를 처음 들었던 건 Twitter의 "observability engineering" 이라 부르는 모니터링 팀을 만난 때입니다. 제가 말할 수 있는 한, 그들은 원격 측정의 동의어로 관찰 가능성을 사용하였습니다.

두 번째로 이 용어가 사용된 것을 만난 건, Cory Watson의 "Creating a culture of observability at Stripe" 라는 아티클이었습니다. Cory는 Twitter 팀의 매니저였습니다. 그것은 Honeycomb이 채택하고, 홍보하고 이를 위한 소프트웨어 솔루션을 구축하기 전까지 제가 아는 유일한 유산입니다.

이와 동시에, Google을 포함한 기술 거인들은 자체 관찰 가능성 플랫폼을 개발했지만, 그 자체를 "관찰 가능성"이라 부르지는 않았습니다. Dapper, Monarch 그리고 Dremel과 같은 도구는 처음에는 외부에 공개되지는 않았고, Google Cloud Platform이 출시될 때까지는 Google 내부용으로 구축되어 있었습니다. 이후 외부 시장용 이름이 필요해졌고, 비로소 Observability의 때가 됩니다. 때론 움직임을 만들기 위해 더 큰 플레이어 몇몇이 필요하죠.

현 Honeycomb의 수석 개발 지지자(dev advocate) Liz Fong-Jones은 전에 Google에서 다음과 같이 공유했습니다.

우리는 바깥 세계 사람들의 "모니터링(monitoring)" (Nagios, Splunk 등)을 훨씬 뛰어넘는 것을 때때로 "모니터링"이라고 부르곤 했습니다. 그러나 우리는 또한 2016년 3월에 발행한 SRE 책에서 "관찰 가능성", "관찰하다(observe)", "관찰(observation)" 이라는 단어를 병행하여 사용하기 시작했습니다.

2017년 11월, 구글 엔지니어 Janna B.Dogan은 "관찰 가능성"을 전면적으로 사용했으나 집계된 시스템 데이터를 인용하기 위해 사용됐습니다. 그 규모에서는 그걸로도 효과적이었기 때문입니다.

Honeycomb는 2016년 1월 1일에 설립됐습니다. 첫해에는 스토리지 엔진과 쿼리 플래너를 구축하여 카디널리티 제한에 영향을 받지 않고 확장할 수 있는 Honeycomb 제품의 강력한 기반을 만들었습니다. 2016년 중반, 저는 Parse/Facebook에서 직접 목격한 고통을 통해 우리가 하고 있던 일과 그 영향력이 소프트웨어 엔지니어링 팀에 미칠지에 대해 설명할 방법을 찾느라 고생하고 있었습니다. "시스템을 위한 비즈니스 인텔리전스", "분산 시스템을 위한 strace"와 같은 초기 노력은 제가 추구하던 충격을 가져오지 못했고, 당시에는 너무 부족해 보였습니다. 내 채팅 로그에 따르면, 2016년 7월에 관찰 가능성의 정의를 찾아보고, 그 이후로 계속해서 이야기를 이어가기 시작했습니다.

다가오는 폭풍의 선구자로서, Gregory Poirier는 2016년 6월 Monitorama에서 "Monitoring Is Dead" 라는 제목의 강연에서 당시 최첨단 기술을 사용해 프로덕션 시스템을 운영하려는 사람들의 투쟁에 관해 이야기했습니다.

2017년 5월, 저는 Monitorama에서 "Monitoring: A Post Mortem" 이라는 강연을 하여 카디널리티 제한과 모니터링 모델의 여타 고유한 문제에 관해 이야기 했으며, 마지막 슬라이드에는 내년에는 (Monitorama가 아닌) "observability-orama"에서 만나자고 전했습니다. 예상하셨겠지만, 일부 사람들은 언짢은 듯한 트윗을 보냈습니다.

그리고 2017년 9월, 엔지니어 Cindy Sridharan은 관찰 가능성에 대한 영향력 있는 글을 썼는데, 그 글에서 그녀는 우리의 관점을 대부분 수용하고, 아는-모르는 것과 모르는-모르는 것의 차이에 대해 더 많이 조명했습니다. 이를 통해 사람들이 모니터링, APM 및 로그 툴에 대한 불만족이 점점 더 커지고 있고 사람들의 요구를 충족하지 못하고 있다는 우리의 인식이 맞다는 것에 확신을 얻었습니다. 엔지니어들은 우리가 설명하는 모니터링 소프트웨어의 문제를 매우 잘 알아들었으며, 매일같이 증가하는 문제가 무엇인지, 어떻게 해결할지에 대해 기꺼이 듣고 싶어 했습니다.

2017년, Peter Bourgon 또한 관찰 가능성에는 세 개의 기둥이 있다는 아티클을 썼습니다. 벤더들은 이러한 대안적 정의에 맹렬히 빗장을 걸어 잠갔지만, 저는 Ben Sigelman의 Lightstep이 그들을 여기서 철저히 반박하도록 두겠습니다.

2018년 QCon 컨퍼런스는 "관찰 가능성" 트랙을 추가하였습니다. Serverlessconf 시리즈 또한 관찰 가능성의 열성적인 초기 도입자였는데 — 새로운 모델과 완벽하게 일치하는 서버리스의 특징이 있기 때문에 충분히 이해가 갑니다: 세상을 순수하게 그들의 장비를 통해 바라본다는 점이나, 디스크에 로깅 하지 않는다는 점, 요청에 따라 많은 정보를 빼곡히 집계한다는 점 등 말이죠.

마이크로서비스 커뮤니티와 쿠버네티스를 도입하던 이들도 초기에 관찰 가능성을 수용했습니다. 모놀리스를 폭파(혹은 분해)하면 대부분의 "전통적인" 디버깅 툴은 동작하지 않기 때문입니다. 첫 번째 원칙으로 돌아가 이러한 모든 결정을 다시 내려야 하며, 요청 ID로 집계하는 것이 가장 중요해집니다. 가장 어려운 부분은 코드 자체를 디버깅하는 것이 아니라, 분산 시스템 중 어디에 문제가 있는지 파악하는 것입니다.

그리고 2017년과 2018년 사이, 모니터링, APM 및 로그 관리 시장 부문의 모든 벤더는 콘텐츠, 사이트 및 마케팅 언어에 관찰 가능성이라는 용어를 추가했습니다. 이것은 얼마나 많은 사람이 관찰 가능성을 오용하고 다른 사람들을 잘못된 길로 이끄는지에 대한 다음 섹션으로 이어집니다.

관찰 가능성의 목적과 가치는 어떻게 잘못 표현되어 왔는가

저는 2018년 초반 벤더들이 "관측 가능성의 세 기둥"으로 "분산 추적, 메트릭, 로그"를 고수하고 있음을 알게 됐습니다. Ben Sigelman은 이것을 깔끔하게 반박하며 이렇게 말했습니다: 이것은 단순히 세 종류의 데이터 타입에 불과하기 때문에 의미가 없습니다. 세 가지 모두를 이용해서 혹은 그 어떤 것도 이용하지 않고 관찰 가능성을 달성할 수 있습니다 — 중요한 것은 데이터 자체가 아니라 그 데이터로 무엇을 하는지입니다.

오늘날 업계 컨퍼런스에 참석하면, 발표자가 정확한 정의에 집착하는 것을 듣게 될 것입니다 — 관찰 가능성은 모르는-모르는 것을 설명하는 방식이며, 대시보드와 패턴 일치 혹은 특정 데이터 타입에 접근하는 것이 아닌 탐색과 디버깅에 대한 것이라고요. 실무자들이 많은 모니터링 툴 벤더가 사용자에게 "세 기둥" 정의를 주입시키는 매스 마케팅에 거의 영향을 받고 있지 않다는 사실이 뿌듯하고 기쁘지만, 더 많은 소프트웨어를 전달하고 매출을 올리려는 수백만 달러의 광고비 지출에 대해 얼마나 더 버틸 수 있을 지 궁금하기도 합니다. 나는 희망적이며 이것이 단지 "엘리트"들에 한정한 것인지 또는 보다 기술적인 정의가 마침내 일반 대중들에게 닿은 건지는 잘 모르겠지만 — 지난 6개월 동안 그 초기 징후를 보아왔습니다.

저는 때때로 저희 제품의 마케팅 용어로 관찰 가능성을 사용하고 그 정의를 규정하는 것에 대한 비판을 받습니다. 사람들은 관찰 가능성을 "Honeycomb을 구성하는 일련의 기능" 이라 정의한다고 저를 비난합니다. 공정한 비판이죠! 그러나 그들의 인과관계는 뒤집혀있습니다. 관찰 가능성을 "Honeycomb이 하는 일" 이라 정의하는 것보다, 관찰 가능성이 먼저였습니다. 나는 이러한 문제들과 씨름하며 수년을 보냈고, 관찰 가능성의 정의와 그 부작용, 관찰 가능성 솔루션의 의미에 대해 몇 달을 고민했습니다. 예를 들어, 관찰 가능성은 다음 사항이 없으면 불가능 합니다:

  • 정제되지 않은 이벤트 (raw events)
  • 높은 카디널리티 차원
  • (당신을 사전에 정의된 질문에 갇히게 할) 사전 집계, 사전 인덱싱 없음
  • 읽는 시간에서의 집계
  • 임의의 광범위한 이벤트
  • 스키마 없음 (schema-less-ness)
  • 구조화된 데이터
  • 요청의 라이프사이클 지향
  • 일괄적으로 처리된 컨텍스트
  • 메트릭 기반이 아닐 것
  • 정적 대시보드는 동작하지 않으며, 탐색적이어야 함
  • 기타

그리고 저희는 이 스펙에 정확히 맞는 Honeycomb를 만들었습니다.

그래요, 저는 사람들이 관찰 가능성을 어떻게 사용하는 지에 주시할 것입니다 — 저는 그것이 실제 의미를 진정한 기술적 용어가 되길 간절히 원하고 있습니다. 소프트웨어 엔지니어링 팀이 직면한 문제를 해결하기 위해서는 이 특정한 기술적 언어가 필요합니다. 원격 측정에 대한 다른 동의어가 필요한 게 아닙니다; 그건 충분히 많이 가지고 있습니다.

아는-모르는 것과 모르는-모르는 것의 차이, 수동적 모니터링과 탐색적 디버깅의 차이를 나타내기 위해 "관찰 가능성"을 적절히 하지 않으면, 우리가 사용할 수 있는 다른 용어가 있을지 모르겠습니다. (그리고 그 용어도 같은 운명에 처할지도) 모니터링과 관찰 가능성 사이의 (실질적인) 기술적 차이를 명확하게 설명할 수 없다면 수년 후에는 업계가 뒤처질 것이라고 믿습니다. 그러나 이는 결국 현업의 엔지니어에게 달려 있습니다. 언어에 책임이 있는 (혹은 없을) 벤더를 억제할 수 있는 유일한 사람들 말이죠.

관찰 가능성의 미래

이 여정을 시작한 지 3년이 지나, 저는 이 질문을 깊게 생각해봅니다; 다음은 무엇이며, 이 움직임은 우리를 어디로 데려 갈까? 저는 향후 ~ 3년 내에 이 모든 세 가지 카테고리 (APM, 모니터링/메트릭, 로그 등) 가 더 이상 존재하지 않을 것이라고 생각합니다. 오직 하나의 카테고리, 관찰 가능성만 존재할 것입니다. 그리고 그것은 시스템이 처할 수 있는 그 어떤 상태도 이해할 수 있는 모든 인사이트를 포함할 것입니다.

결국, 메트릭, 로그 그리고 트레이싱은 임의의 구조화된 이벤트에서 사소하게 파생 될 수 있겠지만; 그 반대는 성립하지 않습니다.

사용자는 한 번만 저장해야 할 단일 데이터 셋을 저장하기 위해 여러 번 비용을 지불하고 있다는 사실을 알게 될 것입니다. 별도의 모니터링 벤더, 로깅 벤더, 트레이싱 벤더, 혹은 APM 벤더에 예산을 쏟을 이유가 없습니다. 임의의 구조화 된 이벤트에서 데이터를 수집하는 경우, 해당 이벤트에서 메트릭을 추론할 수 있으며 일부 단순한 스팬 식별자를 자동으로 추가하는 것으로 뷰 추적에 동일한 이벤트를 사용할 수 있게 될 것입니다. 지출을 3~4배 줄일 수 있을 뿐만 아니라 단일 도구를 사용하고 큰 그림을 보는 것과 ("그래프의 급상승을 발견했습니다") 바로 그 에러에 관한 정제되지 않은 이벤트에 깊게 파고드는 작업 사이에서 자연스럽게 왔다 갔다 할 수 있다면 훨씬 더 강력해질 것입니다. 다음으로, 공통된 이상 값에 대한 계산을 하고, 그 중 하나를 파고 들고, 문제가 있는 위치를 파고 들어, 특정 이상 행동의 영향을 받는 다른 사람을 파악합니다. 이 모든 것은 모든 팀이 동일한 수준의 가시성을 확보하는 단일 솔루션에서 수행됩니다.

지금 당장 이것은 a) 불가능하거나 b) 인간이 한 시스템에서 다른 시스템으로 ID를 붙여넣어야 합니다. 이는 낭비가 심하며 느리고, 번거롭고, 문제를 해결할 때마다 이 작업을 해야하는 팀에게 극도의 좌절감을 안깁니다. 툴은 사일로를 만들고 사일로화 된 팀은 당면한 문제 대신 현실의 섭리에 대해 논쟁하는 데 너무 많은 시간을 보냅니다.

당신의 코드와 끊임없는 대화를

우리는 소프트웨어 엔지니어에게 연락을 해 프로덕션에서 자신의 코드를 진정으로 이해할 수 있도록 돕고 있습니다. 우리는 개발자가 프로덕션에서 테스트하고, 카오스 엔지니어링, 피처 플래그 및 기타 현대적인 시도들을 할 수 있도록 지원하고 있습니다.

3년 전, 이것은 업계에서 활발한 논쟁거리였습니다. 이 싸움은 끝났습니다; 이제 우리는 양질의 서비스를 구축하는 유일한 방법은 소프트웨어 엔지니어가 프로덕션 단계에서까지 오너십을 잃지 않도록 하는 것이라는 걸 알고 있습니다. 남은 것은 오직 구현뿐이며, 이는 아직 진행 중이고 향후 10년 정도 계속해서 진행될 것입니다. 이렇게 해서 우리 업계는 지속적으로 제공자가 대규모 서비스를 운영할 수 있도록 유도하고 있습니다.

개발자... 뿐 아니라 관련된 팀을 위해서도

또한 엔지니어링을 위해 이를 구축하고, 개선하고, 유지하는 것을 완벽히 한 후, — "제가 전한 제품이 제 예상대로 작동하는 지 확인하고, 다른 것은 이상하게 보이지 않은지 확인하는" 빡빡하고 고결한 피드백 루프를 받고, 성공적으로 개발자에게 연락을 한 후 — 다음 개척지는 엔지니어링에 인접한 팀에 실제 프로덕션에 대한 인사이트를 드러내는 것이라고 생각합니다. 지원, 고객 서비스, PM, 심지어 이러한 시스템의 비즈니스 오너도 업무상 중요한 애플리케이션에서 무슨 일이 일어나고 있는 지 깊게 이해함으로써 얻을 수 있습니다. 툴은 사일로를 만듭니다 — 팀에서 어떤 툴을 사용하고 다른 팀에서 다른 툴을 사용하는 경우, 동일한 세계관을 공유하지 않습니다. 실제 문제를 해결하기 전에 현실을 어떻게 바라보고 있는 지에 대한 의견 차를 좁히는 데 많은 시간을 할애하게 될 것입니다.

우리는 다른 팀이 엔지니어의 개입 없이도 방대한 양의 디버깅과 문제 해결을 수행할 수 있도록 지원할 수 있습니다. 지원 팀이 티켓을 열고 엔지니어에게 전달하기 전에, 사용자 ID에 연결하고 불만 사항과 알려진 버그가 일치하는지, 이미 수정되었는지, 혹은 애초에 이것이 진짜 존재하는지를 확인하기 위한 몇몇 질문 템플릿 셋을 상상해보세요. 다른 사람들의 질문에 답하기 위해 프로덕션에 있는 여러 사람들에게 전화를 걸어대며 시간을 보내는 것을 상상해보세요. 그리고 이제 그 어떤 것도 할 필요 없다고 상상해보세요.

모든 사람이 프로덕션에 대한 이해에 가까워질수록 승리할 것입니다.

TL;DR... 인간에 관한 이야기입니다.

이 전투의 승자는 최고의 엔드 유저 경험을 제공할 수 있는 이가 될 것입니다. Mike Julian이 그의 Monitoring and Observability 2019 Predictions에서 말했듯이, 분산 시스템을 이해하고 추적 가능할 있게 만들기 위해서는 역사, 사회적 공유, 그리고 다른 팀을 서로 아는 것이 필요합니다.

AI와 ML은 강력한 (그리고 어쩌면 위험한) 도구이지만, 너무 많은 조직이 주객이 전도된 상황에 처할 위험을 감수하고 있습니다. 모든 기계는 갑작스런 에러의 상승을 감지할 수 있지만, 그것이 나쁜지, 좋은지, 바람직한지, 예상대로인지, 두려운지는 오직 인간만이 알 수 있습니다. 인간만이 숫자에서 의미를 도출할 수 있습니다.

우리는 디버깅은 영원히 인간 중심적 과정이어야 한다는 Allspaw의 선언을 믿습니다. 우리의 목표는 가능한 즐겁고 함께하는 과정을 만드는 것이어야 합니다.