안녕하세요. HBase 팀 이욱입니다. 저는 16년간 데이터베이스 엔지니어로 일해 왔습니다. DBA(database administrator)의 업무에는 다양한 작업이 있으며, 그중에서 특히 데이터 마이그레이션은 일상다반사처럼 자주 수행하는 작업인데요. 그럼에도 DBA에게는 언제나 힘들고 때론 도전적인 작업입니다. 마이그레이션 작업 중에는 언제든 데이터 유실이나 데이터 정합성 관련 문제가 발생할 수 있기 때문입니다.특히 RDBMS가 아닌 NoSQL인 HBase의 데이터 마이그레이션 작업에는 더욱 많은 공수와 도전이 수반됩니다. 저 역시 RDBMS에서 많은 데이터 마이그레이션 작업을 수행해 왔지만, NoSQL인 HBase 마이그레이션은 클러스터 수가 훨씬 많고 데이터 크기가 수백 테라바이트에서 수백 페타바이트에 달하기 때문에 더욱 어렵습니다.이번 글에서는 최근에 진행한 Anzen 서비스(LINE Official Account 서비스)의 HBase 마이그레이션 작업 과정을 공유하고 작업하면서 얻은 지식을 나누려고 합니다. 이 글이 HBase에서 데이터 마이그레이션 작업을 계획하고 계신 분들께 도움이 되기를 바라며 시작하겠습니다.Anzen 서비스의 HA(high availablitiy) 프로젝트를 진행하게 된 배경은 크게 두 가지입니다.서비스의 고가용성 확보LINE 앱에서는 기업이나 단체, 공공기관 등에서 사용할 수 있는 공식 계정 서비스인 LINE Official Account 서비스를 제공하고 있습니다. 이 서비스에서 각 공식 계정은 Messaging API라는 API를 이용해 메시지를 주고받으며, 이 API에 대한 요청과 결과 로그는 HBase에 저장합니다.이 로그는 LINE Official Account의 각 사용자에게 얼마의 비용을 청구할지 산정하는 데 사용하는 중요한 데이터인데요. 이전에는 장애가 발생하면 이 데이터가 유실돼 정확한 데이터를 산출할 수 없는 문제가 발생했었습니다. 이에 IDC 장애나 자연재해 발생 시에도 서비스를 지속할 수 있도록 HA 환경을 구축하기로 결정했습니다.기존에 사용하던 Cloudera 제품의 라이선스 비용이 날로 증가하며 점점 부담이 커지고 있었습니다. 이에 라이선스 비용을 줄이고 기술을 내재화하기 위해 오픈소스로 전환하는 것을 검토했고, 내부에서 Apache HBase를 이용해 준비하며 테스트한 결과 내재화에 성공해(참고: HBase 오픈소스 전환을 위한 HBH(HitBase Handler) 개발기) 마이그레이션 프로젝트가 시작됐습니다.HBase는 대용량 데이터를 처리할 수 있는 분산형 NoSQL 데이터베이스로, 수평적 확장성이 뛰어납니다. 수십억 개의 행과 열을 효율적으로 처리할 수 있으며, 저비용으로 확장할 수 있습니다. RDBMS와 달리 스키마가 유연하고, 비정형 데이터를 쉽게 저장할 수 있어 빅데이터 처리에 적합합니다. 칼럼 기반 저장 방식을 사용하기 대문에 조회와 쓰기 속도가 빠릅니다. HBase는 특히 빅데이터를 처리하거나 실시간으로 데이터를 처리해야 하는 시스템에서 RDBMS보다 더 적합한

안녕하세요. HBase 팀 김영주, 김동의입니다. HBase 팀에서는 LY의 많은 서비스를 지원하기 위해 수천 대 규모의 HBase를 운영하고 있습니다. HBase는 Hadoop 기반 칼럼형 분산 데이터베이스로 확장이 용이해 대용량 데이터를 다룰 때 많이 사용하는데요. 회사가 성장하면서 많은 서비스에서 HBase를 사용하고자 하는 니즈가 생겼고, 이를 지원하기 위해 저희 팀에서 전문적으로 HBase를 운영하고 있습니다.HBase 도입 초기에는 Cloudera사의 Cloudera's Distribution for Hadoop(이하 CDH)을 솔루션으로 사용했습니다. CDH가 Hadoop 관련 운영 도구 중 주류였고 커뮤니티를 중심으로 많은 자료를 이용할 수 있었기 때문입니다.하지만 현재 이 솔루션을 탈피하기 위한 작업을 진행하고 있습니다. 몇 가지 이유가 있는데요. 첫 번째 이유는 라이선스 비용입니다. 초기에는 라이선스 비용이 크지 않았지만 서비스가 늘어나고 노드 수가 많아지면서 라이선스 비용이 점점 증가해 무시할 수 없는 수준이 되었습니다. 두 번째 이유는, 상용 배포판의 매니저와 에이전트가 프로세스를 관리하기 때문에 사내 프라이빗 클라우드 플랫폼인 Verda에서 제공하기가 어려울 것이라고 판단했기 때문입니다. 세 번째 이유는 상용 배포판을 계속 사용하면 Cloudera사의 기술 지원에 의존할 수밖에 없어서 팀의 기술력 향상 측면에서 부정적이라고 판단했기 때문입니다.이와 같은 이유로 HBase 팀에서는 CDH로 운영하고 있는 HBase 클러스터를 모두 오픈소스 HBase(이하 Apache HBase)로 이관하기로 결정하고, 내부적으로 HitBase라고 이름을 지었습니다. 또한 이관하기 위해서, Cloudera사의 클러스터 관리 도구인 Cloudera Manager(이하 CM)을 대체할 수 있는 HitBase Handler(이하 HBH)라는 관리용 도구를 만들기로 결정한 뒤 개발에 돌입해 2023년에 HBH v1 버전을 릴리스했습니다.개발 완료 후 실제 운영 중인 서비스를 순차적으로 HitBase로 이관했고, 현재 약 50%의 HBase가 HitBase로 운영되고 있습니다. 이번 글에서는 저희가 2023년 한 해 동안 HBH를 어떻게 개발했는지 공유하려고 합니다.팀 내에서 개발에 투자할 수 있는 시간과 인력을 고려했을 때 처음부터 CM에 포함된 모든 기능을 HBH에서 지원하도록 만드는 것은 어려울 것이라고 판단했습니다. 요구 사항을 분석하며 논의한 결과, 우선 필요한 기능부터 넣은 뒤 CM에서 제공하는 기본 기능을 구현했고, 그 외 그동안 운영하면서 필요하다고 판단했던 리전 복구 및 백업과 실시간 인스펙터 기능을 추가했습니다. 아래는 HBH와 CM의 기능을 비교한 표입니다.HBH 개발 과정은 다음과 같습니다. 각 과정을 하나씩 살펴보겠습니다.Apache HBase로 전환하기 위해서는 무엇보다도 문제없이 작동하는 HBase 바이너리 파일이 필요합니다. 이때 Hadoop 호환성 이슈를 피하려면 안정적이고 검증된 버전을 사용할 필요가 있는데요.

네이버 검색에서는 검색 서비스 제공에 필요한 대규모 데이터를 HBase 기반의 데이터 저장소인 Cuve에 저장하고 있습니다. HBase는 Java 기반의 오픈 소스 NoSQL 분산 데이터베이스입니다. HDFS와 함께 사용되며 내구성(durability)과 지속성(persistence)을 보장합니다. 지연 시간이 매우 짧고 거의 실시간에 가까운 랜덤 읽기와 랜덤 쓰기를 지원합니다.HBase 쓰기 경로는 다음과 같습니다.그림 1 HBase 쓰기 경로(원본 출처: Apache HBase Write Path)HBase는 쓰기 요청을 처리할 때 HDFS에 데이터를 바로 쓰지 않고 RegionServer의 MemStore라고 불리는 메모리 영역에 데이터를 먼저 저장합니다. MemStore에 저장된 데이터는 Flush 과정을 통해서 주기적으로 HDFS에 저장됩니다. HDFS에 데이터를 저장하기 전에 서버에 장애가 발생한다면 메모리 영역인 MemStore에 저장된 데이터는 유실될 수 있습니다. HBase는 데이터 유실을 방지하기 위해 WAL(Write-Ahead Log)에 모든 변경 사항을 기록합니다.WAL은 MySQL의 BIN 로그와 비슷하게 모든 변경 사항을 로그에 기록하여 데이터 내구성을 보장하는 방법입니다. 변경 사항은 일반적으로 영구적인 데이터 저장 장치(예: HDD, SSD 등)에 저장하는데 HBase는 HDFS에 저장합니다. 서버에 장애가 발생하여 메모리의 모든 데이터가 유실되어도 WAL을 이용해 복구할 수 있습니다.HBase 버전 1에서는 HDFS가 제공하는 DFSOutputStream을 통해서 WAL 데이터를 HDFS에 저장했습니다. 하지만 HDFS 쓰기 파이프라인을 따라 데이터가 3개의 DataNode에 쓰이다 보니 지연 시간이 증가하는 문제와 WAL 데이터를 쓰는 과정에서 오류가 발생했을 때 파이프라인 복구 실패로 인해 사용자 요청 처리가 지연되는 문제가 있었습니다. Cuve에서도 HBase 버전 1 클러스터에서 WAL 데이터 쓰기 파이프라인 복구 실패로 사용자의 요청을 처리하지 못하여 SLA를 위반하는 장애가 발생했었습니다. HBase 버전 2에서는 HBase에 WAL 쓰기 전용 Fan-out DFSOutputStream이 구현되어 이러한 문제가 해결되었습니다.이 글에서는 Cuve에서 HBase 버전 1 기반으로 운영하던 HBase 클러스터에서 어떤 오류가 발생했는지 알아보고 HDFS 쓰기 파이프라인과 HBase의 Fan-out DFSOutputStream에서 HDFS 프로토콜을 어떻게 활용했는지 알아보겠습니다.이 글은 HDFS와 HBase에 대한 기본적인 개념과 사용법에 익숙하다고 가정하고 있습니다. HDFS와 HBase의 구성 요소와 특징은 Hadoop 문서 HDFS Architecture와 HBase 문서 Architecture Overview를 참고하기 바랍니다.파이프라인 복구 실패로 인한 장애 상황HBase 버전 1의 RegionServer는 HDFS가 제공하는 DFSOutputStream을 통해 WAL 데이터를 쓴다.

들어가며안녕하세요. Global EC(Global E-Commerce, 이하 GEC)에서 쇼핑 개발을 담당하고 있는 김성도입니다. LINE 쇼핑에서는 실시간으로 상품 정보를 업데이트할 수 있는 LINE 쇼핑 플랫폼을 사용해 모든 상품 정보를 취합하고 있으며, 취합한 상품 정보는 사용자의 쇼핑 경험을 개선하기 위해 검색 엔지니어와 데이터 엔지니어에게 제공하고 있습니다. 수억 개에 이르는 상품 정보를 서비스에 영향을 주지 않으면서 ETL(Extract, Trasnform, Load)하는 작업은 쉽지 않은 일입니다. 그런데 여기에 한술 더 떠서 실시간으로 업데이트까지 하려면 어떻게 해야 할까요? 이번 글에서는 이 어려운 과제를 해결하기 위해 어떤 과정을 거쳤는지 소개하려 합니다.글은 다음과 같은 순서로 진행합니다.요구 사항 분석Hadoop 에코 시스템에서 작동하는 Hive를 사용한다는 전제가 있습니다. 이를 염두에 두고 요구 사항을 '데이터베이스 부하 감소'와 '업데이트 주기 개선', '정합성 유지', 세 항목으로 나눠 살펴보겠습니다.데이터베이스 부하 감소이번 개선 작업 전에는 상품 정보를 모두 받아오기 위해서 MongoDB를 풀 스캔하는 방식으로 ETL 작업을 해왔습니다. 평소에 가해지는 부하량만 놓고 보면 이와 같은 방식이 문제 되지 않지만, 평소보다 상품 정보 업데이트가 많이 발생하거나 많은 사용자가 몰릴 때에는 문제가 발생할 수 있습니다. 데이터베이스에 적정량 이상의 부하가 가해지면 자연스레 서비스에 영향을 미치기 때문입니다. 이로 인해 판매자가 상품 정보의 가격을 변경했지만 바로 반영되지 않는다거나 사용자가 상품을 조회했을 때 결과가 제대로 나오지 않는 현상이 발생할 수 있습니다. 이런 상황에서는 아무래도 서비스에 직접적인 영향을 미치지 않기 때문에 상대적으로 중요도가 떨어지는 ETL 작업을 포기할 수밖에 없습니다. 이와 같은 현상을 사전에 방지하려면 데이터베이스에 부하를 주지 않는 방법을 생각해야 합니다.업데이트 주기 개선이번 개선 작업 전에는 업데이트 주기가 하루였고 이보다 더 짧게 만들기는 어려웠습니다. 주기가 짧아질수록 데이터베이스에 더 큰 부하를 유발하기 때문입니다. 하지만 ETL 데이터를 사용하는 쪽에서는 주기가 짧아질수록 좋습니다. 주기가 짧아질수록 아래와 같이 할 수 있는 작업이 더 많아지기 때문입니다.업무 시간 중에 업데이트된 상품 정보를 사용해 통계 산출상품 정보 데이터로 만드는 검색 피처(feature) 갱신 주기 단축상품 정보 수신 여부 확인이와 같은 작업을 통해 LINE 쇼핑에 상품을 등록한 판매자에게 정확한 통계 정보를 제공해 상품 판매에 도움을 줄 수 있고, LINE 쇼핑 사용자에게 최신화한 관련 상품 정보를 더욱 풍부하게 보여줘 더 나은 쇼핑 경험을 제공할 수도 있습니다.정합성 유지기존에 사용하던 ETL 데이터와 개선하며 만든 데이터는 동일해야 합니다. UPDATE, CREATE, DELETE 이벤트가 정상적으로 반영되지 않으면 정합성을 유지할 수 없으며, 이는 의사 결정에 잘못된 데이터를 사용하거나 저품