카카오 자체 개발 하둡 플랫폼, Kakao Hadoop Platform(KHP)

디렉터리의 구조를 보았을 때, 현재 hadoop-x라는 클러스터를 구성하고 있는 상황입니다.

프로젝트 내 가장 상위 디렉터리인 inventories 폴더의 하위 폴더들로는 alpha, prod-hadoop, prod-hbase가 있습니다. 이 각각의 하위 폴더들은 같은 이름을 가진 클러스터들과 매칭됩니다. 쉽게 말하자면, alpha 폴더는 alpha 클러스터에 적용되는 yml 파일들을 가지고 있습니다. 이때, 각 폴더에서 클러스터의 공통되는 설정들은 _default.yml 파일에서 정의하고 있습니다.

이제 alpha 폴더가 가지고 있는 yml을 살펴보면서, yml이 적용되는 방식에 대해서 설명하고자 합니다. alpha 하위 폴더의 yml 중 hadoop-x.yml에 있는 설정값은 _default.yml에서 정의된 설정값이 클러스터에 반영된 후 두 번째로 적용됩니다. 이때, hadoop-x.yml에는 설치할 하둡 컴포넌트들의 다운로드 URL, 데이터 디렉터리 지정, 데몬 메모리 설정, 컴포넌트 별 meta DB 접속 정보 등이 정의되어 있습니다. 또한, hadoop-x.ini 파일에는 역할별 호스트가 정의되어 있습니다.

마지막으로 alpha 폴더 안에 있는 하위 폴더 hadoop-x 폴더에는 custom_group.yml, hadoop-x-8.host.yml 파일이 있습니다. 아까 hadoop-x.ini 파일에 역할별 호스트가 정의되어 있다고 했는데요, hadoop-x 폴더 안의 yml들이 클러스터 내 호스트 그룹 별로 정의되어야 하는 설정값을 갖고 있고, 설정을 읽는 작업이 실행되면 클러스터 별로도 각 yml 파일을 읽어 설정값을 재정의하는 것입니다.

정리하자면 alpha 클러스터의 경우, _default.yml → hadoop-x.yml → custom_group.yml / hadoop-x-8.host.yml 과 같은 적용 순서로 설정을 구성하는 것을 확인할 수 있습니다. 이러한 구조를 사용하면 개별 클러스터 설정에서 불필요한 중복은 최대한 줄일 수 있는 장점이 있습니다. 이와 같이 이번 단원에서는 클러스터 및 그룹/호스트 단위로 설정을 재정의하여 개별 클러스터의 설정을 관리하는 과정을 확인해 보았습니다.   

khp-server: khp-ansible에 정의된 클러스터 설정을 기반으로 시각화

khp-ansible에 정의된 하둡 클러스터들은 khp-server의 Web UI를 사용하여 관리할 수 있습니다.

Web UI에서는 각각의 클러스터 및 하위의 링크(Links)와 분류(Type)를 시각적으로 보여주고 있을 뿐 아니라, 다양한 정보를 포함하는 클러스터의 상태까지도 한 번에 확인할 수 있습니다. 이는 뒤에 모니터링을 설명하는 부분에서 다시 다루도록 하겠습니다.

또한, 다수의 호스트를 관리하다 보면 개별 노드 혹은 서비스별로 특정 작업을 수행해야만 하는 경우가 종종 있습니다. 이는 나중에 어떤 호스트에 어느 부분까지 새로운 설정을 변경하고 적용했는지 혼란을 초래하기도 합니다. 이 경우 아래처럼 Stale configuration을 활용하여 상황을 파악할 수 있습니다.

설치(install)

하둡 클러스터 설치는 khp-ansible을 사용합니다. 빠른 시간 안에 다수의 클러스터를 설치하기 위해 GUI가 아닌 텍스트 기반의 툴만을 활용하여 클러스터의 설정과 설치 및 배포를 진행합니다.   

khp-ansible: 하둡 클러스터 설치

설치하는 데 기본이 되는 인벤토리 설정은 ‘설정 관리’ 장에서 다루었습니다. 이번 장에서는 roles 디렉터리의 하위 구성들을 중점으로 살펴보겠습니다.

위의 그림에서 보이는 것과 같이 roles/hadoop/tasks 디렉터리 아래에 install.yml 파일이 있습니다. 이는 대부분의 컴포넌트가 가지는 공통 작업(task)이며, 클러스터 설치에 필요한 작업들이 정의되어 있습니다. 또한, 전체 설치를 하는 데는 all-install.yml을 사용하고 있습니다.

이때, install.yml 파일을 통한 설치(install) 작업은 멱등성을 가지도록 정의하여 사용합니다. 이러한 특성 덕분에 클러스터의 설치뿐 아니라 설정 파일들을 배포하는 용도로도 install.yml을 활용하고 있습니다.

제어

khp-ansible: 하둡 클러스터 제어(start, stop, restart, …)

설치(install)와 유사하게 시작(start), 중지(stop), 재시작(restart) 또한 대부분의 컴포넌트가 가지고 있는 공통 작업(task)입니다. 마찬가지로 전체 작업 시 all-start.yml, all-stop.yml을 통해 올바른 순서로 간단하게 작업을 진행할 수 있습니다.

제어 과정에서는 start, stop, restart와 같은 작업(task) 외에도, 서비스별로 특정 작업을 추가로 정의해서 사용합니다. 이에 대한 예시로, 위와 같이 hadoop 디렉터리 하위에 작업이 정의된 format-namenode.yml, start-balancer.yml 파일을 나타냈습니다. 이름에서 알 수 있듯이 이는 각각 네임노드(namenode)에 대한 포맷 수행, HDFS 밸런서(Balancer) 수행 역할을 담당합니다.   

khp-server: 호스트 내 프로세스 제어

아래와 같이 khp-server를 통해서도 프로세스에 대한 상태 조회 및 간단한 제어(start/stop, restart)가 가능합니다. 이 방식은 간단히 프로세스를 제어하기 위한 보조적인 수단으로 사용하며, supervisord API를 통해 구현되어 있습니다.

모니터링

khp-agent가 모니터링의 기반이 되는 메트릭을 수집하고 이를 처리한 후 대시보드를 구성하는 역할을 합니다. 이때, khp-server는 대시보드를 웹으로 연결해 모니터링 정보를 쉽게 접근할 수 있도록 하며, 추가로 khp-ansible의 작업 감사(audit)를 수행합니다. 마지막으로 khp-log는 로그를 적재하고 검색할 수 있도록 지원합니다. 덕분에 단순히 메트릭을 기반으로 모니터링을 수행하는 것뿐 아니라, 원하는 로그를 빠르고 쉽게 검색하고 조회할 수 있습니다.

모니터링 내 각각의 역할을 나누어 알아보도록 하겠습니다.   

khp-agent: 메트릭 수집 및 Grafana 대시보드 구성

khp-agent는 호스트와 서비스의 메트릭을 수집하여 메시지로 전송, 처리 후 저장합니다. khp-agent가 어떻게 배포되어 역할을 수행하는지 알아보겠습니다.

khp-agent는 클러스터 내 각각의 호스트에서 개별 프로세스로 동작합니다. 그림 왼쪽 위의 Host OS에 접근하여 가져오는 메트릭 수집은 모든 에이전트가 동일하게 수행하고 있습니다. 또한, 바로 Host OS 옆에 위치한 서비스 메트릭 수집의 경우에는 호스트 별로 배포된 서비스 종류와 특성이 다르므로, 하단의 “Auto detect(자동 감사)” 기능을 활용하여 해당 호스트에 배포된 서비스 설정을 기반으로 메트릭을 수집하게 됩니다.

추가로 khp-agent는 자체 설정을 통해 HTTP, JMX, SHELL 등의 엔드포인트 변경과 필터링 및 파싱 규칙 등을 지원하기 때문에 서비스별로 유연한 사용이 가능하다는 장점이 있습니다. 수집된 데이터는 가장 오른쪽에서 확인할 수 있는 것처럼 필터링, 파싱 과정을 거쳐 카프카에 저장하게 됩니다. 이후 데이터는 Druid Kafka 인덱싱 서비스(Indexing Service)를 통해 Druid로 전달되고, 모니터링 및 알람 등의 기능에서 활용하게 됩니다.   

khp-server: Grafana dashboard 활용, Audit 로깅 및 조회

아래와 같이 그라파나 대시보드(Grafana dashboard)를 임포트하여 클러스터 전체를 간단히 조망하는 페이지를 제공합니다.

이전에 khp-ansible이 클러스터의 설치를 포함한 전반적인 제어를 담당한다고 설명해 드렸었는데요, 이러한 일련의 작업을 누가 언제 수행했고 결과가 어땠는지를 기록하고 있습니다. 즉, 감사(audit)를 위한 로그(log)를 기록하고 있습니다.

또한 이 로그를 목적에 맞게 잘 사용할 수 있도록 Cluster, User, Result의 정보를 이용한 필터링 기능을 제공합니다.

khp-log: 로그 수집, 검색 서비스 제공

이번엔 로그 서비스인 khp-log를 살펴보겠습니다. khp-log는 서비스 로그 분석 시, 빠른 검색을 위한 수집과 처리 서비스를 제공하는데요, 이 기능의 경우 대표적인 로그 관리 오픈소스들을 적극적으로 활용하여 구현했습니다. 로그의 수집 과정에는 파일비트(Filebeat)를 사용하고, 카프카(Kafka)로 로그 데이터를 보냅니다. 이후, 로그스태시(Logstash)를 거쳐 데이터 처리를 진행하고 결과를 엘라스틱서치(Elasticsearch)에 저장합니다. 마지막으로 키바나(Kibana)를 통해 필요한 데이터를 쉽게 검색할 수 있습니다.

또한, khp-log에는 KHP에서 지원하는 모든 서비스 및 JVM GC 로그 들에 대한 처리가 가능하도록 준비되어 있습니다. 이와 유사하게, Kibana에서도 일반적인 서비스 로그 필터링 외에, JVM GC를 위한 대시보드를 추가로 구성하여 운영상의 문제를 해결하는 데 활용하고 있습니다.

마지막으로 사내 공용 하둡에서 사용하는 컴포넌트들인 Zookeeper, Hadoop(NameNode, NodeManager, ResourceManager, Timeline Server), Hive(HiveServer2)의 경우에도 서비스 로그 검색을 지원하고 있습니다.   

알람

khp-agent: 알람의 대상이 되는 메트릭을 수집

모니터링에서 다룬 메트릭 수집의 내용과 동일합니다. 위에서 언급했던 것처럼 khp-agent가 Druid에 저장한 데이터를 모니터링 및 알람의 용도로 활용하고 있습니다.   

khp-server: 메트릭을 폴링하여 알람 생성

알람의 히스토리를 조회하고 필터링할 수 있는 기능을 UI로 제공합니다. 이때, Ansible을 통해 배포된 임계값(threshold) 설정에 따라 알람을 생성하고 알람을 받을 기준을 변경할 수 있습니다. 아래의 목록을 살펴보면, ‘Too many dead datanode 비율이 5% 넘었다’, ‘missing block이 발생했다’와 같은 과거의 정보들을 khp-server에서 제공하는 것을 알 수 있습니다.

추가로, 알람이 발생하면 이를 카카오톡 혹은 카카오워크 메신저로 메시지를 발송하도록 설정할 수 있습니다. 아래는 실제 발생한 Warning 알람을 카카오워크를 통해 수신한 예시입니다.

업그레이드

khp-ansible: 하둡 컴포넌트 패치 업그레이드

메타데이터의 구조 변경이 없다면 바이너리 교체를 통해 하둡 컴포넌트의 패치 버전 업그레이드가 가능합니다. 이 경우, 새로운 버전을 설치하기 위해 파일에 정의된 바이너리 URL을 변경하고 install, restart를 수행하면 됩니다. 이때, 클러스터 노드에 바이너리 URL을 배포 및 설치하는 과정에서 심볼릭 링크를 사용하기 때문에 패치 배포 후 기능에 문제가 생긴다면 다시 손쉽게 기존 버전으로 롤백할 수 있습니다.

예로 들면, 하둡 업그레이드를 진행할 시 아래와 같이 다운로드 URL를 변경하여 배포를 수행하면 됩니다. 배포 후 클러스터 서버에서의 링크 변경이 아래와 같이 일어납니다. 이후 각각의 데몬을 재시작하면, 바이너리 교체를 성공적으로 적용할 수 있습니다.

• 다운로드 URL 변경
  
  • 변경 전: hadoop_url: http://khp-fileserver/hadoop-2.10.0-khp-20220307.tar.gz
  • 변경 후: hadoop_url: http://khp-fileserver/hadoop-2.10.0-khp-20210809.tar.gz
• 링크 변경
  
  • 변경 전: /opt/khp/hadoop -> /opt/khp/package/hadoop-2.10.0-khp-20220307
  • 변경 후: /opt/khp/hadoop -> /opt/khp/package/hadoop-2.10.0-khp-20210809

마이그레이션

해당 장에서 마이그레이션의 정의는 ‘기존 솔루션’을 사용한 하둡 클러스터에서, KHP로 새롭게 구성한 하둡 클러스터로 전환하는 것을 의미합니다.

가장 일반적인 마이그레이션의 방법으로는 클러스터를 새롭게 구성하고 기존 클러스터로부터 잡(Job)과 데이터를 순차적으로 이동하는 것입니다. 카카오에서도 규모가 크고 다양한 용도로 사용되는 클러스터의 경우, 이 순차 이동 방식을 통해 마이그레이션을 진행하였습니다. 또한, HBase 클러스터의 경우, 새롭게 클러스터를 구성한 뒤 양방향 replication을 걸어서 안정적으로 마이그레이션을 진행했습니다.

KHP의 구성요소를 알아보는 내용이니만큼 일반적인 마이그레이션에 대한 이야기보다는 khp-ansible을 통해 지원했던 마이그레이션 방법을 소개하고자 합니다.  

khp-ansible: In-place 마이그레이션

In-place 마이그레이션이란 기존 솔루션이 설치된 머신을 그대로 활용하여 새로운 클러스터로 마이그레이션 하는 것을 의미합니다. 설치된 머신을 그대로 활용하기에 물리적인 데이터 복사가 일어나지 않고, 별도의 장비가 필요하지 않아 빠르고 저렴한 비용으로 마이그레이션이 가능하다는 장점이 있습니다. khp-ansible은 다음과 같은 2가지 형태로 In-place 마이그레이션 기능을 지원합니다.

• 바이너리 교체를 통한 마이그레이션
• HDFS 롤링 업그레이드

먼저 “바이너리 교체를 통한 마이그레이션”을 살펴보겠습니다. 이 방식은 기존 하둡과 동일한 layout version의 릴리즈를 활용함으로써 바이너리만 교체하는 마이그레이션입니다. HDFS로 설명하자면 데이터노드(Datanode)가 데이터를 디스크에 저장하는 형태인 블록 파일을 건드리지 않고 그대로 사용하기 위해 동일한 설정으로 KHP 관리 기반의 하둡 바이너리를 배포한다는 뜻입니다. 그러므로, HDFS의 파일 layout version을 반드시 확인해야 하며, 동일한 layout version을 가지는 하둡 배포판을 사용해야만 합니다. 새로 띄운 프로세스에 문제가 있는 경우에도 기존 데이터를 건드리지 않았으므로 이전 버전으로 롤백이 가능한 장점을 가지고 있습니다.

두 번째로, “HDFS 롤링 업그레이드”입니다. 이는 하둡에서 지원하는 기본 기능이며, 이를 활용하여 KHP의 요건에 맞도록 Playbook을 구현했습니다. 이 방식은 상위 아파치(Apache) 버전을 도입해야 할 때 고려할 수 있는 마이그레이션 방식입니다. 다만, HDFS의 데이터 layout version까지도 함께 업그레이드 대상이 되기 때문에 작업이 잘못될 경우 이전 버전으로 롤백 하는 데 제약이 있습니다.

그렇기에 HDFS의 버전 업그레이드가 필요하지 않다면 첫 번째 옵션을 선택하는 것이 안전합니다. 저희 카카오에서는 “바이너리 교체를 통한 마이그레이션”을 일부 HBase 클러스터를 마이그레이션 하는데 적용하여, 시간과 비용을 크게 절약할 수 있었습니다.  

마무리

지금까지 KHP의 정의와 그 구성 요소 및 기능들에 대해서 간략하게 알아보는 시간을 가졌습니다. 기술 블로그를 통해 KHP를 처음 소개하는 자리이기도 한 만큼, 너무 심도 있는 내용보다는 카카오 내에서 사용하는 KHP를 어떻게 구성했는지에 대한 기술 전반의 흐름에 초점을 맞추어 설명해 드렸습니다.

KHP에 관한 생생한 이야기가 궁금하시다면 “2022 if Kakao 발표(https://if.kakao.com/2022/session/62)”를 통해 영상으로 확인해 보실 수 있습니다.

또한, KHP 소개만으로는 아쉬워하실 분들을 위해, 관련 내용을 다음 블로그 글(KHP 하둡 배포판 릴리즈 관리하기)에 연계해 작성하려고 합니다. 함께 읽어보시면 도움이 되실 것입니다.

감사합니다.