가동률

"서비스가 안정적입니까" 라는 질문에 오래 감으로 답했습니다. 물어본 쪽도 답한 쪽도 기준이 없어서, 안정적이라는 말이 무엇을 뜻하는지가 사람마다 달랐습니다.

기준이 없으면 비교도 안 됩니다. 5분씩 여섯 번 끊긴 달과 30분 한 번 끊긴 달 중 어느 쪽이 나쁜지 말할 수 없습니다. 끊긴 시간 총합은 같은데 체감은 다르고, 그 차이를 이야기할 단위가 없었습니다.

수아가 기업 고객 보안 검토 자리에서 이 질문을 받았을 때 바로 드러났습니다. "지난 1년 동안 얼마나 안정적이었습니까" 에 내놓을 수 있는 답이 "큰 장애는 없었습니다" 였고, 고객사는 그 문장을 계약서에 넣을 수 없었습니다.

가동률은 그 질문에 한 숫자로 답하려고 만든 값입니다. 정의는 간단한데 실제로 재려면 정상이 무엇인지부터 정해야 해서, 이 값을 만드는 과정이 팀의 기준을 정하는 일이 됩니다.

정상 동작한 시간을 전체 시간으로 나누고 100을 곱합니다. 계산은 한 줄이지만 그 전에 셋을 정해야 합니다.

1. 무엇을 정상으로 볼지 정합니다. 응답이 오기만 하면 정상인지, 3초 걸려도 정상인지가 갈립니다. 실무에서는 요청 성공률이 99퍼센트 아래로 떨어진 시각부터를 중단으로 셉니다.
2. 어디서 재는지 정합니다. 서버 안에서 재면 네트워크 문제를 못 잡으니 외부에서 1분마다 실제 요청을 보내 보는 방식을 함께 씁니다.
3. 기간을 정합니다. 한 달, 분기, 최근 30일 중 하나입니다. 기간을 바꾸면 같은 장애가 다른 숫자로 보입니다.

30일은 43,200분입니다. 그중 22분이 중단이었다면 43,178을 43,200으로 나눈 99.949퍼센트가 그 달의 값입니다.

이 숫자는 9를 몇 개 붙이느냐로 말하는 관습이 있습니다. 한 달 기준으로 허용되는 중단 시간이 이렇게 달라집니다.

1. 99퍼센트 — 7시간 12분입니다. 하루 업무 시간에 가까운 양입니다.
2. 99.9퍼센트 — 43분입니다. 일반적인 유료 서비스가 여기를 목표로 둡니다.
3. 99.95퍼센트 — 21분입니다.
4. 99.99퍼센트 — 4분 20초입니다. 배포 한 번 실수하면 그 달 몫이 다 나갑니다.
5. 99.999퍼센트 — 26초입니다. 사람이 알아채고 손을 쓰는 것으로는 도달할 수 없어서 자동 전환 장치가 필요합니다.

부분 장애를 어떻게 셀지도 정해 둡니다. 저장은 되고 검색만 안 되는 30분을 중단으로 셀지에 따라 숫자가 크게 달라집니다. 켜짐과 꺼짐만 세는 대신 전체 요청 중 성공한 비율로 세면, 검색이 전체 요청의 8퍼센트일 때 그 30분은 8퍼센트만큼만 깎입니다.

숫자 자체로는 좋다 나쁘다를 말할 수 없습니다. 그 서비스가 멈췄을 때 무엇이 멈추는지가 기준입니다. 사내 회의실 예약 도구가 한 달에 7시간 멈추는 것은 불편이고, 결제 처리가 7시간 멈추는 것은 사고입니다.

목표를 정하는 순서는 대개 이렇습니다.

1. 멈췄을 때의 손실을 적습니다. 결제가 한 시간 멈추면 매출이 얼마 빠지고 문의가 몇 건 들어오는지를 숫자로 적습니다.
2. 9를 하나 더 붙이는 비용을 견줍니다. 43분에서 4분으로 내리려면 서버를 여러 지역에 두고 배포를 무중단으로 바꾸고 당번을 24시간으로 돌려야 해서, 비용이 몇 배로 뜁니다.
3. 두 값이 만나는 지점을 SLO로 적습니다. SLO는 지키기로 정한 품질 목표치입니다.
4. 고객과의 약속은 그보다 낮춰 적습니다. 내부 목표를 99.95로 두고 SLA에는 99.9로 적습니다. 여유가 없으면 목표를 한 번 넘기는 순간 계약 위반입니다.

평균에는 함정이 있습니다. 한 달 43분을 지켰어도 그 43분이 월요일 아침 업무 시작 시각에 몰려 있으면 체감은 훨씬 나쁩니다. 그래서 영향받은 사용자 수를 함께 적습니다.

100퍼센트를 목표로 두지 않는 것도 기준의 일부입니다. 완벽을 목표로 하면 배포를 멈추는 것이 가장 안전한 선택이 됩니다. 그래서 목표와 100퍼센트 사이의 여유분을 에러 버짓으로 정해 두고 그 안에서는 배포를 계속합니다.

"지난달 가동률 99.94퍼센트입니다. SLA 기준은 넘겼습니다."

약속한 수준을 지켰다는 보고입니다.

"가동률은 99.9인데 응답이 4초씩 걸렸어요. 이건 멈춘 것과 다르지 않습니다."

켜져 있었다는 사실만으로는 사용자 경험을 설명하지 못한다는 지적입니다.

"결제 대행사 장애였는데 우리 가동률에 잡히네요."

외부 의존 서비스의 중단도 이 숫자에 들어온다는 뜻입니다.

페이지덱은 이 값을 둘로 나눠 잽니다. 문서를 열고 저장하는 핵심 동작과 검색이나 템플릿 같은 나머지입니다. 태오가 처음에는 하나로 쟀는데, 검색이 30분 멈춘 달과 저장이 30분 멈춘 달이 같은 숫자로 나왔기 때문입니다.

규원이 요구한 것은 계약서에 넣을 숫자였습니다. 지난 6개월 중 가장 나쁜 달이 99.91퍼센트였고, 그래서 내부 목표를 99.95로 두고 계약에는 99.9로 적었습니다. 이 여유가 없으면 나쁜 달 한 번에 환불 조항이 걸립니다.

가동률이 높으면 사용자 경험이 좋다고 읽는 경우가 가장 많습니다. 멈추지 않았다는 말이 잘 돌아갔다는 말처럼 들립니다. 하지만 이 값은 켜짐과 꺼짐만 봅니다. 응답이 4초씩 걸리고 저장이 세 번에 한 번 실패하는 상태도, 요청이 돌아오고 있다면 가동으로 잡힙니다. 그런 달에는 가동률이 99.95퍼센트로 찍히는데 문의는 평소의 세 배로 들어옵니다. 응답 시간과 성공률을 따로 재서 함께 봐야 하고, 그것들이 SLI입니다.

우리가 만든 부분만 책임이라고 보는 것도 흔합니다. 결제 대행사가 멈췄다면 우리 코드는 아무 문제가 없으니 억울하게 느껴집니다. 하지만 사용자에게는 결제가 안 되는 것이고, 기업 고객과의 계약도 우리 서비스가 동작하는지를 기준으로 씁니다. 그래서 외부 의존이 있는 기능은 그쪽이 멈췄을 때 어떻게 할지를 미리 정해 둡니다. 다른 대행사로 넘기거나 사용자에게 알리고 나중에 다시 시도하게 하는 경로가 있으면 중단으로 세는 시간이 줄어듭니다.