추가 주제

추가 주제 (Additional Topics)

백업/복원 기능의 구성 키, 모범 사례, Amazon S3 활용 시나리오, 백업 데이터 보안, 그리고 증분 백업·복원의 기술적 세부 사항과 용량 계획까지 추가 주제를 살펴볼게요.

출처: 문서

본문

구성 키 (Configuration keys)

백업/복원 기능은 필수 구성 키와 선택적 구성 키를 모두 포함해요.

필수 속성 (Required properties)

hbase.backup.enable: 기능이 활성화되는지 여부를 제어해요(기본값: false). 이 값을 true로 설정해 주세요.

hbase.master.logcleaner.plugins: HBase Master에서 로그를 정리할 때 호출되는 클래스의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.master.BackupLogCleaner로 설정하거나 현재 값에 덧붙여 주세요.

hbase.procedure.master.classes: Master의 Procedure 프레임워크와 함께 호출되는 클래스의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager로 설정하거나 현재 값에 덧붙여 주세요.

hbase.procedure.regionserver.classes: RegionServer의 Procedure 프레임워크와 함께 호출되는 클래스의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager로 설정하거나 현재 값에 덧붙여 주세요.

hbase.coprocessor.region.classes: 테이블에 배포되는 RegionObserver의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.BackupObserver로 설정하거나 현재 값에 덧붙여 주세요.

hbase.coprocessor.master.classes: 테이블에 배포되는 MasterObserver의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.BackupMasterObserver로 설정하거나 현재 값에 덧붙여 주세요.

hbase.master.hfilecleaner.plugins: Master에 배포되는 HFileCleaner의 쉼표로 구분된 목록이에요. 이 값을 org.apache.hadoop.hbase.backup.BackupHFileCleaner로 설정하거나 현재 값에 덧붙여 주세요.

선택적 속성 (Optional properties)

hbase.backup.system.ttl: hbase:backup 테이블 데이터의 TTL(time-to-live)을 초 단위로 지정해요(기본값: forever). 이 속성은 hbase:backup 테이블이 생성되기 전에만 관련이 있어요. 이 테이블이 이미 존재하면 HBase shell의 alter 명령을 사용해 TTL을 수정해 주세요. 이 구성 속성의 영향에 대한 자세한 내용은 아래 섹션을 참고해 주세요.

hbase.backup.attempts.max: hbase 테이블 스냅샷을 찍을 때 수행할 시도 횟수(기본값: 10)예요.

hbase.backup.attempts.pause.ms: 실패한 스냅샷 시도 사이에 대기할 시간을 밀리초 단위로 지정해요(기본값: 10000).

hbase.backup.logroll.timeout.millis: Master의 프로시저 프레임워크에서 RegionServer가 WAL 롤링을 실행할 때까지 기다릴 시간을 밀리초 단위로 지정해요(기본값: 30000).

모범 사례 (Best Practices)

복원 전략을 수립하고 테스트하세요. (Formulate a restore strategy and test it.)

운영 환경에서 백업/복원 전략에 의존하기 전에, 백업이 어떻게 수행되어야 하는지, 그리고 더 중요하게는 복원이 어떻게 수행되어야 하는지를 파악하세요. 계획을 테스트해서 실행 가능한지 확인해 주세요. 최소한 운영 클러스터의 백업 데이터를 다른 클러스터나 서버에 저장하세요. 데이터를 더 안전하게 하려면 다른 물리적 위치에 있는 백업 위치를 사용하세요.

컴퓨터 시스템 문제로 기본 운영 클러스터에서 복구 불가능한 데이터 손실이 있다면, 같은 사이트의 다른 클러스터나 서버에서 데이터를 복원할 수 있을 수도 있어요. 하지만 사이트 전체를 파괴하는 재해는 로컬에 저장된 백업을 쓸모없게 만들어요. 백업 데이터와 필요한 리소스(컴퓨팅 용량과 운영자 전문성 모두)를 운영 사이트에서 충분히 떨어진 사이트에 저장해 데이터를 복원하는 것을 고려해 보세요. 기본 사이트 전체가 재앙(화재, 지진 등)을 겪는 경우, 원격 백업 사이트가 매우 가치 있을 수 있어요.

먼저 전체 백업 이미지를 확보하세요. (Secure a full backup image first.)

기준선으로, 증분 백업에 의존하기 전에 HBase 데이터의 전체 백업을 최소 한 번 완료해야 해요. 전체 백업은 소스 클러스터 밖에 저장되어야 해요. 완전한 데이터셋 복구를 보장하려면 기준선 전체 백업을 복원하는 옵션으로 복원 유틸리티를 실행해야 해요. 전체 백업은 데이터셋의 기반이에요. 증분 백업 데이터는 마지막으로 백업을 받은 시점으로 돌아가도록 복원 작업 중 전체 백업 위에 적용돼요.

전체 데이터셋의 논리적 하위 집합인 테이블 그룹에 백업 세트를 정의하고 사용하세요. (Define and use backup sets for groups of tables that are logical subsets of the entire dataset.)

테이블을 backup set(백업 세트)이라는 객체로 그룹화할 수 있어요. 반복적으로 백업하거나 복원할 것으로 예상하는 특정 테이블 그룹이 있을 때 백업 세트는 시간을 절약해 줘요.

백업 세트를 만들 때 그룹에 포함할 테이블 이름을 입력해요. 백업 세트는 관련 테이블 그룹뿐 아니라 HBase 백업 메타데이터도 유지해요. 이후에는 모든 테이블 이름을 개별적으로 입력하는 대신 백업 세트 이름을 호출해 명령 실행에 어떤 테이블이 적용되는지 표시할 수 있어요.

백업/복원 전략을 문서화하고, 가능하면 각 백업에 대한 정보를 기록하세요. (Document the backup and restore strategy, and ideally log information about each backup.)

지식 기반이 직원 이동 후 새 관리자에게 이전될 수 있도록 전체 과정을 문서화하세요. 추가 안전 조치로 각 백업의 데이터에 대한 달력 날짜, 시간, 기타 관련 세부 정보도 기록해 두세요. 이 메타데이터는 소스 클러스터 장애나 기본 사이트 재해 시 특정 데이터셋을 찾는 데 도움이 될 수 있어요. 모든 문서의 중복 사본을 유지하세요: 하나는 운영 클러스터 사이트에, 다른 하나는 백업 위치 또는 관리자가 운영 클러스터에서 원격으로 접근할 수 있는 곳에 두세요.

시나리오: Amazon S3에서 애플리케이션 데이터셋 보호하기 (Scenario: Safeguarding Application Datasets on Amazon S3)

이 시나리오는 가상의 소매 비즈니스가 백업을 사용해 애플리케이션 데이터를 보호한 다음 장애 후 데이터셋을 복원하는 방법을 설명해요.

HBase 관리 팀은 green이라는 애플리케이션을 위한 상호 연관된 정보를 가진 테이블 그룹의 데이터를 백업 세트로 저장해요. 이 예시에서 한 테이블은 거래 레코드를, 다른 테이블은 고객 세부 정보를 담고 있어요. 두 테이블은 그룹으로 백업되고 복구 가능해야 해요.

관리 팀은 또한 일별 백업이 자동으로 발생하도록 보장하기를 원해요.

다음은 green 애플리케이션의 데이터를 백업하고 나중에 복구하는 데 사용되는 명령의 단계와 예시에 대한 개요예요. 모든 명령은 HBase 슈퍼유저로 로그인한 상태에서 실행돼요.

green_set이라는 백업 세트가 transactions 테이블과 customer 테이블 모두의 별칭으로 생성돼요. 백업 세트는 각 테이블 이름을 입력하지 않도록 모든 작업에 사용될 수 있어요. 백업 세트 이름은 대소문자를 구분하며 인쇄 가능한 문자만으로, 공백 없이 구성해야 해요. $ hbase backup set add green_set transactions $ hbase backup set add green_set customer
green_set 데이터의 첫 백업은 전체 백업이어야 해요. 다음 명령 예시는 Amazon S3에 자격 증명을 전달하고 s3a: 접두사로 파일 시스템을 지정하는 방법을 보여줘요. $ ACCESS_KEY=ABCDEFGHIJKLMNOPQRST $ SECRET_KEY=123456789abcdefghijklmnopqrstuvwxyzABCD $ sudo -u hbase hbase backup create full\ s3a://$ACCESS_KEY:SECRET_KEY@prodhbasebackups/backups -s green_set
증분 백업은 재해 시 필수 데이터 복구를 보장하는 일정에 따라 실행되어야 해요. 이 소매 회사에서 HBase 관리 팀은 자동화된 일별 백업이 데이터를 충분히 안전하게 한다고 결정해요. 팀은 /etc/crontab에 정의된 기존 Cron 작업을 수정해 이를 구현할 수 있다고 결정해요. 결과적으로 IT는 다음 줄을 추가해 Cron 작업을 수정해요. @daily hbase hbase backup create incremental s3a://$ACCESS_KEY:$SECRET_KEY@prodhbasebackups/backups -s green_set
치명적인 IT 사고가 green 애플리케이션이 사용하는 운영 클러스터를 비활성화해요. 백업 클러스터의 HBase 시스템 관리자는 복구 목표에 가장 가까운 시점으로 green_set 데이터셋을 복원해야 해요. 백업 HBase 클러스터의 관리자가 접근 가능한 기록에 관련 세부 정보와 함께 백업 ID를 가지고 있다면, hdfs dfs -ls 명령으로 검색하고 백업 ID 목록을 수동으로 스캔하는 것은 건너뛸 수 있어요. 환경의 운영 클러스터 밖에서 백업 ID의 상세 로그를 지속적으로 유지·보호하는 것을 고려해 보세요. HBase 관리자는 백업이 저장된 디렉터리에서 다음 명령을 실행해 성공적인 백업 ID 목록을 콘솔에 출력해요. hdfs dfs -ls -t /prodhbasebackups/backups
관리자는 목록을 스캔해 복구 목표에 가장 가까운 날짜와 시간에 생성된 백업을 확인해요. 이를 위해 백업 ID가 Unix 시간으로 고유하게 식별되므로, 관리자는 복구 시점의 달력 타임스탬프를 Unix 시간으로 변환해요. 백업 ID는 역시간순으로 나열되어 가장 최근의 성공적인 백업이 먼저 나타나요. 관리자는 복원해야 하는 green_set 백업에 해당하는 명령 출력의 다음 줄을 발견해요. /prodhbasebackups/backups/backup_1467823988425
관리자는 백업 ID와 -overwrite 옵션을 호출해 green_set을 복원해요. -overwrite 옵션은 대상의 모든 기존 데이터를 잘라내고 백업 데이터셋의 데이터로 테이블을 채워요. 이 플래그가 없으면 백업 데이터가 대상의 기존 데이터에 추가돼요. 이 경우 관리자는 데이터가 손상되었으므로 데이터를 덮어쓰기로 결정해요. $ sudo -u hbase hbase restore -s green_set \ s3a://$ACCESS_KEY:$SECRET_KEY@prodhbasebackups/backups backup_1467823988425 \ -overwrite

백업 데이터의 보안 (Security of Backup Data)

데이터를 원격 위치로 복사하는 이 기능에서는 데이터 보안에 관한 절차적 우려를 명확히 밝히는 것이 중요해요. HBase 복제 기능처럼 백업/복원은 기업 경계 내에서 그 경계 밖의 일부 시스템으로 데이터를 자동 복사하는 구성을 제공해요. 민감한 데이터를 저장할 때, 백업/복원은 물론 HBase에서 데이터를 추출하는 어떤 기능도 데이터가 전송되는 위치가 보안 감사를 거쳐 인증된 사용자만 그 데이터에 접근할 수 있도록 보장하는 것이 필수적이에요.

예를 들어 데이터를 S3로 백업하는 위의 예시에서, 최소한의 인가된 사용자 집합만 이 데이터에 접근할 수 있도록 S3 버킷에 적절한 권한을 할당하는 것이 가장 중요해요. 데이터가 더 이상 HBase와 그 인증·인가 제어를 통해 접근되지 않으므로, 그 데이터를 저장하는 파일시스템이 비슷한 수준의 보안을 제공하는지 확인해야 해요. 이는 사용자가 스스로 구현해야 하는 수동 단계예요.

증분 백업·복원의 기술적 세부 사항 (Technical Details of Incremental Backup and Restore)

HBase 증분 백업은 HBase Export와 Import API만 사용하는 것 같은 이전의 직렬 백업/복원 솔루션 시도보다 HBase 테이블 이미지를 더 효율적으로 포착할 수 있게 해줘요. 증분 백업은 WAL(Write Ahead Logs, 로그 선행 쓰기)을 사용해 이전 백업 생성 이후의 데이터 변경을 포착해요. 백업에 포함해야 할 WAL을 추적하기 위해 모든 RegionServer에 걸쳐 WAL 롤(새 WAL 생성)이 실행돼요. WAL 외에도 증분 백업은 백업 대상 테이블의 벌크 로드된 HFiles도 추적해요.

증분 백업은 소스 클러스터에서 마지막 백업 이후 생성된 모든 WAL 파일을 수집하고, BACKUP_ROOT 아래의 .tmp 디렉터리에서 그것들을 HFiles로 변환한 다음, 이 HFiles를 백업 루트 디렉터리 아래의 최종 위치로 옮겨 백업 이미지를 형성해요. 또한 백업 시스템 테이블에서 벌크 로드 레코드를 읽고 해당 벌크 로드된 HFiles의 경로를 형성한 뒤 그 파일들을 백업 대상으로 복사해요. 벌크 로드된 파일은 (각 백업 루트에 대해) 백업에 포함될 때까지 보존돼요(cleaner 작업으로 삭제되지 않아요). 백업 파일을 대상 파일시스템으로 옮기는 데는 DistCp(분산 복사) 도구와 유사한 프로세스가 사용돼요.

테이블 복원 작업이 시작되면 두 단계 프로세스가 시작돼요. 첫째, 전체 백업 이미지에서 전체 백업이 복원돼요. 둘째, 마지막 전체 백업과 복원 중인 증분 백업 사이의 증분 백업(벌크 로드된 HFiles 포함)의 모든 HFiles가 HBase Bulk Load 유틸리티를 사용해 테이블에 벌크 로드돼요.

복원은 데이터가 재분배되어야 복원 작업이 성공적으로 완료되므로 실행 중인 HBase 클러스터에서만 할 수 있어요.

파일시스템 성장에 대한 경고 (A Warning on File System Growth)

참고로, 증분 백업은 HBase가 주로 데이터 내구성을 위해 사용하는 로그 선행 쓰기(write-ahead logs)를 유지하는 방식으로 구현돼요. 따라서 백업에 포함해야 할 모든 데이터가 시스템에 여전히 존재하는지 보장하기 위해, HBase 백업/복원 기능은 다음 증분 백업이 실행될 때까지 마지막 백업 이후의 모든 로그 선행 쓰기(WAL)를 유지해요.

HBase 스냅샷처럼 이는 대용량 테이블의 HBase HDFS 사용량에 예상보다 큰 영향을 줄 수 있어요. 백업/복원 기능을 활성화하고 사용할 때 주의하고, 특히 백업 세션을 적극적으로 사용하지 않을 때는 제거하는 것에 유의해 주세요.

백업/복원을 위해 유지되는 로그 선행 쓰기에 대한 유일한 자동 상한은 hbase:backup 시스템 테이블의 TTL에 기반하는데, 이 문서를 작성하는 시점 기준으로 이는 무한합니다(백업 테이블 항목이 자동으로 삭제되지 않음). 이는 관리자가 HDFS의 사용 가능한 공간 양에 상대적인 빈도의 일정으로 백업을 수행해야 함을 요구해요(예: HDFS 공간이 적을수록 더 공격적인 백업 병합과 삭제가 필요). 참고로, TTL은 HBase shell의 alter 명령을 사용해 hbase:backup 테이블에서 변경할 수 있어요. 시스템 테이블이 존재한 후 hbase-site.xml에서 hbase.backup.system.ttl 구성 속성을 수정하는 것은 효과가 없어요.

용량 계획 (Capacity Planning)

분산 시스템 배포를 설계할 때, 시스템의 데이터와 소프트웨어 요구사항을 고려해 충분한 컴퓨팅 용량이 사용 가능한지 확인하기 위해 몇 가지 기본적인 수학적 엄밀성이 실행되는 것이 중요해요. 이 기능에 대해, 백업/복원의 어떤 구현의 성능을 추정할 때 네트워크 용량의 가용성이 가장 큰 병목이에요. 두 번째로 비용이 큰 함수는 데이터를 읽고/쓸 수 있는 속도예요.

전체 백업 (Full Backups)

전체 백업의 지속 시간을 추정하려면 호출되는 일반적인 작업을 이해해야 해요.

각 RegionServer의 로그 선행 쓰기 롤: RegionServer마다 병렬로 수 초에서 수십 초. 각 RegionServer의 부하에 상대적.
테이블의 HBase 스냅샷 촬영: 수십 초. 테이블을 구성하는 region과 파일 수에 상대적.
스냅샷을 대상으로 내보내기: 아래 참고. 데이터 크기와 대상까지의 네트워크 대역폭에 상대적.

마지막 단계가 얼마나 걸릴지 근사하려면 하드웨어에 대한 몇 가지 가정을 해야 해요. 이것들이 여러분의 시스템에는 정확하지 않을 수 있음을 유의하세요 — 이것은 여러분이나 관리자가 시스템에 대해 알고 있는 숫자들이에요. 단일 노드에서 HDFS에서 데이터를 읽는 속도가 80MB/s로 제한되고(그 호스트에서 실행되는 모든 Mapper에 걸쳐), 최신 NIC(network interface controller)는 10Gb/s를 지원하고, top-of-rack 스위치가 40Gb/s를 처리할 수 있으며, 클러스터 간 WAN이 10Gb/s라고 가정해 보세요. 이는 원격지로 데이터를 1.25GB/s의 속도로만 보낼 수 있다는 뜻이에요 — 즉, ExportSnapshot에 참여하는 16개 노드(1.25 * 1024 / 80 = 16)가 클러스터 간 링크를 완전히 포화시킬 수 있어요. 클러스터에 더 많은 노드가 있으면 여전히 네트워크를 포화시킬 수 있지만 단일 노드에 대한 영향은 줄어들어 로컬 SLA를 충족하는 데 도움이 돼요. 스냅샷 크기가 10TB라면, 이 전체 백업은 대략 2.5시간이 걸려요 (10 * 1024 / 1.25 / (60 * 60) = 2.23hrs).

일반적으로, 로컬 클러스터와 원격 저장소 사이의 WAN 대역폭이 전체 백업 속도의 가장 큰 병목일 가능성이 매우 높아요.

백업의 컴퓨팅 영향을 "운영 시스템"으로 제한하는 것이 우려일 때, 위 공식을 hbase backup create의 선택적 커맨드라인 인자인 -b, -w, -q와 함께 재사용할 수 있어요. -b 옵션은 각 작업자(Mapper)가 데이터를 기록할 대역폭을 정의해요. -w 인자는 DistCp 작업에서 생성될 작업자 수를 제한해요. -q는 사용자가 YARN 큐를 지정할 수 있게 해서 작업자가 생성될 특정 노드를 제한할 수 있어요 — 이것은 복사를 수행하는 백업 작업자를 중요하지 않은 노드 집합으로 격리할 수 있어요. -b와 -w 옵션을 앞의 방정식과 연결하면: -b는 각 노드가 전체 80MB/s로 데이터를 읽는 것을 제한하는 데 사용되고, -w는 작업이 16개 작업자 태스크를 생성하는 것을 제한하는 데 사용돼요.

증분 백업 (Incremental Backup)

전체 백업에서 했던 것처럼, 실행 시간과 비용을 근사하려면 증분 백업 프로세스를 이해해야 해요.

마지막 전체 또는 증분 백업 이후의 새 로그 선행 쓰기 식별: 무시할 만함. 백업 시스템 테이블의 사전 지식.
WAL에 해당하는 "최소화된" HFiles 읽기, 필터링, 쓰기: 데이터 쓰기 속도가 지배적. HDFS 쓰기 속도에 상대적.
백업 시스템 테이블에서 벌크 로드 레코드 읽기, 벌크 로드된 HFiles의 경로 형성, 백업 대상으로 복사.
HFiles를 대상으로 DistCp: 위 참고.

두 번째 단계에서 이 작업의 지배적 비용은 데이터 재작성(WAL의 데이터 대부분이 보존된다는 가정 하에)이 될 거예요. 이 경우 노드당 총 30MB/s의 쓰기 속도를 가정할 수 있어요. 16노드 클러스터 예시를 계속하면, 50GB 데이터에 대해 이 단계를 수행하는 데 약 15분이 필요해요 (50 * 1024 / 60 / 60 = 14.2). DistCp MapReduce 작업을 시작하는 데 걸리는 시간은 실제 데이터 복사에 걸리는 시간(50 / 1.25 = 40초)을 지배할 가능성이 높으며 무시할 수 있어요.

백업/복원 유틸리티의 제한 사항 (Limitations of the Backup and Restore Utility)

직렬 백업 연산 (Serial backup operations) 백업 연산은 동시에 실행할 수 없어요. 연산에는 create, delete, restore, merge 같은 작업이 포함돼요. 하나의 활성 백업 세션만 지원돼요. HBASE-16391이 다중 백업 세션 지원을 도입할 거예요.

백업 취소 수단 없음 (No means to cancel backups) 백업과 복원 연산 모두 취소할 수 없어요. (HBASE-15997, HBASE-15998) 백업을 취소하는 해결 방법은 클라이언트 측 백업 명령을 종료(control-C)하고, 관련 MapReduce 작업이 모두 종료되었는지 확인한 다음, hbase backup repair 명령을 실행해 시스템 백업 메타데이터가 일관적인지 확인하는 것이에요.

백업은 단일 위치에만 저장 가능 (Backups can only be saved to a single location) 백업 정보를 여러 위치로 복사하는 것은 사용자의 몫으로 남겨져 있어요. HBASE-15476이 다중 백업 대상을 내재적으로 지정하는 기능을 도입할 거예요.

HBase 슈퍼유저 접근 필요 (HBase superuser access is required) HBase 슈퍼유저(예: hbase)만 백업/복원을 수행할 수 있어, 공유 HBase 설치에서는 문제가 될 수 있어요. 현재의 완화 조치는 백업/복원 전략을 구축·배포하기 위해 시스템 관리자와의 조정이 필요해요 (HBASE-14138).

백업 복원은 온라인 연산 (Backup restoration is an online operation) 백업에서 복원을 수행하려면 현재 구현의 조건(caveat)으로서 HBase 클러스터가 온라인 상태여야 해요 (HBASE-16573).

일부 연산은 실패할 수 있고 다시 실행이 필요해요 (Some operations may fail and require re-run) HBase 백업 기능은 주로 클라이언트가 주도해요. HBase Connection에 표준 HBase 재시도 로직이 내장되어 있지만, 연산 실행 시 지속적인 오류가 클라이언트로 전파될 수 있어요(예: region 분할로 인한 스냅샷 실패). 백업 구현은 향후 ProcedureV2 프레임워크로 이동되어 일시적/재시도 가능한 장애에 대한 추가 견고성을 제공해야 해요. hbase backup repair 명령은 시스템이 자동으로 감지하고 복구할 수 없는 상태를 교정하기 위한 것이에요.

공개 API 선언 회피 (Avoidance of declaration of public API) 이 기능과 상호작용하는 Java API가 존재하고 그 구현이 인터페이스와 분리되어 있지만, 사용자에게 제공하려는 것이 정확히 맞는지 결정하기 위한 충분한 엄밀성이 적용되지 않았어요. 따라서 사용자가 기능을 사용하기 시작하면 호환성을 깨뜨릴 수정이 있을 것으로 예상되어 Private 대상으로 표시되어 있어요 (HBASE-17517).

백업/복원에 대한 전역 지표 부족 (Lack of global metrics for backup and restore) 개별 백업/복원 연산에는 그 연산이 포함한 작업량에 대한 지표가 있지만, 정보를 제공하는 중앙 위치(예: Master UI)는 없어요 (HBASE-16565).

더 알아보기 (Learn more)

백업/복원 명령 실행법과 운영은 Backup and Restore commands와 Administration of Backup Images 문서를 보시길 권해요.