관측성

서버가 한 대이던 시절에는 이 말이 필요 없었습니다. 무언가 이상하면 그 서버에 접속해 로그 파일을 열어 보면 됐습니다. 로그는 프로그램이 돌면서 "몇 시에 무엇을 했다" 를 한 줄씩 남겨 놓은 글이고, 파일 하나를 끝까지 읽는 데 오래 걸리지 않았습니다.

서버가 열 대가 되고 하나이던 프로그램이 문서·권한·결제처럼 여러 조각으로 쪼개지면서 그 방법이 통하지 않게 됐습니다. 사용자가 저장 버튼을 한 번 누르면 그 요청이 조각 넷을 차례로 거치는데, 실패했다는 사실만 알 뿐 어느 조각에서 멈췄는지는 아무도 몰랐습니다. 열 대에 흩어진 로그를 하나씩 열어 시각을 맞춰 가며 읽는 일이 원인 찾기의 대부분을 차지했습니다.

그래서 장애가 나면 회사는 늘 같은 장면을 반복했습니다. 고객이 저장이 안 된다고 알려 오면 개발자 셋이 각자 다른 서버에 들어가 각자 짐작한 파일을 열고, 한 시간쯤 뒤에 "제 쪽은 멀쩡한데요" 세 마디가 모입니다. 그 사이 대시보드의 서버 상태는 계속 초록색이었습니다. 미리 만들어 둔 화면은 CPU 사용률이나 메모리 사용량처럼 만들 때 정해 둔 질문에만 답합니다. 서버가 몇 대 살아 있느냐는 질문에는 답하지만, 권한을 확인하는 조각이 특정 문서에 대해서만 느려졌느냐는 질문에는 답하지 못합니다. 이번 고장은 뒤쪽이었고, 그런 고장은 매번 모양이 달라서 질문 목록에 미리 넣어 둘 수도 없었습니다.

관측성은 그 지점을 뒤집은 개념입니다. 고장이 날 때마다 서버에 들어가 확인하는 대신, 시스템이 스스로 충분한 신호를 밖으로 내보내게 미리 만들어 둡니다. 신호가 충분하면 처음 보는 고장을 만나도 서버에 다시 들어가지 않고 이미 나와 있는 자료만으로 원인을 좁힐 수 있습니다. 갖춘 정도를 가리키는 말이라 있고 없고로 나뉘지 않고, 처음 보는 질문에 답할 수 있는 범위가 얼마나 넓은지로 따집니다.

엔지니어링 축에서 서비스가 도는 동안을 보는 갈래는 셋입니다. 관측성이 안을 들여다볼 수단을 미리 심어 두는 일이라면, 장애 대응은 실제로 멈췄을 때 누가 먼저 움직이고 무엇부터 되살릴지를 정해 둔 절차이고, DORA 지표는 이 조직이 얼마나 자주 안전하게 내보내는지를 배포 횟수와 복구 시간 같은 네 값으로 잽니다. 셋 가운데 관측성이 가장 앞에 옵니다. 심어 둔 신호가 없으면 장애 대응은 시작 신호를 고객 문의에서 받게 되고, 복구 시간을 재려 해도 장애가 언제 시작됐는지를 적을 수가 없습니다.

이 아래 묶인 용어는 세 갈래입니다. 무엇을 내보낼지 정하는 수단, 그 신호를 모아 보여 주는 도구, 그리고 모인 값으로 어디까지를 정상으로 볼지 정하는 신뢰성 목표입니다. 순서대로 신호를 만들고, 읽고, 판정합니다.

수단은 시스템이 밖으로 내보내는 신호의 종류를 다루는 갈래로 넷이 있습니다. 앞의 셋은 서로 다른 질문에 답하고, 넷째는 그 답을 사람에게 전달합니다.

1. 로깅 — 벌어진 일을 한 줄씩 글로 남깁니다. "14시 02분, 사용자 8821의 문서 저장 요청이 타임아웃으로 실패" 같은 줄입니다. 사건 하나의 사연을 가장 자세히 담지만, 하루에 수백만 줄이 쌓이므로 어디를 봐야 할지 모르면 아무 소용이 없습니다.
2. 메트릭 — 같은 종류의 값을 세어 시간축에 쌓습니다. 분당 요청 수, 실패율, 응답 시간 같은 것들입니다. 실패율이 0.2퍼센트에서 14퍼센트로 튄 시각이 14시 01분이라는 사실을 1초 단위로 짚어 주지만, 왜 튀었는지는 말해 주지 않습니다.
3. 분산 추적 — 요청 하나가 조각들을 거친 경로를 순서대로 이어 붙입니다. 저장 요청이 문서 조각을 지나 권한 조각에 1.8초를 머물다 저장소로 갔다는 사실이 한 줄에 보입니다. 조각이 여럿일 때 어느 조각이 느린지는 이 방법이 아니면 짐작으로만 남습니다.
4. 알림 — 정해 둔 조건을 넘으면 담당자에게 연락이 가게 만든 장치입니다. 앞의 셋은 누군가 보고 있어야 쓸모가 있지만, 새벽 세 시에 화면을 보고 있는 사람은 없습니다.

앞의 세 가지는 대체재가 아니라 분업 관계입니다. 메트릭이 언제부터인지를, 추적이 어느 조각인지를, 로깅이 무엇 때문인지를 맡습니다. 하나만 심어 두면 매번 한 걸음에서 멈춥니다. 실패율 그래프만 있으면 14시 01분까지는 알아내고 거기서 서버에 들어가게 됩니다. 반대로 로그만 잔뜩 남겨 두면 문제가 있다는 사실 자체를 고객이 알려 줄 때까지 모릅니다. 셋을 같이 심을 때 드는 값도 서로 다릅니다. 로깅과 메트릭은 코드 몇 줄로 시작할 수 있지만, 추적은 조각마다 같은 표식을 달아 이어 붙여야 해서 손이 더 갑니다. 그래서 대개 메트릭과 로깅을 먼저 깔고, 조각이 늘어 원인 찾기가 길어질 때 추적을 붙입니다.

도구는 그 신호를 모아 사람이 읽을 수 있게 만드는 갈래로 둘이 있습니다. APM은 어느 화면과 어느 요청이 느린지를 응답 시간 중심으로 보여 줍니다. 에러 트래킹은 발생한 예외를 같은 것끼리 묶어 "이 오류가 오늘 4200번, 사용자 310명에게" 처럼 정리해 줍니다. 로그를 그대로 읽으면 같은 오류 4200줄이 서로 다른 줄로 보이지만, 묶어 놓으면 고쳐야 할 것이 한 건이라는 사실이 드러납니다. 둘은 겹치는 구간이 있어 한 제품이 양쪽을 다 하는 경우도 많습니다. 다만 도구가 대신해 주는 일에는 경계가 있습니다. 어느 요청이 느린지까지는 자동으로 잡아 주지만, 그 요청 안에서 팀이 만든 어느 단계가 느린지는 그 자리에 표식을 심어 둔 만큼만 보입니다.

신뢰성 목표는 모인 값으로 선을 긋는 갈래로 다섯이 있습니다. 넷은 한 줄로 이어지고 하나는 그중 가장 오래된 형태입니다.

1. SLI — 서비스 품질을 실제로 재는 값입니다. 저장 요청 성공률이나 응답 시간의 상위 1퍼센트 구간처럼 사용자가 겪는 것에 가깝게 고릅니다.
2. SLO — 그 값을 어디까지 지키겠다고 팀이 정한 목표입니다. 저장 성공률 99.9퍼센트 같은 한 줄이고, 이 선이 있어야 알림을 걸 기준이 생깁니다.
3. 에러 버짓 — 목표를 지키면서 써도 되는 실패의 여유분입니다. 99.9퍼센트가 목표면 0.1퍼센트만큼은 실패해도 됩니다. 이 여유분이 남아 있으면 새 기능을 과감히 내보내고, 다 썼으면 안정화를 먼저 합니다.
4. SLA — 같은 약속을 고객과 계약서에 적은 것입니다. 지키지 못하면 요금 일부를 돌려주는 조건이 따라붙으므로, 보통 SLO보다 한 단계 느슨하게 적습니다.

가동률은 이 가운데 가장 먼저 쓰이던 값으로, 서비스가 정상 동작한 시간의 비율입니다. 한 달에 99.9퍼센트면 43분까지 멈춰도 된다는 뜻입니다. 다만 멈추지는 않았는데 모든 요청이 8초씩 걸리는 상태를 이 값은 정상으로 셉니다. 그래서 요즘은 가동률 한 줄 대신 SLI와 SLO를 함께 적는 쪽으로 옮겨 갔습니다.

세 갈래는 한 방향으로 흐릅니다. 수단이 신호를 만들고, 도구가 그것을 읽을 수 있게 정리하고, 신뢰성 목표가 그 값을 보고 지금이 괜찮은 상태인지 판정합니다. 앞이 비면 뒤가 성립하지 않습니다. 추적을 심지 않은 채 응답 시간 목표만 적으면 목표를 못 지킨 날에 무엇을 고쳐야 할지 알 방법이 없습니다. 반대 방향으로도 비면 곤란합니다. 신호를 아무리 촘촘히 심어도 어디까지가 정상인지 정해 두지 않으면, 응답 시간이 0.4초에서 1.1초로 늘어난 화면을 보고도 지금 손을 대야 하는지 다음 주에 봐도 되는지를 매번 회의에서 정하게 됩니다.

"로그만 봐서는 어느 단계에서 늦어졌는지 모르겠어요. 이 요청 추적 붙어 있나요?"

기록은 있는데 요청이 지나간 경로가 남아 있지 않아 원인을 좁히지 못한다는 뜻입니다.

"알림이 하루 마흔 번 울리면 아무도 안 봅니다. 목표치를 넘긴 경우만 울리게 다시 잡죠."

울리는 조건이 느슨해 진짜 장애가 묻히고 있으니 기준을 다시 세우자는 제안입니다.

"이번 달 여유분을 벌써 60퍼센트 썼어요. 다음 배포는 한 번에 열지 말고 나눠서 갑시다."

허용된 실패의 여유가 얼마 남지 않았으니 위험을 낮춰 내보내자는 말입니다.

페이지덱은 그 토요일 장애를 겪고 나서야 이 작업을 시작했습니다. 태오가 먼저 한 일은 도구를 고르는 것이 아니라 질문을 적는 것이었습니다. 지금 저장이 실패하고 있는가, 실패한다면 전체인가 일부인가, 어느 조각에서 멈추는가, 언제부터인가. 네 질문에 각각 어떤 신호가 있어야 답할 수 있는지를 적고 나니 심을 것이 정해졌습니다. 저장 요청의 성공률과 처리 시간을 숫자로 쌓고, 실패한 요청에는 사용자와 문서를 알아볼 수 있는 값을 로그에 붙이고, 조각을 넘나드는 요청에 같은 표식을 달아 경로를 잇는 것까지 셋이었습니다.

두 달 뒤 같은 증상이 다시 나타났을 때는 화면 하나로 끝났습니다. 실패율 그래프가 밤 11시 12분부터 꺾여 있었고, 추적 화면에서 권한 조각이 응답을 3초씩 끌고 있었으며, 그 조각의 로그에 연결 수가 한계에 닿았다는 줄이 반복되고 있었습니다. 태오가 서버에 접속한 것은 원인을 찾기 위해서가 아니라 고치기 위해서였습니다. 수아가 고객사에 안내를 보낸 시각이 지난번에는 복구 뒤였는데 이번에는 복구 전이었다는 점도 지현이 회고에서 짚었습니다.

도구를 도입하면 관측성이 생긴다고 생각하는 경우가 가장 많습니다. 설치하면 화면이 바로 채워지고 그래프가 예쁘게 그려지니 그렇게 보입니다. 하지만 도구가 자동으로 모아 주는 것은 어느 서비스에나 있는 공통 신호뿐입니다. 이 팀의 저장 기능이 어느 단계에서 실패했는지는 그 코드에 사람이 직접 남겨 둬야 나옵니다. 이 차이를 모르고 계약부터 하면 월 수백만 원을 내면서 정작 장애가 났을 때 보는 화면은 여전히 CPU 그래프인 상태가 됩니다.

많이 남길수록 좋다고 여기는 것도 흔합니다. 나중에 필요할지 모르니 일단 다 남기자는 판단은 합리적으로 들립니다. 실제로는 두 가지가 같이 무너집니다. 하나는 비용입니다. 저장하고 검색하는 값이 남긴 양에 비례해서 붙기 때문에, 쓰지 않는 로그가 서버 비용보다 커지는 일이 드물지 않습니다. 다른 하나는 신호가 소음에 묻히는 것입니다. 정상 동작까지 전부 기록하면 장애 순간의 결정적인 한 줄이 같은 시각의 3만 줄 사이에 끼고, 찾는 데 걸리는 시간은 아무것도 안 남겼을 때와 비슷해집니다. 무엇을 남길지는 앞서 나온 질문 목록에서 거꾸로 정합니다. 답해야 할 질문을 먼저 적고 그 질문에 필요한 신호만 남기면, 양은 줄고 장애가 났을 때 보는 화면은 오히려 또렷해집니다.