[컴] 2022년 11월 카카오 서비스 장애 내용

카톡 중단 이유 / 화재 사건 / 사고발생 이유 / 중단된 이유 / 이중화 /

카카오 서비스 장애 내용

정부의 디지털서비스 장애 조사결과 발표

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 데이터센터간 노드분산 확대 필요
  • https://youtu.be/mG17fY4RhHw?t=18m9s
    • 2중화가 잘안된 운영관리도구들
      • 사내 계정 인증 서버
      • 소스 관리 도구
      • 앱 배포 도구
      • 위키, 지라
  • https://youtu.be/mG17fY4RhHw?t=18m56s
    • 2중화가 잘 안된 플랫폼
      • 자체 클라우드
      • 엘라스틱서치 플랫폼
      • 레디스, 카프카 클러스터 운영
    • region 이 동작안할 때에 대한 대비가 없었다.
    • 수많은 서비스들이 한꺼번에 다운된 경우 어떤 순서로 restart 를 해야되는지에 대한 가이드가 없었다.
    • 엘라스틱서치, 레디스, 카프카 모두 전체중 약 1/3 가량의 클러스터에서 통신장애가 발생
  • 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 저장소의 장애로 다시 실행을 할 수 없었다.

Refereces

  1. 디지털서비스 장애 조사결과 발표, 시정 요구, 과학기술정보통신부 - 과학기술정보통신부, 2022-12-07

댓글 없음:

댓글 쓰기