Cost and Architectural Decisions
What One More Nine Costs
한국어 원문으로 표시합니다.
한 줄 요약
가용성은 사면 됩니다. 문제는 9 하나를 더 붙일 때마다 비용이 대략 한 자릿수씩 뛴다는 것입니다. 그래서 '최대한 안전하게' 가 아니라 '얼마나 필요한가' 를 먼저 정해야 합니다.
왜 이게 필요했나
모든 서비스를 같은 가용성으로 만들면 중요하지 않은 기능에도 이중화와 대기 자원을 과투자하게 됩니다. 중단 시간과 데이터 손실이 사업에 주는 피해를 RTO·RPO로 나눠 적어야 복구 전략의 추가 비용이 실제로 피하는 손실보다 작은지 비교할 수 있습니다.
어떻게 동작하나
9 의 의미
| 가용성 | 연간 허용 중단 | 월간 |
|---|---|---|
| 99% | 약 3.65일 | 약 7시간 |
| 99.9% | 약 8.8시간 | 약 43분 |
| 99.95% | 약 4.4시간 | 약 22분 |
| 99.99% | 약 52분 | 약 4.3분 |
| 99.999% | 약 5분 | 약 26초 |
99.99% 는 연간 52분입니다. 배포 한 번에 5분씩 멈춘다면 연 10회 배포로 예산을 다 씁니다. 그래서 높은 가용성 목표는 자동으로 무중단 배포를 요구합니다. 목표를 정하는 순간 따라오는 일이 생기는 것입니다.
RTO 와 RPO
| 뜻 | 질문 | |
|---|---|---|
| RTO (복구 시간 목표) | 얼마나 빨리 다시 서비스되나 | 몇 분/시간 안에 복구? |
| RPO (복구 시점 목표) | 얼마나 최근 데이터까지 살리나 | 몇 분/시간치 데이터를 잃어도 되나? |
둘은 독립입니다. "10분 안에 복구되지만 하루치 데이터를 잃는" 구성도, "데이터는 1초도 안 잃지만 복구에 6시간 걸리는" 구성도 가능합니다. 서비스마다 다르게 정합니다 — 결제 원장의 RPO 는 0에 가까워야 하지만 추천 캐시는 하루를 잃어도 됩니다.
전략과 값
| 전략 | RTO | RPO | 상대 비용 |
|---|---|---|---|
| 백업 후 복구 | 수 시간~1일 | 백업 주기 | 가장 쌈 |
| 파일럿 라이트 | 수십 분 | 분 단위 | 낮음 |
| 웜 스탠바이 | 수 분 | 분 단위 | 중간 |
| 액티브-액티브 | 거의 0 | 거의 0 | 가장 비쌈 |
파일럿 라이트는 DB 복제만 켜 두고 나머지는 꺼 두는 방식입니다. 유사시에 나머지를 켭니다. 종량제의 값이 가장 잘 드러나는 전략이고, 비용 대비 효과가 좋아 실무에서 자주 선택됩니다.
결정하는 순서
- 서비스별로 등급을 나눈다 — 전부 최고 등급일 수는 없습니다. 보통 3단계면 충분합니다(핵심 / 중요 / 일반).
- 각 등급의 RTO/RPO 를 숫자로 정한다 — 사업 쪽과 합의해야 합니다. "중단되면 시간당 얼마를 잃는가" 가 근거가 됩니다.
- 그 숫자를 만족하는 최소 구성을 고른다 — 더 좋은 게 아니라 충분한 것.
- 검증한다 — 리허설을 하지 않은 RTO 는 희망 사항입니다.
4번이 실제로 가장 자주 생략됩니다. 그리고 진짜 장애 때 RTO 가 계획의 3배가 나옵니다.
리허설이 드러내는 것들
복구 훈련을 하면 문서에 없던 문제가 나옵니다.
- 복구 절차서가 최신이 아니다
- 필요한 권한을 담당자가 안 갖고 있다
- 백업은 있는데 복호화 키를 못 찾는다
- 의존 서비스의 복구 순서가 정해져 있지 않다
- DNS·인증서가 새 환경을 가리키지 않는다
이걸 장애 중에 발견하면 RTO 는 지켜지지 않습니다.
비용과 균형 잡기
가용성 투자액이 기대 손실을 넘으면 과투자입니다.
기대 손실 = 연간 예상 중단 시간 × 시간당 손실
시간당 손실이 100만 원인 서비스에서 99.9%(연 8.8시간)를 99.99%(연 52분)로 올리면 약 8시간을 아끼고, 그 값은 연 800만 원입니다. 그 구성에 연 3,000만 원이 든다면 과투자입니다. 반대라면 당연히 해야 합니다.
가용성을 사는 대신 복구를 빠르게 하는 선택
"99.99% 를 목표로 한다" 는 말은 대개 예산 이야기 없이 나온다. 9 를 하나 늘리는 비용은 선형이 아니라 지수적이므로, 어디까지 살 것인지 정하려면 반대편도 함께 봐야 한다.
멈춤 시간의 값을 먼저 계산한다. 시간당 매출, 이탈하는 사용자, 위약금, 복구에 드는 사람의 시간을 더한다. 이 숫자가 나와야 "이중화에 월 200만 원" 이 비싼지 싼지 말할 수 있다. 대부분의 내부 시스템은 계산해 보면 99.9%(월 43분)면 충분하다는 결론이 나온다.
같은 돈이면 복구를 빠르게 하는 쪽이 대개 낫다. 이중화는 특정 종류의 장애만 막는다(장비 고장, AZ 장애). 실제로 겪는 장애의 상당수는 잘못된 배포와 설정 변경이고, 이중화된 시스템은 그 변경도 양쪽에 똑같이 배포한다. 되돌리기를 5분 안에 할 수 있는 능력이 이중화보다 넓은 범위를 덮는다.
복구 시간을 재 본 적 없으면 그 숫자는 희망이다. 백업에서 복원하는 데 몇 분이 걸리는지, 다른 리전에서 뜨는 데 얼마나 걸리는지는 해 봐야 안다. 대개 문서에 적힌 값의 두세 배가 나온다. DNS TTL, 이미지 내려받기, 캐시가 비어 있는 상태의 첫 트래픽이 전부 시간을 먹는다.
단일 장애점은 인프라보다 사람과 절차에 더 자주 있다. 그 시스템을 되살릴 수 있는 사람이 한 명이거나, 복구 절차가 그 사람 머릿속에만 있거나, 비상용 계정의 비밀번호를 아무도 모르는 상태가 흔하다. 이중화 예산을 쓰기 전에 평일 낮에 그 사람 없이 복구 훈련을 한 번 해 보는 편이 값이 크다.
측정하지 않는 가용성은 관리되지 않는다. 내부에서 재는 가용성과 사용자가 겪는 가용성은 다르다. 서버는 200을 돌려주는데 사용자는 화면을 못 보는 상황이 있기 때문이다. 밖에서 실제 사용자 흐름을 재는 합성 모니터링을 하나만 두어도, "우리는 99.95% 였다" 와 "저는 세 번 실패했습니다" 의 간격이 줄어든다.
현장에서 만나는 모습
- "가용성 99.99% 목표" 를 정하고 수동 배포를 유지 → 배포로 예산을 다 쓴다.
- 백업은 매일 도는데 복구를 해 본 적 없음 → RTO 가 미지수.
- 모든 서비스를 액티브-액티브로 → 비용이 감당 안 돼 결국 되돌림.
다음에 볼 것
이 결정들을 나중 사람이 읽을 수 있게 남기는 법.