[종합] 카카오가 스스로 돌아본 장애사태의 원인과 대책

지난 10월 15일, 카카오가 입주하고 있는 데이터센터에 화재가 발생했다. 이 화재는 127시간이라는 사상 초유의 서비스 장애로 이어졌다. 카카오톡을 비롯한 모든 카카오 관련 서비스가 정지됐다. 이로 인해 커뮤니케이션, 결제, 교통 등 사회 전반이 영향을 받았다. 카카오는 범국민적인 비판을 받았고, 정치권에서는 재발방지를 위한 법안 마련에 나서기도 했다. 이번 사태로 단순한 배터리 화재가 사회시스템을 마비시킬 수도 있다는 교훈을 얻었다. IT시스템의 안정적 운영이 얼마나 중요한지 깨닫는 계기가 되기도 했다.

같은 일을 반복하지 않기 위해서는 문제의 원인을 정확히 파악해 대책을 마련해야 한다.

카카오는 7일부터 8일까지 진행한 개발자 컨퍼런스 ‘이프(카카오)데브 2022’ 행사에서 5개의 기술세션을 통해 1015 장애 사태를 회고했다. 단순 화재가 대규모 서비스 장애로 이어진 이유는 무엇인지, 서비스 복구에 오랜 시간이 걸린 배경은 무엇인지 살펴보고, 유사 사태 재발을 방지하기 위한 대책을 설명하는 자리였다.

바이라인네트워크는 이날 행사에서 발표된 5개의 세션을 종합 정리했다.

 

데이터센터 단위의 다중화

유용하 카카오 회원플랫폼사업실장은 첫 번째 장애 관련 세션인 ‘데이터센터 단위의 다중화를 위한 고민’에서 재난의 원인을 레이어별로 나눠 소개했다.

유 실장은 “카카오 서비스를 위한 레이어를 ▲인프라 설비 ▲데이터 ▲운영 및 관리도구 ▲서비스 플랫폼 ▲애플리케이션 총 5개로 나눠 볼 수 있다”며 “각각의 레이어는 각각의 역할에 따른 다중화 설계가 돼야 한다”고 말했다.

보통 일부 레이어에 부족한 부분이 있더라도 일반적 장애 상황에선 대처가 가능하다. 그러나 이번과 같은 데이터센터 규모 장애 상황에선 모든 레이어의 설계가 잘 맞물려 돌아가야 하나, 그러지 못했다. 허술했던 부분이 드러난 것이다.

유 실장은 “이번 장애에서 운영 및 관리도구 레이어에서 데이터센터 다중화 구성이 완벽하지 못해 전체적인 서비스 복구 시간이 지연되는 가장 큰 원인이 됐다”고 설명했다.

운영 및 관리도구 레이어는 서비스 운영에 필요한 기술적 도구들이 속한 부분이다. 운영상 배포에 관련된 도구들과 문서, 모니터링 관련한 도구들 그리고 이런 도구를 사용하기 위한 사내 권한 관리를 하는 서비스 등을 포함하고 있다.

전날 기조발표에서 언급한 주요 장애 요인은 카카오의 플랫폼 도구가 클러스터(연계 작동하는 구조) 형태로 작동한다는 것이다. 공용 솔루션 등을 포함한 레이어가 작동하지 않으면서 연쇄 장애를 겪었다.

유 실장은 “이런 서비스 플랫폼은 많은 서비스에서 공통적으로 사용되는 특성이 있는 만큼 장애 전파의 연쇄작용이 처음 혹은 중간 단계로서 영향을 미쳤다”고 말했다.

애플리케이션 레이어는 실제 사용자에게 서비스를 하기 위한 컴포넌트 구성과 소프트웨어를 말한다. 이 역시 여러 시스템 간 복잡한 의존성이 존재하는 특성을 지닌다.

유 실장은 “이로 인해 여러 부분에서 병목이 발생할 수 있고, 일부 시스템 장애가 전체 서비스 장애로 이어지기도 쉽다”며 “이 레이어에선 전략적으로 이중화를 구성하고 의존성을 관리해 설계하고 트래픽을 잘 관리해 실시간 대응도 잘해야 하는 등 신경 써야 할 주제들이 있다”고 짚었다.

또 유 실장은 “개선 과정 중 어어떤 것은 몇 년이 걸리는 장기적인 과제”라며 “이번과 같은 공유를 일회성으로 끝나지 않고 다양한 방법으로 꾸준히 공유해 나갈 예정”이라고 약속했다.

 

인프라의 다중화

“화재가 나고 8분 후 데이터센터 모든 기능이 상실되었습니다”

카카오 데이터센터파트 문승조 파트장과 네트워크엔지니어링파트 서상덕 파트장은 인프라 설비 레이어 다중화를 주제로 세션 발표를 진행했다.

당초 화재 진압에 물을 사용하기 위해 전원을 내려서 데이터센터가 마비됐다고 알려졌지만, 사실은 전원 차단 이전에 마비됐다는 것이다.

문 파트장에 따르면, 화재가 난 직후 네트워크 코어가 영향을 받아 모든 통신이 끊긴 상태였던 것으로 확인됐다. 통신이 끊긴 순간부터 데이터센터의 모든 기능은 상실된다.

문승조 파트장은 이러한 마비는 “우리나라 데이터센터 역사상 단 한 번도 일어나지 않았던 센터 기능 전부 마비 상태”라고 전했다.

문 파트장은 이어 복구 예상 시점보다 실제 복구가 지연된 이유 또한 설명했다. 전원을 빠르게 되살리려고 했으나 베터리에 불꽃이 발생해 미뤄질 수밖에 없었으며, 서비스 중단 10시간 만에 전원을 연결했지만 긴급전원장치(UPS) 없이 전기를 공급받아 전력 공급이 불안정한 상태였다고 설명했다. 이후 구역별 복전이 진행되었고 사고 발생 4일 후 모든 서버의 불이 켜지게 되었다고 당시 상황을 전했다.

문 파트장은 이런 사태의 재발 방지를 위한 방안을 제시하기도 했다. 그는 빠른 화재 진압을 위해 독립적인 배터리실에 소화가스 외 추가적인 스프링클러 소화 설비를 갖출 필요가 있다고 전했다. 또 배터리 사이의 간격이 충분치 않아 화재 진압이 어려웠던 만큼 배터리 모듈 간 간격을 벌리는 것이 필요하다는 의견을 제시했다.

이 밖에도 CCTV의 픽셀을 감지하는 기능을 이용하여 화재를 빠르게 인지하고 이후 소방서에 자동으로 화재를 신고할 수 있도록 해 지원을 빠르게 받는 것이 필요하다고 덧붙였다.

이번 장애는 배터리 화재로 시작했으나 배터리 뿐 아니라 UPS까지 영향을 받아 대규모 정전 사태로 이어졌다. 그는 앞으로는 다원화된 배터리실과 UPS실을 상면 옆으로 이동해 배터리 하나의 문제가 전체 전원에 영향을 주지 않도록 해야 한다고 설명했다. 이러한 재발방지 대책들은 카카오의 자체 데이터센터 설계에 반영될 것으로 보인다.

서상덕 네트워크파트장은 데이터센터 네트워크 부분의 구성 현황과 장애 당시의 영향 등을 설명했다. 서 파트장에 따르면 카카오의 인프라는 크게 두 개의 백본 센터와 2개 이상의 물리적 확장 센터로 구성되어 있다. 다른 확장 센터들은 두 개의 백본 센터와 분산해 연결을 맺고 있고 회선 등의 장애 시에는 자동적으로 우회되도록 다이나믹 라우팅이 가능하다. 장애 당시에도 다이나믹 라우팅 동작에 의해 경로들이 자동적으로 조정이 되었다고 말했다.

다만 전원 전면 차단 이전에 전원의 불안정으로 인해 이미 상당수의 네트워크 장비가 다운되어 카카오톡 등 주요 서비스에 일부 장애가 발생되고 있었고 트래픽 감소가 있었던 것으로 확인됐다. 서 파트장은 “장애 당시 큰 틀에서 네트워크는 운영자의 조작 없이도 트래픽 우회가 자동 동작하는 등 이중화 구성정책에 따라 잘 동작했다”고 밝혔다.

서 파트장은  카카오가 기존에 진행하고 있던 네트워크 측면의 개선 포인트들을 설명했다. 우선 메인 백본 센터를 2개에서 3개로 증설해 좀 더 폭넓은 대역폭을 구성할 계획을 밝혔다. 이에 확장센터들이 세 개의 경로를 가지게 되어 특정 데이터센터 장애 시에도 좀 더 안정적인 구조를 유지할 것이라는 기대감을 보였다. 또한 새롭게 구성되는 데이터센터들은 최상단 집성 장비까지 최소 4중화 구조로 구성해 이슈 발생 시 운영자가 장비를 즉시 조치하기에 더 용이한 구조로 만들어 나간다고 전했다.

데이터센터간 전송망 확장을 통해 서비스 다중화 배치에 활용하겠다는 방안도 소개했다. 향후 대규모 투자를 통해, 센터간 전송망의 용량 증가, 서비스별 전용망 구성 능력을 확보해서, 카카오 서비스의 데이터센터 다중화 배치 강화에 제약이 없도록 할 계획이라고 밝혔다.

데이터 레이어 다중화

카카오가 완전히 다중화되지 않았던 일부 데이터 환경을 개선하기로 했다. 여러 데이터센터에 분산 구성을 추진해 가용성을 높일 계획이다.

이태윤 카카오 데이터플랫폼 팀장에 따르면, 현재 카카오의 데이터는 ▲마이SQL·포스트그레SQL·오라클로 구성된 ‘관계형데이터베이스관리시스템(RDBMS)’ ▲몽고DB를 주력으로 하는 ‘NoSQL’ ▲에이치베이스(HBase)·드루이드(Druid)·하둡(Hadoop)으로 처리되는 ‘빅데이터 클러스터’ 등 3가지 카테고리로 운영한다.

당시 장애 상황을 복기한 결과 RDBMS의 경우 구성 자체의 문제점이나 복구에 따른 데이터 손실은 없었다는 설명이다. 평상 시에 운영 노드는 서비스 트래픽을 맡고, 재해복구(DR) 노드는 분석 작업을 맡는 구조다. 하지만 장애 시 서버이중화(HA) 노드를 작동하는 단계 때 내부 백업 스토리지에 장애가 발생했다. 또한 DR 백업 스토리지에 접근하기 어려운 시간도 있었다는 게 이태윤 팀장의 설명이다.

그는 “RDBMS는 3곳의 IDC를 활용하는 것을 목표로 하고 최소 2곳의 IDC를 활용한 DR을 구성하겠다”며 “IDC 별로 가상장비 인스턴스 용량을 충분히 확보, 멀티 리전을 이용한 다중화를 진행하겠다”고 밝혔다.

또한 내부 백업 스토리지를 각 IDC에 구성해 백업 복구에 필요한 상시 가용성을 확보하고, 한 개의 오라클 클러스터에서 발견된 DR 노드의 처리 성능을 높이는 작업도 병행한다.

몽고DB는 데이터를 삼중화해 작동시키지만 일부 문제점이 있었다. 이 팀장은 “가상장비 인스턴스 부족으로 3곳의 IDC로 분산되지 못하고 2곳의 IDC에 구성된 사례가 있었다”며 “한 IDC에서 두 개의 노드가 동시 장애 시 나머지 한 개의 노드가 읽기 전용 모드로 동작하게 돼 일부 서비스가 읽기 전용 모드로 전환해 운영됐다”고 되짚었다.

빅데이터 클러스터의 내부 데이터는 삼중화로 분산 구성해 피해는 없었다. 단, 다중화하지 않은 소수 클러스터가 발견됐고, IDC간 노드 분산이 이뤄지지 않은 한 개의 클러스터가 발견돼 추가 다중화가 필요한 상황이다.

이 팀장은 “일부 삼중화되지 않은 몽고DB도 가상장비 인스턴스 용량을 충분히 확보해 3개의 IDC를 활용, 재구성할 계획”이라며 “빅데이터(카테고리)는 클러스터를 다중화하고 충분히 IDC 간 노드를 분산해 장애 시에도 상시 가용이 가능한 상태를 유지하겠다”고 밝혔다.

서비스 플랫폼 레이어

네번째 세션에서는 공용준 클라우드플랫폼팀장, 강차훈 시스템엔지니어링파트장이 나와 카카오 서비스 플랫폼 레이어에 대한 다중화를 설명했다. ▴운영관리도구 ▴클라우드 ▴레디스(Redis)나 엘라스틱서치(ES), 카프카(Kafka)와 같은 오픈소스 기반 플랫폼 등이 설명의 범주에 들어갔다.

먼저 공용준 팀장은 데이터센터별로 권한관리를 위한 사내 계정인증 ‘엘댑(LDAP, Lightweight Directory Access Protocol)’ 서버와  담당자 정보가 존재, 장애 영향 범위를 빠르게 빠악해 전파할 수 있었던 것이 화재 당시 잘 처리된 부분이라고 파악했다. 사내 계정 인증 서비스 구조가 단순한 면도 있지만, 서비스 간 연계 영향을 받지 않는 로직과 구조로 운영하고 있었던 것도 대응에 유리했다고 말했다.

당시 장애 대응 작업이 10분 내외로 이루어졌으나 VPN 접근을 1시간 가량 하지 못해 복구가 지체되었던 것은 부족했던 대처라고 설명했다. 공 팀장은 “이 과정에서 전사 장애 대응 훈련 시나리오가 필요하다고 깨닫게 됐다”고 강조했다. 아울러 LDAP을 직접 사용하는 사내 서비스(도구)는 데이터센터 장애 시 직접적인 영향을 받는 구조이기에 데이터센터 간 삼중화 GSLB(Global Server Load Balancing)로 장애 상황에 따른 수동 전환 작업 단계 제거를 위한 구성이 필요하다고 말했다.

소스관리 깃허브와 관련해서는 데이터센터 이중화(ActiveÓStandby)로 구성했지만 판교 데이터센터 장애 발생 후 스탠바이 깃허브를 ‘액티브(Active) 상태로 승격하는 과정에 예상보다 오랜 시간 소요되는 등의 문제가 있었다고 설명했다.

데이터 백업 파일의 경우 삼중화 보관 이후 증분 백업은 하루에 2번, 풀백업은 5일에 한 번하면서 안정화를 꾀했으나 장애 극복(failover)을 위한 테스트를 다양한 예외 상황에서 하지 못한 경험 부족을 뼈아픈 실책의 원인으로 봤다. 공 팀장은 “재현테스트 등을 통해 다양한 예외 사항을 확인 하고 있으며 장애 극복 과정에서 예외상황이 발생해도 신속 대응을 하기 위해 데이터센터 삼중화와 비상상황을 위한 자립 방식(standalone)을 구상 중에 있다”고 밝혔다.

레디스, 엘라스틱서치(ES), 카프카 등 오픈소스 플랫폼과 관련한 설명도 있었다. 예컨대 엘라스틱서치의 경우 전체 서비스 단위 클러스트 중 30% 정도에서 장애가 발생했는데, 그 영향이 핵심 컴포넌트를 사용하는 경우에는 전면적으로, 로그 저장소나 내부 관리 도구로 사용하는 경우에는 일부에 있었다.

강차훈 파트장은 “서비스 핵심 컴포넌트로 사용되는 경우 하나의 데이터센터 장애에도 버틸 수 있는 구조가 필요하다”면서 “사용목적, 중요도, 장애 시 영향도에 대해 파악이 충분하지 못해 복구 시 우선순위를 정하는데 어려움이 있었던 것”이라고 설명했다.

특히 레디스 클러스터, ES의 마스터 노드, 카프카의 주키퍼처럼 쿼럼(Quorum)구조의 클러스트를 구성할 때 독립 IDC 혹은 클라우드의 리젼 같은 최소 3개의 가용구역(Availability Zone)에 분산해야 한다는 점을 강조했다. 그렇지 않을 경우 하나의 가용 구역 전면 장애 시 제대로 된 동작을 보장할 수 없기 때문이다.

이와 관련해서 플랫폼 자체뿐만 아니라 플랫폼 관리 도구와 모니터링 도구도 이중화가 필요하다고 설명했다. 강 파트장은 “플랫폼 서비스의 사용 주체와 운영주체가 다를 경우, 플랫폼을 사용하는 서비스와 사용 용도를 파악해야 한다”면서 “금융시장의 블랙스완과 같은 IDC 전면 장애는 국가로 치면 전시와 같으므로 사전에 장애 시나리오에 따른 준비와 대비훈련이 필요하다”고 강조했다.

애플리케이션 레이어 다중화

두 데이터센터가 다중화되려면 해당 서비스에 필요한 모든 구성요소가 갖춰져야 한다. 그러나 카카오의 경우 몇몇 서비스 중 일부 구성 요소가 한쪽의 데이터센터에서 준비되지 않은 것으로 조사됐다.

카카오톡의 주요 서비스 중 상태정보를 캐시하던 레디스(Redis)가 판교 데이터센터에만 구성이 되어 결국 데이터센터 다중화가 작동하지 않은 것이다. 카카오에 따르면, 해당 레디스는 담당 조직이 달랐고 다른 전략에 따른 다중화 일정에 맞춰 진행됐다. 또 새로운 설계가 적용된 로그인 시스템의 경우 일정기간을 거친 뒤 데이터센터 간 다중화 구성이 이뤄지기 때문에 직격탄을 받았다.

유용하 카카오 회원플랫폼 사업실장은 이상적인 다중화 동작을 위한 조건으로, 서비스 시작 시점에 모든 구성요소가 데이터센터 간 다중화되어야 한다고 주장했다. 다만, 이때 상면 확보가 어렵거나 수많은 유휴 장비 운영에 따른 비효율성 등 한정된 자원의 문제가 있다. 따라서 영향도에 따른 서비스 별 우선순위를 관리하고 각각의 다중화 구성 수준을 조정해야 한다. 다수 조직에 일관된 다중화 전략을 적용할 수 있는 거버넌스가 필요하다는 것이 유 실장의 제언이다.

두 번째는 서비스간 장애 격리 설계다. 카카오의 서비스는 복잡한 연동관계를 맺고 있다. 카카오 내부에서 사용하는 클라우드, 스토리지, 캐시 등 공용 서비스 플랫폼은 많은 서비스에서 사용하고 있다. 각 서비스도 다른 서비스의 기능이나 데이터를 사용하기 위해 애플리케이션프로그래밍인터페이스(API)를 통한 의존적인 관계를 맺고 있다. 이런 복잡한 구조는 효율적으로 서비스를 구성할 수 있으나, 하나의 서비스에 장애가 발생할 경우 다른 서비스에도 연쇄적으로 영향을 미친다는 단점이 있다.

실례로 도커 이미지는 많은 서비스의 클라우드 환경을 재구성하는데 영향을 줬다. 이미지, 동영상 등을 저장하는 미디어 저장소의 장애는 카카오톡 미디어 전송 서비스의 복구를 지연시켰다. 카카오 로그인도 하나의 플랫폼 서비스로서의 역할을 하고 있어 카카오T, 카카오페이지 등의 외부 서비스 복구가 늦어지게 했다.

카카오가 찾은 해결방식은 시스템의 결합도를 낮추는 것이다. 기능을 최대한 독립적인 구조로 설계하고, 각각의 기능을 실시간으로 활성화·비활성화할 수 있도록 구현한다. 카카오는 의존성이 있는 시스템을 재분류하고 개선할 계획이다. 채팅같은 필수기능은 다른 서비스의 의존성을 최소화하는 구조로 고민하고 있다.

세 번째는 데이터센터 간 트래픽 전환 문제다. 데이터센터 전환 직후 초기 트래픽은 로그인, 정보 동기화 등으로 많은 시스템 자원을 필요로 한다. 이때 캐시는 비어있으며 데이터베이스(DB) 등 구간 병목 발생으로 전체 서비스에 영향을 준다.

이에 윤 실장은 과도한 트래픽을 처리할 수 있는 인프라와 클라우드를 준비해야 할 필요가 있다고 말했다. 애플리케이션 내 장비와 클라우드 리소스를 합리적인 수준에서 과도한 트래픽까지 처리할 수 있을 정도로 구성한다. 클라우드 전환 직후에는 몰린 트래픽을 시간적으로 분산해 시스템의 피크 로드를 낮추는 것이 중요하다.

마지막으로 실시간 복구 체계를 갖추는 것이다. 데이터센터 다중화 구성이 만능은 아니라는 이야기다. 실시간 시스템 재구성, 변경으로 빠른 시간에 대응해야 한다. 이때 배포 도구와 같은 운영관리 도구가 중요한 역할을 한다. 실시간 복구 작업을 체계화하기 위해 장비, 클라우드 등 리소스의 안정적인 실시간 투입체계도 마련해야 한다. 복구 우선순위 관리, 서비스 상태 대시보드, 관리 및 운영 도구의 가용성 확보 등이 그것이다.

윤 실장은 “카카오는 서비스 중요도에 따른 다중화 수준을 나누고 대응 전략을 마련할 예정”이라며 “중요한 서비스의 핵심 기능은 다수 데이터센터에서 단독으로 서비스할 수 있는 수준으로 다중화하고, 빠르게 전환할 수 있도록 시스템을 정비할 것”이라고 밝혔다.

글. 바이라인네트워크 편집부 byline@byline.network