AI 시스템 구축: 자동화 기법 – Self-healing
ㅁ 자동화 기법
ㅇ 정의:
– 시스템이나 서비스에서 장애나 오류가 발생했을 때, 사람이 개입하지 않아도 자동으로 문제를 감지하고 복구하는 기능 또는 기법.
– 주로 모니터링, 진단, 복구 절차가 통합된 자동화 운영 환경에서 구현됨.
ㅇ 특징:
– 실시간 상태 모니터링 및 이상 징후 감지.
– 사전 정의된 복구 시나리오 또는 AI 기반 의사결정으로 문제 해결.
– 서비스 중단 시간을 최소화하여 가용성을 높임.
– 로그 분석, 상태 점검, 재시작, 롤백 등의 조치를 자동 수행.
ㅇ 적합한 경우:
– 24/7 무중단 서비스가 필요한 금융, 통신, 클라우드 서비스 환경.
– 대규모 서버나 컨테이너 환경에서 장애 대응 속도가 중요한 경우.
– 인력 자원이 한정되어 즉각적인 수동 대응이 어려운 경우.
ㅇ 시험 함정:
– Self-healing은 장애 예방이 아니라 장애 ‘발생 후’ 자가 복구임.
– 모든 오류를 복구하는 것이 아니라 사전에 정의된 범위 내에서만 자동 복구.
– 모니터링만 하는 것은 Self-healing이 아님.
ㅇ 시험 대비 “패턴 보기” 예시:
– (O) Self-healing 시스템은 장애 발생 시 자동으로 감지하고 복구 절차를 수행한다.
– (X) Self-healing 시스템은 장애를 사전에 완전히 예방한다.
– (X) Self-healing은 관리자 승인 없이는 복구를 시작하지 않는다.
ㅁ 추가 학습 내용
Self-healing 학습 정리
1. Self-healing 구현 방식
– 규칙 기반(rule-based): 사전에 정의된 조건과 규칙에 따라 자동 복구 동작 수행. 예측 가능성이 높고 구현이 단순하지만 새로운 유형의 장애 대응에는 한계가 있음.
– 머신러닝 기반(ML-based): 과거 데이터와 패턴을 학습하여 이상 징후를 탐지하고 복구 동작을 결정. 유연성과 적응력이 높으나 모델 학습 및 유지 관리가 필요하고 예측 오류 가능성 존재.
2. 클라우드 네이티브 환경에서 Kubernetes의 Self-healing 메커니즘
– Pod 재시작: 컨테이너 상태가 비정상일 때 kubelet이 자동으로 재시작.
– ReplicaSet 보정: 지정된 replica 수와 실제 실행 중인 Pod 수를 비교하여 부족한 경우 자동 생성.
– Node 장애 시 Pod 재스케줄링: 장애가 발생한 Node의 Pod를 다른 정상 Node로 이동.
3. SRE에서의 Self-healing 적용과 SLO/SLA 연계
– SRE는 서비스 신뢰성을 유지하기 위해 Self-healing을 자동화된 운영 도구로 활용.
– SLO(서비스 수준 목표)와 SLA(서비스 수준 계약)를 충족하기 위해 장애 발생 시 신속한 복구를 자동화하여 가용성과 안정성을 보장.
– Error budget 관리와 연계하여 Self-healing 자동화의 수준과 범위를 결정.
4. Self-healing과 Auto-scaling, Chaos Engineering과의 관계
– Auto-scaling: 부하 변화에 따라 자원을 자동 증감하는 기능으로, Self-healing은 장애 복구에 초점. 두 기능은 함께 사용되어 안정성과 효율성 향상.
– Chaos Engineering: 의도적으로 장애를 유발하여 시스템의 복원력과 Self-healing 메커니즘을 검증하는 실험적 접근.
5. 장애 유형별 복구 전략과 한계점
– 네트워크 장애: 연결 재시도, 대체 경로 사용, 서비스 메시 기반 라우팅 변경. 한계는 외부 네트워크 문제나 ISP 장애 시 자동 복구 어려움.
– 애플리케이션 크래시: 프로세스 재시작, 컨테이너 재배포. 한계는 코드 결함 지속 시 반복 크래시 발생 가능.
– 디스크 고장: 데이터 복제본 사용, 스토리지 교체, 클라우드 스토리지 마이그레이션. 한계는 데이터 손실 가능성과 복구 시간 지연.