카카오 "개발환경·자동화도구도 데이터센터 다중화할 것"

전체 시스템 계층 다중화 체제로 전환

카카오가 지난 10월 발생한 장애 재발을 막기 위해 전체 시스템 레이어에 걸친 다중화된 시스템 체제로 전환하겠다고 7일 밝혔다. 사용자 데이터뿐 아니라 개발과 운영에 필요한 각종 백엔드 시스템의 다중화를 추진하겠다고 강조했다.

이채영 카카오 비상대책위원회 재발방지대책소위원회 부위원장은 개발자연례행사 ‘이프카카오’에서 “데이터센터 등 전체 시스템을 다중화해 재발 방지는 물론 비슷한 장애 발생 시 기존보다 더 빠른 모니터링과 복구가 가능하도록 박차를 가하겠다”고 강조했다.

이채영 카카오 비상대책위원회 재발방지대책소위원회 부위원장 (사진=행사 캡처)

이채영 부위원장은 카카오 서비스 복구가 늦어진 주요 원인을 진단하고 그에 대한 기술적 대응방안을 설명했다.

지난 장애의 1차적 원인은 판교 데이터센터로 집중된 애플리케이션 인프라였다. 카카오톡을 비롯한 각종 서비스를 데이터센터 세 곳 이상에 분산해 운영했지만, 주요 애플리케이션과 개발 및 운영 관련 시스템이 판교 데이터센터에 집중돼 이중화되지 못했다. 

그는 “판교 데이터센터 전원공급 화재로 네트워크 시스템과 무관하게 서버까지 다운됐고,  이로 인해 모니터링이나 분석 툴까지 마비돼 장애 탐지가 원활히 이뤄지지 못했다"고 설명했다. 

그는 서버 이동이나 재설치에 필요한 정보가 대부분 화재가 난 판교 데이터센터에 있던 것도 문제 삼았다. 애플리케이션의 데이터는 다중 지역으로 이중화돼 사라지지 않았지만, 카카오 서비스 구현을 위한 전체 서버의 구성 정보가 판교 데이터센터에만 있어 기본 설계도를 구할 수 없었던 것이다.

데이터센터 장애 방지 대책 키워드 (사진=행사 캡처)

이 부위원장은 “앞으로 데이터센터 전체에 장애가 발생하더라도 모니터링과 장애 탐지가 원활하도록 시스템을 이중화에서 다중화 시스템으로 바꾸겠다”고 해결책을 제시했다.

또 메인 백본 센터를 두곳에서 세곳으로 확대할 계획도 밝혔다. 그는 “데이터센터 간 늘어날 트래픽에 대응하도록 확장성 설비 투자를 진행하겠다”며 "향후 대용량 트래픽 전송이 필요한 서비스에는 데이터센터 간 삼중화를 위해 별도 전용망도 구성하겠다"고 말했다.

데이터베이스 환경에 대한 다중화도 개선하기로 했다. 카카오는 ▲마이SQL, 포스트그레SQL, 오라클 데이터베이스 등 관계형DB(RDBMS) ▲몽고DB 등 NoSQL ▲드루이드, HBASE, 하둡 클러스터 등 빅데이터 등의 데이터 구조를 운영중이다. 이중 RDBMS와 NoSQL은 데이터센터를 분산해 이중화해 데이터 복구에 문제가 없었다. 분석 영역인 드루이드, HBASE, 하둡 클러스터 등도 향후 이중화와 데이터센터 분산을 추진한다는 계획이다. 

지난 장애의 직접적 원인은 아니지만, 카카오가 복구에 너무 많은 시간을 소요하게 된 건 개발 및 운영을 위한 각종 도구에 접근하지 못했기 때문이다. 전체 구성 설계를 알지 못하면 수많은 리눅스 컨테이너로 쪼개져 있는 카카오의 각종 소프트웨어 서비스요소가 어떻게 연결되고 상호 연동되는지 맵을 재구성할 수 없게 된다. 이를 자동화하는 도구와 시스템을 갖추고 있었지만 그마저도 판교 데이터센터에 있어 활용할 수 없었다.

이 부위원장은 "사내 계정과 인증, 소스 관리나 앱 배포 도구, 위키나 지라 등 협업 도구 등 운영 관리 도구가 일부 이중화돼있지 않아서 장애 초기에 개발자들이 서비스를 복구할 시간이 지연됐다"며 "특히 앱 배포 도구의 경우 앱 빌드와 배포에 꼭 필요한 시스템임에도 해당 시스템의 가용성에 대한 인식이 부족했다"고 설명했다.

그에 의하면, 카카오는 자체 클라우드와 엘라스틱서치, 레디스, 카프카 등 관리 운영을 위한 플랫폼 도구를 클러스터 형태로 운영하고 있다. 각 서비스 담당 개발자가 이 도구를 각각의 클러스터를 통해 자신의 서비스에 사용한다. 이런 클러스터도 데이터센터 간 이중화가 돼 있지 않았다. 데이터센터 전면 장애를 대비한 구조도 없었다.

그는 "일시에 많은 수의 서비스 장애가 발생해 많은 수의 서비스를 복구해야 했을 때, 수많은 서비스 중 어떤 서비스를 먼저 기동할 것인지에 대한 우선순위 판단도 쉽지 않았다"며 "해당 클러스터 중 약 3분의 1이 통신 장애가 발생했으며 카카오의 다양한 서비스가 엘라스틱서치와 레디스를 사용하고 있기 때문에 정도의 차이는 있으나 많은 서비스들이 장애를 겪었다"고 설명했다.

그는 "앞으로 모든 클러스터를 데이터센터 단위에서 삼중화해 데이터센터 전면적 장애에도 서비스 수준을 유지할 수 있는 구조로 운영할 계획"이라며 "각 도구의 사용 목적, 서비스 영향도와 클러스터별 중요도를 정기적으로 파악하는 프로세스를 도입하고 특정 시스템의 장애 시 영향을 받는 대상에 대한 공지를 자동화하겠다"고 밝혔다.

카카오 클라우드에서 컨테이너 오케스트레이터 컨테이너 이미지 저장소 등의 일부 서비스는 이중화 구성이 돼있었다. 그러나 주요 메타데이터 저장소, 보안 키 저장소, 오브젝트 스토리지 클러스터 모니터링 도구 등이 단일 구성으로 돼 있었, 데이터센터 간 복제가 돼 있지 않았다. 소프트웨어 구동에 필요한 데이터의 위치를 찾는 메타데이터 검색을 할 수 없게 돼 정상적 서비스가 불가능했다. 

그는 "현재 오브젝트 스토리지 등 스토리지 시스템에 대해 데이터센터 간 삼중화를 계획하고 있다"며 "레이턴시 등 삼중화에 따라 발생할 수 있는 부수적인 문제들은 해결해 나가려 한다"고 밝혔다.

다음 첫화면은 DB와 캐시서버는 고가용성 구성으로 돼 있었지만, 컨테이너 오케스트레이터 위에서 각 노드별로 헬스체크를 자동화해 동작하게 한다. 그러나 캐시서버의 HA가 자동 전환하지 않았고, 노드 헬스체크에 실패하며 자동으로 모든 컨테이너 동작이 꺼졌다. 오케스트레이터가 헬스체크를 할 수 없는 경우 해당 컨테이너를 자동으로 꺼버리게 설정돼 있었기 때문이다. 여러 서비스가 다른 서비스와 의존성을 갖고 동작하게 돼 있는 구조여서 한 서비스가 동작하지 않으면 의존성을 가진 다른 서비스도 연쇄 중단됐다.

이 부위원장은 "서비스 간 의존성을 최소화하기 위해 단독실행하는 구조로 변경하고 있으며, 발견되 페일오버 구성 문제점을 개선하고 있다"며 "장애 대응 시나리오를 재검토를 시작했고, 사용자 데이터뿐 아니라 서버 구성정보나 배포설정도 철저하게 이중화하는 작업을 진행하고 있다"고 밝혔다.

그는 "전체 시스템 레이어에어 다중화를 설계하고 구축해 가겠으며, 데이터 범위도 사용자 데이터에 국한해 생각하지 않겠다"며 "서버 각각의 구성정보도 이중화해 빠른 복구 가능한 구조를 만들겠다"고 강조했다.