이 글(https://gigglehd.com/gg/soft/13394843 )을 보고. 제가 아는 바랑 달라서 소식 글을 적어봅니다.

 

if kakao 1일차(2022.12.07)에 발표된 첫 키노트 - 2022년 10월 15일 발생한 서비스 장애 원인 분석과 개선 사항- 입니다.

좀 대충 요약해서 부족한 것들이 있을텐데.. 영상을 직접 보시면 더 자세하게 나옵니다.

더 잘 정리된 글은 https://it.chosun.com/site/data/html_dir/2022/12/07/2022120701641.html?fbclid=IwAR0N2jd429CvKryOqrS2FG1IB57Q_0C4BKyLdke5A0bE17wepnyrFGidRtI 여기를 참고해주세요

 

3줄 요약

- 판교데이터센터에 몰빵된 것이 있어 이중화 안 된 서비스들이 있었음

- 서비스/데이터 이중화를 강화하겠다.

- 인프라쪽에 투자 및 인원을 확충하겠다.

 

0) Our Social Mission - 비상대책위원회 재발방지대책 공동 소위원장, 남궁훈 (nkay.play)

- 대표이사 -> 비상대책위원회 재발방지대책 공동 소위원장

한 달 반 정도 문제 확인

- 이중화가 안 되어있다는 것을 확인하여 원인분석/재발방지/미래투자를 할 예정

 

1) 1015 장애원인 분석 - 비상대책위원회 원인조사 소위원장, 이확영 (Grepp CEO)

1.1) 발생

- 서비스 서버가 이중화 되어있었으나, 서비스 장애 발생

- 모든 서비스 복구(10.20.)될 때까지 시간이 오래 걸림

 

1.2) 원인분석

- 이중화와 위기 대응 과정에 미흡함이 있음

 

1.2.1) 원인 분석: 이중화

- 데이터센터간 이중화 미흡

ㄴ 서비스 운영에 사용하던 캐시 서버/오브젝트 스토리지 이중화가 완벽하지 않고, 판교 데이터센터에만 있음

ㄴ 카카오 로그인/ 카카오톡 사진 전송기능

- 데이터센터 문제 발생시 감지 후 데이터센터 변경 기능

ㄴ 판교 데이터센터에만 설치

ㄴ 수동으로 전환작업이 진행되 느림

 

1.2.2) 운영 관리 도구/모니터링 시스템 이중화 미흡

ㄴ 안정성 확보 소홀

ㄴ 컨테이너 저장 서버/일부 모니터링 시스템

 

1.2.3) 이중화 전환 후 가용 자원 부족

ㄴ 판교 데이터센터 전체를 대신할 만큼 가용 자원이 확보되어있지 않음

ㄴ 판교 데이터센터 전원이 들어올때까지 모든 시스템 정상화 불가

 

=> 전체 시스템의 이중화 수준은 가장 약한 시스템의 이중화 수준을 따라감 

ㄴ 개별 시스템 미흡한 이중화 시스템 - 전체 장애

ㄴ 회사 차원에서 체계적인 이중화 준비

 

1.3) 원인 분석: 위기 대응

1.3.1) 장애복구를 위한 인력과 자원 부족

1.3.2) 장애대응 커뮤니케이션 채널 혼선

 

2) 재발방지를 위한 기술적 개선 - 비상대책위원회 재발방지대책소위원회 부위원장, 이채영 (ean.lee)

2.1) 전체 시스템 레이어에서 철저한 이중화

- 모니터링 시스템 자중화

- 메인 백본 센터 확장

- 별도 전용망 구성

 

2.2) 데이터

- RDBMS, NoSQL, 분산빅데이터 스토어

ㄴ 분산 빅데이터 스토어 중 Druid/하둡은 부족

ㄴㄴ 다중복제 구조 구성

ㄴㄴ 장애조치 즉각 실시 환경 구축

 

2.3) 운영관리도구 

- 앱 배포 도구 

ㄴ 가용성 인식 부족

ㄴ 이중화는 완료 / 삼중화 예정

 

2.4) 플랫폼

- 자체 클라우드/엘라스틱서치/레디스 등

- 엘라스틱서치/카프카

ㄴ 문제점

ㄴㄴ 이중화가 되어있지 않음

ㄴㄴ 데이터센터 전면장애 대비 구조가 아님

ㄴ 해결방법

ㄴㄴ 데이터센터 단위 삼중화

ㄴㄴ 각 도구의 목적, 영향도, 중요도 파악 프로세스 도임

- 카카오 클라우드

ㄴ 메타정보 저장소, 보안키 저장소, 오브젝트 스토리지, 클러스터 모니터링 도구 - 이중화 안 됨

ㄴ 이로 인해 데이터 유실은 없으나 데이터 위치 못찾음

ㄴ 스토리지 시스템의 데이터센터 단위 3중화

 

2.5) 서비스

2.5.1) 다음 첫 화면

ㄴ HA 구성 / 컨테이너로 구성

ㄴ 캐시서버

ㄴㄴ HA 구성이였으나 자동 동작 실패 

ㄴㄴ 헬스체크 실패로 전부 종료

ㄴㄴ 모니터링 미동작으로 찾는데 시간 오래 걸림

 

2.5.2) 카카오톡 서버/로그인

- 문제점

ㄴ 서비스 간 의존성 문제 / 일부 페일오버 구성 미비

ㄴㄴ 서버를 바로 기동시켜도 의존성 서버가 죽어있으면 실행할 수 없었음

ㄴㄴ 이중화 및 페일오버 자동화해도 동작 이상 감지 서버 문제가 발생하면 불가

ㄴ 트래픽 쏠림시 대응 부족 / 충분치 않은 장애 시나리오

ㄴㄴ 트래픽이 다른 데이터 센터로 넘어감

ㄴㄴ 일부 서버 헬스체크 실패 - 자동 중지 -> 한 서버에 트래픽이 더 몰림

ㄴㄴ 전체 서비스 내려감

ㄴㄴ 다시 기동하려고 하였으나, 컴테이너 이미지 저장소 장애 발생

- 해결책

ㄴ 서비스 간 의존성 최소화

ㄴ 페일오버 구성 문제점 개선

ㄴ 장애 대응 시나리오 재검토

ㄴ 서버 구성정보, 배포설정 이중화

 

2.6) 실행계획

- 전체 시스템 레이어에서의 다중화

- 서비스 간 우선순위 체계화

- 장애 대빈 훈련 확대 실시

- 자체 구축 데이터센터 디자인 개선

 

3) 미래 투자와 혁신 계획 - 비상대책위원회 재발방지대책 공동 소위원장, 고우찬 (gilbert.c)

3.1) 안산 데이터 센터 시공중

ㄴ 무중단 실행

ㄴ UPS/배터리 실 이중화 및 격벽 사용

ㄴㄴ 3중 진화대책

ㄴ 재해 대비책이 있는 데이터 센터

 

3.2) IT 엔지니어링 혁신

3.2.1) 거버넌스

ㄴ IT 엔지니어링을 CEO 하위로 만들 예정

ㄴㄴ 엔지니어링 인원 공격적으로 충원

ㄴㄴ 재해복구 위원회 신설

ㄴㄴ 서비스 연속성 확보 전담 조직 신설

 

3.2.2) BCP/DR

- BCP

ㄴ 사건이 발생해도 사업이 중단되는 사항을 최소화하는 비상 대응 계획

ㄴ 외부 전문가 파트너와 준비할 예정

ㄴ 외부에서 진행하는 카오스엔지니어링 등을 위해 R&D 진행

ㄴ Opensoruce 진행

 

- DR

ㄴ 삼중화 + alpha

ㄴ 삼중화 1개 죽어도 가능

ㄴ 주요서비스는 멀티 서비스 사용하여 서비스 연속성 준비

ㄴㄴ 외부 서비스 클라우드 사용예정

ㄴㄴ 단기간에 살려야 되는 서비스(카카오톡 문자)은 원격지 DR 데이터센터 구축 방안 검토중

 

3.2.3) 투자 확대

- 5년간 투자 비용의 3배 확대