この記事は、ハイブリッド クラウドとマルチクラウドのデプロイ、アーキテクチャ パターン、ネットワーク トポロジについて説明する、マルチパート シリーズのパート 1 です。このパートでは、ハイブリッド クラウドとマルチクラウドのデプロイがもたらす機会と課題を検証し、Google Cloud を使用するハイブリッド構成に取り組み、これを実装する方法について指針を示します。
シリーズは次のパートで構成されています。
- ハイブリッド クラウドとマルチクラウドのパターンと実践（この記事）
- ハイブリッドおよびマルチクラウドのアーキテクチャ パターン
- ハイブリッドおよびマルチクラウドのネットワーク トポロジ
デジタル化が進み、変化する市場のニーズに素早く適応する必要にせまられ、企業の IT 部門にかけられる要望や期待が大きくなっています。多くの企業は、既存のインフラストラクチャやプロセスではこうしたトレンドに対応し、適応するのは困難であると感じています。
同時に IT 部門は、コスト効率改善に努力しているか監視の目が向けられ、プレッシャーにさらされているため、データセンターや機器の増設やモダナイズのために資本的支出（capex）の追加投資は望めません。
ハイブリッド クラウド戦略は、このような状況に対する実用的な解決策です。パブリック クラウドを使用することで、資本的支出の初期投資なしで IT の対応容量と能力を拡大できます。既存のインフラストラクチャに 1 つ以上のクラウド デプロイを追加すると、既存の投資を維持するだけでなく、1 社の IT ベンダーに縛られることがなくなります。さらに、ハイブリッド戦略を採用することで、アプリケーションとプロセスをリソースの許容範囲で段階的に最新化できます。
ハイブリッド クラウドとマルチクラウド
ワークロード、インフラストラクチャ、プロセスは企業ごとに異なるため、各ハイブリッド戦略は企業の特定のニーズに合わせる必要があります。そのため、ハイブリッド クラウドとマルチクラウドという言葉は、状況によって違う使われ方をします。
Google Cloud のコンテキストの場合、ハイブリッド クラウドが表すのは、共通の、または相互接続されたワークロードが複数のコンピューティング環境にまたがってデプロイされる構成です。その環境の 1 つはパブリック クラウドに基づき、少なくとも 1 つはプライベート コンピューティング環境です。
最も一般的な例は、次の図に示すように、プライベート コンピューティング環境（通常は既存のオンプレミス データセンター）とパブリック クラウド コンピューティング環境の組み合わせです。
マルチクラウドは、次の例のように、2 つ以上のパブリック クラウド プロバイダを組み合わせた構成を表します。
マルチクラウド構成には、プライベート コンピューティング環境も含まれる場合があります。
ハイブリッド クラウド構成とマルチクラウド構成での達成目標
ハイブリッド クラウド構成とマルチクラウド構成は、移行を可能にするために一定期間だけ維持される一時的なものとして使用される場合があります。反面、こうした構成が多くの組織の将来の状態を示している場合もあります。この構成の稼働場所がどこであっても、この構成によって新しいシステムが構築され、既存のシステムが進化してそれぞれのシステムが最大限に活用されるようになるからです。そのため、ハイブリッド クラウド構成とマルチクラウド構成は IT 環境において定着した存在になる可能性があります。
ハイブリッド クラウド構成やマルチクラウド構成はそれ自体が目標となる場合はまれであり、むしろビジネス要件を満たす手段になります。つまり、適切なハイブリッド クラウド構成やマルチクラウド構成を選択するには、まずビジネス要件を明確にする必要があります。
ビジネスにおける達成目標と制約
ビジネス側の視点での共通した達成目標と制約は次のとおりです。
- 設備投資や全般的な IT 支出を削減する。
- 変化する市場のニーズに的確に対応するための柔軟性と即応性を向上する。
- 既存の環境では実装が困難な、高度な分析サービスなどの機能を追加する。
- サービスの質と可用性を向上する。
- 費用やリソースの使用に関する透明性を高める。
- データの統治に関する法律や規制に留意する。
- ベンダーの固定化を避ける、または減らす。
設計と開発における達成目標
設計および開発側の視点での一般的な達成目標は次のとおりです。
- アプリケーションのロールアウトを自動化、迅速化することで、製品化までの時間とサイクル期間を短縮する。
- 抽象度の高い API やサービスを活用して開発スピードを速める。
- コンピューティング リソースとストレージ リソースのプロビジョニングを迅速化する。
運用上の要件と制約
運用側の視点で検討対象となる要件と制約は次のとおりです。
- コンピューティング環境全体で認証、承認、監査、ポリシーの一貫性を確保する。
- 一貫したツールやプロセスを使用することで、運用が複雑にならないようにする。
- 環境全体の可視性を確保する。
アーキテクチャ上の制約
アーキテクチャ側の視点では、大きな制約には次のようなものがあり、多くは既存のシステムに起因します。
- アプリケーション間の依存関係。
- システム間通信のパフォーマンスとレイテンシの要件。
- パブリック クラウドでは使用できないハードウェアやオペレーティング システムへの依存。
- ライセンス上の制限。
全体的な目標
ハイブリッド クラウド / マルチクラウド戦略で目指す目標は、計画によって上記の要件を満たすことです。計画に記述する内容は次のとおりです。
- 各コンピューティング環境で実施するワークロード、または各コンピューティング環境に移行するワークロード。
- 複数のワークロードに共通して適用するパターン。
- 使用するテクノロジーとネットワーク トポロジ。
基本的に、ハイブリッド クラウド / マルチクラウド戦略はビジネス要件に基づいて作成します。しかし、実用性のある戦略をどのようにビジネス要件から導き出すかは明確ではありません。選択するワークロード、アーキテクチャ パターン、テクノロジーは、ビジネス要件によって変わるだけでなく、循環しながら相互に影響し合います。次の図は循環の様子を示しています。
ビジョンの明確化
依存関係と制約が複雑にからみ合った中で、すべてのワークロードと要件に配慮した計画を定義することは、特に、複雑な IT 環境では困難な作業です。さらに、計画の作成には時間がかかるため、利害関係者同士で利益が相反してしまう可能性もあります。
こうした状況にならないよう、まずビジョン ステートメントを作成してください。ビジョン ステートメントは、ビジネスの展望に焦点を合わせ、次の質問に答えられるものでなければなりません。
- 現在のアプローチとコンピューティング環境ではなぜ不十分なのか。
- パブリック クラウドを使用して改善したいメインの指標は何なのか。
- ハイブリッド クラウドやマルチクラウドの設定の予定使用期間はどれくらいか。この設定を永続的なものと考えているのか、またはクラウドの移行が完了する間だけの暫定的なものと考えているのか。
ビジョン ステートメントにこうした目標の達成方法は記されません。
ビジョンに合意し、関係者の承認を取り付けることが、計画作成プロセスの次のステップに進むための基盤となります。
ハイブリッド クラウド / マルチクラウド戦略の策定
ビジョンを策定したら、戦略の詳細を決めていきます。
初期ワークロードの見積もりを行います。ビジョン ステートメントに記述されている目標を考慮しながら、計画されたワークロードと既存のワークロードのうち、パブリック クラウドにデプロイまたは移行することによってメリットを得られる可能性のある、候補ワークロードをリストします。このトピックについては、後のセクションで詳しく説明します。
明らかになった候補ワークロードから、適用可能なパターンを特定し、そのパターンに基づいて候補のトポロジを特定します。
適用可能なパターンとトポロジが複数見つかった場合は、ワークロードの選択を絞り込むことでパターンとトポロジを 1 つに決められるようにします。必要に応じて選択の絞り込みを繰り返します。
大規模な組織であれば、複数のパターンとトポロジを適用するアプローチも有効です。しかし、複雑性が増し、進行が遅くなるため、理想的とは言い難いアプローチです。
ワークロードの優先順位を付けます。要件が多い場合は、反復的アプローチを使用するのが適切です。
パブリック クラウドに投入する初期ワークロードを選択します。ビジネス クリティカルなワークロードや移行が非常に難しいワークロードは選択せず、その後に行うデプロイや移行のための青写真の役目を果たせる標準的なものを選んでください。
移行するワークロードを選択しながら、Google Cloud 側での準備を開始します。
最初のデプロイ用のクラウド環境を準備するために必要な Google Cloud の組織、プロジェクト、ポリシーを設定します。
ネットワーク トポロジを実装し、Google Cloud とプライベート コンピューティング環境間に必要な接続を確立します。
ワークロード
どのワークロードをどのコンピューティング環境で実施するかの決定は、ハイブリッド クラウド / マルチクラウド戦略の有効性に大きな影響を与えます。クラウドに不適切なワークロードを投入すると、デプロイが複雑化し、効果もほとんど得られません。適切な場所に適切なワークロードを投入すると、ワークロードが効率化されるだけでなく、各環境がもたらすメリットも把握できます。
クラウド ファースト
パブリック クラウドを使い始める際は「クラウド ファースト」方式を使用するのが一般的です。このアプローチでは、新しいワークロードをパブリック クラウドにデプロイします。この場合、技術的な理由や組織上の理由でクラウドへのデプロイを実施できない場合にだけ、プライベート コンピューティング環境に従来どおりのデプロイを行うことを検討してください。
クラウド ファースト戦略にはメリットとデメリットがあります。メリットは、先進的である点です。新しいワークロードを真新しいクラウド ネイティブな方法でデプロイできると同時に、既存のワークロードを移行する煩わしさを避ける（または最小限に抑える）ことができます。
デメリットは、クラウド ファースト戦略を使用すると、既存のワークロードを活用する機会を失う可能性がある点です。新しいワークロードが IT ワークロード全体に占める割合は低く、IT 全体の支出や業績に与える影響は限られます。既存のワークロードの移行に時間を費やす方が、クラウドで新しいワークロードに対応しようとするよりメリットが大きく、時間や費用も節減できる可能性があります。
また、クラウド ファースト戦略により IT 環境全体の複雑さが増すリスクもあります。このアプローチでは環境間の通信を余分に行うため、冗長性が生じ、パフォーマンスが低下する可能性があります。また、コンピューティング環境が個々のワークロードに適さなくなる懸念もあります。
上記のリスクを考慮すると、クラウド ファースト アプローチは一部のワークロードに限定して使用するのが適切と考えられます。これにより、クラウドにデプロイまたは移行するメリットの大きいワークロードに集中できます。このアプローチでは既存のワークロードの最新化にも取り組めます。この点については、次のセクションで説明します。
移行と最新化
ハイブリッド クラウド / マルチクラウドと IT の最新化は、好循環の中でリンクする 2 つのコンセプトです。パブリック クラウドを使用すると IT ワークロードの最新化を容易かつ簡単に実施でき、IT を最新化することでクラウドをより効果的に使用できます。
ワークロードを最新化する主な目的は、次のとおりです。
- 変化するニーズに適応できるように俊敏性を高める。
- インフラストラクチャと運用の費用を削減する。
- ビジネスリスクを最小限に抑えるために信頼性と復元性を高める。
Google Cloud への移行で説明しているように、以下のいずれかの移行タイプを実装できます。また、必要に応じて複数のタイプを組み合わせることもできます。
- リフト＆シフト
- 改善して移行
- 完全な置き換え
リフト＆シフト
リフト＆シフトは、ワークロードを大幅に変更せずにプライベート コンピューティング環境からパブリック クラウドに移行するプロセスを表します。通常、このプロセスでは、既存の仮想マシン（VM）とそのイメージを Compute Engine に移行します。
VM をプライベート コンピューティング環境ではなく Compute Engine で稼働する場合、次のメリットが得られます。
コンピューティング リソースとストレージ リソースを迅速にプロビジョニングできるため、従来の（プライベートまたはオンプレミス）データセンターでの機器の調達や設置による遅れが生じません。
コンピューティング リソースを使った分だけ支払うので、事前の約束や投資は不要です。
運用業務を自動化できるので、労力や費用を削減できます。
また、クラウド ネイティブ化を進めるためにアプリケーションを再作成する場合、さらに多くのメリットが得られます。
自動スケーリングを利用することで、必要なときにだけコンピューティング リソースがプロビジョニングされるので、オーバープロビジョニングの費用が発生しません。
Kubernetes などのクラスタ マネージャーを利用することで、障害発生時にアプリケーションを自動的に再起動したり別のマシンに移行したりして、アプリケーションの復元性を向上できます。
マネージド サービスを使用して運用のオーバーヘッドをさらに削減できます。
デプロイを自動化できるので、サービスの開発とリリースのプロセスが迅速化され、企業はフィードバック、変化するニーズ、市場の要求に迅速に反応できます。
上記の図に示すように、既存のワークロードを最新化するときは、アプリケーションをクラウドにシフトしてから、クラウド ネイティブにすることを検討してください。
改善して移行
一般的にはアプリケーションをクラウドにシフトしてから改善に取り組むのですが、アプリケーションによっては逆のアプローチが適切な場合があります。「改善して移行」の考え方は、移行を始めるにあたって、まず既存のアプリケーションのリファクタリングと最新化を行うというものです。アプリケーションをクラウドに移行する前でも、この改善にはいくつものメリットがあります。
デプロイ プロセスを改善できます。
継続的インテグレーション / 継続的デプロイ（CI/CD）のインフラストラクチャとツールに投資することで、リリースの間隔とフィードバック サイクルを短縮できます。
改善後にアプリケーションをクラウドに移行します。これにより、リソースを迅速にプロビジョニングでき、自動スケーリングによってオーバープロビジョニングをなくすことで費用効率を向上できます。
「改善して移行」を適切に実施するには、オンプレミス インフラストラクチャとツールに対してなんらかの投資（たとえば、ローカルの Docker レジストリを設定し、Kubernetes クラスタをプロビジョニングしてアプリケーションをコンテナ化する）を行うことを検討してください。
完全な置き換え
「削除して置き換え」は、システムを削除して置き換えることを表します。場合によっては、既存のシステムとコードベースを発展させようとしても、費用効率が低い場合や実現そのものが不可能なことがあります。ニーズが大きく変化した場合や、既存のアプリケーションが、将来の投資に適さないソフトウェアやハードウェア スタックに基づいている場合がこれに該当します。こうした場合は、システムを置き換える方法が適切です。置き換える場合、新しいソリューションの購入か、最新かつクラウド ネイティブなアプリケーションの新規開発が必要です。
移行アプローチの混用とマッチング
3 つの移行アプローチにはそれぞれ強みと弱みがあります。ハイブリッド クラウド / マルチクラウド戦略を採用する大きなメリットは、1 つのアプローチに決める必要がない点です。ワークロードごとに最適なアプローチを決められます。
次の条件に該当するワークロードでは、「リフト＆シフト」を選択してください。
- 環境に対する依存関係が比較的少ない。
- リファクタリングを行う必要はないと見なされている。
- サードパーティ ソフトウェアに基づいている。
次のようなワークロードでは「改善して移行」の使用を検討してください。
- 解決しなければならない依存関係がある。
- クラウドでは対応できないオペレーティング システム、ハードウェア、データベースシステムに依存している。
- コンピューティング リソースやストレージ リソースが効率的に使用されていない。
- デプロイの自動化が容易でない。
最後に、「削除して置き換え」は次のようなワークロードに適しています。
- 現在のニーズに対応できなくなっている。
- 古くなった第三者テクノロジーに基づいている。
- 支払いが必要な第三者ライセンス料が高価になっている。
ポータビリティ
多くの移行において、クラウドへのワークロードのシフトは 1 回限りの元に戻せない作業です。ただし、ハイブリッドの場合（特にマルチクラウドの使用時）、後でクラウド間でワークロードをシフトする必要が生じることがあります。この機能を利用するには、以下を確認してワークロードにポータビリティがあることを確かめてください。
- 大幅な変更を行わずに、コンピューティング環境間でワークロードをシフトできる。
- アプリケーションのデプロイと管理がコンピューティング環境間で一貫した方法で行われている。
- ワークロードのポータビリティを維持することが、ワークロードをクラウド ネイティブにすることと競合しない。
インフラストラクチャ レベルでは、Terraform などのツールを使用することで、異種混合環境内でのインフラストラクチャ リソース（VM やロードバランサなど）の作成を自動化し、一元化できます。また、Ansible、Puppet、Chef などの構成管理ツールを使用すると、デプロイと構成の共通プロセスを確立できます。Packer などのイメージ焼き付けツールを使用することで、単一の共有構成ファイルによって複数の異なるプラットフォーム用の VM イメージを作成することもできます。また、Prometheus や Grafana などのソリューションを使用すると、複数の環境間で一貫したモニタリングを実施できます。
上記のツールに基づいて、次の図のようなツールチェーンを構築できます。ツールチェーンによって、コンピューティング環境の違いを抽象化し、プロビジョニング、デプロイ、管理、モニタリングを統合できます。
一般的なツールチェーンでポータビリティを実現できますが、短所もあります。
クラウド環境固有の機能を利用できない場合があります。特に、VM を共通基盤として使用すると、真にクラウド ネイティブなアプリケーションの実装が難しくなります。場合によっては、VM を使用することでマネージド サービスを利用できなくなり、管理オーバーヘッドを削減する機会が失われることもあります。
ツールチェーンの構築と維持に、オーバーヘッドと運用コストが発生します。
時間とともにツールチェーンが拡大して複雑化する可能性があります。複雑さの程度は企業ごとに異なります。ツールチェーンの複雑化がトレーニング費用の増加につながることもあります。
コンテナと Kubernetes
カスタム ツールチェーンを構築、維持して VM によってワークロードのポータビリティを実現する場合、多くの課題がそれに伴います。1 つの解決策として、コンテナと Kubernetes を活用する方法があります。
コンテナを利用すると、ソフトウェアを異なる環境に移行しても、その動作の信頼性を維持できます。コンテナ化されたアプリケーションのオーケストレーション、デプロイ、スケーリング、管理は Kubernetes によって行われ、クラウド ネイティブなアプリケーションの基盤となるサービスが提供されます。Kubernetes はさまざまなコンピューティング環境にインストールして実行できるため、Kubernetes を使用してコンピューティング環境間に共通したランタイム レイヤを確立することもできます。
Kubernetes では、クラウド コンピューティング環境とプライベート コンピューティング環境で同じサービスと API が提供されます。さらに、抽象化のレベルが VM の使用時より大幅に高まるため、必要な下準備が減り、デベロッパーの生産性が向上します。
カスタム ツールチェーンとは異なり、Kubernetes は開発とアプリケーション管理の両方に広く採用されているため、既存の専門知識や技術、ドキュメント、第三者サポートを活用できます。
Kubernetes では Docker コンテナが使用されます。Docker は、特定のベンダーに関わりのない、アプリケーション パッケージに関する業界採用標準です。Kubernetes 自体は、Cloud Native Computing Foundation によって管理されているオープンソースのサービスです。
Google Kubernetes Engine（GKE）などのマネージド Kubernetes プラットフォームを使用することで、Kubernetes のインストールや操作を行う必要がなくなるため、運用スタッフはインフラストラクチャではなくアプリケーションに集中できるようになります。次の図は、マネージド Kubernetes プラットフォームを示しています。
ワークロードのポータビリティの制限
ワークロードのポータビリティを向上させるために、Kubernetes には抽象化レイヤが用意されています。このレイヤが存在することで、コンピューティング環境の複雑で細かい内容やコンピューティング環境間の相違点が覆い隠されます。ただし、こうした抽象化にも制限があります。
アプリケーションはほとんど変更を行わずに別の環境に移植できますが、アプリケーションが両方の環境で同じパフォーマンスを示すとは限りません。基盤にあるコンピューティング インフラストラクチャやネットワーキング インフラストラクチャの違いと、依存関係のあるサービスとの近接性によって、パフォーマンスが大幅に変わる可能性があります。
コンピューティング環境間でワークロードを移動すると、データの移行も必要になることがあります。コンピューティング環境間でデータのコピーや移動に時間、労力、予算が必要になるだけでなく、データを保存、管理するためのサービスや機能も環境間で異なる場合があります。
Kubernetes では、種類の異なるロードバランサが一元的にプロビジョニングされます。こうしたロードバランサの動作は詳しく定義されておらず、環境ごとに少しずつ異なる場合があります。
GKE では役割ベースのアクセス制御（RBAC）が Identity and Access Management と統合されますが、他の環境では、RBAC を構成する方法とワークロードを保護する方法が異なる場合があります。
Kubernetes を使用する場合でも、コンピューティング環境間やパブリック クラウド間の相違点を解消するのは容易ではありません。ワークロードのポータビリティの本来の目的は環境間での移行を簡単にすることであり、移行を自動化することではありません。
ワークロードの評価
進行中の新しいプロジェクトがある場合や、すでに稼働中のワークロードが数百、場合によっては数千もある場合、どのワークロードをどのコンピューティング環境にデプロイまたは移行するかを決めるのは困難な作業です。
この決定を矛盾なく客観的に行うために、適時性、リスク、技術的な難しさという項目別にワークロードを分類し、スコアを付けることを検討してください。
移行の適時性を評価するには、次の要素を確認してください。
- クラウド サービスを使用して可能になる市場での差別化やイノベーションの可能性
- アプリケーションの総所有コストの節減の可能性
- 可用性、復元力、セキュリティ、パフォーマンスの改善の可能性
- 開発とリリースのプロセスの迅速化の可能性
移行のリスクを評価するには、次の要素を確認してください。
- 移行そのものが原因で起こる障害や、当初はパブリック クラウドへのデプロイに関するユーザーの経験が浅いことが原因で起こる障害による影響の可能性
- 既存の法律上または規制上の制限に従う必要性
移行の技術的な難しさを評価するには、次の要素を確認してください。
- アプリケーションのサイズ、複雑さの程度、経過期間
- 他のアプリケーションとの間の依存関係の数
- 第三者ライセンスによって課されている制限
- オペレーティング システム、データベースやその他の環境構成の特定のバージョンに対する依存の有無
初期ワークロードを評価したら、ワークロードの優先順位付けと、適切なアーキテクチャ パターンとネットワーク トポロジの特定を開始できます。必要に応じて、この手順を何回か繰り返します。時間がたつと評価が変わる可能性があるため、最初にクラウドへのデプロイを行った後にワークロードを再評価することも必要です。
次のステップ
- Google Cloud への移行を開始する方法について学ぶ。
- ハイブリッド クラウドとマルチクラウドの一般的なアーキテクチャ パターン、そのパターンに最適なシナリオとその適用方法について学ぶ。
- ハイブリッド クラウドとマルチクラウド用のネットワーク トポロジと、その実装方法について学ぶ。
- VM を Compute Engine に移行する場合のおすすめの方法に関する説明を読む。
- ワークロードを Google Cloud に移行する際に Google のパートナーからどのような支援を受けられるかを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center をご覧ください。