[기술세미나] if(kakao)dev2022 Day1 Keynote 1015 카카오 장애 원인 분석, 기술 개선, 해결 방안

2022 카카오 개발자 컨퍼런스 (https://if.kakao.com/2022/session/1) 영상 정리 노트

 

사건의 발단과 카카오의 미션

발표자: 카카오 비상대책 위원회 재발방지대책 소위원회 위원장 남궁훈, nkay님

22년 10월 15일 카카오 서비스에 긴 장애가 발생하고 한 달 반이라는 시간이 지난 현재,
이 위기 상황에서 책임을 지며, 책임을 다하는 방식을 카카오의 크루들과 외부 전문가들과 고민하고 있는 상황.
업계 공동의 '재발방지'를 위해 if kakao 를 통해 공유하고자 함.

카카오는 멈추지 않고 서비스의 안정성을 위해 지속적인 고민을 할 예정임
새로운 기술을 통해 미래를 개척하고 그 과정에서 다양한 이해관계자들과 함께 성장하는 방식으로 ESG 과제를 수행해 왔지만, 본질을 놓치고 있었음.
본질로는, 서비스를 안정적으로 제공하는 것 그 자체가 ESG 과제가 되어야 했음
바로 이중화가 완성되지 않은 다리와 같았음

3가지 관점에서 실천과제를 수립했음
(완벽하지 못했던 이중화를 비릇해 부족한 인프라를 개선하기 위해 세운 3가지 관점)

1. 과거의 원인 분석
2. 현재 재발 방지 대책 세우기
3. 미래에 대한 투자


인프라 조직의 재구성

인프라 부분을 소홀히 하지 않고 서비스 안정성을 보장하고자 함
기존 개발 조직에서 분리되어 별도의 상위 조직으로 구성된 인프라 분야 재구성할 것

if kakao... 만약 카카오가 이랬더라면...

카카오 서비스의 안정화과 최우선 과제이며 사회적 책임임을 다시 다짐
한달 여간의 고민을 공유하고자 하기 위함
사회적 미션에 책임을 다하고 성장할 수 있는 계기가 되기를!

---

1015 장애 원인 분석

발표자: 그렙 공동대표를 맡고 있는 이확영 님

장애 원인

카카오 서비스 장애의 원인을 객관적으로 규명하고 공유하고자 외부 인사소러 카카오 비상대책위원회 원인 조사 소위를 맡게 되었음
이유는, 과거에 카카오톡 개발을 비롯한 여러 서비스를 경험해봤고, 카카오 서비스와 인프라에 대한 경험으로, 제3자의 관점에서 카카오 장애 원인을 면밀히 분석하고자 함
시스템이 이중화되어 있음에도 장애가 발생한 원인 분석 결과를 공유하고자 함

1. 22년 10월 15일 3시 19분경 카카오가 이용중인 SK C&C 판교 데이터센터에 화재 발생
2. 카카오 서비스 전반의 장애로 이어졌음. 10월 20일 모든 서비스 복구 완료

서비스 담당하는 서버가 이중화 되어 있음에도 불구하고 오랜 시간이 지나서야 모든 서비스가 복구된 원인은 이중화와 위기 대응 과정에 미흡합에 있었음.

원인 분석: 이중화

1. 데이터센터가 간 이중화가 미흡했음
- 카카오 서비스의 일부 시스템이 판교 데이터센터 내에서만 이중화되어 있어서 장애복구가 늦어짐
- 예를 들어, 캐시 서버와 오브젝트 스토리지의 경우 판교 데이센터에만 설치되어 있어 이를 사용하는 서비스들의 복구가 늦어짐
- 카카오 로그인, 카카오톡의 사진 전송 기능이 여기에 속함
- 다른 데이터센터로 자동 전환해주는 시스템마저 판교 데이터센터에만 설치되어 있었음
- 수동으로 전환 작업이 진행되어 복구가 지연

2.. 사용자 서비스에 직접적으로 필요한 서비스 외에, 서비스 개발과 관리를 위한 운영 도구들의 이중화가 미흡했음
- 상대적으로 이러한 도구들의 안정성 확보에 소홀했음
- 예를 들어 모니터링 도구 등 화재 여파로 사용할 수 없게 됨

3. 이중화 전환 후 가용 자원이 부족했음
- 판교 데이터센터 전체를 대신할 만큼의 가용 자원이 확보되어 있지 않았기 때문에 판교 DC에 전원이 들어와서 모든 시스템이 정상회기 전까지 복구를 완료할 수 없었음


결국, 개별 시스템의 미흡한 이중화가 전체적인 장애를 유발한 것

원인 분석: 위기 대응

1. 장애 복구를 위한 인력과 자원이 부족했음
- 운영 관리 도구의 복구 인력 부족은 치명적이었음
- DC 전체의 장애 상황에 대한 준비가 부족했음

2. 장애 대응을 위한 커뮤니케이션 채널에 혼선이 있었음
- 카카오톡, 카카오 워크 채널을 쓸 수 없을 때 중요한 사항 전파 및 의사결정을 위한 커뮤니케이션 채널이 준비되어 있고 일상적으로 사용되고 있었어야 함

재해 초기 컨트롤 타워 부재에 대한 지적.
카카오와 공동체, 개별 조직이 동시 다발적으로 장애에 대응함
전체적인 조율과 협업을 지원하는 전사 조직이 세팅되어 있지 않았던 것이 큰 문제였음


이러한 원인 분석 결과 보고서를 제출했고, 앞으로 다시 같은 문제가 재발하지 않도록 대책을 세우고 행동에 옮기는 것은 카카오의 역활과 책임일 것.

---

재발 방지를 위한 기술 개선

발표자 : 비상대책위원회 재발방지 대책 소위원회 부위원장 이채영, ean님

이중화 개념에 대한 적극적 해석


인프라 하드웨어 설비부터 서비스 애플리케이션에 이르는 전체 시스템 레이어에서 철저한 이중화 실행을 할 예정

판교 데이터센터를 비롯해 3곳 이상의 데이터 센터에 다양한 형태로 분산배치해 운영해 왔음.
판교 DC에서만 32,000대의 서버를 사용하고 있는 상황
이중화에도 불구하고, 모니터링 및 분석 툴이 마비되어 장비 모니터링과 장애 탐지가 원활히 이루어지지 못했음
서버 이동 및 재설치에 필요한 환경 구성 정보가 대부분 판교 DC 시스테ㅁ에 있어 해당 정보를 조회하는 것도 원할하지 않았음

모니터링 시스템 관
모니터링 시스템을 다중화할 것이며, 메인 백본 센터를 2곳에서 3곳으로 확대하여 확장성을 고려한 설비 투자를 진행할 계획, 대용량 트래픽 전송이 필요한 서비스의 DC 간 삼중화를 위해 별도 전용망도 구성할 예정

데이터 관점
MySQL, PostgreSQL, Oracle 등 RDBMS 군, MongoDB를 포함한 NoSQL 군, 분산 빅데이터 스토어인 Hbase, Druid, Hadoop 클러스터로 크게 3가지 형태로 데이터를 관리하고 있음
RDBS, NoSQL은 데어터센터 3곳에 걸쳐 다중화되어 있어 데이터 손실 없이 복구할 수 있었지만, 빅데이터 처리를 위한 시스템의 경우 클러스터 다중화 작업, 데이터센터 간 노드 분산을 확대 조치할 계획이다.

모든 형태의 데이터를 1:1 복제를 넘어 다중 복제 구조로 구성하고, 장애 발생 시 복구 조치를 즉각 실시할 수 있는 환경을 구축할 예정

운영 관리 도구 관점
사내 엔지니어들이 서비스를 운영하고 관리할 수 있는 도구로는 사내 계정 인증, 소스 관래와 앱 배포 도구, 위키 지라 등의 협업 도구가 있는데, 일부가 이중화되어 있지 않아 장애를 대응할 수 있는 시간이 지연되었음
앱 배포 도구의 경우 앱 빌드, 배포에 꼭 필요한 시스템 임에도 가용성에 대한 인식이 부족했던 것이 문제였음
DC 간 이중화 완료, 삼중화 예정

플랫폼
자체 클라우드와 엘라스틱서치 플랫폼, 레디스와 카프카 등 플랫폼 도구를 클러스터 형태로 운영하고 있음
각 서비스 담당 개발자들은 각각 클러스터르를 통해 자신의 서비스로 사용하게 되는데, 이러한 클러스터 부분도 삼중화하여 데이터센터의 전면적인 장애를 대응할 수 있도록 할 것
각 도구의 목적, 영향도 및 중요도를 파악한 프로세스를 도입할 예정

스토리지 시스템
카카오 클라우드에서 컨테이너 오케스트레이터, 컨테이너 이미지 저장소 등 일부 서비스는 이중화 구성이 되어 있었지만, 주요 메타 정보 저장소, 보안 키 저장소, 오브젝트 스토리지 등이 이중화되어 있지 않아 데이터 유실은 없었지만, 데이터 위치를 찾을 수 없는 문제가 발생했던 것.

해결 방안

다음 첫 화면의 경우 DB, 캐시 시스템 기반 시스템이 HA로 되어 있었음
캐시 서버는 HA 구성이 되어 있었음에도 불구하고 자동 전환 로직이 정상 동작하지 않아 각 노드 별 헬스 체크가 실패하면서 모든 앱이 비활성화되며 서비스 오류가 발생했음
장애 상황 초기 운영 관리 도구가 동작하지 않아, 원인 파악하는데 많은 시간이 소요되었음
카카오톡 서버, 카카오 로그인 등의 서비스에서는 서비스 간 의존성 문제, 서버의 불완전한 페일오버 구성 등의 문제가 있었음.
의존성이 있는 다른 서버가 응답이 없는 경우 기동시킬 수 없는 서버가 있었음

한쪽 데이터센터로 트래픽이 몰리며 부하가 발생했음
클라우드 오케스트레이션이 자동으로 동작이 멈추며, 전체 서버가 다운되어 문제가 발생했음

서비스 관점에서 해결 방안
서비스 간 의존성 최소화
페일오버 구성 문제점 개선
장애 대응 시나리오 재검토
서버 구성정보와 배포설정 이중화

실행 계획
- 전체 시스템 레이어에서의 다중화
- 데이터의 범위도 사용자의 데이터에만 국한하지 않을 것
- 서비스 간 우선순위와 중요도, 복구의 우선순위 수립할 예정
- 장애 대비 훈련 확대 실시
- 자체 구축 데이터센터 디자인 개선 (2024년 상반기 완공될 예정인 안산 DC, 또 다른 곳에 DC 착공하는 것을 목표로 삼을 것)

---

 

미래 투자와 혁신 계획

발표자: 재발방지 소위원회 공동 위원장 고우찬, gilbert 님


안산 데이터 센터 2024년 완공 예정. DC 대응책은?
24시간 무중단 운영을 위한 인프라 구축으로 진화 예방과 장애에 적극 대처 예정
자연 재해, 극단적 재난 재해에 대한 대비책도 수립함

IT 엔지니어링 관점에서의 혁신

1. 거버넌스
- IT 엔지니어링 조직은 개발 조직 산하에 있음
- 앞으로 CEO 직할의 부문 규모로 IT 엔지니어링 전담 조직을 확대 편성할 예정
- 데이터센터, SRE, Devops, 클라우드 개발 엔지니어 채용과 육성을 진행할 예정\
- 대규모 장애에 대비한 재해복구 위원회 신설 예정
- 서비스 연속성 확보를 최우선 임무로 하는 조직 준비할 것

2. BCP 정책과 DR 아키텍처 강화
- Business Continuity Plan, 사업이 중단되는 상황을 최소화하기 위해 외부 전문가들을 자뭍하여 구체적인 비상 대응계획 정책 수립 예정
- DR (disaster Recoevry Architecture) 삼중화 플러스 알파로 구성할 예정 , 멀티 클라우드를 활용하여 서비스 연속성을 더욱 강화할 예정
- 외부의 클라우드를 안정장치로 추가할 예정
- 모든 것이 무력화되더라도 단기간 내에 살려야할 서비스 (카카오톡의 메시지 전송 등 원격지 DR 데이터센터를 별도로 구축하는 방안)

3. 투자 재원
- 지난 5년간 투자 금액의 3배 이상 규모로 투자 확대할 예정