사례2건

2건 중 1~2번째

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-0519 AWS 보안 그룹 변경으로 cloud.gov PaaS 의 나가는 트래픽이 막혀 애플리케이션들이 멈췄다

   cloud.gov2016

   증상

   cloud.gov 에서 돌던 애플리케이션 가운데 의존하는 서비스에 접속하려고 밖으로 트래픽을 보내던 애플리케이션들은 그 트래픽이 막혀 쓸 수 없게 됐다. 한때는 cloud.gov 의 모든 애플리케이션이 멈췄다.

   네트워크 도달 불가서비스 중단

   촉발

   3월 8일 태평양 시간 오전 9시 28분에 Aquilent 의 외주 엔지니어가 AWS 의 보안 그룹 설정을 바꿔 cloud.gov PaaS 의 나가는 트래픽을 제한했다. 이 변경은 플랫폼의 ATO 를 받는 과정에서 하던 여러 변경 가운데 하나였다.

   원인

   설정 변경

   구성 요소

   VPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   –

   조치

   • 애플리케이션마다 보안 그룹 예외를 더해 일부 애플리케이션을 되살렸다.
   • 결국 보안 그룹 변경을 롤백하기로 했고, 3월 9일 태평양 시간 오전 8시에 모든 애플리케이션이 돌아왔다.

   후속 조치

   • 보안 그룹 설정을 모두 버전 관리에 넣고, 풀 리퀘스트로 바뀔 내용을 보이게 하며 변경을 언제 적용할지 통제한다.
   • cloud.gov 에서 도는 애플리케이션을 모니터링하고, 애플리케이션이 기대대로 돌지 않으면 cloud.gov 팀이 알림을 받게 한다.
   • AWS 보안 그룹 대신 CF 보안 그룹을 쓰고, 이 규칙의 현재 상태를 cloud.gov 팀과 cloud.gov 를 쓰는 팀들이 볼 수 있게 한다.
   • 플랫폼에서 도는 애플리케이션마다 주요 연락 담당자에게 알릴 수 있는 알림 체계를 만든다.
   • 이런 변경을 실제와 더 가깝게 시험할 수 있도록 스테이징 환경을 더 정확하게 만든다.

   사례 보기

원인별2