最新のクラウド環境において、冗長性はリソースの無駄遣いか？

クリス・メリル、プロダクト・マーケティング・ディレクターGrass Valley

よく言われるファイブナイン（5ナイン）の中断のないパフォーマンスを実現するための従来の放送モデルでは、プロダクション・チェーンにおけるすべての重要なコンポーネントを二重化する必要がある。これらのコンポーネントは、障害が発生した場合にも利用可能でなければならないため、必然的にこれらのリソースはほとんどアイドル状態のままとなる。 これはリソースの最適化としては決して良いものではなかったが、ワークフローのランタイムが従量制であり、使用済みであれ予備であれ、すべてのリソースに関連コストがかかる今日のクラウド環境では、完全な冗長システムをホットスタンバイにしておくことは無駄である。

放送市場で提供されている初期のクラウド・ホスティング・コンポーネントの多くは、リフト・アンド・シフトのモノリシックな開発であり、中断のないパフォーマンスという標準を維持するためにはクラウド上で完全に複製する必要があるため、冗長性の追加コストが発生する。

このようなシステムが機能するためには、互いのコンポーネントとの接続性を維持するために、非常に固定された動作環境を持つ硬直したネットワークに依存している。システムに障害が発生した場合、回復するための猶予のないシステム障害が発生する可能性がある。

今日の優れたクラウドベースのシステムは、そのような古い考え方を捨てている。その代わりに、究極の目標である高いレベルの回復力を達成することに重点を置いている。レジリエンスは、システムの平均障害時間（MTTF）と平均復旧時間（MTTR）で測定される。その他のレジリエンスの尺度には、システムの能力が含まれる：

  • 故障の可能性を予測する
  • 影響を受けたコンポーネントを分離する
  • 潜在的な故障からの保護
  • 故障を取り除き、故障状態から回復する
  • 最適なシステムパフォーマンスを回復する（ムハンマド、2019年）

冗長性よりも回復力という目的に焦点を当てることで、最低コストとオペレーターの複雑さを最適化しながら、信頼性を測定・改善する意思決定が非常に容易になります。

クラウドベースの処理の性質上、時折障害が発生する。データセンターは停電に見舞われるかもしれない。サーバーやアプリに障害が発生することもある。高水準のパフォーマンスを維持するためには、クラウドシステムの耐障害性は、ネットワーク、プラットフォーム、そしてそれらのプラットフォーム上で実行されるソリューションなど、システム設計のあらゆる側面を考慮する必要がある。

潜在的な障害を補うには ソフトウェア定義ネットワーキング(SDN).SDN はアットスケールのネットワーク仮想化と仮想ネットワークインフラストラクチャのスピンアップを可能にし、より柔軟に、そしてコスト効率よく顧客の要求に応える。

弾力的なキャパシティを持つ、よく設計されたモジュラーシステムでは、障害が自動的にエラー、そして障害へと連鎖する必要はない。クラウド・ソリューションがマイクロサービス・レベルまでモジュール化されている場合、特定のリソースのレプリケーション、リルート、再起動を必要に応じて外科的に行うレジリエンシー戦略が可能になる。各サービスはその状態を外部化し、システムの残りの部分にその健全な状態を示します。そのため、効果的なエラー検出メカニズムが潜在的な障害の早期警告を提供し、予防措置として潜在的な問題領域を分離、停止、復元することができます。障害はシステム・オペレータには見えないままであり、回復イベント中はすべて人手を介さない。

クラウドにおけるレジリエンシーは、スケールアウトの概念からネットワーク・レベルで始まる。

従来の放送ワークフローでは、大規模制作に対応する一般的なモデルは、利用可能な最大のハードウェア処理フレームを購入することであった。Grass Valley を含む多くの企業は、可能な限り最大の処理能力を持つ機器を提供することで、市場でのリーダーシップを確立してきた。規模の大小にかかわらず、こうした処理能力には、可能な計算回数と、プロセッサへの地理的なアクセスという両面で限界がある。

うまく設計されたクラウドシステムでは、1台のマシンの能力を最大化する代わりに、仕事を分担する複数のサーバーに処理能力を追加する。サーバーは、Amazon ECSやKubernetesのようなテクノロジーを使って、必要に応じてデプロイされ、オーケストレーションされる。単一のロケーション、単一のヘルス・ステータス、および最大サイズを持つスケールアップとは異なり、スケールアウトは、実質的に無制限のスケール能力、地理的制約のないアクセス、および障害に対処するためのはるかに弾力性を提供する。

スケールアップとスケールアウトのモデルは、リカバリーのレスポンスタイムに影響を与える。万能なソリューションは存在しない。必要な応答時間とスタンバイ・リソースの量は、個々のクラウド・サービスのサービス・レベル・アグリーメントを使用して設計する必要があります。

ネットワーク上で実行されるSaaSソリューションのための同様のモジュラーアーキテクチャーは、プリエンプティブな障害対応の重要な部分である。
一般的な経験則では、復旧プロセスを開始する前に故障しなければならない機能ユニットが大きいほど、システムの復旧に時間がかかる。

これが、マイクロサービスのコンセプトが非常に重要な理由だ。モノリシックなデプロイメントとは対照的に、マイクロサービスをベースとしたソリューションでは、潜在的な障害を予測し、切り分けながら、それを補うために新たなリソースを投入することがはるかに簡単かつ迅速になる。モノリシックなシステムは、システム全体に対して単一の状態しか持たない。システム全体がダウンした場合、復旧にはるかに時間がかかる。

クラウド技術には、弾力性のあるシステムを提供するためのさまざまな方法論があります。さまざまなテクノロジーの選択肢をすべて理解することは重要ではありませんが、システム全体がお客様のパフォーマンス要件を満たしていることを確認することは重要です。

クラウドベースのメディア制作システムを開発するための選択肢を検討する際に、以下の点を考慮してください。

  • SaaSアプリケーションはプラットフォームにとらわれないか？単一のクラウド・プロバイダーに制約されると、必要な場所で新たなリソースを獲得する能力が制限される可能性がある。
  • 地理的に分散していることは、私のプロジェクトにとってどの程度重要ですか？データセンターへのローカルアクセスとバックアップリソースの分散という両方の観点から地理を考慮する。
  • 潜在的な故障の前に先手を打ってリソースを確保するために、どのような予測メカニズムがあるのか？
  • システムに障害が発生した場合、どの程度のフェイルオーバー応答時間が必要ですか？
  • 提案されたシステムは、そのフェイルオーバー応答時間を満たすことができるか？
  • リカバリは、能力と性能の点で初期インスタンスと同一のインスタンスを提供するか？
  • 回復システムは同一でなければならないのか、それとも "十分 "なのか？