사례2건

2건 중 1~2번째

1. IL-0575 OpenSearch 의 힙 사용률이 치솟아 클러스터가 red 상태가 되고 관리 화면의 고객 목록이 열리지 않았다

   Sonicmoov2026

   증상

   정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 곧이어 고객 문의도 들어왔다. AWS 를 살펴보니 OpenSearch 가 red 상태였다.

   서비스 중단메모리 압박

   원인

   용량 한계

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   용량 계획 부재

   감지

   정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 이어서 고객 문의가 들어왔다. 엔지니어가 AWS 를 살펴보고 OpenSearch 가 red 상태인 것을 확인했다.

   조치

   • OpenSearch 노드를 재시작해 30분쯤 만에 장애를 일시적으로 풀었다.
   • 노드 9개에 맞춰 이름에 날짜를 넣은 새 인덱스를 만들고, 샤드 9개, 레플리카 0개, refresh_interval -1 로 설정했다.
   • reindex 로 옛 인덱스의 데이터를 새 인덱스에 복사하고, 끝난 뒤 두 인덱스의 문서 건수를 맞춰 보며 제대로 옮겨졌는지 확인했다.
   • 복사가 끝난 뒤 number_of_replicas 를 1 로, refresh_interval 을 1s 로 바꿨다.
   • 애플리케이션이 접속하는 별칭 customer_data 를 옛 인덱스에서 떼어 새 인덱스에 붙였다.
   • 별칭을 바꾸기 전까지 옛 인덱스에 들어온 데이터를 가져오려고, 첫 reindex 작업을 실행한 시각 이후의 event.at 값만 고르는 조건을 걸어 reindex 를 한 번 더 실행했다.

   교훈

   글쓴이는 서비스가 커지면서 비기능 요건을 갖추는 일이 필요해졌다고 보고, 문제가 생기기 전에 미리 알맞게 대처하겠다고 했다. 인프라를 구축한 담당자가 이미 회사에 없어 인프라에 손대기가 부담스러웠다는 점도 함께 적었다.

   사례 보기
2. 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 서비스에 카오스 봇을 만든다.

   사례 보기

원인별1