답없는 세 기둥
Ben Sigelman의 글을 번역한 포스팅입니다. 저자에게 번역 후 게재를 허락 받았습니다. Observability 관련해서 SaaS 솔루션들을 찾아보다가 비용 관점에서도 그렇고 구성 후 사용 관점에서도 그렇고 혼란에 빠져 있던 중, “관찰 가능성, 3년을 돌아보며” 블로그 글을 읽으면서 많은 공감이 들었습니다. 그 글 안에서 인용한 Ben Sigelman의 “Three Pillars with Zero Answers”를 읽고 번역해보았습니다.
불문율
“Observability의 세 기둥”에 대해 들어본 적 있나요? 없어요? 그 이야기는 이렇게 시작합니다:
마이크로서비스 구조를 사용하고 있다면, 이미 고전적인 모니터링 툴들로는 서비스의 상태를 이해할 수 없다는 사실을 알고 있을 겁니다. 마이크로서비스 구조 자체가 “피자 두판”으로 먹일 수 없는 크기의 DevOps 팀을 피하기 위해 만들어졌고, 그렇기 때문에 특정 개인이 전체 서비스를 아는것은 거의 불가능에 가깝습니다. 심지어 가까이 이웃한 서비스들에 대한 이해도 쉽지 않습니다.
뭐… 그래도, 구글이나 페이스북, 넷플릭스는 “마이크로서비스”라는 단어가 생기기도 전부터 마이크로서비스 구조의 서비스를 만들고 있었고, 트위터의 한 글에서 보니 저런 문제들을 이미 해결했다고 하더군요, 휴… 메트릭, 로깅, 분산 트레이스를 사용해 저 문제들을 해결했다고 하니, 여러분들도 똑같이 문제를 해결하면 되지 않을까요? - 이 세가지가 “Observability의 세 기둥”이라고 불립니다. 그리고 이미 저것들이 어떻게 생겼는지 알고 있을겁니다.
(메트릭!) 
(로그!) (트레이스!)
그러니까, 구글이나 페이스북, 트위터에서 했듯 Observability에 대한 문제를 해결하고 싶으면… 간단합니다! 메트릭 솔루션, 로깅 솔루션, 트레이싱 솔루션들을 찾으면… 짜잔! 여러분의 devops팀은 분산 Observability의 따듯한 햇빛 아래 놓일 수 있습니다!
치명적 결함
물론 치명적 결함이라는 단어 자체는 좀 과장일 수 있습니다. 하지만, “세 기둥”을 단순한 기술로 배포한 사람들의 “따듯한 햇빛”은 치명적 결함들이 보이며 금새 따듯함을 잃었습니다.
메트릭과 카디널리티
메트릭의 경우, “카디널리티”라는 단어를 짚고 넘어갈 필요가 있습니다. 메트릭은, 구불구불한 선으로 보기 편하게 위아래로 널뛰며 어떤 나쁜일이 일어나는지 쉽게 알 수 있다는 이점이 있습니다. 하지만, 이상이 발생했을 때 단순히 메트릭만 가지고 깊이 진단할 수는 없습니다. 여기서 우리는 “깊이 파 들어가는” 선택을 할 수 있습니다. 메트릭들을 “태그”해서 그룹화 하고, 특정 태그의 값에서 이상을 찾고, 해당 태그 그룹에서 또 이상이 있는 특정 태그를 찾아가는 방향으로 “깊이 파 들어갈”수 있습니다.
“카디널리티”는 집합에서의 원소 값을 뜻합니다. 메트릭에서의 “카디널리티”는 태그의 수 입니다. {= 수집되는 시계열 메트릭의 수} 5개? 괜찮습니다. 50개? 그정도도 괜찮을 수 있습니다. 500개? 아마 꽤 비쌀겁니다. 1000개가 넘어가면, ROI{투자 대비 이득}가 터져버릴지도 모릅니다. 불행인 점은, 많은 실 생활의 태그들은 수 천개, 수 만개가 되기도 한다는 것입니다.(e.g., user-id, container-id, 등등) 따라서, 탐사를 한다는 관점에선 메트릭은 더이상 우리의 길이 되지 못합니다.
많은 양의 로그 /w 마이크로서비스
로그의 경우, 문제 묘사가 훨씬 쉽습니다: “너무 비싸요” -끝- 작년 모니터링 컨퍼런스 조찬 발표장에 참석했었는데, 그 때 아주 똑똑하고 인지도 있을 뿐만 아니라 내노라 하는 테크 회사에서 로그 방면으로 일하고 있던 다른 연사자가 있었습니다. 그 사람이 다음날 “마이크로서비스 구조에서의 로깅” 이라는 주제로 발표를 한다길래 호기심이 발동해 “기본적 원칙을 뭘로 두고 일하시나요?” 하고 물어봤는데, 예상치 못한 대답이 돌아왔습니다. “아, 간단합니다. 우린 더이상 로그하지 않아요.”
왜일지 생각해보면 간단합니다. 각각의 트랜잭션에 하나하나 로그를 하다 보면(흔히 모노리틱 서비스를 구성하듯) 우리는 다음과 같은 영수증을 받게 됩니다.
어플리케이션 트랜잭션 수 x 모든 마이크로서비스 수 x 네트워크 및 스토리지 비용 x N주간의 데이터 리텐션 => 엄청난 비용
로그의 수가 각 트랜잭션 당 거치는 마이크로서비스의 수에 비례해 배로 늘기 때문에, 로그 시스템들은 모든 트랜잭션 로그들을 전부 저장하기 힘듭니다. 저장하는데 많은 비용이 든다는 것 외에도, 로그를 이해하기 위해 마이크로서비스 트랜잭션에서 발생하는 동시성과 인과관계를 별도로 분석해야 하기 때문에 로그 자체가 그렇게 도움이 되지도 않습니다. 그렇기에, 옛날부터 쓰던 로깅 방식은 우리의 “멋진 신-아키텍처-세계”에서는 충분하지 않습니다.
트레이싱과 사전지식
다음으로 자연스럽게 “분산 트레이싱”으로 이어집니다. 위에 언급한 로깅 시스템의 문제를 해결하기 위해 개발된 기술이죠. 구글에 있을 때 Dapper 프로젝트{“분산 트레이싱”의 시초 프로젝트}를 직접 개발했었습니다. 정상 상태에서의 지연시간 분석을 하는데 잘 써먹었지만, 엄청난 데이터 양 문제를 해결하기 위해 무식하게 완전 랜덤으로 아주 적극적인 샘플링이 필요했습니다. 이 엄청난 데이터 양 문제는 오랫동안 껄끄러운 문제로 남아있었고, Dapper 프로젝트를 관제 상황에 바로 적용하기 어려운 이유이기도 했습니다.
샘플링을 하지 않는게 가장 간단한 답입니다. 하지만 큰 규모로 스케일된 마이크로서비스 구조에서는, 비용때문에 그 답은 생각도 할 수 없습니다. 만약 샘플링을 한다면 트랜잭션이 끝나는 시점으로 샘플링 결정을 미루는게 자연스러운데, 이것 역시 어떤 트레이스를 샘플할지 어떻게 고르냐 라는 문제가 있습니다. 우리가 각각의 트레이스를 분석한다고 하면, 느려서 에러가 될 가능성이 있는 트레이스들에 초점을 맞춥니다. 하지만, 제품의 성능 및 안정성 문제는 대체로 트랜잭션간의 영향에 의한 부산물 입니다. 따라서 이런 영향을 이해하고 샘플링이 진행되어야 합니다. 그 결과, 같은 자원을 공유하여 서로 연관있는 트레이스들을 수집하는 아주 복잡한 샘플링 전략을 낳습니다.
단순히 각각의 트레이스를 보는것은 때때로 유용할지 모릅니다만, 수많은 트레이스 중 바로 그 트레이스가 유의미한 인사이트를 줄 수 있을지는 기도를 올리며 찾아보는 수 밖에 없습니다. 반면, 적절한 분산 트레이스를 샘플링하여 의미 있고 실제로 접근 가능한 인사이트를 추출하는것은 아주 넓고 어려우면서 가치가 있는 문제일 겁니다.
그리고 애초에 구글을 모방하려는 것의 문제점…
“세 기둥”이야기의 또다른 문제점은, 구글(이나 페이스북, 트위터 등)의 “행성 단위”급에서나 적합한 소프트웨어를 항상 흠모하고 따라하려는 바로 그 어리석은 생각입니다. 짧게 말하자면, “구글을 모방하지 마세요.” 구글을 뭐라 하는게 아닙니다. 구글엔 대단한 사람들이 있고, 그들은 요청받은 엄청난 일들을 해냈습니다.
하지만! 구글의 기술들을 대체로 엄청난 범위로 스케일될 수 있도록 설계되고, 그건 꼭 “좋지”많은 않습니다. 제프 딘(대단한 구글러 들 중 한명이자, 자기 이름으로 된 밈이 있는 사람)이 종종 3~4배보다 큰 단위로 확장될만한 소프트웨어 시스템을 설계하는게 왜 거의 불가능한 일에 가까운지 말하고는 했습니다. 그에 더해, 시스템의 기능과 확장 가능성 사이에는 태초부터 존재하는 긴장의 끈이 존재합니다.
구글의 마이크로서비스들은 1초에 50억개의 요청을 발생합니다. 초당 50억개의 요청을 처리할만큼 스케일링 되는 Observability 도구는 애초에 기능 관점에서 좋을 수가 없습니다. 만약 당신의 조직이 초당 5백만개의 요청을 처리한다면, 그래도 꽤 인상깊지만 그래도 구글이 하듯 하면 안됩니다. 여전히 구글에 비해 1/1000 수준이고, 그 정도의 스케일이면 훨씬 더 많은 기능들을 사용하는데 문제가 없습니다.
Bits vs Benefits
네, 각 “기둥”들은 치명적 결함이 있고(그냥 “세 결함” 일지도 모르지만.) 그 결함은 우리에게 문제로 다가옵니다. 또 다른 문제가 있는데, 메트릭/로그/트레이스가 그저 “디지털 비트” 에 불과하다는 근본적인 문제입니다. 각각은 데이터 구조의 특정 타입으로 묘사되고, 우리는 각 타입의 가장 간단한 시각화를 먼저 떠올리는 경향이 있습니다. 메트릭은 위아래로 움직이는 선, 로그는 포멧된 스트링의 시간 순서 리스트, 트레이스는 흔히 보는 폭포수 타이밍 도표가 먼저 떠오릅니다.
하지만 위에 언급한 것 모두 불편한 부분을 해결해준다거나, 용례가 있다거나, 비즈니스 니즈등과 직접적으로 연관있지 않습니다. “세 기둥” 불문율 때문에 우리는 메트릭, 로그 및 트레이스를 분석하는 복잡한 작업들을 그것을 보는사람에게 암묵적으로 위임 하고 있습니다. 그리고, 위에 언급한 결함들과 각 세가지 데이터 타입끼리의 미묘한 관계, 상호의존성까지 합쳐져 우리의 Observability 과정은 늘 고통을 받는 결과에 놓여 있습니다.
다음 이시간에는…
우리는 “메트릭, 로그, 트레이스”를 다시 제자리로 돌려놓을 필요가 있습니다. 메트릭, 로그, 트레이스는 연료이지 자동차가 아닙니다. 조금 더 멀리 보고 구현을 해야 합니다. 우리는 새로운 점수기록표가 필요합니다! 다음 포스팅에선 이성적이자 독립적으로 Observability 전략을 측정하고 평가하기 위한 새로운 방법을 소개해드리겠습니다.