기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하는 동안 애플리케이션 가용성을 유지해야 하는 경우, 이 주제에서 설명하는 주요 구성 요소를 구현하여 사용자 지정 온라인 마이그레이션 전략을 준비할 수 있습니다. 온라인 마이그레이션에 대한 이러한 모범 사례를 따르면 전체 마이그레이션 프로세스 동안 애플리케이션 가용성과 쓰기 후 읽기 일관성을 유지하여 사용자에게 미치는 영향을 최소화할 수 있습니다.
Apache Cassandra에서 Amazon Keyspaces로의 온라인 마이그레이션 전략을 설계할 때는 다음 주요 단계를 고려해야 합니다.
새 데이터 쓰기
애플리케이션 이중 쓰기: 기존 Cassandra 클라이언트 라이브러리 및 드라이버를 사용하여 애플리케이션에서 이중 쓰기를 구현할 수 있습니다. 한 데이터베이스를 리더로 지정하고 다른 데이터베이스를 팔로워로 지정합니다. 팔로워 데이터베이스에 대한 쓰기 실패는 분석을 위해 Dead Letter Queue(DLQ)에 기록됩니다.
메시징 계층 이중 쓰기: 또는 추가 소비자를 사용하여 Cassandra와 Amazon Keyspaces 모두에 쓰기를 보내도록 기존 메시징 플랫폼을 구성할 수 있습니다. 이렇게 하면 결국 두 데이터베이스 모두에서 일관된 보기가 생성됩니다.
기록 데이터 마이그레이션
기록 데이터 복사: AWS Glue 또는 사용자 지정 추출, 전환, 적재(ETL) 스크립트를 사용하여 Cassandra에서 Amazon Keyspaces로 기록 데이터를 마이그레이션할 수 있습니다. 경량 트랜잭션 또는 타임스탬프와 같은 기술을 사용하여 이중 쓰기와 대량 로드 간의 충돌 해결을 처리합니다.
TTL(Time-To-Live): 데이터 보존 기간을 단축하려면 Cassandra 및 Amazon Keyspaces 모두에서 TTL을 사용하여 불필요한 기록 데이터를 업로드하지 않아도 됩니다. Cassandra에서 이전 데이터가 만료되고 이중 쓰기를 통해 새 데이터가 작성되면 Amazon Keyspaces가 결국 따라잡습니다.
데이터 검증
이중 읽기: Cassandra(기본) 및 Amazon Keyspaces(보조) 데이터베이스 모두에서 이중 읽기를 구현하여 결과를 비동기적으로 비교합니다. 차이점은 로깅되거나 DLQ로 전송됩니다.
샘플 읽기: Λ 함수를 사용하여 두 시스템의 데이터를 주기적으로 샘플링하고 비교하며, 불일치가 있으면 DLQ에 로깅합니다.
애플리케이션 마이그레이션
블루 그린 전략: 애플리케이션을 전환하여 Amazon Keyspaces를 기본 데이터 스토어로, Cassandra를 보조 데이터 스토어로 한 번에 처리합니다. 성능을 모니터링하고 문제가 발생하면 롤백합니다.
카나리 배포: 먼저 사용자 하위 집합에 마이그레이션을 점진적으로 롤아웃하여 완전히 마이그레이션될 때까지 Amazon Keyspaces에 대한 트래픽을 기본으로 점진적으로 증가시킵니다.
Cassandra 서비스 해제
애플리케이션이 Amazon Keyspaces로 완전히 마이그레이션되고 데이터 일관성이 검증되면 데이터 보존 정책에 따라 Cassandra 클러스터를 폐기할 계획을 세울 수 있습니다.
이러한 구성 요소를 사용하여 온라인 마이그레이션 전략을 계획하면 가동 중지 시간이나 중단을 최소화하면서 완전 관리형 Amazon Keyspaces 서비스로 원활하게 전환할 수 있습니다. 다음 섹션에서는 각 구성 요소에 대해 자세히 설명합니다.