서비스 장애 대응 및 복구 전략 수립 - Genie-Uss/genieus GitHub Wiki
장애 전파 차단: Resilience4j를 통한 서킷브레이커 적용
- MSA 환경에서는 하나의 서비스 장애가 연쇄적으로 전체 시스템에 영향을 줄 수 있기 때문에, 호출 실패 시 빠르게 차단하고 복구할 수 있는 Circuit Breaker 패턴이 필수적이었습니다.
Resilience4j를 선택한 이유
- Spring Boot와 자연스러운 통합 지원
- 비동기, Future, Reactor 등 다양한 프로그래밍 모델 지원
- 경량화된 구조로 추가적인 시스템 부하 없이 적용 가능
- 이를 통해 외부 API 실패, DB 연결 문제 등 장애 발생 시 서비스 장애 전파를 차단하고 빠르게 폴백(fallback) 할 수 있도록 했습니다.
장애 감지 및 실시간 알림: Grafana Alert + Slack 연동
- 장애 발생 시 빠르게 인지하고 대응할 수 있도록 Grafana Alert 기능을 활용해 주요 지표(CPU, Memory, Error Rate 등)에 대한 임계치(Alert Rule) 를 설정했습니다.
Slack Webhook 연동을 선택한 이유
- 별도 라이선스 비용 없이 Slack 채널을 통한 실시간 알림 수신 가능
- Grafana Alert 설정만으로 간편하게 통합 가능
- 팀 내부 협업 채널(Slack)과 바로 연결되어 즉시 대응 체계 마련 가능
- 이를 통해 시스템 이상 징후가 발생할 경우, 운영팀과 개발팀이 즉시 장애를 인지하고 대응할 수 있는 프로세스를 구축했습니다.
부하 테스트 및 사전 검증: k6 기반 성능 테스트
- 대규모 트래픽이 발생할 경우 예상치 못한 병목이나 장애가 발생할 가능성을 줄이기 위해, 사전 부하 테스트(Load Testing) 를 필수적으로 수행했습니다.
k6를 선택한 이유
- Go 기반 경량화 구조로 고성능 부하 생성 가능
- 테스트 스크립트(JavaScript 기반)가 직관적이라 유지보수가 용이
- Grafana + Prometheus 연동 기능이 기본 지원되어, 부하 테스트 결과를 실시간 시각화 가능
- 실제 시나리오(회원가입 → 로그인 → 주문 → 결제 완료/취소 흐름)를 기반으로 대량 부하를 가해, 시스템 한계치와 병목 구간을 사전에 파악하고 개선 작업을 선제적으로 수행했습니다.
✍🏻 요약
| 항목 | 선택 이유 |
|---|---|
| Resilience4j | Spring Boot 통합성, 경량성, 다양한 모델 지원 |
| Grafana Alert + Slack | 실시간 알림, 비용 없음, 협업 채널 통합 용이 |
| k6 | 경량 고성능, 코드 관리 용이, Grafana 연동 최적화 |