관계형 데이터베이스에서 DynamoDB로 마이그레이션

관계형 데이터베이스를 DynamoDB로 마이그레이션하려면 성공적인 결과를 보장하기 위해 신중한 계획이 필요합니다. 이 안내서는 이 프로세스의 작동 방식, 사용 가능한 도구, 잠재적 마이그레이션 전략을 평가하고 요구 사항에 맞는 전략을 선택하는 방법을 이해하는 데 도움이 됩니다.

DynamoDB로 마이그레이션하는 이유

Amazon DynamoDB로 마이그레이션하면 기업과 조직은 다양하고 매력적인 이점을 누릴 수 있습니다. 다음은 DynamoDB가 데이터베이스 마이그레이션에 적합한 이유라고 할 수 있는 주요 이점입니다.

관계형 데이터베이스를 DynamoDB로 마이그레이션하는 경우 고려 사항

관계형 데이터베이스 시스템과 NoSQL 데이터베이스는 각기 다른 장단점을 갖고 있습니다. 이런 차이가 두 시스템의 데이터베이스 설계를 다르게 만듭니다.

NoSQL 데이터베이스를 설계할 때는 관계형 데이터베이스 관리 시스템(RDBMS)과는 다른 사고 방식이 필요합니다. RDBMS의 경우, 액세스 패턴을 생각하지 않고 정규화된 데이터 모델을 생성할 수 있습니다. 그런 후 나중에 새로운 질문과 쿼리에 대한 요구 사항이 생길 때 이를 확장할 수 있습니다. 각 데이터 유형을 고유의 테이블에 구성할 수 있습니다.

NoSQL 설계와는 달리, 대답해야 할 질문을 알았을 때 DynamoDB에 대한 스키마를 설계해야 합니다. 비즈니스 문제와 애플리케이션 읽기 및 쓰기 패턴을 이해하는 것이 필수입니다. 또한 DynamoDB 애플리케이션에서는 가능한 적은 수의 테이블을 유지하는 것을 목표로 해야 합니다. 테이블 수가 적을수록 확장성이 향상되고 권한 관리가 줄어들며 DynamoDB 애플리케이션의 오버헤드가 감소합니다. 백업 비용도 전반적으로 낮게 유지할 수 있습니다.

DynamoDB의 관계형 데이터를 모델링하고 프런트엔드 애플리케이션의 새 버전을 구축하는 작업은 별도의 주제입니다. 이 안내서에서는 DynamoDB를 사용하도록 새 버전의 애플리케이션을 구축했다고 가정하지만, 전환 중에 기록 데이터를 마이그레이션하고 동기화하는 최선의 방법을 결정해야 합니다.

크기 조정 고려 사항

DynamoDB 테이블에 저장하는 각 항목(행)의 최대 크기는 400KB입니다. 자세한 내용은 Amazon DynamoDB의 서비스, 계정 및 테이블 할당량 단원을 참조하십시오. 항목 크기는 항목에 있는 모든 속성 이름 및 속성 값의 총 크기에 따라 결정됩니다. 자세한 내용은 DynamoDB 항목 크기 및 형식 단원을 참조하십시오.

애플리케이션이 DynamoDB 크기 제한이 허용하는 것보다 많은 데이터를 항목에 저장해야 하는 경우, 항목을 항목 모음으로 나누거나, 항목 데이터를 압축하거나, Amazon Simple Storage Service(S3)에 항목을 객체로 저장하는 동시에 DynamoDB 항목에 Amazon S3 객체 식별자를 저장합니다. DynamoDB에 큰 항목과 속성 저장 모범 사례 섹션을 참조하세요. 항목 업데이트 비용은 항목의 전체 크기를 기준으로 합니다. 기존 항목을 자주 업데이트해야 하는 워크로드의 경우 1~2KB의 작은 항목이 있으면 큰 항목보다 업데이트 비용이 적게 듭니다. 항목 모음에 대한 자세한 내용은 항목 컬렉션 - DynamoDB에서 일대다 관계를 모델링하는 방법 섹션을 참조하세요.

파티션 및 정렬 키 속성, 기타 테이블 설정, 항목 크기 및 구조, 보조 인덱스 생성 여부를 선택할 때는 DynamoDB 모델링 설명서와 DynamoDB 테이블의 비용 최적화에 대한 안내서를 검토하세요. DynamoDB 솔루션이 비용 효율적이고 DynamoDB의 기능 및 제한 사항을 벗어나지 않는지 마이그레이션 계획을 테스트해야 합니다.

DynamoDB로의 마이그레이션 작동 방식 이해

사용 가능한 마이그레이션 도구를 검토하기 전에 DynamoDB에서 쓰기를 처리하는 방법을 고려해 보세요.

기본적이고 가장 일반적인 쓰기 작업은 단일 PutItem API 작업입니다. 루프에서 PutItem 작업을 수행하여 데이터세트를 처리할 수 있습니다. DynamoDB는 사실상 무제한의 동시 연결을 지원하므로 MapReduce 또는 Spark와 같은 대규모 다중 스레드 로드 루틴을 구성하고 실행할 수 있다고 가정하면 쓰기 속도는 대상 테이블의 용량에 의해서만 제한됩니다. 대상 테이블의 용량도 일반적으로 무제한입니다.

DynamoDB로 데이터를 로드할 때는 로더의 쓰기 속도를 이해하는 것이 중요합니다. 로드하는 항목(행)의 크기가 1KB 이하인 경우 이 속도는 단순히 초당 항목 수입니다. 그러면 대상 테이블에 이 속도를 처리할 수 있는 충분한 쓰기 용량 단위(WCU)를 프로비저닝할 수 있습니다. 로더가 어느 시점에든 프로비저닝된 용량을 초과할 경우 추가 요청이 제한되거나 아예 거부될 수 있습니다. DynamoDB 콘솔 모니터링 탭에 있는 CloudWatch 차트에서 제한을 확인할 수 있습니다.

두 번째로 수행할 수 있는 작업은 BatchWriteItem이라는 관련 API를 사용하는 것입니다. BatchWriteItem은 최대 25개의 쓰기 요청을 하나의 API 직접 호출로 결합할 수 있습니다. 이러한 요청은 서비스에서 수신되며 테이블에 대한 개별 PutItem 요청으로 처리됩니다. 현재는 BatchWriteItem을 선택하면 PutItem을 사용하여 singleton을 직접적으로 호출할 때 AWS SDK에 포함된 자동 재시도 기능을 이용할 수 없습니다. 따라서 오류(예: 제한 예외)가 있는 경우 BatchWriteItem에 대한 응답 직접 호출에서 실패한 쓰기 목록을 찾아야 합니다. CloudWatch 제한 차트에서 제한 경고가 감지된 경우 이를 처리하는 방법에 대한 자세한 내용은 DynamoDB의 제한 문제 섹션을 참조하세요.

세 번째 유형의 데이터 가져오기는 S3에서 DynamoDB로 가져오기 기능을 사용하는 것입니다. 이 기능을 사용하면 Amazon S3에 대규모 데이터세트를 스테이징하고 DynamoDB에 데이터를 새 테이블로 자동으로 가져오도록 요청할 수 있습니다. 가져오기는 즉시 이루어지지 않으며, 데이터세트의 크기에 비례하여 시간이 걸립니다. 하지만 ETL 플랫폼을 사용하거나 사용자 지정 DynamoDB 코드를 작성할 필요가 없으므로 편리합니다. DynamoDB는 가져오기를 통해 생성된 새 테이블에 데이터를 로드합니다. 현재는 기존 테이블에 데이터를 로드할 수 없습니다. DynamoDB는 변환 없이 데이터를 있는 그대로 가져옵니다. PutItem과 마찬가지로 업스트림 프로세스가 필요하며 선택한 형식의 데이터를 Amazon S3 버킷에 씁니다.

DynamoDB로 마이그레이션하는 데 도움이 되는 도구

데이터를 DynamoDB로 마이그레이션하는 데 사용할 수 있는 몇 가지 일반적인 마이그레이션 및 ETL 도구가 있습니다.

Amazon은 AWS Database Migration Service(DMS), AWS Glue, Amazon EMR, Amazon Managed Streaming for Apache Kafka 등 마이그레이션에 사용할 수 있는 다양한 데이터 도구를 제공합니다. 이러한 도구를 모두 사용하여 가동 중지 시간 마이그레이션을 수행할 수 있으며, 관계형 데이터베이스 변경 데이터 캡처(CDC) 기능을 활용하여 온라인 마이그레이션도 지원할 수 있습니다. 도구를 선택할 때는 각 도구의 기능, 성능 및 비용과 함께 조직이 각 도구에 대해 보유하고 있는 기술 역량 및 경험을 고려하는 것이 도움이 됩니다.

많은 고객이 마이그레이션 프로세스를 위한 사용자 지정 데이터 변환을 구축하기 위해 자체 마이그레이션 스크립트와 작업을 작성합니다. 쓰기 트래픽이 많거나 정기적인 대량 로드 작업이 있는 대용량 DynamoDB 테이블을 운영하려는 경우 쓰기 트래픽이 많을 때 DynamoDB의 동작에 더 익숙해지도록 마이그레이션 코드를 직접 작성하는 것이 좋습니다. 마이그레이션을 연습할 때 제한 처리 및 효율적인 테이블 프로비저닝과 같은 시나리오를 프로젝트 초기에 경험할 수 있습니다.

DynamoDB로 마이그레이션하기 위한 적절한 전략 선택

대규모 관계형 데이터베이스 애플리케이션은 테이블이 100개 이상일 수 있으며 다양한 애플리케이션 함수를 지원할 수 있습니다. 대규모 마이그레이션을 진행할 때는 애플리케이션을 더 작은 구성 요소나 마이크로서비스로 나누고 한 번에 작은 테이블 집합을 마이그레이션하는 것을 고려해 보세요. 그런 다음 추가 구성 요소를 DynamoDB로 여러 차례에 걸쳐 마이그레이션할 수 있습니다.

마이그레이션 전략을 선택할 때 다양한 요인에 따라 솔루션을 선택하게 될 수 있습니다. 요구 사항과 사용 가능한 리소스를 고려하여 사용 가능한 옵션을 단순화하기 위해 의사 결정 트리로 이러한 옵션을 시각화할 수 있습니다. 개념은 여기에 간략하게 설명되어 있습니다(이 안내서의 뒷부분에서 더 자세히 다룰 예정).

DynamoDB로 오프라인 마이그레이션 수행

오프라인 마이그레이션은 마이그레이션을 수행할 때 가동 중지 시간을 허용할 수 있는 경우에 적합합니다. 관계형 데이터베이스는 일반적으로 유지 관리 및 패치 적용으로 인해 매달 최소 어느 정도의 가동 중지 시간이 발생하며 하드웨어 업그레이드 또는 메이저 릴리스 업그레이드의 경우 가동 중지 시간이 더 길어질 수 있습니다.

Amazon S3는 마이그레이션 중에 스테이징 영역으로 사용할 수 있습니다. S3에서 DynamoDB로 가져오기 기능을 사용하여 쉼표로 구분된 값(CSV) 또는 DynamoDB JSON 형식으로 저장된 데이터를 새 DynamoDB 테이블로 자동으로 가져올 수 있습니다.

고유한 NoSQL 액세스 패턴을 활용하기 위해 테이블을 결합할 수 있습니다(예: 4개의 레거시 테이블을 단일 DynamoDB 테이블로 변환). 단일 키-값 문서 요청 또는 사전 그룹화된 항목 모음에 대한 쿼리는 일반적으로 다중 테이블 조인을 수행하는 SQL 데이터베이스보다 지연 시간이 더 짧습니다. 하지만 이로 인해 마이그레이션 작업이 더 어려워집니다. SQL 뷰는 소스 데이터베이스 내에서 작업을 수행하여 테이블 4개 모두를 하나의 집합으로 나타내는 단일 데이터세트를 준비할 수 있습니다.

이 뷰는 테이블을 비정규화된 형태로 JOIN할 수도 있고, 엔터티를 정규화한 상태로 유지하고 SQL UNION을 사용하여 테이블을 스태킹할 수도 있습니다. 관계형 데이터 재구성과 관련된 주요 결정 사항은 이 동영상에서 다룹니다. 오프라인 마이그레이션의 경우 뷰를 사용하여 테이블을 결합하는 것은 DynamoDB 단일 테이블 스키마의 데이터를 구성하는 좋은 방법입니다.

계획

Amazon S3를 사용하여 오프라인 마이그레이션 수행

도구

완전 오프라인 마이그레이션은 단순하고 간단하지만 애플리케이션 소유자와 사용자에게는 인기가 없을 수 있습니다. 마이그레이션 중에 애플리케이션이 서비스를 전혀 제공하지 않는 대신 축소된 서비스를 제공할 수 있다면 사용자에게 도움이 될 것입니다.

오프라인 마이그레이션 중에 쓰기를 비활성화하는 기능을 추가하고 읽기는 정상적으로 계속되도록 할 수 있습니다. 관계형 데이터를 마이그레이션하는 동안에도 애플리케이션 사용자는 기존 데이터를 안전하게 찾아보고 쿼리할 수 있습니다. 이 내용을 찾고 있었다면 계속 읽으면서 하이브리드 마이그레이션에 대해 알아보세요.

DynamoDB로 하이브리드 마이그레이션 수행

모든 데이터베이스 애플리케이션이 읽기 및 쓰기 작업을 수행하지만 하이브리드 또는 온라인 마이그레이션을 계획할 때는 수행 중인 쓰기 작업 유형을 고려해야 합니다. 데이터베이스 쓰기는 삽입, 업데이트 및 삭제의 세 가지로 분류할 수 있습니다. 일부 애플리케이션의 경우 삭제를 즉시 처리하지 않아도 될 수 있습니다. 예를 들어 이러한 애플리케이션에서는 월말에 일괄 정리 프로세스를 수행하는 방식으로 삭제를 연기할 수 있습니다. 이러한 유형의 애플리케이션은 부분적인 가동 시간을 허용하면서 더 간단하게 마이그레이션할 수 있습니다.

계획

애플리케이션 이중 쓰기를 허용하면서 하이브리드 온라인/오프라인 마이그레이션 수행

도구

각 테이블을 일대일로 마이그레이션하여 DynamoDB로 온라인 마이그레이션 수행

많은 관계형 데이터베이스에는 변경 데이터 캡처(CDC)라는 기능이 있습니다. 이 기능을 사용하면 사용자가 데이터베이스에서 특정 시점 전 또는 후에 발생한 테이블 변경 사항 목록을 요청할 수 있습니다. CDC는 내부 로그를 사용하여 이 기능을 활성화하며 테이블에 타임스탬프 열이 없어도 작동합니다.

SQL 테이블의 스키마를 NoSQL 데이터베이스로 마이그레이션할 때 데이터를 결합하여 더 적은 수의 테이블로 재구성해야 할 수 있습니다. 이렇게 하면 한 곳에서 데이터를 수집할 수 있고 여러 단계의 읽기 작업에서 관련 데이터를 수동으로 조인하지 않아도 됩니다. 하지만 단일 테이블 데이터 구성이 항상 필요한 것은 아니며 테이블을 일대일로 DynamoDB로 마이그레이션하는 경우도 있습니다. 이러한 일대일 테이블 마이그레이션은 이러한 유형의 마이그레이션을 지원하는 일반 ETL 도구를 사용하여 소스 데이터베이스 CDC 기능을 활용할 수 있으므로 덜 복잡합니다. 각 행의 데이터는 여전히 새 형식으로 변환될 수 있지만 각 테이블의 범위는 변하지 않습니다.

DynamoDB는 서버 측 조인을 지원하지 않는다는 점을 염두에 두고 SQL 테이블을 DynamoDB로 일대일로 마이그레이션하는 것을 고려해 보세요. 여러 테이블의 데이터를 결합하려면 애플리케이션에 로직을 추가해야 합니다.

계획

AWS DMS를 사용하여 각 테이블을 DynamoDB로 온라인 마이그레이션 수행

도구

사용자 지정 스테이징 테이블을 사용하여 DynamoDB로 온라인 마이그레이션 수행

위의 오프라인 마이그레이션 시나리오와 마찬가지로 고유한 NoSQL 액세스 패턴을 활용하기 위해 테이블을 결합할 수 있습니다(예: 4개의 레거시 테이블을 단일 DynamoDB 테이블로 변환). SQL VIEW는 소스 데이터베이스 내에서 작업을 수행하여 테이블 4개 모두를 하나의 집합으로 나타내는 단일 데이터세트를 준비할 수 있습니다.

하지만 변경되는 라이브 데이터가 포함된 온라인 마이그레이션의 경우 CDC 기능은 VIEW에서 지원되지 않으므로 CDC 기능을 활용할 수 없습니다. 테이블에 마지막으로 업데이트된 타임스탬프 열이 포함되어 있고 이 열이 VIEW에 통합되어 있는 경우 이를 사용하여 동기화를 통해 대량 로드를 처리하는 사용자 지정 ETL 작업을 만들 수 있습니다.

이 문제에 대한 새로운 접근 방식은 뷰, 저장 프로시저, 트리거와 같은 표준 SQL 기능을 사용하여 최종적으로 원하는 DynamoDB NoSQL 형식의 새 SQL 테이블을 생성하는 것입니다.

데이터베이스 서버에 여유 용량이 있는 경우 마이그레이션이 시작되기 전에 이 단일 스테이징 테이블을 생성할 수 있습니다. 이를 위해서는 기존 테이블에서 읽고, 필요에 따라 데이터를 변환하고, 새 스테이징 테이블에 쓰는 저장 프로시저를 작성하면 됩니다. 일련의 트리거를 추가하여 테이블의 변경 사항을 스테이징 테이블에 실시간으로 복제할 수 있습니다. 회사 정책에 따라 트리거가 허용되지 않는 경우 저장 프로시저를 변경해도 동일한 결과를 얻을 수 있습니다. 데이터를 쓰는 프로시저에 몇 줄의 코드를 추가하여 동일한 변경 내용을 스테이징 테이블에 추가로 쓸 수 있습니다.

이 스테이징 테이블을 레거시 애플리케이션 테이블과 완전히 동기화하면 실시간 마이그레이션의 훌륭한 출발점이 됩니다. 이제 데이터베이스 CDC를 사용하여 라이브 마이그레이션을 수행하는 도구(예: AWS DMS)를 이 테이블에 사용할 수 있습니다. 이 접근 방식의 장점은 관계형 데이터베이스 엔진에서 사용할 수 있는 잘 알려진 SQL 기술 역량과 기능을 사용한다는 것입니다.

계획

AWS DMS를 사용하여 SQL 스테이징 테이블을 활용하여 온라인 마이그레이션 수행

도구

이 안내서에서는 가동 중지 시간을 최소화하고 일반적인 데이터베이스 도구 및 기법을 사용하는 데 중점을 두고 관계형 데이터베이스 데이터를 DynamoDB로 마이그레이션하기 위한 몇 가지 고려 사항과 접근 방식을 제시했습니다. 자세한 내용은 다음 자료를 참조하세요.