Google Cloud への移行: スタートガイド

Last reviewed 2023-10-09 UTC

このドキュメントは、ワークロードを Google Cloud に移行するプロセスの計画、設計、実装に役立ちます。経験豊富なチームであっても、別の環境にアプリを移行するのは容易ではありません。移行を慎重に計画して実施する必要があります。

このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから Google Cloud への移行を計画する場合に役立つ情報を提供します。また、移行について検討している場合、その概要を把握するためにも利用できます。

はじめに

Google Cloud への移行を計画する場合は、まず、移行に関わる環境の定義から始めます。出発点は、オンプレミス環境、非公開のホスティング環境または別のパブリック クラウド環境になります。

オンプレミス環境は、自社がすべての所有権を持ち、責任を負う環境です。冷却、物理的な安全対策、ハードウェアのメンテナンスなど、環境のあらゆる側面を管理します。

コロケーション施設などの非公開のホスティング環境では、物理的インフラストラクチャとその管理業務の一部を外部に委託しています。このインフラストラクチャは通常、複数の顧客で共有されています。非公開のホスティング環境では、物理的な安全対策やサービスを管理する義務はありません。ホスティング環境によっては、サーバー、ラック、ネットワーク デバイスなどの物理ハードウェアの一部を自社で管理している場合もあれば、他社がハードウェアの管理を行う場合もあります。通常、電源ケーブルとネットワーク ケーブルはサービスとして提供されるため、自社で管理する必要はありません。物理リソースを仮想化するハイパーバイザー、プロビジョニングする仮想化インフラストラクチャ、このようなインフラストラクチャ上で実行するワークロードはすべて自社で管理します。

パブリック クラウド環境の場合、リソース スタック全体を自社で管理する必要はありません。自社にとって最も重要なスタックに焦点を当てることができます。非公開のホスティング環境と同様に、基盤となる物理インフラストラクチャを管理する必要もありません。さらに、リソースを仮想化するハイパーバイザーの管理も必要ありません。仮想化されたインフラストラクチャを構築し、この新しいインフラストラクチャにワークロードをデプロイできます。また、フルマネージド サービスを購入すると、ランタイム環境の管理作業を気にすることなく、ワークロードに専念できます。

それぞれの環境��リソースと関連サービスの提供と管理を行う担当者は次のようになります。

リソース オンプレミス環境 非公開ホスティング環境 パブリック クラウド環境
物理的な安全対策 自社 サービス ��ロ��イダ サービス プロバイダ
電源ケーブルとネットワーク ケーブル 自社 サービス プロバイダ サービス プロバイダ
ハードウェア（メンテナンス含む） 自社 サービス プロバイダによって異なる サービス プロバイダ
仮想化プラットフォーム 自社 自社 サービス プロバイダ
アプリのリソース 自社 自社 自社（最終的にはフルマネージド サービスを利用）

このドキュメントでは、移行先の環境は Google Cloud です。

移行前の環境と移行先の環境を定義したら、移行対象となるワークロードの種類と関連する運用プロセスを定義します。このドキュメントでは、従来型とクラウド最適化の 2 種類のワークロードと運用について説明します。

以前のワークロードと運用プロセスは、クラウド環境を考慮せずに開発されています。通常、これらのワークロードと運用プロセスはスケーラビリティに対応していないため、変更が容易ではなく、実行とメンテナンスに多額の費用がかかる可能性があります。

クラウド最適化のワークロードと運用プロセスはスケーラブルで、移植可能であり、安全に利用できます。このようなワークロードと運用プロセスでは、実際のワークロードに集中できるため、デベロッパーの生産性とアジリティが向上します。開発環境やランタイム環境の管理に煩わされることなく、煩雑なデプロイ プロセスを手動で行う必要もありません。Google Cloud には、セキュリティの責任共有モデルがあります。インフラストラクチャの物理的な安全対策とセキュリティは Google Cloud 側の責任となりますが、インフラストラクチャにデプロイするワークロードのセキュリティは利用者側の責任となります。

このような環境とワークロードの種類を考慮すると、最初の状況は次のいずれかになります。

  • オンプレミス環境または非公開のホスティング環境で、以前のワークロードと運用プロセスを使用している。
  • オンプレミス環境またはプライベート ホスティング環境で、クラウド最適化のワークロードと運用プロセスを使用している。
  • パブリック クラウド環境または非公開のホスティング環境で、以前のワークロードと運用プロセスを使用している。
  • パブリック クラウド環境または非公開のホスティング環境で、クラウド最適化のワークロードと運用プロセスを使用している。

移行プロセスは出発地によって異なります。

以前のオンプレミス環境や非公開のホスティング環境からパブリック クラウドなどのクラウド最適化環境にワークロードを移行する作業は容易ではなく、リスクを伴います。移行に成功するには、移行プロセスの実施中に、移行するワークロードをできるだけ少なくする必要があります。従来のオンプレミス アプリをクラウドに移行する場合は、複数の移行手順が必要になります。

移行の種類

このドキュメントでは、次の主要な移行の種類を定義します。

  • 再ホスト: リフト＆シフト
  • 再プラットフォーム化: リフト＆最適化
  • リファクタリング: 移行＆改善
  • 再設計: モダナイズの継続
  • 再構築: 削除して置換（削除して置き換えとも呼ばれます）
  • 再購入

以下では、これらの移行タイプの違いと、どの種類を選択すべきかについて、事例を挙げながら説明します。

再ホスト: リフト＆シフト

再ホストによる移行の場合、変更やリファクタリングをほとんど行わずに、移行前の環境から移行先の環境にワークロードを移行します（変更やリファクタリングをまったく行わない場合もあります）。ワークロードを移行先の環境で実行するために必要な場合に限り、��行するワークロードに変更を行います。

ワークロードを移行先の環境でそのまま実行できる場合や、ビジネス上の変更が必要ない場合（または、ほとんど必要ない場合）は、再ホストによる移行が理想的です。このタイプでは、リファクタリングの量が最小限になるため、短時間で移行を行うことができます。

技術的な問題から、再ホストによる移行を強制的に行う場合もあります。移行するワークロードのリファクタリングや廃止ができない場合、再ホストによる移行を使用する必要があります。たとえば、ワークロードのソースコードを変更することが困難または不可能な場合や、ビルドプロセスが簡単でない場合は、ソースコードのリファクタリング後に新しいアーティファクトが生成されないことがあります。

チームがこれまで使用していた同じツールとスキルを引き続き使用できるため、再ホストによる移行が最も簡単です。これらの移行は、既製のソフトウェアにも対応しています。既存のワークロードを最小限のリファクタリングで移行するため、リファクタリングによる移行や再構築による移行と比べると、再ホストによる移行は短い時間で完了する傾向があります。

ただし、再ホストによる移行後、移行先の環境で実行されているワークロードはクラウド用に最適化されません。これらのワークロードでは、水平方向のスケーラビリティ、きめ細かな料金体系、高度なマネージド サービスなど、Cloud Platform の機能を活用できません。

再プラットフォーム化: リフト＆最適化

再プラットフォーム化による移行では、既存のワークロードをリフトし、これを新しいクラウド環境用に最適化します。

再プラットフォーム化による移行は、クラウドのコア コンピテンシーをすべて利用したい組織に最適です。これらのコンピテンシーには、弾力性のあるコンピューティング、冗長性、パフォーマンスの向上、セキュリティが含まれます。

たとえば、クラウドベースのマイクロサービス アーキテクチャや Google Kubernetes Engine のコンテナを利用するために、ワークロードをクラウドに再プラットフォーム化できます。これらのワークロードは、クラウドで実行することでパフォーマンスと効率が向上します。

ただし、再プラットフォーム化による移行は、再ホストによる移行よりも多くの作業を必要とします。新しい Cloud Platform は基盤となるコードベースが異なるため、すべてが最適なレベルで実行されていることを確認するために、テストを数回行う必要があります。

リファクタリング: 移行＆改善

リファクタリングによる移行では、新しい環境で機能するようにワークロードを変更するだけでなく、クラウド機能を利用できるようにワークロードを変更します。これにより、ワークロードのパフォーマンス、機能、費用、ユーザー エクスペリエンスを改善します。

ワークロードは、クラウドへの移行中または移行前に変更できます。たとえば、クラウドへの移行の経験がない場合は、移行中にワークロードを変更することをおすすめします。ただし、クラウド移行の経験がある場合は、クラウド機能を最大限に利用するためにワークロードで必要となる変更についてすでに把握しているかもしれません。

アプリの現在のアーキテクチャやインフラストラクチャが移行先の環境でサポートされていない場合、これらの制限を克服するため、一定のリファクタリングが必要になります。

リファクタリング方式を選択するのは、移行に必要な変更だけでなく、ワークロードの大幅な変更が必要になる場合です。

リファクタリングによる移行で、アプリはスケーラビリティや高可用性などのクラウド プラットフォームの機能を利用できるようになります。また、アプリのポータビリティを高めるために改善を行うこともできます。

ただし、アプリを移行するためにワークロードをリファクタリングする必要があるため、リファクタリングによる移行は再ホストによる移行よりも時間がかかります。

リファクタリングによる移行の場合、新しいスキルの習得も必要です。

再設計: モダナイズの継続

再設計による移行は、リファクタリングによる移行に似ています。ただし、再設計による移行は、ワークロード コードの仕組みを再構築するのではなく、そのコードの動作方法を変更します。こうしたコード変更により、ワークロードが最適化され、スケーラビリティ、セキュリティ、アジリティなどのクラウド最適化プロパティを利用できるようになります。たとえば、再設計による移行では、1 つの大規模なモノリシック ワークロードを、Google Cloud にデプロイする複数の独立したマイクロサービスに変換できます。

再設計による移行は、リファクタリングによる移行よりも複雑であるため、多くの時間と労力がかかります。再設計による移行では、新しいワークロードにバグやセキュリティの問題が発生する可能性があります。したがって、再設計による移行では、すべてが最適なレベルで実行されていることを確認するために、テストを数回行う必要があります。

再構築: 削除して置換

再構築による移行では、既存のアプリを廃止し、設計を見直して完全なクラウド最適化アプリに書き換えます。

現在のアプリが目標を達成していない場合（たとえば、アプリのメンテナンスを行いたくない場合、前述の方法では移行コストがかかりすぎる場合、アプリが Google Cloud でサポートされていない場合など）は、再構築することで移行させます。

再構築による移行では、アプリは水平方向のスケーラビリティ、高度なマネージド サービス、高可用性などの Google Cloud の機能を最大限に活用できます。アプリを最初から書き換えるので、既存のレガシー バージョンの技術的な問題も解決されます。

ただし、再構築による移行は、再ホストによる移行やリファクタリングによる移行よりも時間がかかることがあります。また、アプリを書き直す必要があるため、既製のアプリの移行には適していません。アプリのライフサイクルの一部として、追加の時間と作業を評価し、アプリの再設計と書き換えを行う必要があります。

再構築による移行では、新しいスキルも必要です。新しいツールチェーンを使用して新しい環境のプロビジョニングと構成を行い、環境にアプリをデプロイする必要があります。

再購入

再購入による移行では、購入したオンプレミス ワークロードから、クラウドでホストされる Software as a Service（SaaS）サービスに移行します。たとえば、オンプレミスのコラボレーション ソフトウェアとローカル ストレージから Google Workspace に移行できます。

リソースの観点から見ると、再購入��よる移行��、リファクタリング、再構築、再設計による移行よりもはるかに容易です。ただし、再購入による移行の方がコストが大幅に高くなる可能性があり、独自のクラウド環境を制御するきめ細かい機能を利用できない場合があります。

Google Cloud 導入フレームワーク

移行を開始する前に、クラウド テクノロジーの導入に対する組織の成熟度を評価する必要があります。Google Cloud 導入フレームワークを利用すると、組織のビジネス情報技術の現状を把握し、目標の達成に何が必要かを確認できます。

このフレームワークを使用すると、次の図のように Google Cloud に対する組織の準備状況を評価し、新しい技術に対応するために必要な作業を確認できます。

4 つのテーマと 3 つのフェーズから構成される Google Cloud 導入フレームワークのアーキテクチャ。

このフレームワークでは、次の 4 つのテーマを評価します。

  • 学習。学習プログラムの質と規模。
  • リード。Google Cloud への移行で IT 部門がサポートされる範囲。
  • スケーリング。クラウド最適化サービスを使用する範囲と、運用の自動化をどの程度実施しているか。
  • セキュリティ。現行の環境を不正アクセスから保護する能力。

フレームワークによって、それぞれのテーマごとに、次のどのフェーズにあるかを評価します。

  • 戦術。すべてのワークロードを網羅する一貫した計画はありません。投資の迅速な回収と IT 組織の混乱を少なくすることに重点が置かれています。
  • 戦略。将来のスケーリングのニーズに合わせて個々のワークロードを開発する計画があります。業務を合理化し、現在よりも効率的にする中期的な目標に重点が置かれています。
  • 革新的。クラウド運用は円滑に機能し、運用から収集したデータで IT ビジネスを改善しています。IT 部門を組織のイノベーションの原動力の 1 つにするという長期的な目標に重点が置かれています。

4 つのトピックを 3 つのフェーズで評価することで、クラウド技術に対する組織の成熟度を測ることができます。それぞれのテーマで、新しいテクノロジーを採用したときに、どのような変化が起きるかを把握できます。組織全体でより戦略的に取り組むには、チームでより包括的で一貫したトレーニングを行う必要があります。

移行パス

移行プロセスは始まったばかりです。現在は既存のインフラストラクチャと環境を備えたポイント A にあり、ポイント B に到達しようとしています。A から B に到達するには、上記のいずれかのオプションを選択します。

次の図は、移行パスを表しています。

4 フェーズの移行パス

移行には 4 つのフェーズがあります。

サポート

Google Cloud では、Google Cloud サービスを有効に利用していただくために、必要なヘルプとサポートを見つける際の各種のオプションとリソースを提供しています。

セルフサービス リソース

専用サポートが不要な場合、次のリソースを使用できます。

  • プロダクト ドキュメント。Google Cloud では、そのプロダクトとサービス、API に関するドキュメントを用意しています。
  • アーキテクチャ センターのドキュメント。アーキテクチャ センターの移行セクションでは、多くの移行シナリオを取り上げています。たとえば、移行リソースには、Google Cloud への移行段階に関するガイダンスが記載されています。
  • ツール。Google Cloud では、移行を支援するためにいくつかのプロダクトとサービスを提供しています。次に例を示します。
    • Google Cloud Migration Center は、現在のオンプレミス環境またはクラウド環境から Google Cloud へのエンドツーエンドのクラウド移行を加速することに役立つ統合プラットフォームです。
    • Migrate to Virtual Machines は、物理サーバーと仮想マシンをオンプレミス環境やクラウド環境から Google Cloud に移行するためのプロダクトです。Migrate to VMs によって、Google Cloud に数分で仮想マシンを移行できます。データはバックグラウンドでコピーされますが、仮想マシンは完全に機能しています。
    • Storage Transfer Service を使用すると、他のクラウド プロバイダ、オンライン リソースまたはローカルデータから Cloud Storage にデータを転送できます。
    • Database Migration Service は、データベースを Google Cloud に移行する際に役立つプロダクトです。
    • Transfer Appliance は、業務運営を中断することなく、大量のデータ（数百テラバイトから 1 ペタバイトまで）を Google Cloud に移行できるハードウェア アプライアンスです。
    • BigQuery Migration Service は、データ ウェアハウスを BigQuery に移行するための包括的なソリューションです。
  • ホワイトペーパー。これらのドキュメントには、リファレンス アーキテクチャ、事例紹介、ベスト プラクティス、高度なチュートリアルが含まれています。
  • メディア コンテンツ。Google Cloud Podcast を視聴できます。Google Cloud YouTube チャンネルの動画も閲覧できます。商品説明から開発戦略まで、幅広いトピックを取り上げています。
  • オンライン コースとラボ。Google Cloud では、動画コンテンツ、ドキュメント、ラボなどの Coursera でのコースに登録できます。Google Cloud Skills Boost を使用するか、ハンズオンラボに参加して、ラボを利用することもできます。

技術パートナー

Google Cloud は、複数の企業と提携し、お客様が各社の製品を使用できるようにします。一部のサービスは無料でご利用いただけます。各社および Google Cloud アカウント マネージャーまでお問い合わせください。

システム インテグレータ

Google Cloud では、プロダクトやテクノロジー企業だけでなく、キーボード操作を説明できるシステム インテグレータとも提携しています。パートナー リストには、クラウドへの移行に特化したシステム インテグレータも含まれています。

Google Cloud プロフェッショナル サービス

Google のプロフェッショナル サービスチームは、Google Cloud への投資を十分に活用できるようにサポートします。

Cloud Plan and Foundations: 移行を支援

プロフェッショナル サービスでは、Cloud Plan and Foundations サービスを使用して、移行計画を作成し、本番環境にワークロードをデプロイできます。Google Cloud 基盤の設定から、独自のワークロード要件によるプラットフォームの最適化やワークロードのデプロイに至る、ワークロードの本番環境への移行が完了するまでの各フェーズで、ガイダンスが提供されます。

Cloud Plan and Foundations の目的は次のとおりです。

  • Google Cloud 基盤の設定
  • 設計ドキュメントを作成する
  • デプロイと移行の作業を計画する
  • ワークロードを本番環境にデプロイする
  • 問題とリスクを追跡する

プロフェッショナル サービスは、次のアクティビティの結果と成果物をチームに提供します。

  1. 技術的なキックオフ ワークショップを実施する
  2. 技術設計書を作成する
  3. 移行計画を作成する
  4. プログラム チャーターを作成する
  5. プロジェクト管理を行う
  6. 技術的な専門情報を提供する。

Cloud Sprint: Google Cloud への移行を加速化

Cloud Sprint は、アプリを Google Cloud にスムーズに移行できるように支援するための集中型ワークショップです。このワークショップで、Google Cloud プロフェッショナル サービスは対話型ディスカッション、ホワイトボード セッション、ターゲット アプリの見直しを介して、チームの Google Cloud への移行を支援します。Cloud Sprint の期間中は、チームメンバーがクラウド ソリューションを直接体験し、導入に関して必要な作業内容を把握して、Google Cloud への移行に向けた次のステップについて理解できるようにプロフェッショナル サービスがサポートします。

トレーニング: チームのスキルを磨く

Google Cloud プロフェッショナル サービスでは、チームのニーズに基づいた分野でトレーニングを行います。

次のステップ