이 글(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배 확대
강의에서 (외부유출?금지) 로 들었던 내용들 그냥 푸네요