가동률 SLA는 약속처럼 보이지만 환불 규정처럼 작동합니다. 공급자는 이 점을 잘 알고 있습니다. 고객은 그렇지 못한 경우가 많아서, 가용성을 샀다고 믿으며 서비스 수준 협약에 서명합니다. 그러나 실제로 산 것은 가용성이 아니라, 그것을 받지 못했을 때 돌려받는 작은 할인입니다.
그것이 반드시 나쁜 거래라는 뜻은 아닙니다. 다만 대부분의 사람이 맺고 있다고 생각하는 거래와는 다른 거래이고, 그 차이는 시스템이 멈추고 누군가 계약서에 뭐라고 적혀 있는지 묻는 순간에 드러납니다.
쓰리 나인은 거의 완벽하게 들리지만 한 달에 43분의 다운타임을 허용합니다. 포 나인은 4분을 허용합니다. 업무 시간대 오후에 43분짜리 장애를 감당할 수 있는 사업이라면 99.9%로 충분하며 그 이상에 돈을 쓸 필요가 없습니다. 감당할 수 없다면 나인을 아무리 늘려도 소용없습니다. 협약은 장애를 막아 주는 대신 크레딧을 지급할 뿐이기 때문입니다.
가동률 SLA가 분 단위로 약속하는 것
백분율은 아주 넓은 범위를 작아 보이는 차이 안에 압축해 넣습니다. 시간으로 바꿔 적으면 그 차이는 곧바로 드러납니다.
| 가용성 | 연간 다운타임 | 월간 다운타임 |
|---|---|---|
| 99% | 3.65일 | 7.2시간 |
| 99.9% | 8.76시간 | 43.2분 |
| 99.95% | 4.38시간 | 21.6분 |
| 99.99% | 52.6분 | 4.32분 |
| 99.999% | 5.26분 | 26초 |
여기서 두 가지가 따라 나옵니다. 99.9%에서 99.99%로 가는 한 걸음은 허용 다운타임을 10분의 1로 줄이지만, 비용은 보통 그보다 훨씬 크게 늘어납니다. 배포 과정까지 포함해 모든 단일 장애 지점을 없애는 이중화가 필요하기 때문입니다. 여기서 말하는 이중화는 서버를 한 대 더 두는 일이 아니라, 데이터베이스와 네트워크 경로와 인증 계층을 모두 이중으로 만들고, 릴리스 자체가 서비스를 멈추지 못하도록 무중단 배포까지 갖추는 일입니다. 그리고 파이브 나인 이상은 사람이 이상을 알아채고 대응하는 데 걸리는 시간보다 짧기 때문에, 사람이 개입하지 않고 자동으로 전환되는 시스템만이 지켜낼 수 있습니다.
숫자는 인상적으로 들리는 쪽이 아니라 장애가 실제로 시간당 얼마의 손실을 내는지를 기준으로 정하십시오. 장애 한 시간의 손실액을 실제로 계산해 보면, 대부분의 회사에서 그 값은 한 등급 위로 올라갈 때 더 내야 하는 금액보다 작습니다. 대부분의 업무 시스템은 99.9%로 정직하게 충분합니다.
서비스 크레딧은 보상이 아닙니다
거의 모든 가동률 SLA의 구제 수단은 향후 요금에서 차감되는 크레딧이며, 대개 월 요금의 일정 비율이고 그달 총액을 상한으로 두는 경우가 많습니다. Google Cloud의 컴퓨팅 SLA가 대표적인 예로, 크레딧만 제공하고, 고객이 직접 청구해야 하며, 상한이 있습니다.
즉 되돌려 받을 수 있는 최대치는 해당 기간에 지불한 금액 정도이고, 대부분의 서비스에서 그 금액은 장애가 초래하는 손실보다 훨씬 적습니다. 월 몇백 파운드짜리 플랫폼이 하루치 매출 손실을 메워 줄 수는 없으며, 그렇게 될 수 있는 조건에 동의할 공급자도 없습니다. 게다가 크레딧은 대개 장애가 난 그 서비스의 요금만을 기준으로 계산되므로, 그 서비스에 의존하던 나머지 시스템이 함께 멈춰서 생긴 손실은 아예 계산에 들어가지 않습니다.
크레딧은 또한 자동 지급이 아니라 청구를 전제로 하는 경우가 많습니다. 위반 사실을 직접 알아차리고, 직접 계산하고, 때로는 삼십 일에 불과한 기한 안에 청구를 제출해야 합니다. 공급자는 목표를 놓쳤다는 사실을 먼저 알릴 의무가 없고, 대부분은 알리지 않습니다.
실무적인 결론은 크레딧을 보호 장치로 여기는 태도를 그만두라는 것입니다. 크레딧은 공급자가 자기 숫자를 얼마나 진지하게 대하는지 보여 주는 신호일 뿐입니다. 실제로 여러분을 지키는 것은 아키텍처이며, 재해 복구 가이드에서 다룬 복구 계획입니다.
모든 것을 가르는 조항들
무엇을 다운타임으로 볼 것인가. 완전한 이용 불가만인가, 성능 저하도 포함하는가? 삼십 초 만에 응답하는 서비스는 쓸 수 없지만 대부분의 정의에서는 이용 가능으로 잡힙니다. 응답 시간이 중요하다면 지연 임계값을 정의 안에 넣으십시오.
누가 어떻게 측정하는가. 거의 언제나 공급자가 자사 모니터링으로 자사 네트워크에서 측정합니다. 그것은 공급자 인프라의 측정이지 여러분 경험의 측정이 아닙니다. 측정 지점을 합의하고, 그와 별개로 독립 모니터링을 반드시 운영하십시오. 직접 관측하지 않은 숫자는 다툴 수 없습니다.
제외 사유. 계획된 유지보수는 보통 전면 제외되므로, 공급자는 아무것도 위반하지 않고도 매달 몇 시간씩 서비스를 내릴 수 있습니다. 사전 통지 기간과 상한이 있는지 확인하십시오. 정기 점검이 전면 제외되면 계약서에 적힌 백분율과 여러분이 실제로 쓸 수 있었던 시간은 눈에 띄게 벌어집니다. 여러분의 설정, 제3자, 불가항력에 귀속되는 사유도 함께 제외되며 이 범주는 상당히 많은 것을 흡수합니다.
측정 구간. 월 단위가 표준이고 고객에게 유리합니다. 연 단위 측정은 공급자가 긴 장애를 겪고도 목표를 달성하게 해 줍니다. 99.9%에서는 꼬박 하루의 정지도 연간 허용치 안에 들어가기 때문입니다.
대응 대 해결. 많은 계약이 일정 시간 안에 대응하겠다고만 약속하고 복구에 대해서는 아무 말도 하지 않습니다. 한 시간 내 대응에 복구 기한은 무제한인 형태가 흔하며, 읽히는 것보다 훨씬 약한 약속입니다.
숫자 대신 요구해야 할 것
겉으로 드러나는 숫자가 아니라 실제 행동을 바꾸는 항목을 밀어붙이십시오.
계획된 유지보수의 상한, 사전 통지와 피크 시간대를 피한 작업 창을 함께 요구하십시오. 실제 가용성에는 백분율보다 이쪽이 더 크게 작용하는 경우가 많습니다.
상태 공개, 즉 공개 상태 페이지와 장애를 신속히 게시하겠다는 약속입니다. 자기 장애를 스스로 알리는 공급자는 자신이 어떻게 일하는지를 말해 주고 있는 셈입니다.
정해진 에스컬레이션 경로, 이름이나 역할과 시간이 명시되어 있어야 장애 대응이 누구에게 연락할지 찾는 일부터 시작되지 않습니다.
중대한 장애 이후의 사후 보고서, 무엇이 일어났고 그 결과 무엇을 바꿨는지를 담아야 합니다. 공급자가 줄 수 있는 가장 유익한 문서이며, 제공을 꺼린다는 사실 자체도 많은 것을 알려 줍니다.
반복 실패 시 해지권. 만성적인 미달 성능이라면 위약금 없이 떠날 수 있어야 합니다. 이 권리는 어떤 크레딧보다 값집니다. 피해에 비례하는 유일한 구제 수단이기 때문입니다.
여러분이 SLA를 제공하는 쪽이라면
평균적인 달이 아니라 가장 나쁜 달에도 지킬 수 있는 숫자를 제시하고, 약속하기 전에 직접 측정하십시오. 검증한 적 없는 숫자를 약속한 공급자는 그 격차를 공개된 자리에서 확인하게 됩니다.
계획된 유지보수를 정직하게 정의하고 그 작업 창을 지키십시오. 상태 페이지를 공개하십시오. 아무도 요구하지 않아도 사후 보고서를 쓰십시오. 남는 고객은 여러분이 무슨 일이 있었는지 안다고 믿는 고객이기 때문입니다.
그리고 각 등급의 가격은 실제로 제공하는 데 드는 비용에 맞추십시오. 포 나인은 마케팅 결정이 아니라 이중화된 인프라이고, 자동 장애 조치이며, 시스템을 멈추지 않는 배포 과정입니다. 여기에는 모두 청구서가 따라붙습니다. 그 운영 기반의 상당 부분은 CI/CD 파이프라인 가이드에서 시작됩니다.
Mecanik은 서버 보안 분석 업무의 일부로 가용성 약속 아래 시스템을 구축하고 운영합니다. 할 만한 약속은 거의 언제나 나쁜 한 주에도 지킬 수 있는 약속입니다.
자주 묻는 질문
99.9% 가동률은 다운타임을 얼마나 허용하나요? 연간 8.76시간, 월간 43.2분입니다. 99.99%로 올라가면 연간 52.6분, 월간 4.32분으로 10분의 1이 되고, 배포 과정을 포함한 모든 단일 장애 지점을 없애야 하므로 구현 비용은 보통 열 배를 훨씬 넘습니다.
서비스 크레딧은 다운타임에 대한 진짜 보상인가요? 아닙니다. 크레딧은 대개 월 요금의 일정 비율이고 그달 청구액을 상한으로 하므로, 돌려받는 최대치는 지불한 금액 정도이며 장애가 통상 초래하는 손실보다 훨씬 적습니다. 짧은 기한 안에 직접 청구해야 하는 경우도 많고, 공급자가 목표 미달을 먼저 알리는 일은 드뭅니다.
가동률 SLA에서 무엇을 확인해야 하나요? 무엇을 다운타임으로 보는지와 성능 저하가 포함되는지, 누가 어디에서 측정하는지, 제외 사유가 무엇을 덮는지, 계획된 유지보수에 상한과 통지가 있는지, 측정 구간이 월 단위인지 연 단위인지, 그리고 약속이 대응인지 해결인지입니다.
측정 구간이 왜 그렇게 중요한가요? 월 단위 측정은 고객에게 유리합니다. 연 단위 측정은 공급자가 긴 장애 한 번을 겪고도 목표를 달성하게 합니다. 99.9%에서는 꼬박 하루의 다운타임도 연간 허용치 안에 들어가기 때문입니다. 같은 장애가 월 단위 협약이었다면 그대로 위반입니다.
더 높은 숫자 대신 무엇을 협상해야 하나요? 피크 시간대를 피한 통지와 함께 계획된 유지보수에 상한을 두는 것, 장애를 신속히 게시하는 공개 상태 페이지, 담당자와 시간이 명시된 에스컬레이션 경로, 중대한 장애 이후의 서면 사후 보고서, 그리고 반복 실패 시 해지권입니다. 마지막 항목만이 피해에 비례하는 유일한 구제 수단입니다.
댓글