LabHub

비용과 아키텍처 결정 · 가용성의 값 · 이론

9 하나를 더 붙이는 데 드는 값

LabHub 에서 이어서 보기

한 줄 요약

가용성은 사면 됩니다. 문제는 **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 복제만 켜 두고 나머지는 꺼 두는 방식입니다.
유사시에 나머지를 켭니다. 종량제의 값이 가장 잘 드러나는 전략이고,
비용 대비 효과가 좋아 실무에서 자주 선택됩니다.

결정하는 순서

1. 서비스별로 등급을 나눈다 — 전부 최고 등급일 수는 없습니다.
보통 3단계면 충분합니다(핵심 / 중요 / 일반).
2. 각 등급의 RTO/RPO 를 숫자로 정한다 — 사업 쪽과 합의해야 합니다.
"중단되면 시간당 얼마를 잃는가" 가 근거가 됩니다.
3. 그 숫자를 만족하는 최소 구성을 고른다 — 더 좋은 게 아니라 충분한 것.
4. 검증한다 — 리허설을 하지 않은 RTO 는 희망 사항입니다.

4번이 실제로 가장 자주 생략됩니다. 그리고 진짜 장애 때 RTO 가 계획의
3배가 나옵니다.

리허설이 드러내는 것들

복구 훈련을 하면 문서에 없던 문제가 나옵니다.

이걸 장애 중에 발견하면 RTO 는 지켜지지 않습니다.

비용과 균형 잡기

가용성 투자액이 기대 손실을 넘으면 과투자입니다.

기대 손실 = 연간 예상 중단 시간 × 시간당 손실

시간당 손실이 100만 원인 서비스에서 99.9%(연 8.8시간)를 99.99%(연 52분)로
올리면 약 8시간을 아끼고, 그 값은 연 800만 원입니다. 그 구성에 연 3,000만 원이
든다면 과투자입니다. 반대라면 당연히 해야 합니다.

현장에서 만나는 모습

다음에 볼 것

이 결정들을 나중 사람이 읽을 수 있게 남기는 법.