카톡 중단 이유 / 화재 사건 / 사고발생 이유 / 중단된 이유 / 이중화 /
카카오 서비스 장애 내용
정부의 디지털서비스 장애 조사결과 발표
ref. 1 의 내용을 발췌
카카오 계열사의 주요서비스(카카오톡, 카카오티 등) 최대 127시간 33분간 장애 발생
카카오는 서비스 기능을 5개의 레이어로 구분*하고 판교 데이터센터(Active 역할)와 기타 센터 간 동작(Active)-대기(Standby) 체계**로 이중화했으나, 이번 사고 시 대기(Standby) 시스템이 제대로 동작하지 못하였다.
* 애플리케이션, 서비스 플랫폼, 운영 및 관리도구, 데이터베이스, 기반시설 설비 레이어
** 동작 서버 작동 불능시 대기중인 대기 서버를 가동하여 서비스 제공하는 방식
- 대기 서버를 동작 서버로 만들기 위한 권한관리 기능인 ’운영 및 관리도구*’가 판교 데이터센터 내에서만 이중화되어있을 뿐 타 데이터센터에 이중화되어있지 않아, 판교 데이터센터의 동작 서버 작동 불능 시 서비스 장애 복구가 지연되었다.
* 서비스의 가동과 운영 등을 제어하는 기능과 이러한 기능에 대한 접근 및 관리를 수행하는 도구
또한,‘애플리케이션’, ‘서비스 플랫폼’ 레이어에서도 이미지·동영상 송수신 시스템 등 일부 서비스 구성 요소가 데이터센터 간 이중화되어 있지 않아 복구에 상당 시간이 소요된 원인이 되었다.
카카오톡, 다음 등 카카오 서비스 대부분의 핵심기능이 판교 데이터센터에 집중되어 있어 판교 데이터센터 사고 시 카카오 대부분 서비스가 즉각 영향을 받게 되었다.
특히, 여러 서비스의 구동 초기단계부터 필요한 ’카카오인증’과 같은 핵심기능도 판교 센터에 집중되어, 여러 서비스 전반에 광범위한 영향을 미친 원인이 되었다.
카카오는 장애 탐지·전파·복구 전반에 걸쳐 기본 절차를 정의하고 있으나, 각 단계별 체계화 및 자동화가 미흡하였다.
- ※ (예) 사내 전파 수단 준비 미흡, 이용자 공지채널(트위터, 페이스북)의 낮은 접근성 등
일부 서버, 연결망 등 오류에 대비한 재난 대비 훈련 등 조치는 하였으나, 1개 데이터센터 전체가 일시에 불능이 되는 대형 재난상황에 대해서는 대비가 부족하였다.
한편, 카카오는 10.19. ~ 11.6. 간 10만 5,116건의 피해를 접수하였으며, 이중 유료 서비스에 대한 피해는 14,918건, 금전적 피해를 언급한 무료 서비스는 13,198건이 접수되었다.
‘if kakao’ keynote 에서 밝힌 내용
- https://youtu.be/mG17fY4RhHw?t=8m14s : 캐시서버, 오브젝트 storage(카카오톡 사진전송) 의 2중화가 완벽하지 않았다.
- https://youtu.be/mG17fY4RhHw?t=8m35s : 다른 region 으로 자동전환해주는 시스템의 2중화가 안됐다.
- https://youtu.be/mG17fY4RhHw?t=9m : ‘운영관리도구’(컨테이너 이미지를 저장,관리하는 시스템등), ’모니터링 시스템’의 2중화가 안됐다.
- https://youtu.be/mG17fY4RhHw?t=9m24s : 뒤늦게 살리면서, 가용자원의 확보가 어려웠다.(me: 카카오톡 같은 거대한 시스템에 대한 자원확보는 쉽지 않은 일이긴 할듯.)
- https://youtu.be/mG17fY4RhHw?t=10m10s : 장애 복구 인력과 컴퓨터자원 부족
- https://youtu.be/mG17fY4RhHw?t=10m35s : 장애 대응을 위한 소통채널에 혼선. 사내 커뮤니케이션은 카카오톡, 모니터링 채널은 카카오 워크 사용했는데, 이것을 사용할 수 없는 시점에 사용할 비상 커뮤니케이션 채널이 정해진게 없었다.
- https://youtu.be/mG17fY4RhHw?t=11m : 재해 초기의 컨트롤 타워가 없었다. ‘전체적인 조율’, ‘협업을 지원’ 하기 힘들었다.
- https://youtu.be/mG17fY4RhHw?t=15m31s
- 카카오, 판교 데이터센터에만 3만2천대 서버를 사용
- 이번에 판교 데이터 센터의 전체 서버가 다운됨.
- --> 모니터링, 분석 툴을 사용할 수 없게됨.
- --> 장비 모니터링, ’장애 탐지’가 원활히 이뤄지지 못했다.(정보를 조회하는 것등이 원활하지 못했다.)
- https://youtu.be/mG17fY4RhHw?t=17m4s
- 카카오에서 사용중인 data관련 서비스들
- MySQL, PostgreSQL, Oracle : 2중화 잘되어 있었다.
- MongoDB : 2중화 잘되어 있었다.
- HBase, Druid, Hadoop cluster : Druid 는 클러스터 다중화 작업, Hadoop cluster 데이터센터간 노드분산 확대 필요
- 카카오에서 사용중인 data관련 서비스들
- https://youtu.be/mG17fY4RhHw?t=18m9s
- 2중화가 잘안된 운영관리도구들
- 사내 계정 인증 서버
- 소스 관리 도구
- 앱 배포 도구
- 위키, 지라
- 2중화가 잘안된 운영관리도구들
- https://youtu.be/mG17fY4RhHw?t=18m56s
- 2중화가 잘 안된 플랫폼
- 자체 클라우드
- 엘라스틱서치 플랫폼
- 레디스, 카프카 클러스터 운영
- region 이 동작안할 때에 대한 대비가 없었다.
- 수많은 서비스들이 한꺼번에 다운된 경우 어떤 순서로 restart 를 해야되는지에 대한 가이드가 없었다.
- 엘라스틱서치, 레디스, 카프카 모두 전체중 약 1/3 가량의 클러스터에서 통신장애가 발생
- 2중화가 잘 안된 플랫폼
- https://youtu.be/mG17fY4RhHw?t=20m20s
- 카카오 클라우드
- 이중화 구성이 되어있던 부분
- 컨테이너 오케스트레이터
- 컨테이너 이미지 저장소
- 이중화 구성이 안되어있던 부분
- 주요 메타정보 저장소 : 이것이 동작하지 않아서 한동안 데이터의 위치를 찾을 수 없었다.
- 보안키 저장소
- 오브젝트 스토리지
- 클러스터 모니터링 도구
- 이중화 구성이 되어있던 부분
- 카카오 클라우드
- https://youtu.be/mG17fY4RhHw?t=21m5s
- 다음(daum) 첫화면
- DB나 캐시서버등의 기반시스템이 HA 로 구성되어 있다.
- 컨테이너 오케스트레이터위에서 기동, region 간 2중화는 되어 있다.
- 각 노드별로 health check 에서 이상있는 노드를 자동으로 제외하도록 되어 있다.
- HA 구성이 되어 있었지만, 정상작동하지 않았다.
- 그래서 health check 가 fail 되고, 모든 app 이 disabled 돼서 오류가 발생했다.
- 운영관리도구가 동작안해서 파악도 안됐다.
- 다른 region 의 cache server가 동작한 이후에 서비스가 정상화 됐다.
- 카카오톡 서버, 카카오 로그인 등의 서비스에서의 문제점
- 서비스 간 의존성 문제
- 서버의 불완전한 failover 구성
- 트래픽이 쏠림에 따른 대응 부족
- 충분치 않았던 장애 시나리오
- 서버를 기동시켰을 때, 의존성이 있는 서버가 떠 있지 않으면 기동시킬 수 없는 서버가 있었다.
- failover 가 되어도 이것이 health check 등이 동작하는 것을 전제로 만들어져 있어서, 동작 이상을 감지하는 서버의 문제가 발생해서 failover가 제대로 동작하지 않았다.
- 한쪽 서버로 traffic 이 몰려서, 응답속도가 느려지고, health check에 실패하는 경우도 생겼다. 이 경우 orchestrator 가 자동으로 중지를 시키게 되어 있다. 이렇게 중지된 서버를 다시 run 하려 할 때는 container image 저장소의 장애로 다시 실행을 할 수 없었다.
- 다음(daum) 첫화면
Refereces
- 디지털서비스 장애 조사결과 발표, 시정 요구, 과학기술정보통신부 - 과학기술정보통신부, 2022-12-07
댓글 없음:
댓글 쓰기