기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Keyspaces(Apache Cassandra용)로 마이그레이션
Amazon Keyspaces(Apache Cassandra용)로 마이그레이션하면 기업과 조직은 다양하고 매력적인 이점을 누릴 수 있습니다. 다음은 Amazon Keyspaces가 마이그레이션에 적합한 이유라고 할 수 있는 주요 이점입니다.
+ **확장성** - Amazon Keyspaces는 대규모 워크로드를 처리하고 증가하는 데이터 볼륨 및 트래픽을 수용하기 위해 원활하게 확장할 수 있도록 설계되었습니다. 기존 Cassandra에서는 필요에 따라 규모 조정이 수행되지 않으므로 향후 피크를 계획해야 합니다. Amazon Keyspaces를 사용하면 수요에 따라 테이블을 쉽게 확장하거나 축소할 수 있으므로 애플리케이션에서 성능 저하 없이 갑작스러운 트래픽 급증을 처리할 수 있습니다.
+ **성능** - Amazon Keyspaces는 지연 시간이 짧은 데이터 액세스를 제공하므로 애플리케이션이 뛰어난 속도로 데이터를 검색하고 처리할 수 있습니다. 분산 아키텍처는 읽기 및 쓰기 작업이 여러 노드에 분산되도록 하여 요청 속도가 높아도 일관되게 10밀리초 미만의 응답 시간을 제공합니다.
+ **완전관리형** - Amazon Keyspaces는 AWS에서 제공하는 완전관리형 서비스입니다. 즉,는 프로비저닝, 구성, 패치 적용, 백업 및 조정을 포함하여 데이터베이스 관리의 운영 측면을 AWS 처리합니다. 따라서 개발자는 데이터베이스 관리 작업보다는 애플리케이션 개발에 더 집중할 수 있습니다.
+ **서버리스 아키텍처** - Amazon Keyspaces는 서버리스입니다. 선결제 용량 프로비저닝 없이 소비된 용량에 대해서만 비용을 지불합니다. 관리할 서버 또는 선택할 인스턴스가 없습니다. 이 요청당 지불 모델은 용량을 프로비저닝하고 모니터링할 필요 없이 사용한 리소스에 대해서만 비용을 지불하므로 비용 효율성이 높고 운영 오버헤드를 최소화합니다.
+ **스키마를 사용한 NoSQL 유연성** – Amazon Keyspaces는 NoSQL 데이터 모델을 따르므로 스키마 설계에 유연성을 제공합니다. Amazon Keyspaces를 사용하면 정형, 반정형 및 비정형 데이터를 저장할 수 있으므로 다양하고 변화하는 데이터 유형을 처리하는 데 적합합니다. 또한 Amazon Keyspaces는 쓰기에 대한 스키마 검증을 수행하여 데이터 모델의 중앙 집중식 진화를 가능하게 합니다. 이러한 유연성 덕분에 개발 주기를 단축하고 변화하는 비즈니스 요구 사항에 쉽게 적응할 수 있습니다.
+ **고가용성 및 내구성** - Amazon Keyspaces는 내의 여러 [가용 영역에](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 데이터를 복제 AWS 리전하여 고가용성과 데이터 내구성을 보장합니다. 복제, 장애 조치 및 복구를 자동으로 처리하여 데이터 손실이나 서비스 중단의 위험을 최소화합니다. Amazon Keyspaces는 최대 99.999%의 가용성 SLA를 제공합니다. Amazon Keyspaces는 더 많은 복원력과 짧은 지연 시간 로컬 읽기를 위해 [다중 리전 복제](multiRegion-replication.md)를 제공합니다.
+ **보안 및 규정 준수** - Amazon Keyspaces는 AWS Identity and Access Management 와 통합되어 세분화된 액세스 제어를 제공합니다. 저장 데이터 암호화 및 전송 중 암호화 기능을 제공하여 데이터의 보안 향상을 돕습니다. Amazon Keyspaces는 HIPAA, PCI DSS 및 SOC를 비롯한 특정 프로그램의 보안 및 규정 준수에 대해 타사 감사자로부터 평가를 받았으며, 이를 통해 규제 요구 사항을 충족할 수 있습니다. 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)의 규정 준수 검증](Keyspaces-compliance.md) 단원을 참조하십시오.
+ ** AWS 에코시스템과의 통합** - Amazon Keyspaces는 에코시스템의 AWS 일부로 Amazon AWS CloudFormation Amazon CloudWatch 및 AWS 서비스같은 다른와 원활하게 통합됩니다 AWS CloudTrail. 이러한 통합을 통해 서버리스 아키텍처를 구축하고, 코드형 인프라를 활용하고, 실시간 데이터 기반 애플리케이션을 만들 수 있습니다. 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용) 모니터링](monitoring-overview.md) 단원을 참조하십시오.
**Topics**
+ [Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하기 위한 마이그레이션 계획 생성](migrating-cassandra.md)
+ [Amazon Keyspaces로 데이터를 대량 업로드하거나 마이그레이션하는 데 적합한 도구를 선택하는 방법](migrating-tools.md)
# Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하기 위한 마이그레이션 계획 생성
Apache Cassandra에서 Amazon Keyspaces로 성공적으로 마이그레이션하려면 해당 마이그레이션 개념 및 모범 사례를 검토하고 사용 가능한 옵션을 비교하는 것이 좋습니다.
이 주제에서는 몇 가지 주요 개념과 사용 가능한 도구 및 기법을 도입하여 마이그레이션 프로세스가 작동하는 방식을 간략하게 설명합니다. 다양한 마이그레이션 전략을 평가하여 요구 사항에 가장 적합한 전략을 선택할 수 있습니다.
**Topics**
+ [기능적 호환성](#migrating-cassandra-compatibility)
+ [Amazon Keyspaces 요금 추정](#migrating-cassandra-sizing)
+ [마이그레이션 전략을 선택합니다.](#migrating-cassandra-strategy)
+ [Amazon Keyspaces로 온라인 마이그레이션: 전략 및 모범 사례](migrating-online.md)
+ [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md)
+ [하이브리드 마이그레이션 솔루션 사용: Apache Cassandra에서 Amazon Keyspaces로](migrating-hybrid.md)
## 기능적 호환성
마이그레이션 전에 Apache Cassandra와 Amazon Keyspaces의 기능적 차이점을 신중하게 고려하세요. Amazon Keyspaces는 키스페이스 및 테이블 생성, 데이터 읽기, 데이터 쓰기 등 일반적으로 사용되는 모든 Cassandra 데이터 플레인 작업을 지원합니다.
하지만 일부 Cassandra API는 Amazon Keyspaces에서 지원하지 않습니다. 지원되는 API에 대한 자세한 내용은 [지원되는 Cassandra API, 작업, 함수, 데이터 유형](cassandra-apis.md) 섹션을 참조하세요. Amazon Keyspaces와 Apache Cassandra 간의 모든 기능적 차이점에 대한 개요는 [기능적 차이: Amazon Keyspaces와 Apache Cassandra](functional-differences.md) 섹션을 참조하세요.
Amazon Keyspaces에서 지원되는 기능과 사용 중인 Cassandra API 및 스키마를 비교하려면 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)의 Amazon Keyspaces 툴킷에서 사용 가능한 호환성 스크립트를 실행할 수 있습니다.
**호환성 스크립트 사용 방법**
1. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)에서 호환성 Python 스크립트를 다운로드하여 기존 Apache Cassandra 클러스터에 액세스할 수 있는 위치로 이동합니다.
1. 호환성 스크립트는 `CQLSH`와 유사한 파라미터를 사용합니다. `--host` 및 `--port`에 클러스터의 Cassandra 노드 중 하나에 쿼리를 연결하고 실행하는 데 사용하는 IP 주소와 포트를 입력합니다.
Cassandra 클러스터가 인증을 사용하는 경우 `-username` 및 `-password`도 제공해야 합니다. 호환성 스크립트를 실행하려면 다음 명령을 사용할 수 있습니다.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Amazon Keyspaces 요금 추정
이 섹션에서는 Amazon Keyspaces의 예상 비용을 계산하기 위해 Apache Cassandra 테이블에서 수집해야 하는 정보에 대한 개요를 제공합니다. 각 테이블에는 서로 다른 데이터 유형이 필요하며, 서로 다른 CQL 쿼리를 지원해야 하고, 고유한 읽기/쓰기 트래픽을 유지해야 합니다.
테이블을 기반으로 요구 사항을 고려하면 Amazon Keyspaces 테이블 수준 리소스 격리 및 [읽기/쓰기 처리량 용량 모드](ReadWriteCapacityMode.md)와 일치합니다. Amazon Keyspaces를 사용하면 테이블의 읽기/쓰기 용량과 [자동 조정 정책](autoscaling.md)을 독립적으로 정의할 수 있습니다.
테이블 요구 사항을 이해하면 기능, 비용 및 마이그레이션 노력에 따라 마이그레이션을 위한 테이블의 우선순위를 정하는 데 도움이 됩니다.
마이그레이션 전에 다음 Cassandra 테이블 지표를 수집합니다. 이 정보는 Amazon Keyspaces에서 워크로드 비용을 추정하는 데 도움이 됩니다.
+ **테이블 이름** - 정규화된 키스페이스의 이름과 테이블 이름입니다.
+ **설명** - 테이블의 사용 방식 또는 테이블에 저장되는 데이터 유형과 같은 테이블에 대한 설명입니다.
+ **초당 평균 읽기** - 장기간 동안 테이블에 대한 좌표 수준 읽기의 평균 횟수입니다.
+ **초당 평균 쓰기** - 장기간 동안 테이블에 대한 좌표 수준 쓰기의 평균 횟수입니다.
+ **바이트 단위의 평균 행 크기** - 바이트 단위의 평균 행 크기입니다.
+ **스토리지 크기(GB)** - 테이블의 원시 스토리지 크기입니다.
+ **읽기 일관성 분석** - 최종 일관성(`LOCAL_ONE` 또는 `ONE`)과 강력한 일관성(`LOCAL_QUORUM`)을 사용하는 읽기의 백분율입니다.
이 표는 마이그레이션을 계획할 때 함께 가져와야 하는 테이블에 대한 정보의 예를 보여줍니다.
****
| 테이블 이름 | 설명 | 초당 평균 읽기 | 초당 평균 쓰기 | 바이트 단위의 평균 행 크기 | 스토리지 크기(GB) | 읽기 일관성 분석 |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | 장바구니 기록을 저장하는 데 사용 | 10,000 | 5,000 | 2,200 | 2,000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | 최신 프로필 정보를 저장하는 데 사용 | 20,000건 | 1,000 | 850 | 1,000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### 테이블 지표를 수집하는 방법
이 섹션에서는 기존 Cassandra 클러스터에서 필요한 테이블 지표를 수집하는 방법에 대한 단계별 지침을 제공합니다. 이러한 지표에는 행 크기, 테이블 크기 및 초당 읽기/쓰기 요청(RPS)이 포함됩니다. 이를 통해 Amazon Keyspaces 테이블에 대한 처리량 용량 요구 사항을 평가하고 가격을 추정할 수 있습니다.
**Cassandra 소스 테이블에서 테이블 지표를 수집하는 방법**
1. 행 크기 결정
행 크기는 Amazon Keyspaces에서 읽기 용량 및 쓰기 용량 사용률을 결정하는 데 중요합니다. 다음 다이어그램은 Cassandra 토큰 범위에 대한 일반적인 데이터 배포를 보여줍니다.
![\[murmur3 파티셔너를 사용하여 Cassandra 토큰 범위에 대한 일반적인 데이터 배포를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)에서 사용할 수 있는 행 크기 샘플러 스크립트를 사용하여 Cassandra 클러스터의 각 테이블에 대한 행 크기 지표를 수집할 수 있습니다.
스크립트는 `cqlsh` 및 `awk`를 사용하여 구성 가능한 테이블 데이터 샘플 세트에 대한 행 크기의 최소, 최대, 평균 및 표준 편차를 계산하여 Apache Cassandra에서 테이블 데이터를 내보냅니다. 행 크기 샘플러는 인수를 `cqlsh`에 전달하므로 동일한 파라미터를 사용하여 Cassandra 클러스터를 연결하고 읽을 수 있습니다.
다음 문은 이에 대한 예입니다.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Amazon Keyspaces에서 행 크기를 계산하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요.
1. 테이블 크기 결정
Amazon Keyspaces를 사용하면 스토리지를 미리 프로비저닝할 필요가 없습니다. Amazon Keyspaces는 테이블의 청구 가능 크기를 지속적으로 모니터링하여 스토리지 요금을 결정합니다. 스토리지는 월별 GB로 결제됩니다. Amazon Keyspaces 테이블 크기는 단일 복제본의 원시 크기(압축되지 않음)를 기반으로 합니다.
Amazon Keyspaces에서 테이블 크기를 모니터링하려면 AWS Management Console의 각 테이블에 대해 표시되는 지표 `BillableTableSizeInBytes`를 사용할 수 있습니다.
Amazon Keyspaces 테이블의 청구 가능 크기를 추정하려면 다음 두 가지 방법 중 하나를 사용할 수 있습니다.
+ 평균 행 크기를 사용하고 숫자 또는 행을 곱합니다.
평균 행 크기에 Cassandra 소스 테이블의 행 수를 곱하여 Amazon Keyspaces 테이블의 크기를 추정할 수 있습니다. 이전 섹션의 행 크기 샘플 스크립트를 사용하여 평균 행 크기를 캡처합니다. 행 수를 캡처하려면 `dsbulk count`와 같은 도구를 사용하여 소스 테이블의 총 행 수를 확인할 수 있습니다.
+ `nodetool`을 사용하여 테이블 메타데이터를 수집합니다.
`Nodetool`은 Apache Cassandra 배포에서 제공되는 관리 도구로, Cassandra 프로세스의 상태에 대한 통찰력을 제공하고 테이블 메타데이터를 반환합니다. `nodetool`을 사용하여 테이블 크기에 대한 메타데이터를 샘플링하고 Amazon Keyspaces에서 테이블 크기를 추론할 수 있습니다.
사용할 명령은 `nodetool tablestats`입니다. Tablestats는 테이블의 크기와 압축 비율을 반환합니다. 테이블의 크기는 테이블의 `tablelivespace`로 저장되며 `compression ratio`로 나눌 수 있습니다. 그런 다음 이 크기 값을 노드 수로 곱합니다. 마지막으로 복제 인수(일반적으로 3)로 나눕니다.
테이블 크기를 평가하는 데 사용할 수 있는 계산의 전체 공식입니다.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Cassandra 클러스터에 12개의 노드가 있다고 가정해 보겠습니다. `nodetool tablestats` 명령을 실행하면 200GB의 `tablelivespace`와 0.5의 `compression ratio`가 반환됩니다. 키스페이스의 복제 계수는 3입니다.
이 예제의 계산은 다음과 같습니다.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. 읽기 및 쓰기 수 캡처
Amazon Keyspaces 테이블의 용량 및 크기 조정 요구 사항을 확인하려면 마이그레이션 전에 Cassandra 테이블의 읽기 및 쓰기 요청 속도를 캡처합니다.
Amazon Keyspaces는 서버리스이며 사용한 비용만 지불하면 됩니다. 일반적으로 Amazon Keyspaces의 읽기/쓰기 처리량 가격은 요청 수와 크기를 기반으로 합니다.
Amazon Keyspaces에는 두 가지 용량 모드가 있습니다.
+ [온디맨드](ReadWriteCapacityMode.OnDemand.md) - 용량을 계획할 필요 없이 초당 수천 개의 요청을 처리할 수 있는 유연한 청구 옵션입니다. 읽기 및 쓰기 요청에 대해 요청당 지불 가격을 제공하므로 사용하는 만큼에 대해서만 비용을 지불하면 됩니다.
+ [프로비저닝됨](ReadWriteCapacityMode.Provisioned.md) - 프로비저닝된 처리량 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. 이렇게 하면 Amazon Keyspaces 사용량을 관리하여 정의된 요청 속도 이하로 유지하여 예측 가능성을 유지할 수 있습니다.
프로비저닝 모드는 [오토 스케일링](autoscaling.md)을 제공하므로 프로비저닝된 속도를 자동으로 조정하여 규모를 늘리거나 축소하여 운영 효율성을 개선할 수 있습니다. 서버리스 리소스 관리에 대한 자세한 정보는 [Amazon Keyspaces(Apache Cassandra용)에서 서버리스 리소스 관리](serverless_resource_management.md) 섹션을 참조하세요.
Amazon Keyspaces에서 읽기 및 쓰기 처리량 용량을 별도로 프로비저닝하므로 기존 테이블의 읽기 및 쓰기 요청 속도를 독립적으로 측정해야 합니다.
기존 Cassandra 클러스터에서 가장 정확한 사용률 지표를 수집하려면 단일 데이터 센터의 모든 노드에서 집계되는 테이블에 대해 장기간 동안 조정자 수준 읽기 및 쓰기 작업에 대한 RPS(초당 평균 요청)를 캡처합니다.
다음 다이어그램과 같이 최소 몇 주 동안 평균 RPS를 캡처하면 트래픽 패턴의 피크와 밸리가 캡처됩니다.
![\[2주 동안 하루당 초당 평균 요청 속도를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/migration-rps.png)
Cassandra 테이블의 읽기 및 쓰기 요청 속도를 결정하는 두 가지 옵션이 있습니다.
+ 기존 Cassandra 모니터링 사용
다음 표에 표시된 지표를 사용하여 읽기 및 쓰기 요청을 관찰할 수 있습니다. 지표 이름은 사용 중인 모니터링 도구에 따라 변경될 수 있습니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/migrating-cassandra.html)
+ `nodetool` 사용
`nodetool tablestats` 및 `nodetool info`를 사용하여 테이블에서 평균 읽기 및 쓰기 작업을 캡처합니다. `tablestats`는 노드가 시작된 시간부터 총 읽기 및 쓰기 수를 반환합니다. `nodetool info`는 노드의 가동 시간을 초 단위로 제공합니다.
읽기 및 쓰기의 초당 평균을 받으려면 읽기 및 쓰기 수를 노드 가동 시간으로 초 단위로 나눕니다. 그런 다음 읽기의 경우 복제 계수로 나눈 쓰기에 대한 일관성 수준 광고로 나눕니다. 이러한 계산은 다음 공식으로 표현됩니다.
초당 평균 읽기 수식:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
초당 평균 쓰기 수식:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
4주 동안 가동된 12개의 노드 클러스터가 있다고 가정해 보겠습니다. `nodetool info`는 2,419,200초의 가동 시간을 반환하고 `nodetool tablestats`는 10억 개의 쓰기와 20억 개의 읽기를 반환합니다. 이 예제에서는 다음과 같은 계산을 수행합니다.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. 테이블의 용량 사용률 결정
평균 용량 사용률을 추정하려면 Cassandra 소스 테이블의 평균 요청 속도와 평균 행 크기로 시작합니다.
Amazon Keyspaces는 *읽기 용량 단위*(RCU) 및 *쓰기 용량 단위*(WCU)를 사용하여 테이블에 대한 읽기 및 쓰기의 프로비저닝된 처리량 용량을 측정합니다. 이 추정치에서는 이러한 단위를 사용하여 마이그레이션 후 새 Amazon Keyspaces 테이블의 읽기 및 쓰기 용량 요구 사항을 계산합니다.
이 주제의 뒷부분에서는 프로비저닝된 용량 모드와 온디맨드 용량 모드 중에서 선택한 것이 결제에 어떤 영향을 미치는지 설명합니다. 그러나 이 예제의 용량 사용률 추정치를 위해 테이블이 프로비저닝된 모드라고 가정합니다.
+ **읽기** - RCU 1은 최대 4KB 크기의 행에 대한 `LOCAL_QUORUM` 읽기 요청 1회 또는 `LOCAL_ONE` 읽기 요청 2회를 나타냅니다. 4KB보다 큰 행을 읽어야 하는 경우 읽기 작업에 추가 RCU가 사용됩니다. 필요한 총 RCU 수는 행 크기, `LOCAL_QUORUM` 또는 `LOCAL_ONE` 읽기 일관성을 사용하려는지 여부에 따라 다릅니다.
예를 들어 8KB 행을 읽으려면 `LOCAL_QUORUM` 읽기 일관성을 사용하는 2RCU가 필요하고 `LOCAL_ONE` 읽기 일관성을 선택한 경우 1RCU가 필요합니다.
+ **쓰기** - WCU 1은 최대 1KB 크기의 행에 대한 1회의 쓰기를 나타냅니다. 모든 쓰기는 `LOCAL_QUORUM` 일관성을 사용하며 간단한 트랜잭션(LWT) 사용에 대한 추가 비용은 없습니다.
필요한 WCU의 총 수는 행 크기에 따라 달라집니다. 1KB보다 큰 행을 써야 하는 경우 쓰기 작업에 추가 WCU가 사용됩니다. 예를 들어 행 크기가 2KB인 경우 쓰기 요청 하나를 수행하려면 2WCU가 필요합니다.
다음 공식을 사용하여 필요한 RCU 및 WCU를 추정할 수 있습니다.
+ **RCU의 읽기 용량**은 초당 읽기 수에 읽기당 읽기 행 수를 곱하고 평균 행 크기를 4KB로 나눈 다음 가장 가까운 정수로 반올림하여 결정할 수 있습니다.
+ **WCU의 쓰기 용량**은 요청 수에 평균 행 크기를 1KB로 나누고 가장 가까운 정수로 반올림하여 결정할 수 있습니다.
이는 다음 공식으로 표현됩니다.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
예를 들어 Cassandra 테이블에서 행 크기가 2.5KB인 4,960개의 읽기 요청을 수행하는 경우 Amazon Keyspaces에 4,960RCU가 필요합니다. 현재 Cassandra 테이블에서 행 크기가 2.5KB인 초당 1,653개의 쓰기 요청을 수행하는 경우 Amazon Keyspaces에서 초당 4,959WCU가 필요합니다.
이 예제는 다음 공식으로 표현됩니다.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
`eventual consistency`를 사용하면 각 읽기 요청에서 처리량 용량의 최대 절반을 절약할 수 있습니다. 최종적으로 일관된 각 읽기는 최대 8KB를 소비할 수 있습니다. 다음 공식과 같이 이전 계산에 0.5를 곱하여 최종적으로 일관된 읽기를 계산할 수 있습니다.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Amazon Keyspaces에 대한 월별 요금 추정 계산
읽기/쓰기 용량 처리량을 기준으로 테이블의 월별 결제를 추정하려면 다른 공식을 사용하여 온디맨드 및 프로비저닝 모드의 요금을 계산하고 테이블의 옵션을 비교할 수 있습니다.
**프로비저닝 모드** - 읽기 및 쓰기 용량 소비량은 초당 용량 단위를 기준으로 시간당 요금으로 청구됩니다. 먼저 이 비율을 0.7로 나누어 기본 오토 스케일링 대상 사용률 70%를 나타냅니다. 그런 다음 역일 기준 30일, 하루 24시간 및 지역 요금 요금을 곱합니다.
이 계산은 다음 공식에 요약되어 있습니다.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**온디맨드 모드** - 읽기 및 쓰기 용량은 요청 속도당 요금으로 청구됩니다. 먼저 요청 속도를 30일, 하루 24시간으로 곱합니다. 그런 다음 요청 단위를 100만 단위로 나눕니다. 마지막으로 리전 비율을 곱합니다.
이 계산은 다음 공식에 요약되어 있습니다.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## 마이그레이션 전략을 선택합니다.
Apache Cassandra에서 Amazon Keyspaces로 마이그레이션할 때 다음 마이그레이션 전략 중에서 선택할 수 있습니다.
+ **온라인** - 이중 쓰기를 사용하여 Amazon Keyspaces와 Cassandra 클러스터에 새 데이터를 동시에 쓰기 시작하는 실시간 마이그레이션입니다. 이 마이그레이션 유형은 마이그레이션 중에 가동 중지 시간이 없고 쓰기 일관성 이후 읽기가 필요한 애플리케이션에 권장됩니다.
온라인 마이그레이션 전략을 계획하고 구현하는 방법에 대한 자세한 내용은 [Amazon Keyspaces로 온라인 마이그레이션: 전략 및 모범 사례](migrating-online.md) 섹션을 참조하세요.
+ **오프라인** - 이 마이그레이션 기법에는 가동 중지 시간 동안 Cassandra에서 Amazon Keyspaces로 데이터세트를 복사하는 작업이 포함됩니다. 오프라인 마이그레이션은 애플리케이션을 변경하거나 기록 데이터와 새 쓰기 간에 충돌을 해결할 필요가 없기 때문에 마이그레이션 프로세스를 간소화할 수 있습니다.
오프라인 마이그레이션을 계획하는 방법에 대한 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 섹션을 참조하세요.
+ **하이브리드** - 이 마이그레이션 기술을 사용하면 변경 사항을 Amazon Keyspaces에 거의 실시간으로 복제할 수 있지만 쓰기 일관성 후에는 읽지 않아도 됩니다.
하이브리드 마이그레이션을 계획하는 방법에 대한 자세한 내용은 [하이브리드 마이그레이션 솔루션 사용: Apache Cassandra에서 Amazon Keyspaces로](migrating-hybrid.md) 섹션을 참조하세요.
이 주제에서 설명한 마이그레이션 기법과 모범 사례를 검토한 후 의사 결정 트리에 사용 가능한 옵션을 배치하여 요구 사항과 사용 가능한 리소스에 따라 마이그레이션 전략을 설계할 수 있습니다.
# 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 배포를 중단할 수 있습니다.
# 오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로
오프라인 마이그레이션은 마이그레이션을 수행하기 위한 가동 중지 시간을 감당할 수 있는 경우에 적합합니다. 패치, 대규모 릴리스 또는 하드웨어 업그레이드 또는 주요 업그레이드에 대한 가동 중지 시간을 위한 유지 관리 기간이 있는 것은 기업에서 흔히 발생합니다. 오프라인 마이그레이션은 이 창을 사용하여 데이터를 복사하고 Apache Cassandra에서 Amazon Keyspaces로 애플리케이션 트래픽을 전환할 수 있습니다.
오프라인 마이그레이션은 Cassandra와 Amazon Keyspaces에 동시에 통신할 필요가 없기 때문에 애플리케이션 수정을 줄입니다. 또한 데이터 흐름이 일시 중지된 경우 뮤테이션을 유지하지 않고도 정확한 상태를 복사할 수 있습니다.
이 예제에서는 Amazon Simple Storage Service(Amazon S3)를 오프라인 마이그레이션 중에 데이터의 스테이징 영역으로 사용하여 가동 중지 시간을 최소화합니다. Spark Cassandra 커넥터 및 AWS Glue를 사용하여 Amazon S3의 Parquet 형식으로 저장한 데이터를 Amazon Keyspaces 테이블로 자동으로 가져올 수 있습니다. 다음 섹션에서는 프로세스의 상위 수준 개요를 보여줍니다. 이 프로세스의 코드 예제는 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue)에서 찾을 수 있습니다.
Amazon S3를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 오프라인 마이그레이션 프로세스를 수행하려면 다음 AWS Glue작업이 AWS Glue필요합니다.
1. CQL 데이터를 추출 및 변환하여 Amazon S3 버킷에 저장하는 ETL 작업입니다.
1. 버킷에서 Amazon Keyspaces로 데이터를 가져오는 두 번째 작업입니다.
1. 증분 데이터를 가져오는 세 번째 작업입니다.
**Amazon Virtual Private Cloud의 Amazon EC2에서 실행되는 Cassandra에서 Amazon Keyspaces로 오프라인 마이그레이션을 수행하는 방법**
1. 먼저 AWS Glue를 사용하여 Cassandra에서 Parquet 형식으로 테이블 데이터를 내보내고 Amazon S3 버킷에 저장합니다. Cassandra를 실행하는 Amazon EC2 인스턴스가 있는 VPC에 대한 AWS Glue커넥터를 사용하여 AWS Glue작업을 실행해야 합니다. 그런 다음 Amazon S3 프라이빗 엔드포인트를 사용하여 Amazon S3 버킷에 데이터를 저장할 수 있습니다.
다음 다이어그램은 이러한 단계를 보여줍니다.
![\[AWS Glue를 사용하여 VPC에서 실행되는 Amazon EC2에서 Amazon S3 버킷으로 Apache Cassandra 데이터 마이그레이션.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Amazon S3 버킷의 데이터를 셔플하여 데이터 무작위화를 개선합니다. 균등하게 가져온 데이터를 사용하면 대상 테이블에서 더 많은 분산 트래픽을 사용할 수 있습니다.
이 단계는 대규모 파티션(1,000개 이상의 행이 있는 파티션)이 있는 Cassandra에서 데이터를 내보내는 경우 Amazon Keyspaces에 데이터를 삽입할 때 단축키 패턴을 피하기 위해 필요합니다. 핫 키 문제는 Amazon Keyspaces의 `WriteThrottleEvents`에서 발생하며 로드 시간이 늘어납니다.
![\[AWS Glue작업은 Amazon S3 버킷의 데이터를 셔플링하여 다른 Amazon S3 버킷으로 반환합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. 다른 AWS Glue작업을 사용하여 Amazon S3 버킷에서 Amazon Keyspaces로 데이터를 가져옵니다. Amazon S3 버킷의 셔플 데이터는 Parquet 형식으로 저장됩니다.
![\[AWS Glue가져오기 작업은 Amazon S3 버킷에서 셔플 데이터를 가져와 Amazon Keyspaces 테이블로 이동합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/migration-import.png)
오프라인 마이그레이션 프로세스에 대한 자세한 내용은를 사용한 [ Amazon Keyspaces 워크숍을 참조하세요.AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# 하이브리드 마이그레이션 솔루션 사용: Apache Cassandra에서 Amazon Keyspaces로
다음 마이그레이션 솔루션은 온라인 및 오프라인 마이그레이션 간의 하이브리드로 간주될 수 있습니다. 이 하이브리드 접근 방식을 사용하면 쓰기 후 읽기 일관성을 제공하지 않고 거의 실시간으로 대상 데이터베이스에 데이터가 기록됩니다. 즉, 새로 작성된 데이터를 즉시 사용할 수 없으며 지연이 예상됩니다. 쓰기 후 읽기 일관성이 필요한 경우 [Amazon Keyspaces로 온라인 마이그레이션: 전략 및 모범 사례](migrating-online.md) 섹션을 참조하세요.
Apache Cassandra에서 Amazon Keyspaces로 거의 실시간으로 마이그레이션하려면 두 가지 방법 중에서 선택할 수 있습니다.
+ **CQLReplicator** – (권장) CQLReplicator는 [Github](https://github.com/aws-samples/cql-replicator)에서 사용할 수 있는 오픈 소스 유틸리티로, Apache Cassandra에서 Amazon Keyspaces로 데이터를 거의 실시간으로 마이그레이션하는 데 도움이 됩니다.
대상 데이터베이스에 전파할 쓰기 및 업데이트를 결정하기 위해 CQLReplicator는 Apache Cassandra 토큰 범위를 스캔하고 AWS Glue작업을 사용하여 중복 이벤트를 제거하고 Amazon Keyspaces에 직접 쓰기 및 업데이트를 적용합니다.
+ **변경 데이터 캡처(CDC)** - Cassandra CDC에 익숙하다면, 이 하이브리드 마이그레이션을 구현하는 또 다른 옵션은 Apache Cassandra 내장 CDC 기능으로 별도의 CDC 디렉터리에 커밋 로그를 복사하여 변경 사항을 캡처하는 것입니다.
Amazon Keyspaces에 데이터 변경 사항을 복제하여 CDC를 데이터 마이그레이션 시나리오의 대체 옵션으로 만들 수 있습니다.
쓰기 후 읽기 일관성이 필요하지 않은 경우 CQLReplicator 또는 CDC 파이프라인을 사용하여 각 솔루션에 AWS 서비스사용되는 도구에 대한 기본 설정 및 친숙도를 기반으로 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션할 수 있습니다. 이러한 방법을 사용하여 거의 실시간으로 데이터를 마이그레이션하는 것은 온라인 마이그레이션의 대안을 제공하는 하이브리드 마이그레이션 접근 방식으로 간주할 수 있습니다.
이 전략은 이 주제에서 설명한 옵션 외에도 온라인 마이그레이션 진행의 일부 단계(예: [온라인 마이그레이션](migrating-online.md) 주제에서 설명한 기록 데이터 복사 및 애플리케이션 마이그레이션 전략)를 구현해야 하므로 하이브리드 접근 방식으로 간주됩니다.
다음 섹션에서는 하이브리드 마이그레이션 옵션에 대해 자세히 설명합니다.
**Topics**
+ [CQLReplicator를 사용하여 데이터 마이그레이션](migration-hybrid-cql-rep.md)
+ [변경 데이터 캡처(CDC)를 사용하여 데이터 마이그레이션](migration-hybrid-cdc.md)
# CQLReplicator를 사용하여 데이터 마이그레이션
[CQLReplicator](https://github.com/aws-samples/cql-replicator)를 사용하면 CQL 쿼리를 사용하여 Cassandra 토큰 링을 지능적으로 스캔하여 Apache Cassandra에서 거의 실시간으로 데이터를 읽을 수 있습니다. CQLReplicator는 Cassandra CDC를 사용하지 않고 대신 캐싱 전략을 구현하여 전체 스캔의 성능 페널티를 줄입니다.
대상에 대한 쓰기 수를 줄이기 위해 CQLReplicator는 복제 이벤트를 자동으로 제거합니다. CQLReplicator를 사용하면 소스 데이터베이스에서 대상 데이터베이스로의 변경 사항 복제를 조정할 수 있으므로 Apache Cassandra에서 Amazon Keyspaces로 데이터를 거의 실시간으로 마이그레이션할 수 있습니다.
다음 다이어그램은 AWS Glue를 사용하는 CQLReplicator 작업의 일반적인 아키텍처를 보여줍니다.
1. 프라이빗 VPC에서 실행되는 Apache Cassandra에 대한 액세스를 허용하려면 AWS Glue연결 유형 **네트워크**로 연결을 구성합니다.
1. 복제본을 제거하고 CQLReplicator 작업으로 키 캐싱을 활성화하려면 Amazon Simple Storage Service(Amazon S3)를 구성합니다.
1. CQLReplicator 작업은 확인된 소스 데이터베이스 변경 사항을 Amazon Keyspaces로 직접 스트리밍합니다.
![\[CQLReplicator를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
CQLReplicator를 사용한 마이그레이션 프로세스에 대한 자세한 내용은 AWS데이터베이스 블로그 [ CQLReplicator를 사용하여 Cassandra 워크로드를 Amazon Keyspaces로 마이그레이션](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) 및AWS 권장 지침 [를 사용하여 Apache Cassandra 워크로드를 Amazon Keyspaces로 마이그레이션의AWS Glue](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) 다음 게시물을 참조하세요.
# 변경 데이터 캡처(CDC)를 사용하여 데이터 마이그레이션
[Debezium](https://debezium.io/)을 사용하여 변경 데이터 캡처(CDC) 파이프라인을 구성하는 데 이미 익숙한 경우 이 옵션을 사용하여 CQLReplicator를 사용하는 대신 Amazon Keyspaces로 데이터를 마이그레이션할 수 있습니다. Debezium은 데이터베이스를 모니터링하고 행 수준 변경 사항을 안정적으로 캡처하도록 설계된 CDC용 오픈 소스 분산 플랫폼입니다.
[Apache Cassandra용 Debezium 커넥터](https://debezium.io/documentation/reference/stable/connectors/cassandra.html)는 Amazon Managed Streaming for Apache Kafka(Amazon MSK)에 변경 사항을 업로드하여 다운스트림 소비자가 사용하고 처리할 수 있도록 하고, 이를 통해 Amazon Keyspaces에 데이터를 씁니다. 자세한 내용은 [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)를 참조하세요.
잠재적인 데이터 일관성 문제를 해결하기 위해 소비자가 Cassandra의 키 또는 파티션을 Amazon Keyspaces의 키 또는 파티션과 비교하는 Amazon MSK 프로세스를 구현할 수 있습니다.
이 솔루션을 성공적으로 구현하려면 다음을 고려하는 것이 좋습니다.
+ 중복 이벤트를 제거하는 방법 등 CDC 커밋 로그를 구문 분석하는 방법.
+ CDC 디렉터리를 유지하는 방법(예: 이전 로그를 삭제하는 방법).
+ 예를 들어 쓰기가 복제본 3개 중 1개에서만 성공하는 경우 Apache Cassandra에서 부분 장애를 처리하는 방법.
+ 노드에서 발생하는 CDC 프로세스에 대한 추가 CPU, 메모리, DISK 및 IO 요구 사항을 고려하기 위해 인스턴스 크기를 늘리는 등 리소스 할당을 처리하는 방법.
이 패턴은 Cassandra의 변경 사항을 키가 이전 상태에서 변경되었을 수 있는 '힌트'로 취급합니다. 대상 데이터베이스에 전파할 변경 사항이 있는지 확인하려면 먼저 `LOCAL_QUORUM` 작업을 사용하여 원본 Cassandra 클러스터에서 최신 레코드를 받은 다음 Amazon Keyspaces에 기록해야 합니다.
범위 삭제 또는 범위 업데이트의 경우 전체 파티션과 비교하여 대상 데이터베이스에 작성할 쓰기 또는 업데이트 이벤트를 결정해야 할 수 있습니다.
쓰기가 멱등성이 아닌 경우 Amazon Keyspaces에 쓰기 전에 이미 대상 데이터베이스에 있는 것과 쓰기를 비교해야 합니다.
다음 다이어그램은 Debezium 및 Amazon MSK를 사용하는 CDC 파이프라인의 일반적인 아키텍처를 보여줍니다.
![\[변경 데이터 캡처 파이프라인을 사용하여 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Amazon Keyspaces로 데이터를 대량 업로드하거나 마이그레이션하는 데 적합한 도구를 선택하는 방법
이 섹션에서는 Amazon Keyspaces로 데이터를 대량 업로드하거나 마이그레이션하는 데 사용할 수 있는 다양한 도구를 검토하고 필요에 따라 올바른 도구를 선택하는 방법을 배울 수 있습니다. 또한이 섹션에서는 Amazon Keyspaces로 데이터를 가져오는 방법을 보여주는 사용 가능한 step-by-step 자습서에 대한 개요와 사용 사례를 제공합니다.
Apache Cassandra에서 Amazon Keyspaces로 워크로드를 마이그레이션하는 데 사용할 수 있는 전략을 검토하려면 [Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하기 위한 마이그레이션 계획 생성](migrating-cassandra.md) 섹션을 참조하세요.
+ **마이그레이션 도구**
+ Github에서 사용할 수 있는 [Amazon Keyspaces(Apache Cassandra용)의 요금 계산기](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)를 사용하면 기존 Apache Cassandra 워크로드를 기반으로 Amazon Keyspaces의 월별 비용을 추정할 수 있습니다. Cassandra nodetool 상태 출력의 지표와 Amazon Keyspaces의 의도된 서버리스 구성을 입력하여 두 솔루션 간의 직접 비용을 비교합니다. 이 계산기는 기존 Cassandra 배포와 비교하여 Amazon Keyspaces의 운영 비용에만 중점을 둡니다. 인프라 유지 관리, 운영 오버헤드 또는 Cassandra 지원 비용과 같은 총 소유 비용(TCO) 요소는 포함되지 않습니다.
+ **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로의 제로 가동 중지 마이그레이션을 지원합니다.
+ **CQLReplicator** – CQLReplicator는 [Github](https://github.com/aws-samples/cql-replicator)에서 사용할 수 있는 오픈 소스 유틸리티로, Apache Cassandra에서 Amazon Keyspaces로 데이터를 거의 실시간으로 마이그레이션하는 데 도움이 됩니다.
자세한 내용은 [CQLReplicator를 사용하여 데이터 마이그레이션](migration-hybrid-cql-rep.md) 단원을 참조하십시오.
+ Amazon Managed Streaming for Apache Kafka를 사용하여 이중 쓰기를 사용하는 [온라인 마이그레이션](migrating-online.md) 프로세스를 구현하는 방법에 대한 자세한 내용은 [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)를 참조하세요.
+ 대규모 마이그레이션의 경우 추출, 전환, 적재(ETL) 도구를 사용하는 것이 좋습니다. AWS Glue 를 사용하여 데이터 변환 마이그레이션을 빠르고 효과적으로 수행할 수 있습니다. 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 단원을 참조하십시오.
+ Apache Cassandra Spark 커넥터를 사용하여 Amazon Keyspaces에 데이터를 쓰는 방법을 알아보려면 [자습서: Apache Spark와 통합하여 데이터 가져오기 또는 내보내기](spark-integrating.md) 섹션을 참조하세요.
+ cqlsh `COPY FROM` 명령을 사용하여 Amazon Keyspaces로 데이터를 빠르게 로드합니다. cqlsh는 Apache Cassandra에 포함되어 있으며 작은 데이터 세트 또는 테스트 데이터를 로드하는 데 가장 적합합니다. 단계별 지침은 [자습서: cqlsh를 사용하여 Amazon Keyspaces에 데이터 로드](bulk-upload.md)섹션을 참조하세요.
+ Apache Cassandra용 DataStax 벌크 로더를 사용하여 `dsbulk` 명령을 사용하여 Amazon Keyspaces에 데이터를 로드할 수도 있습니다. DSBulk는 cqlsh보다 더욱 강력한 가져오기 기능을 제공하며 [GitHub 리포지토리](https://github.com/datastax/dsbulk)에서 사용할 수 있습니다. 단계별 지침은 [자습서: DSBulk를 사용하여 Amazon Keyspaces에 데이터 로드](dsbulk-upload.md)섹션을 참조하세요.
Amazon Keyspaces에 데이터를 업로드하기 위한 일반적인 고려 사항
+ **데이터 업로드를 더 작은 구성 요소로 나눕니다.**
원시 데이터 크기 측면에서 다음과 같은 마이그레이션 단위와 잠재적 공간을 고려합니다. 한 단계 이상의 단계에서 소량의 데이터를 업로드하면 마이그레이션을 단순화하는 데 도움이 될 수 있습니다.
+ **클러스터별** - 모든 Cassandra 데이터를 한 번에 마이그레이션합니다. 이 접근 방식은 소규모 클러스터의 경우 괜찮을 수 있습니다.
+ **키스페이스 또는 테이블별** - 마이그레이션을 키스페이스 또는 테이블 그룹으로 나눕니다. 이 접근 방식을 사용하면 각 워크로드의 요구 사항에 따라 단계적으로 데이터를 마이그레이션할 수 있습니다.
+ **데이터별** - 데이터 크기를 더 줄이려면 특정 사용자 그룹 또는 제품에 대한 데이터를 마이그레이션하는 것을 고려합니다.
+ **단순성을 기반으로 먼저 업로드할 데이터의 우선 순위를 정합니다.**
먼저 더 쉽게 마이그레이션할 수 있는 데이터가 있는지 고려합니다. 예를 들어 특정 시간대에 변경되지 않는 데이터, 야간 배치 작업의 데이터, 오프라인 시간 동안 사용하지 않은 데이터 또는 내부 앱의 데이터 등이 여기에 해당하는지 고려합니다.
**Topics**
+ [자습서: cqlsh를 사용하여 Amazon Keyspaces에 데이터 로드](bulk-upload.md)
+ [자습서: DSBulk를 사용하여 Amazon Keyspaces에 데이터 로드](dsbulk-upload.md)
# 자습서: cqlsh를 사용하여 Amazon Keyspaces에 데이터 로드
이 자습서는 `cqlsh COPY FROM` 명령을 사용하여 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션하는 프로세스를 안내합니다. 이 `cqlsh COPY FROM` 명령은 학술 또는 테스트 목적으로 Amazon Keyspaces에 작은 데이터세트를 빠르고 쉽게 업로드하는 데 유용합니다. 프로덕션 워크로드를 마이그레이션하는 방법에 대한 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 섹션을 참조하세요. 이 자습서에서는 다음 단계를 완료합니다.
사전 조건 - 자격 증명으로 AWS 계정을 설정하고, 인증서에 대한 JKS 트러스트 스토어 파일을 생성하고, Amazon Keyspaces에 연결`cqlsh`하도록를 구성합니다.
1. **소스 CSV 및 대상 테이블 생성** - 소스 데이터로 CSV 파일을 준비하고 Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. **데이터 준비** - CSV 파일에서 데이터를 무작위 배정하고 분석하여 평균 및 최대 행 크기를 결정합니다.
1. **처리량 용량 설정** - 데이터 크기 및 원하는 로드 시간을 기준으로 필요한 쓰기 용량 단위(WCU)를 계산하고 테이블의 프로비저닝된 용량을 구성합니다.
1. **cqlsh 파라미터 구성** - 워크로드를 균등하게 분산하기 위해 `INGESTRATE`, `NUMPROCESSES`, `MAXBATCHSIZE`, `CHUNKSIZE`와 같은 `cqlsh COPY FROM` 파라미터의 최적 값을 결정합니다.
1. **`cqlsh COPY FROM` 명령 실행 ** - `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 Amazon Keyspaces 테이블에 업로드하고 진행 상황을 모니터링합니다.
문제 해결 - 데이터 업로드 프로세스 중에 잘못된 요청, 구문 분석기 오류, 용량 오류 및 cqlsh 오류와 같은 일반적인 문제를 해결합니다.
**Topics**
+ [사전 조건: `cqlsh COPY FROM`을 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계](bulk-upload-prequs.md)
+ [1단계: 데이터 업로드를 위해 소스 CSV 파일 및 대상 테이블 생성](bulk-upload-source.md)
+ [2단계: 성공적인 데이터 업로드를 위해 소스 데이터 준비](bulk-upload-prepare-data.md)
+ [3단계: 테이블의 처리량 용량 설정](bulk-upload-capacity.md)
+ [4단계: `cqlsh COPY FROM` 설정 구성](bulk-upload-config.md)
+ [5단계: `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드](bulk-upload-run.md)
+ [문제 해결](bulk-upload-troubleshooting.md)
# 사전 조건: `cqlsh COPY FROM`을 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계
이 자습서를 시작하려면 먼저 다음 작업을 완료해야 합니다.
1. 아직 등록하지 않은 경우의 단계에 AWS 계정 따라에 가입합니다[설 AWS Identity and Access Management정](accessing.md#SettingUp.IAM).
1. [Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 서비스별 자격 증명 만들기](programmatic.credentials.ssc.md)의 단계에 따라 서비스별 자격 증명을 생성합니다.
1. Cassandra 쿼리 언어 쉘(cqlsh) 연결을 설정하고 [`cqlsh` 사용하여 Amazon Keyspace에 접속](programmatic.cqlsh.md)의 단계에 따라 Amazon Keyspaces에 연결할 수 있는지 확인합니다.
# 1단계: 데이터 업로드를 위해 소스 CSV 파일 및 대상 테이블 생성
이 자습서에서는 이름 `keyspaces_sample_table.csv`가 있는 쉼표로 구분된 값(CSV) 파일을 데이터 마이그레이션의 원본 파일로 사용합니다. 제공된 샘플 파일에는 이름이 `book_awards`인 테이블에 대한 몇 개의 데이터 행이 포함되어 있습니다.
1. 소스 파일을 생성합니다. 다음 옵션 중 하나를 선택할 수 있습니다.
+ 다음 아카이브 파일 [samplemigration.zip](samples/samplemigration.zip)에 포함된 샘플 CSV 파일(`keyspaces_sample_table.csv`)을 다운로드합니다. 아카이브의 압축을 풀고 `keyspaces_sample_table.csv`의 경로를 기록해 둡니다.
+ Apache Cassandra 데이터베이스에 저장된 자체 데이터로 CSV 파일을 채우려면 다음 예와 같이 `cqlsh` 및 `COPY TO` 문을 사용하여 소스 CSV 파일을 채울 수 있습니다.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
생성한 CSV 파일이 다음 요구 사항을 충족하는지 확인합니다.
+ 첫 번째 행에는 열 이름이 포함됩니다.
+ 소스 CSV 파일의 열 이름은 대상 테이블의 열 이름과 일치합니다.
+ 데이터는 쉼표로 구분됩니다.
+ 모든 데이터 값은 유효한 Amazon Keyspaces 데이터 유형입니다. [데이터 타입](cql.elements.md#cql.data-types)을(를) 참조하세요.
1. Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. `cqlsh`를 사용하여 Amazon Keyspaces에 연결하고 다음 예제의 서비스 엔드포인트, 사용자 이름 및 암호를 사용자 고유의 값으로 바꿉니다.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. 다음 예제와 같이 이름 `catalog`를 사용하여 새 키스페이스를 생성합니다.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. 새 키스페이스를 사용할 수 있게 되면 다음 코드를 사용하여 대상 테이블 `book_awards`를 생성합니다.
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Apache Cassandra가 원본 데이터 소스인 경우 헤더가 일치하는 Amazon Keyspaces 대상 테이블을 생성하는 간단한 방법은 다음 문과 같이 소스 테이블에서 `CREATE TABLE` 문을 생성하는 것입니다.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
그런 다음 Cassandra 소스 테이블의 설명과 일치하는 열 이름 및 데이터 유형을 사용하여 Amazon Keyspaces에 대상 테이블을 생성합니다.
# 2단계: 성공적인 데이터 업로드를 위해 소스 데이터 준비
효율적인 전송을 위해 소스 데이터를 준비하는 것은 2단계 프로세스입니다. 먼저 데이터를 무작위화합니다. 두 번째 단계에서는 데이터를 분석하여 데이터 업로드가 성공적으로 이루어질 수 있도록 적절한 `cqlsh` 파라미터 값과 필요한 테이블 설정을 결정합니다.
**데이터 무작위화**
이 `cqlsh COPY FROM` 명령은 CSV 파일에 나타나는 것과 동일한 순서로 데이터를 읽고 씁니다. `cqlsh COPY TO` 명령을 사용하여 소스 파일을 만들면 데이터가 키 정렬된 순서대로 CSV에 기록됩니다. Amazon Keyspaces는 내부적으로 파티션 키를 사용하여 데이터를 분할합니다. Amazon Keyspaces에는 동일한 파티션 키에 대한 요청을 로드 밸런싱하는 데 도움이 되는 로직이 내장되어 있지만 순서를 무작위로 지정하면 데이터를 로드하는 것이 더 빠르고 효율적입니다. Amazon Keyspaces가 다른 파티션에 쓸 때 발생하는 내장된 로드 밸런싱을 활용할 수 있기 때문입니다.
쓰기를 파티션 전체에 균등하게 분산하려면 소스 파일의 데이터를 무작위화해야 합니다. 이 작업을 수행하는 애플리케이션을 작성하거나 [Shuf](https://en.wikipedia.org/wiki/Shuf)와 같은 오픈 소스 도구를 사용할 수 있습니다. Shuf는 Linux 배포판, macOS([homebrew](https://brew.sh)에 coreutils 설치), Windows(Windows Subsystem for Linux(WSL) 사용)에서 무료로 사용할 수 있습니다. 이 단계에서 열 이름이 있는 헤더 행이 섞이지 않도록 하려면 한 가지 추가 단계가 필요합니다.
헤더를 보존하면서 소스 파일을 무작위화하려면 다음 코드를 입력합니다.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf는 `keyspace.table.csv`라는 새 CSV 파일에 데이터를 다시 씁니다. 이제 필요 없는 `keyspaces_sample_table.csv` 파일을 삭제할 수 있습니다.
**데이터 분석**
데이터를 분석하여 평균 및 최대 행 크기를 결정합니다.
이렇게 하는 이유는 다음과 같습니다.
+ 평균 행 크기는 전송할 총 데이터 양을 추정하는 데 도움이 됩니다.
+ 데이터 업로드에 필요한 쓰기 용량을 프로비저닝하려면 평균 행 크기가 필요합니다.
+ 각 행의 크기가 Amazon Keyspaces의 최대 행 크기인 1MB 미만인지 확인할 수 있습니다.
**참고**
이 할당량은 파티션 크기가 아니라 행 크기를 나타냅니다. Apache Cassandra 파티션과 달리 Amazon Keyspaces 파티션은 크기가 사실상 바인딩되지 않을 수 있습니다. 파티션 키와 클러스터링 열에는 메타데이터를 위한 추가 스토리지가 필요하며 이를 행의 원시 크기에 추가해야 합니다. 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 단원을 참조하십시오.
다음 코드는 [AWK](https://en.wikipedia.org/wiki/AWK)를 사용하여 CSV 파일을 분석하고 평균 및 최대 행 크기를 인쇄합니다.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
이 코드를 실행하면 다음과 같은 결과가 출력됩니다.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
이 자습서의 다음 단계에서 평균 행 크기를 사용하여 테이블의 쓰기 용량을 프로비저닝합니다.
# 3단계: 테이블의 처리량 용량 설정
이 자습서에서는 설정된 시간 범위 내에서 데이터를 로드하도록 cqlsh를 조정하는 방법을 보여 줍니다. 얼마나 많은 읽기와 쓰기를 수행하는지 미리 알고 있기 때문에 프로비저닝된 용량 모드를 사용합니다. 데이터 전송을 완료한 후에는 애플리케이션의 트래픽 패턴에 맞게 테이블의 용량 모드를 설정해야 합니다. 용량 관리에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에서 서버리스 리소스 관리](serverless_resource_management.md) 섹션을 참조하세요.
프로비저닝된 용량 모드를 사용하면 테이블에 프로비저닝할 읽기 및 쓰기 용량을 미리 지정할 수 있습니다. 쓰기 용량은 시간당 청구되며 쓰기 용량 단위(WCU)로 측정됩니다. 각 WCU는 초당 1KB의 데이터 쓰기를 지원하기에 충분한 쓰기 용량입니다. 데이터를 로드할 때 쓰기 속도는 대상 테이블에 설정된 최대 WCU(매개 변수: `write_capacity_units`) 미만이어야 합니다.
기본적으로 테이블에 최대 40,000WCU를 프로비저닝하고 계정의 모든 테이블에 80,000WCU를 프로비저닝할 수 있습니다. 추가 용량이 필요한 경우 [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas)에서 할당량 증가를 요청할 수 있습니다. 할당량에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
**삽입에 필요한 WCU의 평균 수를 계산합니다.**
초당 1KB의 데이터를 삽입하려면 1WCU가 필요합니다. 360,000개의 행이 있는 CSV 파일에 1시간 내에 모든 데이터를 로드하려면 초당 100개의 행을 작성해야 합니다(360,000행/60분/60초 = 초당 100행). 각 행에 최대 1KB의 데이터가 있는 경우 초당 100개의 행을 삽입하려면 테이블에 100WCU를 프로비저닝해야 합니다. 각 행에 1.5KB의 데이터가 있는 경우 초당 한 행을 삽입하려면 WCU 두 개가 필요합니다. 따라서 초당 100개의 행을 삽입하려면 200개의 WCU를 프로비저닝해야 합니다.
초당 행 하나를 삽입하는 데 필요한 WCU 수를 결정하려면 평균 행 크기(바이트)를 1024로 나누고 가장 가까운 정수로 반올림합니다.
예를 들어 평균 행 크기가 3000바이트인 경우 초당 한 행을 삽입하려면 WCU 3개가 필요합니다.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**데이터 로드 시간 및 용량 계산**
이제 CSV 파일의 평균 크기와 행 수를 알았으므로 주어진 시간 동안 데이터를 로드하는 데 필요한 WCU 수와 다양한 WCU 설정을 사용하여 CSV 파일의 모든 데이터를 로드하는 데 걸리는 대략적인 시간을 계산할 수 있습니다.
예를 들어 파일의 각 행이 1KB이고 CSV 파일에 1,000,000개의 행이 있는 경우 1시간 내에 데이터를 로드하려면 해당 시간 동안 테이블에 최소 278개의 WCU를 프로비저닝해야 합니다.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**프로비저닝된 용량 설정 구성**
테이블을 생성할 때 또는 `ALTER TABLE` CQL 명령을 사용하여 테이블의 쓰기 용량 설정을 지정할 수 있습니다. 다음은 `ALTER TABLE` CQL 문을 사용하여 테이블의 프로비저닝된 용량 설정을 변경하는 구문입니다.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
전체 언어 참조는 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter) 섹션을 참조하세요.
# 4단계: `cqlsh COPY FROM` 설정 구성
이 섹션에서는 `cqlsh COPY FROM`의 파라미터 값을 결정하는 방법을 간략하게 설명합니다. `cqlsh COPY FROM` 명령은 이전에 준비한 CSV 파일을 읽고 CQL을 사용하여 Amazon Keyspaces에 데이터를 삽입합니다. 이 명령은 행을 나누어 작업자 집합 간에 `INSERT` 작업을 분배합니다. 각 작업자는 Amazon Keyspaces와 연결을 설정하고 이 채널을 통해 `INSERT` 요청을 보냅니다.
`cqlsh COPY` 명령에는 작업자 간에 작업을 균등하게 분배하기 위한 내부 로직이 없습니다. 하지만 작업이 균등하게 분배되도록 수동으로 구성할 수 있습니다. 먼저 다음과 같은 주요 cqlsh 파라미터를 검토합니다.
+ **DELIMITER** - 쉼표 이외의 구분 기호를 사용한 경우 이 파라미터를 설정할 수 있습니다. 기본값은 쉼표입니다.
+ **INGESTRATE** - `cqlsh COPY FROM`이 초당 처리를 시도하는 대상 행 수입니다. 지정되지 않은 경우 기본값은 100,000입니다.
+ **NUMPROCESSES** - cqlsh가 `COPY FROM` 작업을 위해 생성하는 하위 작업자 프로세스의 수입니다. 이 설정의 최대값은 16이며, 기본값은 `num_cores - 1`입니다. 여기서 `num_cores`는 cqlsh를 실행하는 호스트의 프로세싱 코어 수입니다.
+ **MAXBATCHSIZE** – 배치 크기에 따라 단일 배치에서 대상 테이블에 삽입되는 최대 행 수가 결정됩니다. 설정되지 않은 경우 cqlsh는 삽입된 20개 행의 배치를 사용합니다.
+ **CHUNKSIZE** - 하위 작업자에게 전달되는 작업 단위의 크기입니다. 기본적으로 5,000으로 설정됩니다.
+ **MAXATTEMPTS** - 실패한 작업자 청크를 다시 시도할 수 있는 최대 횟수입니다. 최대 시도 횟수에 도달하면 실패한 레코드가 새 CSV 파일에 기록되며 실패를 조사한 후 나중에 다시 실행할 수 있습니다.
대상 테이블에 프로비저닝한 WCU 수를 기반으로 `INGESTRATE`를 설정합니다. `cqlsh COPY FROM` 명령의 `INGESTRATE`는 제한이 아니라 대상 평균입니다. 즉, 설정한 수치를 초과할 수 있으며 종종 그럴 수도 있습니다. 버스트를 허용하고 데이터 로드 요청을 처리할 수 있는 충분한 용량을 확보하려면 `INGESTRATE`를 테이블 쓰기 용량의 90% 설정합니다.
```
INGESTRATE = WCUs * .90
```
그런 다음 `NUMPROCESSES` 파라미터를 시스템의 코어 수보다 하나 적은 것으로 설정합니다. 다음 코드를 실행하여 시스템의 코어 수를 확인할 수 있습니다.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
이 자습서에서는 다음 값을 사용합니다.
```
NUMPROCESSES = 4
```
각 프로세스는 작업자를 생성하고 각 작업자는 Amazon Keyspaces에 대한 연결을 설정합니다. Amazon Keyspaces는 모든 연결에서 초당 최대 3,000개의 CQL 요청을 지원할 수 있습니다. 즉, 각 작업자가 처리하는 요청이 초당 3,000개 미만인지 확인해야 합니다.
`INGESTRATE`와 마찬가지로 작업자는 설정한 수를 초과하여 버스트하는 경우가 많으며 클록 초로 제한되지 않습니다. 따라서 버스트를 고려하려면 각 작업자가 초당 2,500개의 요청을 처리하게 지정하도록 cqlsh 파라미터를 설정합니다. 작업자에게 분배된 작업량을 계산하려면 다음 지침을 사용합니다.
+ `INGESTRATE`를 `NUMPROCESSES`로 나눕니다.
+ `INGESTRATE`/`NUMPROCESSES` > 2,500인 경우 `INGESTRATE`를 낮추면 이 공식이 true가 됩니다.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
샘플 데이터의 업로드를 최적화하도록 설정을 구성하기 전에 `cqlsh` 기본 설정을 검토하고 기본 설정을 사용하는 것이 데이터 업로드 프로세스에 어떤 영향을 미치는지 살펴보겠습니다. `cqlsh COPY FROM`은 `CHUNKSIZE`를 사용하여 작업자에게 배포할 작업 청크(`INSERT` 문)를 만들기 때문에 작업이 자동으로 균등하게 분배되지 않습니다. `INGESTRATE` 설정에 따라 일부 작업자는 가만히 앉아 있을 수 있습니다.
작업자 간에 작업을 균등하게 분배하고 각 작업자가 초당 2,500개의 요청 속도를 최적화할 수 있도록 하려면 입력 파라미터를 변경하여 `CHUNKSIZE`, `MAXBATCHSIZE` 및 `INGESTRATE`를 설정해야 합니다. 데이터 로드 중에 네트워크 트래픽 사용률을 최적화하려면 `MAXBATCHSIZE`에 대해 최대값인 30에 가까운 값을 선택합니다. `CHUNKSIZE`를 100으로 `MAXBATCHSIZE`를 25로 변경하면 10,000개의 행이 네 명의 작업자 사이에 균등하게 분산됩니다(10,000/2500 = 4).
다음 코드 예제에서는 이를 보여 줍니다.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
요약하면 `cqlsh COPY FROM` 파라미터를 설정할 때 다음 공식을 사용합니다.
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1(기본값)
+ **INGESTRATE / NUMPROCESSES** = 2,500(true 문이어야 합니다.)
+ **MAXBATCHSIZE** = 30(기본값은 20입니다. Amazon Keyspaces는 최대 30개의 배치를 허용합니다.)
+ **CHUNKSIZE** = (INGESTRATE / NUMPROCESSES) / MAXBATCHSIZE
`NUMPROCESSES`, `INGESTRATE` 및 `CHUNKSIZE` 계산을 마쳤고 이제 데이터를 로드할 준비가 되었습니다.
# 5단계: `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드
`cqlsh COPY FROM` 명령을 실행하려면 다음 단계를 완료합니다.
1. cqlsh를 사용하여 Amazon Keyspaces에 연결합니다.
1. 다음 코드를 사용하여 키스페이스를 선택합니다.
```
USE catalog;
```
1. 쓰기 일관성을 `LOCAL_QUORUM`으로 설정합니다. 데이터 내구성을 보장하기 위해 Amazon Keyspaces는 다른 쓰기 일관성 설정을 허용하지 않습니다. 다음 코드를 확인합니다.
```
CONSISTENCY LOCAL_QUORUM;
```
1. 다음 코드 예제를 사용하여 `cqlsh COPY FROM` 구문을 준비합니다.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. 이전 단계에서 준비한 문을 실행합니다. cqlsh는 구성한 모든 설정을 다시 실행합니다.
1. 설정이 입력과 일치하는지 확인합니다. 다음 예를 참조하세요.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. 다음 예와 같이 전송된 행 수와 현재 평균 비율을 검토합니다.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. cqlsh가 데이터 업로드를 완료하면 다음 예와 같이 데이터 로드 통계 요약(읽은 파일 수, 런타임, 건너뛴 행 수)을 검토합니다.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
자습서의 마지막 단계에서는 Amazon Keyspaces에 데이터를 업로드했습니다.
**중요**
이제 데이터를 전송했으니 대상 테이블의 용량 모드 설정을 애플리케이션의 일반 트래픽 패턴에 맞게 조정합니다. 용량을 변경하기 전까지는 프로비저닝된 용량에 대해 시간당 요금이 부과됩니다.
# 문제 해결
데이터 업로드가 완료된 후 행을 건너뛰었는지 확인합니다. 이렇게 하려면 원본 CSV 파일의 소스 디렉터리로 이동하여 다음 이름의 파일을 검색합니다.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh는 건너뛴 데이터 행을 해당 이름의 파일에 기록합니다. 파일이 소스 디렉터리에 있고 그 안에 데이터가 있는 경우 이 행은 Amazon Keyspaces에 업로드되지 않았습니다. 이러한 행을 다시 시도하려면 먼저 업로드 중에 발생한 오류가 있는지 확인하고 그에 따라 데이터를 조정합니다. 이러한 행을 다시 시도하려면 프로세스를 다시 실행하면 됩니다.
**일반적인 오류**
행이 로드되지 않는 가장 일반적인 이유는 용량 오류와 구문 분석 오류입니다.
**Amazon Keyspaces에 데이터를 업로드할 때 잘못된 요청 오류**
다음 예제의 소스 테이블에는 카운터 열이 포함되어 있으며 이로 인해 cqlsh `COPY` 명령의 배치 호출이 로그됩니다. 로그된 배치 호출은 Amazon Keyspaces에서 지원되지 않습니다.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
이 오류를 해결하려면 DSBulk를 사용하여 데이터를 마이그레이션합니다. 자세한 내용은 [자습서: DSBulk를 사용하여 Amazon Keyspaces에 데이터 로드](dsbulk-upload.md) 단원을 참조하십시오.
**Amazon Keyspaces에 데이터를 업로드할 때 구문 분석기 오류**
다음 예는 `ParseError`로 인해 건너뛴 행을 보여 줍니다.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
이 오류를 해결하려면 가져올 데이터가 Amazon Keyspaces의 테이블 스키마와 일치하는지 확인해야 합니다. 가져오기 파일에 구문 분석 오류가 있는지 검토합니다. 오류를 격리하는 `INSERT` 문을 사용하여 단일 데이터 행을 사용해 볼 수 있습니다.
**Amazon Keyspaces에 데이터를 업로드할 때 용량 오류**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces는 처리량 용량이 충분하지 않아 쓰기 요청이 실패하는 경우를 나타내기 위해 `ReadTimeout` 및 `WriteTimeout` 예외를 사용합니다. 용량 부족 예외를 진단하는 데 도움이 되도록 Amazon Keyspaces는 Amazon CloudWatch에 `WriteThrottleEvents` 및 `ReadThrottledEvents` 지표를 게시합니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오.
**Amazon Keyspaces에 데이터를 업로드할 때 cqlsh 오류**
cqlsh 오류를 해결하는 데 도움이 되도록 `--debug` 플래그를 사용하여 실패한 명령을 다시 실행합니다.
호환되지 않는 버전의 cqlsh를 사용하는 경우 다음 오류가 표시됩니다.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
다음 명령을 실행하여 올바른 cqlsh 버전이 설치되어 있는지 확인합니다.
```
cqlsh --version
```
출력에 대해 다음과 같은 내용이 표시되어야 합니다.
```
cqlsh 5.0.1
```
Windows를 사용하는 경우 `cqlsh`의 모든 인스턴스를 `cqlsh.bat`로 바꿉니다. 예를 들어 Windows에서 cqlsh 버전을 확인하려면 다음 명령을 실행합니다.
```
cqlsh.bat --version
```
cqlsh 클라이언트가 서버로부터 유형에 상관없이 연속으로 세 개의 오류를 수신한 후 Amazon Keyspaces에 대한 연결이 실패합니다. cqlsh 클라이언트가 실패하고 다음 메시지가 표시됩니다.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
이 오류를 해결하려면 가져올 데이터가 Amazon Keyspaces의 테이블 스키마와 일치하는지 확인해야 합니다. 가져오기 파일에 구문 분석 오류가 있는지 검토합니다. 오류를 격리하는 INSERT 문을 사용하여 단일 데이터 행을 사용해 볼 수 있습니다.
클라이언트는 자동으로 연결 재설정을 시도합니다.
# 자습서: DSBulk를 사용하여 Amazon Keyspaces에 데이터 로드
[GitHub](https://github.com/datastax/dsbulk.git)에서 제공하는 DataStax 벌크 로더(DSBulk)를 사용하여 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션하는 방법에 대한 단계별 자습서입니다. DSBulk를 사용하면 학습 또는 테스트 목적으로 Amazon Keyspaces에 데이터세트를 업로드하는 데 유용합니다. 프로덕션 워크로드를 마이그레이션하는 방법에 대한 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 섹션을 참조하세요. 이 자습서에서는 다음 단계를 완료합니다.
사전 조건 - 자격 증명으로 AWS 계정을 설정하고, 인증서에 대한 JKS 트러스트 스토어 파일을 생성하고,를 구성하고`cqlsh`, DSBulk를 다운로드 및 설치하고, `application.conf` 파일을 구성합니다.
1. **소스 CSV 및 대상 테이블 생성** - 소스 데이터로 CSV 파일을 준비하고 Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. **데이터 준비** - CSV 파일에서 데이터를 무작위 배정하고 분석하여 평균 및 최대 행 크기를 결정합니다.
1. **처리량 용량 설정** - 데이터 크기 및 원하는 로드 시간을 기준으로 필요한 쓰기 용량 단위(WCU)를 계산하고 테이블의 프로비저닝된 용량을 구성합니다.
1. **DSBulk 설정 구성** - 인증, SSL/TLS, 일관성 수준 및 연결 풀 크기와 같은 설정을 사용하여 DSBulk 구성 파일을 생성합니다.
1. **DSBulk 로드 명령 실행** - DSBulk 로드 명령을 실행하여 CSV 파일에서 Amazon Keyspaces 테이블로 데이터를 업로드하고 진행 상황을 모니터링합니다.
**Topics**
+ [사전 조건: DSBulk를 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계](dsbulk-upload-prequs.md)
+ [1단계: DSBulk를 사용하여 데이터 업로드를 위한 소스 CSV 파일 및 대상 테이블 생성](dsbulk-upload-source.md)
+ [2단계: DSBulk를 사용하여 업로드할 데이터 준비](dsbulk-upload-prepare-data.md)
+ [3단계: 대상 테이블의 처리량 용량 설정](dsbulk-upload-capacity.md)
+ [4단계: CSV 파일에서 대상 테이블로 데이터를 업로드하도록 `DSBulk` 설정 구성](dsbulk-upload-config.md)
+ [5단계: DSBulk `load` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드](dsbulk-upload-run.md)
# 사전 조건: DSBulk를 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계
이 자습서를 시작하려면 먼저 다음 작업을 완료해야 합니다.
1. 아직 등록하지 않은 경우의 단계에 따라 AWS 계정에 가입합니다[설 AWS Identity and Access Management정](accessing.md#SettingUp.IAM).
1. [Amazon Keyspaces에 대한 AWS 자격 증명 생성 및 구성](access.credentials.md)의 단계에 따라 자격 증명을 생성합니다.
1. JKS 신뢰 저장소 파일을 생성합니다.
1. 다음 디지털 인증서를 다운로드하고 파일을 로컬 또는 홈 디렉터리에 저장합니다.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield 클래스 2 루트(선택 사항 - 이전 버전과의 호환성을 위해)
인증서를 다운로드하려면 다음 명령을 사용할 수 있습니다.
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**참고**
Amazon Keyspaces는 이전에 Starfield Class 2 CA에 고정된 TLS 인증서를 사용했습니다. AWS 는 Amazon Trust Services(Amazon Root CA 1\$14)에 따라 발급된 인증서 AWS 리전 로 모두 마이그레이션하고 있습니다. CAs 이 전환 중에 Amazon Root CAs1\$14와 Starfield 루트를 모두 신뢰하도록 클라이언트를 구성하여 모든 리전에서 호환성을 보장합니다.
1. 디지털 인증서를 trustStore 파일로 변환하고 키 스토어에 추가합니다.
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
마지막 단계에서는 키 스토어의 암호를 생성하고 각 인증서를 신뢰해야 합니다. 대화형 명령은 다음과 같습니다.
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Cassandra 쿼리 언어 쉘(cqlsh) 연결을 설정하고 [`cqlsh` 사용하여 Amazon Keyspace에 접속](programmatic.cqlsh.md)의 단계에 따라 Amazon Keyspaces에 연결할 수 있는지 확인합니다.
1. DSBulk를 다운로드하여 설치합니다.
**참고**
이 자습서에 표시된 버전은 사용 가능한 최신 버전이 아닐 수 있습니다. DSBulk를 다운로드하기 전에 [DataStax Bulk Loader 다운로드 페이지에서](https://downloads.datastax.com/#bulk-loader) 최신 버전을 확인하고 다음 명령에서 버전 번호를 적절히 업데이트합니다.
1. DSBulk를 다운로드하려면 다음 코드를 사용할 수 있습니다.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. 그런 후 다음 예제와 같이 tar 파일의 압축을 풀고 `PATH`에 DSBulk를 추가합니다.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. DSBulk에서 사용할 설정을 저장할 `application.conf` 파일을 생성합니다. `./dsbulk_keyspaces.conf`로 다음 예제를 저장할 수 있습니다. 로컬 노드에 있지 않은 경우 `localhost`를 로컬 Cassandra 클러스터의 연락처(예: DNS 이름 또는 IP 주소)로 바꿉니다. 나중에 `dsbulk load` 명령에서 지정해야 하므로 파일 이름과 경로를 기록해 둡니다.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. SigV4 지원을 활성화하려면 [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)에서 음영 처리된 `jar` 파일을 다운로드하고 다음 예와 같이 DSBulk `lib` 폴더에 저장합니다.
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# 1단계: DSBulk를 사용하여 데이터 업로드를 위한 소스 CSV 파일 및 대상 테이블 생성
이 자습서에서는 이름 `keyspaces_sample_table.csv`가 있는 쉼표로 구분된 값(CSV) 파일을 데이터 마이그레이션의 원본 파일로 사용합니다. 제공된 샘플 파일에는 이름이 `book_awards`인 테이블에 대한 몇 개의 데이터 행이 포함되어 있습니다.
1. 소스 파일을 생성합니다. 다음 옵션 중 하나를 선택할 수 있습니다.
+ 다음 아카이브 파일 [samplemigration.zip](samples/samplemigration.zip)에 포함된 샘플 CSV 파일(`keyspaces_sample_table.csv`)을 다운로드합니다. 아카이브의 압축을 풀고 `keyspaces_sample_table.csv`의 경로를 기록해 둡니다.
+ Apache Cassandra 데이터베이스에 저장된 자체 데이터로 CSV 파일을 채우려면 다음 예와 같이 `dsbulk unload`를 사용하여 소스 CSV 파일을 채울 수 있습니다.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
생성한 CSV 파일이 다음 요구 사항을 충족하는지 확인합니다.
+ 첫 번째 행에는 열 이름이 포함됩니다.
+ 소스 CSV 파일의 열 이름은 대상 테이블의 열 이름과 일치합니다.
+ 데이터는 쉼표로 구분됩니다.
+ 모든 데이터 값은 유효한 Amazon Keyspaces 데이터 유형입니다. [데이터 타입](cql.elements.md#cql.data-types)을(를) 참조하세요.
1. Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. `cqlsh`를 사용하여 Amazon Keyspaces에 연결하고 다음 예제의 서비스 엔드포인트, 사용자 이름 및 암호를 사용자 고유의 값으로 바꿉니다.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. 다음 예제와 같이 이름 `catalog`를 사용하여 새 키스페이스를 생성합니다.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. 새 키스페이스가 사용 가능 상태가 되면 다음 코드를 사용하여 대상 테이블 `book_awards`를 생성합니다. 비동기 리소스 생성 및 리소스가 사용 가능한지 확인하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 키스페이스 생성 상태 확인](keyspaces-create.md) 섹션을 참조하세요.
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Apache Cassandra가 원본 데이터 소스인 경우 헤더가 일치하는 Amazon Keyspaces 대상 테이블을 생성하는 간단한 방법은 다음 문과 같이 소스 테이블에서 `CREATE TABLE` 문을 생성하는 것입니다.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
그런 다음 Cassandra 소스 테이블의 설명과 일치하는 열 이름 및 데이터 유형을 사용하여 Amazon Keyspaces에 대상 테이블을 생성합니다.
# 2단계: DSBulk를 사용하여 업로드할 데이터 준비
효율적인 전송을 위해 소스 데이터를 준비하는 것은 2단계 프로세스입니다. 먼저 데이터를 무작위화합니다. 두 번째 단계에서는 데이터를 분석하여 적절한 `dsbulk` 파라미터 값과 필요한 테이블 설정을 결정합니다.
**데이터 무작위화**
이 `dsbulk` 명령은 CSV 파일에 나타나는 것과 동일한 순서로 데이터를 읽고 씁니다. `dsbulk` 명령을 사용하여 소스 파일을 만들면 데이터가 키 정렬된 순서대로 CSV에 기록됩니다. Amazon Keyspaces는 내부적으로 파티션 키를 사용하여 데이터를 분할합니다. Amazon Keyspaces에는 동일한 파티션 키에 대한 요청을 로드 밸런싱하는 데 도움이 되는 로직이 내장되어 있지만 순서를 무작위로 지정하면 데이터를 로드하는 것이 더 빠르고 효율적입니다. Amazon Keyspaces가 다른 파티션에 쓸 때 발생하는 내장된 로드 밸런싱을 활용할 수 있기 때문입니다.
쓰기를 파티션 전체에 균등하게 분산하려면 소스 파일의 데이터를 무작위화해야 합니다. 이 작업을 수행하는 애플리케이션을 작성하거나 [Shuf](https://en.wikipedia.org/wiki/Shuf)와 같은 오픈 소스 도구를 사용할 수 있습니다. Shuf는 Linux 배포판, macOS([homebrew](https://brew.sh)에 coreutils 설치), Windows(Windows Subsystem for Linux(WSL) 사용)에서 무료로 사용할 수 있습니다. 이 단계에서 열 이름이 있는 헤더 행이 섞이지 않도록 하려면 한 가지 추가 단계가 필요합니다.
헤더를 보존하면서 소스 파일을 무작위화하려면 다음 코드를 입력합니다.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf는 `keyspace.table.csv`라는 새 CSV 파일에 데이터를 다시 씁니다. 이제 필요 없는 `keyspaces_sample_table.csv` 파일을 삭제할 수 있습니다.
**데이터 분석**
데이터를 분석하여 평균 및 최대 행 크기를 결정합니다.
이렇게 하는 이유는 다음과 같습니다.
+ 평균 행 크기는 전송할 총 데이터 양을 추정하는 데 도움이 됩니다.
+ 데이터 업로드에 필요한 쓰기 용량을 프로비저닝하려면 평균 행 크기가 필요합니다.
+ 각 행의 크기가 Amazon Keyspaces의 최대 행 크기인 1MB 미만인지 확인할 수 있습니다.
**참고**
이 할당량은 파티션 크기가 아니라 행 크기를 나타냅니다. Apache Cassandra 파티션과 달리 Amazon Keyspaces 파티션은 크기가 사실상 바인딩되지 않을 수 있습니다. 파티션 키와 클러스터링 열에는 메타데이터를 위한 추가 스토리지가 필요하며 이를 행의 원시 크기에 추가해야 합니다. 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 단원을 참조하십시오.
다음 코드는 [AWK](https://en.wikipedia.org/wiki/AWK)를 사용하여 CSV 파일을 분석하고 평균 및 최대 행 크기를 인쇄합니다.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
이 코드를 실행하면 다음과 같은 결과가 출력됩니다.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
최대 행 크기가 1MB를 초과하지 않는지 확인합니다. 그럴 경우 행을 분할하거나 데이터를 압축하여 행 크기를 1MB 미만으로 가져와야 합니다. 이 자습서의 다음 단계에서 평균 행 크기를 사용하여 테이블의 쓰기 용량을 프로비저닝합니다.
# 3단계: 대상 테이블의 처리량 용량 설정
이 자습서에서는 설정된 시간 범위 내에서 데이터를 로드하도록 DSBulk 를 조정하는 방법을 보여 줍니다. 얼마나 많은 읽기와 쓰기를 수행하는지 미리 알고 있기 때문에 프로비저닝된 용량 모드를 사용합니다. 데이터 전송을 완료한 후에는 애플리케이션의 트래픽 패턴에 맞게 테이블의 용량 모드를 설정해야 합니다. 용량 관리에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에서 서버리스 리소스 관리](serverless_resource_management.md) 섹션을 참조하세요.
프로비저닝된 용량 모드를 사용하면 테이블에 프로비저닝할 읽기 및 쓰기 용량을 미리 지정할 수 있습니다. 쓰기 용량은 시간당 청구되며 쓰기 용량 단위(WCU)로 측정됩니다. 각 WCU는 초당 1KB의 데이터 쓰기를 지원하기에 충분한 쓰기 용량입니다. 데이터를 로드할 때 쓰기 속도는 대상 테이블에 설정된 최대 WCU(매개 변수: `write_capacity_units`) 미만이어야 합니다.
기본적으로 테이블에 최대 40,000WCU를 프로비저닝하고 계정의 모든 테이블에 80,000WCU를 프로비저닝할 수 있습니다. 추가 용량이 필요한 경우 [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas)에서 할당량 증가를 요청할 수 있습니다. 할당량에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
**삽입에 필요한 WCU의 평균 수를 계산합니다.**
초당 1KB의 데이터를 삽입하려면 1WCU가 필요합니다. 360,000개의 행이 있는 CSV 파일에 1시간 내에 모든 데이터를 로드하려면 초당 100개의 행을 작성해야 합니다(360,000행/60분/60초 = 초당 100행). 각 행에 최대 1KB의 데이터가 있는 경우 초당 100개의 행을 삽입하려면 테이블에 100WCU를 프로비저닝해야 합니다. 각 행에 1.5KB의 데이터가 있는 경우 초당 한 행을 삽입하려면 WCU 두 개가 필요합니다. 따라서 초당 100개의 행을 삽입하려면 200개의 WCU를 프로비저닝해야 합니다.
초당 행 하나를 삽입하는 데 필요한 WCU 수를 결정하려면 평균 행 크기(바이트)를 1024로 나누고 가장 가까운 정수로 반올림합니다.
예를 들어 평균 행 크기가 3000바이트인 경우 초당 한 행을 삽입하려면 WCU 3개가 필요합니다.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**데이터 로드 시간 및 용량 계산**
이제 CSV 파일의 평균 크기와 행 수를 알았으므로 주어진 시간 동안 데이터를 로드하는 데 필요한 WCU 수와 다양한 WCU 설정을 사용하여 CSV 파일의 모든 데이터를 로드하는 데 걸리는 대략적인 시간을 계산할 수 있습니다.
예를 들어 파일의 각 행이 1KB이고 CSV 파일에 1,000,000개의 행이 있는 경우 1시간 내에 데이터를 로드하려면 해당 시간 동안 테이블에 최소 278개의 WCU를 프로비저닝해야 합니다.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**프로비저닝된 용량 설정 구성**
테이블을 생성할 때 또는 `ALTER TABLE` 명령을 사용하여 테이블의 쓰기 용량 설정을 지정할 수 있습니다. 다음은 `ALTER TABLE` 명령을 사용하여 테이블의 프로비저닝된 용량 설정을 변경하는 구문입니다.
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
전체 언어 참조는 [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) 및 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter) 섹션을 참조하세요.
# 4단계: CSV 파일에서 대상 테이블로 데이터를 업로드하도록 `DSBulk` 설정 구성
이 섹션에서는 Amazon Keyspaces에 데이터를 업로드하기 위해 DSBulk를 구성하는 데 필요한 단계를 간략하게 설명합니다. 구성 파일을 사용하여 DSBulk를 구성합니다. 구성 파일은 명령줄에서 직접 지정합니다.
1. Amazon Keyspaces로 마이그레이션하기 위한 DSBulk 구성 파일을 생성합니다. 이 예에서는 파일 이름 `dsbulk_keyspaces.conf`를 사용합니다. DSBulk 구성 파일에 다음 설정을 지정합니다.
1. *`PlainTextAuthProvider`* - `PlainTextAuthProvider` 클래스를 사용하여 인증 제공자를 생성합니다. `ServiceUserName` 및 `ServicePassword`는 [Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 자격 증명 만들기](programmatic.credentials.md)의 단계에 따라 서비스별 자격 증명을 생성할 때 얻은 사용자 이름 및 암호와 일치해야 합니다.
1. *`local-datacenter`* -의 값을 연결 AWS 리전 중인 `local-datacenter`로 설정합니다. 예를 들어 애플리케이션이 `cassandra.us-east-1.amazonaws.com`에 연결 중인 경우 로컬 데이터 센터를 `us-east-1`로 설정합니다. 사용 가능한 모든 항목은 섹션을 AWS 리전참조하세요[Amazon Keyspaces의 서비스 엔드포인트](programmatic.endpoints.md). 복제본을 피하려면 `slow-replica-avoidance`를 `false`로 설정합니다.
1. *`SSLEngineFactory`* - SSL/TLS를 구성하려면 `class = DefaultSslEngineFactory`로 클래스를 지정하는 한 줄로 구성 파일에 섹션을 추가하여 `SSLEngineFactory`를 초기화합니다. `cassandra_truststore.jks`의 경로와 이전에 만든 암호를 입력합니다.
1. *`consistency`* - 일관성 수준을 `LOCAL QUORUM`으로 설정합니다. 다른 쓰기 일관성 수준은 지원되지 않습니다. 자세한 내용은 [지원되는 Apache Cassandra 읽기 및 쓰기 일관성 수준 및 관련 비용](consistency.md) 섹션을 참조하세요.
1. Java 드라이버에서 풀당 연결 수를 구성할 수 있습니다. 이 예제에서는 `advanced.connection.pool.local.size`를 3으로 설정합니다.
다음은 전체 샘플 구성 파일입니다.
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. DSBulk `load` 명령의 파라미터를 검토합니다.
1. *`executor.maxPerSecond`* - load 명령이 초당 동시에 처리하려고 시도하는 최대 행 수입니다. 설정하지 않으면 이 설정이 -1로 비활성화됩니다.
대상 테이블에 프로비저닝한 WCU 수를 기반으로 `executor.maxPerSecond`를 설정합니다. `load` 명령의 `executor.maxPerSecond`는 제한이 아니라 대상 평균입니다. 즉, 설정한 수치를 초과할 수 있으며 종종 그럴 수도 있습니다. 버스트를 허용하고 데이터 로드 요청을 처리할 수 있는 충분한 용량을 확보하려면 `executor.maxPerSecond`를 테이블 쓰기 용량의 90% 설정합니다.
```
executor.maxPerSecond = WCUs * .90
```
이 자습서에서는 `executor.maxPerSecond`를 5로 설정했습니다.
**참고**
DSBulk 1.6.0 이상을 사용하는 경우 대신 `dsbulk.engine.maxConcurrentQueries`를 사용할 수 있습니다.
1. DSBulk `load` 명령에 대해 이러한 추가 파라미터를 구성합니다.
+ *`batch-mode`* - 이 파라미터는 파티션 키별로 작업을 그룹화하도록 시스템에 지시합니다. 핫키 시나리오와 `WriteThrottleEvents` 원인이 발생할 수 있으므로 배치 모드를 비활성화하는 것이 좋습니다.
+ *`driver.advanced.retry-policy-max-retries`* - 실패한 쿼리를 재시도할 횟수를 결정합니다. 설정하지 않은 경우 기본값은 10입니다. 필요에 따라 이 값을 조정할 수 있습니다.
+ *`driver.basic.request.timeout`* - 시스템에서 쿼리가 반환되기를 기다리는 시간(분)입니다. 설정하지 않은 경우 기본값은 "5분"입니다. 필요에 따라 이 값을 조정할 수 있습니다.
# 5단계: DSBulk `load` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드
이 자습서의 마지막 단계에서는 Amazon Keyspaces에 데이터를 업로드합니다.
DSBulk `load` 명령을 실행하려면 다음 단계를 완료합니다.
1. 다음 코드를 실행하여 csv 파일의 데이터를 Amazon Keyspaces 테이블에 업로드합니다. 이전에 생성한 애플리케이션 구성 파일의 경로를 업데이트해야 합니다.
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. 출력에는 성공한 작업과 실패한 작업을 자세히 설명하는 로그 파일의 위치가 포함됩니다. 이 파일은 다음 디렉터리에 저장됩니다.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. 로그 파일 항목에는 다음 예와 같은 지표가 포함됩니다. 행 수가 csv 파일의 행 수와 일치하는지 확인합니다.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**중요**
이제 데이터를 전송했으니 대상 테이블의 용량 모드 설정을 애플리케이션의 일반 트래픽 패턴에 맞게 조정합니다. 용량을 변경하기 전까지는 프로비저닝된 용량에 대해 시간당 요금이 부과됩니다. 자세한 내용은 [Amazon Keyspaces의 읽기/쓰기 용량 모드 구성](ReadWriteCapacityMode.md) 단원을 참조하십시오.