Categories
컴퓨터

if (kakao) dev 2019 (2) – 카카오에서 컨테이너를 사용하는 방법

어제 봤던 if (kakao) dev 2019 (1) – 카카오뱅크 모바일앱 DevOps 포스팅에 이어지는 포스트다. 오늘 저녁에 본 영상은 카카오에서 컨테이너를 사용하는 방법이다.

영상을 소개하기 전에 VM과 컨테이너에 대해 간단히 살펴보자. 하드웨어를 가상화하는 가상머신(Virtual Machine, VM)은 기술 수용 속도가 매우 더딘 공공기관에서도 많이 사용할 정도로 이미 널리 활용되고 있다. 반면에 OS를 가상화하는 컨테이너(Container)는 적어도 내가 재직중인 기관에서는 아직 고려조차 하고 있지 않다. 약 반 년 전에 중소기업 솔루션 영업 담당자에게 레퍼런스를 문의했을 때, ‘컨테이너에서 구동 가능하도록 솔루션 개발이 되어 있지만 도입한 곳은 없다’는 답변을 듣기도 했다.

VM 과 컨테이너 비교
VM 과 컨테이너 비교

카카오에서는 국민 메신저앱 카카오톡(KakaoTalk), 한국 인터넷 포탈의 두 번째 대장인 다음(Daum), 음악 스트리밍 서비스 멜론(Melon) 등 대부분의 서비스가 컨테이너로 동작하고 있다. 즉, 컨테이너를 통한 안정적인 서비스 제공은 이미 입증된 거나 다름이 없다고 이해하면 된다. 참고로 카카오의 클라우드 플랫폼은 오픈스택(OpenStack)을 기반으로 운영되고 있다.

컨테이너 기반 카카오 서비스 목록
컨테이너 기반 카카오 서비스 목록

컨테이너 기술을 검색해보면 컨테이너 구현체인 도커(Docker)와 다수의 컨테이너를 관리하는 쿠버네티스(Kubernetes)를 만나게 되는데 실제로 이 두 가지 도구만으로는 안정적인 컨테이너 운영이 불가하다고 한다. 카카오는 서비스 모니터링을 위해 추가 도구를 쓰고 있는데, Metric 수집을 위해서는 Prometheus, Grafana를 Log 수집을 위해서는 Fluentd와 ElasticSearch를 활용하는데 각각의 서버 로그를 중앙서버에 수집한 후 분석한다.

프로메테우스(Prometheus)시계열 데이터를 처리하는 것이 주 목적인 Time-series DB이다. 프로메테우스는 주로 CPU, 메모리 사용량과 같은 Metrics 데이터에 대한 APM 구축을 목적으로 한다. 참고로 그리스 신화에서 인간에게 불을 선물하여 영원한 벌을 받는 신이 바로 여기 나오는 프로메테우스(Prometheus)이다.

그라파나(Grafana)는 오픈소스 시각화 도구다. 어떤 블로그를 살펴보니 ELK(Elastic Search + LogStash + Kibana) 스택의 시각화 도구인 Kibana는 Time-series DB와 함께 쓰기 어렵다고 한다. 그래서 Grafana를 함께 쓰는 게 아닐까 싶다.

컨테이너 오케스트레이터는 모니터링을 안해줘요
컨테이너 오케스트레이터는 모니터링을 안해줘요

강의 내용 중 카카오 인프라 구성의 내부 표준을 간간히 들을 수 있었다. 아래 그림의 Load Balancer는 항상 물리 서버를 사용한다고 한다.

카카오 인프라 표준 중 하나: Load Balancer는 물리 서버
카카오 인프라 표준 중 하나: Load Balancer는 물리 서버

참고로 가상 머신(Virtual Machine, VM)을 쓰면 클러스터 생성 자동화자원 사용 효율화를 꾀할 수 있다. 대부분의 서버는 24시간 바쁜 게 아니라 특정 시간대에 바쁘기 때문이다. 그렇다면 어떤 서버를 물리 서버로 선택해야 할까? 항상 사용률이 높은 서버간섭 현상을 피하기 위해 전용 서버, 즉 물리 서버(Physical Machine)로 구축하는 게 좋다.

가상 서버와 물리 서버
가상 서버와 물리 서버

잠시 이야기가 옆으로 세었다. 카카오는 소프트웨어 회사이다 보니 필요한 도구는 직접 만들어서 사용한다. 아래는 카카오에서 컨테이너 운영을 효율적으로 하기 위해 만든 도구다. 물론 처음부터(from scratch) 만드는 건 아니고 기존의 오픈 소스를 기반으로 기능을 추가했을 것으로 생각된다.

카카오가 개발해서 사용하는 컨테이너 도구
카카오가 개발해서 사용하는 컨테이너 도구

발표 중 언급된 내용으로 Container Registry인 D2hub는 운영 5년차로 전체 용량이 약 80TB 정도 된다고 한다. 또한 Container Orchestrator인 DKOS에는 클러스터가 약 1,500개, 노드가 16,000개, 컨테이너는 75,000개가 운영중이다. 또한 Helm Chart Registry인 K2Hub에는 운영한지 얼마 되지 않아서 Chart는 수십개, Usage는 800여개 된다고 한다.

참고로 D2Hub은 오픈소스로 공개되어 있으며 주소는 아래와 같다. 곧 TOEFL 시험을 봐야 하기 때문에 그 이후에 살펴봐야겠다.

부러웠던 내용 중 하나는 카카오에서 일하는 리눅스 장인들이 CentOS 이미지를 카카오 서버에 맞도록 사전에 튜닝하여 이미지를 제공한다는 내용이었다. 나도 장인처럼 무언가를 세밀하게 깎는 일을 좋아하기 때문에 저렇게 리눅스 배포판을 만지고 놀 수 있으면 좋겠다는 생각이 들었다. 커널 2.4 시절, 16MB 크기의 Disk On Module(DOM)에 올라가는 임베디드 리눅스를 만들기도 했었고, 어렸을 때부터 리눅스를 만져봤으니 그래도 필요한 자료를 찾으며 학습할 능력이 충분히 된다.

그리고 기존 배포판(여기서는 CentOS)을 카카오 표준에 맞게 이미지로 만들어서 배포하는 것처럼, 재직중인 곳에서도 사전에 표준 OS 이미지를 만들어 놓으면 매번 OS 설치 후 수작업으로 보안 설정 및 계정 생성을 하지 않아도 되기 때문에 업무에 실수가 줄어들고 효율이 좋아져서 결국에는 삶이 편해질 수 있을 거다. 그리고 무엇보다 전용 이미지가 있으면 좀 더 있어 보인다.

눈치 챙겨
눈치 챙겨

발표 마무리에 발표자는 대놓고 말하지는 않았지만, 운영의 어려움을 어느 정도 토로한 것으로 보인다. 끊임없이 챙겨야 할 게 생기기 때문에 관리자 입장에서는 어느 정도 업무 난이도가 있는 것으로 보인다. 그러나 포방동 돈까스좌의 말처럼 내가 피곤해야 내가 만든 서비스를 사용하는 사람들이 편해진다는 건 어떻게 보면 진리다.

포방터 돈까스좌 명언
포방터 돈까스좌 명언
포방터 돈까스좌 명언
포방터 돈까스좌 명언
포방터 돈까스좌 명언

이번 if (kakao) dev 2019 동영상 혼자보기는 여기서 마친다. 이번 편은 컨테이너와 오케스트레이션 솔루션을 제대로 사용해보지 않은 나에게는 쉽지 않았다. 온라인에 좋은 자료가 많으니 조만간 실습을 해봐야겠다.

이번 영상의 발표자료는 여기(링크)를 클릭하면 받을 수 있다. 그리고 카카오에서 컨테이너를 사용하는 방법의 영상은 여기(링크)를 클릭하면 바로 볼 수 있다.

다음에 볼 영상은 카카오톡 적용 사례를 통해 살펴보는 카카오 클라우드의 Kubernetes as a Service 이다.

Hits: 1640

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다