Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하기 위한 마이그레이션 계획 수립 - Amazon Keyspaces(Apache Cassandra용)
호환성예상 요금마이그레이션 전략

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Apache Cassandra에서 Amazon Keyspaces로 마이그레이션하기 위한 마이그레이션 계획 수립

Apache Cassandra에서 Amazon Keyspaces로 성공적으로 마이그레이션하려면 적용 가능한 마이그레이션 개념 및 모범 사례를 검토하고 사용 가능한 옵션을 비교하는 것이 좋습니다.

이 주제에서는 몇 가지 주요 개념과 사용 가능한 도구 및 기술을 소개하여 마이그레이션 프로세스의 작동 방식을 간략하게 설명합니다. 다양한 마이그레이션 전략을 평가하여 요구 사항에 가장 적합한 전략을 선택할 수 있습니다.

주제

기능적 호환성

마이그레이션하기 전에 Apache Cassandra와 Amazon Keyspaces 간의 기능적 차이를 신중하게 고려하십시오. Amazon Keyspaces는 키스페이스 및 테이블 생성, 데이터 읽기, 데이터 쓰기 등 일반적으로 사용되는 모든 Cassandra 데이터 플레인 작업을 지원합니다.

하지만 APIs Amazon Keyspaces가 지원하지 않는 카산드라도 있습니다. 지원에 대한 자세한 내용은 을 참조하십시오. APIs 지원되는 Cassandra API, 작업, 함수, 데이터 유형 Amazon Keyspace와 Apache Cassandra 간의 모든 기능적 차이에 대한 개요는 를 참조하십시오. 기능적 차이: Amazon Keyspaces와 Apache Cassandra

사용 중인 카산드라 APIs 및 스키마를 Amazon Keyspaces에서 지원되는 기능과 비교하려면 Amazon Keyspaces 도구 키트에서 사용할 수 있는 호환성 스크립트를 실행할 수 있습니다. GitHub

호환성 스크립트 사용 방법

  1. 에서 GitHub호환성 Python 스크립트를 다운로드하여 기존 Apache Cassandra 클러스터에 액세스할 수 있는 위치로 이동합니다.

  2. 호환성 스크립트는 와 유사한 매개 변수를 사용합니다. CQLSH 클러스터의 Cassandra 노드 중 하나에 연결하고 쿼리를 실행하는 데 사용하는 IP 주소 및 포트를 --port 입력하고 입력합니다. --host

    Cassandra 클러스터에서 인증을 사용하는 경우 및 도 제공해야 합니다. -username -password 호환성 스크립트를 실행하려면 다음 명령을 사용할 수 있습니다.

    python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

아마존 키스페이스 가격 추정

이 섹션에서는 Amazon Keyspaces의 예상 비용을 계산하기 위해 Apache Cassandra 테이블에서 수집해야 하는 정보에 대한 개요를 제공합니다. 각 테이블에는 필요한 데이터 유형이 다르고, 서로 다른 CQL 쿼리를 지원해야 하며, 고유한 읽기/쓰기 트래픽을 유지 관리해야 합니다.

테이블을 기반으로 요구 사항을 고려하면 Amazon Keyspace의 테이블 수준 리소스 격리 및 읽기/쓰기 처리 용량 모드와 일치합니다. Amazon Keyspaces를 사용하면 테이블의 읽기/쓰기 용량 및 자동 조정 정책을 독립적으로 정의할 수 있습니다.

테이블 요구 사항을 이해하면 기능, 비용 및 마이그레이션 노력을 기반으로 마이그레이션할 테이블의 우선 순위를 정하는 데 도움이 됩니다.

마이그레이션하기 전에 다음 Cassandra 테이블 지표를 수집하십시오. 이 정보는 Amazon Keyspace에서의 워크로드 비용을 추정하는 데 도움이 됩니다.

  • 테이블 이름 — 정규화된 키스페이스의 이름 및 테이블 이름.

  • 설명 - 테이블에 대한 설명 (예: 테이블 사용 방법 또는 테이블에 저장된 데이터 유형)

  • 초당 평균 읽기 — 오랜 기간 동안 테이블에 대해 좌표 수준에서 읽은 평균 횟수입니다.

  • 초당 평균 쓰기 — 오랜 기간 동안 테이블에 대한 평균 좌표 수준 쓰기 횟수입니다.

  • 평균 행 크기 (바이트) — 평균 행 크기 (바이트).

  • 스토리지 크기 (GBs단위) - 테이블의 원시 스토리지 크기.

  • 읽기 일관성 분석 — 최종 일관성 (LOCAL_ONE또는ONE) 을 사용하는 읽기와 강력한 일관성 () 을 사용하는 읽기의 비율입니다. LOCAL_QUORUM

이 표에는 마이그레이션을 계획할 때 취합해야 하는 테이블 관련 정보의 예가 나와 있습니다.

테이블 이름 설명 초당 평균 읽기 초당 평균 쓰기 평균 행 크기 (바이트) 스토리지 크기 (단위) GBs 읽기 일관성 분석

마이키스페이스. 마이테이블

장바구니 기록을 저장하는 데 사용됩니다.

10,000개

5,000

2,200

2,000

100% LOCAL_ONE

마이 키스페이스. 마이 테이블 2

최신 프로필 정보를 저장하는 데 사용됩니다.

20,000건

1,000

850

1,000

25% LOCAL_QUORUM 75% LOCAL_ONE

테이블 메트릭을 수집하는 방법

이 섹션에서는 기존 Cassandra 클러스터에서 필요한 테이블 메트릭을 수집하는 방법에 대한 단계별 지침을 제공합니다. 이러한 지표에는 행 크기, 테이블 크기, 초당 읽기/쓰기 요청 () 이 포함됩니다. RPS 이를 통해 Amazon Keyspaces 테이블의 처리 용량 요구 사항을 평가하고 요금을 추정할 수 있습니다.

Cassandra 소스 테이블에서 테이블 지표를 수집하는 방법

  1. 행 크기 결정

    행 크기는 Amazon Keyspace의 읽기 용량 및 쓰기 용량 사용률을 결정하는 데 중요합니다. 다음 다이어그램은 카산드라 토큰 범위에 걸친 일반적인 데이터 분포를 보여줍니다.

    파티셔너를 사용한 카산드라 토큰 범위의 일반적인 데이터 분포를 보여주는 다이어그램입니다. murmur3

    에서 사용할 수 있는 행 크기 샘플러 스크립트를 사용하여 Cassandra 클러스터의 각 테이블에 대한 GitHub행 크기 메트릭을 수집할 수 있습니다.

    이 스크립트는 구성 가능한 테이블 데이터 샘플 세트에 대한 행 크기의 최소, 최대, 평균 cqlsh 및 awk 표준 편차를 사용하고 계산하는 방식으로 Apache Cassandra에서 테이블 데이터를 내보냅니다. 행 크기 샘플러는 인수를 로 cqlsh 전달하므로 동일한 매개변수를 사용하여 Cassandra 클러스터를 연결하고 읽을 수 있습니다.

    다음 문은 이에 대한 예입니다.

    ./row-size-sampler.sh 10.22.33.44 9142 \\
   -u "username" -p "password" --ssl

    Amazon Keyspaces에서 행 크기를 계산하는 방법에 대한 자세한 내용은 을 참조하십시오. Amazon Keyspace의 행 크기 추정

  2. 테이블 크기 결정

    Amazon Keyspaces를 사용하면 스토리지를 미리 프로비저닝할 필요가 없습니다. Amazon Keyspaces는 테이블의 청구 가능 크기를 지속적으로 모니터링하여 스토리지 요금을 결정합니다. 스토리지는 월별 GB당 요금이 청구됩니다. Amazon Keyspaces 테이블 크기는 단일 복제본의 원시 크기 (압축되지 않은 크기) 를 기준으로 합니다.

    Amazon Keyspace의 테이블 크기를 모니터링하려면 각 테이블에 대해 표시되는 지표를 BillableTableSizeInBytes 사용할 수 있습니다. AWS Management Console.

    Amazon Keyspaces 테이블의 청구 가능 크기를 추정하려면 다음 두 가지 방법 중 하나를 사용할 수 있습니다.

    • 평균 행 크기를 사용하고 행 수를 곱하십시오.

      평균 행 크기에 Cassandra 소스 테이블의 행 수를 곱하여 Amazon Keyspaces 테이블의 크기를 추정할 수 있습니다. 이전 섹션의 행 크기 샘플 스크립트를 사용하여 평균 행 크기를 캡처하십시오. 행 수를 dsbulk count 캡처하려면 등의 도구를 사용하여 원본 테이블의 총 행 수를 확인할 수 있습니다.

    • 를 사용하여 테이블 메타데이터를 nodetool 수집할 수 있습니다.

      NodetoolApache Cassandra 배포판에서 제공되는 관리 도구로, Cassandra 프로세스의 상태를 파악하고 테이블 메타데이터를 반환합니다. 테이블 크기에 대한 메타데이터를 nodetool 샘플링하여 Amazon Keyspace의 테이블 크기를 추정하는 데 사용할 수 있습니다.

      사용할 명령은 입니다. nodetool tablestats Tablestats는 테이블의 크기와 압축률을 반환합니다. 테이블 크기는 테이블의 크기로 저장되며 이 크기를 로 나눌 수 있습니다. tablelivespace compression ratio 그런 다음 이 크기 값에 노드 수를 곱합니다. 마지막으로 복제 인자 (일반적으로 3) 로 나눕니다.

      이것은 테이블 크기를 평가하는 데 사용할 수 있는 완전한 계산 공식입니다.

      ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

      Cassandra 클러스터에 12개의 노드가 있다고 가정해 보겠습니다. nodetool tablestats명령을 실행하면 tablelivespace 200GB의 a와 0.5의 a가 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

  3. 읽기 및 쓰기 횟수를 캡처합니다.

    Amazon Keyspaces 테이블의 용량 및 규모 조정 요구 사항을 확인하려면 마이그레이션 전에 Cassandra 테이블의 읽기 및 쓰기 요청 비율을 캡처하십시오.

    Amazon Keyspaces는 서버리스이므로 사용한 만큼만 비용을 지불하면 됩니다. 일반적으로 Amazon Keyspace의 읽기/쓰기 처리량 요금은 요청 수와 크기를 기준으로 합니다.

    Amazon Keyspace에는 두 가지 용량 모드가 있습니다.

    • 온디맨드 — 용량 계획 없이 초당 수천 건의 요청을 처리할 수 있는 유연한 청구 옵션입니다. 읽기 및 쓰기 요청에 대한 pay-per-request 요금을 제공하므로 사용한 만큼만 비용을 지불하면 됩니다.

    • 프로비저닝 — 프로비저닝된 처리량 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 수를 지정합니다. 이를 통해 Amazon Keyspaces 사용이 정의된 요청 속도 이하로 유지되도록 관리하여 가격을 최적화하고 예측 가능성을 유지할 수 있습니다.

      프로비저닝된 모드에서는 Auto Scaling을 통해 프로비저닝 속도를 자동으로 조정하여 규모를 늘리거나 줄여 운영 효율성을 높일 수 있습니다. 서버리스 리소스 관리에 대한 자세한 내용은 을 참조하십시오. Amazon Keyspaces의 서버리스 리소스 관리 (아파치 카산드라용)

    Amazon Keyspaces에서 읽기 및 쓰기 처리 용량을 개별적으로 프로비저닝하므로 기존 테이블의 읽기 및 쓰기 요청 속도를 개별적으로 측정해야 합니다.

    기존 Cassandra 클러스터에서 가장 정확한 사용률 지표를 수집하려면 단일 데이터 센터의 모든 노드에 걸쳐 집계된 테이블에 대해 장기간에 걸친 코디네이터 수준의 읽기 및 쓰기 작업에 대한 초당 평균 요청 수 (RPS) 를 캡처하십시오.

    다음 다이어그램과 같이 최소 몇 주 RPS 동안의 평균을 캡처하면 트래픽 패턴의 최고점과 최저점을 캡처할 수 있습니다.

    2주 동안의 일일 초당 평균 요청 비율을 보여주는 다이어그램입니다.

    Cassandra 테이블의 읽기 및 쓰기 요청 비율을 결정하는 데는 두 가지 옵션이 있습니다.

    • 기존 카산드라 모니터링 사용

      다음 표에 표시된 지표를 사용하여 읽기 및 쓰기 요청을 관찰할 수 있습니다. 단, 지표 이름은 사용 중인 모니터링 도구에 따라 변경될 수 있습니다.

      측정기준 카산드라 메트릭 JMX

      쓰기

      org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count

      읽습니다

      org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

    • 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 info2,419,200초의 가동 시간을 반환하고 10억 개의 쓰기와 20억 개의 읽기를 nodetool tablestats 반환합니다. 이 예제의 계산 결과는 다음과 같습니다.

      ((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

  4. 테이블의 용량 활용도를 결정하십시오.

    평균 용량 사용률을 추정하려면 먼저 Cassandra 소스 테이블의 평균 요청 비율과 평균 행 크기에서 시작하십시오.

    Amazon Keyspace는 읽기 용량 단위 (RCUs) 및 쓰기 용량 단위 (WCUs) 를 사용하여 테이블의 읽기 및 쓰기에 대한 프로비저닝된 처리 용량을 측정합니다. 이 추정치에서는 이러한 단위를 사용하여 마이그레이션 후 새 Amazon Keyspaces 테이블의 읽기 및 쓰기 용량 요구량을 계산합니다.

    이 주제 후반부에서는 프로비저닝된 용량 모드와 온디맨드 용량 모드 중 선택이 청구에 미치는 영향에 대해 설명하겠습니다. 하지만 이 예제의 용량 사용률 추정치에서는 테이블이 프로비저닝 모드라고 가정합니다.

    • 읽기 - 하나는 최대 4KB 크기의 행에 대한 LOCAL_ONE 읽기 요청 1개 LOCAL_QUORUM 또는 읽기 요청 2개를 RCU 나타냅니다. 4KB보다 큰 행을 읽어야 하는 경우 읽기 작업에는 추가 행이 사용됩니다RCUs. RCUs필요한 총 개수는 행 크기, 사용 여부 LOCAL_QUORUM 또는 LOCAL_ONE 읽기 일관성 여부에 따라 달라집니다.

      예를 들어 8KB 행을 읽으려면 읽기 일관성을 RCUs 사용하는 경우 2개, LOCAL_QUORUM 읽기 일관성을 선택한 RCU LOCAL_ONE 경우 1개가 필요합니다.

    • 쓰기 - 1은 최대 1KB 크기의 행에 대한 쓰기 1회를 WCU 나타냅니다. 모든 쓰기는 LOCAL_QUORUM 일관성을 사용하며 경량 트랜잭션 사용에 대한 추가 비용은 없습니다 (LWTs).

      WCUs필요한 총 개수는 행 크기에 따라 달라집니다. 1KB보다 큰 행을 써야 하는 경우 쓰기 작업에 추가 행이 사용됩니다WCUs. 예를 들어 행 크기가 2KB인 경우 쓰기 요청 1건을 WCUs 수행하려면 2KB가 필요합니다.

    다음 공식을 사용하여 필요한 RCUs AN을 추정할 수 WCUs 있습니다.

    • 읽기 용량 (%) 은 초당 읽기 횟수에 읽기당 읽은 행 수를 곱하고 평균 행 크기를 4KB로 나눈 다음 가장 가까운 정수로 반올림하여 구할 수 있습니다. RCUs

    • 쓰기 용량은 요청 수에 평균 행 크기를 1KB로 나눈 다음 가장 가까운 정수로 반올림하여 구할 WCUs 수 있습니다.

    이는 다음 공식으로 표현됩니다.

    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

    예를 들어 카산드라 테이블에서 행 크기가 2.5KB인 4,960개의 읽기 요청을 수행하는 경우 Amazon Keyspace에는 4,960개의 읽기 요청이 필요합니다. RCUs 현재 Cassandra 테이블에서 2.5KB의 행 크기로 초당 1,653개의 쓰기 요청을 수행하고 있다면 Amazon Keyspaces에서 초당 4,959개의 쓰기 요청이 필요합니다. WCUs

    이 예제는 다음 공식으로 표현됩니다.

    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

  5. 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 Keyspace와 Cassandra 클러스터에 새 데이터를 동시에 쓰기 시작하는 라이브 마이그레이션입니다. 이 마이그레이션 유형은 마이그레이션 중에 다운타임이 전혀 없고 쓰기 후 읽기 일관성이 필요한 애플리케이션에 권장됩니다.

    온라인 마이그레이션 전략을 계획하고 구현하는 방법에 대한 자세한 내용은 을 참조하십시오Amazon Keyspace로의 온라인 마이그레이션: 전략 및 모범 사례.

  • 오프라인 — 이 마이그레이션 기법에는 다운타임 기간 동안 Cassandra에서 Amazon Keyspaces로 데이터 세트를 복사하는 작업이 포함됩니다. 오프라인 마이그레이션은 애플리케이션을 변경하거나 기록 데이터와 새 쓰기 간의 충돌 해결이 필요하지 않기 때문에 마이그레이션 프로세스를 간소화할 수 있습니다.

    오프라인 마이그레이션을 계획하는 방법에 대한 자세한 내용은 을 참조하십시오오프라인 마이그레이션 프로세스: 아파치 카산드라에서 Amazon Keyspaces로.

  • 하이브리드 — 이 마이그레이션 기술을 사용하면 쓰기 후 읽기 일관성 없이 거의 실시간으로 Amazon Keyspaces에 변경 내용을 복제할 수 있습니다.

이 주제에서 설명하는 마이그레이션 기술과 모범 사례를 검토한 후, 사용 가능한 옵션을 의사 결정 트리에 배치하여 요구 사항과 사용 가능한 리소스를 기반으로 마이그레이션 전략을 설계할 수 있습니다.