クラウドアーキテクチャのSLAの簡単な分析

[[318684]]

クラウド サービスによりエンタープライズ アプリケーションのアーキテクチャが再形成され、パブリック クラウドはエンタープライズ アプリケーション、プラットフォーム ソフトウェア、およびサービスを統合するための設計センターになりました。 API 駆動型のオンデマンド リソース割り当ては、従来のエンタープライズ データ センター インフラストラクチャとは大きく異なります。エンタープライズ アプリケーションは、クラウド サービスにエンタープライズ属性とサービス レベルを追加しながら、クラウド サービスのアーキテクチャ設計に適応する必要があります。

[[318685]]

これまで、エンタープライズ アプリケーションの主流のアーキテクチャは、専用のデータ センターに構築され、エンタープライズ アプリケーションに保証されたサービス レベルを提供するように設計されたシステムでした。これは、アプリケーションとサービスが分散システムとして仮想化されたリソース上に構築されるため、パブリック クラウドのマルチテナント アーキテクチャとはまったく異なります。一部の IT 部門にとって、クラウド サービスは、企業の財務監査のトラブルを回避するための手段にすぎません。

多くの大企業がクラウド サービスを活用して、弾力性と効率性に優れたアプリケーションを提供することに成功していますが、エンタープライズ アプリケーションでパブリック クラウドを使用できるようにするのは、依然として容易ではありません。柔軟性と自動化により、IT 運用を簡素化できます。クラウド サービスは、財務分析、ERP システム、サプライ チェーン管理などのビジネス レベルのアプリケーションをサポートできる、高性能なエンタープライズ レベルのプラットフォームになる必要があります。

[[318686]]

クラウド サービスにおけるエンタープライズ アプリケーション SLA の課題

エンタープライズ アプリケーションには、高可用性、セキュリティ、信頼性、パフォーマンスなどの属性を備えた追加のビジネス環境が必要であり、これらは新しいアプリケーションと古いアプリケーションの両方に適用されます。たとえば、データ セキュリティは、規制上またはビジネス上の理由で重要になる場合があります。データの整合性が侵害されると、ビジネス上の意思決定や財務結果が不正確になり、企業が実際の金銭的損失を被ったり、市場価値の損失につながる可能性があります。

SLA は、通常、プロバイダーと消費者の間の契約の形式をとるエンタープライズ サービス要件であり、遵守しない場合は罰則が科せられます。具体的かつ測定可能な SLO は、SLA が満たされているかどうかをテストするために使用される単一のメトリックです。ここで、クラウド サービスとは、アプリケーションやサービスを展開するためのプラットフォームを指します。多くの IaaS および PaaS プロバイダーがクラウド サービスを提供しています。クラウド サービスには通常、オンデマンド セルフサービス、WAN アクセス、リソース プーリング、迅速な弾力性などが含まれます。クラウド サービスによって提供されるサービス レベルと企業が期待するサービス レベルの間には、一般的にギャップがあります。多くのクラウド サービスの SLA は通常 99.95% ～ 99.99% であり、パフォーマンスは保証されません。

信頼性と可用性

エンタープライズ レベルのアプリケーション SLA の可用性を実現することは、技術的な課題となる場合があります。たとえば、重要なビジネスでは、年間 5 分を超えるダウンタイムは許容されず、99.999% の可用性が求められる場合があります。対照的に、クラウド サービスのリソース経済性では、予想される障害率が比較的高くなる可能性があります。たとえば、AWS の EBS サービスの障害率は年間約 0.1% ～ 0.5% であり、これは障害率が年間 1/200 に達する可能性があることを意味します。

重要なビジネスでは、一般的に、データの不整合やデータの破損に対する許容度が低くなります。多くのエンタープライズ アプリケーションでは、パフォーマンスと可用性を最適化するために、「最終的な一貫性」アーキテクチャを使用して再実装する必要がある場合があります。ビジネス リスクやペナルティが十分に高い場合、一部のエンタープライズ アプリケーションでは、誤った結果をもたらすよりも、ダウンタイムやデータ損失を優先します。可用性が十分に厳しい場合、ソフトウェアに迅速な回復を求める圧力がかかります。

クラウド サービスでは、高可用性を実現するために、通常の操作として「障害を考慮した設計」を推奨しています。これには、RAID が信頼性の低い物理メディアを補うのと同様に、信頼性の低いインフラストラクチャを補うフォールト トレラント ソフトウェアが必要です。信頼性と可用性はソフトウェアの問題になっています。おそらく、これは堅牢なソフトウェアを構築する機会です。

パフォーマンス

エンタープライズ アプリケーションのパフォーマンス要件はさまざまです。エンドユーザー向けのアプリケーションは、特定の応答時間に合わせて管理される場合があります。 ERP や財務分析などのビジネス クリティカルなアプリケーションでは、応答時間とスループット指向の SLO の両方を管理して、オーバーナイト取引戦略の最適化などの特定のビジネス目標をサポートできます。

クラウド サービスでは、マルチテナントの副産物として多くのパフォーマンス上の課題が発生します。実際には、物理​​リソースはキューイング システムになります。つまり、マルチテナント クラウド ファシリティのオーバーサブスクライブにより、パフォーマンスが大幅に変動する可能性があります。ストレージのパフォーマンスであれ、ネットワーク帯域幅であれ、「うるさい隣人」が存在する可能性があります。計算のオーバーサブスクリプションも IO レイテンシに悪影響を与える可能性があり、パフォーマンスとコストの間にはトレードオフがあります。マルチテナントにより、物理インフラストラクチャの利用率が向上し、クラウド サービスのコストが最適化されますが、共有物理リソースのパフォーマンスを可能な限り低い固定コストで保証することはできません。オーバーサブスクライブされた物理リソースのパフォーマンスはランダムに変動する可能性がありますが、静的な物理リソースのパフォーマンスは保証されますが、コストが高くなります。

パフォーマンスを保証するには、クラウド サービスで仮想リソースを柔軟に使用することが必須であり、パフォーマンス目標を達成するには分散システムを積極的に管理する必要があります。

[[318687]]

安全

セキュリティ要件は、エンタープライズ アプリケーションの種類によって異なります。アプリケーションまたはデータのビジネス価値が高くなるほど、セキュリティ要件は厳しくなります。 DDOS や「データ漏洩」を回避するだけでなく、単一のシステムだけでは完全に安全ではないため、複数レベルのセキュリティ制御を実装する必要があります。

企業のセキュリティの観点から見ると、クラウドは興味深い環境です。一方で、マルチテナントは新しい、そして心配な環境であると考えられています。一方、ワークロード全体に実装された論理的なセキュリティ制御と自動化されたポリシー管理により、セキュリティを強化する機会が提供されます。論理制御は、物理制御よりも柔軟性、監査性、強制性に優れています。ネットワーク アクセス制御ルールは、仮想マシンに直接適用し、論理パーティションを動的にプロビジョニングし、ワークロード内のリソースにぴったり合うようにスケールダウンし、ワークロードの移動に合わせて論理パーティションを移動できる論理制御の典型的な例です。

クラウド サービスには、新しいセキュリティ ツールと技術、および従来のセキュリティ技術の再考が必要であり、セキュリティ SLO をプログラムで表現する必要がある場合があります。ユーザー、アプリケーション、データ中心の探索は、より高いレベルのセキュリティ SLA を達成するための課題です。

[[318688]]

エンタープライズアプリケーションのクラウドサービスへの適応性

エンタープライズ クラスのデータ センターは通常、事前に決められた一連のユース ケースに合わせて最適化されています。専用システムは、ハードウェア アプライアンス、バックアップ システム、プライベート クラウドなど、固定価格のコストとパフォーマンスを備えた事前統合されたコンポーネントを通じて、特定のサービス レベルを提供します。ベンダーは、ハードウェア コンポーネントとソフトウェア コンポーネントを垂直に統合して、サービス レベルの属性 (I/O レート、物理リソース構成、障害分離など) を提供します。ベンダーの導入とパフォーマンスおよび信頼性のベストプラクティスを組み合わせることで、より高いレベルの SLA を満たすことができます。

専用システムでは、高帯域幅のノード間通信が必要であり、非常に高いパフォーマンス レベルが提供されます。企業は特定のユースケースに対して追加料金を支払う場合があります。

静的統合と動的配布

確かに、専用システムとパブリッククラウド間のハードウェアのギャップは縮まっています。クラウド サービスでは、大規模な導入と運用に適したハードウェア設計が採用されており、仮想マシン リソースを適切なサイズに設定すると、単純なスケーラビリティの問題、ノード間のデータ移動コストの削減、価格/パフォーマンス/電力効率などの実用的なメリットがあるため、この傾向は今後も続くと思われます。また、一部のクラウド サービス プロバイダーは、特定のサービス レベルの専用システムも提供しています。

クラウド サービスは動的かつ分散型ですが、専用システムは静的かつ統合型です。仮想化されたリソースは、自動化、コスト、スケールに合わせて最適化されており、プラットフォームとハードウェアの抽象化レイヤーも備えています。どの仮想リソースが同じパフォーマンスおよび障害ドメインにあるかを把握せずにサービス レベルを保証することは難しいため、抽象化は高レベルの SLA を提供する上で課題となります。

エンタープライズ インフラストラクチャには変革の機会があります。高可用性の分散システムを実装するという困難な作業では、アプリケーションはコンポーネント障害に対して耐性を持つようになり、高可用性インフラストラクチャの必要性は時間の経過とともに減少します。 SLA はクラウド サービス上のソフトウェアで提供され、エンタープライズ アプリケーションにエンタープライズ属性とサービス レベルを提供します。

[[318689]]

クラウド サービス上のエンタープライズ アプリケーションの SLA

クラウド サービスのオンデマンド リソースは、企業のニーズに応じて実質的に無制限です。公表されることはほとんどありませんが、控えめな見積もりでは、単一のパブリック クラウド内のサーバーの数は数十万に上り、急速に増加しています。これは、数万台のサーバーを備えた大規模な企業データセンターよりも 1 桁または 2 桁大きい規模です。大規模な Web サイトの何百万ものエンド ユーザーと比較すると、エンタープライズ ビジネス、バッチ処理、または分析アプリケーションでは、50,000 人のエンド ユーザーというのは大きな数です。

クラウド サービスは、今日のエンタープライズ アプリケーションとインフラストラクチャのアーキテクチャを根本的に変えました。リソースは固定されなくなり、エンタープライズ アプリケーションに追加の CPU と RAM も提供されるようになりました。リソースは予算によってのみ制限されます。

クラウド サービスでは限定的な SLA が提供されますが、通常、パフォーマンス、回復力、可用性、コストなどのアプリケーション特性に関する保証を提供するには、アプリケーションおよびプラットフォーム ソフトウェアが必要です。マルチテナントに関しては、任意の障害を許容し、独自の SLA を実装するように設計する必要があります。

ソフトウェアがすべてを定義しました。

ソフトウェア定義のSLA

ソフトウェア定義の SLA は、クラウド サービス ソフトウェア コンポーネントの構成可能なパラメーターとして SLA と SLO を形式化する新しい設計パターンを提供する潜在的なソリューションになる可能性があります。これらのコンポーネントは、特定の SLO 要件を満たすために基盤となるリソースを管理します。オンデマンド リソースを使用すると、以前は計画、静的パーティショニング、およびオーバープロビジョニングが必要だった特定の SLO をシステム レベルで満たすことが可能になります。最後に、クラウド サービス API には、ランタイム構成としてソフトウェア定義の SLA が組み込まれています。

ソフトウェア定義の SLA では、応答時間、I/O スループット、可用性などの基本的なサービス レベルのメトリックを指定できるほか、地理的な分散や負荷制約などの抽象的だが測定可能な属性も指定できます。ソフトウェア定義の SLA は、ベンダーやテクノロジーに依存せず、論理単位で指定され、客観的に測定可能である必要があります。

可能な実装

実行時に構成可能な SLO 拡張、高可用性とフォールト トレランス、コンピューティング能力と I/O リソースのオンデマンド割り当てを実現するには、ソフトウェア定義の SLA をクラウド サービスに実装する必要があります。

分散システム開発の課題を考慮すると、ソフトウェア定義の SLA に万能のアプローチが採用される可能性は低いでしょう。さまざまなプログラム SLO をアプリケーション サービスとプラットフォーム コンポーネントに実装できます。特定のアプリケーションのコンテキストによって、特定のユースケースに適したコンポーネントが決まります。クラウド サービスとエンタープライズ アプリケーションはどちらも動的なターゲットであるため、クラウド サービスによって提供される属性とエンタープライズ アプリケーションによって提供される属性、およびその間のソフトウェア コンポーネントとサービスが反復される可能性があります。

ランタイム再構成は非常に困難です。 QoS 技術は必要ですが、それだけでは十分ではありません。変化する環境条件下で SLO を満たすには、RAM、CPU、およびストレージ リソースを動的にプロビジョニングする必要があります。ただし、ソフトウェア定義の SLA の価値は、多大なエンジニアリングの労力とコストを正当化します。パフォーマンスとデータの可用性を考慮する場合、コンピューティング能力とデータ ストレージの構成を考慮する必要があります。これにより、マルチテナント ネットワークに関連するパフォーマンスの問題の一部を軽減できます。

タグを使用すると、一般的にリソースを識別したり、特にセキュリティ SLO を実装したりできます。ホストベースの仮想ネットワークと OpenFlow により、ネットワーク フロー内のユーザーとグループにタグを付ける機会が増えます。セキュリティ SLO は、ユーザー タグとグループ タグをアクセス制御に関連付けることで実現できます。同様に、ストレージ サービス メタデータ内のデータセットのタグ付けは、データ関連の SLO (データ可用性、レプリケーション、アクセス制御、暗号化キー管理ポリシーなど) の実装に役立ちます。

コスト最適化

プライベート クラウド テクノロジーの場合でも、サービス レベルを保証するための標準的なアプローチは、依然としてオーバープロビジョニングです。専用システムの全コストは、SLA や時間の経過とともに増加するオーバープロビジョニングのオーバーヘッドを含めて、前払いする必要があります。パブリック クラウド サービスのリソースは必要に応じて割り当ておよび解放できるため、実際の使用量に基づいて課金できます。これは、変動するワークロードの運用効率の点で、パブリック クラウド サービスが専用システムを上回るチャンスです。

異なる SLO を達成するにはさまざまなリソースが必要になる可能性があるため、ソフトウェア定義の SLA はコスト関数に関連付けられます。基本的な条件が変化すると (予測できないマルチテナント リソースなど)、他のすべての SLO が固定されていても、コストはランダム変数になります。

ソフトウェア定義SLAの制限

ソフトウェア定義の SLA には、理論上も実践上も制限がある場合があります。コストは常に管理する必要があるシステムレベルのパラメータであるため、一部の組み合わせは機能しない可能性があります。コストが無限であっても、一部の SLO は物理的に達成不可能な場合があります。さらに、設計が不十分なクラウド サービスは、ソフトウェア定義の SLA に適さない可能性があります。

動的リソース管理の領域では、物理属性を個々の消費可能な単位に分解できます。たとえば、コンピューティング リソースは I/O から独立し、I/O スループットは容量から独立し、CPU と RAM は互いに独立することができます。これにより、専用システムの垂直統合の利点が損なわれます。

パブリック クラウド サービスは根本的な経済的変化をもたらします。価格/パフォーマンス メトリックでは、ワークロードと稼働時間を考慮する必要があります。パブリック クラウド サービスはオンデマンドであるため、価格は標準的なエンタープライズ ハードウェア ライフサイクルではなく、ワークロードの実行後、時間または日数で測定される、時間の経過に伴って割り当てられたリソースに基づいて決まります。また、自動テスト インフラストラクチャと分析を通じてソフトウェア定義の SLA を検証する機会も増え、これにより、SLA のサードパーティ検証とペナルティの適切な評価が可能になります。

[[318690]]

クラウドサービスと同期して成長

パブリック クラウド サービスにとって、幅広いエンタープライズ コンピューティングのユースケースに対応することは、やりがいのある道のりとなるでしょう。これまでと同様に、エンタープライズ アプリケーション モデルの変革は、重要でないアプリケーションから始めて、エコシステムが成熟するにつれて段階的に進めることができます。パブリック クラウドのイノベーションのペースは止まることなく、パブリック クラウド インフラストラクチャには膨大なエネルギーと資金が投入され続けています。歴史的に、コンピューティングの経済の変化の結果として、エンタープライズ プラットフォームの構造は根本的に変化しました。

エンタープライズ アプリケーションとインフラストラクチャは、再利用可能なプラットフォーム コンポーネントを使用して分散システムとして構築できます。これにより、IT プロフェッショナルと開発者は、毎回車輪の再発明をすることなく、高速で信頼性の高いアプリケーションを展開できるようになります。このモデルでは、信頼性、可用性、セキュリティ、信頼性に関連するいくつかのエンタープライズ機能を継続的に実行できます。ソフトウェア定義の SLA のランタイム構成により、生のハードウェアまたは事前にパッケージ化された SLA に基づく物理的な特性ではなく、正確なパフォーマンス メトリックを管理する機会が提供されます。エンタープライズ アプリケーションは、専用システムではなくパブリック クラウド リソースを通じて実装されるため、クラウド サービスのハードウェアの規模、効率、迅速な開発を活用し、それらに合わせて成長することができます。