AWS DMS非対応環境における実践的アプローチ

ネットワーク制約下でのデータ移行の現実と課題

ガバナンス要件がもたらす技術的制約の本質

大規模エンタープライズにおけるデータベース移行プロジェクトでは、技術的な課題以上に組織のガバナンス要件が大きな制約となることがあります。

私が直近の開発事例で直面したケースでは、オンプレミスのOracle Exadata 19cおよびOCI上のOracleデータベースから、Amazon DynamoDBへ約700GB〜1TB規模のデータを移行する必要がありました。

通常であれば「AWS DMS」を利用することで、ソースデータベースからターゲットへのフルロード＋継続的な変更同期（CDC: Change Data Capture）により、ダウンタイムを最小化した移行が実現できます。しかし、顧客のセキュリティポリシーにより、システムインテグレーターが顧客LANに接続することが禁止されており、AWS側から直接Oracleに接続するレプリケーションインスタンスやDirect Connect経由のネットワーク経路の使用が許可されませんでした。

この制約は単なる技術的な問題ではなく、データガバナンスとコンプライアンスに関わる本質的な課題です。多くの金融機関や政府系機関では、外部ベンダーによる内部ネットワークへのアクセスを厳格に制限しており、たとえ専用線接続であっても例外を認めないケースが増えています。

DMSが対応できないスキーマ変換の複雑性

AWS DMSのもう一つの制約として、リレーショナルからNoSQLへの本格的なスキーマ変換に対応していない点が挙げられます。DMSをDynamoDBのターゲットとして使用する場合、デフォルトではソースDBと同じ数のテーブルをDynamoDB上に作成し、各テーブルの行をそのまま項目（Item）の属性にマッピングする1対1移行になります。

しかし、NoSQLへの移行で真の価値を生み出すには、データモデル自体をリレーショナルからNoSQL向けに根本的に再設計する必要があります。今回のケースでは、500あったテーブルを「ファセット設計」により数個のテーブルに統合し、アクセスパターンに最適化した非正規化データ構造への変換を計画していました。このような抜本的なスキーマ変換は、DMSの自動変換機能では対応できず、カスタム開発が必須となります。

AWS エコシステムを活用した代替移行戦略

AWS Glueによる柔軟なETLパイプラインの構築

ネットワーク制約下でも実現可能な移行手法として、まず検討すべきは「AWS Glue」を活用したETLパイプラインの構築です。Glueはフルマネージドのサーバーレス「ETLサービス」であり、大規模データ処理に必要なインフラストラクチャの管理から解放されます。

Glueの最大の利点は、PySparkやSparkによる分散処理により、テラバイト級のデータでも効率的に処理できる点です。Oracle側でエクスポートしたデータファイルをS3に配置し、GlueジョブでこれらのファイルをDynamoDB向けの構造に変換して書き込む、というフローが構築できます。

実際のプロジェクトでは、以下のような処理パターンを実装しました。Oracleの複数テーブルをJOINして非正規化したビューを作成し、そのビュー結果をCSVエクスポート。S3上のCSVファイルをGlueのDynamic Frameで読み込み、必要な変換処理を適用後、glueContext.write_dynamic_frameメソッドでDynamoDBに直接書き込むというパイプラインです。

Amazon DynamoDB S3インポート機能による大規模データの一括取り込み

2024年以降、Amazon DynamoDBは「S3からのデータインポート」機能を大幅に拡張しており、テラバイト級のデータでも効率的にインポートできるようになりました。この機能は、あらかじめS3に配置したCSVまたはDynamoDB JSON形式のファイルから、新規テーブルを自動作成してデータを一括取り込みます。

インポート処理の特徴として、専用のバックグラウンドプロセスで実行されるため、通常のWrite Capacity Unitを消費しません。これにより、大量データの初期ロードにかかるコストを大幅に削減できます。1TBのデータでも数時間で取り込みが完了し、インポート中のスロットリングやエラー処理も自動的に管理されます。

ただし、この機能には制約もあります。既存テーブルへのマージはサポートされておらず、新規テーブル作成のみが可能です。また、インポート中はテーブルがアクティブでないため、完全なオフライン移行を前提とする必要があります。

AWS Snowball Edgeによる物理的なデータ転送戦略

ネットワーク経由でのデータ転送が完全に禁止されている環境では、「AWS Snowball Edge」デバイスによる物理的なデータ転送が有効な選択肢となります。Snowball Edgeは最大100TB級のデータを扱える堅牢なストレージデバイスで、AES-256暗号化により輸送中のセキュリティも確保されます。

実際の移行プロセスでは、顧客環境でOracleデータをSnowballデバイスにエクスポートし、デバイスをAWSデータセンターに物理的に返送します。AWS側でデータが自動的にS3バケットに転送され、その後DynamoDBへのインポート処理を実行します。1TBのデータであれば、物理転送を含めても数日で完了できるため、週末のメンテナンスウィンドウで十分対応可能です。

この手法の利点は、顧客ネットワークへの一切の接続を必要としない点です。データ提供という形で顧客から受領する形になるため、ガバナンス上も問題になりにくく、多くの規制産業で採用されています。

データモデル変換における設計上の考慮点

アクセスパターン主導型設計への転換

リレーショナルDBからNoSQLへの移行で最も重要なのは、データモデル設計の根本的な思考転換です。Oracleでは正規化されたテーブル構造でデータの整合性を保証しますが、DynamoDBでは「アクセスパターン」を中心に据えた非正規化設計が求められます。

移行プロジェクトの初期段階で実施すべきは、既存アプリケーションのクエリパターンの徹底的な分析です。どのようなSELECT文が頻繁に実行されているか、JOINの組み合わせパターンは何か、更新系処理の特性はどうかなど、実際のワークロードを詳細に調査します。

AWS Well-Architected Frameworkのベストプラクティスでは、DynamoDBのテーブル設計において「単一テーブル設計」が推奨されています。これは、関連するすべてのエンティティを1つのテーブルに格納し、Partition KeyとSort Keyの組み合わせでデータを整理する手法です。

単一テーブル設計の実装パターンと課題

単一テーブル設計を採用する際の実装パターンとして、以下のようなキー構成を検討しました。

表 DynamoDB単一テーブル設計のキー構成例

この設計により、顧客に関連するすべての情報を単一のQueryで取得でき、アプリケーション側でのJOIN処理が不要になります。ただし、複雑なクロス集計や全文検索が必要な場合は、DynamoDB単体では対応が困難なため、ElasticsearchやAmazon Athenaとの併用も検討する必要があります。

AWS Schema Conversion Toolによる移行難易度の評価

AWS Schema Conversion Tool（SCT）の2024年アップデートにより、OracleからDynamoDBへのスキーマ変換評価がより精緻になりました。SCTは既存のOracleスキーマを分析し、DynamoDB向けの変換可能性をパーセンテージで示すレポートを生成します。

SCTの評価レポートでは、自動変換可能な要素、手動変換が必要な要素、変換不可能な要素が明確に分類されます。特にストアドプロシージャやトリガーなどのデータベース側ロジックは、アプリケーション層への移植が必要となるため、開発工数の見積もりに重要な情報となります。

実際のプロジェクトでは、SCTの評価結果を基に、段階的な移行計画を策定しました。まず変換難易度の低いマスタテーブル群から着手し、トランザクション系のテーブルは最後に移行するという戦略を採用しました。

ダウンタイム戦略と移行パターンの選択

オフライン移行：シンプルかつ確実な選択

ダウンタイムを許容できる場合、オフライン移行は最もシンプルで確実な選択肢となります。週末や深夜のメンテナンスウィンドウを活用し、アプリケーションを完全停止した状態で一括データ移行を実施します。

オフライン移行の利点は、データ整合性の担保が容易であることです。移行中にデータ変更が発生しないため、差分同期の複雑な仕組みが不要となります。1TB程度のデータであれば、適切に最適化されたインポートプロセスで数時間での移行が可能です。

ただし、ビジネス要件として24/7稼働が求められる場合は、オフライン移行は選択できません。その場合は、次に述べるハイブリッド移行やオンライン移行を検討する必要があります。

ハイブリッド移行：ビジネス影響を最小化する中間解

ハイブリッド移行は、部分的にサービスを継続しながら移行を実施する戦略です。典型的なパターンとして「読み取り専用モード」での移行があります。移行期間中、ユーザーはデータの参照は可能ですが、更新・削除操作は一時的に制限されます。

実装パターンとして効果的なのは、アプリケーション層での「デュアルライト」戦略です。新規データの書き込みはOracleとDynamoDBの両方に行い、読み取りは段階的にDynamoDBに切り替えていきます。この手法により、ロールバック可能性を保ちながら、段階的な移行が実現できます。

2024年のAWSアップデートでは、DynamoDB Global Tablesの整合性モデルが強化され、マルチリージョンでのデュアルライト戦略がより実装しやすくなりました。これにより、地理的に分散したシステムでも、データ整合性を保ちながらハイブリッド移行が可能となっています。

カスタムCDCソリューションによるオンライン移行

完全なゼロダウンタイム移行を実現するには、カスタムのChange Data Capture（CDC）ソリューションの構築が必要です。Oracle側でGoldenGateやDebeziumなどのCDCツールを使用し、変更データをリアルタイムでキャプチャし、Amazon KinesisやKafka経由でDynamoDBに反映する仕組みを構築します。

実際のプロジェクトでは、以下のようなアーキテクチャを採用しました。

1. Oracle側でトリガーベースの変更履歴テーブルを作成
2. 定期的なバッチジョブで変更データを抽出しS3に配置
3. Lambda関数でS3イベントをトリガーに変更データを処理
4. DynamoDB Streamsで最終的な整合性を確認

この方式により、移行期間中もシステムは完全に稼働を継続でき、ビジネスへの影響を最小限に抑えることができました。

セキュリティとコンプライアンスの実装

エンドツーエンドの暗号化戦略

データ移行において最も重要なセキュリティ要件は、エンドツーエンドでの暗号化です。Oracle Exadataの「Transparent Data Encryption（TDE）」から、転送中の暗号化、そしてDynamoDBでの保存時暗号化まで、一貫した暗号化チェーンを維持する必要があります。

転送経路における暗号化では、以下の対策を実装しました。エクスポートファイルは「GPG暗号化」を適用し、S3への転送はSSL/TLSプロトコルを使用。S3バケットでは「SSE-KMS」による暗号化を有効化し、アクセスログもCloudTrailで完全に記録します。

DynamoDBは2018年以降、すべてのテーブルでデフォルト暗号化が有効となっており、AWS管理のCMKによる透過的な暗号化が適用されます。必要に応じて、顧客管理のKMSキーを使用することも可能で、より厳格なキー管理要件にも対応できます。

IAMによる最小権限の原則の徹底

移行作業における権限管理では、「最小権限の原則」を徹底的に適用しました。移行専用のIAMロールを作成し、必要最小限のアクションのみを許可するポリシーを定義します。

以下のような段階的な権限管理を実装しました。

表 移行フェーズ別のIAM権限設定

各フェーズ終了後は速やかに権限を剥奪し、不要なアクセス権限が残存しないよう管理しました。

監査ログとコンプライアンス証跡の確保

規制産業向けのプロジェクトでは、すべての移行作業の監査証跡を残すことが必須要件となります。AWS CloudTrailによるAPIコールの記録に加え、カスタムのアプリケーションログも統合的に管理しました。

Amazon CloudWatch Logsの2024年アップデートにより、ログの長期保管とコスト最適化がより柔軟になりました。移行作業のログは最低7年間保管する要件があったため、ログのライフサイクル管理ポリシーを適切に設定し、古いログは自動的にGlacierにアーカイブする仕組みを構築しました。

コンプライアンス対応として、DynamoDBはPCI DSS、HIPAA、ISO27001など主要な認証を取得しており、金融・医療分野での利用にも対応しています。移行後は定期的な脆弱性スキャンとペネトレーションテストを実施し、セキュリティ態勢の継続的な改善を図っています。

移行プロジェクトから得られた実践的な教訓

技術選択における本質的な価値の見極め

AWS DMSが使えないという制約は、一見すると大きな障害に思えました。しかし、この制約により、より柔軟で拡張可能な移行アーキテクチャを設計する機会を得ることができました。DMSによる自動移行に頼らず、カスタムETLパイプラインを構築したことで、複雑なデータ変換ロジックを柔軟に実装でき、将来的な要件変更にも対応しやすい基盤を構築できました。

特に重要だったのは、「移行」を単なるデータのコピーではなく、データモデルの最適化とアーキテクチャの近代化の機会として捉えたことです。500テーブルから数テーブルへの統合により、アプリケーションの複雑性が大幅に削減され、運用コストも劇的に改善されました。

ステークホルダー管理の重要性

技術的な課題以上に重要だったのは、ステークホルダーとのコミュニケーションでした。ガバナンス部門、セキュリティ部門、ビジネス部門それぞれの要件を理解し、バランスの取れた解決策を提案する必要がありました。

特に効果的だったのは、段階的な移行計画の策定と、各段階での成功基準の明確化です。小規模なPoCから始め、段階的にスケールアップしていくアプローチにより、リスクを最小化しながら着実に移行を進めることができました。

今後のクラウド移行プロジェクトへの示唆

このプロジェクトから得られた最も重要な教訓は、制約は創造性を生み出す源泉になるということです。AWS DMSのような便利なツールが使えない環境でも、AWSエコシステムの他のサービスを組み合わせることで、より柔軟で強力なソリューションを構築できることを実証しました。

2025年のAWS re:Inventで発表された新機能では、DynamoDBのマルチリージョンレプリケーション機能がさらに強化され、グローバルスケールでのデータ移行がより容易になっています。今後のプロジェクトでは、これらの新機能を活用しながら、本記事で紹介した基本的なアプローチを応用することで、さらに効率的な移行が実現できるでしょう。

データベース移行は単なる技術的な作業ではなく、ビジネス変革の重要な要素です。適切な戦略と実装により、レガシーシステムの制約から解放され、真のデジタルトランスフォーメーションを実現することができます。本記事が、同様の課題に直面している方々の参考になれば幸いです。