if Kakao dev 2020 - 카카오 대 장애 회고 정리

원인 분석

데이터센터 간 이중화 미흡

• 일부 시스템이 판교 데이터센터에서만 설치되어 있어 이를 사용하는 서비스들의 복구가 늦어짐
• 카카오 로그인, 카카오 사진 전송 기능 등이 여기에 속함
• 하나의 데이터 센터에서 장애가 발생하면, 다른 데이터 센터로 자동 전환하는 시스템이 작동해야 하는데,
  해당 시스템도 판교 데이터 센터에서만 존재했음 -> 수동 전환 작업으로 늦어짐

운영 관리 도구의 이중화가 부족

• 컨테이너 이미지를 저장하고 관리하는 시스템이 화재 여파로 사용할 수 없게 됨

이중화 전환 후 가용 자원 부족

• 판교 데이터 센터 전체를 대신할 만큼의 가용 자원이 확보되지 않아, 판교 데이터 센터가 복구될 때 까지 해결이 늦어짐
• 장애 복구를 위한 인력이 부족

재발 방지를 위한 대책

판교 데이터 센터 내에서만 32,000대의 서버를 사용중이었다.
판교와 타 지역 중심으로 이중화해왔지만, 판교 내 화재로 인해 모니터링 및 분석툴 마비로 장애 탐지가 원할하지 않음.
이후에는 모니터링 시스템을 다중화하겠다고 선언

DB 데이터 다중화

카카오에서는 DB 로 크게 RDBMS, NoSQL, 분산 빅데이터 스토어, 데이터 클러스터를 사용하고 있는데
RDBMS 와 NoSQL 은 데이터센터 간 다중화가 되어있어 데이터 손실 없이 복구가 가능했다.

다중 복제 구조 구성

앞으로는 모든 데이터를 일대일 복제를 넘어 다중 복제 구조로 구성하여 장애 발생 시 장애 복구 조치를 즉각 실행할 수 있는 환경을 구축하겠다고 함

플랫폼 도구 클러스터 (엘라스틱서치, 레디스, 카프카 등)

현 카카오는 플랫폼 도구 클러스터가 데이터센터 전면 장애를 대비한 구조로 구성하고 있지 않았다.
앞으로는 모든 클러스터를 데이터센터 단위에서 삼중화하여 전면 장애에 대비하겠다고 함.

서비스 장애

캐시 서버 등의 기반 시스템이 HA 로 구성되어 있었다.
앱은 데이터센터 이중화가 되어 있는 컨테이너 오케스트레이터 위에서 동작하여
각 노드별로 헬스 체크에서 이상있는 노드들을 자동으로 제외하는 방식으로 동작하고 있었다.
하지만, 데이터센터 장애 시 캐시 서버는 HA 구성이 되어 있었음에도 불구하고 자동 전환이 정상적으로 동작하지 않음
그로인해 각 노드의 헬스 체크가 실패하면서 모든 앱이 비활성화되며 서비스 오류가 발생함.
장애 도구가 대부분 화재로 인해 동작하지 않는 상황이어서 원인 파악에 많은 시간이 소요됨.
타 지역의 데이터센터에서 캐시 서버가 활성화 된 이후에야 서비스를 정상화 할 수 있었다.
카카오톡 서버, 카카오 로그인 등의 서비스에서는 서비스 간 의존성 문제, 서버의 불완전한 페일오버 구성등의 문제가 있었다.
또한 트래픽 쏠림 시 대응 부족과 충분치 않은 장애 시나리오에 문제가 있었다.

바로 서버를 기동 시킬 수 있었지만 의존성이 있는 다른 서버가 응답이 없을 경우, 기동 시킬 수 없는 서버가 있었다.
그리고 서비스가 이중화되어 있고 페일오버를 자동화해 놓았다고 하더라도 동작 이상을 감지하는 서버에 문제가 생기자 페일 오버가 동작하지 않았다.
한쪽 데이터센터에 장애가 발생하여 다른 데이터센터로 트래픽이 몰리자 부하가 커지면서 파드의 응답 속도가 느려지고 헬스 체크에 실패하는 경우도 있었다.
헬스 체크에 실패한 파드들은 클라우드 오케스트레이션 서비스가 자동으로 중지시키므로 전체 서비스가 내려가는 상황이 발생했고,
다시 기동시키려고 했을 때는 컨테이너 이미지 저장소의 장애로 다시 실행하지 못했다.

이후 서비스 장애 대응 전략

• 서비스 간 의존성 최소화
• 페일오버 구성 문제점 개선
• 장애 대응 시나리오 재검토
• 서버 구성정보, 배포설정 이중화

참고

• https://if.kakao.com/2022/session/1