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

원문: Observability — A 3-Year Retrospective

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

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

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

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

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

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

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

나는 오늘 오후 2시에 엣지에 오류가 급증하는 것을 보았다. 한 번 살펴보자. 나는 복제 셋(replica set) 단위로 쪼개 보기로 했다. (엔드포인트, 사용자 또는 말 그대로 뭐든 지 가능하지만, 일단 복제 셋이라고 가정합시다.) 좋아, 복제 셋1에 오류가 급증했고, 그보다 훨씬 적은 수의 오류가 다른 두 복제 셋 4, 5에 있었다. 흥미로워. 대기열 길이는 에러가 늘어남에 따라 함께 서서히 늘어나는 것을 복제 셋 1에서 확인할 수 있었고, 그리고 4에서는 시간이 지나면서 위아래로 요동치고, 5에서는 작은 스파이크만 있다. 실행 시간이 긴 쿼리는 RS1에만 있고, 다른 둘에는 없다. EBS/IOPS의 일시적인 문제인지 궁금하군 — 그래서 나는 복제 셋 노드와 가용 존으로 쪼게 다른 가용 존에도 같은 증상이 있는지 확인하기로 했다. 좋아, 이건 아니고. 마이그레이션인가? 아냐, buildid가 변하지 않았어. 잠금 지속 시간을 합하고 이걸 userid로 쪼개 누가 어떤 쿼리로 락을 걸고 있는지 보자 — 아! 이건 만료된 백그라운드 크론잡이 원인이로군! 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 및 로그 관리 시장 부문의 모든 벤더는 콘텐츠, 사이트 및 마케팅 언어에 관찰 가능성이라는 용어를 추가했습니다. 이것은 얼마나 많은 사람이 관찰 가능성을 오용하고 다른 사람들을 잘못된 길로 이끄는지에 대한 다음 섹션으로 이어집니다.