4. 서비스 플랫폼 레이어 다중화

#HA #DR

지난 10월 15일, 카카오가 사용하고 있던 SKC&C 판교 데이터센터에 화재가 났습니다. 이로 인해 카카오 전체 서버의 1/3의 전원이 꺼지면서 서비스에 장시간 장애가 발생하여, 이용자분들에게 많은 불편을 드렸습니다.

그 후 카카오는 '데이터센터 단위로 어떻게 다중화를 해야 이번과 같은 화재시에도 장애를 최소화 할 수 있는지' 광범위하고 깊은 원인 분석을 했고, 해결책을 고민하고 오늘도 계속 보완/실행해가고 있습니다.
이번 이프카카오에서 '1015장애 회고' 트랙을 통해, 각 시스템 레이어별로 어떻게 다중화할지 그 방안을 상세히 공유드리고자 합니다.

'1015장애 회고' 트랙은 다음과 같이 총 5개의 발표로 구성하였습니다. 이 영상은 카카오가 사용하는 서비스 플랫폼 레이어에 대한 다중화를 설명드립니다. 이 서비스 플랫폼 레이어애는 카카오내에서 사용하는 운영관리도구 / 클라우드 / Redis, ES, Kafka 와 같은 오픈소스기반의 플랫폼 등이 포함됩니다.

1. 데이터센터 단위의 다중화를 위한 고민
2. 인프라 설비 레이어 다중화
3. 데이터 레이어 다중화
4. 서비스 플랫폼 레이어 다중화
5. 애플리케이션 레이어 다중화

발표자 : andrew.kong
카카오 클라우드플랫폼팀 andrew 입니다.

chadwick.kang
카카오 시스템엔지니어링파트 chadwick 입니다.

Transcript

1. 공용준 (andrew.kong) 강차훈 (chadwick.kang) 카카오 4.서비스 플랫폼 레이어 다중화 if(kakao)2022 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao.
2. 1. 운영관리 도구 2. 클라우드 3. 오픈소스 기반 플랫폼(Redis, Elasticsearch, Kafka)
3. 1. 운영관리 도구 2. 클라우드 3. 오픈소스 기반 플랫폼(Redis, Elasticsearch, Kafka)
4. 공용준 (andrew.kong) 카카오 1. 운영관리 도구 if(kakao)2022 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao. 권한 관리
5. 사내 계정인증(LDAP) 요약 - LDAP(Lightweight Directory Access Protocol)은 판교 데이터센터를 포함 3곳의 데이터센터에 분산 된 상태. 화재 시점에 사내 계정인증 서버 설정을 판교 데이터센터에서 타 데이터센터로 수동 변경(10분 소요) 해 장애 대응(17:31’’) 해결 - 유사하게 판교 LDAP을 직접 사용했던 서비스(Git, Jira, Wiki)의 경우 타 데이터센터의 LDAP으로 수동 도메 인 전환이 필요했음
6. 사내 계정인증(LDAP) 잘 되었던 부분 - LDAP은 데이터센터 별로 서버가 분산 구축이 되어 있었고, 사내 계정인증 서버는 다른 데이터센터 별로 액티브- 스탠바이로 구축이 되어 있음 - 데이터센터 별 LDAP 유저(서버) 및 담당자 사전 파악 정보가 존재해서 장애 영향 범위 및 빠른 전파가 가능했음 - 사내 계정 인증 서비스 구조가 단순한 면도 있지만, 서비스 간 연계 영향 안 받는 로직/구조로 운영하고 있음
7. DC1 PG <<Master>> <<Master>> DC2 Actor Actor Actor Actor Actor Actor User 사내 계정인증(LDAP) 아키텍처 : IAM LDAP 시스템 흐름도 GSLB 전용 도메인 DC1 PG DC2 <<Master>> <<Master>> <<Master>> <<Master>>
8. 사내 계정인증(LDAP) 부족했던 부분 - 장애 대응 작업은 10분 내외였으나, VPN 접근을(OTP 미수신) 1시간(17:02분까지) 가량 못함. VPN 담당자 유선 연락으로 접근 방법 및 상황 가이드 받음 - 전사 장애 대응(훈련) 시나리오 필요성 회고 - LDAP 직접 사용하는 사내 서비스(도구)는 데이터센터 장애 시 직접적인 장애 영향을 받는 구조이기에 - 데이터센터 간 삼중화 GSLB 구성으로 장애 상황에 따른 수동 전환 작업 단계 제거를 위한 구성 적용 필요
9. 소스 관리 - 깃허브 요약 - 깃허브는 DC 이중화(Active - Standby) 구성되었지만 두 가지 이유로 신속한 대응이 이루어지지 못했음 원인 1. - 판교 DC 장애 발생 후, Standby 깃허브를 Active로 승격하는 과정이 예상보다 오랜 시간 소요 - 깃허브 매뉴얼 기준 기대시간은 10분 이지만 ‘ES unassigned shard’ 이슈가 발생해서 실제 3~4시간 소요 원인 2. - 판교 DC LDAP 장애 발생 후, DC 2 - LDAP 전환 과정에서 지연 발생 - 깃허브는 LDAP 전환을 위해, UI를 통해 권한을 획득해야 하는 프로세스 - 두 가지 원인으로 복잡도가 증가하여 대응 시간 지연 Standby Active replica DC 1(판교) DC 2
10. 소스 관리 - 깃허브 잘 되었던 부분 - 데이터 백업 파일은 데이터센터 삼중화 보관 - 증분 백업은 하루에 2번 / 풀백업은 5일 단위 부족했던 부분 - failover 테스트를 Dev Stage에서만 진행 - (Prod Stage에서는 모의 훈련 미경험) - 다양한 예외 사항 케이스들을 사전 학습, 경험 부족 Active Standby DC 1(판교) DC 2 Standby DC 3 (진행중) replica replica 백업 파일 백업 파일 백업 파일
11. 후속 대응 Nexus Repository 요약 - 판교 DC 내에서만 서버 이중화 되어 있었음 장애 후속 대응 - DC 이중화(완료), DC 삼중화(진행중) 부족했던 부분 - (DC 레벨)고가용성 필요성 인식 부족 Active Standby DC 1(판교) DC 2 : 완료 Standby DC 3 : 계획중 replica Active DC 1(판교) DC 2 Standby replica DC 이중화 구성 없었음
12. 1. 운영관리 도구 2. 클라우드 3. 오픈소스 기반 플랫폼(Redis, Elasticsearch, Kafka)
13. 공용준 (andrew.kong) 카카오 2. 클라우드 if(kakao)2022 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao.
14. Service Platform, before the DC outage 서비스 티어링 및 복제 상태
15. Service Platform, DC outage DC 간 복제 상태
16. Incidents Actions 컨테이너 오케스트레이터 API/DB 2 DC Active - Standby Automatic Switching 리소스 풀(Pool) 사고 난 DC 리소스 다운 DC 1에서 신규 리소스 제공 데이터 저장소 - - 컨테이너 이미지 저장소 API/DB 2 DC Active - Standby Automatic Switching 리소스 풀(Pool) - - 데이터 저장소 오브젝트 스토리지 1 장애 위치 저장소를 오브젝트 2로 변환(RO) RW 가능한 컨테이너 이미지 저장소 신규 제공 가상머신 클라우드 API/DB 2 DC Active – Standby + 각 DC 전용 API/DB 분리 구조 Automatic Switching 리소스 풀(Pool) - DC 1에서 신규 리소스 제공 물리와 동일 성능의 가상 서버(hvm) 제공 데이터 저장소 য়࠳ં౟ झషܻ૑ 1 ੢গ 위치 저장소를 오브젝트 2로 변환(RO), RW 가능한 가상 머신 이미지 저장소 신규 제공 Service Platform: the incidents and actions Compute
17. Incidents Actions 오브젝트 스토리지 1 API/DB 3 DC Active - Standby Automatic Switching 오브젝트 위치 저장소 DC 이전/종료 등의 이유로 1 DC Zone 간 복제 이관을 위해서 오브젝트 스토리지 2 용 메타로 데이터 2중화 오브젝트 스토리지 2의 메타를 활용 읽기 상태로 복구 데이터 저장소 3 DC 복제 데이터 유실 없음 오브젝트 스토리지 2 API/DB 3 DC Active - Standby Automatic Switching 오브젝트 위치 저장소 3 DC 복제 - 데이터 저장소 기본 3 DC 복제 DC 이전/상면 부족으로 데이터 일부 1DC Zone 복제 3 DC 복제본 정상, 1 DC 복제본 데이터는 전원 인입 후 정상화 보안 정보 저장소 API/DB 2 DC Active - Standby Automatic Switching 리소스 풀(Pool) - - 데이터 저장소 오브젝트 스토리지 2 + DB 백업 오브젝트 스토리지 2의 일부 데이터 접근 불가로 DB 전환 후 복구 Persistent Platform: the incidents and actions Storage
18. Telemetry and data Platform: the incidents and actions Incidents Actions Metering as a Service API/DB 2 DC Active - Standby Automatic Switching 컴퓨팅 리소스 판교 위치 DC에 긴급 재구성 데이터 저장소 시계열 데이터베이스 안양 위치 - Data pipeline as a service API/DB 2 DC Active - Standby Automatic Switching 컴퓨팅 리소스 판교 위치 - 데이터 저장소 메시지 브로커 장애 Elasticsearch 장애 Hadoop 장애 - 판교 복구후 해소
19. Lessons and Remedies Learned From 10.15 outage RTO 30분을 위해 API는 Active - Active, 데이터 저장소는 티어1급으로 변경 Lessons Remedies 컨테이너 오케스트레이터 API/DB 2 DC Active – Standby 복구 시간 소요 Active - Active 구성 리소스 풀(Pool) 상면 부족 및 풀의 밀도 낮음 고집적 컴퓨팅 리소스로 변환 컨테이너 이미지 저장소 API/DB 2 DC Active – Standby 복구 시간 소요 Active - Active 구성 데이터 저장소 변환 중인 오브젝트 스토리지 1은 확장 안함 오브젝트 스토리지 2로 변환 가상머신 클라우드 API/DB 2 DC Active – Standby 복구 시간 소요 + 각 DC 전용 API/DB 분리 구조 Active - Active 구성 리소스 풀(Pool) 상면 부족 및 풀의 밀도 낮음 고집적 컴퓨팅 리소스로 변환 데이터 저장소 변환 중인 오브젝트 스토리지 1은 확장 안함 오브젝트 스토리지 2로 변환
20. Lessons and Remedies Learned From 10.15 outage RTO 30분을 위해 API는 Active - Active, 데이터 저장소는 3DC 복제를 기본으로 Lessons Remedies 오브젝트 스토리지 1 API/DB 3 DC Active - Standby Active - Active 구성 오브젝트 위치 저장소 존 단위 복제는 장애의 위험이 있음 3 DC 복제로 변경 데이터 저장소 3 DC 복제 3 DC 복제 유지 오브젝트 스토리지 2 API/DB 3 DC Active - Standby Active - Active 구성 오브젝트 위치 저장소 3 DC 복제 3 DC 복제 유지 데이터 저장소 일부라도 1DC 존간 분리는 부족함 3 DC 복제로 변경 보안 정보 저장소 API/DB 2 DC Active - Standby Active - Active 구성 리소스 풀(Pool) - - 데이터 저장소 오브젝트 스토리지 2 + DB 백업 DB(tier1)로 저장소 전환
21. Lessons and Remedies Learned From 10.15 outage RTO 30분을 위해 API는 Active - Active, 완벽한 자동화를 통한 빠른 재구성 Lessons Remedies Metering as a Service API/DB 2 DC Active – Standby 복구 시간 소요 Active - Active 구성 컴퓨팅 리소스 대규모 리소스라서 이중화 불가 재구성의 완벽한 자동화 데이터 저장소 1 DC 복제본은 이슈가 있음 3 DC 복제본 가능한 시계열 데이터베이스로 이관 Data pipeline as a service API/DB 2 DC Active – Standby 복구 시간 소요 Active - Active 구성 컴퓨팅 리소스 판교 위치 재구성의 완벽한 자동화 데이터 저장소 메시지 브로커 장애 Elasticsearch 장애 Hadoop 장애 장애 발생 시 오브젝트 스토리지 2로 긴급 전환, 이후 오브젝트 스토리지 2 데이터로 복구
22. Lessons and Remedies Learned From 10.15 outage RTO 30분을 위해 API는 Active - Active, 가시성 강화 , 멀티 클라우드 개발 플랫폼 강화 Lessons Remedies 가시성 강화 40여종의 클라우드 서비스 상태를 개발자가 모니터링이 어려움 (어드민 뷰는 있음) -카카오 SaaS 프레임워크로 전환 -사용자가 접근 가능한 카카오 클라우드 서비스 관제 시스템 및 대시보드 개발 개발 플랫폼 강화 개별 IDE/CI 환경의 구성으로 장애에 취약하고 한 곳에서 개발/배포/운영을 할 수 없음. 클라우드 기반 종합 개발 플랫폼 개발 멀티 클라우드 활용 리소스 부족이나 주요 에코 손상시에 서비스를 재구성하기 어려움. 카카오 클라우드 SSO와 IAM기반의 멀티 클라우드 POC완료 및 23년내 적용
23. 강차훈 (chadwick.kang) 카카오 3. 오픈소스 기반 플랫폼 (Redis, Elasticsearch, Kafka) if(kakao)2022 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao.
24. Redis 요약 - RHA(Redis HA), 레디스 싱글, 레디스 클러스터 3가지 형태의 구성이 있음 - 장애 시 레디스 클러스터는 문제가 없었으나, RHA와 레디스 싱글은 문제가 있었음
25. Redis 잘 되었던 부분 - Redis Cluster는 구축 시 부터 3중화가 되어 있어, 하나의 IDC 전면 장애에도 문제가 없었음 이슈 및 개선 사항 - RHA는 Master - Slave 모두, Redis Single은 인스턴스가 판교에 있는 경우 재구성 전까지 서비스 다운 상태 - Redis 관리 툴, 내부 툴이 이중화되지 않은 부분이 있어 장애 상황에서 수동으로 확인하며 복구작업을 하는 도중 작업 실수도 발생하였으며 의존 API들이 동작하지 않음 - RHA를 Failover 시키는 데몬에 네트워크 순단 등의 일시적 장애에 전면 전환되지 않도록 하는 로직이 있음. 이 로직이 실제 전면 장애 시에는 필요한 Failover 를 방해함 - Redis 도메인별 서비스 영향도를 파악하기 힘들었음. Redis를 캐시, 세션 스토리지, 큐 등 다양한 용도의 사용 과 구축 시 논의된 것과 다른 데이터의 추가 등 클라이언트단의 변화를 알기 힘들었음
26. Elasticsearch 요약 - 전체 서비스 단위의 클러스터 중 30% 정도에서 장애 발생 - 장애 영향도는 핵심 컴포넌트로 사용하는 경우 전면적, 로그 저장소나 내부관리 도구로 사용하는 경우에는 일부 영향 - 데이터 센터 내의 일부 장애는 버틸 수 있도록 구축하고 더한 상황에도 버티도록 계속 개선 중이었으나 데이터 센터 전체 다운 상황에서는 장애를 피할 수 없었음
27. Elasticsearch 잘 되었던 부분 - 데이터 센터 전면 장애 시 복구 시나리오가 있어, 절차를 따라 복구를 진행함 이슈 및 개선 사항 - 서비스 핵심 컴포넌트로 사용되는 경우 하나의 데이터 센터 장애에도 버틸 수 있는 구조가 필요 - 사용목적, 중요도, 장애 시 영향도에 대해 파악이 충분하지 못하여 복구 시 우선순위를 정하는데 어려움 - 일부 클러스터는 여러 가지 주변 여건상 안정성보다 빠른 배포와 비용이 절감되는 방향으로 운영되어 장애에 취약함
28. Elasticsearch 기존 구조 (IDC 일부 장애 대비, 전면 장애 대응 불가) - 데이터를 관리하는 마스터 서버가 클러스터 전체에 과반수 이상 동작해야 함.(카카오 기준 3개 중 2개) - 마스터 서버가 클러스터에 부족한 경우 데이터 정합성 유지를 위해 클러스 터 통신 중지. - 서비스 부서에서 요청하는 경우만 데이터 서버 분산 배치.(그림 생략) 개선된 구조(IDC 1개 전면 장애 대비) - 데이터를 관리하는 마스터 서버를 3개 IDC에 분산 배치. - 중요 클러스터는 반드시 데이터 서버도 2개 IDC에 분산 배치.(그림 생략) 마스터 마스터 데이터 마스터 IDC A IDC B 마스터 데이터 마스터 IDC A IDC B 마스터 IDC C
29. Kafka 요약 - 클러스터는 여러 서비스들이 같이 사용하는 공용 클러스터와, 컴플라이언스와 부하 등의 이슈로 특정 서비스 독 립적으로 사용하는 개별 클러스터 두 가지로 나눔. - 판교 포함 4개의 IDC에 Kafka 클러스터들이 있으며 그중 공용 클러스터는 35%, 개별 클러스터는 25% 가 판 교에 위치해 있으며, 해당 클러스터에서 장애 발생.
30. Kafka 잘 되었던 부분 - 복구가 오래 걸린 클러스터는 타 공용 클러스터에 약 300여 개의 긴급 토픽을 생성하여 대응. - 기존에 권고 구성대로 서비스단에서 토픽을 다중으로 생성하여 사용하는 경우에는 문제가 없었음. 이슈 및 개선 사항 - Broker는 살아 있지만 메타데이터를 관장하는 Zookeeper의 경우도 과반수가 살아있어야 동작하나 그렇 지 못하여 정상동작이 되지 못하는 경우가 있었음. - Broker의 Disk, Network부하가 거대하고 파티션구성으로 Broker자체의 IDC다중화 복제구성은 IDC 간 트래픽문제등으로 현실적으로는 어려운 점이 있어 수행하지 않고 있었음. - 관리 운영툴 및 모니터링이 이중화가 되어있지 않아 지표 모니터링이 불가하였음. - 각 서비스들의 중요도와 영향도 파악이 잘 되어있지 않아 복구 우선순위를 정하기가 쉽지 않았음.
31. 요약 - Master - Slave 구조 2중화의 경우 독립 IDC 혹은 클라우드의 리젼 같은 2개의 가용구역(Availability Zone) 에 분산되어 있지 않고 모두 하나의 가용 구역에서 운영하면 장애를 극복할 수 없음. - Redis cluster, Elasticsearch의 Master node, Kafka의 Zookeeper처럼 쿼럼(Quorum)구조의 클 러스터 구성요소의 경우 독립 IDC 혹은 클라우드의 리젼 같은 최소 3개의 가용구역(Availability Zone)에 분산 되어 있지 않으면 하나의 가용 구역 전면 장애 시 제대로 된 동작을 보장할 수 없음. - 플랫폼 자체뿐만 아니라 플랫폼 관리 도구와 모니터링 도구도 이중화가 필요. - 플랫폼 서비스의 사용 주체와 운영주체가 다를 경우, 플랫폼을 사용하는 서비스와 사용 용도를 파악. - 금융시장의 블랙스완과 같은 IDC 전면 장애는 국가로 치면 전시와 같으므로 사전에 장애 시나리오에 따른 준비와 대비훈련이 필요.