사례8건

8건 중 7~8번째

1. IL-0520 logs.cloud.gov 로그인이 리디렉션 루프에 빠지고 로그 검색 서비스가 하루 넘게 멈춤

   cloud.gov2016

   증상

   미국 동부 시각 2016년 7월 5일 오후 7시 12분, cloud.gov 의 로그 검색 서비스 logs.cloud.gov 에서 로그인 리디렉션 루프가 발견됐다. 사용자는 서비스에 로그인할 수 없었다.

   서비스 중단쓰기 거부

   원인

   용량 한계

   구성 요소

   인메모리 캐시Elasticsearch 와 OpenSearch

   기여 요인

   장애 중첩모니터링 사각지대

   조치

   • logsearch 서비스의 Redis 를 훨씬 큰 메모리 인스턴스로 바꿔, Elasticsearch 클러스터가 내려가 있는 동안에도 로그를 계속 받아 두게 했다.
   • Elasticsearch 설정에서 메모리 설정과 하드닝 스크립트 문제를 고치고 클러스터를 다시 배포했다.
   • 클러스터 배포가 끝난 뒤 Kibana 인스턴스를 다시 배포하고 로그를 확인해 서비스를 되살렸다.

   후속 조치

   • 로그가 계속 들어오고 있는지 확인하고, 끊기면 울리는 장애 알림을 만든다.
   • Redis 에 오토스케일링이나 고가용성을 갖춰, Redis 다음 단계에 있는 더 취약한 구성 요소가 실패해도 데이터를 잃지 않게 한다.
   • 보안 사고가 아닌 사건도 다루도록 사고 대응 계획을 넓힌다.
   • logs.cloud.gov 서비스에 카오스 봇을 만든다.

   사례 보기
2. IL-0320 주 MySQL 서버의 디스크가 가득 차 메일 발송, API, 웹 화면이 지연됐다

   Postmark2011

   증상

   오전 8시 15분 EDT 무렵 주 MySQL 서버의 디스크 공간이 바닥나 메일 발송, API, 웹 화면이 지연됐다. 디스크 공간 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

   노드 디스크 가득 참쓰기 거부장애 조치 실패

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   –

   감지

   서버마다 디스크 공간을 감시해 알리는 시스템이 있었다. 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

   조치

   • 로그를 지워 디스크 공간을 확보하려 했지만 쉽게 되지 않았다.
   • 약 30분 뒤 두 번째 서버로 직접 장애 조치했고, 그 뒤 서비스가 정상으로 돌아왔다.
   • 장애 조치 뒤 실패한 작업을 복구했다.
   • 데이터베이스를 쓸 수 없는 동안 각 서버가 메일을 로컬 큐에 쌓아 두었다가 복구 뒤 보냈으므로 잃어버린 메일은 없었다.

   후속 조치

   • 가용성과 성능에 초점을 맞춰 클러스터를 업그레이드한다.
   • 문제를 더 일찍 잡도록 알림을 조금 더 민감하게 바꾼다.

   교훈

   돌아보면 처음부터 바로 두 번째 서버로 장애 조치했어야 했다. 팀은 복제가 정상인지 먼저 확인하려다가 약 30분을 썼다.

   사례 보기

원인별1