카카오가 직접 회고한 1015 장애사태 원인과 대책
과오를 인정하고 더 나은 서비스를 만들겠다는 약속
카카오 대규모 장애 사태가 발생하고 벌써 두 달의 시간이 흘렀습니다. 현재는 서비스가 완전 정상화되었다고는 하지만, 또 언제 터질지 모르는 불안함 속에서 하루하루를 보내고 있는데요. (필자의 카카오홈 앱은 아직도 연결이 안 되고 있답니다 ^^) 그렇다고 당장 카카오 생태계를 대체할 수 있는 플랫폼도 없기 때문에 좋든 싫든 우리 일상 속에서 카카오를 완전히 벗어나기는 힘든 것 같습니다.
얼마 전 if(kakao)dev 2022에 참가했었습니다. 이프(카카오)데브 컨퍼런스는 매년 열리는 카카오의 개발자 컨퍼런스로, 행사를 통해 카카오의 개발자뿐만 아니라 모든 참가자들이 서로 소통하고 성장하는 것을 목적으로 하는 행사입니다. 조금 놀라웠던 점은, 이 행사에서 카카오가 1015 장애 사태에 대해 원인과 피해 규모, 개선 방향 등을 자세히 브리핑하는 세션을 따로 준비했다는 점입니다.
카카오같은 규모의 플랫폼 기업이 자신들의 과오와 실수를 대중에게 공개하는 것이 절대 쉬운 선택은 아니었을 것입니다. 일부 사람들은 카카오를 포식자, 독과점 기업으로 평가하고 있지만 분명한 것은 카카오로 인해 우리 일상생활이 더욱 편리하게 바뀌어 가고 있다는 점입니다. 서비스가 더 다양해지고 복잡해지면서 해결해야 할 문제들도 쌓여가고 있지만, 공개적인 자리에서 자신들의 실수를 인정하고 어떻게 개선해나갈 것인지 명확히 제시한 부분은 분명 응원할 점인 것 같습니다.
오늘은 if(kakao)dev 2022 컨퍼런스에서 1015 장애 사태 세션의 내용을 비전공자 및 일반인이 이해하는데 문제없을 정도의 대략적인 내용만 요약했습니다. 더 딥한 실무 내용은 각 주제별로 하단에 원본 영상 링크를 첨부했으니, 해당 영상을 참고해주시기 바랍니다 :)
<이미지= 연합뉴스>지난 10월 15일 오후 15시 30분경, SKC&C 판교 데이터센터에서 화재가 났었다. 이로 인해 카카오 전체 서버의 1/3의 전원이 꺼지면서 127시간이라는 긴 시간 동안 카카오의 주요 서비스들(커뮤니케이션, 결제, 교통)에 치명적인 장애가 발생했다.
똑같은 데이터센터에 입주해 있는 네이버와 SK텔레콤도 일부 서비스에 장애가 발생했지만, 서비스 전반이 멈추진 않았다. 이는 네이버가 데이터를 분산해 서비스를 운영하고 있기 때문이다. 반면에 같은 대형 플랫폼 업체인 카카오는 데이터 이원화 체제를 제대로 갖추지 못했다는 지적과 함께 거센 비판을 받았다.
카카오는 지난 7일부터 9일까지 3일 간 진행한 'if(kakao)dev 2022 개발자 컨퍼런스'에서 이번 1015장애 회고 세션을 총 5가지 트랙으로 나누어 장애 원인과 재발 방지를 위한 대책을 설명했다. 또, 이번 사태로 체득한 경험과 지식을 지속적으로 공유하며 더 나은 서비스를 만들어갈 것임을 약속했다.
데이터센터 단위의 다중화를 위한 고민
카카오의 데이터센터는 판교 데이터센터(DC 1)를 포함해 총 4곳으로 분산되어 있다. 카카오는 다양하고 많은 서비스들을 운영하고 있기 때문에 하나의 서비스를 여러 데이터센터에 분산해서 관리하고 있다.
서비스의 데이터센터 간 다중화 설계가 잘 되어 있었다면, 장애가 발생해도 빠른 시간 내에 복구가 되었을 것이다. 그러나, 카카오는 이번과 같은 데이터센터 규모의 장애에서 빠르게 복구될 수 있도록 데이터 설계가 되어 있지 못했기 때문에 서비스가 정상 복구되는데 상당 시간이 소요되었다.
완전한 데이터 이중화를 설계하기 위해서는 크게 5가지 기술적 레이어가 각각 데이터 이중화에 대비되어 있어야 한다. 카카오 회원플랫폼사업실 유용하(indy) 실장은 아래부터 카카오의 기술적 레이어에 대해 설명하며, 각 레이어에서 장애를 발생시킨 원인과 보완이 필요한 부분을 공유하겠다고 밝혔다.
인프라 설비 레이어는 상면, 전력, 네트워크와 같은 물리적인 설비 장치로 이번 사고에 직접적 원인이 된 부분이다. 이번 사고에서는 규모에 비해 인프라 설비 레이어의 다중화 관련 대응은 대체적으로 잘 동작했다고 볼 수 있지만, 보완해야 하는 부분을 찾을 수 있었다고 덧붙였다.
데이터 레이어는 카카오의 서비스에서 사용되는 많은 데이터들을 다루는 레이어로 신뢰성 있는 서비스를 제공하기 위한 근간이 되는 부분이다. 서비스에 사용되는 데이터는 실시간 이중화, 삼중화 백업되고 있어 데이터 유실이 발생하지는 않았지만, 이번 사고를 통해 더 개선해야 할 점을 찾을 수 있었다고 말했다.
운영 및 관리 도구 레이어는 실제 서비스의 트래픽을 받는 부분은 아니지만, 권한 및 소스 관리, 빌드, 배포, 문서 저장소 같은 서비스 운영에 필요한 기술적 도구들이 속한 부분이다. 카카오에서는 해당 레이어의 다중화 구성을 깊이 있게 생각하지 않아서 이번 사고 때 긴 시간 동안 정상 동작하지 못했으며, 서비스 전체의 정상화까지 가장 많은 복구 시간을 발생시켰다고 말했다.
서비스 플랫폼 레이어는 카카오에서 공통적으로 사용하는 플랫폼 도구를 분류하는 레이어로 보안키 저장소, 대용량 미디어 저장소와 같은 공용 솔루션들을 포함하는 부분이다. 거의 모든 서비스에서 공통적으로 사용되는 특성이 있는 만큼 이번 장애에서 연쇄 작용을 일으켰다.
애플리케이션 레이어는 실제 사용자에게 서비스를 하기 위한 컴포넌트 구성과 소프트웨어다. 자체적으로도 많은 컴포넌트로 구성되어 있는 만큼 여러 시스템에 대해 복잡한 의존성을 가지고 있다는 특성이 있다. 이로 인해 여러 부분에서 병목현상이 발생할 수 있고, 일부 시스템 장애가 전체 시스템 장애로 이어질 수도 있다.
데이터센터 단위의 다중화를 위한 고민 트랙 영상보기 >
인프라 설비 레이어 다중화
인프라 설비 레이어 다중화 트랙에서는 화재 발생의 원인과 화재 발생 직후 카카오의 네트워크가 어떻게 작동했는지, 또 이번 사고의 재발 방지를 위해서 카카오가 어떤 고민을 했는지에 대해 설명했다.
화재 발생 원인은 SKC&C 지하 3층 전기실의 배터리에서 스파크로 인한 화재이다. 화재로 인해 코어 네트워크의 통신이 끊기면서 이미 대부분의 서버가 제 기능을 상실하고, 외부와 통신이 끊겨 정상 작동하지 않았다. 언론은 화재 진압을 위해 전력을 차단하면서 데이터센터의 기능이 마비되었다고 발표하고 있지지만, 실제로는 화재 직후 코어 네트워크의 통신이 전부 끊겨 코어 네트워크의 기능을 상실했다고 한다.
장애 원인 분석과 향후 대책 방안에 대해서는 소화가스와 스프링클러 이중화를 구성해 소화 설비를 충분히 구축할 필요가 있다고 말했다. 또, 기존 배터리 간 간격이 좁고 배터리 모듈이 서로 맞닿아 있어 화재가 번지기 쉬운 구조였기 때문에 배터리 간 최대 설치 거리를 확보할 필요성이 있다며 덧붙였다.
다음으로 CCTV가 픽셀을 분석하고 화재를 탐지하여 즉각 발견하고 대응할 수 있도록 섬광 감지 카메라가 도입되어야 한다고 말했으며, 마지막으로 화재 발생 시 자동으로 소방서에 핫라인을 연결해 빠르게 조치할 수 있도록 자동 화재 속보기를 설치해 소방서의 지원을 빠르게 받을 수 있는 환경을 구현해야 한다고 말했다. 그밖에도 배터리실 다원화 등 피해를 최소화할 수 있는 방안에 대해서 설명했다.
카카오가 신규 데이터센터를 구축할 때 위와 같은 설비가 구축될 수 있도록 세심하게 검토하여, 안전하게 서비스를 이용할 수 있는 환경을 만들겠다는 약속과 함께 발표를 마쳤다.
다음은 카카오의 데이터센터 네트워크 구성 현황과 장애 당시의 네트워크 영향에 대해 설명했다. 카카오의 인프라는 크게 두 개의 백본 센터와 물리적으로 분리된 2개 이상의 확장 센터로 구성되어 있다. 확장 센터들은 두 개의 백본 센터와 모두 분산해서 연결을 맺고 있으며, 회선 장애 시에는 자동적으로 우회되도록 다이내믹 라우팅으로 구성되어 있다.
장애 당시 상황을 살펴보면, 판교 데이터센터의 외부 통신사들의 회선은 모두 2개의 백본 센터에 분산 배치되어 있었기 때문에 처리 용량을 줄었지만, 인터넷으로 연결되는 경로는 정상 유지되고 있는 상태였다. 따라서, 다이내믹 라우팅 동작에 의해 경로들은 자동적으로 조정이 되었던 것으로 확인되고 있다.
외부 회선들은 평상시 최대 트래픽 사용량 대비 수 배 이상의 용량을 확보하고 있었기 때문에 처리 역량 부분에서는 위험한 상황은 아니었지만, 전원 전면 차단 이전에 일부 전원 불안정으로 인해 상당 수의 네트워크 장비가 이미 다운되었고, 이로 인해 카카오톡과 같은 주요 서비스가 이미 정상 작동하지 않았다고 한다.
데이터센터 복구 이후에도 대부분 장애 이전 상태로 복구되었으나, 일부 장비들은 하드웨어 결함이 발생(물리적 손실)하여 교체가 필요했다. 네트워크 레이어는 이중화 구성 정책에 따라 자동적으로 잘 동작되었다고 볼 수 있다. 다만, 장비나 시스템들의 다중화 구성은 잘 되어 있었지만, 일부 운영 툴과 모니터링 툴이 영향을 받았기 때문에 장애 당시의 로그도 상당량 손실이 발생한 것으로 파악되고 있다.
따라서, 향후 모니터링 툴, 분석 툴과 같은 네트워크 운영에 관계된 백엔드 플랫폼까지 모두 이중화될 수 있도록 대책을 마련할 필요성이 있다고 말했다. 추가로 네트워크 백본 삼중화, 데이터센터 간 전송망 대폭 확장 등 네트워크 구조 개선 계획에 대해서도 설명했다.
데이터 레이어 다중화
카카오는 MySQL, PostgreSQL, Oracle 등을 주력으로 하는 'RDBMS', MongoDB를 주력으로 하는 'NoSQL', 그리고 HBase, Druid, Hadoop으로 처리되는 '빅데이터 클러스터'로 크게 3가지 카테고리로 나누어서 데이터를 보관 및 운영하고 있다.
RDBMS는 HA, DR 운영을 위한 DBMS 구성 자체로 인한 문제나 복구 과정에서의 데이터 손실은 없었다. 평상시 운영노드는 서비스 트래픽을, 재해복구(DR) 노드는 분석 작업을 나누어 수행하는 구조로 운영되고 있어 었다. 그러나, 장애 당시 내부 백업 스토리지 시스템의 장애와 재해복구(DR) 백업 스토리지에 대한 접근이 불가했던 이슈가 있었다고 한다.
NoSQL은 데이터를 삼중화해 작동하는 구조이다. 장비의 인스턴스 부족으로 세 군데의 인터넷데이터센터(IDC)로 분산되지 못하고, 두 군데의 인터넷데이터센터(IDC)로 분산되는 사례가 있었다. 한 군데의 IDC에서 두 개의 노드가 동시에 장애가 발생할 경우, 나머지 한 개의 노드가 읽기 전용 모드로 동작되어, 일부 서비스는 읽기 전용 모드로 전환되어 운영했다고 말했다.
빅데이터 클러스터는 내부의 데이터가 NoSQL과 마찬가지로 삼중화되어 분산 구성되어 있고, 대부분 주요 클러스터가 다중화되어 운영되기 때문에 직접적인 피해는 없었다. 그러나, 그중 IDC간 노드 분산이 되어 있지 않은 한 개의 클러스터가 발견되었다.
개선 사항으로는 최소 세 곳의 인터넷데이터센터(IDC)에 RDBMS를 구성하여 데이터를 다중화하는 것을 목표로 하고, 두 군데 이상의 IDC에 재해복구(DR) 시스템을 구축하겠다고 밝혔다. 또, 각 장비별로 가상 장비 인스턴스 용량을 충분히 확보하여 멀티 리전을 활용한 다중화 구성을 진행하겠다고 말했다.
추가로 일부 삼중화되어 있지 않은 MongoDB도 가상 장비 인스턴스 용량을 충분히 확보하여 세 곳의 IDC를 활용해 재구성할 계획이다. 빅데이터 클러스터의 경우에는 클러스터를 다중화하고 충분히 IDC 간 노드를 분산시켜 장애 시에도 상시 가용한 상태를 유지할 수 있도록 노력하겠다고 말했다.
서비스 플랫폼 레이어 다중화
서비스 플랫폼 레이어는 크게 운영관리 도구, 클라우드(Cloud) 그리고 오픈소스 기반 플랫폼인 레디스(Redis), 엘라스틱서치(Elasticsearch), 카프카(Kafka) 세 가지로 구분해 볼 수 있다.
카카오는 사내 계정인증을 위해 '앨댑(LDAP, Lightweight Directory Access Protocol)'을 사용하고 있는데, 이 프로토콜은 각 IDC 간 세 곳에 분산되어 있다. 화재 직후 판교 데이터센터의 사내 계정인증은 다른 IDC 센터로 변경해서 해결했다. 추가로 판교 데이터센터의 LDAP 서버를 사용하고 있는 깃(Git), 지라(Jira), 위키(Wiki)도 수동 전환하여 데이터, 통신 연결 유실을 피할 수 있었다.
공용준 클라우드플랫폼팀장은 데이터센터 규모의 재난에도 데이터센터 별 LDAP 유저(서버) 및 담당자 사전 파악 정보가 존재했기 때문에, 장애 영향 범위를 빠르게 파악 및 전파가 가능했다고 말했다. 사내 계정인증 서비스 구조가 단순한 면도 있지만, 서비스 간 연계 영향(Cluster)을 받지 않는 로직과 구조로 분리되어 운영되고 있었기에 운영관리 도구는 큰 이슈는 없었다고 한다.
그러나, 장애 대응 작업시간 자체는 길지 않았지만, VPN 접근이 원활하지 않아서 복구하는데 1시간 이상이 지체되었다. 이 과정에서 전사 장애 대응 훈련 시나리오의 필요성을 회고할 수 있었다고 말했다. 추가로 LDAP 클러스터를 상위에서 연결해주는 GSLB를 구성하여 예기치 못한 장애 상황 시 자동으로 전환되어 대응할 수 있는 구성이 필요하고 덧붙였다.
깃허브는 DC 이중화(Active-standby)로 구성되어 있지만, 판교 DC 장애 발생 직후 장애 조치(failover) 과정이 신속하게 이루어지지 못했다고 말했다. 그 이유 중 하나로 Standby 깃허브를 승격하는 과정이 예상보다 오랜 시간이 소요되었음을 설명했다.
그동안 깃허브 개발 테스트 과정에서 장애 조치(failover) 테스트를 진행할 때는 경험하지 못했던 부분이라, 추후 실환경에서 다양한 예외사항을 모의 훈련 테스트를 통해 경험하고, 원인 파악과 후속 대응을 성실하게 하겠다고 말했다.
또, 공용준 팀장은 이번 장애로 운영관리 도구 하나가 전체 서비스의 복구 과정을 더디게 만들어 피해를 키울 수 있다는 점에서 중요성을 깨달았고, 빌드 산출물 관리도구의 고가용성 필요성 역시 인식이 너무 부족했다는 점을 되돌아보며 즉각적으로 보완해 이중화 작업을 끝내고, 현재 삼중화 작업을 진행하고 있다고 말했다.
다음으로 강차훈 시스템엔지니어링파트장은 카카오가 전사적으로 운영하고 있는 오픈소스 기반 플랫폼인 레디스(Redis), 엘라스틱서치(Elasticsearch), 카프카(Kafka)의 장애 원인과 대응 과정에 대해 설명했다.
카카오의 서비스에 투입되는 레디스(Redis)의 종류에는 RHA(Redis HA), 레디스 싱글, 레디스 클러스트 세 가지가 있다. 이번 판교 데이터센터 사고 발생 시, 레디스 클러스트를 제외한 레디스 싱글과 RHA에서 장애가 발생했다. 레디스 클러스트는 구축 시 삼중화 작업이 되어 있었기에 장애 여파를 피할 수 있었다고 한다.
레디스 관리 툴과 내부 툴 또한 이중화되어 있지 않아 전부 수동으로 장애 여부를 체크해야 해서 정상화까지 더 긴 시간이 소요되었다. 외부에서 동작하는 의존 API도 복구가 되어야 정상화가 가능했기 때문에 플랫폼뿐만 아니라 이런 관리 툴까지 장애 조치(faliover) 대책이 필요하고 말했다.
엘라스틱서치(ES)의 경우 전체 서비스 단위의 30% 정도에서 장애가 발생했다. ES의 핵심 컴포넌트인 검색 등의 서비스는 전면적으로 장애가 발생했으며, 로그 저장소, 내부 관리도구 역시 일부 장애 영향을 미쳤다고 말했다. 다행히도 ES는 데이터센터 전면 장애 시 복구 시나리오가 있었기 때문에 절차대로 복구를 진행했고, 타 장애 플랫폼 복구 작업 대비 빠른 복구화가 가능했다고 밝혔다.
마지막으로 카프카(Kafka)를 살펴보면, 여러 서비스들이 공용으로 사용하는 공용 클러스터와 컴플라이언스, 부하 등의 이유로 특정 서비스마다 독립적으로 사용하는 개별 클러스터로 나뉜다. 판교 데이터센터를 비롯한 네 군데의 IDC에 Kafka 클러스터가 있는데 이중 공용 클러스터는 35%, 개별 클러스터는 25%가 판교 DC에 위치하고 있고, 해당 클러스터에서 장애가 발생했다고 한다.
애플리케이션 레이어 다중화
데이터센터의 다중화가 가능하려면 우선 각각의 데이터센터에 해당 서비스가 필요한 모든 구성요소가 갖추어져 있어야 한다. 하지만, 실제로 다중화가 필요했던 몇몇 서비스에서는 일부 구성요소가 IDC 내에 제대로 준비되지 않은 것으로 파악되고 있다.
위 이미지는 카카오톡의 대략적인 구성도이다. 상태 정보를 캐싱하던 레디스가 판교 DC 내에서만 서버이중화(HA) 구성이 되어 결국 데이터센터 다중화가 작동하지 않았다. 그 이유는 레디스를 담당하는 조직이 달랐고, 각각 다른 전략에 따른 이중화 작업 일정으로 진행하고 있었기 때문이라고 말했다.
또, 장애를 대비한 시스템 구성은 보통 과거에 경험한 문제를 해결하며 개선된 경우가 많기 때문에 오히려 경험해보지 않은 문제는 소홀해지기 쉽다는 지적도 있었다.
시스템 구성 다중화를 위한 계산 방향은 어렵지 않다. 서비스 시작 시점에 모든 구성요소가 데이터센터 다중화를 염두에 두고 구성하면 된다. 하지만 현실적으로 한정된 자원의 문제(상면 확보 어려움 등)도 있고, 많은 자원이 유휴 상태로 운영이 되어야 하는데 여러 측면에서 비효율적일 것이라는 게 유용하 실장의 주장이다.
따라서, 다중화의 구성 수준을 다양한 수준에서 분류하고, 서비스별로 영향도에 따라 적당한 다중화 구성을 하는 전략적인 접근이 필요해 보인다. 예를 들어, 카카오톡 대화 등 주요 기능이나 로그인 같은 필수적인 서비스는 완전한 다중화를 구성하고, 그 외의 서비스는 목표 트래픽이나 목표 복구 시간 등의 기준을 각각 적용하는 것이다. 또, 담당 조직이 파편화되어 있어도 일반적으로 설계를 적용할 수 있는 조직적 거버넌스의 필요성도 언급했다.
끝으로 실시간 복구 체계에 대한 이상과 현실에 대해 설명했다. 이상적으로는 실시간 시스템을 변경하는 일 없이 다중화된 데이터 센터로 전환이 되어야 하지만, 현실에선 그렇지 않다. 장애는 예상하지 못한 상황이고, 준비하지 못한 상황에도 대비할 수 있어야 한다.
현실에서는 실시간을 시스템을 재구성하고 변경해 대응해야 할 일이 생기곤 하는데 이런 방법이 주어진 상황에서 가장 빠르게 복구를 할 수 있는 방법인 경우가 많다. 카카오 역시 이번 장애에서 이런 시스템 재구성을 위한 도구들에 문제가 생겨 복구 작업에 차질이 생겼고, 이로 인해 그 중요성을 제고할 수 있는 계기가 되었다.
루트비히 비트겐슈타인은 말했습니다.
"나의 언어의 한계가 나의 세계의 한계다"
브런치를 통해 지식의 지평을 넓혀가고 있습니다.
오늘도 방문해주셔서 감사합니다.
2022. 12. 13. 채드윅.
