📗하둡에서 쿠버네티스 플랫폼으로 이관 고려사항

하둡에서 Kubernetes로 이관을 고려하는 이유는 주로 운영 효율성과 확장성을 개선하기 위함이다.

• 목표 아키텍처 정의하기
• • 스토리지: Object Storage (S3, MinIO) + Iceberg
• • 데이터 처리: Spark on Kubernetes, Flink on Kubernetes
• • 데이터 쿼리: Trino, Iceberg
• • 메시지 브로커: Kafka on Kubernetes (Strimzi)
• • 워크플로: Airflow
• • 모니터링 및 로깅: Prometheus, Grafana, Jaeger
• 플랫폼 이관 전략 세우기
• • ASIS TOBE 기술 매핑 하기
• • 단계적 이관 전략 세우기

🏳️‍🌈 [궁금한점]

• 왜 하둡에서 쿠버네티스로 플랫폼을 바꾸려 하나
• 어떻게 이관할 것인가
• 이관 시 유의해야 할 점은 없나

---

🔗[목차]

• 📗하둡에서 쿠버네티스 플랫폼으로 이관 고려사항
• 🔗[목차]
• 쿠버네티스 플랫폼 사용에 대한 기대
  • 리소스 활용 최적화 및 비용 절감
  • 운영 효율성 향상
  • 멀티테넌시 및 유연한 워크로드 지원
  • 데이터 스토리지 유연성
  • 확장성과 클라우드 네이티브 아키텍처
• 이관 시 유의 사항
• 이관 전략
  • 기술 매핑
  • 단계별 이관 전략
• 이관 가이드
  • 스토리지 이관
    • HDFS에서 Object Storage로 전환
  • 데이터 처리 및 분석 프레임워크 이관
    • YARN을 Kubernetes 스케줄러로 대체
    • Hive에서 Iceberg/Trino로 전환
    • Oozie 대신 Airflow 사용
  • 서비스 및 메시지 브로커 이관
    • Kafka on Kubernetes
    • ZooKeeper 제거 또는 대체
  • 운영 및 모니터링

쿠버네티스 플랫폼 사용에 대한 기대

리소스 활용 최적화 및 비용 절감

• Hadoop (YARN): 리소스가 특정 워크로드(MapReduce, Spark) 전용으로 할당됨.

• Kubernetes: 여러 워크로드(ML, 웹 애플리케이션, 데이터 분석)와 공유 리소스 활용 가능.

• Auto-scaling 지원 → Spark/Flink 등 동적 리소스 할당 가능.

• 스팟 인스턴스 활용 → 클라우드 환경에서 비용 절감 효과.

운영 효율성 향상

• Kubernetes는 컨테이너 기반이라 환경 설정 및 배포가 표준화됨.
• Helm Chart, Operator를 활용해 자동화된 배포 및 관리 가능.
• Kubernetes의 Self-healing 기능 → 장애 발생 시 자동 복구.
• Spark/Flink Job을 CI/CD 파이프라인과 쉽게 연동하여 DevOps 구현 가능.

멀티테넌시 및 유연한 워크로드 지원

• 여러 팀이 Namespace를 분리하여 독립적으로 운영 가능.
• Hadoop은 배치 중심, Kubernetes는 스트리밍, 배치, ML, 웹 서비스 등 다양한 워크로드를 실행 가능.
• 데이터 엔지니어뿐만 아니라, ML 엔지니어, 개발자가 함께 활용 가능.

데이터 스토리지 유연성

• HDFS 유지 가능 (HDFS on Kubernetes) 또는 S3, MinIO 같은 오브젝트 스토리지로 대체 가능.
• S3를 사용하면 클라우드 환경과 더 쉽게 통합 가능.
• Iceberg, Delta Lake 등 최신 데이터 레이크 솔루션과 쉽게 연동 가능.

확장성과 클라우드 네이티브 아키텍처

• Kubernetes는 온프레미스 + 클라우드 하이브리드 배포 가능.
• 서버리스 Spark, Flink 실행 가능 (예: AWS EMR on EKS, GCP Dataproc on Kubernetes).
• 벤더 종속성 감소 → 특정 Hadoop 배포판(예: Cloudera, Hortonworks) 의존도 줄일 수 있음.
• 점진적 이관 + 클라우드 네이티브 데이터 레이크 전환이 가장 현실적인 접근 방식이다.

이관 시 유의 사항

Hadoop 전체를 Kubernetes로 한 번에 이관하는 것은 부담이 크다. Spark/Flink 등 핵심 데이터 처리 엔진부터 점진적으로 Kubernetes로 이전하는 전략이 유리하다. HDFS를 Object Storage로 변경하는 것이 가장 중요한 단계이다. Kubernetes 기반 운영 방식(YAML, Helm, Operator 등)에 익숙해질 필요가 있다.

• 기존 Hadoop 생태계와의 차이점
• • Kubernetes에는 YARN의 Fair Scheduler, Capacity Scheduler 같은 기능이 없음.
• • 대안: Kubernetes ResourceQuota, PriorityClass 활용 가능하지만, 완벽한 대체는 어려움.
• 데이터 로컬리티가 약해짐
• • Kubernetes의 랜덤 스케줄링으로 인해 Spark/Flink가 데이터가 있는 노드에서 실행되지 않을 수 있음.
• • 대안: Node Affinity 설정, S3 기반 데이터 저장.
• 데이터 이동 비용 증가 가능
• • HDFS 대신 S3를 사용하면, 네트워크를 통해 데이터 이동이 발생하여 I/O 비용 증가 가능.
• • 기존 HDFS 기반 Spark/Hive 쿼리를 변경해야 할 수도 있음.
• • 대안: Iceberg/S3 기반 데이터 레이크로 전환.
• 운영 난이도 증가 (Hadoop 관리팀의 Kubernetes 적응 필요)
• • Hadoop 관리자는 Kubernetes, Helm, Operator 등의 개념을 익혀야 함.
• • Kubernetes는 YAML 기반 설정이 많아 초기 진입 장벽이 있음.
• • 기존 YARN 중심 모니터링(Cloudera Manager, Ambari) 대신 Prometheus, Grafana, ELK, Jaeger 같은 도구를 추가적으로 구축해야 함.
• HBase, Kafka 같은 기존 Hadoop 컴포넌트 이관 필요
• • HBase → StatefulSet 기반으로 배포 가능하지만, HDFS 없이 운영하려면 Cassandra, Google Bigtable, DynamoDB 같은 대체 솔루션 고려 필요.
• • Kafka → Kubernetes용 Kafka Operator(Strimzi, KRaft) 활용 필요.
• • ZooKeeper → etcd 또는 Zookeeper on Kubernetes 배포 필요.

이관 전략

기술 매핑

Hadoop 생태계의 기존 구성 요소를 분석하고, Kubernetes에서 어떻게 대응될지를 결정

기존 Hadoop 구성 요소	Kubernetes에서의 대응
HDFS	Object Storage(S3, MinIO) 또는 HDFS on K8s
YARN	Kubernetes 스케줄러
MapReduce	Spark on Kubernetes, Flink
Hive	Iceberg, Trino, Spark SQL
HBase	HBase on Kubernetes 또는 NoSQL 대체 (Cassandra 등)
Oozie	Airflow, Argo Workflows
ZooKeeper	Zookeeper on K8s 또는 etcd 활용
Kafka	Kafka on Kubernetes (Strimzi, KRaft)

단계별 이관 전략

• Object Storage 기반 데이터 레이크 구축 (HDFS → S3)
• Spark/Flink on Kubernetes 전환 (YARN 제거)
• Hive → Iceberg/Trino로 전환
• Kafka/ZooKeeper 운영 방식 변경
• Airflow 기반 워크플로 구축
• 전체 모니터링 및 최적화

이관 가이드

스토리지 이관

HDFS에서 Object Storage로 전환

• Hadoop의 HDFS를 완전히 제거하고, S3(Ceph, MinIO) 같은 Object Storage를 사용.
• Iceberg 또는 Delta Lake 같은 테이블 포맷을 사용하면 성능 및 관리성이 향상됨.
• Spark, Presto/Trino, Hive 등에서 Object Storage를 기본 스토리지로 설정해야 함.
• HDFS가 필요한 경우, HDFS on K8s(HDFS Operator, StatefulSet 배포) 방식도 고려 가능.

데이터 처리 및 분석 프레임워크 이관

YARN을 Kubernetes 스케줄러로 대체

• 기존 Spark, Flink, Hive 작업이 YARN 기반이었다면 Spark on Kubernetes 또는 Flink on Kubernetes로 변경.
• Kubernetes Operator (Spark Operator, Flink Operator) 사용 가능.
• 기존 MapReduce Job은 Spark/Flink로 재작성하는 것이 좋음.

Hive에서 Iceberg/Trino로 전환

• Hive Metastore를 유지하면서 Iceberg로 마이그레이션 가능.
• Trino, Spark, Flink에서 Iceberg 테이블을 읽고 쓸 수 있도록 설정.

Oozie 대신 Airflow 사용

• 워크플로 관리용으로 Airflow를 활용하고, DAG를 통해 Spark/Flink 작업 실행.
• Spark on K8s를 Airflow에서 관리하도록 설정.

서비스 및 메시지 브로커 이관

Kafka on Kubernetes

• Kafka를 Kubernetes에서 실행하려면 Strimzi Operator 또는 KRaft 모드 사용.
• 기존 Kafka 데이터를 새 클러스터로 동기화하는 방안 검토.

ZooKeeper 제거 또는 대체

• Kafka가 KRaft 모드를 지원하므로 ZooKeeper 없이 운영 가능.
• etcd를 활용하여 일부 ZooKeeper 기능 대체 가능.

운영 및 모니터링

• 모니터링: Prometheus + Grafana 조합 사용.
• 로깅: ELK (Elasticsearch, Logstash, Kibana) 또는 Loki + Grafana 활용.
• 분산 트레이싱: Jaeger, OpenTelemetry 사용하여 Spark/Flink 성능 분석.