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

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

Compute Engine に移行する利点は次のとおりです。

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

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

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

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

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

費用の計算

まず、VM の移行を行う前に、移行の費用を計算しなければなりません。具体的には、データセンターの現在の運用費用を評価します。物理マシンの費用だけではなく、データセンターで使用しているネットワーク機器、電気代、高熱費、人件費、リース代を計算する必要があります。Google は、Cloud Physics や Stratazone などの技術パートナーと緊密に協力して、既存の IT ランドスケープのための無料の検出および評価ツールを提供しています。

これらの費用を計算するときには、クラウドの費用モデルを使用します。次の点を検討します。

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

これらの点はすべて、1 台の VM を移行する前に計画しておく必要がある費用の考慮事項です。GCP セールスチームは、これらの費用の評価と計算をサポートします。

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

移行対象の評価

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

これらのアプリケーションを次の 3 つのグループに分類します。

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

これは一例にすぎません。その他の判断基準もあります。それについては、GCP セールスチームがお手伝いします。

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

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

移行の設計

移行するアプリケーションを決めたら、移行を行う前にクラウド環境を設計する必要があります。まず、現在の環境と GCP の環境を比較します。比較すべき点について簡単な概要を次の表に示します。

サービスの種類 データセンター GCP
コンピューティング 物理ハードウェア、仮想化ハードウェア(VMWare ESXi、Hyper-V、KVM、XEN) Compute Engine
ストレージ SAN、NAS、DAS 永続ディスク、Cloud Storage
ネットワーク MPLS、VPN、ハードウェアの負荷分散、DNS Cloud VPN、CDN 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 および GCP サービスの比較評価に比較ガイドを使用できます。

さまざまなサービスを比較し、アプリケーションに必要なものが把握できたら、GCP などの環境を具体的に検討します。

VM を移行する前に、アプリケーションの環境を構築していく必要があります。以下では、おすすめの手順について説明します。

権限の設定

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

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

ネットワークの作成

VM を移行する前に、移行先のネットワークが存在していなければなりません。権限やアカウントと同様に、このネットワークも事前に作成しておく必要があります。アプリケーションを移行した後では手順の設定が難しくなります。

ネットワークを設計する場合、アプリケーションが使用するネットワークだけでなく、会社の使用パターンも設定する必要があります。次のことを検討してください。

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

会社によって事情が異なり、さまざまな選択肢があるため、どの環境にも当てはまる模範的な解答はありません。アプリケーションのデプロイを始める前に、自社の要件を把握し、適切な戦略を立てることをおすすめします。

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

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

Google へのより高速な接続が必要な場合は、CDN Interconnect を利用して Google への専用回線結ぶサポートを受けられます。

また、Google のダイレクト ピアリング ロケーションの 1 つに直接リンクを作成するという選択もできます。

オペレーションの計画

アプリケーションをクラウドで実行する場合、アプリケーションをモニタリングしてログを保持し、システム内で想定どおり動作するように管理する必要があります。計画の段階で、これらのオペレーションを検討しておく必要があります。

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

モニタリングとロギングについても判断して同様に行います。GCP 上で機能するサードパーティのツールがいくつかあります。すでにそれらの 1 つ以上を使用している場合は、引き続き使用する必要があります。それ以外の場合は、モニタリング、ロギング、およびアラートを単一のサービスに統合する Stackdriver など、さまざまなツールを検討してください。

移行の開始

最後に、最初のアプリケーションを移行します。最初の移行は今後のテンプレートとなります。移行を行いながらプロセスを調整していきますので、記録を残しておくことが重要になります。特に、最初の移行は重要です。

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

移行方法

大まかに言うと、アプリケーションの移行方法は 3 つあります。

まず、クラウド用にアプリケーションを完全に作り直す方法があります。これも現実的な選択肢の 1 つですが、クラウド用に新しいアプリケーションを作成することと同じですので、説明は割愛します。

ここでは、残りの 2 つの方法について説明します。

リフト&シフト移行

通常、このアプローチが最も簡単に着手できる方法です。アプリケーションに対する変更は少なくてすみます。このシナリオでは、既存のアプリケーションをシャットダウンして、データと仮想マシンをクラウドにコピーします。

データの移行

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

VM の移行

次に、VM を移行します。いくつかの方法があります。Google のクラウド移行ツール Velostrata の使用が推奨されています。Velostrata の場合、Velostrata が小さなブートセットを GCP に転送してからアプリケーションを起動し、バックグラウンドで透過的にデータを同期し、数分以内に VM が GCP 上で起動されます。

アプリケーションのテスト

データと VM を GCP に移行したら、アプリケーションをテストモードで実行し、動作を確認します。パフォーマンス指標を確認して、アプリのデプロイ、モニタリング、ロギングが正しく行われているかどうか検証します。Velostrata では組み込みのテストと適切なサイズ設定が行われ、クラウドのパフォーマンス、SLA、費用の検証が実行されます。

本番環境への移行

このステップにかかる時間は、アプリケーションの特性によって変わります。本番環境でのアプリケーションの実行に移行するには、一定期間アプリケーションをオフラインにしておく必要があります。Velostrata でこのオフライン時間を前もって非常に短くすることもできます(5 分程度にもなる)。ユーザーの観点から、アプリケーションをオフラインにせずに本番環境に移行する方法は、この一連のベスト プラクティスの対象範囲外です。

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

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

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

許容範囲の移行期間を決定した後、次の手順を行います。

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

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

ハイブリッド移行

3 つ目のアプローチはハイブリッド型です。この方法では、アプリケーションの一部分をクラウドに移行します。通常、フロントエンドの部分と、可能であればアプリケーション ロジックを移行します。バックエンドと関連サービスは既存のリソースと一緒に残します。ハイブリッドはリフト&シフトの変化形で、アプリケーションの移行が可能でも、バックエンド サービスの一部が移行できない場合に便利です。このタイプの移行では、リフト&シフトよりも手順が少なくなります。たとえば、データ ストレージはクラウドに移行しません。

ネットワーク接続を決定する

最初のステップは、既存のリソースと GCP の間に十分な速度の接続を確立することです。この接続の動作はアプリケーションのプロファイルに依存します。場合によっては、VPN で十分な可能性もあります。十分でない場合は、専用の高速回線が必要になります。

VM の移行

次に、VM イメージを移行します。リフト&シフトシナリオの場合と同様です。もう一度この時点でアプリケーションをテストして、クラウドで期待どおりに機能することを確認し既存のリソースにリンクします。

本番環境への移行

この場合はデータを移行する必要がないため、メンテナンスの時間枠がはるかに短くなります。残りの手順として次を行います。

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

何も問題がなければアプリが GCP 上で実行されます。この時点で、再びユーザーにアクセスを許可することができます。

GCP 移行ツール Velostrata を使用する

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

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

Velostrata で VM を GCP に移行する方法については、ドキュメントをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...