SLI

"지금 서비스 괜찮은가" 라는 질문에 자리마다 다른 답이 나오던 시절이 있었습니다. 서버를 보는 사람은 프로세스가 살아 있고 CPU 사용률이 40퍼센트니 정상이라고 답하고, 고객 문의를 받는 사람은 저장이 안 된다는 메일이 쌓이고 있다고 답합니다. 두 사람이 서로 다른 것을 보고 있었으니 둘 다 맞았습니다.

문제는 재는 값이 시스템 쪽 사정이었다는 데 있었습니다. CPU 사용률, 메모리 여유, 디스크 남은 용량은 서버를 돌보는 사람에게 필요한 값이지만 사용자가 겪는 것과 직접 이어지지 않습니다. 사용자는 CPU 를 겪지 않습니다. 저장 버튼을 눌렀을 때 저장이 되는지, 얼마나 기다려야 하는지를 겪습니다.

태오가 실제로 이런 아침을 보냈습니다. 대시보드는 전부 초록인데 문의는 열두 건이 쌓여 있었습니다. 특정 지역에서 들어오는 저장 요청만 시간이 초과되고 있었는데, 서버 쪽 숫자에는 그 사실이 나타나지 않았습니다. 그 뒤로 팀은 재는 값을 사용자가 겪는 행동 쪽으로 옮겼습니다. SLI 는 그렇게 옮긴 값에 붙은 이름입니다.

좋은 이벤트 수를 전체 이벤트 수로 나누고 100을 곱합니다. 세 단계로 정합니다.

1. 사용자가 실제로 하는 행동 하나를 고릅니다. 문서 저장 요청, 문서 열기, 로그인처럼 실패하면 고객이 바로 아는 것을 고릅니다. 화면 단위가 아니라 요청 단위로 잡아야 세기 쉽습니다.
2. 무엇을 좋음으로 볼지 정합니다. 여기서 기준을 명시적으로 적는 것이 계산의 절반입니다. 저장 요청이라면 서버가 성공 응답을 돌려주고 그 응답이 2초 안에 왔을 때만 좋음으로 셉니다. 응답이 왔지만 9초가 걸렸다면 좋음이 아닙니다.
3. 기간을 정해 나눕니다. 보통 최근 28일을 매일 갱신하는 방식으로 봅니다. 달력 기준 월간으로 보면 1일에 값이 초기화되어 지난달 사고가 화면에서 사라집니다.

28일 동안 저장 요청이 1,240만 건 들어오고 그중 기준을 충족한 것이 1,238만 건이면 이 SLI 는 99.84퍼센트입니다. 이 값을 만드는 재료는 메트릭, 곧 같은 종류의 값을 세어 시간축에 쌓아 둔 관측 데이터입니다.

응답 시간처럼 비율로 세기 어려운 것은 분위수로 적습니다. 상위 1퍼센트를 뺀 값이 몇 초인지를 보는 식이고, 평균은 쓰지 않습니다. 평균이 0.3초인 서비스에서도 100명 중 1명은 9초를 기다리고 있을 수 있는데, 평균값은 그 한 명을 지워 버립니다. 그 한 명이 가장 큰 고객일 수도 있습니다.

좋은 SLI 는 높은 값이 아니라 사용자 체감과 같은 방향으로 움직이는 값입니다. 숫자가 떨어졌을 때 문의가 늘고, 숫자가 회복되면 문의가 줄어야 이 값을 보고 판단할 수 있습니다. 반대로 숫자는 멀쩡한데 문의가 늘어나는 값이라면 재는 대상을 잘못 고른 것입니다.

고를 때 보는 조건은 셋입니다.

1. 사용자가 겪는 것에 가깝습니다. 저장 성공률은 사용자가 겪지만 CPU 사용률은 겪지 않습니다. 후자는 원인을 찾을 때 쓰는 값이고 품질을 재는 값이 아닙니다.
2. 팀이 움직일 수 있습니다. 값이 나빠졌을 때 손댈 곳이 우리 코드나 우리 설정 안에 있어야 합니다. 사용자 휴대폰의 통신 상태까지 섞어 재면 나빠진 원인을 우리가 어쩔 수 없습니다.
3. 개수가 적습니다. 서비스 하나에 두세 개가 적당합니다. 스무 개를 재기 시작하면 어느 날 몇 개는 늘 빨간색이고, 그러면 아무도 보지 않습니다.

숫자 자체에 목표가 걸리는 것은 다음 단계의 일입니다. SLI 는 값을 재기만 하고, 그 값을 몇 퍼센트까지 지킬지 정하는 선은 SLO 가 됩니다. 그 선에서 남는 여유분을 에러 버짓이라고 부르는데, 목표가 99.9퍼센트라면 0.1퍼센트만큼은 실패해도 된다는 뜻입니다. 재는 값이 없으면 이 셋 다 성립하지 않아서, 순서상 SLI 를 먼저 정합니다.

"저장 성공률을 SLI 로 잡고 기준은 2초 안에 성공 응답으로 하겠습니다."

무엇을 재고 무엇을 좋음으로 셀지를 팀에 고정해 두는 말입니다.

"이 지표는 SLI 로 쓰기 어렵습니다. 나빠져도 우리가 손댈 데가 없어요."

값이 팀의 통제 밖에 있어 판단 근거가 되지 못한다는 지적입니다.

"28일 기준 99.84퍼센트입니다. 지난주 사고가 아직 창에 남아 있습니다."

기간이 굴러가는 방식이라 최근 사고가 값에 반영되어 있다는 뜻입니다.

페이지덱은 문서 저장 성공률과 문서 열기 응답 시간 두 개만 SLI 로 둡니다. 태오가 지역별로도 나눠 볼 수 있게 표식을 심어, 전체 값은 멀쩡한데 한 지역만 나빠지는 상태가 화면에서 드러나게 했습니다. 아침에 대시보드를 열면 두 줄만 봅니다.

지현은 이 두 값을 기능 회의에서도 씁니다. 저장 성공률이 목표 아래로 내려간 주에는 새 기능을 미루고 그 자리를 손보는 일에 사람을 붙입니다. 숫자가 결정을 대신하지는 않지만, 무엇을 먼저 할지 정하는 대화가 이 두 줄에서 시작됩니다.

값이 높으면 사용자가 만족하고 있다고 읽는 경우가 가장 많습니다. 비율이 99.9퍼센트면 거의 모두가 잘 쓰고 있는 것처럼 보입니다. 그런데 이 값은 전체를 한 덩어리로 평균 낸 결과라, 특정 조건에 있는 사람들만 계속 실패하는 상태를 가릴 수 있습니다. 전체 요청의 0.1퍼센트가 실패하는데 그 0.1퍼센트가 한 대형 고객의 요청 전부라면, 그 고객에게 이 서비스는 100퍼센트 고장입니다. 이 오해를 그대로 두면 이탈이 대시보드에 한 번도 뜨지 않은 채 일어납니다.

개발팀 성적표로 읽는 것도 흔합니다. 이름이 붙은 숫자는 평가에 쓰기 좋아 보입니다. 하지만 이 값은 무엇을 먼저 할지 정하려고 만든 것입니다. 평가에 쓰기 시작하면 팀은 값을 올리는 가장 쉬운 방법을 찾는데, 그 방법은 코드가 아니라 정의를 고치는 쪽입니다. 좋음의 기준을 2초에서 5초로 늘리거나 실패가 잦은 요청을 셈에서 빼면 숫자는 다음 달에 올라갑니다. 그러면 화면의 값은 좋아지고 고객 문의만 늘어납니다.