Kakao Hadoop Platform (KHP)

카카오에서 자체 개발한 하둡 솔루션인 Kakao Hadoop Platform, KHP를 소개합니다.

하둡이 무엇인지 궁금하시다면 아래 링크를 통해 “하둡엔지니어링파트” 를 확인해보세요.
https://tech.kakao.com/2022/10/21/data-platform-engineering/

하둡을 사용하기 위해서는 에코시스템 내 다양한 하둡 컴포넌트들의 호환성을 검증하고, 이를 배포 및 운영 관리하는 도구가 필요합니다. 하둡을 운영 환경에서 사용해 보신 분들이라면 이는 선택이 아닌 필수라는 데에 공감대가 있으실 것으로 생각합니다. 카카오의 경우에도 사내 하둡의 운영을 외부 벤더사의 솔루션을 사용하여 대규모 클러스터로 운영하고 있었는데요, 그렇다 보니 다음과 같은 문제점을 마주하게 되었습니다.

첫째는 “새로운 기능 적용 어려움”이었습니다. 외부 벤더사의 솔루션을 사용하다 보니 기능의 변경이 불가능하거나 어려웠기 때문에 원활한 운영을 위한 추가 서비스의 개발이 필요하기도 했으며, 하둡 배포판 내 컴포넌트를 활용하는 데에서도 적극적인 버전 관리가 어려웠습니다.

둘째는 "늘어나는 운영 비용"이었습니다. 점점 늘어나는 데이터 처리 규모에 따라서 서버 비용뿐 아니라 상용 솔루션 비용도 증가할 수밖에 없었습니다. 특히나 2019년은 하둡 솔루션의 비용 리스크가 크게 화두가 된 시기이기도 했죠.

이를 해결하기 위해 카카오가 직접 개발하고 운영하기 시작한 것이 바로 KHP입니다.

KHP 기능

KHP는 5가지 구성 요소인 배포판(khp-package) , 배포툴(khp-ansible), 에이전트(khp-agent), 관리 서버(khpserer), 로그 서비스(khp-log)로 관리되고 있으며, 각각의 구성 요소들이 어떠한 역할을 맡고 있는지 간략히 나타내면 아래와 같습니다.

이 글에서는 개별 구성 요소의 프로젝트명을 그대로 사용하여 khp-xxx 형태로 표기하도록 하겠습니다.

	배포판 khp-package	배포툴 khp-ansible	에이전트 khp-agent	관리서버 khp-server	로그 서비스 khp-log
배포판 관리	✔️
설정 관리		✔️		✔️
설치		✔️
제어 (start, stop, …)		✔️		✔️
모니터링			✔️	✔️	✔️
알람			✔️	✔️
업그레이드		✔️
마이그레이션		✔️

기능을 따라가면서 각각의 구성 요소들이 어떤 역할을 수행하고 있는지 하나씩 알아보도록 하겠습니다.

배포판 관리

사용 가능한 하둡 컴포넌트들의 버전을 확인하고 호환성을 검증합니다. 그리고 관련 코드를 수정하여 운영이 가능한 배포판을 완성합니다. 이는 khp-package를 통해 진행합니다.

khp-package: 하둡 컴포넌트들에 대한 검증, 배포 및 릴리즈 수행

KHP를 통해, 설치하는 하둡 컴포넌트(Hadoop, Hive, Spark, …)들의 코드 관리와 빌드 및 검증을 수행합니다.

KHP가 검증하고 빌드 프로세스를 관리하는 하둡 컴포넌트들은 모두, khp-package 프로젝트에 서브모듈(submodule)로서 연결되어 있습니다. 각각의 컴포넌트들은 모두 오픈소스 프로젝트의 업스트림 릴리즈 버전에 기반하고 있습니다. 그렇기 때문에, 컴포넌트들의 상호 호환성 및 안정성을 보장하기 위해 변경사항이 생기면 커밋을 추가하고 별도로 빌드한 배포판을 사용합니다.

포함된 컴포넌트

Anaconda
Druid
Hadoop
HBase
Hive Hue
Oozie
Ranger
Spark
Sqoop
Tez Trino
Zookeeper

khp-package 내 작업 과정을 간단히 도식화하면 아래와 같습니다.

새로운 변경사항이 생기면 이를 검증하기 위해 오픈소스 내 유닛 테스트와 별도의 통합 테스트 프로세스를 수행합니다. 통합 테스트는 주로 CLI 커맨드를 통해 수행하며, 컴포넌트 버전 변경에 따른 영향을 최소화하기 위해 스크립트의 형태로 정의되어 있습니다.

통합 테스트는 이미 설치된 라이브 클러스터(live cluster)를 대상으로도 수행됩니다. 라이브 클러스터란 운영 환경과 동일한 조건의 물리 서버에 설치된 서버로, 통합 테스트를 진행할 때 사용합니다. 이 과정에서 기본 기능의 검증 및 하둡 컴포넌트 간 상호 호환성 검증 테스트를 수행하여 변경사항 적용 시 클러스터의 정상 동작 여부를 검증합니다.

테스트를 전부 통과하여 검증이 완료되면 변경사항에 대해 빌드 과정을 거쳐 쉽게 설치가 가능한 패키지를 tar.gz의 형태로 생성하고 파일서버에 이를 배포합니다.

마지막으로 컴포넌트 버전별 다운로드 URL을 정리한 yml 파일과 새롭게 변경된 내용을 정리하여 마크다운(md) 파일을 만들고 공개하는 것으로 릴리즈를 마무리 짓고 있습니다. 예를 들면 다음과 같습니다. 1.1.6-hadoop2.yml, 1.1.6-hadoop. md.

설정 관리

하둡 에코 시스템을 구성하기 위해서 다양한 컴포넌트를 사용할 때, 위에서 확인한 것처럼 코드 수준에서의 호환성 검토도 중요하지만 하둡을 적절하게 설정하는 것 또한 마찬가지로 중요합니다. 대부분의 하둡 설정의 변경은 컴포넌트 코드를 최대한 건드리지 않고 배포툴 프로젝트인 khp-ansible 내에서 처리하고 있습니다. 그리고 khp-ansible 내에 정의된 설정 정보는 khp-server의 Web UI에서 시각적으로 확인할 수 있습니다.

khp-ansibe과 khp-server가 각각 설정 관리를 위해 수행하고 있는 역할을 나누어 알아보도록 하겠습니다.

khp-ansible: 하둡 기본 설정 및 규칙을 정의하고, 클러스터별 설정 재정의

khp-ansible은 Ansible을 사용하여 클러스터를 배포하고 전반적인 제어를 수행합니다. 그렇기에 우선 Ansible에 대한 소개를 간략하게 드리겠습니다.

Ansible은 프로비저닝, 구성 관리, 애플리케이션 배포, 오케스트레이션 및 다양한 수동 IT 프로세스를 자동화하는 오픈소스기반의 자동화 툴입니다. 프로세스를 자동으로 관리하기 위해 다음의 2가지 파일을 사용합니다.

Playbook (.yml): 어떤 작업을 수행할 것인지 정의하는 파일입니다. 예를 들어 khp-ansible에서는 하둡의 설치 과정을 roles/hadoop/tasks/install.yml 에 Ansible Playbook 형태로 정의하고 있습니다.
Inventory(.ini): 어떤 호스트를 대상으로 Playbook을 실행할 것인지 그룹을 지정하는 파일입니다.

Ansible에 대한 자세한 정보는 아래의 링크를 통해 찾아보실 수 있습니다.
https://www.redhat.com/ko/technologies/management/ansible/what-is-ansible

다시 khp-ansible에 대한 설명으로 돌아와서 Ansible을 어떻게 활용하고 있는지에 대해 설명드리도록 하겠습니다.

하둡 클러스터는 내부에서 사용하는 컴포넌트에 따라 서로 영향을 주는 설정들이 존재합니다. 이러한 설정의 기본 값과 규칙을 확인하여 Ansible Playbook과 Jinja template 파일로 값을 정의합니다. 이후, 클러스터 배포 시, 이렇게 잘 정의된 값들을 참조하여 클러스터 내부 설정을 변경합니다.

아래의 Jinja 파일(hdfs-site.xml.j2)의 코드 일부를 예로 들어보겠습니다. 이 경우, 어떤 호스트를 사용하느냐에 따라 설정값을 변경해야 합니다. 아래와 같이, 호스트 중에서도 데이터노드(datanode)인 경우에 실행될 조건문을 추가하여, 배포 시 클러스터에서 호스트별 기본 설정값이 변경될 수 있도록 할 수 있습니다.

{% if 'datanode' in group_names %}
    
        dfs.datanode.address
        {{ inventory_hostname }}:{{ ports.datanode.data }}
    
    ...
{% endif %}

또한 간단한 규칙을 조건문 없이 설정하고자 하는 경우, 아래와 같이 적용하기도 합니다.


    dfs.datanode.handler.count
    {{ hdfs_dn_dirs | length * 4 }}

그렇다면 복잡할 수 있는 개별 클러스터의 설정들은 어떻게 khp-ansible를 사용하여 관리할까요? 먼저 아래의 khp-ansible의 디렉터리 구조를 보시겠습니다.

디렉터리의 구조를 보았을 때, 현재 _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 하둡 배포판 릴리즈 관리하기)에 연계해 작성하려고 합니다. 함께 읽어보시면 도움이 되실 것입니다.

감사합니다.

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