관찰 가능성, 3년을 돌아보며 - 3

원문: Observability — A 3-Year Retrospective

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

저는 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의 선언을 믿습니다. 우리의 목표는 가능한 즐겁고 함께하는 과정을 만드는 것이어야 합니다.