기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Keyspaces로 온라인 마이그레이션: 전략 및 모범 사례
Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하는 동안 애플리케이션 가용성을 유지해야 하는 경우, 이 주제에서 설명하는 주요 구성 요소를 구현하여 사용자 지정 온라인 마이그레이션 전략을 준비할 수 있습니다. 온라인 마이그레이션에 대한 이러한 모범 사례를 따르면 전체 마이그레이션 프로세스 동안 애플리케이션 가용성과 쓰기 후 읽기 일관성을 유지하여 사용자에게 미치는 영향을 최소화할 수 있습니다.
Apache Cassandra에서 Amazon Keyspaces로의 온라인 마이그레이션 전략을 설계할 때는 다음 주요 단계를 고려해야 합니다.
1. **새 데이터 쓰기**
+ **Amazon Keyspaces 마이그레이션을 위한 ZDM 듀얼 쓰기 프록시** - [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)에서 사용할 수 있는 ZDM 듀얼 쓰기 프록시를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 제로 가동 중지 마이그레이션을 수행합니다. ZDM 프록시는 기존 애플리케이션을 리팩터링할 필요 없이 이중 쓰기를 수행하고 쿼리 검증을 위해 이중 읽기를 수행합니다.
+ 애플리케이션 이중 쓰기: 기존 Cassandra 클라이언트 라이브러리 및 드라이버를 사용하여 애플리케이션에서 이중 쓰기를 구현할 수 있습니다. 한 데이터베이스를 리더로 지정하고 다른 데이터베이스를 팔로워로 지정합니다. 팔로워 데이터베이스에 대한 쓰기 실패는 분석을 위해 [Dead Letter Queue(DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)에 기록됩니다.
+ 메시징 계층 이중 쓰기: 또는 추가 소비자를 사용하여 Cassandra와 Amazon Keyspaces 모두에 쓰기를 보내도록 기존 메시징 플랫폼을 구성할 수 있습니다. 이렇게 하면 결국 두 데이터베이스 모두에서 일관된 보기가 생성됩니다.
1. **기록 데이터 마이그레이션**
+ 기록 데이터 복사: AWS Glue 또는 사용자 지정 추출, 전환, 적재(ETL) 스크립트를 사용하여 Cassandra에서 Amazon Keyspaces로 기록 데이터를 마이그레이션할 수 있습니다. 경량 트랜잭션 또는 타임스탬프와 같은 기술을 사용하여 이중 쓰기와 대량 로드 간의 충돌 해결을 처리합니다.
+ TTL(Time-To-Live): 데이터 보존 기간을 단축하려면 Cassandra 및 Amazon Keyspaces 모두에서 TTL을 사용하여 불필요한 기록 데이터를 업로드하지 않아도 됩니다. Cassandra에서 이전 데이터가 만료되고 이중 쓰기를 통해 새 데이터가 작성되면 Amazon Keyspaces가 결국 따라잡습니다.
1. **데이터 검증**
+ 이중 읽기: Cassandra(기본) 및 Amazon Keyspaces(보조) 데이터베이스 모두에서 이중 읽기를 구현하여 결과를 비동기적으로 비교합니다. 차이점은 로깅되거나 DLQ로 전송됩니다.
+ 샘플 읽기: Λ 함수를 사용하여 두 시스템의 데이터를 주기적으로 샘플링하고 비교하며, 불일치가 있으면 DLQ에 로깅합니다.
1. **애플리케이션 마이그레이션**
+ 블루 그린 전략: 애플리케이션을 전환하여 Amazon Keyspaces를 기본 데이터 스토어로, Cassandra를 보조 데이터 스토어로 한 번에 처리합니다. 성능을 모니터링하고 문제가 발생하면 롤백합니다.
+ 카나리 배포: 먼저 사용자 하위 집합에 마이그레이션을 점진적으로 롤아웃하여 완전히 마이그레이션될 때까지 Amazon Keyspaces에 대한 트래픽을 기본으로 점진적으로 증가시킵니다.
1. **Cassandra 서비스 해제**
애플리케이션이 Amazon Keyspaces로 완전히 마이그레이션되고 데이터 일관성이 검증되면 데이터 보존 정책에 따라 Cassandra 클러스터를 폐기할 계획을 세울 수 있습니다.
이러한 구성 요소를 사용하여 온라인 마이그레이션 전략을 계획하면 가동 중지 시간이나 중단을 최소화하면서 완전 관리형 Amazon Keyspaces 서비스로 원활하게 전환할 수 있습니다. 다음 섹션에서는 각 구성 요소에 대해 자세히 설명합니다.
**Topics**
+ [온라인 마이그레이션 중에 새 데이터 쓰기](migration-online-dw.md)
+ [온라인 마이그레이션 중 기록 데이터 업로드](migration-online-historical.md)
+ [온라인 마이그레이션 중 데이터 일관성 검증](migration-online-validation.md)
+ [온라인 마이그레이션 중 애플리케이션 마이그레이션](migration-online-app-migration.md)
+ [온라인 마이그레이션 후 Cassandra 서비스 해제](migration-online-decommission.md)
# 온라인 마이그레이션 중에 새 데이터 쓰기
온라인 마이그레이션 계획의 첫 번째 단계는 애플리케이션에서 작성한 모든 새 데이터가 데이터베이스, 기존 Cassandra 클러스터 및 Amazon Keyspaces 모두에 저장되도록 하는 것입니다. 목표는 두 데이터 스토어에서 일관된 뷰를 제공하는 것입니다. 두 데이터베이스 모두에 새 쓰기를 모두 적용하여 이 작업을 수행할 수 있습니다. 이중 쓰기를 구현하려면 다음 세 가지 옵션 중 하나를 고려하세요.
+ **Amazon Keyspaces 마이그레이션을 위한 ZDM 이중 쓰기 프록시** - [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)에서 사용할 수 있는 Amazon Keyspaces용 ZDM 프록시를 사용하면 애플리케이션 가동 중지 없이 Apache Cassandra 워크로드를 Amazon Keyspaces로 마이그레이션할 수 있습니다. 이 향상된 솔루션은 AWS모범 사례를 구현하고 공식 ZDM 프록시 기능을 확장합니다.
+ Apache Cassandra와 Amazon Keyspaces 간에 온라인 마이그레이션을 수행합니다.
+ 애플리케이션을 리팩터링하지 않고 소스 테이블과 대상 테이블 모두에 동시에 데이터를 씁니다.
+ 이중 읽기 작업을 통해 쿼리를 검증합니다.
이 솔루션은 AWS및 Amazon Keyspaces와 함께 사용할 수 있도록 다음과 같은 향상된 기능을 제공합니다.
+ **컨테이너 배포** - VPC 액세스 가능 배포를 위해 Amazon Elastic Container Registry(Amazon ECR)의 사전 구성된 Docker 이미지를 사용합니다.
+ **코드형 인프라** - 자동 설정을 위한 AWS CloudFormation템플릿을 사용하여 배포합니다AWS Fargate.
+ **Amazon Keyspaces 호환성 **- Amazon Keyspaces에 대한 사용자 지정 적응을 통해 시스템 테이블에 액세스합니다.
이 솔루션은 Fargate를 사용하는 Amazon ECS에서 실행되므로 워크로드 요구 사항에 따라 서버리스 확장성을 제공합니다. 네트워크 로드 밸런서는 고가용성을 위해 여러 Amazon ECS 작업에 수신 애플리케이션 트래픽을 분산합니다.
![\[Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션하기 위한 ZDM 이중 쓰기 프록시 구현.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **애플리케이션 이중 쓰기** - 기존 Cassandra 클라이언트 라이브러리 및 드라이버를 활용하여 애플리케이션 코드를 최소한으로 변경하여 이중 쓰기를 구현할 수 있습니다. 기존 애플리케이션에서 이중 쓰기를 구현하거나 아키텍처에서 새 계층을 생성하여 이중 쓰기를 처리할 수 있습니다. 기존 애플리케이션에서 이중 쓰기가 구현된 방법을 보여주는 고객 사례 연구 및 자세한 내용은 [Cassandra 마이그레이션 사례 연구 섹션](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)을 참조하세요.
이중 쓰기를 구현할 때 하나의 데이터베이스를 리더로 지정하고 다른 데이터베이스를 팔로워로 지정할 수 있습니다. 이렇게 하면 팔로워 또는 대상 데이터베이스가 애플리케이션의 중요 경로를 중단하지 않고 원본 소스 또는 리더 데이터베이스에 계속 쓸 수 있습니다.
팔로워에 실패한 쓰기를 다시 시도하는 대신 Amazon Simple Queue Service를 사용하여 [Dead Letter Queue(DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)에 실패한 쓰기를 기록할 수 있습니다. DLQ를 사용하면 팔로워에 대한 실패한 쓰기를 분석하고 대상 데이터베이스에서 처리가 성공하지 못한 이유를 확인할 수 있습니다.
보다 정교한 이중 쓰기 구현을 위해 [Saga 패턴을](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) 사용하여 일련의 로컬 트랜잭션을 설계하는 AWS모범 사례를 따를 수 있습니다. 사가 패턴은 트랜잭션이 실패하면 사가에서 보정 트랜잭션을 실행하여 이전 트랜잭션에서 수행한 데이터베이스 변경 내용을 되돌립니다.
온라인 마이그레이션에 이중 쓰기를 사용하는 경우 각 쓰기가 로컬 트랜잭션이 되도록 사가 패턴에 따라 이중 쓰기를 구성하여 이기종 데이터베이스에서 원자 작업을 보장할 수 있습니다. 에 권장되는 설계 패턴을 사용하여 분산 애플리케이션을 설계하는 방법에 대한 자세한 내용은 클라우드 설계 패턴, 아키텍처 및 구현을 AWS 클라우드참조하세요. [https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)
![\[Apache Cassandra에서 Amazon Keyspaces로 마이그레이션할 때 애플리케이션 계층에서 이중 쓰기를 구현합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **메시징 계층 이중 쓰기** - 애플리케이션 계층에서 이중 쓰기를 구현하는 대신 기존 메시징 계층을 사용하여 Cassandra 및 Amazon Keyspaces에 이중 쓰기를 수행할 수 있습니다.
이렇게 하려면 메시징 플랫폼에 추가 소비자를 구성하여 두 데이터 스토어에 쓰기를 보낼 수 있습니다. 이 접근 방식은 메시징 계층을 사용하여 두 데이터베이스 모두에서 최종적으로 일관된 두 가지 보기를 생성하는 간단한 로우 코드 전략을 제공합니다.
# 온라인 마이그레이션 중 기록 데이터 업로드
이중 쓰기를 구현하여 두 데이터 스토어 모두에 새 데이터를 실시간으로 기록하도록 한 후, 마이그레이션 계획의 다음 단계는 Cassandra에서 Amazon Keyspaces로 복사하거나 대량 업로드하는 데 필요한 기록 데이터의 양을 평가하는 것입니다. 이렇게 하면 애플리케이션을 마이그레이션하기 전에 새 Amazon Keyspaces 데이터베이스에서 새 데이터와 기록 데이터를 모두 사용할 수 있습니다.
조직 정책에 따라 보존해야 하는 기록 데이터의 양과 같은 데이터 보존 요구 사항에 따라 다음 두 가지 옵션 중 하나를 고려할 수 있습니다.
+ **기록 데이터의 대량 업로드** - 기존 Cassandra 배포에서 Amazon Keyspaces로 기록 데이터를 마이그레이션하는 작업은 AWS Glue또는 사용자 지정 스크립트를 사용하여 데이터를 추출, 변환 및 로드(ETL)하는 등 다양한 기술을 통해 수행할 수 있습니다. AWS Glue를 사용하여 기록 데이터를 업로드하는 방법에 대한 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 섹션을 참조하세요.
기록 데이터의 대량 업로드를 계획할 때는 새 쓰기가 업로드 중인 것과 동일한 데이터를 업데이트하려고 할 때 발생할 수 있는 충돌을 해결하는 방법을 고려해야 합니다. 대량 업로드는 최종적으로 일관될 것으로 예상되므로 데이터가 모든 노드에 도달하게 됩니다.
새 쓰기로 인해 동일한 데이터의 업데이트가 동시에 발생하는 경우 기록 데이터 업로드로 덮어쓰지 않도록 해야 합니다. 대량 가져오기 중에도 데이터의 최신 업데이트를 보존하려면 대량 업로드 스크립트 또는 이중 쓰기를 위한 애플리케이션 로직에 충돌 해결을 추가해야 합니다.
예를 들어 [간단한 트랜잭션](functional-differences.md#functional-differences.light-transactions)(LWT)를 사용하여 작업을 비교하고 설정할 수 있습니다. 이렇게 하기 위해 수정 시간 또는 상태를 나타내는 필드를 데이터 모델에 추가할 수 있습니다.
또한 Amazon Keyspaces는 Cassandra `WRITETIME` 타임스탬프 함수를 지원합니다. Amazon Keyspaces 클라이언트 측 타임스탬프를 사용하여 소스 데이터베이스 타임스탬프를 보존하고 last-writer-wins 충돌 해결을 구현할 수 있습니다. 자세한 내용은 [Amazon Keyspaces의 클라이언트 측 타임스탬프](client-side-timestamps.md) 단원을 참조하십시오.
+ **TTL(Time-to-Live) 사용** - 데이터 보존 기간이 30일, 60일 또는 90일 미만인 경우 마이그레이션 중에 Cassandra 및 Amazon Keyspaces에서 TTL을 사용하여 불필요한 기록 데이터를 Amazon Keyspaces에 업로드하지 않도록 할 수 있습니다. TTL을 사용하면 데이터베이스에서 데이터가 자동으로 제거되는 기간을 설정할 수 있습니다.
마이그레이션 단계에서 기록 데이터를 Amazon Keyspaces에 복사하는 대신 이중 쓰기 방법을 사용하여 Amazon Keyspaces에 새 쓰기만 적용하면서 기록 데이터가 이전 시스템(Cassandra)에서 자동으로 만료되도록 TTL 설정을 구성할 수 있습니다. 시간이 지남에 따라 이전 데이터가 Cassandra 클러스터에서 계속 만료되고 이중 쓰기 방법을 사용하여 작성된 새 데이터가 있는 경우 Amazon Keyspaces는 Cassandra와 동일한 데이터를 포함하도록 자동으로 추적합니다.
이 접근 방식은 마이그레이션할 데이터의 양을 크게 줄여 마이그레이션 프로세스를 더 효율적이고 간소화할 수 있습니다. 다양한 데이터 보존 요구 사항이 있는 대규모 데이터세트를 처리할 때 이 접근 방식을 고려할 수 있습니다. TTL에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)의 TTL(Time to Live)을 사용하여 데이터 만료](TTL.md) 섹션을 참조하세요.
TTL 데이터 만료를 사용하여 Cassandra에서 Amazon Keyspaces로 마이그레이션하는 다음 예제를 고려해 보세요. 이 예제에서는 두 데이터베이스 모두에 대해 TTL을 60일로 설정하고 90일 동안 마이그레이션 프로세스가 어떻게 진행되는지 보여줍니다. 두 데이터베이스는 이중 쓰기 방법을 사용하여 이 기간 동안 새로 작성된 동일한 데이터를 수신합니다. 마이그레이션의 세 가지 단계를 살펴보겠습니다. 각 단계의 기간은 30일입니다.
각 단계에 대한 마이그레이션 프로세스의 작동 방식은 다음 이미지에 나와 있습니다.
![\[Apache Cassandra에서 Amazon Keyspaces로 마이그레이션할 때 TTL을 사용하여 기록 데이터를 만료합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 처음 30일이 지난 후 Cassandra 클러스터와 Amazon Keyspaces는 새 쓰기를 수신했습니다. Cassandra 클러스터에는 아직 60일 보존 기간에 도달하지 않은 기록 데이터도 포함되어 있어 클러스터의 데이터 중 50%를 차지합니다.
60일이 지난 데이터는 TTL을 사용하여 Cassandra 클러스터에서 자동으로 삭제됩니다. 현재 Amazon Keyspaces에는 Cassandra 클러스터에 저장된 데이터의 50%가 포함되어 있으며, 이는 새 쓰기에서 과거 데이터를 뺀 값으로 구성됩니다.
1. 60일이 지나면 Cassandra 클러스터와 Amazon Keyspaces 모두 지난 60일 동안 작성된 동일한 데이터를 포함합니다.
1. 90일 이내에 Cassandra Keyspaces와 Amazon Keyspaces 모두 동일한 데이터를 포함하며 동일한 속도로 데이터가 만료됩니다.
이 예제에서는 만료 날짜가 60일로 설정된 TTL을 사용하여 기록 데이터를 업로드하는 단계를 피하는 방법을 보여줍니다.
# 온라인 마이그레이션 중 데이터 일관성 검증
온라인 마이그레이션 프로세스의 다음 단계는 데이터 검증입니다. 이중 쓰기는 Amazon Keyspaces 데이터베이스에 새 데이터를 추가하고 있으며 TTL을 사용한 대량 업로드 또는 데이터 만료를 사용하여 기록 데이터의 마이그레이션을 완료했습니다.
이제 검증 단계를 사용하여 두 데이터 스토어에 실제로 동일한 데이터가 포함되어 있는지 확인하고 동일한 읽기 결과를 반환할 수 있습니다. 다음 두 옵션 중 하나를 선택하여 두 데이터베이스 모두에 동일한 데이터가 포함되어 있는지 확인할 수 있습니다.
+ **이중 읽기** - 소스 및 대상 데이터베이스 모두에 새로 작성된 데이터와 기록 데이터세트가 동일한지 검증하기 위해 이중 읽기를 구현할 수 있습니다. 이렇게 하려면 기본 Cassandra와 보조 Amazon Keyspaces 데이터베이스 모두에서 듀얼 쓰기 방법과 유사하게 읽고 결과를 비동기적으로 비교합니다.
기본 데이터베이스의 결과는 클라이언트로 반환되고 보조 데이터베이스의 결과는 기본 결과 집합을 대상으로 검증하는 데 사용됩니다. 발견된 차이점은 나중에 조정할 수 있도록 기록하거나 [Dead Letter Queue(DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)로 전송할 수 있습니다.
다음 다이어그램에서 애플리케이션은 기본 데이터 스토어인 Cassandra에서 동기식 읽기를 수행하고 보조 데이터 스토어인 Amazon Keyspaces에서 비동기식 읽기를 수행합니다.
![\[이중 읽기를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 온라인 마이그레이션 중에 데이터 일관성을 검증합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **샘플 읽기** - 애플리케이션 코드를 변경할 필요가 없는 대체 솔루션은 AWS Lambda함수를 사용하여 소스 Cassandra 클러스터와 대상 Amazon Keyspaces 데이터베이스 모두에서 데이터를 주기적으로 무작위로 샘플링하는 것입니다.
이러한 Lambda 함수는 정기적으로 실행되도록 구성할 수 있습니다. Lambda 함수는 소스 및 대상 시스템 모두에서 임의 데이터 하위 집합을 검색한 다음 샘플링된 데이터를 비교합니다. 두 데이터세트 간의 불일치 또는 불일치는 나중에 조정할 수 있도록 기록하여 전용 [Dead Letter Queue(DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)로 전송할 수 있습니다.
이 프로세스는 다음 다이어그램에 설명되어 있습니다.
![\[샘플 읽기를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하는 동안 및 온라인으로 데이터 일관성을 검증합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# 온라인 마이그레이션 중 애플리케이션 마이그레이션
온라인 마이그레이션의 4단계에서는 애플리케이션을 마이그레이션하고 Amazon Keyspaces를 기본 데이터 스토어로 전환합니다. 즉, 애플리케이션을 Amazon Keyspaces에서 직접 읽고 쓰도록 전환합니다. 사용자의 중단을 최소화하려면 프로세스를 잘 계획하고 조정해야 합니다.
애플리케이션 마이그레이션에 권장되는 두 가지 솔루션인 블루 그린 컷오버 전략과 카나리 컷오버 전략을 사용할 수 있습니다. 다음 섹션에서는 이러한 전략을 자세히 설명합니다.
+ **블루 그린 전략** - 이 접근 방식을 사용하면 애플리케이션을 전환하여 Amazon Keyspaces를 기본 데이터 스토어로, Cassandra를 보조 데이터 스토어로 한 번에 처리합니다. AWS AppConfig기능 플래그를 사용하여 애플리케이션 인스턴스에서 기본 및 보조 데이터 스토어의 선택을 제어할 수 있습니다. 기능 플래그에 대한 자세한 내용은 [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)을 참조하세요.
Amazon Keyspaces를 기본 데이터 스토어로 만든 후 애플리케이션의 동작과 성능을 모니터링하여 Amazon Keyspaces가 요구 사항을 충족하고 마이그레이션이 성공했는지 확인합니다.
예를 들어 애플리케이션에 이중 읽기를 구현한 경우 애플리케이션 마이그레이션 단계에서 Cassandra에서 Amazon Keyspaces로 이동하는 기본 읽기와 Amazon Keyspaces에서 Cassandra로 보조 읽기를 전환합니다. 전환 후에는 Cassandra를 해체하기 전에 두 데이터베이스 간의 일관성을 보장하기 위해 [데이터 검증](migration-online-validation.md) 섹션에 설명된 대로 결과를 계속 모니터링하고 비교합니다.
문제가 감지된 경우 Cassandra를 기본 데이터 스토어로 되돌리면 빠르게 이전 상태로 돌아갈 수 있습니다. Amazon Keyspaces가 기본 데이터 스토어로서의 모든 요구 사항을 충족하는 경우에만 마이그레이션의 서비스 해제 단계로 진행합니다.
![\[Apache Cassandra에서 Amazon Keyspaces로 애플리케이션을 마이그레이션하는 데 블루 그린 전략을 사용합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **카나리 전략** - 이 접근 방식에서는 사용자 또는 트래픽의 하위 집합으로 마이그레이션을 점진적으로 롤아웃합니다. 처음에는 애플리케이션 트래픽의 작은 비율, 예를 들어 모든 트래픽의 5%가 Amazon Keyspaces를 기본 데이터 스토어로 사용하여 버전으로 라우팅되는 반면 나머지 트래픽은 Cassandra를 기본 데이터 스토어로 계속 사용합니다.
이를 통해 실제 트래픽으로 마이그레이션된 버전을 철저히 테스트하고 성능과 안정성을 모니터링하고 잠재적 문제를 조사할 수 있습니다. 문제를 감지하지 못하면 모든 사용자 및 트래픽에 대한 기본 데이터 스토어가 될 때까지 Amazon Keyspaces로 라우팅되는 트래픽의 비율을 점진적으로 늘릴 수 있습니다.
이 단계적 롤아웃은 광범위한 서비스 중단 위험을 최소화하고 보다 통제된 마이그레이션 프로세스를 가능하게 합니다. 카나리 배포 중에 중요한 문제가 발생하는 경우 Cassandra를 영향을 받는 트래픽 세그먼트의 기본 데이터 스토어로 사용하여 이전 버전으로 빠르게 롤백할 수 있습니다. Amazon Keyspaces가 정상적으로 사용자 및 트래픽을 100% 처리하는지 확인한 후에만 마이그레이션의 서비스 해제 단계로 진행합니다.
다음 다이어그램은 카나리리 전략의 개별 단계를 보여줍니다.
![\[Apache Cassandra에서 Amazon Keyspaces로 애플리케이션을 마이그레이션하는 데 카나리 전략을 사용합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# 온라인 마이그레이션 후 Cassandra 서비스 해제
Amazon Keyspaces에서 애플리케이션이 완전히 실행되고 일정 기간 동안 데이터 일관성을 확인한 후 애플리케이션 마이그레이션이 완료되면 Cassandra 클러스터를 해제할 계획을 세울 수 있습니다. 이 단계에서는 Cassandra 클러스터에 남아 있는 데이터를 보관해야 하는지 또는 삭제할 수 있는지 평가할 수 있습니다. 이는 데이터 처리 및 보존에 대한 조직의 정책에 따라 달라집니다.
이 전략을 따르고 Cassandra에서 Amazon Keyspaces로의 온라인 마이그레이션을 계획할 때 이 주제에 설명된 권장 모범 사례를 고려하면 애플리케이션의 읽기 후 쓰기 일관성과 가용성을 유지하면서 Amazon Keyspaces로 원활하게 전환할 수 있습니다.
Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하면 운영 오버헤드 감소, 오토 스케일링, 보안 개선, 규정 준수 목표 달성에 도움이 되는 프레임워크 등 다양한 이점을 얻을 수 있습니다. 이중 쓰기, 기록 데이터 업로드, 데이터 검증 및 점진적 롤아웃을 사용하여 온라인 마이그레이션 전략을 계획하면 애플리케이션과 사용자의 중단을 최소화하면서 원활한 전환을 보장할 수 있습니다.
이 주제에서 논의한 온라인 마이그레이션 전략을 구현하면 마이그레이션 결과를 검증하고, 문제를 식별 및 해결하고, 궁극적으로 완전 관리형 Amazon Keyspaces 서비스를 위해 기존 Cassandra 배포를 중단할 수 있습니다.