Upgrade to Pro — share decks privately, control downloads, hide ads and more …

5. 애플리케이션 레이어 다중화

kakao
PRO
December 08, 2022

5. 애플리케이션 레이어 다중화

#HA #DR

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

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

'1015장애 회고' 트랙은 다음과 같이 총 5개의 발표로 구성하였습니다. 이 영상은 카카오의 서비스의 사용자 접점인 서비스 애플리케이션 레이어에 대한 다중화를 설명드립니다. 서비스를 위한 컴포넌트 구성 및 소프트웨어가 여기에 해당합니다. 애플리케이션에서 전략적으로 이중화를 구성하고, 의존성을 관리해 설계를 하고, 트래픽을 잘 관리하며, 실시간 대응도 잘 해야하는 등 이중화가 잘 동작하기 위해 신경써야할 주제를 다룹니다.

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

발표자 : indy.jones
카카오에서 회원플랫폼사업실을 맡고 있는 indy 입니다.

kakao
PRO

December 08, 2022
Tweet

More Decks by kakao

Other Decks in Programming

Transcript

  1. 유용하 (Indy.jones) 카카오 5.애플리케이션 레이어 다중화 if(kakao)2022 Copyright 2022. Kakao

    Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao.
  2. APP1 APP N HA DB (Active) DB (Standby) Cache Server

    (Active) Message Queue (Active) Message Queue (Standby) DC 2 HA Cache Server (Standby) HA Active External Resources SLB SLB GSLB 일반적인 서비스의 시스템 설계 다중화를 위한 일반적인 시스템 설계 (예시) Browser DC 1 Circuit Breaker APP1 APP N Circuit Breaker Active
  3. 1. 시스템 구성의 다중화 2.서비스 간 장애 격리 설계 3.데이터

    센터 트래픽 전환 절차 4.실시간 복구 체계 서비스 다중화의 작동
  4. KakaoTalk App Con fi g Server DB1 (Active) Media Cache

    Front Server App Server Private API Data Cache DB2 (Standby) Status Server Con fi g Server DB2 (Active) Media Cache Front Server App Server Private API Data Cache DB1 (Standby) Status Server 판교DC 시스템 구성의 문제 서비스의 일부 시스템이 다중화되지 못한 경우 1. 서비스 구성의 주체의 모듈별 파편화 2.서비스 구성 후 장시간 장애 사례가 없음 3.다중화 구성 진행 중이었음 4.일반적인 상황에서는 역할이 작음 DC2 Redis
  5. 시스템 구성 다중화의 개선 방향 이상적인 다중화 동작을 위한 조건

    - “서비스 시작 시점”에 “모든 구성 요소”가 데이터센터 간 다중화되어야 함 한정된 자원의 문제 - 상면 확보의 어려움 - 수많은 유휴 장비 운영에 따른 과도한 비효율성 전략적인 다중화 구성 수준 관리 - 영향도에 따른 서비스 별 우선순위를 관리하고 각각의 다중화 구성 수준 조정 - 다수 조직에 일관된 다중화 전략을 적용할 수 있는 거버넌스 필요
  6. 1. 시스템 구성의 다중화 2.서비스 간 장애 격리 설계 3.데이터

    센터 트래픽 전환 절차 4.실시간 복구 체계 서비스 다중화의 작동
  7. 서비스 간 장애 격리 설계의 문제 공용 서비스 플랫폼 장애로

    인한 장애 전파 - 컨테이너 오브젝트 저장소 (도커 이미지) : 다수의 서비스 클라우드 환경 재구성 - 오브젝트 저장소 (미디어) : 이미지를 사용하는 서비스(카카오톡 이미지, 동영상 전송 등) - 보안 정보 저장소 (Vault) : 다수의 서비스 서버 기동 의존성이 있는 다른 서비스의 장애로 인한 장애 전파 - 카카오 로그인 : 카카오T, 카카오페이 등 다수의 서비스 로그인 - 카카오톡 메시지 전송 API : 알림톡 등 메시지 기반 서비스 - 이외, 위의 서비스를 플랫폼으로 사용하는 서비스
  8. 서비스 간 장애 격리 설계의 개선 방향 시스템 설계 개선

    - 기능간 독립적 구조로 설계 및 각각의 런타임 활성화(on/off) 설계 - 필수 기능의 외부 의존성 최소화 연동 방식 개선 - 일부 연계 서비스의 실패 시에도 요청 실패 케이스 최소화 - 느슨한 연동 : 주요 연계 서비스의 데이터에 대한 적극적 캐싱 정책 도입 등 - 서킷 브레이커(Circuit breaker) 고도화 : 빠른 조치에 의한 가용성 유지에 필수. 연동 서비스의 패턴에 따른 상세 튜닝
  9. 1. 시스템 구성의 다중화 2.서비스 간 장애 격리 설계 3.데이터

    센터 트래픽 전환 절차 4.실시간 복구 체계 서비스 다중화의 작동
  10. 데이터센터 간 트래픽 전환 문제 사례 데이터센터 전환 직후 초기

    트래픽에 의한 리소스 소모 문제 - 초기 트래픽은 로그인/정보 동기화 등으로 많은 시스템 자원을 필요로 하는 요청임 - 캐시는 비어있는 상태 - DB 등 구간에 병목 발생으로 전체 서비스에 영향 호출부에서 연계 서버의 IP를 캐싱하는 경우 - GSLB 등을 이용할 때 서비스 애플리케이션에서 연계 서버의 도메인 IP를 캐싱해 자동 전환하는 기능 미동작 - 장애 서버 제외하기 위해 재기동이나 배포가 필요해 장애 시간 장기화 헬스체커 장애 - 서비스에서 자체적으로 fail - over를 구현한 상황에서 헬스체커가 미동작한 경우
  11. 데이터센터 전환 후 트래픽 대응 방법 과도한 트래픽을 처리할 수

    있는 인프라/클라우드 준비 - 주요 병목 구간은 100% “이상” 트래픽을 처리할 수 있는 장비 구성 - 빠르게 스케일 아웃할 수 있는 환경 구성 과도한 트래픽을 방지할 수 있는 웜업(Warm - up) 전략 수립 - 병목 구간의 상황에 따른 점진적인 요청 처리 확대하여 트래픽의 시간적 분산 (자동화 적용) - 셀프 디도스(DDos)를 방지하는 클라이언트의 재요청 룰 설정 - 우선순위에 따라 순차적 기능 활성화(런타임 설정) 서비스 자체 문제 사례 공유 및 방지 - 서버 IP 정보 캐싱 등의 알려진 문제점 체크리스트 - 헬스체커의 데이터센터 다중화 구성
  12. 1. 시스템 구성의 다중화 2.서비스 간 장애 격리 설계 3.데이터

    센터 트래픽 전환 절차 4.실시간 복구 체계 서비스 다중화의 작동
  13. 이상적이지 않은 현실 “언제나 데이터센터 간에 갖추어진 다중화 구성만으로 대응할

    수 있는 것은 아니다.” - 병목이 되는 구성 요소의 스케일 아웃을 위한 리소스 긴급 투입이 필요한 경우 - 우선순위 문제로 다중화 구성되지 않은 구성 요소를 긴급 투입해야 하는 경우 - 소프트웨어의 긴급 패치로 대응해야 하는 경우 - 서비스 그룹이 다운되어 재기동이 필요한 경우 실시간 시스템 재구성/변경을 통해 빠른 시간에 대응해야 함 배포 도구와 같은 운영관리 도구가 중요한 역할
  14. 영향을 미치는 도구들 애플리케이션 배포 - 소스 관리, CI, 도커

    이미지 저장소 등 서버의 재기동 - 보안 정보 저장소 - 서비스 디스커버리(Service discovery): Zookeeper 등 - 설정 스토리지: 각 서비스의 시스템을 시작하기 위한 설정 파일 제공 수작업이 필요한 경우 - 위키 등 문서 도구
  15. 실시간 복구 작업의 체계화 - 장비 및 클라우드 등 리소스의

    안정적인 실시간 투입 체계 마련 - 복구 우선순위 관리 - 서비스 상태 대시보드 - 관리 및 운영 도구의 가용성 확보 (데이터센터 다중화) - 웜업(Warm - up) 플랜
  16. 정리 서비스의 중요도에 따른 다중화 전략 마련 - 중요한 서비스를

    이루는 모든 구성 요소 데이터센터 간 다중화 - 영향도에 따른 서비스 우선순위의 관리, 다중화 구성 수준 조정 장애의 확산을 방지할 수 있는 시스템 구성 - 기능별 활성화 구조, 코어 기능의 의존성 최소화 - 장애를 고려한 결합도를 낮춘 서비스간 연동 설계 실시간 대응 방안 체계화 - 관리 및 운영 도구의 가용성 최대한 확보 - 서비스 웜업(Warm - up) 절차 체계화 - 인프라 및 클라우드 등의 예비 리소스 유지
  17. E.O.D