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

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

このドキュメントは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。

この記事はシリーズの一部です。

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移行の種類

移行には次の 3 つの種類があります。

  • リフト&シフト
  • 改善して移行
  • 削除して置換(削除して置き換えとも呼ばれます)

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

リフト&シフト

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

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

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

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

ただし、「リフト&シフト」で移行した場合、移行先の環境で実行されるのはクラウドネイティブでないワークロードになります。これらのワークロードでは、水平方向のスケーラビリティ、きめ細かな料金体系、高度なマネージド サービスなど、Cloud Platform の機能を活用できません。

改善して移行

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

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

改善して移行を選択するのは、移行に必要な変更だけでなく、ワークロードの大幅な変更が必要になる場合です。

改善して移行することで、アプリケーションはスケーラビリティや高可用性などの Cloud Platform の機能を利用できるようになります。また、アプリの移植性を高めるために改善を行うこともできます。

改善して移行は、リフト&シフトよりも時間がかかります。これは、アプリの移行でリファクタリングが必要になるためです。アプリのライフサイクルの一部として、追加の時間と作業を評価しておく必要があります。

「改善して移動」の場合、新しいスキルの習得も必要です。

削除して置換

「削除して置換」では、既存のアプリを廃止し、設計を見直してクラウドネイティブなアプリに書き換えます。

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

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

ただし、「削除して置換」は、他の 2 つの移行方法よりも時間がかかります。また、アプリを書き直す必要があるため、既製のアプリの移行には適していません。アプリのライフサイクルの一部として、追加の時間と作業を評価し、アプリの再設計と書き換えを行う必要があります。

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

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 では、移行を支援するためにいくつかのプロダクトとサービスを提供しています。次に例を示します。
    • Migrate to Virtual Machines は、物理サーバーと仮想マシンをオンプレミス環境やクラウド環境から Google Cloud に移行するためのプロダクトです。Migrate to VMs によって、Google Cloud に数分で仮想マシンを移行できます。データはバックグラウンドでコピーされますが、仮想マシンは完全に機能しています。
    • Google Cloud CLICloud Storage JSON API、または Google Cloud コンソールを使用した Cloud Storage へのオンライン転送。
    • Storage Transfer Service を使用すると、他のクラウド プロバイダ、オンライン リソースまたはローカルデータから Cloud Storage にデータを転送できます。
    • 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 プロフェッショナル サービスでは、チームのニーズに基づいた分野でトレーニングを行います。

次のステップ

  • 環境の評価と調査を行い、Google Cloud への移行を開始する。
  • Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center をご覧ください。