Uptime
가동 시간
시스템이 정상 운영되는 시간. SLA로 보장. 99.99% = 연 52분 다운타임.
가동 시간
시스템이 정상 운영되는 시간. SLA로 보장. 99.99% = 연 52분 다운타임.
가동 시간(Uptime)은 시스템이 정상적으로 운영되어 서비스를 제공하는 시간의 비율입니다. 보통 퍼센트로 표현하며, SLA(Service Level Agreement)의 핵심 지표입니다. 99.9%("쓰리 나인")가 일반적인 목표이고, 99.99%("포 나인")는 고가용성 기준입니다.
Uptime 퍼센트에 따른 허용 다운타임은 다음과 같습니다. 99%(투 나인)는 연 3.65일, 99.9%(쓰리 나인)는 연 8.76시간, 99.99%(포 나인)는 연 52.6분, 99.999%(파이브 나인)는 연 5.26분입니다. 한 자리 차이가 실제로는 10배의 안정성 차이를 의미합니다.
Uptime을 높이기 위한 전략으로는 이중화(Redundancy), 로드 밸런싱, 자동 장애 조치(Failover), 카나리 배포, 서킷 브레이커 등이 있습니다. 정기 점검(Planned Maintenance)도 다운타임에 포함되므로, 무중단 배포와 롤링 업데이트가 중요합니다.
실무에서는 Uptime Robot, Pingdom, Datadog 같은 모니터링 도구로 지속적으로 측정합니다. 상태 페이지(Status Page)를 운영해 고객에게 실시간 가용성을 공개하고, 장애 발생 시 사후 분석(Post-mortem)으로 재발을 방지합니다. Error Budget은 SLO 대비 사용 가능한 다운타임 예산입니다.
# Prometheus + Grafana로 Uptime 모니터링
# prometheus-rules.yaml - SLO/SLI 정의
groups:
- name: slo-rules
rules:
# 성공 요청 비율 (SLI)
- record: http_request_success_rate:5m
expr: |
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# 99.9% SLO 위반 여부
- alert: HighErrorRate
expr: http_request_success_rate:5m < 0.999
for: 5m
labels:
severity: critical
annotations:
summary: "서비스 가용성 SLO 위반"
description: "현재 성공률: {{ $value | humanizePercentage }}"
# Error Budget 소진율
- record: error_budget_remaining:30d
expr: |
1 - (
(1 - avg_over_time(http_request_success_rate:5m[30d]))
/
(1 - 0.999) # 99.9% SLO
)
---
# Kubernetes Liveness/Readiness Probe 설정
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 3 # 고가용성을 위한 복제본
template:
spec:
containers:
- name: api
image: myapp/api:v1.0.0
ports:
- containerPort: 8080
# Liveness: 컨테이너가 살아있는지 확인
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
# Readiness: 트래픽을 받을 준비가 되었는지 확인
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 2
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
---
# PodDisruptionBudget - 업그레이드 중 가용성 보장
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api-pdb
spec:
minAvailable: 2 # 최소 2개 Pod 유지
selector:
matchLabels:
app: api-server
---
# 상태 페이지 API 예제 (Node.js)
# GET /status 응답 예시
{
"status": "operational",
"uptime": "99.98%",
"uptime_30d": "99.95%",
"components": {
"api": { "status": "operational", "latency_p99": "45ms" },
"database": { "status": "operational", "latency_p99": "12ms" },
"cache": { "status": "degraded", "message": "Redis failover in progress" }
},
"incidents": [
{
"id": "inc-2024-001",
"title": "API 응답 지연",
"status": "resolved",
"duration_minutes": 15,
"resolved_at": "2024-01-15T10:30:00Z"
}
]
}
시니어: "이번 달 에러 버짓을 거의 다 썼어요. 99.9% SLO인데 이미 8시간 가까이 다운됐거든요."
주니어: "그럼 이번 달은 새 기능 배포를 자제해야 하나요?"
시니어: "네, 안정성 작업 위주로 가고 리스크 있는 변경은 다음 달로 미뤄요. 에러 버짓이 회복되면 다시 속도 내죠."
면접관: "99.99% 가용성을 달성하기 위해 어떤 아키텍처를 설계하시겠습니까?"
지원자: "다중 가용 영역(Multi-AZ) 배포로 단일 장애점을 제거하고, 오토스케일링으로 부하에 대응합니다. 데이터베이스는 읽기 복제본과 자동 장애 조치를 구성하고, 애플리케이션 레벨에서 서킷 브레이커와 재시도 로직을 구현합니다. 무중단 배포를 위해 블루-그린 또는 카나리 배포를 사용합니다."
리뷰어: "readinessProbe가 없네요. DB 연결 안 되어도 트래픽 받으면 에러 폭주해요."
개발자: "/ready 엔드포인트에서 DB, Redis 연결 상태 확인하도록 추가하겠습니다. failureThreshold도 적절히 설정할게요."