Service Fabric クラスター リソース マネージャーの概要

  • [アーティクル]

従来、IT システムまたはオンライン サービスの管理とは、特定の物理コンピューターまたは仮想マシンを特定のサービスまたはシステム専用にすることを意味していました。 サービスは階層として設計されていました。 "Web" 階層と、"データ" または "ストレージ" 階層があります。 アプリケーションには、要求が出入りするメッセージング階層と、キャッシュ専用の一連のコンピューターがあります。 ワークロードの階層または種類にはそれぞれ専用のコンピューターが使用されていました。データベースには 2 個の専用コンピューターが、Web サーバーには数個が使用されました。 特定の種類のワークロードがそのワークロード用のコンピューターの能力を超えた場合は、そのワークロード用に構成されたコンピューターの数をその階層に増やしていました。 ただし、すべてのワークロードを簡単にスケール アウトできる訳ではありません。通常はコンピューターを大きなコンピューターで置き換えるデータ層では特にそうですが、 簡単です。 マシンで障害が発生した場合、マシンが復元されるまで、アプリケーションのその部分の処理能力が低下します。 まだ (楽しくはないにしても) 十分に簡単です。

ただし、サービスとソフトウェア アーキテクチャの世界は変化しました。 アプリケーションがスケールアウト設計を採用することは一般的になりました。 コンテナーまたはマイクロサービス (またはその両方) を使用してアプリケーションを構築することは一般的です。 現在では、コンピューター数がごくわずかでも、実行しているワークロードのインスタンスは 1 つのみではありません。 複数のワークロードを同時に実行している可能性もあります。 何十種類ものサービス (コンピューターの容量すべてに相当するリソースを消費するサービスはありません) があり、おそらくこれらのサービスの何百ものインスタンスがあります。 各名前付きインスタンスには高可用性 (HA) のためのインスタンスまたはレプリカが 1 つ以上あります。 ワークロードのサイズとビジー状態によっては、数百または数千単位のコンピューターがある可能性があります。

いきなり、環境の管理は、1 種類のワークロードに専用の数台のマシンの管理といった単純なものではなくなります。 サーバーは仮想化されており、もはや名前を持ちません (考え方を ペットから家畜の牛 に変え ます )。 マシンに関する構成は減り、サービス自体に関する構成が増えています。 単一インスタンスのワークロード専用のハードウェアの大部分は過去のものになっています。 サービス自体が複数の細分化されたコモディティ ハードウェアにまで及ぶ小規模な分散システムになっています。

アプリケーションは複数の階層にまたがって分散する一連のモノリスではなくなったため、処理に必要な数の組み合わせを持つことができるようになりました。 どのハードウェアまたは何台のハードウェアで実行できるワークロードの種類をだれが決定しますか。 どのワークロードが同じハードウェアで適切に動作し、競合しているでしょうか。 コンピューターが停止した場合、そのコンピューターで実行されていたものを知るにはどうすればよいでしょうか。 確実にワークロードが再実行する責任はだれにありますか。 (仮想) マシンが回復するまで待ちますか、またはワークロードは自動的に他のマシンにフェールオーバーし、実行し続けていますか。 ユーザーの介入は必要ですか。 この環境でのアップグレードについてはどうですか。

Microsoft では、この環境に対応している開発者およびオペレーターがこの複雑さを管理できるように支援します。 むやみに人を雇って複雑さを覆い隠そうとすることは、おそらく正しい答えではありません。それではどうすればよいでしょうか。

オーケストレーターの導入

"オーケストレーター" とは、管理者がこの種の環境を管理するのを支援するソフトウェアの一般的な用語です。 オーケストレーターは、"このサービスの 5 つのコピーを環境で実行したい" といった要求を受け取るコンポーネントです。何が起きようとも、環境を望ましい状態にしようとします。

オーケストレーター (人ではありません) は、何らかの予期しない理由によってマシンで障害が発生したりワークロードが中断したりすると活動を開始します。 ほとんどのオーケストレータ―は、ただ障害に対応するだけではありません。 それ以外にも、新しいデプロイの管理、アップグレードの処理、リソース消費とガバナンスの処理などを行います。 オーケストレータ―はすべて、基本的には環境内の構成を何らかの望ましい状態に維持することに関係しています。 管理者としては、オーケストレーターに希望を伝えて重労働を任せることができればいいと思うでしょう。 Mesos 上の Aurora、Docker Datacenter/Docker Swarm、Kubernetes、Service Fabric は、いずれもオーケストレーターの例です。 これらのオーケストレーターは、運用環境で実際のワークロードのニーズを満たすために積極的に開発されています。

サービスとしてのオーケストレーション

クラスター リソース マネージャーは、Service Fabric のオーケストレーションを処理するシステム コンポーネントです。 クラスター リソース マネージャーのジョブは 3 つの部分に分かれます。

  1. ルールの強制
  2. 環境の最適化
  3. その他のプロセスの支援

Cluster Resource Manager のしくみを説明しているトレーニング ビデオについては、このページを確認してください。

説明

従来の N 層 アプリケーションには、常にロード バランサーがあります。 通常は、ネットワーク スタック内での位置によりネットワーク ロード バランサー (NLB) またはアプリケーション ロード バランサー (ALB) と呼ばれていました。 ロード バランサーには、F5 の BigIP のようなハードウェア ベースのものと、Microsoft の NLB のようなソフトウェア ベースのものがあります。 他の環境では、このロールに HAProxy、nginx、Istio、Envoy のようなものがありました。 これらのアーキテクチャでの負荷分散の仕事は、すべての異なるステートレス ワークロードが、(ほぼ) 同じ量の作業を受け取るようにすることです。 負荷分散にはさまざまな戦略があります。 一部のロード バランサーは、異なるサーバーにそれぞれ異なる呼び出しを送信していました。 その他のロード バランサーは、セッションの固定や持続性を提供するものでした。 より高度なロード バランサーは、予想されるコストと現状のコンピューターの負荷に基づいて、実際の負荷の推定またはレポートを使用して呼び出しをルーティングします。

ネットワーク ロード バランサーやメッセージのルーターは、Web/ワーカー層をほぼバランスの取れた状態で維持しようとしました。 データ層の負荷分散戦略は異なり、データ ストレージ メカニズムに依存していました。 データ層の負荷分散は、データ シャーディング、キャッシュ、管理されたビュー、ストアド プロシージャなど、ストア固有のメカニズムに依存していました。

これらの方法の中には興味深いものもありますが、Service Fabric クラスター リソース マネージャーはネットワーク ロード バランサーやキャッシュとはまったく異なるものです。 ネットワーク ロード バランサーは、トラフィックをフロントエンド全体に分散することで、フロントエンドの負荷を分散しています。 Service Fabric クラスター リソース マネージャーの戦略は異なります。 基本的に、Service Fabric はサービスを最も理にかなった場所に移動し、トラフィックや負荷が追随するようにします。 たとえば、割り当てられているサービスがあまりやることがないために、現在コールド状態になっているノードなどに移動します。 ノードは、存在していたサービスが削除されたか別の場所に移動されたために、コールド状態になっている可能性があります。 クラスター リソース マネージャーが、マシンからサービスを移動する場合もあります。 これは、マシンがアップグレードされようとしているか、実行されているサービスによる使用量の急増により過負荷状態になっているという状況が考えられます。 または、サービスのリソース要件が増えている可能性があります。 その結果、実行を継続できるだけのリソースがこのコンピューターにありません。

クラスター リソース マネージャーはサービスを移動させる役割を担うため、ネットワーク ロード バランサーにあるものとは違った機能セットを持っています。 これは、ネットワーク ロード バランサーは、その場所がサービス自体の実行に最適ではない場合でも、サービスが既に配置されている場所にネットワーク トラフィックを配信するためです。 クラスター内のリソースが効率的に活用されるようにするため、Service Fabric クラスター リソース マネージャーは、根本的に異なる方法を採用しています。

次のステップ

  • クラスター リソース マネージャー内のアーキテクチャと情報フローについては、こちらの記事をご確認ください
  • Cluster Resource Manager には、クラスターを記述するためのさまざまなオプションがあります。 メトリックの詳細については、Service Fabric クラスターの記述に関するこの記事を参照してください。
  • サービスの構成の詳細については、サービスの構成についての学習に関する記事を参照してください。
  • メトリックは、Service Fabric クラスター リソース マネージャーが管理するクラスターの利用量と容量を表します。 メトリックの詳細とその構成方法については、この記事を参照してください。
  • クラスター リソース マネージャーは Service Fabric の管理機能と連動します。 その統合の詳細については、 この記事
  • クラスター リソース マネージャーでクラスターの負荷を管理し、分散するしくみについては、 負荷分散