20260411 TIL - 장애 대응 5장까지

[서론]

주말인데 뭔가 하기 싫어서 안했다. 주말이라 그런가.. 다른 생각들만 난다. 일단 컨디션 회복 후 심기일전해야겠다.

 

 

[오늘의 추천곡] Katy Perry - Dark Horse

케이티 페리의 곡이다. Roar, Firework, Cali gurls, Feels, HotNCold 등등 많은 곡이 있지만 이 곡만한 충격은 없는 것 같다. 과거에는 노래만 내면 뜨던 가수인데 요즘에는 히트곡이 거의 없다... 파워풀한 노래를 듣고 싶으면 케이티 페리의 곡을 추천한다.

 

 

 

[장애 대응]

1. 모니터링

모니터링의 목적은 장애를 고객보다 먼저 식별하는 데 있다. 가장 좋지 않은 장애 식별 방식은 고객 제보를 통해 처음 문제를 인지하는 경우이며, 이는 이미 사용자 경험이 훼손된 이후라는 점에서 늦은 대응이다. 효과적인 모니터링은 시스템, 애플리케이션, 사용자 경험, 알림 체계, 도구 구성까지 포함하는 종합적인 활동이다.

시스템 모니터링에서는 CPU, 메모리, 디스크 I/O, 네트워크 대역폭 같은 자원 사용량을 추적하고, 서버 가용성 및 응답 시간 등을 관찰해야 한다. 애플리케이션 모니터링에서는 로그 수집, 오류 탐지, 응답 시간, 처리량, 오류율 등을 통해 성능 병목과 이상 징후를 분석한다. 또한 헬스 체크를 주기적으로 수행하여 서비스의 정상 동작 여부를 확인할 수 있어야 한다.

사용자 경험 모니터링도 중요하다. 엔드 투 엔드 모니터링, 실제 사용자 브라우저에서의 데이터 수집(RUM), 사용자 피드백 분석 등을 통해 단순 서버 상태가 아니라 실제 사용자가 어떤 문제를 겪는지 관찰해야 한다. 알림 시스템은 임계값 기반으로 구성하되, 불필요한 알림 남발을 피하고 중요한 경고가 묻히지 않도록 채널 분리와 자동화가 필요하다. Prometheus, Grafana, ELK, New Relic 같은 도구는 각각 메트릭 수집, 시각화, 로그 분석, APM에 활용될 수 있다.

결국 모니터링은 단순히 숫자를 보는 행위가 아니라, 장애를 조기에 감지하고 대응 속도를 높이기 위한 운영 체계의 일부라고 볼 수 있다.

---

2. 장애 분석 및 진단

장애가 발생하면 가장 먼저 해야 할 일은 상황을 빠르게 인지하고 초기 대응 체계를 가동하는 것이다. 자동 알림 시스템을 통해 장애를 인지하고 관련 팀에 즉시 전파해야 하며, 동시에 장애의 영향도와 심각도를 평가해 우선순위를 정해야 한다. 서비스 중단인지, 성능 저하인지, 데이터 손상인지에 따라 대응 방식이 달라질 수 있다. 또한 장애 상황을 가능하면 재현하고, 과거 유사 사례와 패턴을 분석해 근본 원인에 접근해야 한다.

로그와 메트릭 분석은 진단의 핵심이다. 중앙 집중식 로그 관리 시스템을 기반으로 오류, 예외, 반복 패턴을 파악하고, CPU 사용률, 메모리 사용량, 네트워크 트래픽 등의 실시간 메트릭을 정상 상태와 비교해 이상 징후를 찾아야 한다. 단순히 에러 메시지 하나를 보는 것이 아니라, 로그와 메트릭을 함께 해석해야 정확한 원인 파악이 가능하다.

시스템 및 네트워크 분석도 필요하다. 프로세스 상태, 리소스 과다 사용, JVM 스레드 덤프, 네트워크 지연, 패킷 손실, 외부 API 연결 상태 등을 확인함으로써 애플리케이션 외부의 원인도 검토해야 한다. 데이터베이스 측면에서는 슬로우 쿼리, 락 대기, 데드락, 커넥션 풀 상태, 데이터 무결성 등을 점검해야 하며, 문제가 데이터 손상까지 이어졌다면 복구 절차를 준비해야 한다. 즉 장애 진단은 로그, 메트릭, 시스템, 네트워크, DB를 모두 포함하는 다층적 분석 과정이다.

---

3. 장애 복구

장애 복구의 목표는 근본 원인을 제거하는 것뿐 아니라, 사용자 영향 범위를 빠르게 줄이고 서비스 지속성을 회복하는 데 있다. 이를 위해 사전에 대응팀의 역할과 책임, 연락 체계, 표준 운영 절차(SOP), 긴급 대응 매뉴얼, 시나리오 기반 전략이 준비되어 있어야 한다. 장애는 기술 문제이기도 하지만 동시에 협업과 의사결정의 문제이기도 하다.

실시간 대응에서는 먼저 임시 조치를 통해 영향 범위를 줄이고, 원인을 가능한 한 격리해야 한다. 이후 상황을 이해관계자에게 명확히 전달하고, 복구 이후에도 지속적으로 모니터링해 문제가 정말 해결되었는지 확인해야 한다. 이 과정에서 내부 커뮤니케이션과 외부 커뮤니케이션은 별도로 관리되어야 하며, 특히 사용자 공지는 불안감을 줄일 수 있도록 사실 기반으로 전달되어야 한다.

복구 방식은 장애 유형에 따라 달라진다. 데이터베이스 장애는 백업 복원과 무결성 검증이 핵심이고, 애플리케이션 장애는 로그 기반 원인 파악 후 코드 수정 및 재배포로 해결할 수 있다. 캐시 문제가 원인일 경우 캐시 클리어가 유효할 수 있으며, 시스템 장애는 재부팅이나 디스크 정리로 복구할 수 있다. 네트워크 장애는 장비 재시작이나 네트워크 구성 변경을 검토해야 한다. 더 나아가 페일오버는 주 시스템 장애 시 스탠바이 시스템으로 전환해 서비스 연속성을 보장하는 대표적 방법이다. 즉 복구는 단순 재시작이 아니라, 장애 유형에 맞는 복구 수단을 선택하고 검증하는 과정이다.

---

4. 후속조치 및 사후평가 개선

장애는 복구로 끝나지 않는다. 복구 이후에는 반드시 원인 분석, 대응 과정 정리, 재발 방지 대책 수립, 문서화, 교육, 사후 평가가 이어져야 한다. 이것이 없으면 같은 유형의 장애가 반복될 가능성이 높다. 후속조치는 장애를 조직의 학습 기회로 전환하는 단계라고 볼 수 있다.

원인 분석에서는 로그, 메트릭, 시스템 상태 등을 종합적으로 검토하여 근본 원인을 찾는다. 여기서 5 Whys 기법처럼 “왜?”를 반복하여 표면적인 현상이 아니라 구조적 원인까지 파고드는 방식이 유용하다. 또한 자료의 페이지 14에는 피시본 다이어그램 예시가 제시되어 있는데, 이를 통해 문제 원인을 도구, 프로세스, 환경, 사람 관점으로 시각적으로 분해할 수 있다. 단기 해결책은 즉각적인 완화에 초점을 두고, 장기 해결책은 재발 방지를 목표로 설계해야 한다. 장애 발생부터 해결까지의 경과, 수행한 조치, 그 결과도 시간 순서대로 기록해야 한다.

이후에는 대응 조치 기록과 커뮤니케이션 로그를 남기고, 시스템 개선과 프로세스 개선으로 이어가야 한다. 교육과 시뮬레이션을 통해 팀의 대응 역량을 높이고, 장애 보고서와 대응 절차 문서를 최신 상태로 유지해야 한다. 사후 평가 회의에서는 대응 속도, 정확성, 커뮤니케이션 품질 등을 검토해 다음 장애에서 더 나은 대응이 가능하도록 피드백을 반영해야 한다. 결국 후속조치의 핵심은 “이번 장애를 끝내는 것”이 아니라 “같은 장애를 다시 겪지 않도록 운영 체계를 개선하는 것”이다.