このドキュメントでは、Google Cloud への移行の評価フェーズを計画、設計、実装するときに役立つ情報をご紹介します。ワークロードとサービスのインベントリを調査してそれぞれの依存関係をマッピングすると、どのワークロードをどの順序で移行すべきかを特定するのに役立ちます。Google Cloud への移行を計画して設計する際は、まず、現在の環境と移行対象のワークロードについて熟知する必要があります。
このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。
- Google Cloud への移行: スタートガイド
- 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）を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
ワークロードのインベントリを作成する
移行のスコープを設定するには、まず、現在の環境内に存在するワークロードやハードウェア アプライアンスなどのアイテムの数と、それぞれの依存関係を理解する必要があります。インベントリを作成するのは簡単な作業ではありません。とりわけ、自動カタログ化システムが整っていない場合は多大な労力を要する作業です。包括的なインベントリを作成するには、現在の環境内の各ワークロードと環境自体の設計、デプロイ、オペレーションを担当するチームの専門知識を活用する必要があります。
インベントリには、ワークロードだけに限定せずに少なくとも次のアイテムを含めてください。
- 各ワークロードの依存関係（データベース、メッセージ ブローカー、構成ストレージ システム、その他のコンポーネント）。
- ワークロード インフラストラクチャをサポートするサービス（ソース リポジトリ、継続的インテグレーションと継続的デリバリー（CI/CD）ツール、アーティファクト リポジトリなど）。
- サーバー、仮想環境または物理環境、ランタイム環境
- 物理アプライアンス（ネットワーク デバイス、ファイアウォール、その他の専用ハードウェア）
以上のリストを作成する際は、各アイテムについて以下の情報も収集してください。
- ソースコードの場所と、そのソースコードを変更できるかどうか。
- ランタイム環境でのワークロードのデプロイ方法（たとえば、自動化されたデプロイ パイプラインを使用しているのか、あるいは手動でデプロイしているのかなど）。
- ネットワークに関する制限事項またはセキュリティ要件。
- IP アドレスの要件
- ワークロードをクライアントに公開する方法。
- ソフトウェアまたはハードウェアのライセンス要件。
- ワークロードが Identity and Access Management システムに対して認証される方法。
たとえば、各ハードウェア アプライアンスについて、その名前、ベンダー、テクノロジー、インベントリ内の他のアイテムへの依存関係といった詳細な仕様を把握する必要があります。次に例を示します。
- 名前: NAS アプライアンス
- ベンダーとモデル: ベンダー Y、モデル Z
- テクノロジー: NFS、iSCSI
- 依存関係: ジャンボ フレームを使用した VM コンピューティング ハードウェアへのネットワーク接続
このリストには、技術面以外の情報も含める必要があります。たとえば、各アイテムの使用許諾に適用されるライセンス条項や、その他すべてのコンプライアンス要件についての情報です。ライセンスにはクラウド環境へのワークロードのデプロイを許可しているものもあれば、クラウドへのデプロイを明示的に禁止しているものもあります。一部のライセンスは使用する CPU またはソケットの数に基づいて割り当てられますが、クラウド テクノロジーをベースに実行するアプリには、CPU やソケットの数といったコンセプトは適用されないこともあります。また、データによっては保管場所の地理的なリージョンに関して制限が課せられる場合もあります。さらに、機密性が高いワークロードには単独のテナントが必要になります。
インベントリとともに、収集したデータを視覚的に解釈できるようにすると役立ちます。たとえば、依存関係のグラフとチャートを用意すると、ワークロードが自動または手動のデプロイ プロセスでどのように配布されるかといった側面を明らかにできます。
インベントリの作成方法
ワークロード インベントリを構築する方法はいくつかあります。最も早い方法は手動で作成することですが、大規模な本番環境では、この方法に従うのは困難です。手動で作成されたインベントリの情報はすぐに古くなりがちであり、インベントリの内容を確認していないため、移行が失敗する可能性があります。
インベントリの作成は、一度限りの作業ではありません。現在の環境が極めて動的である場合、インベントリの作成とメンテナンスの自動化にも取り組んで、最終的に環境内のすべてのアイテムをいつでも矛盾のない状態で把握できるようにしてください。ワークロードのインベントリを作成する方法については、Migration Center: アセットの検出を開始するをご覧ください。
ワークロード インベントリの例
この例は、e コマースアプリをサポートする環境のインベントリを示しています。インベントリには、ワークロード、依存関係、複数のワークロードをサポートするサービス、ハードウェア アプライアンスが含まれます。
ワークロード
次の表には、環境内の各ワークロードについて、特に重要なテクノロジー、デプロイ手順、その他の要件が記載されています。
| 名前 | ソースコードの場所 | テクノロジー | デプロイ手順 | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|---|---|
| マーケティング ウェブサイト | 会社のリポジトリ | Angular フロントエンド | 自動 | 法務部がコンテンツを検証すること | キャッシュ サービス | 5 CPU コア 8 GB の RAM |
| バックオフィス | 会社のリポジトリ | Java バックエンド、Angular フロントエンド | 自動 | なし | SQL データベース | 4 CPU コア 4 GB の RAM |
| e コマース ワークロード | 独自のワークロード | ベンダー X モデル Y バージョン 1.2.0 |
手動 | 顧客データを欧州連合内で保管すること | SQL データベース | 10 CPU コア 32 GB の RAM |
| エンタープライズ リソース プランニング（ERP） | 独自のワークロード | ベンダー Z、モデル C、バージョン 7.0 | 手動 | なし | SQL データベース | 10 CPU コア 32 GB の RAM |
| ステートレス マイクロサービス | 会社のリポジトリ | Java | 自動 | なし | キャッシュ サービス | 4 CPU コア 8 GB の RAM |
依存関係
次の表に、インベントリにリストされているワークロードの依存関係の例を示します。これらの依存関係は、ワークロードが正常に機能するために必要です。
| 名前 | テクノロジー | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|
| SQL データベース | PostgreSQL | 顧客データを欧州連合内で保管すること | バックアップおよびアーカイブ システム | 30 CPU コア 512 GB の RAM |
サポート サービス
環境には、複数のワークロードをサポートするサービスがある場合があります。この e コマースの例には、次のサービスがあります。
| 名前 | テクノロジー | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|
| ソースコード リポジトリ | Git | なし | バックアップおよびアーカイブ システム | 2 CPU コア 4 GB の RAM |
| バックアップおよびアーカイブ システム | ベンダー G、モデル H、バージョン 2.3.0 | 法律により、一部のアイテムは長期間保管する必要がある | なし | 10 CPU コア 8 GB の RAM |
| CI ツール | Jenkins | なし | ソースコード リポジトリ アーティファクト リポジトリ バックアップおよびアーカイブ システム |
32 CPU コア 128 GB の RAM |
| アーティファクト リポジトリ | ベンダー A モデル N バージョン 5.0.0 |
なし | バックアップおよびアーカイブ システム | 4 CPU コア 8 GB の RAM |
| バッチ処理サービス | CI ツール内で実行される cron ジョブ | なし | CI ツール | 4 CPU コア 8 GB の RAM |
| キャッシュ サービス | Memcached Redis |
なし | なし | 12 CPU コア 50 GB の RAM |
ハードウェア
この環境の例には、次のハードウェア アプライアンスがあります。
| 名前 | テクノロジー | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|
| ファイアウォール | ベンダー H モデル V |
なし | なし | なし |
| サーバー j のインスタンス | ベンダー K モデル B |
サポートされなくなったため、廃止する必要がある | なし | なし |
| NAS アプライアンス | ベンダー Y モデル Z NFS iSCSI |
なし | なし | なし |
デプロイと運用のプロセスを評価する
デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらのプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。
デプロイ プロセスと運用プロセスで、ワークロードが機能するために必要なアーティファクトをビルドする場合があります。したがって、各アーティファクト タイプに関する情報を収集する必要があります。たとえば、アーティファクトには、オペレーティング システム パッケージ、アプリケーションのデプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなどがあります。
アーティファクト タイプに加えて、次のタスクの実施方法を検討してください。
- ワークロードを開発する。ワークロードを構築するために開発チームが実施しているプロセスを評価します。たとえば、開発チームはワークロードの設計、コーディング、テストをどのように行っているのか評価します。
- 移行元の環境にデプロイするアーティファクトを生成する。移行元の環境にワークロードをデプロイするには、コンテナ イメージやオペレーティング システム イメージなどのデプロイ可能なアーティファクトを生成するか、ソフトウェアをインストールして構成することで、サードパーティのオペレーティング システム イメージなどの既存のアーティファクトをカスタマイズします。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトが Google Cloud へのデプロイに適していることを確認できます。
アーティファクトを保存する。移行元環境のアーティファクト レジストリに保存するアーティファクトを生成する場合は、Google Cloud 環境でアーティファクトを利用可能にする必要があります。これは、次のような方法で実行できます。
- 環境間の通信チャネルを確立する: 移行元の環境のアーティファクトが移行先の Google Cloud 環境からアクセスできるようにします。
- アーティファクトのビルドプロセスのリファクタリング: 移行元の環境と移行先の環境の両方にアーティファクトを保存できるように、移行元の環境のマイナー リファクタリングを完了します。このアプローチでは、ターゲットの Google Cloud 環境にアーティファクトのビルドプロセスを実装する前に、アーティファクト リポジトリなどのインフラストラクチャを構築することで、移行をサポートします。このアプローチは直接実装することも、最初に通信チャネルを確立する以前のアプローチをベースにして実装することもできます。
移行元環境と移行先環境の両方でアーティファクトを使用できるため、移行の一部としてターゲットの Google Cloud 環境にアーティファクト ビルド プロセスを実装する必要はありません。
コードをスキャンして署名する。アーティファクトのビルドプロセスの一環として、コードスキャンを使用して一般的な脆弱性や意図しないネットワーク公開を防ぐことができます。また、コード署名を使用して、環境で実行されるコードが信頼できるものであることを確認できます。
ソース環境にアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを移行元の環境にデプロイしていることがあります。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloud との互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが移行元の環境で機能する場合は、Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。
ランタイム構成を挿入する。特定のクラスタ、ランタイム環境、ワークロード デプロイのランタイム構成を挿入していることがあります。この構成では、環境変数と、シークレット、認証情報、キーなどの構成値が初期化される場合があります。ランタイム構成の挿入プロセスが Google Cloud で機能するように、移行元の環境で実行されるワークロードの構成を評価することをおすすめします。
ロギング、モニタリング、プロファイリング。移行元環境の健全性、関心のある指標、これらのプロセスによって提供されるデータの使用方法をモニタリングするために、実装されているロギング、モニタリング、プロファイリングのプロセスを評価します。
認証。移行元の環境に対して認証を行う方法を評価します。
リソースのプロビジョニングと構成。移行元の環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装している場合があります。たとえば、Terraform を構成管理ツールとともに使用して、ソース環境でリソースをプロビジョニングして構成している場合があります。
インフラストラクチャを評価する
デプロイ プロセスと運用プロセスを評価したら、移行元の環境で現在ワークロードをサポートしているインフラストラクチャを評価することをおすすめします。
このインフラストラクチャを評価するには、次の点を考慮してください。
- 移行元の環境でリソースを整理した方法。たとえば、一部の環境では、組織、プロジェクト、Namespace など、リソースのグループを互いに分離する構造を使用してリソースを論理的に分離できます。
- 環境を他の環境（オンプレミス環境や他のクラウド プロバイダなど）に接続した方法。
ワークロードを分類する
インベントリの作成が完了したら、ワークロードを各カテゴリに分類して整理する必要があります。分類することで、クラウドに移行する際の複雑さとリスクに応じて、移行するワークロードの優先順位を付けられるようになります。
カタログ マトリックスには、環境内で検討する評価基準ごとに 1 つのディメンションが必要です。各ワークロードに必要なシステム リソースをはじめ、環境のすべての要件を網羅する一連の基準を選択してください。たとえば、ワークロードに依存関係があるかどうか、ステートレスかステートフルかを知りたい場合があります。カタログ マトリックスを設計する際は、各基準を追加するごとに、別の表現のディメンションを追加しているのだということを意識してください。最終的なマトリックスを可視化するのは難しい場合があります。この問題を解決するために考えられる方法は、1 つの複雑なマトリックスではなく、複数の小さなマトリックスを使用することです。
また、各ワークロードの横に、移行の複雑さを示す指標を追加してください。この指標は、各ワークロードの移行の難易度を推定するものです。この指標の粒度は環境によって異なります。基本的な例として、移行の難易度低、難易度高、または移行不可という 3 つのカテゴリに分類します。このアクティビティを完了するには、インベントリに含まれるアイテムごとに、専門家が移行の複雑さを見積もる必要があります。移行の複雑さを決定する要因は、各ビジネスに固有のものです。
カタログが完成したら、自分とチームが対象の指標を簡単に評価できるよう、図とグラフを作成することもできます。たとえば、依存関係を持つコンポーネントの数や、各コンポーネントの移行の難易度を明らかにするグラフを描画します。
ワークロードのインベントリを作成する方法については、Migration Center: アセットの検出を開始するをご覧ください。
ワークロード カタログの例
この例では、マトリックス軸ごとに以下の評価基準のうちの 1 つを使用します。
- ワークロードがビジネスにとってどの程度重要か。
- ワークロードに依存関係があるかどうか、また、ワークロードが他のワークロードの依存関係であるかどうか。
- ワークロードの最大許容ダウンタイム。
- ワークロードの移行の難易度。
| ビジネスにとっての重要性 | 依存関係がない | 依存関係がある | ダウンタイムの最大許容限度 | 難易度 |
|---|---|---|---|---|
| ミッション クリティカル | ステートレス マイクロサービス | 2 分 | 簡単 | |
| ERP | 24 時間 | 高 | ||
| e コマース ワークロード | ダウンタイムなし | 高 | ||
| ハードウェア ファイアウォール | ダウンタイムなし | 移行不可 | ||
| SQL データベース | 10 分 | 簡単 | ||
| ソースコード リポジトリ | 12 時間 | 簡単 | ||
| 非ミッション クリティカル | マーケティング ウェブサイト | 2 時間 | 簡単 | |
| バックアップとアーカイブ | 24 時間 | 簡単 | ||
| バッチ処理サービス | 48 時間 | 簡単 | ||
| キャッシュ サービス | 30 分 | 簡単 | ||
| バックオフィス | 48 時間 | 高 | ||
| CI ツール | 24 時間 | 簡単 | ||
| アーティファクト リポジトリ | 30 分 | 簡単 |
カタログの結果を可視化できるよう、図とグラフを作成できます。次のグラフは、移行の難易度を明らかにしています。
上の図から、ワークロードのほとんどは簡単に移行できる一方、3 つのワークロードは移行が難しく、1 つのワークロードは移行できないことがわかります。
Google Cloud について組織が学習する
Google Cloud を最大限に活用するには、組織がビジネスで利用できる Google Cloud 上のサービス、プロダクト、テクノロジーについての学び始める必要があります。それには、Google Cloud の無料トライアル アカウントを使用できます。スタッフはトライアル アカウントに含まれるクレジットを使って、サービスやプロダクトを試しながら学習できます。自由にテストして学習できる環境を作成することは、スタッフの学習体験にとって非常に重要です。
次のトレーニング オプションがあります。
- 一般公開されたオープン リソース: 無料のハンズオンラボ、動画シリーズ、Cloud OnAir ウェブセミナー、Cloud OnBoard トレーニング イベントを利用して Google Cloud について学習できます。
- 詳細なコース: Google Cloud の仕組みをより深く理解するには、Google Cloud Skills Boost のオンデマンド コースまたは Coursera の Google Cloud トレーニング スペシャライゼーションに参加できます。オンライン上で自分のペースでの参加や、世界中の認定トレーニング パートナーによるクラスルーム トレーニングの受講ができます。これらのコースの所要時間は、一般に 1 日から数日です。
- ロールベースの学習プログラム: 組織内でのロールに応じてエンジニアをトレーニングできます。たとえば、Google Cloud サービスの最適な使用方法をトレーニングできる、ワークロード デベロッパー向けの学習プログラムとインフラストラクチャ オペレーター向けの学習プログラムがあります。
また、さまざまなレベルの各種認定資格を取得して、Google Cloud に関するエンジニアの知識を認定することもできます。
- アソシエイト認定資格: Google Cloud の入門者にとって、Associate Cloud Engineer 認定資格などのアソシエイト認定資格はプロフェッショナル認定資格の取得に向けた出発点です。
- プロフェッショナル認定資格: 長年の経験で培った Google Cloud の高度な設計と実装のスキルを評価するには、Professional Cloud Architect や Professional Data Engineer などの認定資格を取得できます。
- Google Workspace 認定資格: Google Workspace 認定資格を取得すると、Google Workspace ツールを使用したコラボレーション スキルを実証できます。
- Apigee 認定資格: Apigee 認定 API エンジニア認定資格によって、堅牢で安全かつスケーラブルな API を設計、開発する能力を実証できます。
- Google Developers 認定資格: Associate Android Developer 認定資格（この認定資格は更新中です）と Mobile Web Specialist 認定資格によって、開発スキルを実証できます。
トレーニングと認定資格に加え、プロダクトを使用してビジネスの概念実証を作成することも、Google Cloud の経験を積むのにおすすめの方法の一つです。
概念実証を選択してテストする
Google Cloud の価値と有効性を明らかにするには、ワークロード カタログのワークロードの各カテゴリについて 1 つ以上の概念実証（PoC）を設計、開発することを検討してください。実験とテストによって、前提を検証し、ビジネス リーダーにクラウドの価値を実証できます。
概念実証には少なくとも以下の要素を含める必要があります。
- ワークロードがサポートするユースケースの包括的なリスト。例外的なケースや特殊なケースも含めます。
- 各ユースケースでのすべての要件。パフォーマンス、スケーラビリティ、一貫性の要件、フェイルオーバー メカニズム、ネットワーク要件などを含めます。
- 調査とテストの対象のテクノロジーとプロダクトのリスト。
PoC と実験を設計して、リストにあるすべてのユースケースを検証してください。各実験では、正確な有効性のコンテキスト、スコープ、期待される結果、測定可能なビジネスへの影響を考慮する必要があります。
たとえば、需要のピークに対応するために CPU バウンドなワークロードのうちの 1 つを迅速にスケーリングしなければならない場合、所定のゾーンで作成できる仮想 CPU コアの数と、それだけの CPU コアを作成するために必要な時間を検証するためのテストを実施します。現在の環境と比べ、新しいワークロードのスケールアップ時間が 95% 短縮されるなどといった顕著な付加価値が明らかになれば、このテストで直ちにビジネスに価値がもたらされることをアピールできます。
オンプレミス データベースのパフォーマンスが Cloud SQL、Spanner、Firestore、Bigtable と比較してどのように評価されるかに関心がある場合、同じビジネス ロジックでさまざまなデータベースを使用した概念実証を実装します。このような概念実証では、さまざまなベンチマークと運用費用の中から適切なマネージド データベース ソリューションを特定する機会を低リスクで得られます。
Google Cloud での VM プロビジョニング プロセスのパフォーマンスを評価するには、PerfKit Benchmarker などのサードパーティ ツールを使用して、Google Cloud を他のクラウド プロバイダと比較できます。ピーク パフォーマンスの標準的な指標（レイテンシ、スループット、完了までの時間など）のレポートに加え、クラウドでリソースをプロビジョニングするためのエンドツーエンドでの時間を測定できます。たとえば、多くの Kubernetes クラスタをプロビジョニングするのにどれだけの時間と労力がかかるか知りたい場合には、このようなツールを使用してください。PerfKit Benchmarker はオープンソース コミュニティの取り組みであり、研究者、学術機関、Google を含む企業など、500 件を超える参加者が関わっています。
総所有コストを計算する
新しい環境で必要となるリソースを明確に把握したら、総所有コストモデルを作成し、それを使用して Google Cloud にかかる費用を現在の環境での費用と比較できます。
総所有コストモデルを作成する際は、ハードウェアとソフトウェアの費用だけでなく、電力、冷却、メンテナンス、その他のサポート サービスなど、独自のデータセンターを運用するための費用のすべても考慮する必要があります。Google Cloud リソースには柔軟なスケーラビリティが備わっていることから、より厳格なオンプレミスのデータセンターと比べると、通常は費用を削減しやすいという点も考慮してください。
クラウドへの移行を検討するときに見落としがちな費用は、クラウド ネットワークの使用料金です。データセンターでは、ルーターやスイッチなどのネットワーク インフラストラクチャを購入して適切なネットワーク ケーブルを配線するための料金を一度支払えば、ネットワークの全容量を使用できます。クラウド環境では、ネットワークの使用に対する課金はさまざまな方法で行われます。データ集約型ワークロード、つまり大量のネットワーク トラフィックを生成するワークロードの場合、クラウドでのネットワーク コストを削減するには、新しいアーキテクチャとネットワーク フローの検討が必要になることが考えられます。
Google Cloud には、リソースとコストをインテリジェントにスケーリングできるように幅広いオプションも用意されています。たとえば、Compute Engine でのサイズ適正化は、Migrate for Compute Engine による移行中、VM が実行中になった後、またはインスタンスの自動スケーリング グループを作成するときに行うことができます。これらのオプションはサービスの実行費用に大きな影響を与える可能性があるため、十分に調べてから総所有コスト（TCO）を計算する必要があります。
Google Cloud リソースの合計費用を計算するには、料金計算ツールを使用できます。
ワークロードの移行戦略を選択する
移行するワークロードごとに、ユースケースに最適な移行戦略を評価して選択します。たとえば、ワークロードには次の条件があります。
- ミッション クリティカルなワークロードなど、ダウンタイムやデータ損失は許容されません。このようなワークロードでは、ダウンタイムがゼロまたはゼロに近い移行戦略を選択できます。
- セカンダリ ワークロードやバックエンド ワークロードなどのダウンタイムを許容します。このようなワークロードの場合は、ダウンタイムが必要な移行戦略を選択できます。
移行戦略を選択する際は、通常、ダウンタイムを必要とする移行戦略よりも、ダウンタイムなしまたはほぼダウンタイムなしの移行戦略の方が、設計と実装に費用と複雑さが増すことを検討してください。
移行ツールを選択する
ワークロードの移行戦略を選択したら、移行ツールを確認して決定します。
利用可能な移行ツールは多数あり、それぞれ特定の移行ユースケースに合わせて最適化されています。ユースケースには、次のようなものがあります。
- 移行戦略
- 移行元と移行先の環境
- データとワークロードのサイズ
- データとワークロードの変更頻度
- 移行にマネージド サービスを使用できるかどうか
シームレスな移行とカットオーバーを確実に行うには、アプリケーションのデプロイ パターン、インフラストラクチャ オーケストレーション、カスタム移行アプリケーションを使用します。ただし、マネージド移行サービスと呼ばれる専用のツールを使用すると、データ、ワークロード、さらにはインフラストラクチャ全体を環境間で移動するプロセスを容易に実施できます。これらの機能により、移行の複雑なロジックをカプセル化し、移行モニタリング機能を利用できます。
移行計画とタイムラインを定義する
現在の環境を完全に把握したら、移行計画を完成させるために、次の操作を行います。
- 移行するワークロードとデータをバッチ（一部のコンテキストではスプリントとも呼ばれます）にグループ化します。
- バッチの移行順序を選択します。
- 各バッチ内のワークロードの移行順序を選択します。
移行計画の一環として、次のドキュメントも作成することをおすすめします。
- 技術設計書
- RACI 図
- タイムライン（T-Minus プランなど）
Google Cloud の経験を積み、移行の勢いが増し、環境を理解できるようになったら、次のことができます。
- 移行するワークロードとデータのグループ化を絞り込みます。
- 移行バッチのサイズを増やす。
- バッチとバッチ内のワークロードを移行する順序を更新します。
- バッチの構成を更新します。
移行するワークロードとデータをバッチでグループ化し、移行順序を定義するには、次のようないくつかの基準に基づいてワークロードを評価します。
- ワークロードのビジネス価値。
- インフラストラクチャの残りの部分と比べ、ワークロードが独特の方法でデプロイまたは実行されているかどうか。
- ワークロードの開発、デプロイ、運用を担当するチーム。
- ワークロードの依存関係の数、種類、範囲。
- ワークロードを新しい環境で動作させるために必要なリファクタリングの作業。
- ワークロードのコンプライアンスとライセンスの要件。
- ワークロードの可用性と信頼性の要件。
最初に移行するワークロードで、チームは Google Cloud の知識と経験を築くことができます。チームがクラウドを扱って経験を積めば積むほど、移行プロセスの移行フェーズで問題が発生するリスクは低くなり、その後の移行が簡単かつ迅速になります。このため、最初に移行するのに適切なアプリを選ぶことが、移行を成功させる重要な鍵となります。
ビジネス価値
ビジネス クリティカルではないワークロードを選択すると、メインの業務が保護され、クラウド テクノロジーをまだ学習中のチームが気付かなかったリスクや誤りが及ぼすビジネスへの影響が少なくなります。たとえば、e コマース ワークロードの主要な金融取引ロジックが実装されているコンポーネントを最初に移行することにした場合、移行中に一つでも誤りがあると、メインの業務に支障をきたします。ワークロードをサポートする SQL データベースを選択するほうが適切です。さらに適切なのは、ステージング データベースを選択することです。
使用頻度の低いワークロードは避けてください。たとえば、わずかなユーザーが 1 年間に数回しか使用しないワークロードを選ぶと、低リスクの移行ではあるものの、移行に弾みはつかず、問題を検出して対処するのが困難な可能性があります。
エッジケース
移行する他のワークロードに適用できるパターンを発見できるよう、エッジケースも選ばないようにしてください。最初に移行するアプリを選ぶ際の主要な目標は、ナレッジベースを構築できるよう、組織での共通パターンの経験を積むことです。最初に移行したワークロードで学んだ教訓は、将来のワークロードを移行する際に生かすことができます。
たとえば、ワークロードのほとんどがテスト駆動開発手法に沿って設計され、Python プログラミング言語を使用して開発されている場合、テストカバレッジが少なく、Java プログラミング言語を使用して開発されたワークロードを選択しても、Python ワークロードの移行時に適用できるパターンは見つかりません。
チーム
最初に移行するワークロードを選択する際は、各ワークロードを担当するチームに注目してください。最初に移行するアプリを担当するチームは、非常に意欲的で、Google Cloud とそのサービスを積極的に試そうとするチームであることが理想的です。さらに、ビジネス リーダーシップが、最初にアプリを移行するチームの目標を明確に設定し、プロセス全体を通して積極的にチームの後援とサポートに取り組む必要があります。
たとえば、メインオフィスを拠点とし DevOps などの最新の開発方法を実装した確かな実績を持ち、サイト信頼性エンジニアリングなどに精通した高パフォーマンスのチームが有力候補となります。このようなチームにトップダウン型のリーダーシップによる後援もあり、各ワークロードの移行に関する明確な目標も設定されていれば、抜群の候補です。
依存関係
また、他のワークロードまたはサービスからの依存関係の数が特に少ないワークロードにも注目してください。Google Cloud での経験が限られている場合、依存関係のないワークロードを移行する方が簡単です。
他のコンポーネントに依存するワークロードを選択する必要がある場合は、依存関係に疎結合されているワークロードを選択します。最終的に依存関係が使用されなくなるように設計済みのワークロードであれば、ワークロードをターゲット環境に移行する際の負担が軽くなります。たとえば、疎結合の候補としては、メッセージ ブローカーを使用して通信するワークロード、オフラインで動作するワークロード、またはインフラストラクチャの他の部分の利用不可状態を許容するように設計されたワークロードが挙げられます。
ステートフル ワークロードのデータ移行戦略はありますが、ステートレス ワークロードにデータの移行が必要になることはほとんどありません。ステートレス ワークロードの移行では、一時的にデータの一部が現在の環境に置かれ、残りがターゲット環境に置かれるというフェーズを懸念する必要がないため、移行しやすくなります。たとえば、ステートレス マイクロサービスはローカルのステートフルなデータに依存しないため、最初に移行する有力候補です。
リファクタリングの作業
ワークロードのコードと構成に変更を加える作業に多大な労力をかけるのではなく、移行そのものと Google Cloud に集中できるよう、最初に移行するワークロードは最小限のリファクタリングで済むものにしてください。リファクタリングでは、ワークロードのモダナイゼーションと最適化ではなく、ターゲット環境でワークロードを実行できるようにするために必要な変更に焦点を絞ってください。ワークロードのモダナイゼーションと最適化には、移行の後の方のフェーズで取り組むことができます。
たとえば、構成の変更のみが必要なワークロードは、コードベースに変更を実装する必要がなく、既存のアーティファクトを使用できるため、最初に移行するワークロードの有力候補です。
ライセンスとコンプライアンス
最初に移行するワークロードを選ぶ際は、ライセンスも考慮事項の 1 つになります。ワークロードに適用されるライセンス条項が、移行に影響する可能性があるためです。たとえば、ライセンスの中には、クラウド環境でのワークロードの実行を明示的に禁止しているものもあります。
一部のワークロードには単一テナントの要件が適用されるため、ライセンス条項を確認するときは、コンプライアンス要件を念頭に置く必要があります。以上の理由から、最初に移行するワークロードとしては、ライセンスとコンプライアンスの制限が最も少ないワークロードを選んでください。
たとえば、お客様がデータの保存先リージョンを選択する法的権利を持っている場合や、お客様のデータが特定のリージョンに制限されている場合もあります。
可用性と信頼性
最初の移行候補として有力なのは、カットオーバー期間によるダウンタイムの影響を受けないアプリです。可用性の要件が厳しいワークロードを選択する場合は、Y（書き込み / 読み取り）などのゼロ ダウンタイムのデータ移行戦略を実装するか、データアクセス マイクロサービスを開発する必要があります。このアプローチは可能ですが、チームがこうした戦略の実装に時間を費やさなければならなくなるため、Google Cloud で必要な経験を積むことに集中できなくなります。
たとえば、バッチ処理エンジンの可用性の要件は、e コマースサイトでユーザーがトランザクションを確定するのに使うお客様向けワークロードよりも長い時間、ダウンタイムを許容できます。
移行計画を検証する
移行計画を開始する前に、その実現可能性を確認することをおすすめします。詳細については、移行計画の検証に関するベスト プラクティスをご覧ください。
次のステップ
- 移行を計画し、Google Cloud における基盤を構築する方法を確認する。
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Marco Ferrari | クラウド ソリューション アーキテクト