들어가기 전에

카카오 하둡 플랫폼(Kakao Hadoop Platform, 이하 KHP)는 카카오 자체 개발 하둡 플랫폼입니다.

카카오 하둡 플랫폼에 대한 전체적인 소개는 다음 링크의 글(카카오 자체 개발 하둡 플랫폼 KHP)에서 확인하실 수 있습니다:

KHP는 오픈 소스인 하둡 컴포넌트들을 어떻게 릴리즈(관리)하는가

이번 글에서는 KHP가 오픈 소스 하둡 컴포넌트들을 어떻게 관리하고 릴리즈하고 있는지 소개합니다.

KHP를 구성하는 주요 구성 요소 중에는 khp-package가 있습니다. 이 khp-package의 역할과, 오픈 소스인 하둡 컴포넌트에 대해서 설명하고, 이 하둡 컴포넌트들 사이에서 발생하는 변경을 추적하고 호환성을 관리하는 방법 및 이 과정에서 저희가 겪었던 경험을 공유해 보고자 합니다.

KHP 배포판 릴리즈 이해하기

하둡 배포판

Q. 하둡 플랫폼을 구성하는데 있어서 가장 먼저 고려해야하는 것이 뭘까요? A. 하둡 컴포넌트 호환성이라고 생각합니다.

하둡 컴포넌트들은 제각기 다양한 버전이 존재합니다. 버전에 따라 의존성도 제각각입니다. 아무 하둡 컴포넌트나 골라서 설치한다면 개별 설치는 가능할지 몰라도 이를 통합하여 사용하기는 어렵습니다. 컴포넌트 간 호환성 문제가 발생하게 되면 전체 하둡 배포판의 원활한 사용이 어려워집니다. 문제에 따라서는 사용이 불가능한 경우도 있습니다. 그렇기에 하둡 배포판은 호환성 검증이 완료된 하둡 컴포넌트 묶음을 제안할 수 있어야 합니다.

하둡 배포판 릴리즈

하둡 배포판의 컴포넌트 묶음 단위를 버저닝한 것을 릴리즈라고 합니다. 잘 알려진 외부 벤더사 배포판 릴리즈에는 HDP x.y.z, CDH x.y.z가 있습니다.

KHP 배포판 릴리즈

KHP도 위의 하둡 배포판 릴리즈 정책을 따르고 있습니다. KHP가 배포판 릴리즈를 어떻게 준비하고 관리하고 있는지를 알아보겠습니다.

khp-package

khp-package는 KHP의 구성요소 중 하나입니다. KHP는 배포판 릴리즈 프로세스를 정의하고, 이 프로세스를 따르도록 지원하는 도구입니다. KHP에서 배포가 발생하면 이를 검증하고, 릴리즈 하며 배포판을 관리합니다. khp-package에는 하둡 컴포넌트에 대한 커밋 단위의 포인터 관리, 검증을 위한 테스트 절차 및 배포, 릴리즈에 대한 자동화 스크립트가 포함되어 있습니다.

Apache Bigtop과 비교

하둡 컴포넌트를 검증하고 패키징하는 오픈 소스 중에서, 많이 알려진 오픈 소스로는 Apache Bigtop(또는 줄여서 Bigtop)이 있습니다. 저희도 가장 먼저 Bigtop을 살펴보며 활용 여부를 고민했으나, 결국은 자체 개발을 결정했습니다. 이유는 다음과 같습니다.

Bigtop 프로젝트는 하둡 컴포넌트들의 버전에 대한 컴파일 의존성이 있습니다. 그렇기 때문에 테스트 코드가 컴포넌트 버전의 영향을 많이 받는 문제가 있었습니다.
- KHP에서 사용하고자 하는 컴포넌트 버전들을 Bigtop에 적용해 보았을 때, 컴파일 의존성 때문에 변경해야 하는 부분이 많았습니다. 변경점이 많다는 것은 곧 작업 시간이 증가하는 것이고, 때문에 시간 단축의 장점을 누릴 수 없었습니다. 또한, 이후 컴포넌트 버전이 변경되더라도 테스트 코드 및 검증 툴의 변경을 최소화하는 방향으로 검증 방법을 구상하고 있었는데 이에 적합하지 않았습니다.
Bigtop의 테스트 범위가 부족하다고 느꼈습니다.

종합적으로, 기존 프로젝트를 활용하여 얻을 수 있는 이점이 생각만큼 크지 않았습니다. 그래서 단점을 보완하는 방향으로 khp-package를 설계하고 개발했습니다.

khp-package 내에 포함된 통합 테스트 코드들은, 휴(Hue)를 제외하고는 컴파일 의존성이 거의 없습니다. 버전 영향이 가장 적은 CLI를 테스트 인터페이스로 주로 활용하기 때문입니다. 물론 통합 테스트 환경에 버전에 맞는 하둡 클라이언트를 설치해야 하지만 테스트 코드들은 대부분 Shell 내 CLI를 통해 실행하므로 버전 업그레이드의 영향을 거의 받지 않습니다. 하둡 컴포넌트들이 CLI에 대한 하위 호환성을 대부분 철저히 지키기 때문입니다.

물론, 부족하다고 느끼는 부분이 생길 때마다 통합 테스트를 늘려나가며 운영을 관리하고 단점을 보완하고 있습니다. 또한, 카카오 인프라 환경에 맞춰서 우리가 원하는 기능만을 갖춘 검증 툴과 절차를 개발하고 운영함으로써 더욱 빠르고 안정적으로 릴리즈를 지원하는데 크게 기여하고자 노력하고 있습니다.

khp-package 배포판 릴리즈 절차

구체적으로 khp-package를 통해 검증 및 릴리즈 절차를 어떻게 수행하는지 간단히 도식화하면 다음과 같습니다. 그림은 왼쪽 아래부터 흰색 화살표 방향으로 보면 됩니다. 변경, 유닛 테스트, 통합 테스트, 패키지, 배포, 릴리즈로 이어지는 절차를 다음 장에서 자세히 다루겠습니다.

하둡 배포판 릴리즈 관리하기 (feat. khp- package)

하둡 컴포넌트에 변경이 일어나고 이를 릴리즈에 반영하기까지 작업이 진행되는 시간 순서대로 릴리즈 상세 과정을 설명하도록 하겠습니다.

하둡 컴포넌트 내 코드 변경이 일어납니다

오픈 소스 빌드 산출물을 그대로 사용할 수 있다면 가장 좋습니다. 그러나 특정 상황에 맞는 요구사항을 맞춰가다 보면 오픈 소스를 다양하게 변경하거나 새롭게 빌드를 수행할 순간이 있습니다. 이런 변경을 최대한 적은 비용으로 안전하게 적용하는 것이 주요 목표입니다.

하둡 컴포넌트 내 코드 변경

프로젝트의 방향성을 맞춰나가기 위해, 모든 변경은 먼저 지라를 확인해 같은 기능 또는 비슷한 이슈가 있는지 확인합니다. 방향성을 맞추는 것은 중요한 일이기 때문입니다. 되도록이면 카카오에만 해당하는 변경 건이더라도, 일반화하여 업스트림(upstream)에 반영시킬 수 있는지 확인합니다. 업스트림과 달라지면 달라질수록 유지 보수하기가 점점 어려워지기 때문입니다.

이 같은 내용들을 고려하여 신중하게 커밋을 리뷰하고 KHP 브랜치에 머지합니다.

브랜치명은 업스트림 릴리즈를 기반으로 만들어서 따로 관리하고 있습니다. 하둡을 예를 들면 다음과 같습니다. branch-2.10.0-kakao

khp-package에서 하둡 컴포넌트의 코드 변경을 추적

khp-package는 관련 하둡 컴포넌트 리포지토리들을 서브모듈(submodule)로 포함하고 있습니다.

이런 구성에서 얻을 수 있는 장점은 크게 두가지가 있습니다.

컴포넌트 추적이 편함
버전을 모아서 릴리즈하기 용이함

예를 들어, khp-package에서 검증 중인 버전을 체크아웃하고 서브모듈 업데이트까지만 실행하면 스크립트를 실행할 준비가 끝납니다.

단점은 khp-package가 포함하는 리포지토리의 범위와 크기가 커질수록 깃 커맨드의 반응 속도가 점점 느려지는 것입니다. 서브모듈 업데이트가 깃을 클론하는 과정이기에, 느려지는 것은 어쩔 수 없습니다. 일회성에 불과하지만, 모든 컴포넌트의 diff까지 계산하느라 git status가 느려지는 것은 사용성이 너무 떨어지기에 각 서브모듈의 ignore 수준을 dirty로 관리합니다.

# .gitmodules 발췌
[submodule "repositories/hadoopeng/hadoop"]
  path = repositories/hadoopeng/hadoop
  url = https://xxx/hadoopeng/hadoop
  ignore = dirty
...

새로운 변경에 대해 유닛 테스트로 기본 검증합니다

유닛 테스트는 다음과 같은 순서로 진행합니다.

변경에 직접 관여한 유닛 테스트를 제일 먼저 개발 및 검증
영향을 받는 전체 범위에 유닛 테스트를 재수행

하둡 컴포넌트의 테스트 및 빌드를 수행하는 2개의 리눅스(Linux) 서버를 각각 운영하고 있습니다.

쿠버네티스(Kubernetes)나 도커(Docker)를 활용하여 유닛 테스트 환경을 구축하는 시도도 있었습니다. 그러나 컴포넌트의 테스트와 빌드 과정에서 OS 수준의 라이브러리 및 네트워크 설정의 영향을 받았기 때문에, 이를 해결하고자 실제 운영 환경과 동일한 서버 타입인 리눅스 기반 물리 서버를 사용하고 있습니다.

오픈 소스에 포함된 유닛 테스트 자체에 버그가 있는 경우도 종종 있습니다. 이런 경우에는 추가 대응이 필요합니다. 그렇기 때문에, 업스트림에서 직접 코드를 수정해서 빌드하고자 한다면, 빌드 검증에 사용할 유닛 테스트에 버그가 없는지를 먼저 검증하는 게 좋습니다.

khp-package: rake test

컴포넌트별로 유닛 테스트를 수행하기 위한 환경 준비가 필요합니다. 앞서 설명한 것처럼 공통 환경은 빌드 서버에 미리 구축해뒀기 때문에, 개별 컴포넌트들을 위한 환경은 스크립트 내에서 따로 확인하고 준비합니다. test라는 rake task는 verify와 prepare라는 task에 의존성을 가지고 있습니다. 그래서 test를 실행하게 되면 verify와 prepare가 먼저 실행된 뒤 test가 실행됩니다.

Rake는 무엇인가요? Ruby로 task와 작업 의존성을 정의할 수 있는 Make와 비슷한 역할을 하는 프로그램입니다. Make의 Ruby 버전이라고 이해하면 편합니다. Rakefile을 통해 작업을 정의합니다. 위에서는 test, verify, prepare라는 Rake task를 설명하고 있습니다.
하둡을 예로 들면, verify 과정에서 자바(Java), 메이븐(maven), 프로토콜 버퍼(protocol buffer)의 설치 여부를 확인하고 prepare에서는 테스트 수행을 위한 Java option과 language를 설정합니다. 마지막으로 메이븐(mvn) 명령어를 실행하여 두 과정을 포함하는 test를 수행합니다. Rake 공식문서 다음 링크에서 rake의 공식문서를 확인할 수 있습니다.
https://ruby.github.io/rake

task :verify do
  @env.check %i[java maven] 
  @env.check_sh 'protoc --version'
end
task :prepare do
  ENV['JAVA_TOOL_OPTIONS'] = @proxy.java_flag 
  ENV['LANG'] = 'en_US.UTF-8'
  ENV['LC_ALL'] = 'en_US.UTF-8'
end
desc 'run the unit tests'
task test: %w[verify prepare] do
  ...
end

라이브 클러스터로 설치한 후 사용 시 호환성 검증을 위한 통합 테스트를 수행합니다

라이브 클러스터(live cluster)란 운영 환경과 동일한 조건의 물리 서버에 설치된 서버입니다. 통합 테스트를 진행할 때는 라이브 클러스터를 사용합니다.

테스트 클러스터에 하둡 배포 판을 설치하기 위해, 클러스터 내부의 SNAPSHOT 버전에 package와 deploy를 적용할 때, khp-ansible를 통해 변경을 배포하고 재시작하는 과정을 거칩니다. 그렇기 때문에 테스트 검증 과정에서 khp-ansible에 해당 컴포넌트의 설치 및 제어에 대한 스크립트들도 같이 준비하여 동작을 확인합니다.

khp-package: rake itest

통합 테스트를 수행할 대상이 되는 클러스터는 변경이 용이하도록 아래와 같은 설정값들을 활용합니다. config_url로 설정한 tar.gz 파일을 다운로드하면 하둡 컴포넌트들의 모든 설정 파일들(ex. core-site.xml, hdfs-site.xml, … )이 포함된 것을 확인할 수 있습니다. 컴포넌트별로 통합 테스트에 필요한 외부 설정값들을 해당 파일에 정의해서 테스트 과정에 활용합니다.

config_url: http://xxx/khp-client-configs/khp-hadoop-test.tar.gz 
realm: XXX
nameservice: xxx
itest:
  anaconda3.pymysql.select:
...
  hdfs:
...
  ranger:
...
  trino:
...
  sqoop:
...

통합 테스트의 실행 환경은 도커로 구성하며, 컨테이너를 통해 수행합니다. 하둡 클라이언트를 통한 테스트 진행 방식이 주를 이루고 있기 때문에, 클라이언트 버전의 일원화를 위해 처음부터 테스트의 실행 환경을 도커로 구성하였습니다.

desc 'docker run /bin/bash (default: cluster=default rm_skip=false ...)' 
task :run do
  ...
  make_config cluster
  ...
  sh "docker run -t #{rm_opt} #{DOCKER_OPTS} " 
     "-v #{  dir  }/target/config:/config "
     "-v #{  dir  }/../roles:/roles "
     "-v #{ dir }/../repositories:/repositories " 
     "-v #{ dir }/../itest-env:/itest-env " 
     "#{run_opts} #{target_image} #{command}"
end

또한, 유닛 테스트와는 다르게 통합 테스트 환경에는 실행 컨텍스트에 하둡 클라이언트들의 설치가 필요합니다. 테스트 실행 환경의 컨테이너를 관리하면, 통합 테스트 실행 환경을 로컬로 분리할 수 있고 실행이 편리합니다.

통합 테스트 커버리지의 경우 컴포넌트 별로 양상이 다릅니다. 통합테스트 특성이 두드러지는 네가지 컴포넌트로는 하둡(Hadoop), 스파크(Spark), 트리노(Trino), 휴(Hue)가 있습니다. 각 컴포넌트에 대해 예시와 함께 간단히 설명 드리겠습니다.

하둡은 super user를 사용하여 클라이언트 툴을 통한 dfs, dfsadmin CLI 테스트가 주를 이루고 있습니다. 가장 기반이 되는 컴포넌트이기에 하둡 코어(HDFS, YARN)의 동작 여부를 확인하는 데 중점을 두고 있습니다.
스파크는 하둡 컴포넌트들을 가장 다양하게 활용하는 컴포넌트 중 하나입니다. 응용 프로그램 층에 가까워서, 주로 하둡 컴포넌트들을 활용하는 기능이나 의존성 문제를 확인합니다. 파이스파크(Pyspark) 테스트를 통해 아나콘다 파이썬 라이브러리와의 호환성 검토를 수행하거나, 공용 하둡에서 사용하고 있는 Hive auxiliary jars에 대한 기능 테스트를 위해 spark_sql과 spark-submit을 활용하는 식입니다.
트리노는 다양한 쿼리의 성공 실패 여부를 확인하기 위해 TPC-DS를 활용하고 있습니다. 클러스터 내 컴포넌트 버전 차이별 성능을 측정할 수 있는 형태로 확장을 고려하고 있습니다.
휴는 오픈 소스 내 포함된 통합 테스트를 그대로 사용합니다. 휴의 통합 테스트 대상이 되는 미니 클러스터를 구성하기 위해서, 하둡, 우지(Oozie) 바이너리를 KHP로 변경하여 KHP 통합 테스트로 사용합니다.

통합 테스트까지 성공하면 검증이 완료된 것으로 판단합니다. 이후 빌드, 배포, 릴리즈 절차를 이어갑니다. 참고로 성공 기준 통합 테스트를 전부 수행하는 데 140분 이상 소요됩니다.

빌드를 통해 khp-ansible을 통해 설치하기 좋은 형태로 패키지합니다

컴포넌트별로 주로 사용되는 빌드 툴과 스크립트 사용 방법이 다르기 때문에 이를 rake tasks로 정리하여 간단히 실행시킬 수 있도록 작업을 정의합니다.

khp-package: rake package

컴포넌트별로 package tasks 내에서 적절한 옵션과 파라미터를 활용해서 빌드를 수행합니다. 하둡 컴포넌트 중에는 자바 프로젝트가 많아서 주로 메이븐(mvn)을 사용하여 빌드를 수행하도록 구성되어 있습니다. 그 외에는 파이썬(Python) 기반의 아나콘다(Anaconda), 휴 등이 있습니다. 이번에는 하둡과 아나콘다의 각 패키지 작업(task)을 살펴보겠습니다. 하둡은 mvn을 그대로 사용합니다. 전혀 특별할 게 없네요.

desc 'package hadoop'
task package: %w[verify prepare] do 
  Dir.chdir REPO_PATH
  sh 'mvn clean package -Pdist,native -DskipTests -Dtar -Dmaven.javadoc.skip=true' 
end

아나콘다는 기존에 관리하면서 사용하고 있던 빌드 스크립트(build.sh)를 그대로 사용합니다. Rake task에서는 기존 빌드 스크립트를 실행주는 역할만 수행합니다.

desc 'package anaconda'
task package: %w[verify prepare] do 
  Dir.chdir REPO_PATH
  sh './build.sh' 
end

build.sh 내용을 발췌해서 보면 도커를 사용하여 OS별로 conda 환경을 설치(예: centos.Dockerfile) 후 tar.gz(tgz)으로 바이너리를 묶어 정리한 산출물을 외부로 복사해서 사용한다는 것을 알 수 있습니다.

...
echo "Creating package: ${PACKAGE}-${OS_VERSION}.tgz"
DOCKER_BUILDKIT=1 
  docker build --build-arg PACKAGE=${PACKAGE} 
               --build-arg KHP_DIR=$KHP_DIR 
               --build-arg CONDA_URI=${CONDA_URI} 
               --build-arg OS_VERSION=${OS_VERSION} 
               --build-arg TARGET_OS=${TARGET_OS} 
               -t ${IMAGE_NAME}:${TARGET_OS} -f ${DISTRIBUTION}.Dockerfile .
docker run -d --name ${CONTAINER_NAME} -t ${IMAGE_NAME}:${TARGET_OS} /bin/bash
docker cp -L ${CONTAINER_NAME}:${KHP_DIR}/${PACKAGE}-${OS_VERSION}.tgz ./target/${PACKAGE}
docker kill $CONTAINER_NAME 
docker rm $CONTAINER_NAME

패키지 산출물을 배포합니다

배포에는 크게 두 종류가 있습니다.

메이븐 배포
바이너리 배포

메이븐 배포는 테스트 및 빌드 과정에서 이뤄집니다. 비록 카카오 내부의 Nexus에 하둡, 스파크를 배포하고 있으나 업스트림 기준 의존성으로도 충분한 수준이라, 적극적으로 활용하고 있지는 않습니다.

넥서스(Nexus): 카카오 사내의 Maven, Gradle 산출물 저장소 서비스의 이름입니다.

바이너리 배포는 릴리즈 과정에서 이뤄집니다. 내부 파일 서버에 tar.gz 형태로 압축 바이너리 파일을 리네임하여 업로드하는 것을 의미합니다. 이후 릴리즈 문서나 khp-ansible에 포함되는 바이너리 URL도 전부 이 파일 서버를 사용합니다.

khp-package: rake deploy

파일 서버에 업로드는 과정은 간단히 스크립트화하여 rake task로 수행하고 있습니다.

rake task 정의를 살펴보면, 컴포넌트별로 차이가 미미하다는 것을 알 수 있습니다. 이유는 수행해야 할 로직이 동일하고, deploy 라이브러리로 코드가 따로 구현되어 있기 때문입니다.

desc @deploy.desc_msg(:hadoop) 
task :deploy do
  @deploy.run_with_package(PACKAGE_FILE) do 
    Rake::Task['package'].invoke
  end 
end

deploy 라이브러리 내 주요 로직을 보면 다음과 같습니다.

버전 규칙에 따라 파일명 변경
업로드 URL 내 KHP 버전을 상위 URI 경로로 구분
SNAPSHOT이 아닌 경우 파일 서버에 덮어쓰기 불가
파일 업로드 수행

...
private
    ...
    def move_to_common_target_and_upload_to_khp(file) 
      khp_version = @env.metainfo['khp']['version']
      filename = add_postfix_file_name(file, ENV['postfix'])
      target = "#{TARGET_DIR}/#{filename}"
      uri_path = "/khp-#{khp_version}/#{filename}"
      raise "#{uri_path} already exists in the file server." if
          !khp_version.include?('SNAPSHOT') && server_exists?(uri_path)
      system "cp #{file} #{target} && "
        "curl -v -F group=/khp-#{khp_version} -F file=@#{target} #{FILE_SERVER_URL}"
    end

릴리즈 마무리

하둡 컴포넌트들의 호환성 검증이 완료되었고 설치가 가능한 형태로 업로드까지 완료되었습니다. 이 과정을 마친 컴포넌트 묶음을 하나의 릴리즈로 하여 태깅을 재확인하고 마크다운(md) 문서를 재작성합니다. 하둡 컴포넌트별로 검증이 끝난 경우에, 커밋을 기준으로 카카오 브랜치에 머지를 완료하고 태깅을 진행합니다.

태깅 룰은 (1)으로 사용하다가 <빌드 날짜>가 제공하는 정보가 적다고 판단을 해 p으로 태킹 룰을 변경했습니다. 룰이 변경되기 전에 릴리즈 한 것들은 태깅을 변경하지 않았기 때문에, 현재 두 가지 버전의 태깅 방식이 혼용되고 있습니다. 마지막 소챕터에서는 릴리즈 예시를 통해 컴포넌트들의 버전을 확인해 보실 수 있습니다.

(1)``-khp[-``]-`<빌드날짜>`
(2)``-khp-p`[-]`

khp-package: metainfo.yml을 정리하고 태깅

개별 하둡 컴포넌트들에서도 태깅을 하고 이를 submodule로 연결합니다. 또, khp-package 레벨에서는 KHP 버전으로 태깅을 진행합니다.

KHP 버전은 다음과 같은 태깅 룰에 따라 관리되고 있습니다. 마찬가지로 마지막 소챕터에서 예시를 첨부하겠습니다.

khp-``-hadoop``

khp-release: 릴리즈 정리

릴리즈 산출물은 khp-release라는 사내 공개 리포지토리를 통해 이뤄집니다. 다음과 같이 두가지 파일을 업로드합니다.

릴리즈 노트: .md
다운로드 링크: .yml

깃에 해당 변경이 적용되고 나면, 사내 Wiki에도 깃허브 마크다운 링크를 활용하여 공개하는 것으로 릴리즈 절차가 마무리됩니다.

릴리즈 예시) khp-1.3.0-hadoop2

마지막으로 위 과정을 거쳐서 새로운 변경에 대한 검증이 끝나고 릴리즈가 완료된 산출물(파일명: khp-1.3.0-hadoop2.md)에 대한 예시를 공유 드립니다.

# KHP 1.3.0
## 배포판
### 기능 추가 / 버그 수정
#### Spark
기존 upstream 2.4.5에 대한 maintenance 관점에서의 추가 릴리즈
- Spark 버전 업그레이드 - 2.4.8
- 주요 변경: https://spark.apache.org/releases/spark-release-2-4-8.html#notable-changes 
#### Spark3
`KHP-1.3.0에 새롭게 추가되었습니다.`
- Apache Spark 3.2.1 기반 
### 알려진 문제 및 제한 사항 
### Commits
### Spark
- `4e616a96cd` [HADOOPENG-5325] change to set spark test version(unit test) (#13)
- `7c3a39805d` [SPARK-31935][SQL][TESTS][FOLLOWUP] Fix the test case for Hadoop2/3
- `b5a6cf08e4` executed dev/change-scala-version.sh 2.12, changed root scala.version to
2.12.10 in pom.xml
- `2c0dbac737` added a new profile (hadoop-2.10) in the root pom.xml 
### Spark3
- `34c0a1a889` [HADOOPENG-4033] set https protocol for kakao repositories
- `38c6506efd` [HADOOPENG-4033] update hadoop-2.10 profile
- `4299d24538` [HADOOPENG-4033] added khp repo, hadoop-2.10 profile
- `29221168f1` [HADOOPENG-4033] changed pom version to 3.2.1-khp-p1
## Source Code
`PRIVATE` [사내 Github](https://xxx/hadoopeng/khp-package) : 검증이 완료되면 추후 공개 예정

하둡 컴포넌트 배포 버전 (참고용)

변경 없이 공개된 tar.gz 사용

OpenJDK8U-jdk_x64_linux_hotspot_8u242b08.tar.gz
OpenJDK11U-jdk_x64_linux_hotspot_11.0.8_10.tar.gz
hbase-1.4.13-bin.tar.gz
trino-server-355.tar.gz
sqoop-1.4.7.bin hadoop-2.6.0.tar.gz
apache-zookeeper-3.5.7-bin.tar.gz

자체 빌드 "-khp[-"]-'<빌드 날짜>'

Anaconda3-2020.02-3.7.6-khp-el7_20201112.tgz
hadoop-2.10.0-khp-20210809.tar.gz
apache-druid-0.21.0-bin-khp-20220215.tar.gz
tez-0.9.2_khp-20201112.tar.gz

자체 빌드 "-khp-p"[-]

apache-hive-2.3.2-khp-p2-bin.tar.gz
hue-4.10.0-khp-p3-bin.tar.gz
oozie-5.2.0-khp-p2-distro.tar.gz
ranger-2.1.0-khp-p1-admin.tar.gz
spark-2.4.8-khp-p1-bin-without-hadoop.tgz
spark-3.2.1-khp-p1-bin-without-hadoop.tgz

마치며

KHP의 릴리즈를 절차를 따라가며 khp-package의 역할을 알아봤습니다. 부족한 점도 있겠지만 나름의 이유를 가지고 아키텍처 선택해오다 보니 현재의 모습을 갖추게 되었습니다. 결과적으로는 Bigtop보다 범용성이 떨어질 순 있겠지만, 카카오 인프라에 더 적합한 구조가 되었으며 테스트를 쉽게 수행하고 상호 호환성을 검증할 수 있는 이점을 누리게 되었습니다.

저희가 업스트림으로 사용하고 있는 하둡 클러스터 버전을 기반으로 상호 호환성 변경 및 검증을 진행해나가신다면 조금 더 수월한 길이 되실 수 있다고 생각합니다. 또한 일반적인 오픈 소스를 관리하고 운영하는 관점에서도 어떠한 형태로든 도움이 되셨기를 바랍니다. 감사합니다.

KHP 하둡 배포판 릴리즈 관리하기(feat. khp-package)