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

공용준 (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.

View Slide

1. 운영관리 도구

2. 클라우드

3. 오픈소스 기반 플랫폼(Redis, Elasticsearch, Kafka)

View Slide


카카오
if(kakao)2022
권한 관리

View Slide

사내 계정인증(LDAP)
요약

- LDAP(Lightweight Directory Access Protocol)은 판교 데이터센터를 포함 3곳의 데이터센터에 분산
된 상태. 화재 시점에 사내 계정인증 서버 설정을 판교 데이터센터에서 타 데이터센터로 수동 변경(10분 소요)
해 장애 대응(17:31’’) 해결

- 유사하게 판교 LDAP을 직접 사용했던 서비스(Git, Jira, Wiki)의 경우 타 데이터센터의 LDAP으로 수동 도메
인 전환이 필요했음

View Slide

잘 되었던 부분

- LDAP은 데이터센터 별로 서버가 분산 구축이 되어 있었고, 사내 계정인증 서버는 다른 데이터센터 별로 액티브-
스탠바이로 구축이 되어 있음

- 데이터센터 별 LDAP 유저(서버) 및 담당자 사전 파악 정보가 존재해서 장애 영향 범위 및 빠른 전파가 가능했음

- 사내 계정 인증 서비스 구조가 단순한 면도 있지만, 서비스 간 연계 영향 안 받는 로직/구조로 운영하고 있음

View Slide

DC1
PG
<>
<>
DC2
Actor
Actor
Actor
Actor
Actor
Actor
User
아키텍처 : IAM LDAP 시스템 흐름도
GSLB

전용 도메인
DC1
PG
DC2
<>
<>
<>
<>

View Slide

부족했던 부분

- 장애 대응 작업은 10분 내외였으나, VPN 접근을(OTP 미수신) 1시간(17:02분까지) 가량 못함. VPN 담당자
유선 연락으로 접근 방법 및 상황 가이드 받음

- 전사 장애 대응(훈련) 시나리오 필요성 회고

- LDAP 직접 사용하는 사내 서비스(도구)는 데이터센터 장애 시 직접적인 장애 영향을 받는 구조이기에

- 데이터센터 간 삼중화 GSLB 구성으로 장애 상황에 따른 수동 전환 작업 단계 제거를 위한 구성 적용 필요

View Slide

소스 관리 - 깃허브
요약

- 깃허브는 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

View Slide

소스 관리 - 깃허브

- 데이터 백업 파일은 데이터센터 삼중화 보관

- 증분 백업은 하루에 2번 / 풀백업은 5일 단위

부족했던 부분

- failover 테스트를 Dev Stage에서만 진행

- (Prod Stage에서는 모의 훈련 미경험)

- 다양한 예외 사항 케이스들을 사전 학습, 경험 부족
Active
Standby
DC 1(판교) DC 2
Standby
DC 3

(진행중)
replica replica
백업 파일 백업 파일 백업 파일

View Slide

후속 대응
Nexus Repository
요약
- 판교 DC 내에서만 서버 이중화 되어 있었음

장애 후속 대응

- DC 이중화(완료), DC 삼중화(진행중)

부족했던 부분

- (DC 레벨)고가용성 필요성 인식 부족
Active
Standby
DC 1(판교) DC 2 : 완료
Standby
DC 3 : 계획중
replica
Active
DC 1(판교) DC 2
Standby
replica
DC 이중화

구성 없었음

View Slide


2. 클라우드

3. 오픈소스 기반 플랫폼(Redis, Elasticsearch, Kafka)

View Slide


카카오
2. 클라우드
if(kakao)2022

View Slide

Service Platform, before the DC outage
서비스 티어링 및 복제 상태

View Slide

Service Platform, DC outage
DC 간 복제 상태

View Slide

Incidents Actions
컨테이너 오케스트레이터
API/DB 2 DC Active - Standby Automatic Switching
리소스 풀(Pool) 사고 난 DC 리소스 다운 DC 1에서 신규 리소스 제공
데이터 저장소 - -
컨테이너 이미지 저장소
리소스 풀(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

View Slide

Incidents Actions
오브젝트 스토리지 1
오브젝트 위치 저장소
DC 이전/종료 등의 이유로 1 DC Zone 간 복제

이관을 위해서 오브젝트 스토리지 2 용 메타로 데이터 2중화
오브젝트 스토리지 2의

메타를 활용 읽기 상태로 복구
데이터 저장소 3 DC 복제 데이터 유실 없음
오브젝트 위치 저장소 3 DC 복제 -
데이터 저장소
기본 3 DC 복제

DC 이전/상면 부족으로 데이터 일부 1DC Zone 복제
3 DC 복제본 정상, 1 DC 복제본 데이터는

전원 인입 후 정상화
보안 정보 저장소
데이터 저장소 오브젝트 스토리지 2 + DB 백업
오브젝트 스토리지 2의 일부 데이터 접근 불가로

DB 전환 후 복구
Persistent Platform:

the incidents and actions Storage

View Slide

Telemetry and data Platform:

the incidents and actions
Incidents Actions
Metering as a Service
컴퓨팅 리소스 판교 위치 DC에 긴급 재구성
데이터 저장소 시계열 데이터베이스 안양 위치 -
Data pipeline as a service
컴퓨팅 리소스 판교 위치 -
데이터 저장소
메시지 브로커 장애

Elasticsearch 장애

Hadoop 장애
- 판교 복구후 해소

View Slide

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) 상면 부족 및 풀의 밀도 낮음 고집적 컴퓨팅 리소스로 변환
컨테이너 이미지 저장소
-
Active 구성
데이터 저장소 변환 중인 오브젝트 스토리지 1은 확장 안함 오브젝트 스토리지 2로 변환
가상머신 클라우드
API/DB 2 DC Active – Standby 복구 시간 소요 + 각 DC 전용 API/DB 분리 구조 Active
-
Active 구성
리소스 풀(Pool) 상면 부족 및 풀의 밀도 낮음 고집적 컴퓨팅 리소스로 변환
데이터 저장소 변환 중인 오브젝트 스토리지 1은 확장 안함 오브젝트 스토리지 2로 변환

View Slide

-
Active, 데이터 저장소는 3DC 복제를 기본으로
Lessons Remedies
API/DB 3 DC Active - Standby Active
-
Active 구성
오브젝트 위치 저장소 존 단위 복제는 장애의 위험이 있음 3 DC 복제로 변경
데이터 저장소 3 DC 복제 3 DC 복제 유지
-
Active 구성
오브젝트 위치 저장소 3 DC 복제 3 DC 복제 유지
데이터 저장소 일부라도 1DC 존간 분리는 부족함 3 DC 복제로 변경
보안 정보 저장소
-
Active 구성
데이터 저장소 오브젝트 스토리지 2 + DB 백업 DB(tier1)로 저장소 전환

View Slide

-
Active, 완벽한 자동화를 통한 빠른 재구성
Lessons Remedies
Metering as a Service
-
Active 구성
컴퓨팅 리소스 대규모 리소스라서 이중화 불가 재구성의 완벽한 자동화
데이터 저장소 1 DC 복제본은 이슈가 있음 3 DC 복제본 가능한 시계열 데이터베이스로 이관
Data pipeline as a service
-
Active 구성
컴퓨팅 리소스 판교 위치 재구성의 완벽한 자동화
데이터 저장소
메시지 브로커 장애

Elasticsearch 장애

Hadoop 장애
장애 발생 시 오브젝트 스토리지 2로 긴급 전환,

이후 오브젝트 스토리지 2 데이터로 복구

View Slide

-
Active, 가시성 강화 , 멀티 클라우드 개발 플랫폼 강화
Lessons Remedies
가시성 강화
40여종의 클라우드 서비스 상태를 개발자가 모니터링이 어려움

(어드민 뷰는 있음)
-카카오 SaaS 프레임워크로 전환

-사용자가 접근 가능한 카카오 클라우드 서비스 관제 시스템 및 대시보드 개발
개발 플랫폼 강화
개별 IDE/CI 환경의 구성으로 장애에 취약하고

한 곳에서 개발/배포/운영을 할 수 없음.
클라우드 기반 종합 개발 플랫폼 개발
멀티 클라우드 활용 리소스 부족이나 주요 에코 손상시에 서비스를 재구성하기 어려움. 카카오 클라우드 SSO와 IAM기반의 멀티 클라우드 POC완료 및 23년내 적용

View Slide

강차훈 (chadwick.kang)

카카오
3. 오픈소스 기반 플랫폼

(Redis, Elasticsearch, Kafka)
if(kakao)2022

View Slide

Redis
요약
- RHA(Redis HA), 레디스 싱글, 레디스 클러스터 3가지 형태의 구성이 있음

- 장애 시 레디스 클러스터는 문제가 없었으나, RHA와 레디스 싱글은 문제가 있었음

View Slide

Redis

- Redis Cluster는 구축 시 부터 3중화가 되어 있어, 하나의 IDC 전면 장애에도 문제가 없었음

이슈 및 개선 사항

- RHA는 Master
-
Slave 모두, Redis Single은 인스턴스가 판교에 있는 경우 재구성 전까지 서비스 다운 상태

- Redis 관리 툴, 내부 툴이 이중화되지 않은 부분이 있어 장애 상황에서 수동으로 확인하며 복구작업을 하는 도중
작업 실수도 발생하였으며 의존 API들이 동작하지 않음

- RHA를 Failover 시키는 데몬에 네트워크 순단 등의 일시적 장애에 전면 전환되지 않도록 하는 로직이 있음. 이
로직이 실제 전면 장애 시에는 필요한 Failover 를 방해함

- Redis 도메인별 서비스 영향도를 파악하기 힘들었음. Redis를 캐시, 세션 스토리지, 큐 등 다양한 용도의 사용
과 구축 시 논의된 것과 다른 데이터의 추가 등 클라이언트단의 변화를 알기 힘들었음

View Slide

Elasticsearch
요약

- 전체 서비스 단위의 클러스터 중 30% 정도에서 장애 발생

- 장애 영향도는 핵심 컴포넌트로 사용하는 경우 전면적, 로그 저장소나 내부관리 도구로 사용하는 경우에는 일부
영향

- 데이터 센터 내의 일부 장애는 버틸 수 있도록 구축하고 더한 상황에도 버티도록 계속 개선 중이었으나 데이터
센터 전체 다운 상황에서는 장애를 피할 수 없었음

View Slide

Elasticsearch

- 데이터 센터 전면 장애 시 복구 시나리오가 있어, 절차를 따라 복구를 진행함


- 서비스 핵심 컴포넌트로 사용되는 경우 하나의 데이터 센터 장애에도 버틸 수 있는 구조가 필요

- 사용목적, 중요도, 장애 시 영향도에 대해 파악이 충분하지 못하여 복구 시 우선순위를 정하는데 어려움

- 일부 클러스터는 여러 가지 주변 여건상 안정성보다 빠른 배포와 비용이 절감되는 방향으로 운영되어 장애에
취약함

View Slide

Elasticsearch
기존 구조 (IDC 일부 장애 대비, 전면 장애 대응 불가)

- 데이터를 관리하는 마스터 서버가 클러스터 전체에 과반수 이상 동작해야
함.(카카오 기준 3개 중 2개)

- 마스터 서버가 클러스터에 부족한 경우 데이터 정합성 유지를 위해 클러스
터 통신 중지.

- 서비스 부서에서 요청하는 경우만 데이터 서버 분산 배치.(그림 생략)
개선된 구조(IDC 1개 전면 장애 대비)

- 데이터를 관리하는 마스터 서버를 3개 IDC에 분산 배치.

- 중요 클러스터는 반드시 데이터 서버도 2개 IDC에 분산 배치.(그림 생략)
마스터 마스터
데이터
마스터
IDC A IDC B
마스터
데이터
마스터
IDC A IDC B
마스터
IDC C

View Slide

Kafka
요약

- 클러스터는 여러 서비스들이 같이 사용하는 공용 클러스터와, 컴플라이언스와 부하 등의 이슈로 특정 서비스 독
립적으로 사용하는 개별 클러스터 두 가지로 나눔.

- 판교 포함 4개의 IDC에 Kafka 클러스터들이 있으며 그중 공용 클러스터는 35%, 개별 클러스터는 25% 가 판
교에 위치해 있으며, 해당 클러스터에서 장애 발생.

View Slide

Kafka

- 복구가 오래 걸린 클러스터는 타 공용 클러스터에 약 300여 개의 긴급 토픽을 생성하여 대응.

- 기존에 권고 구성대로 서비스단에서 토픽을 다중으로 생성하여 사용하는 경우에는 문제가 없었음.


- Broker는 살아 있지만 메타데이터를 관장하는 Zookeeper의 경우도 과반수가 살아있어야 동작하나 그렇
지 못하여 정상동작이 되지 못하는 경우가 있었음.

- Broker의 Disk, Network부하가 거대하고 파티션구성으로 Broker자체의 IDC다중화 복제구성은 IDC
간 트래픽문제등으로 현실적으로는 어려운 점이 있어 수행하지 않고 있었음.

- 관리 운영툴 및 모니터링이 이중화가 되어있지 않아 지표 모니터링이 불가하였음.

- 각 서비스들의 중요도와 영향도 파악이 잘 되어있지 않아 복구 우선순위를 정하기가 쉽지 않았음.

View Slide

요약
- Master
-
Slave 구조 2중화의 경우 독립 IDC 혹은 클라우드의 리젼 같은 2개의 가용구역(Availability Zone)
에 분산되어 있지 않고 모두 하나의 가용 구역에서 운영하면 장애를 극복할 수 없음.

- Redis cluster, Elasticsearch의 Master node, Kafka의 Zookeeper처럼 쿼럼(Quorum)구조의 클
러스터 구성요소의 경우 독립 IDC 혹은 클라우드의 리젼 같은 최소 3개의 가용구역(Availability Zone)에 분산
되어 있지 않으면 하나의 가용 구역 전면 장애 시 제대로 된 동작을 보장할 수 없음.

- 플랫폼 자체뿐만 아니라 플랫폼 관리 도구와 모니터링 도구도 이중화가 필요.

- 플랫폼 서비스의 사용 주체와 운영주체가 다를 경우, 플랫폼을 사용하는 서비스와 사용 용도를 파악.

- 금융시장의 블랙스완과 같은 IDC 전면 장애는 국가로 치면 전시와 같으므로 사전에 장애 시나리오에 따른 준비와
대비훈련이 필요.

View Slide

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

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

kakao

More Decks by kakao

Other Decks in Programming

Featured

Transcript