“죽지 않아. 알아서 고쳐.”
자동으로 회복하는 인프라의 세계
셀프 힐링 시스템이란?
셀프 힐링 시스템(Self-Healing System) 이란,
애플리케이션이나 시스템에 장애가 발생했을 때
사람의 개입 없이 자동으로 문제를 감지하고 복구하는 시스템입니다.
예를 들어, 서버 하나가 다운됐는데도
자동으로 새 서버가 뜨고 트래픽이 거기로 흘러간다면?
그게 바로 셀프 힐링!
왜 필요한가?
시스템은 언제든 망가질 수 있다
- 컨테이너가 다운됨
- 메모리 누수 발생
- DB 커넥션이 끊김
- CPU 100%로 고정
이런 상황들, 실제로 운영 환경에서 자주 발생합니다.
하지만, 사람은 24시간 대응할 수 없다
모든 에러를 개발자가 수동으로 고치기엔 시간과 비용이 너무 큽니다.
특히 야간/주말에는 대응 속도도 느려지죠.
→ 셀프 힐링이 필요한 이유
어떤 문제를 “스스로” 고치는 걸까?
| 상황 | 셀프 힐링 방식 |
| 서버 프로세스 다운 | 자동 재시작 |
| 컨테이너 비정상 상태 | 헬스 체크 후 재배포 |
| CPU, 메모리 과다 사용 | 인스턴스 재할당 / 스케일 아웃 |
| 포드 간 네트워크 끊김 | 네트워크 재설정 or 리스케줄링 |
| DB 연결 실패 | 재시도, 장애 조치(Failover) |
즉, “무조건 고치는 것”이 아니라
고장났다는 걸 감지하고, 그에 맞게 반응하는 것이 핵심입니다.
셀프 힐링의 주요 기법들
모니터링 + 알림 + 반응
- Prometheus, CloudWatch, Datadog 등으로 시스템 상태를 실시간 모니터링
- 이상 징후 감지 시 자동 대응 (ex. Restart, Scale-out 등)
헬스 체크 & 재시작
- 컨테이너나 애플리케이션이 응답이 없으면 자동으로 재시작
장애 조치(Failover)
- 마스터 DB가 죽으면 슬레이브 DB로 자동 전환
오토 스케일링 연동
- 리소스 과부하가 생기면 자동으로 인스턴스를 추가하거나 재할당
서킷 브레이커 / 재시도 전략
- 네트워크 장애가 발생했을 때, 자동으로 재시도하거나 우회
대표적인 예시
Kubernetes (K8s)
- Pod이 죽으면 자동 재시작
- Liveness/Readiness Probe로 상태 감지
- Node가 비정상이면 Pod 재배치
ReplicaSet으로 항상 지정된 수의 인스턴스를 유지
AWS
- EC2 Auto Recovery: 하드웨어 장애 시 자동으로 인스턴스 복구
- RDS Multi-AZ: 장애 발생 시 대기 인스턴스로 자동 전환
- ECS: Task 죽으면 자동 재시작
Netflix의 Chaos Monkey
- 일부러 시스템을 망가뜨려도 전체 서비스가 살아남게 설계
- 셀프 힐링 + 회복력 훈련의 정점
한계점은 없을까?
“진짜 문제”를 덮어버릴 수 있다
- 고장 원인을 로그로만 남기고, 자동으로 복구해버리면
근본적인 버그가 계속 숨어있을 수 있음
잘못된 복구 시나리오
- 자동 대응 로직이 잘못돼 오히려 더 큰 장애를 유발할 수 있음
비용 증가
- 오토 스케일링, 재시작 등은 리소스를 더 쓰는 방식이기도 해서, 무작정 쓰면 비용 부담
마무리: 셀프 힐링은 '회복력 있는 시스템'의 핵심
“사람이 24시간 붙잡고 있지 않아도 되는 시스템”
그게 바로 현대 인프라에서의 이상적인 모습이고,
셀프 힐링은 이 목표에 가장 가까운 해답입니다.
장애가 발생했을 때
- 알아서 복구되고
- 서비스는 끊기지 않고
- 개발자는 푹 잘 수 있는
그런 환경을 만든다는 건, 단순한 편의가 아니라 서비스 신뢰성 자체를 지키는 일입니다.
728x90