Skip to Content
Data EngineeringHBase 모니터링: Hadoop 배포판(HDP vs CDH)별 버전 충돌 및 메트릭 누락 이슈 해결
📊 Data Engineering2018년 1월 11일

HBase 모니터링: Hadoop 배포판(HDP vs CDH)별 버전 충돌 및 메트릭 누락 이슈 해결

#hbase#monitoring#hdp#cdh#data-engineering#flamingo

과거 당사에서 빅데이터 성능 관리 솔루션 빅데이터 모니터링 플랫폼의 HBase 모니터링 모듈을 개발할 당시 겪었던 가장 치명적이고 골치 아픈 이슈는 바로 “Hadoop 배포판 벤더(Vendor) 간의 파편화”였습니다.

다양한 고객사에 플랫폼 납품을 셋업하는 과정에서, 어떤 고객사는 Hortonworks(HDP)를, 어떤 고객사는 Cloudera(CDH)를 사용하고 있었습니다. 두 배포판 모두 내부적으로는 오픈소스 Apache HBase를 기반으로 구동되었기 때문에, JMX(Java Management Extensions)나 REST API를 통해 모니터링 지표 리스트(ex. RegionServer Request Count, Heap Memory, BlockCache Hit Ratio 등)를 당연히 동일하게 받아올 것으로 예상했습니다. 하지만 실상은 완전히 달랐습니다.

1. HDP와 CDH의 HBase 버전 및 차이점 분석

당시 시장에 혼재되어 있던 두 배포판의 대표 버전을 기준으로 내부 HBase 엔진 버전을 뜯어분석해 보니 다음과 같은 차이가 있었습니다.

  • HDP (2.6.4 기준): 내부적으로 Apache HBase 1.1.2 기반 엔진 사용.
  • CDH (5.13 기준): 내부적으로 Apache HBase 1.2.x 기반 엔진 사용. (여기에 Cloudera 자체 패치버전 포스트픽스 반영)

문제는 Apache HBase 오픈소스 진영에서 1.1.x 버전에서 1.2.x 버전으로 메이저에 가까운 마이너 업데이트를 단행하면서, 성능 모니터링에 쓰이던 핵심 JMX 메트릭 구조를 대거 개편해버린 데 있었습니다.

  • 발생한 이슈: 바닐라(Vanilla) Apache HBase 버전 테스트 매트릭을 돌려본 결과, HBase 1.1.2 모델(HDP 환경)에는 명확히 존재하던 수십 개의 메트릭 속성 경로와 이름들이, 1.2.x 모델(CDH 환경)에서는 이름이 완전히 바뀌거나 통폐합되어 아예 삭제된 상태였습니다. 이는 JMX 접근 방식뿐만 아니라, HTTP REST API나 Thrift 데몬을 통한 조회 응답 값에서도 동일하게 누락되었습니다.

2. 모니터링 솔루션 아키텍처 관점의 대응

수집하는 JSON 응답 Key-Value가 벤더마다 다르다면, 단일 소스코드로 짠 플랫폼 파서(Parser) 로직으로는 “메트릭을 찾을 수 없습니다(NullPointerException)” 에러를 뿜으며 모니터링 대시보드 화면이 텅 비어버리게 됩니다.

이를 해결하기 위해 저희 팀은 개발 및 수집 파이프라인 아키텍처를 전면적으로 리팩토링했습니다.

  1. 배포판 핑거프린팅(Distribution Fingerprinting)
    • 플랫폼 수집 에이전트가 최초 구동될 때, 현재 시스템 환경 변수나 클러스터 메타데이터를 질의하여 대상 HBase 버전이 속한 클러스터가 CDH 군인지, HDP 군인지 자동으로 판별하는 동적 분기 로직을 삽입했습니다.
  2. 어댑터 패턴(Adapter Pattern)을 통한 파싱 레이어 분리
    • HBase 버전에 의존적인 코드를 하드코딩하는 대신, HBaseMetricParser 인터페이스를 만들고 그 밑에 HdpHBaseParserImpl(1.1.x)와 CdhHBaseParserImpl(1.2.x)를 구현했습니다.
    • A라는 메트릭 이름이 CDH에서 B로 변경되었다면, 어댑터가 내부적으로 이 이름을 매핑(Mapping) 테이블을 거쳐 플랫폼 표준 네이밍인 A로 변환(Normalize)해 주어 사용자 화면에서는 끊김 없이 일관된 그래프로 보이게 조치했습니다.
  3. 대체 계산 지표 개발
    • CDH(1.2.x)에서 삭제되어 아예 받아올 수 없는 메트릭이라면, 다른 여러 하위 메트릭들을 집계 연산(Aggregation)하여 수학적으로 유추해야 하는 로직이나, 누락된 지표는 대시보드 UI에서 우아하게 비활성화(Graceful Degradation)하는 처리를 더했습니다.

3. 마무리 (데이터 인프라의 파편화 교훈)

빅데이터 세계에서는 “모두가 오픈소스를 쓴다”고 하지만 실상 벤더별 커스텀 빌드의 차이(Compatibility Matrix)는 상상을 초월합니다. 배포판의 메이저 릴리즈 전환 (예: HDP/CDH 통합 발표)이나 클러스터 업그레이드 프로젝트(Migration) 시에 모니터링 시스템의 호환성을 반드시 최우선적으로 벤치마크 테스트해야 하는 이유가 바로 여기에 있습니다. API 스펙의 단순 변경이 운영 모니터링의 블라인드 스팟(Blind Spot)을 초래하여 대형 장애 탐지를 지연시킬 수 있기 때문입니다.

Last updated on