들어가기 전에
2022년 10월 15일 카카오의 DC 중 하나가 화재로 인해 마비가 되는 사건이 있었다. 몇 시간 이상 카카오의 서비스가 중단됐다. if(kakao)에서 이 엄청난 장애를 회고하는 세션들이 있었다.
장애로부터 정말 많은 것을 배울 수 있다. 부족했던 점을 다시 돌아볼 수 있기 때문이다. 장애를 직접 겪지 않고도 공유받을 수 있다는 게 정말 값진 기회처럼 느껴졌다. (장애를 겪으신 분들은 정말 힘드셨지만 😢) 그래서 모든 세션들을 챙겨봤다.
해당 글에서 세션을 보면서 배우고 느낀 점을 정리해봤다. 해당 세션들을 모두 못 봤지만 간단히 맛보기 하고 싶은 분들이 보면 딱 좋을 것 같다. 다만 모든 내용을 세세하게 요약한 글은 아니다. 그래서 자세한 내용을 원한다면 세션을 보는 것을 권장한다.
회고는 크게 4가지 레이어로 나뉘어있다. 인프라 레이어, 데이터 레이어, 서비스 플랫폼 레이어, 애플리케이션 레이어이다. 가장 로우 레벨인 인프라부터 장 하이 레벨인 애플리케이션까지 다루고 있다.
운영 도구의 마비
운영 도구는 시스템을 위한 관리 도구를 모두 통칭했다. 거의 모든 레이어에서 공통적인 어려움으로 꼽은 것은 모니터링, 배포 시스템, 내부 툴등 운영에 필수적인 것들 역시 같이 마비되면서 복구 자체가 어려웠던 것이었다. 아마 카카오 정도로 큰 회사는 이런 도구들을 사내에서 직접 제공하기 때문에 비교적 작은 규모의 회사보다 영향이 더 컸던 것 같다.
사실 나 역시 회고를 보기 전까지는 전혀 생각도 못했다. 일반적으로 다중화는 서비스, 데이터 베이스만 생각하지 운영 도구는 거의 고려하지 않기 때문이다. 하지만 서비스, 데이터 베이스에 복구 조치를 취하기 위해서는 이런 운영 도구가 필수이다. 아무리 서비스, 데이터 베이스가 다중화가 돼있어도 운영 도구로 복구를 못하면 끝이기 때문이다. 그리고 도구가 동작하지 않아 수동으로 처리하다보니 실수가 발생해 복구 시간이 더 길어졌던 사례도 있다고 한다.
DC간 노드 분산
보통 HA(High Availability)라고 하면 여러 노드로 시스템을 구성하는 걸 많이 떠올린다. 하지만 DC 하나에만 여러 노드로 구성하면 DC 전체 장애에는 소용이 없다. 실제로 카카오에서도 Active — Standby 혹은 여러 노드로 시스템을 구성했지만, 장애가 났던 판교 DC에서만 구성했기 때문에 시스템이 동작하지 않았던 예시가 있었다.
특히 ES 마스터 노드, 카프카 주키퍼 등 클러스터 상태 관리를 위해 쿼럼을 이용하는 시스템은 더 민감하다. 두 개의 DC에 이중화를 하더라도 장애가 난 DC에 과반 이상의 노드가 있다면 클러스터가 마비된다. 이 부분에서 아무리 멀티 DC로 구성해도 시스템을 잘 이해하지 않으면 소용이 없다고 생각했다. 정말 안전하게는 2DC 이중화 정도가 아니라 3DC 삼중화가 필요하다고 한다.
네트워크 트래픽 전환의 자동화 및 간소화
이 부분 역시 운영 도구처럼 거의 모든 레이어에서 언급한 부분이다. 트래픽을 뒷단의 서비스에 전달하는 부분, 즉 로드밸런서에서 자동으로 혹은 간소화된 절차로 트래픽을 빠르게 전환해야한다는 것이다. (더 정확히는 GSLB라고 언급된 것 같지만 조금 더 큰 범주로 로드밸런서라고 했다.)
어플리케이션에서는 조금 더 심화해 서킷 브레이커를 이용하는 방법도 있다고 한다. 여러 서비스에 의존하는 서비스인 경우 장애 민감도가 올라가므로 특히 권장하는 것 같다. 그리고 어플리케이션에서 조심해야할 부분도 있다. 의존하는 서버의 도메인 IP를 잘못 캐싱하면 안된다. 아무리 앞단에서 자동 전환 기능을 적용하더라도, 캐싱된 도메인을 사용해 서버의 재시작이나 배포가 필요하다고 한다.
복구 우선순위
특히 서비스 플랫폼에서 어려움을 겪은 것 같다. Redis, ES, Kafka 각각에 대해서 설명이 나올 때 빠지지 않는 것이었다. 클라이언트에 대한 정보가 충분하지 않아 복구 우선순위를 정하기 어려웠다고 한다. 사실 플랫폼의 경우 클라이언트에서 어떻게 사용하는지 알기 어렵다. 클라이언트와 일일이 컨택을 하거나 로그를 살펴봐야하기 때문이다. 또한 언제든지 변경이 될 수도 있다. 카카오처럼 수많은 서비스가 있다면 더욱 어려웠을 것 같다. 하지만 알지 못하면 어떤 것부터 복구해야될지 알기가 어렵다고 하니 평소에 챙겨야될 것 중 하나인 것 같다.
운영 환경에서 장애 복구 훈련
다른 것들도 실천하기 어렵지만 특히 이건 실천하기가 더 어려운 것 같다. 하나의 팀이 아니라 여러 팀의 협업이 필요할 수도 있기 때문이다. 또한 복구가 잘 되지 않으면 바로 서비스 장애가 되니 리스크가 크다. 하지만 세션을 보면 데브, 스테이징 환경에서 복구 훈련을 한 것과 운영 환경에서 실제로 복구를 할 때 달랐던 부분이 있었다고 한다. 아마 근소한 차이가 아니었기 때문에 언급이 된 것 같다. 확실히 운영 환경에서 장애 복구 훈련을 하는 게 실제 장애 환경에서 복구하는 것과 비슷할 것 같다. 그리고 그 과정에서 미리 문제점을 발견할 수도 있을 것 같다.
마무리
대규모 서비스를 DC 하나가 통째로 마비되도 문제가 없도록 운영하는 건 쉬운 일이 아닌 것 같다. 특정 레이어가 아니라 모든 레이어에서 신경을 써야하기 때문이다. 또한 평소에는 아무런 문제가 없을 수 있기 때문에 간과하기도 쉬워보인다. 하지만 시스템을 구성하거나 운영할 때 언급된 것들을 잘 지키도록 노력해봐야겠다. 엄청난 재난이어서 안타깝지만 회고 세션을 통해 대규모 서비스를 안정적으로 운영하기 위한 방법들을 알 수 있었다.
