ハイブリッドクラウドアーキテクチャモデルを1つの記事で解説

クラウド アーキテクチャについて話すとき、通常はクラウド プラットフォーム自体のアーキテクチャではなく、クラウド プラットフォームに基づくソフトウェア システム インフラストラクチャを指します。クラウド プラットフォーム独自のアーキテクチャは、オブジェクト ストレージ、エラスティック ホスト、仮想ネットワークなど、クラウド サービス プロバイダーのエンジニアだけが関与する多くの共通要件を満たしています。一般企業のエンジニアにとって、クラウド サービスのさまざまな利点を考慮すると、クラウド プラットフォーム、特にクラウド アーキテクチャの重要な要素であるハイブリッド クラウド インフラストラクチャに基づくソフトウェア システムの構築は仕事の 1 つです。

パブリッククラウドとプライベートクラウドの統合、または複数のパブリッククラウドのハイブリッド環境のいずれであっても、そのインフラストラクチャモードは、分散展開モードと冗長展開モードの 2 種類に分けられます。適切なアーキテクチャを決定する際に考慮すべき、変更に対する俊敏性、スケーラビリティ、ネットワーク トポロジの選択、セキュリティ、信頼性という 5 つの相互に関連する側面があります。

分散展開モード

これらのパターンは、クラウド サービスの特定の機能、プロパティ、または機能を活用する必要がある場合に最も役立ちます。

レイヤーブレンドモード

従来の階層化は通常、フロントエンド アプリケーションとバックエンド アプリケーションで構成されます。フロントエンドは、エンドユーザー/クライアント、消費者、またはそれらの組み合わせを扱います。通常、フロントエンドはステートレスであり、その場合、予測不可能なワークロードを処理するにはパフォーマンスと柔軟性が非常に重要です。さらに、通常は多くの変化に対処する必要があり、アジャイル思考の恩恵を受けることができます。バックエンドは規制要件に従ってデータを安全に保存し、変更頻度を低くする必要があります。

このアーキテクチャ パターンの背後にある考え方は、各アプリケーションを移行する際に、最初に複雑度の低いアプリケーションを選択し、次に 1 つずつ進めていくというものです。一般的に、クラウド移行戦略には、ホスト更新、プラットフォーム更新、再購入、再構築、保持、サービスの停止という、一般に「6R」と呼ばれる 6 つの戦略があります。したがって、それぞれのケースごとにアーキテクチャ上の決定を行う必要があります。移行後、セキュリティ、レート制限、API ポリシーなどの横断的な問題に重点を置いた API ゲートウェイを介してバックエンドにアクセスします。

これは、移行プロセスの途中で、会社がすべてを一度に完了することを約束できない場合に適したモデルです。これは、状況が非常に単純な場合を除き、常に当てはまります。

パーティション化されたマルチクラウドモデル

移植性が懸念される場合、このモデルでは、ワークロードをあるクラウド プラットフォームから別のクラウド プラットフォームに移動する機能が提供されます。このモデルの利点は、リスクが固定されて軽減され、各ベンダーから最適な機能を選択でき、ガバナンスが完了することです。

複数のクラウド環境間でワークロードの移植性と一貫性を実現するツールにより、開発、テスト、運用の労力が軽減されます。移植性にはコストがかかり、移植性を最大限に高めるためには、コンテナと K8S が一般的に検討されます。

クラウド分析モード

一般的に言えば、エンタープライズ アーキテクチャは通常、トランザクション システムと分析システムで構成されます。トランザクション システムは、財務、販売、在庫、価格設定などの日常業務を実行するために使用されますが、分析システムは、性質や変化の速度が異なるため、通常は他のシステムから切り離されています。

このパターンの中心的な考え方は、分析ワークロードをクラウドに配置し、必要に応じてデータをフィードバックすることです。クラウド ストレージはデータ レイクを使用して実装でき、トラフィックは BOS を通じて導入できます。

エッジクラウドハイブリッドモード

場合によっては、車両間の接続性など、ビジネスが接続性に 100% 依存できないことがあります。また、工場の可用性サービス レベルがオンサイト リンクの能力を超えている場合や、ショップが重要なトランザクションを処理する必要があり、リンクのダウンタイムが許容されない場合もあります。

エッジ クラウド ハイブリッド モデルは、時間に敏感でビジネス クリティカルなワークロードをネットワークのエッジでローカルに実行し、他のすべての種類のワークロードをクラウドで処理することで、これらの課題に対処します。エッジクラウド ハイブリッド モデル セットアップでは、インターネット接続は、管理目的と、通常は非同期でデータの同期またはアップロードにのみ使用される非クリティカルなコンポーネントですが、時間に敏感なトランザクションやビジネス クリティカルなトランザクションは含まれません。

さらに、エッジ環境とクラウド間で CI/CD プラクティスの一貫性を保つことが賢明です。

冗長展開モード

これらのパターンは、全体的なアーキテクチャに容量や回復力を追加する必要がある場合に役立ちます。

混合環境モード

このモデルでは、開発、テスト、UAT にパブリック クラウド環境が使用され、運用環境にプライベート クラウドが使用されます。このアーキテクチャを使用する理由としては、通常、規制上の制限や、クラウドでの運用ワークロードを妨げるサードパーティ ライセンスの使用などが挙げられます。このパターンは、最初に下位の環境を置き換えたい場合や、必要に応じて環境を簡単に作成およびシャットダウンしたい場合に適しています。

すべての環境は機能的に同等です。つまり、アーキテクチャ、API、オペレーティング システムとライブラリのバージョンは同等であり、システムは環境間で同じように動作します。ただし、パフォーマンス テストはローカルで実装する必要があります。

ビジネス継続性ハイブリッドモデル

このモデルでは、DR 環境がクラウドに実装され、DR 環境の作成とシャットダウンが可能になるというコスト効率が実現されます。さらに、災害復旧が発生した際に、IaaS を利用することで災害復旧環境をより迅速に構築できるため、実際の復旧時間を短縮できます。

もう 1 つの選択肢は、実稼働環境を 1 つのプログラムに配置し、別のプログラムにフェールオーバーすることですが、可用性の要件は通常 1 つのプログラムで達成できるため、このアプローチはあまり一般的ではありません。

ビジネス爆発のためのハイブリッドクラウドモデル

このパターンは、アプリケーションのワークロードが突然予測不能に増加し、ほとんどの場合、集中的なワークロードの特定の期間に過剰なサービスを提供したくない場合に選択できます。これは、スケールアップおよびスケールダウンが可能なフロントエンドのステートレス アプリケーションに特に適しています。

ビジネス バースト用のハイブリッド クラウド モデルでは、ベースライン ロードにプライベート コンピューティング環境を使用し、追加の容量が必要になったときに一時的にクラウドにバーストします。このモデルにより、基礎となる内部投資が維持され、年間を通じて追加の容量を維持する必要がなくなります。

まとめ

これらのハイブリッド クラウド アーキテクチャ パターンに関する決定は複雑であり、多くの場合、さまざまなレベルの懸念を伴う複数の異なるシナリオが関係し、それぞれに包括的なトレードオフ分析が必要であり、複数のパターンを使用してエンタープライズ ソリューションを実装する可能性もあります。

それで -

ハイブリッド クラウドのアーキテクチャ上の決定をどのように行うのでしょうか?

建築の持続可能性を維持するにはどうすればよいでしょうか?