ハイブリッドクラウド・アーキテクチャーの設計方法

近年のハイブリッドクラウド・アプローチでは、一部のサービスをオンプレミス・インフラストラクチャーからパブリッククラウドまたはプライベートクラウドに移行することが一般的で、これらのサービスは相互に通信します。新しいアプリケーションがパブリッククラウドでホストされるように構築された場合でも、従来のサービス指向アーキテクチャー（SOA）に準拠していました。

しかし現在では、マイクロサービス・ベースのアーキテクチャーがハイブリッドクラウド・モデルの中核をなしています。マイクロサービスとは、アプリケーションを小さなコンポーネントまたはサービスに分割して簡単にデプロイメントできるようにするアプローチです。これらのマイクロサービスは、独自の技術スタックを持ち、マイクロサービスとその依存ライブラリーを含む軽量の実行可能ファイルであるコンテナにデプロイされているという点で、SOAのサービスとは異なります。

コンテナはマシンのオペレーティング・システム（OS）カーネルを共有するため軽量であり、各コンテナにはマイクロサービスとその依存関係のみが保持されます。すべてのOSの依存関係は、コンテナが存在するハードウェアから共有されます。この仮想化により、マイクロサービスをオンプレミスまたはクラウド環境に独立してデプロイできるようになります。また、マイクロサービスはその自己完結性によってSOAとは大きく異なるもので、クラウド・リソースを最適化するための弾力性と柔軟性が最も重要となるクラウド・デプロイメントにより適しています。

あらゆる環境でプロセスを分離するためのパッケージ・モデルとしてのコンテナ化は、新しい概念ではありませんが、2013年にコンテナ・エンジンとしてDockerが登場したことで、汎用的なパッケージ構造が生まれました。さらに、Kubernetesのようなコンテナ・オーケストレーション・プラットフォームは、ハイブリッドクラウド環境全体にわたってDockerやOpen Container Initiative（OCI）標準に準拠するその他のコンテナのデプロイメントを自動化します。

コンテナ化の出現により、ハイブリッドクラウドのメリットを真に活用できるようになり、ワークロードの容易な移植性と、選択したクラウド環境でのサービスの自動デプロイメントに焦点が移りました。

数年前、ハイブリッドクラウド・アーキテクチャーに関する議論では、各ワークロードをどのクラウド環境またはオンプレミス環境で実行すべきか、そしてこれらの異なる環境を相互に通信させるにはどうすればよいかが、話題の中心でした。基本的には、ホスティングの場所と物理的な接続が依然として大きな考慮事項でした。

例えば、機密データを扱うアプリケーションはプライベートクラウド上でホストされます。あるいは、モダナイズが困難なレガシー・アプリはオンプレミスに存在し続けることになります。一方、組織は拡張性を必要とするアプリをパブリッククラウド環境にリフト・アンド・シフトします。次に、仮想プライベート・ネットワーク（VPN）トンネルやメッセージ・ストリームなどのチャネルを確立し、環境間の通信を促進します。

これらは依然として考慮すべき重要な要素ですが、コンテナ化のパラダイムにより、焦点は物理的な場所と接続から、ある環境から別の環境にワークロードをシームレスに移動する柔軟性に移行しました。したがって、アプリケーションをプライベートクラウドでホストするかパブリッククラウドでホストするかは、厳格に決定する必要はありません。この戦略が機能しない場合、コンテナとしてパッケージ化されたワークロードを環境間で移動したり、スケールアップやスケールダウンしたり、異なる環境で同じサービスのインスタンスを実行したりすることも簡単です。

こうしたすべての結果、高い性能、リソース効率、コスト削減を実現する、最新の可用性と柔軟性に優れたアーキテクチャーが実現しました。

ハイブリッドクラウド・アーキテクチャーの設計と実装では、企業のビジネス目標、現在の技術的環境、デジタル・トランスフォーメーションの目標、セキュリティーの考慮事項など、多くの要因を考慮する必要があります。複数のハイブリッドクラウド・ソリューションを備えたこのようなアーキテクチャーはすぐに複雑になる可能性があるため、運用ツールを活用して、一元化されたシームレスでスケーラブルなクラウド管理を実現することが重要です。ここでは、ハイブリッドクラウド戦略を策定する際に考慮すべき要素をいくつか紹介します。

モダナイゼーション戦略

ほとんどの組織にとって、ハイブリッドクラウド・コンピューティングのアイデアは、アプリケーションのモダナイゼーション、つまりオンプレミスからクラウドへの移行から始まります。これを実行するにはいくつかの方法があります。

• リフトアンドシフト：モダナイゼーションを開始するための最も一般的な方法の1つであるリフトアンドシフトでは、完全なアプリケーションをオフプレミスからクラウド環境に移動することになります。これには、安全でスケーラブルなクラウド・コンピューティング・リソースとインフラストラクチャー・サービスを活用するために、基盤となるハードウェアを変更することが含まれます。これは、リファクタリングや再設計の時間がない場合に便利なオプションです。
• リファクタリング：クラウドにアプリケーション全体を移行するよりも（時間がかかるだけでなく、必要ない場合もあります）、1つまたは2つのサービス（コンプライアンスや緊急のパフォーマンス改善の必要がないもの）を特定し、それらをリファクタリングし（例えば、以前のサービス・インターフェースは特定のプラットフォームに緊密に結合されている可能性があるため、グルーコードを追加してREST APIを公開する）、クラウドにデプロイする方がよいでしょう。この段階的な動きにより、テストと学習の機会のために少量のトラフィックをクラウド上の新しいインスタンスにルーティングし、最終的にはサービスのすべてのインスタンスをクラウドに移行する機会が得られます。
• 再設計：最後に、すべてのシステム・コンポーネントを、モジュール化され本番環境への独立したパスを持つ単一責任のマイクロサービスに分割し、それらをコンテナ化するという最も洗練されたアプローチがあります。これには完全な書き換えが必要であり費用のかかるプロセスですが、恩恵も最大化します。

一元化されたコントロール・プレーン

エンタープライズ運用チームは、環境全体で一貫性のあるクラウド運用エクスペリエンスを提供する統合コントロール・プレーンを通じてクラウド環境を管理します。これは、ワークロードのスケジュール作成とオーケストレーション、継続的インテグレーションとデプロイメント（CI/CD）パイプライン、ロギング、テレメトリー、フェデレーション・セキュリティーなどのコア・クラスター管理機能をサポートします。

目標は、個々のクラウド・サービス・プロバイダー（CSP）とランタイムの基盤となる複雑さをアプリケーション・チームから抽象化し、運用チームが企業内のワークロードを管理するための共通のインターフェースを提供することです。

統合コントロール・プレーンの利点のいくつかを次に示します。

• 仮想マシン、コンテナ、またはサーバーレス・デプロイメント全体で動的なワークロード配置戦略を活用します。
• 最小限の労力で追加のプロバイダーやエッジ・ロケーションをオンボーディングできる機能を活用できます。
• 可用性が高く、さまざまなクラウド実装で機能するFunction-as-a-Service（FaaS）などのPaaS機能を構築します。
• コンプライアンス管理を一元化します。

APIゲートウェイとサービス・メッシュ

集中型APIゲートウェイやサービス・メッシュなどのアーキテクチャー・パターンにより、ルーティング、サービス間通信、セキュリティー、レート制限、オブザーバビリティーなどのクラウド機能を透過的に管理できるようになります。

APIゲートウェイは、すべてのリージョンにまたがる統一されたフロント・ドアとして機能し、以下を含む「North-South」トラフィック機能を処理します。

• ユーザー認証と承認
• スロットルとレート制限
• トラフィック管理
• APIライフサイクル管理
• クラウド・セキュリティー・ガードレール
• Edge分析

一方、サービス・メッシュは、サービス依存関係間の「East-West」トラフィックを処理します。

• クラスター内の安全なサービス間通信
• ロード・バランシング、ルーティング・ルール、再試行、フェイルオーバー、災害復旧、フォールト・インジェクションによるトラフィック管理
• クラスターのエグレスとイングレスを含むクラスター内のすべてのトラフィックのメトリクス、ログ、トレースを含むテレメトリー
• サービス境界を越えたリクエストのフローを計測するための分散トレーサビリティー
• サービスの自動検出

例えば、Istioは、クラウド管理者によって提供される定義済みの構成に従ってサービス間の通信を制御する、オープンソースのサービスメッシュ・レイヤーです。Kubernetesオーケストレーション層のサイドカーとして機能し、プログラマーや管理者には見えない形でコンテナと連携して動作します。

セキュリティー

ハイブリッドクラウド・アーキテクチャーの複雑さには、エンドツーエンドのセキュリティーと保護を確保するために、さまざまな層での多層アプローチが必要です。

IBM Cloud、Amazon Web Services（AWS）、Microsoft Azure、Google CloudなどのCSPは、サービス・レベル契約（SLA）ごとに、境界層でのすべての呼び出しを認証・承認する責任を負い、エンタープライズ・アプリケーションの周囲にファイアウォールを構築します。これには、サービス拒否からの保護や、一般データ保護規則（GDPR）や医療保険の相互運用性と説明責任に関する法律（HIPAA法）などのプライバシー規制の遵守が含まれます。

オンプレミスのインフラストラクチャーでは、すべてのAPIエンドポイントを保護するAPIゲートウェイを使用して境界セキュリティーを実現できます。データセンターの外にあるWebサービスまたはモバイル・アプリケーションからの呼び出しはすべて、APIゲートウェイを介して検証およびルーティングする必要があります。

クラウド・コンピューティング環境には、サービス・メッシュで定義された制御ポリシーと、オーケストレーション・プラットフォームによって公開されるAPIの形で、追加のセキュリティー層が含まれています。これらのポリシーにより、安全な呼び出しのみがKubernetesノードに転送され、さらにそこからマイクロサービスに転送されるようになります。

また、環境を異なる論理セキュリティー・セグメントに分割して、各サービスとワークロードのアクセス制御ポリシーを定義するマイクロ・セグメンテーションの概念を使用して、環境内で実行されるサービス間のセキュリティー・レベルを構築し、区切ることができます。最後に、暗号化ポリシーは、追加のデータ保護層として機能します。

ネットワーク接続

単一のクラウド・リージョンでは、アベイラビリティー・ゾーンにはネットワーク内のすべてのノードを接続する専用のファイバー・ネットワークがあるため、企業は帯域幅が無制限でネットワークレイテンシーが低い高可用性アーキテクチャーを構築できます。ただし、リージョン間や複数のクラウド・プロバイダー間の通信はパブリック・インターネットを介してルーティングされるため、高遅延と潜在的な障害という代償を伴います。

ハイブリッドクラウド・アーキテクチャーでは、基盤となるプロバイダー間でのデータ交換には次の3つのパターンがあります。

• インターネット経由のパブリックIPアドレス（共有帯域幅による高遅延）
• VPNなどのマネージド・サービス（セキュリティーが高く、レイテンシーが予測可能）
• 共通のポイント・オブ・プレゼンス（POP）を介した専用相互接続（CSPが提供する高価なオプションだが、最大限のセキュリティーで遅延を最小化）

これらのオプションは転送速度、レイテンシー、信頼性、SLA、複雑さ、料金体系の点で異なるため、ネットワーク接続層を設計する前に制約とメリットを比較検討することが重要です。

開発プラットフォームにおけるオープンソースへのバイアス

ハイブリッドクラウドとは、ワークロードをある環境から別の環境に移行でき、任意のクラウド上で動作するアプリケーション開発プラットフォームを利用できることを意味します。真にクラウドネイティブであるためには、特定のテクノロジー、プラットフォーム、さらにはCSPに強く依存することなく、企業が市場の変化に柔軟に対応できる必要があります。

オープンソース・アーキテクチャーによってこの統一された開発アプローチが可能になり、その実装に使用されるテクノロジーに関係なく、開発者が基盤となるインフラストラクチャーを管理できるようになります。オープンソースはもはや、費用対効果のためにそれを使用するニッチで独占的なオーディエンスが存在するわけではありません。その豊富な機能と品質、コミュニティー・ベースの開発により、現在では主流となり、中心的な役割を担っています。

Red Hatの「The State of Enterprise Open Source」レポートによると、セキュリティーのような繊細な分野においても、オープンソース・ソフトウェアは優れた選択肢として認識されています。企業がオープンソースに対して意識的なバイアスを示す最大の理由は、クラウドネイティブ・アーキテクチャーのセキュリティー、品質、サポートです。

詳細については、JJ Asghar氏の記事「Cultivating Careers, Communities and Companies with Open Source（オープンソースでのキャリア、コミュニティー、企業の育成）」をご覧ください。

IBM Cloud ハイブリッド・クラウド・ソリューションは、アプリケーションとデータの両方に柔軟性と移植性を提供します。Linux、Kubernetes、コンテナはハイブリッドクラウドスタックをサポートし、Red Hat OpenShift と組み合わせることで、オンプレミスとクラウドのリソースを接続する共通のプラットフォームを構築できます。

IBM Cloudで構築されたハイブリッドクラウド・ソリューションの詳細をご覧ください。

独自のハイブリッドクラウド・ソリューションの構築を開始するには、IBMidにサインアップしてIBM Cloudアカウントを作成してください。