왜 지금 HBase 3.0을 봐야 하나
Apache HBase 3.0.0-beta-2가 2026년 7월 17일 공개됐다. 이번 베타는 릴리스 공지 기준으로 최종 3.0.0 직전의 마지막 베타다. HBase 팀은 2.0.0 이후 5,000개 이상의 이슈가 정리됐고, 여러 차례의 10B ITBLL 테스트를 통과해 핵심 기능은 실운영에 가까운 수준이라고 설명한다. 다만 이름 그대로 베타이므로, 운영자는 "기능이 많아졌다"보다 "어떤 운영 경계가 바뀌었는가"를 먼저 봐야 한다.
이번 3.0 계열에서 가장 큰 변화는 세 가지다.
- 제어면 재배치: 클라이언트와 복제 메타데이터를 ZooKeeper 바깥으로 빼내기 시작했다.
- 실행 환경 상향: JDK 17, Hadoop 3.3.5 이상을 전제로 다시 선을 그었다.
- 복구·관측성 표준화: 동기 복제, 증분 백업/복구, OpenTelemetry tracing을 운영 표면으로 올렸다.
즉, HBase 3.0은 단순한 성능 패치가 아니라 "어떻게 클러스터를 부팅하고, 복제하고, 복구하고, 추적할 것인가"를 다시 정의하는 릴리스에 가깝다.
한눈에 보는 변화 지도
| 축 | 2.x 운영 습관 | 3.0 계열에서 달라지는 점 | 운영자 메모 |
|---|---|---|---|
| 클라이언트 접속 | ZooKeeper quorum으로 클러스터 찾기 | RPC 기반 registry가 기본 경로, ZooKeeper 연결은 공개 인터페이스에서 밀려남 | 앱 설정에서 ZooKeeper 의존을 지울 준비가 필요 |
| 복제 메타데이터 | peer 정보와 queue 정보를 ZooKeeper에 지속 저장 | peer storage는 filesystem 구현 가능, queue 정보는 hbase:replication 테이블로 이동 | 롤링 업그레이드 중 메타데이터 이동 절차를 점검해야 함 |
| 런타임 바닥선 | JDK 8/11, Hadoop 2.x 잔존 환경 허용 | JDK 17 only, Hadoop 3.3.5+ 최소, Hadoop 2.x 미지원 | 운영 스크립트·빌드·보안 라이브러리까지 함께 올려야 함 |
| DR | 비동기 복제 + 수동 장애조치 중심 | 동기 복제(ACTIVE/STANDBY/DOWNGRADE_ACTIVE) 절차 명시 | DR 훈련 문서를 HBase shell 상태 전이 기준으로 다시 써야 함 |
| 백업/복구 | ExportSnapshot 중심 full copy 관성 | WAL 기반 full + incremental backup/restore 운영면 강화 | HDFS/WAL 보존량이 커질 수 있어 일정 관리가 핵심 |
| 관측성 | HTrace 유산, 로그/메트릭 중심 | OpenTelemetry tracing, fsReadTime slow log, fsSlowReadsCount 추가 | Java agent + collector 경로를 따로 검증해야 함 |
아키텍처: ZooKeeper 축소, 복제/백업/추적 경로의 분리
1) ZooKeeper는 더 이상 공개 인터페이스의 중심이 아니다
가장 상징적인 변화는 ZooKeeper의 역할 축소다.
릴리스 노트에는 두 가지 방향 전환이 동시에 보인다.
HBASE-23324: ZooKeeper로 직접 연결하는 클라이언트를 deprecated 처리했다. 2.6부터 경고를 주기 시작했고, 3.0에서는 RPC 기반 연결이 기본 경로가 되며, 4.0에서는 클라이언트 공개 API에서 제거할 계획이라고 못 박았다.HBASE-27109: replication queue storage를 ZooKeeper에서hbase:replication테이블로 이동했다. 릴리스 노트는 이를 "ZooKeeper에 남아 있던 마지막 persistent data"라고 설명한다.
이 둘을 합치면 운영 의미가 분명해진다. ZooKeeper는 더 이상 클러스터의 장기 상태를 대표하는 저장소가 아니다. 클라이언트 진입점도, 복제 큐의 영속 저장소도 HBase 자체 내부 구조로 옮겨간다.
왜 hbase:replication 테이블이 중요한가
이 변경은 단순 저장 위치 이동이 아니다. 복제 큐를 HBase 테이블로 옮기면 자기 자신을 복제 메타데이터로 관리하는 순환 의존이 생긴다. 릴리스 노트는 이 문제를 피하기 위해:
hbase:replication에 별도 WAL provider를 둔다.- 큐 표현도 "WAL 파일 목록"이 아니라 WAL group offset 중심으로 바꾼다.
즉, 이제 운영자는 복제 장애를 볼 때 ZooKeeper znode를 뒤지기보다 HBase 내부 시스템 테이블과 관련 WAL 흐름을 보는 쪽으로 사고방식을 바꿔야 한다.
peer storage는 아직 즉시 기본값이 아니다
HBASE-27110은 replication peer storage 구현을 zookeeper와 filesystem으로 분리했다. 하지만 기본값은 여전히 zookeeper다. 이유도 명확하다. 업그레이드 순간 기본 구현을 바꾸면 기존 peer metadata를 못 읽어서 조용한 데이터 손실이 날 수 있기 때문이다.
그래서 3.0 업그레이드는 "버전만 올리면 끝"이 아니다. 운영자가 원하면 명시적으로 peer storage를 옮겨야 한다.
./bin/hbase copyreppeers <SRC_REPLICATION_PEER_STORAGE> <DST_REPLICATION_PEER_STORAGE>또한 온라인 마이그레이션을 위해 peer 변경을 잠그는 스위치도 제공한다.
peer_modification_switch <disableOrEnable>, <drainProcedures>이 단계가 필요한 이유는, 3.0의 목표가 "ZooKeeper 제거"가 아니라 ZooKeeper를 내부 구현으로 격리하고, 운영자가 의도적으로 이동할 수 있게 만드는 것이기 때문이다.
2) 업그레이드 바닥선이 높아졌다: JDK 17, Hadoop 3.3.5, Hadoop 2.x 종료
이번 베타에서 가장 즉각적으로 터지는 문제는 런타임이다.
JDK 17 only
릴리스 노트는 두 번 강조한다.
- 컴파일 타깃을 Java 17+로 올렸다.
hbase-config.sh는 17 미만 JDK면 경고 후 종료한다.
즉, 2.x 시절처럼 "서버는 17로 올리고 일부 스크립트나 클라이언트는 11에 남겨 둔다"는 식의 절충이 어렵다. 운영 이미지, CI, 빌드 플러그인, 보안 스캐너, 사용자 shell 환경이 함께 올라와야 한다.
Hadoop 3.3.5+ 최소, Hadoop 2.x 미지원
릴리스 노트 기준으로 HBase 2.6+의 Hadoop 3 최소 지원선은 3.3.5다. 릴리스 공지에서는 더 직접적으로 Hadoop 2.x를 더 이상 지원하지 않는다고 적었다.
이 영향은 단순 의존성 범위를 넘는다.
- HDFS erasure coding을 테이블 데이터 디렉터리 단위로 적용할 수 있다.
- Ozone OFS를 WAL backing storage로 쓰는 경로가 공식적으로 언급된다.
- backup/restore도 DistCp 쪽 버그 수정이 반영된 Hadoop 계열을 요구한다.
즉, HBase 3.0은 HDFS/Hadoop 스택 전체를 같이 올릴 수 있는 팀에게 유리하다. 반대로 Hadoop 2 계열 장기 유지 환경에서는 HBase 3.0 채택 자체가 큰 프로젝트가 된다.
보안 및 스토리지 측면의 부수 변화
릴리스 노트에는 운영자가 놓치기 쉬운 추가 변화도 있다.
hbase-openssl모듈이 추가돼 netty TLS에서 tcnative/BoringSSL 경로를 쓸 수 있다.- Web UI 쪽 LDAP admin ACL 지원이 들어왔다.
- 테이블 디렉터리의
ERASURE_CODING_POLICY를 스키마 레벨에서 관리할 수 있다. 단, 정책 변경 후 major compaction이 필요하다.
이 변화들은 모두 공통적으로 "3.0은 애플리케이션 API보다 운영 환경을 먼저 재정렬하는 릴리스"라는 점을 보여 준다.
3) 동기 복제는 기능이 아니라 장애조치 절차다
HBase는 오래전부터 비동기 복제를 제공했지만, 레퍼런스 가이드의 동기 복제 섹션은 3.0 계열에서 운영자가 따라야 할 절차를 비교적 명확히 제시한다.
상태 기계: ACTIVE / STANDBY / DOWNGRADE_ACTIVE
동기 복제는 두 클러스터 사이에 같은 peer id를 두고, remote WAL 디렉터리를 지정한 뒤 상태를 전이시키는 방식으로 구성한다.
STANDBY: 대기 클러스터. 읽기/쓰기 요청을 거부한다.ACTIVE: 활성 클러스터. 원격 WAL까지 함께 써서 동기성을 맞춘다.DOWNGRADE_ACTIVE: 상대 클러스터 장애 시 임시 완화 상태. 비동기 쪽 대기열은 쌓되, 원격 WAL 동기 쓰기는 중단한다.
레퍼런스 가이드는 다음 사실을 분명히 적는다.
- 현재 구현은 table-level replication만 지원한다.
- standby가 죽으면 active를
DOWNGRADE_ACTIVE로 내려야 한다. - active가 죽으면 standby를
DOWNGRADE_ACTIVE로 올린 뒤 클라이언트 트래픽을 절체해야 한다.
이 말은 곧, 동기 복제를 켰다고 해서 자동 DR이 끝나는 것이 아니라는 뜻이다. 상태 전이 runbook이 없으면 동기 복제는 오히려 장애 시 판단을 더 어렵게 만들 수 있다.
SKIP_WAL 예외도 줄였다
릴리스 노트의 HBASE-26993은 새 region replication framework가 Durability.SKIP_WAL 테이블/뮤테이션도 복제할 수 있게 만들었다고 적는다. 이는 지연을 줄이기 위해 WAL을 건너뛰던 일부 워크로드에서 read replica 정합성의 사각지대를 줄이는 변화다.
다만 이것을 "아무 설정 없이 모든 내구성 문제가 사라진다"로 읽으면 안 된다. SKIP_WAL은 여전히 지역 장애·프로세스 크래시 상황에서 기본 WAL 내구성을 포기하는 선택이므로, replica 가용성과 로컬 durable commit은 다른 층위의 문제로 남는다.
4) 백업·복구와 관측성이 운영 표면으로 올라왔다
증분 백업은 결국 WAL 운영이다
레퍼런스 가이드의 backup/restore 섹션은 HBase 증분 백업이 실제로 어떻게 동작하는지 설명한다.
- 전체 백업(full backup)으로 기준점을 만든다.
- 이후 incremental backup은 직전 백업 이후의 WAL과 bulk-loaded HFile을 수집한다.
- 복구 시에는 full backup을 먼저 복원하고, 그 사이의 incremental backup HFile들을 bulk load한다.
이 구조의 장점은 분명하다. ExportSnapshot보다 훨씬 덜 비싸게 시점 복구 지점을 촘촘히 만들 수 있다.
하지만 운영 비용도 명확하다. 레퍼런스 가이드는 다음 incremental backup이 끝날 때까지 관련 WAL을 보존해야 하므로 파일시스템 사용량이 크게 늘 수 있다고 경고한다. hbase:backup 시스템 테이블 TTL은 기본적으로 무한에 가깝기 때문에, 백업 스케줄을 사람이 의도적으로 관리하지 않으면 HDFS가 서서히 잠긴다.
즉, 증분 백업을 켠 뒤 진짜 질문은 "복구가 가능한가"만이 아니다.
- backup 간격을 얼마나 짧게 둘 것인가
- WAL 증가 속도를 누가 모니터링할 것인가
- backup root 정리 책임이 누구에게 있는가
이 세 가지를 함께 정해야 한다.
tracing은 OpenTelemetry로 재정비됐다
레퍼런스 가이드는 HTrace가 사실상 사라진 뒤, HBase 3.0이 OpenTelemetry 기반 tracing으로 옮겨갔다고 설명한다. 구현 방식도 중요하다.
- async client
- RPC
- region read/write/scan
- WAL
이 경로를 java agent 자동 바이트코드 변환이 아니라, opentelemetry-api를 사용한 수동 계측으로 넣었다. 대신 실제 export는 여전히 OpenTelemetry Java agent를 붙여야 한다.
기본 logging exporter도 가능하지만, 문서 자체가 collector/Jaeger/Zipkin 같은 외부 tracing 시스템 사용을 권장한다. 운영 관점에서는 이게 맞다. HBase는 이미 로그가 많은 시스템이라, trace를 콘솔로 흘리면 분석이 아니라 잡음이 된다.
느린 스캔을 HDFS까지 연결해서 본다
HBASE-28302는 fsReadTime과 fsSlowReadsCount를 추가했다. 이것이 좋은 이유는, 느린 scan을 더 이상 "클라이언트가 느리다" 수준으로만 보지 않고 HDFS block read 지연과 직접 연결해 볼 수 있기 때문이다.
HBase에서 진짜 병목은 종종 RPC 큐가 아니라 아래쪽 저장소다. 이 메트릭은 3.0 이후 tracing과 metrics를 묶는 첫 번째 실용 지점이 될 가능성이 크다.
운영자가 실제로 밟을 마이그레이션 순서
- 런타임 인벤토리부터 만든다.
- 모든 HMaster/RegionServer/sidecar 이미지가 JDK 17으로 올라갈 수 있는지 확인한다. - Hadoop 클러스터가 최소 3.3.5 선을 만족하는지 먼저 본다.
- 클라이언트 bootstrap을 ZooKeeper에서 떼어낸다.
- 앱 설정, 배치 잡, 도구 스크립트에 zk_quorum 전제가 남아 있는지 찾는다. - 3.0 카나리 클러스터에서는 RPC 기반 registry 경로만 허용해 본다.
- 복제 메타데이터 이동을 별도 작업으로 분리한다.
- 업그레이드와 peer storage migration을 한 번에 묶지 않는다. - 먼저 3.0 롤링 업그레이드를 끝내고, 그다음 copyreppeers와 peer_modification_switch를 사용해 이동 절차를 검증한다.
- DR runbook을 shell 상태 전이 중심으로 다시 쓴다.
- ACTIVE → DOWNGRADE_ACTIVE - STANDBY → DOWNGRADE_ACTIVE - 복귀 후 어느 쪽을 STANDBY로 내릴지 - 클라이언트 절체 시점을 문서화한다.
- 백업 운영을 저장소 용량 계획과 함께 묶는다.
- full/incremental 주기 - WAL 증가량 - backup root cleanup 책임자 - restore drill 빈도를 함께 정한다.
- OTel은 logging exporter로 끝내지 말고 collector까지 연결한다.
- service.name을 process별로 다르게 둔다. - trace, slow log, HDFS read latency를 같은 장애 티켓에서 볼 수 있게 만든다.
도입 전 검증 체크리스트
| 검증 항목 | 어떻게 확인할까 | 실패 시 의미 |
|---|---|---|
| JDK 17 강제 | java -version, hbase-config.sh 기동 로그 확인 | 아예 부팅 단계에서 멈춤 |
| Hadoop 3.3.5+ | 배포 이미지와 Hadoop 패키지 버전 확인 | backup/restore, EC, Ozone 경로를 신뢰하기 어려움 |
| 클라이언트 bootstrap | 앱 설정에서 ZooKeeper quorum 의존 검색 | 3.0 이후 연결 경로가 꼬일 수 있음 |
| peer storage 구현 | hbase.replication.peer.storage.impl, peer 목록 백업 | 이동 없이 기본값만 믿으면 메타데이터가 예상과 다를 수 있음 |
hbase:replication 생성 | 시스템 테이블 존재, 관련 WAL 파일 생성 여부 확인 | 복제 큐 이전 경로가 제대로 끝나지 않았을 수 있음 |
| 동기 복제 상태 전이 | 테스트 peer에 ACTIVE/STANDBY/DOWNGRADE_ACTIVE drill 수행 | DR 절차가 문서만 있고 실제로는 안 돌아갈 수 있음 |
| backup root 증가량 | incremental backup 주기와 HDFS 사용량 추적 | WAL 보존 때문에 저장소가 예상보다 빨리 찰 수 있음 |
| OTel trace 수집 | collector에서 HMaster/RS/service.name 분리 수집 확인 | trace를 켰지만 운영 분석에는 못 쓰는 상태 |
fsReadTime / fsSlowReadsCount | slow log, JMX, 대시보드 반영 확인 | HDFS 병목을 여전히 RPC 문제로 오진할 가능성 |
| EC / Ozone 사용 시 | major compaction 이후 효과 확인, WAL 성능 측정 | 스토리지 기능은 켰지만 성능/내구성 검증이 빠진 상태 |
한계와 주의사항
첫째, 이 릴리스는 아직 베타다. 릴리스 공지가 "production use에 충분히 안정적"이라고 말하더라도, 운영자 입장에서는 GA와 베타를 같은 의미로 받아들이면 안 된다. 최소한 카나리 클러스터와 복구 훈련을 먼저 거쳐야 한다.
둘째, 동기 복제는 생각보다 보수적이다. table-level만 지원하고, standby는 읽기/쓰기 요청을 거부한다. 다지역 active-active처럼 오해하면 안 된다.
셋째, ZooKeeper 축소는 자동 완성이 아니다. peer storage 기본값은 여전히 zookeeper이며, 운영자가 원할 때 명시적으로 옮겨야 한다. 즉, 3.0은 ZooKeeper를 "당장 제거"하기보다 밖으로 드러난 의존을 줄이는 첫 번째 완성 단계로 보는 편이 맞다.
넷째, 증분 백업은 비용을 줄이는 기능이면서 동시에 WAL 보존 비용을 키우는 기능이다. 백업을 켜는 순간 저장소 운영이 따라와야 한다.
결론
HBase 3.0.0-beta-2를 한 문장으로 요약하면 이렇다.
"HBase가 이제는 ZooKeeper를 덜 드러내고, JDK 17 위에서, 복제·백업·추적을 운영자가 명시적으로 훈련할 수 있는 구조로 넘어간다."
이 변화는 화려한 새 API보다 더 중요하다. 실제 운영에서는 클라이언트 연결 방식, 복제 메타데이터 위치, DR 상태 전이, 백업 스케줄, tracing 배선이 곧 시스템의 생존성이다. HBase 3.0은 바로 그 생존성의 기준선을 다시 그은 릴리스다.
지금 2.x를 길게 유지하고 있는 팀이라면, 이번 베타를 "당장 올릴 것인가"보다 "우리 운영 습관 중 무엇이 3.0과 충돌하는가"를 찾는 기준점으로 읽는 편이 훨씬 생산적이다.
References
- Apache HBase Team, Apache HBase 3.0.0-beta-2 is now available for download, GitHub Release, published 2026-07-17. https://github.com/apache/hbase/releases/tag/rel/3.0.0-beta-2
- Apache HBase, HBASE 3.0.0-beta-2 Release Notes, accessed 2026-07-21. https://downloads.apache.org/hbase/3.0.0-beta-2/RELEASENOTES.md
- Apache HBase, HBASE Changelog for 3.0.0-beta-2, accessed 2026-07-21. https://downloads.apache.org/hbase/3.0.0-beta-2/CHANGES.md
- Apache HBase Reference Guide, Synchronous Replication, accessed 2026-07-21. https://hbase.apache.org/book.html#syncreplication
- Apache HBase Reference Guide, Backup and Restore and Technical Details of Incremental Backup and Restore, accessed 2026-07-21. https://hbase.apache.org/book.html#backuprestore
- Apache HBase Reference Guide, Tracing, accessed 2026-07-21. https://hbase.apache.org/book.html#tracing