가용성과 운영 관리
- 6.1 가용성의 정의와 SLA
- 6.2 이중화와 페일오버
- 6.3 클러스터링과 고가용성 아키텍처
- 6.4 가용성 측정과 현실
- 6.5 설정 관리
- 6.6 기능 토글
- 6.7 투명한 배포
- 6.8 운영 친화적 시스템 설계
시스템이 아무리 안정적이어도 배포할 때 죽거나 설정 하나 잘못 바꿔서 터지면 의미 없어. 가용성과 운영은 한 몸이야.
99%와 99.99%가 별 차이 아닌 것 같지? 허용 다운타임으로 보면 3.65일 vs 52분이야. **가용성(Availability)**은 사용자가 시스템을 쓸 수 있는 시간의 비율이야. 안정성이 "장애에 대한 저항력"이라면, 가용성은 "얼마나 자주, 얼마나 오래 살아있느냐"지. SLA로 고객에게 약속하는 건데, 여기서 중요한 건 — 99.999%를 달성하려면 이중화, 자동 페일오버, 무중단 배포, 24/7 운영 인력이 필요하고 비용이 기하급수적으로 올라간다는 거야. 그래서 SLA는 비즈니스 결정이지 기술 결정이 아니야. "우리 시스템에 어느 수준이 필요한가"는 비즈니스가 답해야 할 질문이지.
가용성의 기본 전략은 이중화(Redundancy) — 단일 장애점(SPOF)을 제거하기 위해 모든 컴포넌트를 최소 2개 이상 두는 거야. 서버, DB, 네트워크, 데이터센터까지. 근데 이중화만으로는 부족해. **페일오버(Failover)**가 제대로 동작해야 하고, 핵심은 자동이라는 거야. 비동기 복제면 Master가 죽었을 때 데이터 유실이 가능하고, 네트워크 파티션이면 양쪽 다 자기가 Master라고 우기는 스플릿 브레인이 생길 수 있어. 그래서 테스트하지 않은 페일오버는 작동한다고 보장할 수 없어 — 정기적으로 페일오버 드릴을 돌려야 해.
고가용성의 근간은 무상태(Stateless) 서비스야. 서버에 상태를 두지 않으면 어떤 서버가 죽어도 다른 서버가 대신 처리 가능하잖아. 세션, 캐시를 Redis 같은 외부 스토어에 넣어서 서버와 상태를 분리하고, 트래픽에 따라 자동 스케일링하고, 배포할 때도 끊김 없이 — 이게 현대적인 고가용성 아키텍처의 모습이야. 가용성을 측정할 때도 "서버가 살아있냐"보다 "성공한 요청 수 / 전체 요청 수"가 더 현실적이고, 계획된 다운타임도 다운타임이고, 결제만 안 되는 부분 장애도 사용자에게는 장애야.
가용성을 높이려면 운영도 함께 성숙해야 해. 프로덕션 장애의 상당 부분이 **잘못된 설정(misconfiguration)**에서 시작돼. 코드 변경보다 설정 변경이 훨씬 자주 일어나는데, 설정에 대한 관리는 코드만큼 엄격하지 않은 경우가 많거든. 설정을 코드와 분리하고(12-Factor App의 원칙이기도 하지), Git으로 버전 관리해서 누가 언제 뭘 바꿨는지 추적하고, 서버 100대에 수동 배포 같은 건 하지 말고 Ansible이나 설정 서버로 자동화해야 해. 필수 설정이 누락되면 시작을 거부하는 게 맞고 — Fail Fast — 나머지는 안전한 기본값을 제공하는 게 나아.
**기능 토글(Feature Toggle)**은 코드 배포 없이 기능을 끄고 켤 수 있게 해줘. 전체 사용자의 5%에게만 새 기능을 켜서 검증하는 점진적 롤아웃, 문제 생기면 배포 없이 즉시 끄는 킬 스위치, A/B 테스트 — 운영 유연성이 크게 올라가. 근데 오래된 토글을 정리 안 하면 토글 부채가 쌓이고, 토글 10개면 가능한 조합이 1024개라서 테스트도 어려워지니 주의해야 해.
**무중단 배포(Zero-Downtime Deployment)**는 사용자가 눈치채지 못하는 배포야. 롤링 배포, 블루-그린, 카나리 — 전략은 다양한데, 가장 까다로운 건 DB 스키마 변경이야. 코드 롤백은 쉽지만 DB 마이그레이션은 롤백이 어렵거든. 새 컬럼을 먼저 추가(expand)하고, 모든 코드가 전환된 후에 옛 컬럼을 삭제(contract)하는 확장-축소 패턴이 안전해. 그리고 시스템에 /health 엔드포인트, 캐시 클리어 같은 관리 API, 그레이스풀 셧다운, 시작 시 자가 진단을 넣어두면 — 운영하는 사람(결국 미래의 나)이 감사하게 될 거야.
정리
6장 읽고 기억할 거 세 가지:
- SLA는 비즈니스 결정이야 — 가용성 목표에 따라 비용이 기하급수적으로 올라가니까, 비즈니스 요구에 맞는 수준을 정해.
- 이중화만으로는 부족하고, 페일오버를 테스트해야 해 — 테스트하지 않은 페일오버는 작동한다고 보장할 수 없어.
- 설정 변경은 코드 변경만큼 위험해 — 설정도 버전 관리하고, 기능 토글과 무중단 배포로 운영 유연성을 확보해.