SLA란
서비스를 운영하다/사용하다 보면 “서비스 얼마나 안정적이에요?”라는 질문을 피할 수 없습니다. 이 질문에 숫자로 답하기 위해 존재하는 것이 SLA, SLO, SLI입니다.
SLA, SLO, SLI
이 세 개념은 자주 혼용되지만, 각각 역할이 다릅니다.
- SLI(Service Level Indicator): 서비스 상태를 측정하는 지표 자체입니다. 응답 시간, 에러율, 가용성 등 실제로 관측 가능한 메트릭.
- 고지 의무 없음. Status Page 운영 등도 자율적
- SLO(Service Level Objective): SLI에 대해 내부적으로 설정하는 목표치입니다. “월간 가용성 99.95% 이상 유지”처럼, 팀이 스스로 달성하겠다고 정한 기준.
- 고지(공개) 의무 없음.
- SLA(Service Level Agreement): SLO를 기반으로 고객과 맺는 계약입니다. SLO를 충족하지 못했을 때의 보상(Service Credit 등)까지 명시합니다. 법적 구속력이 있습니다.
정리하면, SLI로 측정하고, SLO로 목표를 세우고, SLA로 약속합니다.
SLO와 SLA의 간격
실무에서는 SLA보다 SLO를 더 높게 잡는 것이 일반적이라고 합니다. 예를 들어 고객에게 99.9%를 약속(SLA)했다면, 내부 목표(SLO)는 99.95%로 설정합니다. 이 간격이 Safety Margin이 되어, SLO를 살짝 못 맞추더라도 SLA 위반과 보상 지급을 피할 수 있습니다.
의미
- 고객 입장: 이 서비스에 의존해도 되는지 판단할 근거가 생깁니다.
- 제공자 입장: Error Budget(허용 가능한 장애 예산)이 생겨서, 새로운 기능 배포와 안정성 유지 사이의 균형을 잡을 수 있습니다.
- 양측 모두: 장애가 발생했을 때 “이건 계약 범위 내인가?”를 객관적으로 판단할 수 있습니다.
The Nines - 가용성 레벨
SLA에서 가용성은 보통 “nines”로 표현합니다. 99.9%는 “three nines”, 99.99%는 “four nines”라고 부릅니다. 소수점 아래 9의 개수가 곧 서비스의 신뢰 수준입니다.
| SLA | 명칭 | 연간 다운타임 | 월간 다운타임 | 적합한 서비스 |
|---|---|---|---|---|
| 99% | Two Nines | 3.65일 | 7.31시간 | 내부 도구, 비핵심 배치 시스템 |
| 99.9% | Three Nines | 8.77시간 | 43.83분 | 일반 SaaS, 비즈니스 애플리케이션 |
| 99.95% | Three and a Half Nines | 4.38시간 | 21.92분 | 클라우드 단일 서비스 기준선 |
| 99.99% | Four Nines | 52.60분 | 4.38분 | 결제 시스템, 핵심 인프라 |
| 99.999% | Five Nines | 5.26분 | 26.30초 | 통신, 의료, 항공 관제 |
| 99.9999% | Six Nines | 31.56초 | 2.63초 | 이론적 한계, 극소수 시스템 |
99%와 99.9%의 차이는 숫자로 보면 0.9%에 불과하지만, 허용 다운타임으로 환산하면 3.65일과 8.77시간으로 차이가 꽤 많이 납니다. 그리고 이 격차는 9를 추가할수록 더 극적으로 벌어집니다.
실제 서비스들의 SLA
AWS
| 서비스 | SLA | 비고 |
|---|---|---|
| EC2 | 99.99% | Region-level (2개 이상 AZ 사용 시) |
| EC2 (단일 인스턴스) | 99.5% | Instance-level |
| S3 | 99.9% | 설계 목표는 99.99% 가용성, 11 Nines 내구성 |
| Lambda | 99.95% | Region 단위 |
| RDS | 99.95% | Multi-AZ 배포 기준 |
S3의 SLA 함정
S3의 경우 제가 예전에 착각했던 한 포인트가 있습니다. “99.999999999% 내구성”이라는 숫자를 보고 대단한 회사구나 생각했는데, 이것은 데이터가 유실되지 않을 확률(Durability)이지 접속 가능 여부(Availability)가 아닙니다. 실제 가용성 SLA는 99.9%입니다.
Google Cloud Platform
| 서비스 | SLA | 비고 |
|---|---|---|
| Compute Engine (Multi-zone) | 99.99% | 2개 이상 Zone 사용 시 |
| Compute Engine (단일 인스턴스) | 99.9% | Memory-optimized VM은 99.95% |
| Cloud Storage (Multi-Region) | 99.95% | Standard class |
| Cloud Storage (Regional) | 99.9% | Standard class |
| Cloud Functions | 99.95% | - |
기타 서비스
| 서비스 | SLA | 비고 |
|---|---|---|
| Cloudflare (Enterprise) | 100% | 다운타임 발생 시 Service Credit 제공 |
| GitHub (Enterprise Cloud) | 99.9% | 분기 단위 측정. Free/Team은 SLA 없음 |
| Slack (Business+ 이상) | 99.99% | Free/Pro는 SLA 없음 |
| Stripe | 명시적 SLA 없음 | 실제 가용성은 ~99.99%+이나 계약상 보장 없음 |
패턴이 보입니다. 대부분의 주요 클라우드 서비스는 단일 서비스 기준 99.9%~99.95% 범위에 수렴하고, Multi-AZ/Multi-zone 구성을 해야 비로소 99.99%에 도달합니다. “돈을 더 쓰면 9가 하나 늘어난다”는 구조가 SLA 테이블에도 그대로 반영되어 있는 것입니다.
9 하나의 비용
10x/9 Rule
9를 하나 추가할 때마다 허용 다운타임은 1/10로 줄어듭니다. 하지만 그것을 달성하기 위한 비용과 복잡도는 약 10배로 늘어납니다. 이것을 “10x/9 Rule”이라고 부릅니다.
| 전환 | 다운타임 감소 | 필요한 것 |
|---|---|---|
| 99% → 99.9% | 3.65일 → 8.77시간 | 기본적인 모니터링, 수동 복구 절차 |
| 99.9% → 99.99% | 8.77시간 → 52.60분 | Multi-AZ, 자동 Failover, Health Check |
| 99.99% → 99.999% | 52.60분 → 5.26분 | Multi-Region, Zero-downtime Deploy, 인간이 복구 루프에서 빠져야 함 |
| 99.999% → 99.9999% | 5.26분 → 31.56초 | 이론적 한계. Active-Active 다중 리전, 실시간 데이터 복제, 극도로 정교한 자동화 |
99.9% → 99.99%: 첫 번째 벽
Three Nines에서 Four Nines로 가는 것은 단순히 백업 서버를 하나 더 추가하는 것으로 달성할 수 없습니다.
- Multi-AZ 배포: 단일 데이터센터 장애에 대비해 최소 2개 이상의 가용 영역에 걸쳐 배포해야 합니다.
- 자동 Failover: 장애 감지부터 트래픽 전환까지 자동화되어야 합니다. 인간이 알림을 보고 대응하는 시간(MTTR)만으로는 연간 52분을 맞출 수 없습니다.
- Health Check와 Circuit Breaker: 모든 의존 서비스에 대한 Health Check, 장애 전파를 차단하는 Circuit Breaker 패턴이 필수입니다.
- 무중단 배포: 배포 자체가 다운타임을 유발하면 안 됩니다. Blue-Green, Canary, Rolling Update 같은 전략이 필요합니다.
이 단계에서 인프라 비용은 복잡도 관리 비용까지 포함하면 체감상 5~10배로 늘어난다고 합니다.
99.99% → 99.999%: 인간이 루프에서 빠져야 함
연간 5.26분. 월간 26.30초. 인간이 장애를 인지하고 대응하는 것 자체가 물리적으로 불가능합니다.
- 자동 장애 감지 + 자동 복구: 모든 장애 시나리오에 대한 자동 복구 로직이 필요합니다. Chaos Engineering으로 장애를 사전에 주입하고 복구를 검증해야 합니다.
- Multi-Region Active-Active: 한 리전이 통째로 죽어도 다른 리전이 즉시 대체해야 합니다. 이는 데이터 동기화, 일관성, 레이턴시 등 분산 시스템의 가장 어려운 문제들이 전부 해결되어 있어야 한다는 이야기입니다.
- 코드 자체의 신뢰성: 인프라만으로는 부족합니다. 코드를 더 신뢰성 높은 언어로 재작성하거나, 형식 검증(Formal Verification)을 도입하는 경우도 있습니다.
- 조직 구조 변경: SRE 전담 팀, 24/7 자동화된 모니터링 체계, 정기적인 Disaster Recovery 훈련이 필요합니다. 기술적 문제를 넘어 조직 문제까지 고려해야 하는 레벨이라고 합니다.
비용 곡선
9 하나를 추가하는 것은 “조금 더 안정적으로 만드는” 것이 아니라, 아키텍처, 운영 체계, 조직 구조 전체를 한 단계 끌어올려야 하는 작업이라고 정리할 수 있습니다.
99.95% - 실용적 타협점
대부분의 서비스가 수렴하는 지점
앞서 살펴본 실제 SLA 테이블을 다시 보면, 단일 서비스 기준으로 99.95%가 반복적으로 등장합니다:
- AWS Lambda: 99.95%
- AWS RDS (Multi-AZ): 99.95%
- Google Compute Engine (Memory-optimized, 단일 인스턴스): 99.95%
- Google Cloud Storage (Multi-Region): 99.95%
- Azure VMs (Availability Sets): 99.95%
99.95%는 기술적으로 달성 가능하면서도 비용이 폭발적으로 증가하지 않는 마지막 지점이라고 합니다. 연간 4.38시간의 다운타임은 합리적인 유지보수 창과 간헐적 장애를 수용할 수 있는 수준이면서, 고객 신뢰를 유지하기에 충분히 높은 숫자입니다.
가장 약한 링크
아무리 서비스를 견고하게 만들어도, 사용자 경험의 가용성은 경로상 가장 약한 링크에 의해 결정됩니다.
서비스에 접속하는 예시를 하나 들어보면:
flowchart LR A["사용자"] --> B["ISP"] B --> C["CDN"] C --> D["Load Balancer"] D --> E["서비스"] E --> F["DB"]
여기서 ISP의 가용성이 99.9%라면, 열심히 서비스를 99.999%로 만들어도 사용자가 체감하는 가용성은 99.9%에 가깝습니다. 각 계층의 가용성을 곱하면 전체 가용성은 반드시 가장 낮은 계층보다 낮아집니다.
따라서 한 구성 요소만 극단적으로 끌어올리는 것(특히 다른 요소를 내가 통제할 수 없는 한)은 비용 대비 효과가 없습니다.
SLA보다는 MTTR
같은 99.9% SLA라도, 장애 패턴에 따라 체감이 완전히 달라진다고 합니다.
- 서비스 A: 99.9% 가용성. 장애 발생 시 평균 5분 내 복구.
- 서비스 B: 99.95% 가용성. 장애 발생 시 평균 2시간 소요.
숫자만 보면 서비스 B가 더 안정적이지만, 실제로 의존하기에 더 안전한 것은 서비스 A입니다. 장애는 반드시 발생합니다.
중요한 것은 발생 빈도보다 얼마나 빨리 복구하느냐(MTTR, Mean Time To Recovery)입니다.
Google SRE Book - Embracing Risk
“100% is probably never the right reliability target: not only is it impossible to achieve, it’s typically more reliability than a service’s users want or notice.”
100%는 올바른 신뢰성 목표가 될 수 없습니다. 달성이 불가능할 뿐 아니라, 사용자가 원하거나 인지하는 수준 이상의 신뢰성이기 때문입니다.
Cloudflare 저격
결국 SLA는 “얼마나 높이 올릴 수 있는가”의 문제가 아니라, “어디서 멈추는 것이 합리적인가”의 문제입니다.
이미 업계에 답이 나와있습니다. 대부분의 서비스(정부, 금융권과 같은 특수 케이스 제외)는 그 답이 99.95%이고, 남은 예산은 MTTR을 줄이는 데 투자하는 것이 훨씬 효과적입니다.