仮想マシンを Compute Engine に移行するためのベスト プラクティス

この記事では、コンピューティングのワークロードを Google Cloud に移行する際のガイダンスとベスト プラクティスについて説明します。このガイドは、すでに一般的なクラウド コンピューティングのコンセプトに精通しているクラウド コンピューティング アーキテクトおよびシステム アーキテクトを対象としています。

Compute Engine に移行するメリットは次のとおりです。

  • 費用。Compute Engine 仮想マシン(VM)の継続利用割引(SUD)を使用すると、従来のデータセンターでハードウェアや仮想マシン(VM)を管理するよりもコストを大幅に削減できます。別のクラウドから Google Cloud に移行する場合も、同じ価格設定のメリットを活用できます。

  • アジリティ。リソースの獲得とプロビジョニングを待つことなく、ほとんど瞬時に仮想マシンを作成できるため、大半のお客様が即座にアジリティの向上を実感されています。新しいアプリケーションを迅速に準備して、テストし、必要に応じて終了できます。

  • オーバーヘッド。通常、データセンターでは複数のベンダーを利用していますが、ベンダーごとに契約内容や料金体系が異なります。クラウドに移行すると、そのオーバーヘッドを大幅に削減できます。データセンターの運用管理を担当するスタッフの負担も軽減できます。従業員はより重要な業務にシフトできます。

すべての技術的ワークロードの大部分はコンピューティング リソース(コンピューティング)を必要とするため、この記事では VM の移行に焦点を当て、同時に、データベース、メッセージング、分析など、アプリを動作させるその他のサービスについても説明します。

移行は単なる 1 つの小さなステップではありません。巨大なステップです。下記のセクションでは、推奨される手順について説明します。

費用の計算

VM を移行する前に行う最初のステップは、移行の費用とデータセンターで実行しているものの費用を計算することです。この計算には、物理マシンの費用だけでなく、データセンターで使用しているネットワーク機器の代金、電源と冷却の費用、人件費、リース代を計算する必要があります。

これらの費用の見積りを助けるため、Google は、Cloud Physics や StratoZone などの技術パートナーと緊密に協力して、既存の IT ランドスケープのための無料の検出および評価ツールを提供しています。

費用がわかったら、クラウドの費用モデルが必要です。次の点を考慮してください。

  • 使用するオペレーティング システムの種類。ライセンスが必要かどうか。
  • 使用する仮想マシンの種類。さまざまなサイズがあり、サイズによってコストが異なります。アプリのパフォーマンス特性を把握する必要があります。
  • 仮想マシン以外に、アプリに必要なサービスは何か。また、それらの料金はいくらか。
  • これらのアプリにはライセンスが必要なソフトウェアが必要か。クラウドではどのくらいの費用がかかるか。

VM を移行する前に、上記の点をすべて検討しておく必要があります。Google Cloud セールスチームが、これらの費用の見積もりと計算をサポートします。

すでにクラウド プロバイダを利用されている場合には、検討項目が変わります。たとえば、その場合データセンターのリース費用を考慮する必要はありません。しかし、要件は変わりません。移行する前に、現在のプロバイダと Google の間で異なる課金モデルを理解することが重要です。Amazon Web Services(AWS)から移行する場合には、Cloud Platform のブログに記載されている仮想マシンの料金比較が参考になります。

移行対象の評価

移行コストを計算したら、何を移行するのかを検討します。社内で利用されているアプリは 1 種類ではありません。お客様が直接アクセスできるアプリもあれば、バックオフィスのアプリ、デベロッパー用のツール、試験運用中のアプリもあります。すべてのアプリを同時に同じ方法で移行することに意味はありません。

これらのアプリを次の 3 つのグループに分類することをおすすめします。

  • 簡単に移行できるアプリ。たとえば、依存度の低いアプリケーション、社内で最近作成したライセンス不要なアプリケーション、スケーリングやクラウド パターンに対する耐性の高いアプリケーションなどが該当します。
  • 移行が難しいアプリ。依存度が高く、スケーリングに対する耐性が低いアプリケーションやライセンス要件が複雑なアプリケーションが該当します。
  • 移行できないアプリ。移行に適さないアプリには、特殊なハードウェアや古いハードウェアで実行されているアプリ、ビジネスや規制上の要件を満たすために自社のデータセンターに存在する必要があるアプリ、ライセンス要件が複雑でクラウドに移行できないアプリがあります。

これらは 3 つのグループそれぞれの例にすぎず、実際に使用しているアプリにはさらに多くの決定要因があるはずです。Google Cloud セールスチームがサポートいたします。

これらの条件を考慮して、データセンターまたは他のクラウド プロバイダから移行するかどうかを決める必要があります。

この作業が完了したら、最初に移行するアプリを選択します。最初の段階では、少数のアプリだけを移行することをおすすめします。最初の移行は今後のテンプレートとなるだけでなく、移行プロセスを定義する判断材料となります。

移行の設計

移行するアプリを決定したら、移行する前にクラウド環境を設計する必要があります。まず、現在の環境と Google Cloud の環境を比較します。次の表に比較のポイントをまとめます。

サービスタイプ データセンター Google Cloud
Compute 物理ハードウェア、仮想化ハードウェア(VMware ESXi、Hyper-V、KVM、XEN) Compute Engine
ストレージ SAN、NAS、DAS 永続ディスク、Cloud Storage
ネットワーク MPLS、VPN、ハードウェアの負荷分散、DNS Cloud VPN、Cloud Interconnect、Cloud Load Balancing、Google Domains、Cloud DNS
セキュリティ ファイアウォール、NACL、ルートテーブル、暗号化、IDS、SSL Compute Engine ファイアウォール、暗号化、IDS、SSL
ID Active Directory、LDAP IAM、GCDS、LDAP
管理 構成サービス、CI / CD ツール Deployment Manager、構成サービス、継続的インテグレーション / 継続的デリバリー(CI / CD)ツール

AWS から移行する場合は、比較ガイドを使用して、AWS と Google Cloud サービスの違いを評価してください。

さまざまなサービスを比較して、アプリのニーズと使用方法を理解したら、Google Cloud での環境を計画します。

VM を移行する前に、アプリの環境を構築する必要があります。次のセクションでは、推奨される手順を説明します。

権限の設定

社内でクラウド リソースの作成、アクセス、変更、破棄を許可する担当者を決める必要があります。また、リソースの利用方法も決めておきます。詳細については、IAM のベスト プラクティスをご覧ください。

この段階で、クラウドのアカウントを所有する担当者も決めておきます。社内の全員に直接アクセスを許可する必要はありません。また、デベロッパー全員に許可する必要もありません。アカウントだけでなく、これらのアカウントの作成 / 削除ポリシーは事前に設定しておく必要があります。

ネットワークの作成

VM を移行する前に、移行先のネットワークが存在していなければなりません。権限やアカウントと同様に、事前にこのネットワークを作成することが重要です。アプリが稼働した後に、ネットワーク確立のための手続きを行うのは困難だからです。

ネットワークを設計する際には、アプリのネットワークを構築しているだけではなく、会社が従うパターンを設計していることも理解することが重要です。次のことを検討してください。

  • アプリごとに、または環境ごとに 1 つのネットワークを作成するのか。
  • アプリから共有サービスにどのようにアクセスするのか。
  • ハブアンドスポーク型のネットワークにするのか、フルメッシュ型にするのか。
  • さまざまなネットワークに接続するかどうか。
  • VPN 接続を使用するのか、プロジェクト間ネットワークを使用するのか。

さまざまな選択肢と企業間の違いを踏まえると、あらゆる状況に対応できる規範的なアドバイスを提供することは困難です。アプリのデプロイを始める前に、自社の要件を把握し、適切な戦略を立てることをおすすめします。

次に、既存のリソースにどのように接続するのかを検討します。Google では複数の接続オプションを用意していますので、必要に応じて選択することができます。

最も基本的なこととして、既存のリソースと Google の間に VPN 接続を作成できます。このサービスでは、両方のロケーションに静的または動的ルートを設定します。

Google への高速接続が必要な場合は、Cloud Interconnect をご利用ください。Google への専用回線作成のサポートが得られます。

また、Google のピアリング ロケーションの 1 つに直接接続する選択肢もあります。

オペレーションの計画

クラウドでアプリを実行している場合は、どのシステムでも行うのと同様に、アプリをモニタリングし、ログを保持し、運用管理を行う必要があります。計画の段階で、これらのオペレーションを検討しておく必要があります。

さまざまなサードパーティの構成ツールが提供されています。Chef、Puppet などのソフトウェアは有用です。これらのツールをすでに使用している場合は、引き続き Google Cloud 環境で使用されることでしょう。そうでない場合は、デベロッパーやオペレーション エンジニアの作業を考慮して、どのツールが最適か確認することを強く推奨します。これらのツールは Cloud Deployment Manager と連携して動作します。Cloud Deployment Manager をお客様のデプロイおよびオペレーション管理に組み込むことをおすすめします。

モニタリングとロギングにも同様のことを行います。Google Cloud で機能するサードパーティのツールがいくつかあります。これらのツールをすでに使用している場合は、それらを引き続き使用されることでしょう。使用していない場合は、Cloud LoggingCloud MonitoringError Reporting などのさまざまなツールを検討してください。

移行の開始

最初の移行は今後のテンプレートとなります。さらに移行を進めていくうちに手順を調整することが考えられます。しかし、最初の移行で行ったすべての作業を記録しておくことは重要です。

以下では、移行方法の概要と各シナリオでの移行手順について説明します。

移行方法

大まかに言うと、アプリごとに次の 3 種類の移行方法を使用できます。

1 つ目は、クラウド向けにアプリを完全に再設計することです。これは実行可能なオプションですが、クラウドで新しいアプリを作成する場合と基本的に同じなので、この記事では扱いません。

次のセクションでは、2 つ目と 3 つ目の方法について説明します。

リフト&シフト移行

この方法はアプリの変更を最小限に抑えるので、通常、開始するのが最も簡単な方法です。既存のアプリをシャットダウンし、データと仮想マシンをクラウドにコピーします。

データの移行

リフト&シフトの最初のステップは、アプリの実行に必要なデータを移動することです。多くの場合これはデータベースのデータですが、SAN から Cloud Storage のオブジェクト ストレージに移動できる静的なアセットも含まれます。アプリがローカルで必要とするデータを Cloud Storage に移動し、仮想マシンの起動時に Compute Engine の永続ディスクにダウンロードします。

VM の移行

次に、VM を移動します。これにはさまざまな方法があります。Migrate for Compute Engine を使用することをおすすめします。Migrate for Compute Engine では、平均で数分以内に Google Cloud で VM が開始されます。Migrate for Compute Engine は Google Cloud に小さな起動セットを転送した後、アプリを起動し、バックグラウンドで透過的にデータを転送して同期します。

アプリをテストする

Google Cloud 上でデータと VM を実行したら、アプリをテストモードで実行して期待どおりに動作しているか確認する必要があります。パフォーマンス指標を確認して、アプリのデプロイ、モニタリング、ロギングが正しく行われているかどうか検証します。Migrate for Compute Engine には組み込みテストと適切なサイズ設定があり、クラウド内のパフォーマンス、SLA、費用を検証できます。

本番環境への移行

この手順にかかる時間はアプリの性質によって異なります。本番環境のアプリを実行する場所を切り替えるには、ほぼすべての場合において、Migrate for Compute Engine を使用しても、ある程度はアプリがオフラインになる時間が必要です。このオフラインの時間は、事前の非常に短い時間(場合によっては約 5 分)にすることができます。ユーザーから見てアプリがオフラインにならないようにしつつ本番環境に移行する方法は、このベスト プラクティスの範囲外です。

移行にかかる時間は、次の 2 つの要素で決まります。

  • 元のデータをインポートしてから経過した期間
  • DNS で、アプリのフロントエンドのエントリを更新するのにかかる時間

通常、最初の要素は調整が可能です。本番環境への移行期間を短くするために、データをインポートした後にできるだけ早く移行してください。

許容できる期間を決定したら、次の操作を行います。

  1. メンテナンスの時間枠についてユーザーに通知します。
  2. 現在のロケーションからアプリを終了します。
  3. 不足しているデータを Google Cloud の適切な場所にインポートします。
  4. DNS エントリを切り替えて、クラウドでアプリをオンにします。

すべてのことが問題なく完了すればアプリの移行は完了です。使用可能になったことをユーザーに通知してください。Migrate for Compute Engine を使用すると、ソフトウェアがクラウドへのデータ転送を処理し、移行中に移行元と移行先の間でデータを同期し、DNS エントリを更新します。この処理により、移行中の多大な労力とリスクを軽減できます。

ハイブリッド移行

3 つ目の方法はハイブリッド移行です。この方法では、アプリの一部だけをクラウドに移行します。通常はフロントエンドとアプリのロジックです。バックエンドと関連サービスは既存のリソースと一緒に残します。ハイブリッド移行は、リフト&シフトのバリエーションです。アプリはクラウドに移動できても一部のバックエンド サービスを移動できない場合に役立ちます。このタイプの移行は、リフト&シフトよりも手順が少なくて済みます。たとえば、この方法ではデータ ストレージはクラウドに移動しません。

ネットワーク接続の決定

最初のステップは、既存のリソースと Google Cloud の間に十分な速度の接続を確立することです。この接続の動作はアプリのプロファイルによって異なります。VPN で十分な場合もあれば、専用の高速回線が必要になる場合もあります。

VM の移行

次に、VM イメージを移行します。リフト&シフトシナリオの場合と同様です。繰り返しになりますが、この時点でアプリをテストして、クラウドで想定どおりに動作することを確認し、元の既存のリソースにリンクします。

本番環境への移行

この場合はデータを移行する必要がないため、メンテナンスの時間枠ははるかに短くなります。それでも、次の操作を行う必要があります。

  1. メンテナンスの時間枠をユーザーに通知します。
  2. 既存のアプリをオフにします。
  3. DNS エントリを切り替えます。
  4. クラウドでアプリをオンにします。

すべてがうまくいけば、アプリは Google Cloud 上で動作するはずです。この段階で、使用可能になったことをユーザーに知らせてください。

Migrate for Compute Engine の使用

Migrate for Compute Engine はエージェントレス クラウド移行ツールを提供しており、VM を効率的に数分で Google Cloud に移行できます。ストリーミング テクノロジーを使用して移行時間を短縮するほか、適切なインスタンス タイプの選択に役立つ移行前のサイズ適正化の推奨を提供し、VMware vCenter を統合して VM 移行を 1 か所で管理できるようにします。Migrate for Compute Engine は、VM を一括で同時に移行する処理を編成し、自動化するウェブベースのインターフェースも提供します。

現在、Migrate for Compute Engine は Google Cloud に移行するお客様には無料でご利用いただけます。標準の料金は、移行中または移行後に使用または消費された他のすべての Google Cloud プロダクトに適用されます。たとえば、Compute Engine VM を使用して Migrate for Compute Engine をデプロイする場合、そのインスタンス時間分の料金を支払う必要があります。Migrate for Compute Engine が使用する Google Cloud プロダクトの情報については、Migrate for Compute Engine の料金ページをご覧ください。

Migrate for Compute Engine で VM を Google Cloud に移行する方法については、ドキュメントをご覧ください。

次のステップ