Google Cloud には、Amazon Simple Storage Service（Amazon S3）から Cloud Storage へのデータの移行に役立つツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。このドキュメントでは、Amazon S3 から Cloud Storage への移行計画を設計、実施、検証する方法について説明します。このドキュメントには、Amazon S3 アーティファクトのインベントリを作成し、移行プロセスの対応方法の計画を作成する、移行プロセス全体の一部について説明します。
このドキュメントの説明は、移行プロセスを計画して実施する方法を詳しく知りたいクラウド管理者を対象としています。また、移行の機会を評価し、移行がどのように行われるかを調査する意思決定者も対象としています。
このドキュメントは、AWS からGoogle Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。
- 始めましょう
- Amazon EC2 から Compute Engine への移行
- Amazon S3 から Cloud Storage への移行（本ドキュメント）
- Amazon EKS から Google Kubernetes Engine への移行
- Amazon RDS for MySQL および Amazon Aurora for MySQL から Cloud SQL for MySQL への移行
- Amazon RDS for PostgreSQL と Amazon Aurora for PostgreSQL から Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL への移行
- Amazon RDS for SQL Server から Cloud SQL for SQL Server への移行
- AWS Lambda から Cloud Run に移行する
Google Cloudに移行する場合は、 Google Cloudへの移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。
- ワークロードとデータを評価して検出します。
- Google Cloudで基盤を計画し、構築します。
- ワークロードとデータを Google Cloudに移行します。
- Google Cloud 環境を最適化する。
このフレームワークのフェーズの詳細については、 Google Cloudへの移行: スタートガイドをご覧ください。
効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、 Google Cloudへの移行: 移行計画の検証に関するベスト プラクティスをご覧ください。
移行元の環境を評価する
評価フェーズでは、移行元の環境を Google Cloudに移行するための要件と依存関係を確認します。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、 Google Cloudへの移行を計画して実施するための出発点も理解する必要があります。
評価フェーズは、次のタスクで構成されます。
- ワークロードの包括的なインベントリを作成する。
- プロパティと依存関係に応じてアプリケーションを分類する。
- チームを Google Cloudでトレーニングして教育する。
- Google Cloudでテストと概念実証を構築する。
- ターゲット環境の総所有コスト（TCO）を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
評価フェーズとこれらのタスクの詳細については、 Google Cloudへの移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。
Amazon S3 バケットのインベントリを構築する
移行の対象範囲を設定するには、Amazon S3 バケットのインベントリと、バケットに保存されているオブジェクトのインベントリの 2 つのインベントリを構築します。
Amazon S3 バケットのインベントリを構築したら、各 Amazon S3 バケットに関する次のデータポイントを検討してインベントリを絞り込みます。
- Amazon S3 バケットのサーバーサイド暗号化をどのように構成したか
- Amazon S3 バケットの Identity and Access Management の設定
- S3 ブロック公開アクセスの構成
- Amazon S3 バケット用の任意の費用割り当てタグ
- S3 オブジェクト ロックの構成
- Amazon S3 バケットへのアクセス方法
- リクエスト元による支払いの構成方法
- Amazon S3 オブジェクトのバージョニングの設定
- Amazon S3 の AWS Backup ポリシーの構成
- Amazon S3 Intelligent-Tiering を使用しているかどうか
- Amazon S3 オブジェクトのレプリケーション用の構成方法。
- Amazon S3 オブジェクトのライフサイクル。
また、各バケットに含まれるオブジェクトに関する集計統計を計算することができる、Amazon S3 バケットに関するデータを収集することをおすすめします。たとえば、オブジェクトの合計サイズ、平均オブジェクト サイズ、オブジェクト カウントを収集すると、Amazon S3 バケットから Cloud Storage バケットへの移行に必要な時間と費用を見積もるのに役立ちます。
Amazon S3 バケットのインベントリを構築し、Amazon S3 バケットに関するデータポイントを収集するには、次のような AWS ツールに依存するデータ収集メカニズムとプロセスを実装します。
- Amazon S3 モニタリング ツール
- S3 分析
- AWS マルチアカウント マルチリージョン データ集計
- AWS API
- AWS デベロッパー ツール
- AWS コマンドライン インターフェース
移行中の問題を回避し、移行に必要な労力を見積もるために、Amazon S3 のバケット機能と類似した Cloud Storage のバケット機能のマッピングを評価することをおすすめします。次の表に、このマッピングの概要を示します。
前述のように、これらを比較すると、上記の表に示す機能は次のようになります。ただし、2 つのクラウド プロバイダで機能の設計と実装が異なると、Amazon S3 から Cloud Storage への移行に大きな影響を与える可能性があります。
Amazon S3 オブジェクトに保存されているオブジェクトのインベントリを構築する
Amazon S3 バケットのインベントリを構築した後は、Amazon S3 インベントリ ツールを使用して、これらのバケットに格納されているオブジェクトのインベントリを構築することをおすすめします。
Amazon S3 オブジェクトのインベントリを構築するには、オブジェクトごとに次の点を考慮してください。
- Amazon S3 オブジェクトの名前
- Amazon S3 オブジェクトのサイズ
- Amazon S3 オブジェクトのメタデータ
- Amazon S3 オブジェクトのサブリソース
- Amazon S3 オブジェクトのバージョン、それらのバージョンを移行する必要があるかどうか
- Amazon S3 オブジェクトの事前署名済み URL
- Amazon S3 オブジェクトの変換
- Amazon S3 オブジェクトのタグ
- Amazon S3 オブジェクトのストレージ クラス
- Amazon S3 オブジェクトのアーカイブ
また、Amazon S3 オブジェクトに関するデータを収集し、ユーザーとワークロードが Amazon S3 オブジェクトを作成、更新、削除する頻度を把握することをおすすめします。
移行中の問題を回避し、移行に必要な労力を見積もるために、Amazon S3 のオブジェクト機能と類似した Cloud Storage のオブジェクト機能のマッピングを評価することをおすすめします。次の表に、このマッピングの概要を示します。
前述のように、これらを比較すると、上記の表に示す機能は次のようになります。ただし、2 つのクラウド プロバイダで機能の設計と実装が異なると、Amazon S3 から Cloud Storage への移行に大きな影響を与える可能性があります。
評価を完了する
Amazon S3 環境からインベントリを構築したら、 Google Cloudへの移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。
基盤の計画と構築
計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。
- Google Cloud 環境でワークロードをサポートします。
- 移行元の環境と Google Cloud 環境を接続して、移行を完了します。
計画と構築のフェーズは、次のタスクで構成されます。
- リソース階層を構築する。
- Google Cloudの Identity and Access Management（IAM）を構成します。
- お支払い情報を設定する。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- ロギング、モニタリング、アラートを設定する。
これらの各タスクの詳細については、 Google Cloudへの移行: 基盤の計画と構築をご覧ください。
Amazon S3 から Cloud Storage にデータとワークロードを移行する
Amazon S3 から Cloud Storage にデータを移行するには、 Google Cloudへの移行: 大規模なデータセットを転送するのガイダンスに沿って、データ移行計画を設計することをおすすめします。このドキュメントでは、Storage Transfer Service の使用を推奨しています。Storage Transfer Service は、オンプレミス環境、またはその他のクラウド ストレージ プロバイダなど、複数のソースから Cloud Storage にデータを移行できる Google Cloud サービスです。Storage Transfer Service は、次のような数種類のデータ転送ジョブをサポートしています。
- 1 回限りの転送ジョブ。Amazon S3 または他のサポートされているソースから Cloud Storage にオンデマンドでデータを転送します。
- スケジュールされた転送ジョブ。Amazon S3 またはその他のサポートされているソースから Cloud Storage にスケジュールに従ってデータを転送します。
- イベント ドリブン転送ジョブ。Amazon S3 が Amazon S3 Event Notifications を Amazon Simple Queue Service（SQS）に送信するときにデータを自動的に転送します。
データ移行計画を実施する際は、1 つ以上のデータ転送ジョブを構成します。たとえば、移行中にカットオーバーの時間枠の長さを短縮するには、次のように継続的レプリケーションのデータ移行戦略を実施します。
- Amazon S3 バケットから Cloud Storage バケットにデータをコピーするように 1 回限りの転送ジョブを構成します。
- データの検証と整合性のチェックを行い、Amazon S3 バケット内のデータと Cloud Storage バケット内にコピーされたデータを比較します。
- Amazon S3 バケットの内容が変更されたときに、Amazon S3 バケットから Cloud Storage バケットにデータを自動的に転送するように、イベント ドリブン転送ジョブを設定します。
- 移行途中のデータ（つまり、前の手順に関連するデータ）にアクセスできるワークロードとサービスを停止します。
Amazon S3 ではなく Cloud Storage を使用するようにワークロードをリファクタリングします。ワークロードをリファクタリングするには、次のいずれかの方法、またはそれらの方法の順番に使用します。
- Amazon S3 から Cloud Storage への単純な移行。単純な移行では、Amazon S3 への認証済み REST リクエストを生成する既存のツールとライブラリを使用して、Cloud Storage への認証済みリクエストを代わりに生成します。
- Amazon S3 から Cloud Storage への完全な移行。完全な移行では、複数のプロジェクトや OAuth 2.0 の認証など、Cloud Storage のすべての機能を使用できます。
レプリケーションによって Cloud Storage が Amazon S3 と完全に同期されるまで待ちます。
ワークロードの処理を開始します。
フォールバック オプションとして Amazon S3 環境が不要になった場合は、廃止します。
Storage Transfer Service では、サポートされているソースから Cloud Storage にオブジェクトを移行するときに特定のメタデータを保持できます。対象となる Amazon S3 のメタデータを Storage Transfer Service で移行できるかどうか評価することをおすすめします。
データ移行計画を設計する際には、AWS ネットワークの下り（外向き）の費用と Amazon S3 の費用も評価することをおすすめします。たとえば、データを転送する場合は、次のオプションを検討してください。
- 公共のインターネット上。
- 相互接続リンクの使用。
- Amazon CloudFront の使用。
選択したオプションは、AWS ネットワークの下り（外向き）費用と Amazon S3 の費用に影響する可能性があります。このオプションは、インフラストラクチャのプロビジョニングと構成に必要な労力とリソースにも影響する可能性があります。 費用の詳細については、以下をご覧ください。
- AWS ドキュメントのデータ転送料金について
- Amazon S3 の料金
Amazon S3 から Cloud Storage にデータを移行する場合は、VPC Service Controls を使用して境界を作成し、サービスが承認されない限り、 Google Cloud サービス間の通信を明示的に拒否することをおすすめします。
Google Cloud 環境を最適化する
最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
最適化の目標を達成するまで、このシーケンスを繰り返します。
Google Cloud 環境の最適化の詳細については、 Google Cloudへの移行: 環境の最適化と Google Cloud アーキテクチャ フレームワーク: パフォーマンスの最適化をご覧ください。
次のステップ
- AWS から Google Cloud への移行のその他の工程を確認する。
- AWS サービスや Azure サービスと Google Cloudを比較する方法を学習する。
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Marco Ferrari | クラウド ソリューション アーキテクト