책임과 대응

우리가 부족했던 이유

공유하기

누구에게나 자신의 부족한 부분을 꺼내서 진실하게 공유하는 것은 뼈아픈 일이지만, 언제나 문제를 또렷하게 직면하는 것에서부터 새로운 변화를 위한 다짐이 시작된다고 생각합니다.

 

22년 10월 15일 전 국민의 일상이 멈춘 전례 없던 사건이 발생했었죠. 믿음이 컸던 만큼 아쉬움이 컸던 당시 5일간의 카카오 서비스 장애 사건을 되짚어 보고, 그 이후 철저하게 분석했던 장애 원인에 대해서 알기 쉽게 풀어내고자 합니다. 

 

# 10월 15일 카카오에 무슨 일이 
15일 15시 19분 화재가 발생한 뒤로 서비스가 완전히 복구된 20일까지의 일정을 시계열 순으로 시각화 했습니다. 
화재 발생 후 15일 23시 45분에 화재가 진화되었고, 그 뒤 2시간 이후에 카톡메시지 송수신이 재개되었습니다. 이후 카카오 T, 카카오 페이, 다음의 순으로 서비스가 완전 복구되었습니다.

22년 10월 15일 토요일 오후 15시 19분

 

SK C&C 판교 데이터센터에 리튬이온배터리 화재가 발생했습니다. 카카오가 이용 중인 데이터센터였기에 카카오톡을 비롯한 대부분의 서비스에 장애가 발생하게 되었죠. 약 8시간 후에야 화재 진화가 완료되었고, 그로부터 약 2시간 후엔 카카오톡 메시지 송수신 기능이 복구되었습니다. 크루들이 최선을 다해 순차적으로 복구를 해나갔지만, 모든 서비스를 원활하게 이용할 수 있기까지는 약 5일이 소요되었습니다.

이런 사고를 대비해 카카오는 각 서비스의 데이터를 세 곳 이상의 데이터센터에 분산 배치해 운영하고 있습니다. 이번에 화재가 발생한 SK C&C 판교 데이터센터는 전체 서버의 일부만을 담당하고 있었고요. 데이터베이스 역시 두 곳 이상의 데이터센터에 분산 배치되어 있어 데이터 유실 없이 자동 또는 수동 전환되었습니다. 서비스를 담당하는 서버도 마찬가지였습니다. 

 

그런데 왜 우리의 일상이 긴 시간 동안 멈췄던 걸까요? 

# 왜 이런일이 생겼을까? 🔍 

 

1) 객관적인 원인 규명 

사건에 직면하고 대응하기 위해 카카오에서는 빠르게 비상대책위원회를 구성했습니다. 그리고 객관적인 원인 규명을 위해서 사건당일 4일 뒤인 19일부터 약 1개월 간 카카오 내 테크 직군 크루들 뿐만 아니라 외부 기술 전문가를 선임해 (grepp 이확영 대표) ‘원인조사 소위’를 구성했고, 다양한 측면의 분석이 진행되었죠. 모니터링, 장애, 복구 등 주제를 세분화 하여 내부 장애 관련 테크 직군 대상자들과 인터뷰를 진행했고 장애 복구가 지연된 원인을 검증하기 시작했습니다. 그리고 12월 6일, If kakao 22 컨퍼런스에서 장애 원인 조사 분석 내용을 투명하게 공개했습니다. 

if kakao 22 에서 장애 원인 조사 분석내용을 발표한 화면 캡쳐이미지 입니다.

2) 원인분석 결과 공개 

 

📌 데이터 이중화만큼 중요했던 ‘시스템 전체의 이중화’

가장 먼저, 서비스가 중단되지 않도록 하기 위한 이중화 조치에서 장애가 길어진 몇 가지 원인이 발견되었습니다. 구체적으로 살펴볼게요.

 

1️⃣ 데이터 센터간 이중화 미흡 

한 데이터 센터 전체에 문제가 생겼을 때 다른 데이터 센터를 통해 서비스를 중단없이 이어가기 위한 조치가 부족했습니다. 예를 들어, 주요 인프라인 오브젝트 스토리지*의 메타 정보 시스템*과, 보안키 저장소는 판교 데이터센터에만 이중화 되어 있었기 때문에 시스템들이 정상적으로 재기동될 수 없었어요. 카카오 인증 시스템에서 사용하는 캐시 시스템*인 레디스의 30% 정도는 판교 데이터센터 내부에서 이중화되어 있었어요. 그리고 장애 대응에 필요한 운영 관리 도구와 협업 도구들 또한 데이터센터 내 이중화만 되어 있거나, 데이터센터 간 이중화가 미흡했죠. 그래서 장애에 대응해야 하는 개발자들이 필요한 도구를 제때 사용할 수 없어 어려움을 겪었습니다.

 

✔️용어 설명  

*오브젝트 스토리지
: 안전하게 데이터를 보관하거나 대용량의 데이터를 무제한으로 저장할 수 있는 대용량 스토리지 서비스
*메타 정보 시스템
: 많은 양의 데이터를 수집, 저장 및 분석할 수 있도록 구조화한 데이터 시스템

*캐시 시스템
: 고속으로 데이터를 처리하는 임시 저장소

 

2️⃣ 이중화된 시스템의 자동화를 위한 모니터링 시스템 구축 및 자원확보의 부족

이중화 전환과 트래픽 제어가 자동으로 매끄럽게 이뤄지지 않고, 수동으로 대응할 수밖에 없는 상황들이 존재했어요. 데이터센터 간 이중화가 미흡한 상태에서, 모니터링 시스템이 충분히 갖춰져 있지 않아 수동으로 이중화 전환을 해야 했던 케이스들이 발견됐습니다. 여러 시스템에 동시다발적으로 문제가 생기는데, 의존하는 다른 시스템의 문제를 인지하지 못해 자동 전환에 실패하는 경우죠. 

또한 전체 시스템의 이중화 수준은 개별 시스템의 이중화 수준을 따라가기 때문에, 개별 시스템의 미흡한 이중화가 전체적인 장애를 유발할 수 있습니다. 개별 부서나 시스템마다 다른 이중화 수준 및 체계, 상면 확보 비용 등으로 문제가 생기지 않도록, 회사 차원에서 체계적인 이중화를 준비했어야 했습니다. 

sk 판교 데이터센터1, 데이터센터 2, 데이터센터 3 등 모든 데이터센터가 각각의 데이터 이중화는 되어 있었지만, 화재로 인해 이중화 전환을 돕는 일부 시스템이 작동하지 않으면서 다른 데이터센터로의 이중화 전환이 이뤄지지 않았던 모습을 시각화 했습니다.

정리하면, 데이터의 이중화는 되어 있었지만, 시스템 전체 관점에서의 이중화가 부족했기 때문이라고 할 수 있습니다. 한 데이터센터 전체에 문제가 생기더라도, 이중화 시스템이 정상 작동을 했다면 다른 데이터센터로 이중화 전환이 이뤄져 빠르게 복구가 돼야 했지만 SK C&C 판교 데이터센터의 전원 공급 전체가 중단되었을 때, 이중화 전환을 돕는 일부 시스템이 함께 동작하지 않으면서 다른 데이터센터로의 이중화 전환이 이뤄지지 않았던 것이 근본적인 문제였습니다. 결국 일일이 수동 전환 대응을 진행해야만 했고, 이에 따라 장애 복구가 지연될 수밖에 없었죠. 

 

📌 그 외에도

서비스 장애를 복구하기 위해서는 운영관리 도구의 복구부터 필요한데, 해당 시스템의 복구 인력이 부족했습니다. 또 긴급 이중화 대응을 위해 확보해놓은 장비 배치 공간이 데이터센터 전체를 온전히 대신하기에는 부족하여 빠른 대응이 어려웠고, 이런 이유가 전체 위기 대응을 지연시킨 원인이 되었습니다. 

 

✔️ if kakao 22에서 공개된 장애 원인분석 키노트에서 자세한 내용을 확인할 수 있습니다. 

# 끝이 아닌 시작

다시는 이런 일이 되풀이되지 않아야 한다는 마음으로 무겁게 사건을 짚어보았습니다. 결국 우리의 부족했던 이중화와 재난 앞에서 완벽히 준비되지 못했던 모습들을 스스로 인정했고, 그로 인해 불편을 겪은 모두에게 머리 숙여 사과했습니다. 하지만 문제점들을 투명하게 분석하고 공개하는 또 다른 이유는 이 사건이 끝이 아니라 새로운 시작이라는 것을 믿고, 앞으로 카카오의 굳은 다짐을 보여주기 위해서입니다.

 

뼈 아픈 사건 덕분에 우리는 카카오가 전 국민의 일상을 지키고 있다는 무거운 책임감을 제대로 깨닫게 되었죠. ‘모두의 일상과 대화는 불편함 없이 계속 이어져야 하기에’. 드러난 부족한 부분들은 겸허히 수용해 개선하고 달라진 모습으로 모두의 믿음에 다시 보답하기를 다짐해봅니다.

공유하기
목록 보기
추천 콘텐츠