관계형 데이터베이스에서 DynamoDB로 마이그레이션
관계형 데이터베이스를 DynamoDB로 마이그레이션하려면 성공적인 결과를 보장하기 위해 신중한 계획이 필요합니다. 이 안내서는 이 프로세스의 작동 방식, 사용 가능한 도구, 잠재적 마이그레이션 전략을 평가하고 요구 사항에 맞는 전략을 선택하는 방법을 이해하는 데 도움이 됩니다.
주제
DynamoDB로 마이그레이션하는 이유
Amazon DynamoDB로 마이그레이션하면 기업과 조직은 다양하고 매력적인 이점을 누릴 수 있습니다. 다음은 DynamoDB가 데이터베이스 마이그레이션에 적합한 이유라고 할 수 있는 주요 이점입니다.
-
확장성: DynamoDB는 대규모 워크로드를 처리하고 증가하는 데이터 볼륨 및 트래픽을 수용하기 위해 원활하게 확장할 수 있도록 설계되었습니다. DynamoDB를 사용하면 수요에 따라 데이터베이스를 쉽게 확장하거나 축소할 수 있으므로 애플리케이션에서 성능 저하 없이 갑작스러운 트래픽 급증을 처리할 수 있습니다.
-
성능: DynamoDB는 지연 시간이 짧은 데이터 액세스를 제공하므로 애플리케이션이 뛰어난 속도로 데이터를 검색하고 처리할 수 있습니다. 분산 아키텍처는 읽기 및 쓰기 작업이 여러 노드에 분산되도록 하여 요청 속도가 높아도 일관되게 10밀리초 미만의 응답 시간을 제공합니다.
-
완전관리형: DynamoDB는 AWS에서 제공하는 완전관리형 서비스입니다. 즉, 프로비저닝, 구성, 패치 적용, 백업, 규모 조정 등 데이터베이스 관리의 운영 측면을 AWS가 처리합니다. 따라서 개발자는 데이터베이스 관리 작업보다는 애플리케이션 개발에 더 집중할 수 있습니다.
-
서버리스 아키텍처: DynamoDB는 DynamoDB 온디맨드라고 하는 서버리스 모델을 지원합니다. 이 모델에서는 사전 용량 프로비저닝이 필요 없이 애플리케이션이 수행한 실제 읽기 및 쓰기 요청에 대해서만 비용을 지불합니다. 이 요청당 지불 모델은 용량을 프로비저닝하고 모니터링할 필요 없이 사용한 리소스에 대해서만 비용을 지불하므로 비용 효율성이 높고 운영 오버헤드를 최소화합니다.
-
NoSQL 유연성: 기존 관계형 데이터베이스와 달리 DynamoDB는 NoSQL 데이터 모델을 따르므로 스키마 설계에 유연성을 제공합니다. DynamoDB를 사용하면 정형, 반정형 및 비정형 데이터를 저장할 수 있으므로 다양하고 변화하는 데이터 유형을 처리하는 데 적합합니다. 이러한 유연성 덕분에 개발 주기를 단축하고 변화하는 비즈니스 요구 사항에 쉽게 적응할 수 있습니다.
-
고가용성 및 내구성: DynamoDB는 리전 내 여러 가용 영역에 데이터를 복제하여 고가용성과 데이터 내구성을 보장합니다. 복제, 장애 조치 및 복구를 자동으로 처리하여 데이터 손실이나 서비스 중단의 위험을 최소화합니다. DynamoDB는 최대 99.999%의 가용성 SLA를 제공합니다.
-
보안 및 규정 준수: DynamoDB는 AWS Identity and Access Management와 통합되어 세분화된 액세스 제어를 제공합니다. 저장 데이터 암호화 및 전송 중 암호화 기능을 제공하여 데이터의 보안을 보장합니다. 또한 DynamoDB는 HIPAA, PCI DSS, GDPR을 비롯한 다양한 규정 준수 표준을 준수하므로 규제 요구 사항을 충족할 수 있습니다.
-
AWS 에코시스템과의 통합: DynamoDB는 AWS 에코시스템의 일부로서 AWS Lambda, AWS CloudFormation, AWS AppSync 등의 다른 AWS 서비스와 원활하게 통합됩니다. 이러한 통합을 통해 서버리스 아키텍처를 구축하고, 코드형 인프라를 활용하고, 실시간 데이터 기반 애플리케이션을 만들 수 있습니다.
관계형 데이터베이스를 DynamoDB로 마이그레이션하는 경우 고려 사항
관계형 데이터베이스 시스템과 NoSQL 데이터베이스는 각기 다른 장단점을 갖고 있습니다. 이런 차이가 두 시스템의 데이터베이스 설계를 다르게 만듭니다.
| 관계형 데이터베이스 | NoSQL 데이터베이스 | |
|---|---|---|
| 데이터베이스 쿼리 | 관계형 데이터베이스에서는 데이터를 유연하게 쿼리할 수 있지만, 쿼리 비용이 상대적으로 높으며 트래픽이 많은 상황에서는 확장성이 떨어집니다(DynamoDB의 관계형 데이터를 모델링하는 첫 번째 단계 참조). 관계형 데이터베이스 애플리케이션은 저장 프로시저, SQL 하위 쿼리, 대량 업데이트 쿼리 및 집계 쿼리에서 비즈니스 로직을 구현할 수 있습니다. | DynamoDB와 같은 NoSQL 데이터베이스에서는 몇 가지 방법으로 데이터를 효율적으로 쿼리할 수 있지만, 그 외에는 쿼리 비용이 높고 속도가 느립니다. DynamoDB에 대한 쓰기는 singleton입니다. 이전에 저장 프로시저에서 실행되었던 애플리케이션 비즈니스 로직은 Amazon EC2 또는 AWS Lambda 같은 호스트에서 실행되는 사용자 지정 코드로 DynamoDB 외부에서 실행되도록 리팩터링해야 합니다. |
| 데이터베이스 설계 | 세부적인 구현이나 성능을 걱정하지 않고 유연성을 목적으로 설계합니다. 일반적으로 쿼리 최적화가 스키마 설계에 영향을 미치지 않지만, 정규화가 중요합니다. | 가장 중요하고 범용적인 쿼리를 가능한 빠르고 저렴하게 수행할 수 있도록 스키마를 설계합니다. 사용자의 데이터 구조는 사용자 비즈니스 사용 사례의 특정 요구 사항에 적합하도록 만듭니다. |
NoSQL 데이터베이스를 설계할 때는 관계형 데이터베이스 관리 시스템(RDBMS)과는 다른 사고 방식이 필요합니다. RDBMS의 경우, 액세스 패턴을 생각하지 않고 정규화된 데이터 모델을 생성할 수 있습니다. 그런 후 나중에 새로운 질문과 쿼리에 대한 요구 사항이 생길 때 이를 확장할 수 있습니다. 각 데이터 유형을 고유의 테이블에 구성할 수 있습니다.
NoSQL 설계와는 달리, 대답해야 할 질문을 알기 전까지는 DynamoDB에 대한 스키마 설계를 시작해서는 안 됩니다. 비즈니스 문제와 애플리케이션 읽기 및 쓰기 패턴을 이해하는 것이 필수입니다. 또한 DynamoDB 애플리케이션에서는 가능한 적은 수의 테이블을 유지하는 것을 목표로 해야 합니다. 테이블 수가 적을수록 확장성이 향상되고 권한 관리가 줄어들며 DynamoDB 애플리케이션의 오버헤드가 감소합니다. 백업 비용도 전반적으로 낮게 유지할 수 있습니다.
DynamoDB의 관계형 데이터를 모델링하고 프런트엔드 애플리케이션의 새 버전을 구축하는 작업은 별도의 주제입니다. 이 안내서에서는 DynamoDB를 사용하도록 새 버전의 애플리케이션을 구축했다고 가정하지만, 전환 중에 기록 데이터를 마이그레이션하고 동기화하는 최선의 방법을 결정해야 합니다.
크기 조정 고려 사항
DynamoDB 테이블에 저장하는 각 항목(행)의 최대 크기는 400KB입니다. 자세한 내용은 Amazon DynamoDB의 서비스, 계정 및 테이블 할당량 단원을 참조하십시오. 항목 크기는 항목에 있는 모든 속성 이름 및 속성 값의 총 크기에 따라 결정됩니다. 자세한 내용은 DynamoDB 항목 크기 및 형식 단원을 참조하십시오.
애플리케이션이 DynamoDB 크기 제한이 허용하는 것보다 많은 데이터를 항목에 저장해야 하는 경우, 항목을 항목 모음으로 나누거나, 항목 데이터를 압축하거나, Amazon Simple Storage Service(S3)에 항목을 객체로 저장하는 동시에 DynamoDB 항목에 Amazon S3 객체 식별자를 저장합니다. 큰 항목과 속성 저장 모범 사례 섹션을 참조하세요. 항목 업데이트 비용은 항목의 전체 크기를 기준으로 합니다. 기존 항목을 자주 업데이트해야 하는 워크로드의 경우 1~2KB의 작은 항목이 있으면 큰 항목보다 업데이트 비용이 적게 듭니다. 항목 모음에 대한 자세한 내용은 항목 컬렉션 - DynamoDB에서 일대다 관계를 모델링하는 방법 섹션을 참조하세요.
파티션 및 정렬 키 속성, 기타 테이블 설정, 항목 크기 및 구조, 보조 인덱스 생성 여부를 선택할 때는 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로 가져오기 기능
DynamoDB로 마이그레이션하는 데 도움이 되는 도구
데이터를 DynamoDB로 마이그레이션하는 데 사용할 수 있는 몇 가지 일반적인 마이그레이션 및 ETL 도구가 있습니다.
많은 고객이 마이그레이션 프로세스를 위한 사용자 지정 데이터 변환을 구축하기 위해 자체 마이그레이션 스크립트와 작업을 작성합니다. 쓰기 트래픽이 많거나 정기적인 대량 로드 작업이 있는 대용량 DynamoDB 테이블을 운영하려는 경우 쓰기 트래픽이 많을 때 DynamoDB의 동작을 신뢰할 수 있도록 마이그레이션 도구를 직접 구축하는 것이 좋습니다. 마이그레이션을 연습할 때 제한 처리 및 효율적인 테이블 프로비저닝과 같은 시나리오를 프로젝트 초기에 경험할 수 있습니다.
Amazon은 AWS Database Migration Service(DMS), AWS Glue, Amazon EMR, Amazon Managed Streaming for Apache Kafka 등 활용할 수 있는 다양한 데이터 도구를 제공합니다. 이러한 도구를 모두 사용하여 가동 중지 시간 마이그레이션을 수행할 수 있으며, 관계형 데이터베이스 변경 데이터 캡처(CDC) 기능을 활용할 수 있는 특정 도구는 온라인 마이그레이션도 지원할 수 있습니다. 최상의 도구를 선택할 때는 각 도구의 기능, 성능 및 비용과 함께 조직이 각 도구에 대해 보유하고 있는 기술 역량 및 경험을 고려하는 것이 도움이 됩니다.
DynamoDB로 마이그레이션하기 위한 적절한 전략 선택
대규모 관계형 데이터베이스 애플리케이션은 테이블이 100개 이상일 수 있으며 다양한 애플리케이션 함수를 지원할 수 있습니다. 대규모 마이그레이션을 진행할 때는 애플리케이션을 더 작은 구성 요소나 마이크로서비스로 나누고 한 번에 작은 테이블 집합을 마이그레이션하는 것을 고려해 보세요. 그런 다음 추가 구성 요소를 DynamoDB로 여러 차례에 걸쳐 마이그레이션할 수 있습니다.
마이그레이션 전략을 선택할 때 특정 파라미터에 따라 솔루션을 선택하게 될 수 있습니다. 요구 사항과 사용 가능한 리소스를 고려하여 사용 가능한 옵션을 단순화하기 위해 의사 결정 트리로 이러한 옵션을 시각화할 수 있습니다. 개념은 여기에 간략하게 설명되어 있습니다(이 안내서의 뒷부분에서 더 자세히 다룰 예정).
-
오프라인 마이그레이션: 마이그레이션 중에 애플리케이션이 가동 중지 시간을 어느 정도 감수할 수 있다면 오프라인 마이그레이션은 마이그레이션 프로세스를 크게 단순화합니다.
-
하이브리드 마이그레이션: 이 접근 방식을 사용하면 마이그레이션 중에 부분적인 가동 시간을 허용할 수 있습니다. 예를 들어 읽기는 허용하지만 쓰기는 허용하지 않거나, 읽기 및 삽입은 허용하지만 업데이트 및 삭제는 허용하지 않습니다.
-
온라인 마이그레이션: 마이그레이션 중에 가동 중지 시간이 전혀 없어야 하는 애플리케이션은 마이그레이션하기가 상대적으로 쉽지 않으며 상당한 계획과 맞춤형 개발이 필요할 수 있습니다. 결정해야 하는 한 가지 중요한 사항은 사용자 지정 마이그레이션 프로세스를 구축하는 데 드는 비용과 전환 중에 가동 중지 시간이 발생하는 데 드는 비즈니스 비용을 추정하여 평가하는 것입니다.
| If | And | Then | ||||
|---|---|---|---|---|---|---|
| 데이터 마이그레이션을 수행하기 위해 유지 관리 기간 동안 애플리케이션을 잠시 중단해도 괜찮습니다. 이 방식은 오프라인 마이그레이션입니다. |
AWS DMS를 사용하고 전체 로드 작업을 사용하여 오프라인 마이그레이션을 수행합니다. 원하는 경우 SQL |
|||||
| 마이그레이션 중에 애플리케이션을 읽기 전용 모드로 실행해도 됩니다. 이 방식은 하이브리드 마이그레이션입니다. | 애플리케이션 또는 소스 데이터베이스 내에서 쓰기를 비활성화합니다. AWS DMS를 사용하고 전체 로드 작업을 사용하여 오프라인 마이그레이션을 수행합니다. | |||||
| 마이그레이션 중에 읽기 및 새 레코드 삽입을 허용한 상태로 애플리케이션을 실행해도 괜찮습니다. 단, 업데이트나 삭제는 허용하지 않습니다. 이 방식은 하이브리드 마이그레이션입니다. | 애플리케이션 개발 기술 역량을 보유하고 있으며 모든 새 레코드에 대해 DynamoDB를 포함하여 이중 쓰기를 수행하도록 기존 관계형 앱을 업데이트할 수 있습니다. | AWS DMS를 사용하고 전체 로드 작업을 사용하여 오프라인 마이그레이션을 수행합니다. 동시에, 읽기를 허용하고 이중 쓰기를 수행하는 기존 앱 버전을 배포합니다. | ||||
| 가동 중지 시간을 최소화하면서 마이그레이션해야 합니다. 이 방식은 온라인 마이그레이션입니다. | 주요 스키마 변경 없이 소스 테이블을 DynamoDB로 일대일로 마이그레이션하고 있습니다. | AWS DMS를 사용하여 온라인 데이터 마이그레이션을 수행합니다. 대량 로드 작업을 실행한 다음 CDC 동기화 작업을 실행합니다. | ||||
| 단일 테이블 철학에 따라 소스 테이블을 더 적은 수의 DynamoDB 테이블로 결합하고 있습니다. | 백엔드 데이터베이스 개발 기술 역량이 있으며 SQL 호스트에 예비 용량이 있습니다. | SQL 데이터베이스 내에 NoSQL 지원 테이블을 생성합니다. JOIN, UNION, VIEW, 트리거, 저장 프로시저를 사용하여 테이블을 채우고 동기화합니다. | ||||
| 백엔드 데이터베이스 개발 기술 역량이 없으며 SQL 호스트에 예비 용량이 없습니다. | 하이브리드 또는 오프라인 마이그레이션 접근 방식을 고려해 보세요. | |||||
| 이전 트랜잭션 데이터를 마이그레이션하지 않아도 되거나 마이그레이션하는 대신 Amazon S3에 아카이브할 수 있습니다. 몇 개의 작은 정적 테이블만 마이그레이션하면 됩니다. | 스크립트를 작성하거나 ETL 도구를 사용하여 테이블을 마이그레이션합니다. 원하는 경우 SQL VIEW를 사용하여 소스 데이터를 미리 구성합니다. |
|||||
DynamoDB로 오프라인 마이그레이션 수행
오프라인 마이그레이션은 마이그레이션을 수행할 때 가동 중지 시간을 허용할 수 있는 경우에 적합합니다. 관계형 데이터베이스는 일반적으로 유지 관리 및 패치 적용으로 인해 매달 최소 어느 정도의 가동 중지 시간이 발생하며 하드웨어 업그레이드 또는 메이저 릴리스 업그레이드의 경우 가동 중지 시간이 더 길어질 수 있습니다.
Amazon S3는 마이그레이션 중에 스테이징 영역으로 사용할 수 있습니다. S3에서 DynamoDB로 가져오기 기능을 사용하여 쉼표로 구분된 값(CSV) 또는 DynamoDB JSON 형식으로 저장된 데이터를 새 DynamoDB 테이블로 자동으로 가져올 수 있습니다.
계획
Amazon S3를 사용하여 오프라인 마이그레이션 수행
도구
-
SQL 데이터를 추출 및 변환하여 다음과 같은 S3 버킷에 저장하는 ETL 작업:
-
AWS Glue
-
Amazon EMR
-
자체 사용자 지정 코드
-
-
S3에서 DynamoDB로 가져오기 기능
오프라인 마이그레이션 단계:
-
SQL 데이터베이스를 쿼리하고, 테이블 데이터를 DynamoDB JSON 또는 CSV 형식으로 변환하고, S3 버킷에 저장할 수 있는 ETL 작업을 빌드합니다.
-
S3에서 DynamoDB로 가져오기 기능이 간접 호출되어 새 테이블을 생성하고 S3 버킷에서 데이터를 자동으로 로드합니다.
완전 오프라인 마이그레이션은 단순하고 간단하지만 애플리케이션 소유자와 사용자에게는 인기가 없을 수 있습니다. 마이그레이션 중에 애플리케이션이 서비스를 전혀 제공하지 않는 대신 축소된 서비스를 제공할 수 있다면 사용자에게 도움이 될 것입니다.
오프라인 마이그레이션 중에 쓰기를 비활성화하는 기능을 추가하고 읽기는 정상적으로 계속되도록 할 수 있습니다. 관계형 데이터를 마이그레이션하는 동안에도 애플리케이션 사용자는 기존 데이터를 안전하게 찾아보고 쿼리할 수 있습니다. 이 내용을 찾고 있었다면 계속 읽으면서 하이브리드 마이그레이션에 대해 알아보세요.
DynamoDB로 하이브리드 마이그레이션 수행
모든 데이터베이스 애플리케이션이 읽기 및 쓰기 작업을 수행하지만 하이브리드 또는 온라인 마이그레이션을 계획할 때는 수행 중인 쓰기 작업 유형을 고려해야 합니다. 데이터베이스 쓰기는 삽입, 업데이트 및 삭제의 세 가지로 분류할 수 있습니다. 어떤 애플리케이션은 기존 레코드를 전혀 업데이트하지 않습니다. 삭제를 즉시 처리하지 않아도 되는 애플리케이션도 있고, 월말에 일괄 정리 프로세스를 수행하는 방식으로 삭제를 연기할 수 있습니다. 이러한 유형의 애플리케이션은 부분적인 가동 시간을 허용하면서 더 간단하게 마이그레이션할 수 있습니다.
계획
애플리케이션 이중 쓰기를 허용하면서 하이브리드 온라인/오프라인 마이그레이션 수행
도구
-
SQL 데이터를 추출 및 변환하여 다음과 같은 S3 버킷에 저장하는 ETL 작업:
-
AWS Glue
-
Amazon EMR
-
자체 사용자 지정 코드
-
하이브리드 마이그레이션 단계:
-
대상 DynamoDB 테이블을 생성합니다. 이 테이블은 과거 대량 데이터와 새로운 라이브 데이터를 모두 수신합니다.
-
SQL 데이터베이스와 DynamoDB 모두에 대해 모든 삽입을 이중 쓰기로 수행하면서 삭제 및 업데이트가 비활성화된 레거시 애플리케이션 버전을 생성합니다.
-
ETL 작업을 시작하여 기존 데이터를 마이그레이션하는 동시에 새 애플리케이션 버전을 배포합니다.
-
ETL 작업이 완료되면 DynamoDB는 기존 및 새 레코드를 모두 보유하고 애플리케이션 전환을 수행할 준비가 됩니다.
참고
ETL 작업은 SQL에서 DynamoDB로 직접 씁니다. 전체 가져오기가 완료될 때까지 대상 테이블이 퍼블릭 상태가 되지 않고 다른 쓰기에 사용할 수 없으므로 오프라인 마이그레이션 예시에서처럼 S3 가져오기 기능을 사용할 수 없습니다.
각 테이블을 일대일로 마이그레이션하여 DynamoDB로 온라인 마이그레이션 수행
많은 관계형 데이터베이스에는 변경 데이터 캡처(CDC)라는 기능이 있습니다. 이 기능을 사용하면 사용자가 데이터베이스에서 특정 시점 전 또는 후에 발생한 테이블 변경 사항 목록을 요청할 수 있습니다. CDC는 내부 로그를 사용하여 이 기능을 활성화하며 테이블에 타임스탬프 열이 없어도 작동합니다.
SQL 테이블의 스키마를 NoSQL 데이터베이스로 마이그레이션할 때 데이터를 결합하여 더 적은 수의 테이블로 재구성해야 할 수 있습니다. 이렇게 하면 한 곳에서 데이터를 수집할 수 있고 여러 단계의 읽기 작업에서 관련 데이터를 수동으로 조인하지 않아도 됩니다. 하지만 단일 테이블 데이터 구성이 항상 필요한 것은 아니며 테이블을 일대일로 DynamoDB로 마이그레이션하는 경우도 있습니다. 이러한 일대일 테이블 마이그레이션은 이러한 유형의 마이그레이션을 지원하는 일반 ETL 도구를 사용하여 소스 데이터베이스 CDC 기능을 활용할 수 있으므로 덜 복잡합니다. 각 행의 데이터는 여전히 새 형식으로 변환될 수 있지만 각 테이블의 범위는 변하지 않습니다.
서버 측 조인이 없다는 점을 염두에 두고 SQL 테이블을 DynamoDB로 일대일로 마이그레이션하는 것을 고려해 보세요.
계획
AWS DMS를 사용하여 각 테이블을 DynamoDB로 온라인 마이그레이션 수행
도구
-
AWS Database Migration Service(DMS), 과거 데이터를 대량으로 로드하고 CDC를 활용하여 소스 테이블과 대상 테이블을 동기화할 수 있는 ETL 도구
온라인 마이그레이션 단계:
-
소스 스키마에서 마이그레이션할 테이블을 식별합니다.
-
DynamoDB에 키 구조가 비슷한 동일한 수의 테이블을 생성합니다.
-
AWS DMS에서 복제 서버를 생성하고 소스 및 대상 엔드포인트를 구성합니다.
-
필요한 행별 변환(예: 열을 연결하거나 날짜를 ISO-8601 문자열 형식으로 변환)을 정의합니다.
-
전체 로드 및 변경 데이터 캡처를 위해 각 테이블에 대해 마이그레이션 작업을 생성합니다.
-
진행 중인 복제 단계가 시작될 때까지 이러한 작업을 모니터링합니다.
-
이 시점에서 검증 감사를 수행한 다음 사용자를 DynamoDB에 읽고 쓰는 애플리케이션으로 전환할 수 있습니다.
사용자 지정 스테이징 테이블을 사용하여 DynamoDB로 온라인 마이그레이션 수행
고유한 NoSQL 액세스 패턴을 활용하기 위해 테이블을 결합할 수 있습니다(예: 4개의 레거시 테이블을 단일 DynamoDB 테이블로 변환). 단일 키-값 문서 요청 또는 사전 그룹화된 항목 모음에 대한 쿼리는 일반적으로 다중 테이블 조인을 수행하는 SQL 데이터베이스보다 지연 시간이 더 짧습니다. 하지만 이로 인해 마이그레이션 작업이 더 어려워집니다. SQL VIEW는 소스 데이터베이스 내에서 작업을 수행하여 테이블 4개 모두를 하나의 집합으로 나타내는 단일 데이터세트를 준비할 수 있습니다.
이 뷰는 테이블을 비정규화된 형태로 JOIN할 수도 있고, 엔터티를 정규화한 상태로 유지하고 SQL UNION을 사용하여 테이블을 스태킹할 수도 있습니다. 관계형 데이터 재구성과 관련된 주요 결정 사항은 이 동영상
하지만 변경되는 라이브 데이터가 포함된 온라인 마이그레이션의 경우 CDC 기능은 단일 테이블 쿼리에만 지원되고 VIEW 내부에서는 지원되지 않으므로 CDC 기능을 활용할 수 없습니다. 테이블에 마지막으로 업데이트된 타임스탬프 열이 포함되어 있고 이 열이 VIEW에 통합되어 있는 경우 이를 사용하여 동기화를 통해 대량 로드를 처리하는 사용자 지정 ETL 작업을 만들 수 있습니다.
이 문제에 대한 새로운 접근 방식은 뷰, 저장 프로시저, 트리거와 같은 표준 SQL 기능을 사용하여 최종적으로 원하는 DynamoDB NoSQL 형식의 새 SQL 테이블을 생성하는 것입니다.
데이터베이스 서버에서 스토리지 공간을 추가로 할당할 수 있는 경우 마이그레이션을 시작하기 전에 이 단일 스테이징 테이블을 생성할 수 있습니다. 이를 위해서는 기존 테이블에서 읽고, 필요에 따라 데이터를 변환하고, 새 스테이징 테이블에 쓰는 저장 프로시저를 작성하면 됩니다. 일련의 트리거를 추가하여 테이블의 변경 사항을 스테이징 테이블에 실시간으로 복제할 수 있습니다. 회사 정책에 따라 트리거가 허용되지 않는 경우 저장 프로시저를 변경해도 동일한 결과를 얻을 수 있습니다. 데이터를 쓰는 프로시저에 몇 줄의 코드를 추가하여 동일한 변경 내용을 스테이징 테이블에 추가로 쓸 수 있습니다.
이 스테이징 테이블을 레거시 애플리케이션 테이블과 완전히 동기화하면 실시간 마이그레이션의 훌륭한 출발점이 됩니다. 이제 데이터베이스 CDC를 사용하여 라이브 마이그레이션을 수행하는 도구(예: AWS DMS)를 이 테이블에 사용할 수 있습니다. 이 접근 방식의 장점은 관계형 데이터베이스 엔진에서 사용할 수 있는 잘 알려진 SQL 기술 역량과 기능을 사용한다는 것입니다.
계획
AWS DMS를 사용하여 SQL 스테이징 테이블을 활용하여 온라인 마이그레이션 수행
도구
-
사용자 지정 SQL 저장 프로시저 또는 트리거
-
AWS Database Migration Service(DMS), 라이브 스테이징 테이블을 DynamoDB로 마이그레이션할 수 있는 ETL 도구
온라인 마이그레이션 단계:
-
소스 관계형 데이터베이스 엔진 내에 추가 디스크 공간과 처리 용량이 있는지 확인합니다.
-
타임스탬프 또는 CDC 기능을 활성화하여 SQL 데이터베이스에 새 스테이징 테이블을 생성합니다.
-
저장 프로시저를 작성하고 실행하여 기존 관계형 테이블 데이터를 스테이징 테이블에 복사합니다.
-
트리거를 배포하거나 기존 프로시저를 수정하여 기존 테이블에 일반 쓰기를 수행하면서 새 스테이징 테이블에 이중 쓰기를 수행합니다.
-
AWS DMS를 실행하여 이 소스 테이블을 대상 DynamoDB 테이블로 마이그레이션하고 동기화합니다.
이 안내서에서는 가동 중지 시간을 최소화하고 일반적인 데이터베이스 도구 및 기법을 사용하는 데 중점을 두고 관계형 데이터베이스 데이터를 DynamoDB로 마이그레이션하기 위한 몇 가지 고려 사항과 접근 방식을 제시했습니다. 자세한 내용은 다음 자료를 참조하십시오.
