Service Fabric クラスター リソース マネージャーの概要Introducing the Service Fabric cluster resource manager

従来、IT システムまたはオンライン サービスの管理とは、特定の物理コンピューターまたは仮想マシンを特定のサービスまたはシステム専用にすることを意味していました。Traditionally managing IT systems or online services meant dedicating specific physical or virtual machines to those specific services or systems. サービスは階層として設計されていました。Services were architected as tiers. "Web" 階層と、"データ" または "ストレージ" 階層があります。There would be a “web” tier and a “data” or “storage” tier. アプリケーションには、要求が出入りするメッセージング階層と、キャッシュ専用の一連のコンピューターがあります。Applications would have a messaging tier where requests flowed in and out, as well as a set of machines dedicated to caching. ワークロードの階層または種類にはそれぞれ専用のコンピューターが使用されていました。データベースには 2 個の専用コンピューターが、Web サーバーには数個が使用されました。Each tier or type of workload had specific machines dedicated to it: the database got a couple machines dedicated to it, the web servers a few. 特定の種類のワークロードがそのワークロード用のコンピューターの能力を超えた場合は、そのワークロード用に構成されたコンピューターの数をその階層に増やしていました。If a particular type of workload caused the machines it was on to run too hot, then you added more machines with that same configuration to that tier. ただし、すべてのワークロードを簡単にスケール アウトできる訳ではありません。通常はコンピューターを大きなコンピューターで置き換えるデータ層では特にそうですが、However, not all workloads could be scaled out so easily - particularly with the data tier you would typically replace machines with larger machines. 簡単です。Easy. マシンで障害が発生した場合、マシンが復元されるまで、アプリケーションのその部分の処理能力が低下します。If a machine failed, that part of the overall application ran at lower capacity until the machine could be restored. まだ (楽しくはないにしても) 十分に簡単です。Still fairly easy (if not necessarily fun).

ただし、サービスとソフトウェア アーキテクチャの世界は変化しました。Now however the world of service and software architecture has changed. アプリケーションがスケールアウト設計を採用することは一般的になりました。It's more common that applications have adopted a scale-out design. コンテナーまたはマイクロサービス (またはその両方) を使用してアプリケーションを構築することは一般的です。Building applications with containers or microservices (or both) is common. 現在では、コンピューター数がごくわずかでも、実行しているワークロードのインスタンスは 1 つのみではありません。Now, while you may still have only a few machines, they're not running just a single instance of a workload. 複数のワークロードを同時に実行している可能性もあります。They may even be running multiple different workloads at the same time. 何十種類ものサービス (コンピューターの容量すべてに相当するリソースを消費するサービスはありません) があり、おそらくこれらのサービスの何百ものインスタンスがあります。You now have dozens of different types of services (none consuming a full machine's worth of resources), perhaps hundreds of different instances of those services. 各名前付きインスタンスには高可用性 (HA) のためのインスタンスまたはレプリカが 1 つ以上あります。Each named instance has one or more instances or replicas for High Availability (HA). ワークロードのサイズとビジー状態によっては、数百または数千単位のコンピューターがある可能性があります。Depending on the sizes of those workloads, and how busy they are, you may find yourself with hundreds or thousands of machines.

いきなり、環境の管理は、1 種類のワークロードに専用の数台のマシンの管理といった単純なものではなくなります。Suddenly managing your environment is not so simple as managing a few machines dedicated to single types of workloads. サーバーは仮想化されており、もはや名前を持ちません (考え方をペットから家畜の牛に変えます)。Your servers are virtual and no longer have names (you have switched mindsets from pets to cattle after all). マシンに関する構成は減り、サービス自体に関する構成が増えています。Configuration is less about the machines and more about the services themselves. 単一インスタンスのワークロード専用のハードウェアの大部分は過去のものになっています。Hardware that is dedicated to a single instance of a workload is largely a thing of the past. サービス自体が複数の細分化されたコモディティ ハードウェアにまで及ぶ小規模な分散システムになっています。Services themselves have become small distributed systems that span multiple smaller pieces of commodity hardware.

アプリケーションは複数の階層にまたがって分散する一連のモノリスではなくなったため、処理に必要な数の組み合わせを持つことができるようになりました。Because your app is no longer a series of monoliths spread across several tiers, you now have many more combinations to deal with. どのハードウェアまたは何台のハードウェアで実行できるワークロードの種類をだれが決定しますか。Who decides what types of workloads can run on which hardware, or how many? どのワークロードが同じハードウェアで適切に動作し、競合しているでしょうか。Which workloads work well on the same hardware, and which conflict? コンピューターが停止した場合、そのコンピューターで実行されていたものを知るにはどうすればよいでしょうか。When a machine goes down how do you know what was running there on that machine? 確実にワークロードが再実行する責任はだれにありますか。Who is in charge of making sure that workload starts running again? (仮想) マシンが回復するまで待ちますか、またはワークロードは自動的に他のマシンにフェールオーバーし、実行し続けていますか。Do you wait for the (virtual?) machine to come back or do your workloads automatically fail over to other machines and keep running? ユーザーの介入は必要ですか。Is human intervention required? この環境でのアップグレードについてはどうですか。What about upgrades in this environment?

Microsoft では、この環境に対応している開発者およびオペレーターがこの複雑さを管理できるように支援します。As developers and operators dealing in this environment, we’re going to want help managing this complexity. むやみに人を雇って複雑さを覆い隠そうとすることは、おそらく正しい答えではありません。それではどうすればよいでしょうか。A hiring binge and trying to hide the complexity with people is probably not the right answer, so what do we do?

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

"オーケストレーター" とは、管理者がこの種の環境を管理するのを支援するソフトウェアの一般的な用語です。An “Orchestrator” is the general term for a piece of software that helps administrators manage these types of environments. オーケストレーターは、"このサービスの 5 つのコピーを環境で実行したい" といった要求を受け取るコンポーネントです。Orchestrators are the components that take in requests like “I would like five copies of this service running in my environment." 何が起きようとも、環境を望ましい状態にしようとします。They try to make the environment match the desired state, no matter what happens.

オーケストレーター (人ではありません) は、何らかの予期しない理由によってマシンで障害が発生したりワークロードが中断したりすると活動を開始します。Orchestrators (not humans) are what take action when a machine fails or a workload terminates for some unexpected reason. ほとんどのオーケストレータ―は、ただ障害に対応するだけではありません。Most orchestrators do more than just deal with failure. それ以外にも、新しいデプロイの管理、アップグレードの処理、リソース消費とガバナンスの処理などを行います。Other features they have are managing new deployments, handling upgrades, and dealing with resource consumption and governance. オーケストレータ―はすべて、基本的には環境内の構成を何らかの望ましい状態に維持することに関係しています。All orchestrators are fundamentally about maintaining some desired state of configuration in the environment. 管理者としては、オーケストレーターに希望を伝えて重労働を任せることができればいいと思うでしょう。You want to be able to tell an orchestrator what you want and have it do the heavy lifting. Mesos 上の Aurora、Docker Datacenter/Docker Swarm、Kubernetes、Service Fabric は、いずれもオーケストレーターの例です。Aurora on top of Mesos, Docker Datacenter/Docker Swarm, Kubernetes, and Service Fabric are all examples of orchestrators. これらのオーケストレーターは、運用環境で実際のワークロードのニーズを満たすために積極的に開発されています。These orchestrators are being actively developed to meet the needs of real workloads in production environments.

サービスとしてのオーケストレーションOrchestration as a service

クラスター リソース マネージャーは、Service Fabric のオーケストレーションを処理するシステム コンポーネントです。The Cluster Resource Manager is the system component that handles orchestration in Service Fabric. クラスター リソース マネージャーのジョブは 3 つの部分に分かれます。The Cluster Resource Manager’s job is broken down into three parts:

  1. ルールの強制Enforcing Rules
  2. 環境の最適化Optimizing Your Environment
  3. その他のプロセスの支援Helping with Other Processes

説明What it isn’t

従来の N 層 アプリケーションには、常にロード バランサーがあります。In traditional N tier applications, there's always a Load Balancer. 通常は、ネットワーク スタック内での位置によりネットワーク ロード バランサー (NLB) またはアプリケーション ロード バランサー (ALB) と呼ばれていました。Usually this was a Network Load Balancer (NLB) or an Application Load Balancer (ALB) depending on where it sat in the networking stack. ロード バランサーには、F5 の BigIP のようなハードウェア ベースのものと、Microsoft の NLB のようなソフトウェア ベースのものがあります。Some load balancers are Hardware-based like F5’s BigIP offering, others are software-based such as Microsoft’s NLB. 他の環境では、このロールに HAProxy、nginx、Istio、Envoy のようなものがありました。In other environments, you might see something like HAProxy, nginx, Istio, or Envoy in this role. これらのアーキテクチャでの負荷分散の仕事は、すべての異なるステートレス ワークロードが、(ほぼ) 同じ量の作業を受け取るようにすることです。In these architectures, the job of load balancing is to ensure stateless workloads receive (roughly) the same amount of work. 負荷分散にはさまざまな戦略があります。Strategies for balancing load varied. 一部のロード バランサーは、異なるサーバーにそれぞれ異なる呼び出しを送信していました。Some balancers would send each different call to a different server. その他のロード バランサーは、セッションの固定や持続性を提供するものでした。Others provided session pinning/stickiness. より高度なロード バランサーは、予想されるコストと現状のコンピューターの負荷に基づいて、実際の負荷の推定またはレポートを使用して呼び出しをルーティングします。More advanced balancers use actual load estimation or reporting to route a call based on its expected cost and current machine load.

ネットワーク ロード バランサーやメッセージのルーターは、Web/ワーカー層をほぼバランスの取れた状態で維持しようとしました。Network balancers or message routers tried to ensure that the web/worker tier remained roughly balanced. データ層の負荷分散戦略は異なり、データ ストレージ メカニズムに依存していました。Strategies for balancing the data tier were different and depended on the data storage mechanism. データ層の負荷分散は、データ シャーディング、キャッシュ、管理されたビュー、ストアド プロシージャなど、ストア固有のメカニズムに依存していました。Balancing the data tier relied on data sharding, caching, managed views, stored procedures, and other store-specific mechanisms.

これらの方法の中には興味深いものもありますが、Service Fabric クラスター リソース マネージャーはネットワーク ロード バランサーやキャッシュとはまったく異なるものです。While some of these strategies are interesting, the Service Fabric Cluster Resource Manager is not anything like a network load balancer or a cache. ネットワーク ロード バランサーは、トラフィックをフロントエンド全体に分散することで、フロントエンドの負荷を分散しています。A Network Load Balancer balances frontends by spreading traffic across frontends. Service Fabric クラスター リソース マネージャーの戦略は異なります。The Service Fabric Cluster Resource Manager has a different strategy. 基本的に、Service Fabric はサービスを最も理にかなった場所に移動し、トラフィックや負荷が追随するようにします。Fundamentally, Service Fabric moves services to where they make the most sense, expecting traffic or load to follow. たとえば、割り当てられているサービスがあまりやることがないために、現在コールド状態になっているノードなどに移動します。For example, it might move services to nodes that are currently cold because the services that are there are not doing much work. ノードは、存在していたサービスが削除されたか別の場所に移動されたために、コールド状態になっている可能性があります。The nodes may be cold since the services that were present were deleted or moved elsewhere. クラスター リソース マネージャーが、マシンからサービスを移動する場合もあります。As another example, the Cluster Resource Manager could also move a service away from a machine. これは、マシンがアップグレードされようとしているか、実行されているサービスによる使用量の急増により過負荷状態になっているという状況が考えられます。Perhaps the machine is about to be upgraded, or is overloaded due to a spike in consumption by the services running on it. または、サービスのリソース要件が増えている可能性があります。Alternatively, the service's resource requirements may have increased. その結果、実行を継続できるだけのリソースがこのコンピューターにありません。As a result there aren't sufficient resources on this machine to continue running it.

クラスター リソース マネージャーはサービスを移動させる役割を担うため、ネットワーク ロード バランサーにあるものとは違った機能セットを持っています。Because the Cluster Resource Manager is responsible for moving services around, it contains a different feature set compared to what you would find in a network load balancer. これは、ネットワーク ロード バランサーは、その場所がサービス自体の実行に最適ではない場合でも、サービスが既に配置されている場所にネットワーク トラフィックを配信するためです。This is because network load balancers deliver network traffic to where services already are, even if that location is not ideal for running the service itself. クラスター内のリソースが効率的に活用されるようにするため、Service Fabric クラスター リソース マネージャーは、根本的に異なる方法を採用しています。The Service Fabric Cluster Resource Manager employs fundamentally different strategies for ensuring that the resources in the cluster are efficiently utilized.

次の手順Next steps

  • クラスター リソース マネージャー内のアーキテクチャと情報フローについては、こちらの記事をご確認くださいFor information on the architecture and information flow within the Cluster Resource Manager, check out this article
  • Cluster Resource Manager には、クラスターを記述するためのさまざまなオプションがあります。The Cluster Resource Manager has many options for describing the cluster. メトリックの詳細については、Service Fabric クラスターの記述に関するこの記事を参照してください。To find out more about metrics, check out this article on describing a Service Fabric cluster
  • サービスの構成の詳細については、サービスの構成についての学習に関する記事を参照してください。For more information on configuring services, Learn about configuring Services
  • メトリックは、Service Fabric クラスター リソース マネージャーが管理するクラスターの利用量と容量を表します。Metrics are how the Service Fabric Cluster Resource Manger manages consumption and capacity in the cluster. メトリックの詳細とその構成方法については、この記事を参照してください。To learn more about metrics and how to configure them check out this article
  • クラスター リソース マネージャーは Service Fabric の管理機能と連動します。The Cluster Resource Manager works with Service Fabric's management capabilities. その統合の詳細については、 この記事To find out more about that integration, read this article
  • クラスター リソース マネージャーでクラスターの負荷を管理し、分散するしくみについては、 負荷分散To find out about how the Cluster Resource Manager manages and balances load in the cluster, check out the article on balancing load