[if(kakao) dev 2019] 카카오톡 적용 사례를 통해 살펴보는 카카오 클라우드의 Kubernetes as a Service Review

출처 : https://if.kakao.com/2019/program?sessionId=eebbe5ae-0c77-4f52-83af-5818f9fd6c26 

if(kakao)2021

카카오 프라이빗 클라우드의 KaaS(Kubernetes as a Service) DKOSv3 를 소개 하고, 카카오톡에 적용된 쿠버네티스 사례와 서비스 운영에 대해 공유합니다.

 

리뷰 포인트

• 카카오가 Kubernetes를 사용하는 방법
• Kubernetes 기반 카카오톡 백엔드 배포 및 운영

 

카카오가 Kubernetes를 사용하는 방법

• Kubernetes를 도입한 이유
  • 흐름
    • Monolithic Architecture : 하나의 커다란 Application 이 모든 기능을 다 수행
      • 개발 및 운영방법
        • 하나의 커다란 애플리케이션이 카카오의 모든 서비스를 담당함
        • 커다란 애플리케이션의 실행파일 하나를 복사해 여러 서버에 중복 설치(배포)되어 실행됨
        • 사용자의 요청이 들어오면 Load Balancer가 트래픽이 적은 서버로 요청을 보냄
        • 만약 새로운 버전의 애플리케이션을 배포하고 싶다면 네트워크 담당자가 로드밸런서를 수동으로 제어하여 N개의 서버 중 첫 번째로 가는 요청을 차단하고 개발자와 서버엔지니어가 해당 서버의 새로운 버전의 애플리케이션을 배포함
        • 첫 번째 서버를 다시 기동하고 로드밸런서를 수동으로 제어하여 첫 번째 서버에 트래픽을 다시 연결
        • 두 번째, 세 번째, ... 서버들도 위와 같은 과정을 통해 배포를 완료함
      • 장점
        • 서비스 중단 없이 배포 가능
      • 문제점
        • 기능이 추가될 수록 애플리케이션 내 상호 의존성과 복잡도 증가
          • 기능을 추가하려면 애플리케이션 전체 코드에 대한 이해가 필요함
        • 지속적인 통합/빌드가 어려움
        • 배포 및 기동 시간이 오래걸림
    • MicroService Architecture(MSA) : 역할과 책임을 분리
      • 개발 및 운영방법
        • 하나의 커다란 애플리케이션을 역할과 책임별로 분리하여 여러 개의 애플리케이션으로 나눔
        • 애플리케이션들은 여러 서버에 섞여서 중복 설치(배포)됨
        • 로드밸런서가 각 애플리케이션에 트래픽을 분배함
      • 장점
        • 애플리케이션을 역할별로 나누어서 복잡도가 줄어들면서 개별적으로 디버깅, 업데이트, 확장이 쉬워짐
        • 각 애플리케이션 별로 다른 언어를 사용할 수 있음 -> 가장 적절한 언어를 선택할 수 있음
      • 문제점
        • 하나의 서버에 여러 개의 어플리케이션이 섞여서 배포되므로 애플리케이션 간 성능 간섭이 발생함 -> 애플리케이션 별로 성능 분배 및 격리 필요
        • 각 애플리케이션 별로 다른 언어를 사용할 수 있음 -> 서버에 해당 애플리케이션을 수행하는 데 필요한 언어와 라이브러리가 모두 설치되어 있어야 함
        • 관리해야할 어플리케이션의 개수와 연결해야할 로드밸런싱 설정이 많고 복잠해 짐.
        • 애플리케이션이 매우 많아져서 애플리케이션을 설치(배포)/관리하기 어려움
    • Container와 Orchestrator의 등장 : 패키징/격리와 자동화된 관리/배포
      • 개발, 운영방법
        • Container로 애플리케이션을 OS환경까지 Image화 해서 배포함
        • Contanier Orchestrator인 kubernetes는 Service와 Ingress라는 개념을 활용해 Container 단위의 애플리케이션과 로드밸런서 연결을 자동으로 제어하며 서비스 중단 없는 배포를 자동화
      • 장점
        • 애플리케이션 배포, 로드밸런서 설정, 중단 없는 배포의 자동화
        • Self-healing : 애플리케이션이 죽으면 건강한 다른 서버에 자동으로 복구함

[그림 1] One Big Cluster VS Many Small Ones

• kakao의 KaaS(Kubernetes as a Service)
  • kakao의 DKOS 플랫폼
    • DKOS는 개인혹은 조직이 학습/개발/서비스 용도의 쿠버네티스 클러스터를 생성해서 사용할 수 있게 해주는 카카오의 프라이빗 클라우드 플랫폼이다.
    • 어떤 조직이 프로젝트를 시작하면 먼저 쿠버네티스 클러스터를 생성하고 그 위에서 애플리케이션을 개발/배포한다.
  • One Big Cluster VS. Many Small Ones
    • 용어
      • Multi-tenancy :
        • 단일 소프트웨어 인스턴스로 서로 다른 여러 사용자 그룹에 서비스를 제공할 수 있는 소프트웨어 아키텍처. 멀티테넌시 환경에서 복수의 고객들은 동일한 데이터 스토리지 매커니즘과 함께 동일한 하드웨어의 동일한 운영 체제에서 실행되는 동일한 응용 프로그램을 공유한다. 
      • 쿠버네티스 Namespace :
        • 쿠버네티스 클러스터 내의 논리적인 분리 단위
      • 레플리카셋 :
        • Pod의 수가 정해진 개수만큼 존재하도록 죽은 Pod를 재실행하거나 초과한 Pod를 중단시킨다.
    • 쿠버네티스 클러스터 구성요소
      • Control plane (masters)
        • API
        • Control Managers
        • Scheduler
        • cluster DNS
        • etcd : 클러스터의 상태를 저장
      • worker nodes
        • pod : 쿠버네티스의 최소 실행 단위, container의 모음, worker node에서 실행됨
      • Cloud Infrastructure
        • Compute
        • Storage
        • Network
    • 큰 쿠버네티스 클러스터 안에서 Namespace를 쪼개서 Multi-Tenancy를 제공할 것이냐, 여러 개의 작은 쿠버네티스 클러스터를 통해서 Multi-Tenancy를 제공할 것이냐? 
      • One Big Cluster
        • 특징
          • Control Plane을 공유
            • 모두 동일한 쿠버네티스 버전/설정이 적용
            • 모든 Pod가 하나의 cluster DNS를 사용
            • 모든 User가 하나의 Control plane을 공유해서 사용
          • Worker Node를 공유
            • Namespaces로 논리적으로 분리해서 사용
            • container로 성능 할당, 격리
        • 문제점
          • 임의의 worker node에서 어떤 문제로인해 시작하자마자 종료되는 Pod를 배포하는 경우 쿠버네티스는 레플리카 개수를 유지하기 위해 종료된 Pod를 임의의 worker node에서 다시 실행 (무한반복) -> 부하 발생
          • History Limits 설정 없이 CronJob을 걸어둔 경우 해당 Job은 임의의 worker node에서 pod를 생성해 실행되고 완료되면 종료된다. 이때 어떤 Job에 성공했다 혹은 어떤 Pod가 성공했다 라는 log가 etcd에 남게 되는데 매우 오래 누적되면 서서히 부하가 증가하다가 어느 순간 OOM(Out Of Memory)을 발생시키고 마스터 장애를 가져온다.
          • Namespace가 충분한 Isolation을 제공하지 못함. 서로 다른 Namespace의 Pod들이 성능에 영향을 미친다거나, 서로 통신할 수 있어 보안에 문제가 생김
      • Many Small Ones 
        • 특징
          • 각자 개별의 Control Plane(Masters)
          • 각자 개별의 Network
        • 단점
          • 클러스터가 많이 때문에 관리가 어렵다
          • 자원 효율성이 떨어진다. (클러스터 A는 추가 자원이 필요하고 클러스터 B는 자원이 남아도 자원을 넘겨줄 수 없음)
    • Many Small Ones 전략의 단점을 해소하기 위한 KaaS
      • 클러스터 생성/상제, 노드 추가/삭제, 복구, 업데이트 등 클러스터 관리를 자동화해주는 KaaS 플랫폼 제공
      • 100대 이하의 worker node를 가지는 클러스터의 master node를 VM(가상 머신)으로 구성하고 100대가 초과하는 경우 자동으로 PM(물리 머신)으로 구성하여 자원 효율 증가. 
  • KaaS 운영

 

 

Kubernetes 기반 카카오톡 백엔드 배포 및 운영

• 카카오톡 메시징 서비스 소개
  • 이 글을 읽고 있는 사람이라면 누구나 알고있는 카카오톡이다. 친구를 관리하고, 누군가와 채팅을 하며, 채팅방을 관리하는 등의 기능을 포함하는 메시징 서비스이다.
• 카카오톡 메시징 백엔드 서버 배포 in Kubernetes
  • 백엔드 서버를 배포하기 위해서는 먼저 카카오톡 메시지 트래픽을 제어해야 한다. 하지만 쿠버네티스에서는 이러한 트래픽 제어 기능을 지원하지 않기 때문에 개발자가 signalHandler를 구현해 트래픽을 제어해야 한다.
  • 배포 과정(시그널 핸들링 과정)
    • 쿠버네티스에서 배포 대상 서버 프로세스에 SIGTERM을 보내면 해당 서버는 프로세스를 마무리하기 시작한다.
    • 이 때 SIGTERM (을 받은 서버 프로세스를) 서비스에서 제외하여 트래픽이 추가되는 것을 막는다.
    • 이후에 해당 서버 프로세스는 이미 처리중인 트래픽이 일정 수치 이하로 낮아지기를 무한루프를 돌면서 대기한다.
    • 트래픽이 일정 수치 이하로 떨어지면 서버 프로세스를 종료한다.
    • 서버 프로세스가 안전하게 종료되면 새로운 버전의 서버 이미지로 서버 프로세스를 실행하고 다시 트래픽을 받는다. 
• 서비스 디스커버리 (서버 리스트 관리) in Kubernetes
  • 어떤 요청을 처리하는 과정에서 다른 서버에게 해당 요청을 라우팅해야 하는 경우가 있다. 이 때 실행중인 서버에 요청을 보내기 위해서는 IP, Port 등의 연결 정보알아야 한다. 하지만 쿠버네티스의 경우 어떤 서버가 어떤 노드에서 실행되고 있는지 알기 어렵고 서버가 종료되고 재실행되면 바뀔 수 있다. 이런 문제를 해결하기 위해 외부 유틸리티인 zookeeper를 통해 연결 정보를 관리한다.
  • 서버 배포 시에도 서버가 종료되고 재실행 되기 때문에 이러한 서비스 디스커버리를 수행 해야한다.
• redis 운영 use kubernetes
  • redis는 master/slave 구조의 데이터베이스
  • redis sentinel
    • 자신이 관리하는 master/slave의 연결 정보를 받을 수 있음
    • fail over/fail back 이벤트가 발생하면 call back을 받을 수 있음
  • kubernetes의 self-healing을 활용해 master 혹은 slave가 죽으면 자동 복구
  • 서버 프로세스는 Sentinel을 통해 이벤트를 구독하고 master와 slave의 연결 정보를 획득한 후 master와 slave에 연결하여 redis를 사용함
  • master가 죽으면 sentinel은 다른 slave를 마스터로 승격하고 해당 이벤트를 서버로 전송하면 서버는 새로운 master로 연결 정보를 갱신함
  • kubernetes의 self-healing으로 죽었던 master가 살아나면 Sentinel은 slave로 강등시키고 해당 이벤트르 서버로 전송하면 서버는 새로운 slave로 연결 정보를 갱신
  • master/slave들/sentinel은 하나의 그룹으로 묶인다. 이들은 서로 다른 worker node에 띄워야 한 worker node가 죽어도 복구할 수 있다. 이를 위해서 affinity 설정의 topologykey로 하나의 worker node에는 서로 다른 그룹의 master or slave or sentinel 만 뜰 수 있게 설정하여 하나의 그룹에 있는 master or slave or sentinel이 하나의 worker node에서 실행되는 것을 예방할 수 있다.

 

마무리

MA에서의 배포 방법, MA에서 MSA로 넘어가게된 이유, MSA의 문제점을 해결한 컨테이너와 쿠버네티스 기술, 쿠버네티스 클러스터를 구성할 때 생각해야 하는 부분, 실제 카카오톡 서비스에서 사용되는 쿠버네티스 기술을 알 수 있었다.