Aerospike에서 Bigtable로 마이그레이션
이 문서에서는 Aerospike에서 Bigtable로 데이터를 마이그레이션하는 과정을 안내합니다. 어댑터 라이브러리와 같은 오픈소스 도구를 사용하여 마이그레이션을 실행하는 방법을 설명합니다.
마이그레이션을 시작하기 전에 Aerospike 사용자를 위한 Bigtable을 숙지하세요.
마이그레이션 개요
최소한의 다운타임 또는 다운타임 없이 Aerospike에서 Bigtable로 데이터를 마이그레이션할 수 있습니다.
다음 다이어그램은 마이그레이션 단계를 보여줍니다.
- 진행 중인 변경사항 스트리밍: Aerospike Kafka 소스 (아웃바운드) 커넥터 및 Kafka Connect Bigtable 싱크 커넥터를 사용하여 Aerospike에서 Bigtable로 진행 중인 업데이트를 복제합니다.
- 백업 가져오기: Aerospike 백업을 만들고
AerospikeBackupToBigtableDataflow 작업을 사용하여 Bigtable로 가져옵니다. - 컷오버 실행: 애플리케이션 트래픽을 Bigtable로 이동합니다.
마이그레이션 범위 및 호환성
Bigtable은 유형화된 bin이 아닌 원시 바이트에서 작동하므로 마이그레이션 프로세스에는 Aerospike 기능과 기능을 호환되는 Bigtable 구조에 매핑하는 작업이 포함됩니다. 어댑터 라이브러리는 구조적 호환성을 달성하고 객체 직렬화와 같은 격차를 해결하는 데 필요한 도구를 제공합니다. 하지만 사용자 정의 함수 (UDF)와 같은 특정 기능은 시스템 간의 근본적인 차이로 인해 마이그레이션할 수 없습니다.
다음 표에는 마이그레이션 프로세스에서 Aerospike 기능을 처리하는 방법이 요약되어 있습니다.
| 기능 | 지원 | 설명 |
|---|---|---|
| Aerospike 하이브리드 메모리 아키텍처 (HMA) | 지원됨 | SSD 스토리지 계층 또는 인메모리 계층으로 마이그레이션됩니다. Bigtable Enterprise Plus 버전은 Aerospike 성능과 유사한 밀리초 미만의 응답 시간이 필요한 지연 시간에 민감한 워크로드에 인메모리 스토리지에 대한 액세스를 제공합니다. |
스칼라 (Int, Float, String, Bool) |
지원됨 | Bigtable 셀로 마이그레이션됩니다. |
| 목록 및 맵 | 지원됨 | 맵에는 문자열 키가 있어야 합니다. 목록과 맵은 어댑터 라이브러리에 의해 별도의 열로 직렬화됩니다. |
| 보조 색인 | 일부 지원됨 | 직접 마이그레이션되지 않습니다. 비동기 보조 색인으로 다시 구현해야 합니다. |
| 레코드 수준 TTL (수명) | 지원됨 | Bigtable에서 column family 수준으로 구성되거나 셀당 시뮬레이션됩니다. |
| UDF | 지원되지 않음 | 커스텀 서버 측 로직을 클라이언트 측 애플리케이션으로 이동해야 합니다. |
| HyperLogLog | 지원되지 않음 | 마이그레이션 프로세스에서 지원되지 않습니다. |
| GeoJSON | 지원되지 않음 | 마이그레이션 프로세스에서 지원되지 않습니다. |
| 레코드 키 | 지원되지 않음 | 레코드 키는 직접 마이그레이션되지 않습니다. 대신 마이그레이션은 레코드 다이제스트를 row key로 사용합니다. |
시작하기 전에
마이그레이션을 시작하기 전에 다음 준비 단계를 완료하여 위험을 줄이고 원활한 전환을 보장하세요.
- 데이터 검증: Aerospike 배포가 지원되지 않는 데이터 유형, 보조 색인 또는 UDF에 의존하지 않는지 확인합니다. 안전 장치로 데이터의 대표 하위 집합을 Bigtable로 가져오고 스키마 설계를 검증할 수 있습니다.
- 인프라 프로비저닝: 마이그레이션 파이프라인에 필요한 서비스(Bigtable, Kafka, Kafka Connect)를 설정합니다.
- 용량 계획: 예상 워크로드를 처리할 수 있는 충분한 용량으로 Bigtable을 프로비저닝합니다. 기존 Aerospike 클러스터와 가까운 리전을 선택합니다. 필요한 리소스 추정에 관한 안내는 Bigtable 성능 이해를 참조하세요.
- 스토리지 계층: 밀리초 미만의 응답 시간이 필요한 워크로드의 경우 Bigtable 인메모리 계층을 사용하는 것이 좋습니다. 이 계층은 RAM에 데이터를 저장하여 읽기 중심 또는 지연 시간에 민감한 애플리케이션에 최고의 성능을 제공합니다. 자세한 내용은 인메모리 계층 개요를 참조하세요.
- 액세스 및 네트워킹 구성: 적절한 ID 및 액세스 관리 (IAM) 역할을 할당하고 네트워크 연결을 보장합니다.
- 모니터링 및 오류 보고 사용 설정: 로깅, 측정항목, 알림을 비롯한 새 환경의 관측 가능성을 구성합니다.
- 기준 성능 벤치마킹: 마이그레이션 후 성능을 검증하기 위한 참조를 제공하도록 현재 시스템 성능을 기록합니다.
- 백업 만들기: Aerospike 데이터의 전체 백업을 만듭니다.
- 테스트 마이그레이션 실행: 프로덕션 마이그레이션을 시도하기 전에 스테이징 환경에서 설정을 검증합니다.
데이터 이전
다음 단계를 완료하여 Aerospike에서 Bigtable로 데이터를 마이그레이션합니다.
변경 내역 시작
Aerospike 변경 내역을 사용 설정하면 Aerospike Kafka 소스 (아웃바운드) 커넥터가 Aerospike 레코드 업데이트를 Kafka 주제에 게시하기 시작합니다. Kafka에 변경사항을 버퍼링할 수 있는 충분한 스토리지 용량이 있는지 확인하고 JSON 형식으로 데이터를 출력하도록 커넥터를 구성합니다.
다음은 Kafka 커넥터 구성 예시입니다.
service:
port: <port_to_run_on>
producer-props:
bootstrap.servers:
- <kafka_host>
format:
mode: json
metadata-key: metadata
routing:
mode: static
destination: <kafka_topic>
Aerospike Kafka 소스 (아웃바운드) 커넥터를 사용하여 Kafka와 통신하려면 Aerospike 교차 데이터 센터 복제 (XDR)이 필요합니다. 이 기능은 지연 시간이 더 긴 링크를 통해 클러스터 변경사항을 비동기식으로 복제합니다. XDR은 Aerospike Enterprise 버전에서만 사용할 수 있습니다. Aerospike Community Edition을 사용하는 경우 Enterprise 버전으로 전환하거나 AerospikeBackupToBigtable Dataflow 작업만 사용하여 오프라인 마이그레이션을 실행합니다.
Aerospike의 XDR 구성 예시는 다음과 같습니다.
xdr {
dc aerospike-kafka-source {
connector true
node-address-port <aerospike_connect_host> <aerospike_connect_port>
namespace <your_namespace_to_replicate> {
}
}
}
Aerospike에서 데이터 내보내기
변경 내역을 시작한 후 기존 Aerospike 데이터 세트의 백업을 생성합니다. asbackup 명령줄 도구를 사용하여 Aerospike 데이터베이스 클러스터에서 백업을 만듭니다. 일부 업데이트는 백업과 변경 내역 모두에 표시될 수 있으며 이는 예상되는 동작이며 마이그레이션에 영향을 미치지 않습니다. 복원 중에 동시 가져오기를 허용하려면 백업을 여러 파일로 분할합니다.
Bigtable로 데이터 가져오기
백업된 데이터를 Bigtable로 가져오려면 다음 단계를 따르세요.
- Cloud Storage 버킷에 백업을 업로드합니다.
AerospikeBackupToBigtableDataflow 작업을 실행하여 백업을 Bigtable로 가져옵니다. 백업이 여러 파일로 분할된 경우 작업은 이를 동시에 처리합니다. 쓰기 부하 증가를 처리하고 최적의 처리량을 유지하려면 추가 Bigtable 리소스를 프로비저닝합니다.
Bigtable에 레코드 업데이트 적용
백업을 Bigtable로 가져온 후 Kafka Connect Bigtable 싱크 커넥터를 사용하여 Kafka의 버퍼링된 레코드 업데이트를 Bigtable에 적용합니다.
메시지를 호환되는 형식으로 변환
Aerospike 마이그레이션 도구에는 Kafka Connect 내에서 실행되는 Replicator SMT가 포함되어 있습니다. 복제기는 Aerospike Kafka 소스 (아웃바운드) 커넥터에서 게시한 메시지를 Bigtable에 레코드를 쓰는 대상 싱크와 호환되는 형식으로 변환합니다. 싱크는 Aerospike가 변경사항을 스트리밍하는 방식과 다른 특정 형식으로 데이터를 예상하므로 변환이 필요합니다.
다음 표를 사용하면 지정된 처리량을 달성하는 데 필요한 머신 리소스를 추정할 수 있습니다.
| 레코드 구조 | 처리량 | p99 지연 시간 |
|---|---|---|
| 평면 | vCPU당 초당 최대 3,700개 레코드 | 300ms |
| Nested | vCPU당 초당 최대 2,600개 레코드 | 300ms |
이러한 추정치는 JSON 직렬화된 레코드의 크기가 1KB라고 가정합니다. 파싱 시간은 메시지 구조의 복잡성에 따라 증가합니다. 즉, Aerospike 레코드에 저장된 중첩 객체를 파싱하는 데 시간이 더 오래 걸립니다.
consumer_lag 측정항목을 사용하여 처리 큐에 있는 메시지 수를 확인하고 복제 지연 시간을 측정할 수 있습니다. 싱크가 주제의 메시지 백로그를 처리하면 소비자 지연 시간이 0에 가까워질 때까지 감소합니다. 이때 싱크는 Aerospike 업데이트를 거의 실시간으로 처리하여 전환을 준비합니다. sink-record-active-count를 사용하여 이미 처리된 메시지 수를 확인할 수 있습니다.
Kafka Connect Bigtable 싱크 커넥터로 메시지 수집
Kafka Connect Bigtable 싱크 커넥터는 Kafka에서 Bigtable로 메시지를 수집합니다. 커넥터를 구성할 때 Bigtable의 대상 행에 작성된 레코드가 최신 레코드인지 확인하려면 insert.mode를 REPLACE_IF_NEWEST로 설정합니다. 자세한 내용은 Kafka Connect Bigtable 싱크 커넥터 구성을 참조하세요.
다음 표에는 다양한 워크로드에 필요한 지연 시간과 컴퓨팅 리소스에 관한 안내가 나와 있습니다.
| 레코드 구조 | 처리량 | p99 지연 시간 |
|---|---|---|
| 평면 | vCPU당 초당 최대 3,700개 레코드 | 74 ms |
| Nested | vCPU당 초당 최대 3,700개 레코드 | 100 ms |
이러한 추정치는 JSON 직렬화된 레코드의 크기가 1KB라고 가정합니다. 보고된 지연 시간은 싱크의 처리 시간입니다. Bigtable에 쓰기 요청을 하는 데 약 600ms의 추가 오버헤드가 있다고 가정합니다.
Bigtable로 전환
Bigtable을 기본 데이터베이스로 사용하도록 애플리케이션을 전환합니다.
읽기-쓰기 일관성을 보장하려면 복제 지연 시간이 0에 도달할 때까지 애플리케이션을 일시적으로 종료합니다. 이렇게 하면 변경사항이 손실되지 않고 데이터 읽기가 최신 상태를 반영합니다.
예를 들어 컷오버 직전에 Aerospike에 적용된 변경사항이 아직 Bigtable로 복제되지 않아 비활성 읽기가 발생할 수 있습니다. 이 시나리오를 방지하려면 consumer_lag 및 sink-record-active-count 측정항목이 0에 도달할 때까지 애플리케이션을 오프라인 상태로 유지합니다. 보류 중인 변경사항이 모두 전파된 후 Bigtable을 기본 데이터베이스로 사용하여 애플리케이션을 다시 시작합니다.
라이브 마이그레이션은 다운타임을 방지할 수 있지만 다음과 같은 제약사항이 있습니다.
- Bigtable에 적용된 변경사항은 Aerospike로 다시 복제되지 않습니다.
- Aerospike에서 발생한 변경사항이 지연되어 Bigtable에 표시될 수 있습니다.
- Aerospike의 지연된 변경사항이 Bigtable의 최신 업데이트를 덮어쓸 수 있습니다.
배포를 확인합니다.
배포 후 오류율, 지연 시간, 비용과 같은 측정항목을 검토하여 애플리케이션 성능을 검증합니다. 데이터 무결성 검사를 실행할 수도 있습니다.
모니터링 및 관측 가능성
마이그레이션 전반에 걸쳐 다음 측정항목을 모니터링합니다.
- 총 지연 시간: Kafka 소비자 지연 시간과
sink-record-active-count를 더한 값으로 계산됩니다. 이러한 측정항목은 Bigtable이 Aerospike보다 얼마나 뒤처져 있는지 나타냅니다. 트래픽을 Bigtable로 리디렉션하기 전에 안정적인 지연 시간 값이 필요합니다. - CPU 및 메모리 사용률: 모든 변경 내역 파이프라인 구성요소의 CPU 및 메모리 사용률을 모니터링합니다.
- Kafka 스토리지 용량: 자체 관리형 Kafka 배포의 용량을 모니터링합니다. 스토리지가 가득 차면 새 이벤트를 버퍼링할 수 없어 마이그레이션이 실패합니다.
- 애플리케이션 오류율: 모든 변경 내역 파이프라인 요소의 오류율과 오류 출력을 모니터링합니다.
제한사항
다음 섹션에서는 Aerospike에서 Bigtable로 데이터를 마이그레이션할 때 고려해야 할 제한사항을 설명합니다.
마이그레이션 중 데이터 일관성
asbackup 도구를 사용하여 Aerospike 백업을 생성할 때 백업 프로세스가 원자성 백업을 지원하지 않으므로 백업 프로세스 중에 수정된 레코드가 제외될 수 있습니다. 이 제한사항은 모든 변경사항이 변경 내역에 표시되므로 정확성에 영향을 미치지 않습니다.
Bigtable로 백업을 가져오는 동안 각 행은 마지막 업데이트 시간 (LUT) 타임스탬프가 0인 상태로 작성됩니다.
변경 내역의 업데이트는 가져온 백업 위에 적용됩니다. 스트림에서 작성된 행은 LUT 값을 Bigtable 행 타임스탬프로 사용합니다. 싱크 구성은 새 타임스탬프가 있는 업데이트가 이전 업데이트를 덮어쓰도록 합니다. 이렇게 하면 스트림에서 재생된 변경사항이 해당 행을 덮어씁니다.
LUT 사용
마이그레이션 프로세스는 Aerospike XDR을 사용하여 변경사항을 복제하고 충돌 해결을 위해 LUT에 의존합니다. LUT는 노드의 시스템 시계를 기반으로 하므로 엄격하게 단조롭지 않을 수 있습니다. 따라서 비활성 레코드에 더 새로운 LUT가 있고 최신 레코드를 덮어쓸 수 있습니다. 또한 Aerospike Kafka 소스 (아웃바운드) 커넥터는 Kafka에 게시할 때 정확한 메시지 순서를 보존하지 않을 수 있습니다. 따라서 LUT는 신뢰할 수 있는 버전 마커 역할을 하여 최신 LUT가 있는 레코드만 Bigtable에 적용되도록 합니다.
변경 내역을 시작한 후 백업을 생성하기 전에 레코드가 업데이트되면 백업은 최신 버전을 캡처할 수 있지만 스트림에는 이전 버전이 포함됩니다. 이 이전 버전은 일시적으로 최신 버전을 덮어쓸 수 있습니다. 하지만 올바른 LUT가 있는 후속 스트림 이벤트가 도착하면 최신 버전이 복원됩니다. 불일치를 방지하려면 복제가 안정화되고 파이프라인에서 처리되지 않은 가장 오래된 메시지가 백업보다 최신일 때까지 컷오버를 기다립니다.
데이터 검증
마이그레이션 파이프라인은 전송 중인 데이터의 체크섬을 수행하지 않습니다. 엔드 투 엔드 데이터 무결성 검사가 필요한 경우 검증을 구현해야 합니다.
문제 해결
다음 섹션에서는 마이그레이션 프로세스 중에 발생할 수 있는 일반적인 오류를 설명하고 해결 방법을 안내합니다.
백업 가져오기 오류
Aerospike 백업을 Bigtable로 가져오는 동안 다음 오류가 발생할 수 있습니다.
| 오류 유형 | 원인 | 솔루션 |
|---|---|---|
| 손상된 백업 파일 | 백업 파일을 읽을 수 없거나 손상된 레코드가 포함되어 있습니다. 가져오기 작업이 실패합니다. | 영향을 받은 파일에서 무결성 문제를 검사합니다. 복구할 수 없는 경우 새 백업을 생성하고 가져오기를 반복합니다. |
| Bigtable 쓰기 실패 | Bigtable 연결 또는 서비스 문제가 발생합니다. 가져오기가 실패하지 않습니다. | 실패한 레코드는 JSON 형식으로 오류 출력 파일로 내보내집니다. 수동으로 다시 적용하거나 전체 가져오기 작업을 재시도합니다. |
| 지원되지 않는 데이터 | 백업에 Bigtable로 가져올 수 없는 항목이 포함되어 있습니다. 가져오기가 실패하지 않습니다. | UDF와 같은 지원되지 않는 데이터는 작업 로그에 경고로 보고됩니다. 로그를 검토하여 지원되지 않는 항목을 확인합니다. |
백업 가져오기가 완료되고 잘못된 레코드가 해결되면 변경 내역을 적용할 수 있습니다.
변경 내역 오류
변경 내역 애플리케이션 중에 다음 수준에서 오류가 발생할 수 있습니다.
- 복제기 SMT 오류: SMT가 Aerospike에서 생성한 데이터를 변환하지 못합니다.
- 싱크 오류: 이벤트를 Bigtable에 적용할 수 없습니다.
두 경우 모두 실패한 이벤트는 전용 Kafka 주제로 리디렉션됩니다. 감사를 위해 이벤트를 로깅하거나 커스텀 복구 로직을 사용하여 처리할 수 있습니다.
다음 단계
- Bigtable 스키마 설계 방법 알아보기
- 마이그레이션을 시작하는 방법을 알아보세요. 마이그레이션 대상 Google Cloud.
- 빅데이터 전송에 사용할 수 있는 전략을 알아봅니다.