장애를 버틸 준비: 자동 복구와 운영 안정성 전략
“서버는 반드시 멈춥니다. 중요한 건 얼마나 빨리 복구하느냐입니다.”
개발이 끝나고 배포가 완료되어도, 진짜 운영은 언제나 예외 상황과의 싸움입니다.
이번 편에서는 장애가 발생했을 때 자동 복구하고, 안정적으로 서비스를 유지할 수 있는 전략들을 실습 중심으로 정리합니다.
🧭 왜 장애 대응이 중요한가?
- “서버가 꺼졌어요.” → 누구도 몰랐다면?
- “DB가 초기화됐어요.” → 백업은 언제 했더라?
운영 환경에서 가장 무서운 건 ‘예측하지 못한 일’이 아니라, ‘대응할 준비가 안 된 상태’입니다.
장애를 피할 수 없다면, 버티는 방법을 익혀야 합니다.
실제로 AWS, Google Cloud 같은 거대 플랫폼도 가끔 장애를 겪습니다. 중요한 건 사용자에게 미치는 영향을 최소화하고 빠르게 회복하는 것입니다.
🩺 헬스체크란 무엇인가?
헬스체크는 컨테이너나 서버가 정상 작동 중인지 주기적으로 확인하는 메커니즘입니다.
특정 조건에서 실패하면 자동으로 재시작하거나 트래픽을 차단합니다.
Docker에서의 헬스체크 예시
HEALTHCHECK --interval=30s --timeout=10s \
CMD curl -f http://localhost:3000/health || exit 1
앱에서 /health API를 만들어, 상태 확인 전용 엔드포인트를 구축합니다.
Tip: Kubernetes나 AWS ECS와 같은 환경에서도 유사한 헬스체크 기능이 기본 제공됩니다.
🔄 자동 재시작 설정
Docker는 컨테이너가 예기치 않게 종료됐을 때 자동으로 재시작하게 설정할 수 있습니다.
docker-compose.yml 설정 예시:
restart: always
옵션 종류:
- no: 기본값 (자동 재시작 안 함)
- on-failure: 에러 종료 시만 재시작
- always: 항상 재시작
- unless-stopped: 수동 중지가 아닌 경우에만 자동 재시작
실무 Tip: 불필요한 재시작 루프에 빠지지 않도록 healthcheck와 함께 사용하는 것이 좋습니다.
💾 데이터 백업 전략
장애 중 가장 치명적인 것은 데이터 손실입니다.
데이터베이스는 반드시 주기적으로 백업해야 하며, 백업 파일은 로컬이 아닌 외부 저장소(S3 등) 에 보관해야 안전합니다.
MySQL 백업 예시
mysqldump -u root -p mydb > backup.sql
S3 업로드 예시 (AWS CLI 필요)
aws s3 cp backup.sql s3://mybucket/db-backups/backup-$(date +%F).sql
보너스: cron과 쉘 스크립트를 이용한 자동 백업 루틴 설정
0 3 * * * /usr/bin/mysqldump -u root -p$MYSQL_PW mydb | gzip > /backup/db-$(date +\%F).sql.gz
🔁 롤백 전략: 안전한 되돌리기
서비스 변경 후 오류 발생 시, 이전 상태로 빠르게 되돌릴 수 있는 전략도 중요합니다.
방법 1: Docker 이미지 버전 태깅
docker build -t my-app:v1 .
docker tag my-app:v1 my-app:latest
이후 문제가 생기면 이전 이미지로 교체 실행:
docker run -d --name app -p 3000:3000 my-app:v1
Tip: docker-compose.override.yml을 활용하면 운영과 개발 구성을 쉽게 전환할 수 있습니다.
방법 2: GitHub Release 사용
코드 변경마다 Release 태깅 → 문제가 생기면 해당 커밋으로 Checkout 후 재배포
git checkout tags/v1.0.2
🔔 알림과 대응 자동화
- 장애 징후 포착 → Slack 또는 SMS로 즉시 알림 전송
- 심각도 기준으로 GitHub Issue 자동 생성 (CI 연동)
- PagerDuty, OpsGenie 등 도입 고려
예시: Slack 알림
curl -X POST -H 'Content-type: application/json' \
--data '{"text":"🚨 서버 응답 없음. 즉시 확인 요망."}' \
https://hooks.slack.com/services/XXX/YYY/ZZZ
실전 팁: 로그 기반 이벤트 트리거링과 시스템 리소스 경고를 함께 구성하면 정확도 상승
🧪 실전 구성 체크리스트
- 헬스체크 API /health 구현 완료
- restart: always 설정 확인
- 백업 스크립트 및 외부 저장소 연결 확인
- 이전 이미지로 롤백 테스트 수행
- 장애 발생 시 알림 시스템 작동 테스트
추가 Tip: 실제 운영 배포 전에는 테스트 환경에서 위 항목을 미리 시뮬레이션하는 것이 중요합니다.
🧭 회고: 장애도 경험의 일부다
장애는 ‘일어나지 말아야 할 일’이 아니라, ‘일어나도 괜찮게 준비해야 하는 일’입니다.
실제로 많은 서비스들이 장애 이후 더 강해졌습니다.
우리는 이제 단순한 앱을 만드는 수준을 넘어서, 신뢰성과 회복력을 갖춘 운영을 목표로 나아갑니다.
우리가 얻은 인사이트
- 장애는 예방보다 복구 속도가 관건이다
- 자동화 도구는 신뢰와 반복성의 핵심이다
- “운영자는 최악을 대비하며, 최선을 준비한다”
🔮 다음 편 예고: 테스트 자동화와 운영 안정성의 연결
이제 코드를 변경할 때마다, 사람이 직접 확인하지 않아도 자동으로 문제가 감지되는 구조가 필요합니다.
테스트 자동화는 바로 그 기초이자, 운영의 또 다른 축입니다.
💡 이제 우리는 ‘문제가 생겨도 멈추지 않는’ 시스템을 설계합니다.
다음은 문제를 미리 발견하고 차단하는 자동화의 이야기입니다.