Google Cloud Bare Metal の移行戦略の選択

この記事では、ベアメタル ワークロードを Google Cloud に移行するための 3 つの一般的なオプションと、ワークロードの要件を理解するためのフレームワークについて説明します。また、状況に合ったベアメタル オプションの選択方法についても説明します。最後に、各移行戦略の実用的なユースケースを紹介します。

この記事は、Google Cloud の Migrate to Virtual MachinesBare Metal SolutionMainframe Modernization の機能や、それぞれがベアメタル ワークロードの移行にどのように役立つかを把握したい IT 管理者とスタッフを対象としています。また、この記事では Google Cloud で動作する IBM サービスについても説明します。

Google Cloud でのベアメタルへの移行は、クラウドに集中するために IT 戦略を変革するうえで重要なステップとなります。ベアメタル ワークロードを Google Cloud サービスの近くで実行することで、これらのサービスを活用しながら、アプリケーションのモダナイゼーション戦略を並行して実装できます。

サブスクリプション ベースの請求を評価する

この記事に記載されているベアメタルのオプションを決定する前に、現在の費用をよく確認してください。そうすることにより、会計やキャパシティ プランニングに合わせてソリューションを調整できます。オンプレミスの物理的なハードウェアからクラウドベースのサブスクリプションへの移行は、会計作業とビジネスプランのプロセスに影響する可能性があります。

クラウドに移行することで、サーバーを 3~5 年ごとに購入する必要がなくなります。代わりに、使用したクラウド リソースに応じて毎月 Google から請求されます。これは、サブスクリプション ベースのクラウド型の請求といいます。物理サーバーの寿命を数年にわたって減価償却することは、月ごとの運用コストの会計とは異なります。ベアメタルに移行する前に、会計とキャパシティ プランニングの機能を調整することが重要です。

Google Cloud を使用したベアメタルへの移行を可視化する

Google Cloud には、ベアメタル ワークロードを移行するためのオプションが数多く用意されています。最も一般的な方法は次の 3 つです。

次のフローチャートは、ベアメタル ワークロードに最適な移行戦略を決定する際のポイントをまとめたものです。ベアメタル サーバー アーキテクチャが IBM の場合は、Google Cloud で IBM Power Systems を使用します。アーキテクチャが x86 の場合は、ワークロードの仮想化が可能かどうかを確認します。可能でない場合は Google Cloud Bare Metal Solution を使用し、可能な場合は次の質問に進みます。ライセンスの関係でベアメタルのほうが望ましい場合や、物理サーバーを自社で管理したい場合は、Google Cloud Bare Metal Solution を使用します。そうでない場合は次の質問に進みます。ワークロードがノイジー ネイバーの影響を受けている場合は Compute Engine の単一テナントノードを選択します。それ以外の場合は、標準の Compute Engine VM を使用します。

意思決定のフローチャート

次のセクションでは、ベアメタルのオプションを比較するために、仮想化とその他の重要な情報について説明します。

始める前に: 仮想化について理解する

仮想化を使用すると、1 台の物理マシンで複数の仮想マシンを実行し、それぞれの仮想マシンで異なるオペレーティング システムとワークロードを実行できます。ほとんどのビジネス ワークロードが仮想マシンで実行されますが、物理マシンまたは「ベアメタル」で直接実行されるものもあります。

ベアメタル ワークロードの中には、Bare Metal Solution を使用して物理的なハードウェア上で直接実行されるものもあれば、仮想化されて Compute Engine に移行可能なものもあります。

次の図は、物理的なハードウェア、ハイパーバイザ、仮想マシン、オペレーティング システム、アプリケーションといったベアメタルの仮想化スタックの各レイヤで、Bare Metal Solution と Compute Engine がどのように機能するかを示しています。

ベアメタルの仮想化スタックの図

Migrate to VMs では、オペレーティング システムを選択してアプリケーションを管理します。Google は、ハイパーバイザやベアメタルを含む基盤となる仮想マシン インフラストラクチャを管理します。

Bare Metal Solution を使用すると、ハイパーバイザとその内部など、仮想化スタックのすべてのレイヤを管理できます。

仮想化すべきでない場合

企業でワークロードを仮想化できたとしても、それが必ずしも必要とは限りません。たとえば、物理サーバーの管理を企業としての強みとしている場合は、それを継続していくほうが好ましいでしょう。企業によっては、制限付きライセンス契約を専門とする特殊なソフトウェアが使用されている場合があり、その場合はソフトウェアを仮想環境で実行すると、かえって費用がかさむ結果となります。

多くの場合、ベアメタルで実行するワークロードには、ハードウェア上で実行する場合にのみ実現可能な技術的要件があります。たとえば、VMware ESXi Hypervisor は、Intel VT-xAMD RVI などのハードウェアレベルの仮想化機能にアクセスする必要があります。独自の仮想化スタックを管理している場合は、ソフトウェアに特定の BIOS 設定を構成する必要があります。

また、技術的な理由以外でベアメタルに残す必要のあるワークロードもあります。このような要件としては、ビジネス ポリシー、会計作業、IT スタッフの能力、ライセンスの制限などがあります。たとえば、ソフトウェアの仮想化を制限または禁止するために、ライセンス契約に制限事項を追加しているソフトウェア ベンダーもあります。その場合、ベアメタルで実行せずに仮想化を行うと、費用が増加する可能性があります。

企業によっては、クラウドベースのサービスを利用してリエンジニアリングを行うことを禁止する特殊なソフトウェアを使用している場合があります。また、仮想マシンに移行するとパフォーマンスが極度に低下する可能性のある特殊なソフトウェアをアプライアンスで実行している場合もあります。ハードウェアへの直接アクセスは必須ではありませんが、パフォーマンスやレイテンシの理由から必要になることがあります。特殊なアプライアンスを移行する場合は、仮想化を行うべきか、引き続きベアメタルで実行するべきかを評価し、検討する必要があります。

仮想化すべきでない場合がわかったので、次に、Google Cloud で利用可能なベアメタルのオプションについて見てみましょう。

Google Cloud のベアメタル オプションの比較

このセクションでは、ワークフローの図にあるベアメタルのオプションについて説明します。

Google Cloud で IBM に移行する

Google Cloud の IBM Power Systems は、IBM が提供する Infrastructure as a Service です。これは、オンプレミスと同じインフラストラクチャ機能と、Google Cloud サービスへの低レイテ