Service Fabric に関してよく寄せられる質問Commonly asked Service Fabric questions

Service Fabric で実行できる内容とその使用方法に関してよく寄せられる多数の質問があります。There are many commonly asked questions about what Service Fabric can do and how it should be used. このドキュメントでは、これらのよく寄せられる質問とその回答を示します。This document covers many of those common questions and their answers.

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

クラスターのセットアップと管理Cluster setup and management

Service Fabric クラスターの証明書はどのようにロールバックするのですか?How do I roll back my Service Fabric cluster certificate?

アプリケーションに対するアップグレードをロールバックするには、Service Fabric クラスターのクォーラムが変更をコミットする前に正常性エラーが検出される必要があります。コミットされた変更は、ロールフォワードのみが可能です。Rolling back any upgrade to your application requires health failure detection prior to your Service Fabric cluster quorum committing the change; committed changes can only be rolled forward. 監視対象外の破壊的な証明書の変更が行われた場合、クラスターを回復するために、エスカレーション エンジニアによる初めから終わりまでのカスタマー サポート サービスが必要になる場合があります。Escalation engineer’s through Customer Support Services, may be required to recover your cluster, if an unmonitored breaking certificate change has been introduced. Service Fabric アプリケーションのアップグレードは、Application アップグレード パラメーターに適用され、ダウンタイムが発生しないアップグレードが確約されています。Service Fabric’s application upgrade applies Application upgrade parameters, and delivers zero downtime upgrade promise. 推奨されるアプリケーション アップグレードである監視モードに従えば、更新ドメインを通した自動進行は正常性チェックの合格に基づいたものとなり、既定のサービスの更新が失敗した場合は自動的にロールバックが行われます。Following our recommended application upgrade monitored mode, automatic progress through update domains is based upon health checks passing, rolling back automatically if updating a default service fails.

お使いのクラスターが、Resource Manager テンプレートで旧来の証明書の Thumbprint プロパティをまだ活用している場合は、最新の機密管理機能を活用するため、クラスターで使用するのを証明書の拇印から共通名に変更することをお勧めします。If your cluster is still leveraging the classic Certificate Thumbprint property in your Resource Manager template, it's recommended you Change cluster from certificate thumbprint to common name, to leverage modern secrets management features.

複数の Azure リージョンまたは自らのデータセンターにまたがるクラスターを作成することはできますか?Can I create a cluster that spans multiple Azure regions or my own datacenters?

はい。Yes.

Service Fabric コア クラスタリング テクノロジを使用すると、相互にネットワーク接続されているのであれば、世界中で実行されているコンピューターを組み合わせることができます。The core Service Fabric clustering technology can be used to combine machines running anywhere in the world, so long as they have network connectivity to each other. ただし、そのようなクラスターの構築と実行は複雑になる可能性があります。However, building and running such a cluster can be complicated.

このシナリオに関心がある場合は、Service Fabric GitHub 問題一覧から、あるいはサポート窓口を通じて詳しいガイダンスを入手してください。If you are interested in this scenario, we encourage you to get in contact either through the Service Fabric GitHub Issues List or through your support representative in order to obtain additional guidance. Service Fabric チームでは、このシナリオをさらに明確にし、ガイダンスや推奨事項を追加できるよう取り組んでいます。The Service Fabric team is working to provide additional clarity, guidance, and recommendations for this scenario.

以下の点を考慮してください。Some things to consider:

  1. 現在、Azure での Service Fabric クラスター リソースは、クラスターが構築される仮想マシン スケール セットと同じように、地域に限定されています。The Service Fabric cluster resource in Azure is regional today, as are the virtual machine scale sets that the cluster is built on. つまり、地域的な障害が発生したとき、Azure Resource Manager または Azure Portal を使用してクラスターを管理できなくなることがあります。This means that in the event of a regional failure you may lose the ability to manage the cluster via the Azure Resource Manager or the Azure portal. クラスターが実行し続けていて、直接やり取りできる場合にも、そのような状況になることがあります。This can happen even though the cluster remains running and you'd be able to interact with it directly. また、現在の Azure では、地域にまたがって使用できる単独の仮想ネットワークは提供されていません。In addition, Azure today does not offer the ability to have a single virtual network that is usable across regions. つまり、Azure の複数リージョン クラスターは、仮想マシン スケール セット内の各 VM に対するパブリック IP アドレス、または Azure VPN ゲートウェイを必要とします。This means that a multi-region cluster in Azure requires either Public IP Addresses for each VM in the virtual machine scale sets or Azure VPN Gateways. これらのネットワーク オプションにより、コストやパフォーマンスがさまざまな影響を受けます。ある程度まではアプリケーション設計にも影響があります。このため、このような環境を立ち上げるには、事前に注意深い分析と計画が必要です。These networking choices have different impacts on costs, performance, and to some degree application design, so careful analysis and planning is required before standing up such an environment.
  2. 特に、異なるクラウド プロバイダーやオンプレミス リソースと Azure など、複数の環境の タイプ が混在する場合、これらのマシンのメンテナンス、管理、監視は複雑になります。The maintenance, management, and monitoring of these machines can become complicated, especially when spanned across types of environments, such as between different cloud providers or between on-premises resources and Azure. そのような環境で実稼働ワークロードを実行する前には、クラスターとアプリケーションの両方のアップグレード、監視、管理、診断についてよく理解する必要があります。Care must be taken to ensure that upgrades, monitoring, management, and diagnostics are understood for both the cluster and the applications before running production workloads in such an environment. Azure または自身のデータセンターでこのような問題を解決した経験がある場合は、Service Fabric クラスターを構築または実行する際にも同じソリューションを適用できると考えられます。If you already have experience solving these problems in Azure or within your own datacenters, then it is likely that those same solutions can be applied when building out or running your Service Fabric cluster.

Service Fabric ノードでは、OS の更新は自動的に受信されますか?Do Service Fabric nodes automatically receive OS updates?

現在、仮想マシン スケール セットによる OS イメージの自動アップグレード一般公開機能を使用できます。You can use Virtual Machine Scale Set Automatic OS Image Update Generally Available feature today.

Azure で実行されていないクラスターの場合は、Service Fabric ノードのオペレーティング システムにパッチを適用するためのアプリケーションが提供されています。For clusters that are NOT run in Azure, we have provided an application to patch the operating systems underneath your Service Fabric nodes.

SF クラスターで大規模な仮想マシン スケール セットを使用できますか?Can I use large virtual machine scale sets in my SF cluster?

簡単な回答 - いいえ。Short answer - No.

詳しい回答 - 大規模な仮想マシン スケール セットでは、最大 1000 台の VM インスタンスにスケーリングできますが、これは配置グループ (PG) を使用して実行されます。Long Answer - Although the large virtual machine scale sets allow you to scale a virtual machine scale set up to 1000 VM instances, it does so by the use of Placement Groups (PGs). 障害ドメイン (FD) とアップグレード ドメイン (UD) は、Service Fabric が FD と UD を使用してサービス レプリカ/サービス インスタンスの配置を決定する配置グループ内でのみ整合性が維持されます。Fault domains (FDs) and upgrade domains (UDs) are only consistent within a placement group Service fabric uses FDs and UDs to make placement decisions of your service replicas/Service instances. FD 数と UD 数は配置グループ内でのみ比較可能であるため、SF で使用することはできません。Since the FDs and UDs are comparable only within a placement group, SF cannot use it. たとえば、PG1 の VM1 のトロポジが FD=0 であり、PG2 の VM9 のトポロジが FD=4 の場合、VM1 と VM2 が 2 つの異なるハードウェア ラック上にあることを意味するわけではないため、SF はこの例の FD 値を使用して配置を決定することはできません。For example, If VM1 in PG1 has a topology of FD=0 and VM9 in PG2 has a topology of FD=4, it does not mean that VM1 and VM2 are on two different Hardware Racks, hence SF cannot use the FD values in this case to make placement decisions.

レベル 4 の負荷分散をサポートしていないなど、現在、大規模な仮想マシン スケール セットに関する問題がほかにもあります。There are other issues with large virtual machine scale sets currently, like the lack of level-4 Load balancing support. 詳細については、大規模なスケール セットに関する記事をご覧ください。Refer to for details on Large scale sets

Service Fabric クラスターの最小サイズとは何ですか?What is the minimum size of a Service Fabric cluster? もっと小さくできないのはなぜですか?Why can't it be smaller?

運用ワークロードを実行する Service Fabric クラスターでサポートされる最小サイズは、5 つのノードです。The minimum supported size for a Service Fabric cluster running production workloads is five nodes. 開発シナリオでは、1 つのノード (Visual Studio での迅速な開発エクスペリエンスのために最適化) と 5 つのノード クラスターがサポートされます。For dev scenarios, we support one node (optimized for quick development experience in Visual Studio) and five node clusters.

次の 3 つの理由により、運用クラスターには少なくとも 5 つのノードが必要です。We require a production cluster to have at least five nodes because of the following three reasons:

  1. ユーザー サービスが実行中でない場合でも、Service Fabric クラスターでは一連のステートフル システム サービス (ネーム サービスやフェールオーバー マネージャー サービスなど) が実行されるためです。Even when no user services are running, a Service Fabric cluster runs a set of stateful system services, including the naming service and the failover manager service. クラスターを運用可能な状態のままにするには、これらのシステム サービスが不可欠です。These system services are essential for the cluster to remain operational.
  2. 常に、1 ノードにつきサービスのレプリカを 1 つ配置します。そのため、サービス (実際にはパーティション) が保持できるレプリカの数の上限はクラスター サイズになります。We always place one replica of a service per node, so cluster size is the upper limit for the number of replicas a service (actually a partition) can have.
  3. クラスターのアップグレード時は少なくとも 1 つのノードがダウンするため、少なくとも 1 つのノードのバッファーを用意する必要があります。そのため、運用クラスターには、最小限の数のノードの "ほかに"、少なくとも 2 つのノードが必要です。Since a cluster upgrade will bring down at least one node, we want to have a buffer of at least one node, therefore, we want a production cluster to have at least two nodes in addition to the bare minimum. 最小限とは、以下で説明しますが、システム サービスのクォーラム サイズです。The bare minimum is the quorum size of a system service as explained below.

クラスターは、2 つのノードに同時に障害が発生しても使用できる必要があります。We want the cluster to be available in the face of simultaneous failure of two nodes. Service Fabric クラスターを使用できるようにするには、システム サービスが使用できなければなりません。For a Service Fabric cluster to be available, the system services must be available. クラスターにデプロイされているサービスと現在のホスト場所を追跡するステートフル システム サービス (ネーム サービスやフェールオーバー マネージャー サービスなど) は、強い一貫性に依存しています。Stateful system services like naming service and failover manager service, that track what services have been deployed to the cluster and where they're currently hosted, depend on strong consistency. この強い一貫性は、これらのサービスの状態に対する特定の更新の "クォーラム" を取得する能力に依存しています (クォーラムは特定のサービスに対するレプリカの strict majority (N/2 +1) を表します)。That strong consistency, in turn, depends on the ability to acquire a quorum for any given update to the state of those services, where a quorum represents a strict majority of the replicas (N/2 +1) for a given service. そのため、2 つのノードが同時に失われた (したがって、システム サービスの 2 つのレプリカが同時に失われた) 際の回復性を備えておく必要がある場合、ClusterSize - QuorumSize >= 2 でなければなりません。その結果、最小サイズは強制的に 5 つになります。Thus if we want to be resilient against simultaneous loss of two nodes (thus simultaneous loss of two replicas of a system service), we must have ClusterSize - QuorumSize >= 2, which forces the minimum size to be five. そのことを確かめるために、クラスターに N 個のノードがあり、システム サービスのレプリカが N 個 (ノードごとに 1 個) ある場合を考えてみましょう。To see that, consider the cluster has N nodes and there are N replicas of a system service -- one on each node. システム サービスのクォーラム サイズは (N/2 + 1) です。The quorum size for a system service is (N/2 + 1). 上記の不等式は N - (N/2 + 1) >= 2 のようになります。The above inequality looks like N - (N/2 + 1) >= 2. N が偶数の場合と N が奇数の場合の 2 つのケースを考慮する必要があります。There are two cases to consider: when N is even and when N is odd. N が偶数の場合、たとえば N = 2*m で、m >= 1 とすると、不等式は 2*m - (2*m/2 + 1) >= 2 のようになります。つまり、m >= 3 となります。If N is even, say N = 2*m where m >= 1, the inequality looks like 2*m - (2*m/2 + 1) >= 2 or m >= 3. N の最小値は 6 となり、これは m = 3 の場合に実現されます。The minimum for N is 6 and that is achieved when m = 3. 一方、N が奇数の場合、たとえば N = 2*m + 1 で、m >= 1 とすると、不等式は 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 のようになります。つまり 2*m+1 - (m+1) >= 2、さらには m >= 2 となります。On the other hand, if N is odd, say N = 2*m+1 where m >= 1, the inequality looks like 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 or 2*m+1 - (m+1) >= 2 or m >= 2. N の最小値は 5 となり、これは m = 2 の場合に実現されます。The minimum for N is 5 and that is achieved when m = 2. そのため、ClusterSize - QuorumSize >= 2 という不等式を満たす N のすべての値の最小値は 5 です。Therefore, among all values of N that satisfy the inequality ClusterSize - QuorumSize >= 2, the minimum is 5.

注意していただきたい点として、上記の論証では、すべてのノードにシステム サービスのレプリカがあると想定しています。したがって、クォーラム サイズはクラスター内のノードの数に基づいて計算されます。Note, in the above argument we have assumed that every node has a replica of a system service, thus the quorum size is computed based on the number of nodes in the cluster. ただし、TargetReplicaSetSize を変更することで、クォーラム サイズを (N/2 + 1) よりも小さくすることができます。それによって、5 ノード未満のクラスターでも、クォーラム サイズ以外に 2 つの追加ノードを用意できるという印象を受けるかもしれません。However, by changing TargetReplicaSetSize we could make the quorum size less than (N/2+1) which might give the impression that we could have a cluster smaller than 5 nodes and still have 2 extra nodes above the quorum size. たとえば、4 ノードのクラスターで TargetReplicaSetSize を 3 に設定した場合、TargetReplicaSetSize に基づくクォーラム サイズは (3/2 + 1)、つまり 2 です。したがって、ClusterSize - QuorumSize = 4-2 >= 2 となります。For example, in a 4 node cluster, if we set the TargetReplicaSetSize to 3, the quorum size based on TargetReplicaSetSize is (3/2 + 1) or 2, thus we have ClusterSize - QuorumSize = 4-2 >= 2. ただし、ペアのノードが同時に失われた場合に、システム サービスがクォーラム以上であるという保証はありません。失われた 2 つのノードが 2 つのレプリカをホストしていた可能性があります。その場合、システム サービスはクォーラム損失となり (残っているレプリカが 1 つだけとなり)、使用できなくなります。However, we cannot guarantee that the system service will be at or above quorum if we lose any pair of nodes simultaneously, it could be that the two nodes we lost were hosting two replicas, so the system service will go into quorum loss (having only a single replica left) and will become unavailable.

これを背景として、考えられるいくつかのクラスター構成を検討してみます。With that background, let's examine some possible cluster configurations:

1 つのノード: 単一のノードが何らかの理由で失われることはクラスター全体が失われるためを意味するため、このオプションでは高可用性を提供できません。One node: this option does not provide high availability since the loss of the single node for any reason means the loss of the entire cluster.

2 つのノード: 2 つのノード (N = 2) 間でデプロイされるサービスのクォーラムは 2 です (2/2 + 1 = 2)。Two nodes: a quorum for a service deployed across two nodes (N = 2) is 2 (2/2 + 1 = 2). 1 つのレプリカが失われると、クォーラムを作成できなくなります。When a single replica is lost, it is impossible to create a quorum. サービスのアップグレードを実行するには、レプリカを一時的に停止させる必要があるため、これは有用な構成ではありません。Since performing a service upgrade requires temporarily taking down a replica, this is not a useful configuration.

3 つのノード: 3 つのノード (N = 3) でも、クォーラムを作成するためのノードの要件は 2 つのままです (3/2 + 1 = 2)。Three nodes: with three nodes (N=3), the requirement to create a quorum is still two nodes (3/2 + 1 = 2). つまり、1 つのノードが失われてもクォーラムを維持できますが、2 つのノードに同時に障害が発生すると、システム サービスがクォーラム損失になり、クラスターが使用できなくなります。This means that you can lose an individual node and still maintain quorum, but simultaneous failure of two nodes will drive the system services into quorum loss and will cause the cluster to become unavailable.

4 つのノード: 4 つのノード (N = 4) では、クォーラムを作成するためのノードの要件は 3 つです (4/2 + 1 = 3)。Four nodes: with four nodes (N=4), the requirement to create a quorum is three nodes (4/2 + 1 = 3). つまり、1 つのノードが失われてもクォーラムを維持できますが、2 つのノードに同時に障害が発生すると、システム サービスがクォーラム損失になり、クラスターが使用できなくなります。This means that you can lose an individual node and still maintain quorum, but simultaneous failure of two nodes will drive the system services into quorum loss and will cause the cluster to become unavailable.

5 つのノード: 5 つのノード (N = 5) でも、クォーラムを作成するためのノードの要件は 3 つのままです (5/2 + 1 = 3)。Five nodes: with five nodes (N=5), the requirement to create a quorum is still three nodes (5/2 + 1 = 3). つまり、同時に 2 つのノードが失われても、システム サービスのクォーラムを維持できます。This means that you can lose two nodes at the same time and still maintain quorum for the system services.

運用ワークロードでは、少なくとも 2 つのノードに (たとえば、1 つがクラスターのアップグレードで、もう 1 つが他の理由によって) 同時に障害が発生した際の回復性を備えておかなければならないため、5 つのノードが必要です。For production workloads, you must be resilient to simultaneous failure of at least two nodes (for example, one due to cluster upgrade, one due to other reasons), so five nodes are required.

コストを節約するために夜間/週末にクラスターをオフにすることはできますか?Can I turn off my cluster at night/weekends to save costs?

通常はできません。In general, no. Service Fabric は、一時的なローカル ディスクに状態を格納します。これは、仮想マシンが別のホストに移動されても、データは一緒に移動されないことを意味します。Service Fabric stores state on local, ephemeral disks, meaning that if the virtual machine is moved to a different host, the data does not move with it. 通常の運用では、新しいノードは他のノードによって最新の状態になるため、これは問題にはなりません。In normal operation, that is not a problem as the new node is brought up to date by other nodes. ただし、すべてのノードを停止し、後で再起動した場合は、ほとんどのノードが新しいホスト上で開始され、システムが回復できない状態になる可能性が非常に高くなります。However, if you stop all nodes and restart them later, there is a significant possibility that most of the nodes start on new hosts and make the system unable to recover.

アプリケーションをデプロイする前にテスト用のクラスターを作成する場合は、継続的インテグレーション/継続的配置パイプラインの一部としてこれらのクラスターを作成することをお勧めします。If you would like to create clusters for testing your application before it is deployed, we recommend that you dynamically create those clusters as part of your continuous integration/continuous deployment pipeline.

オペレーティング システムはどのようにアップグレードすればいいですか? (Windows Server 2012 を 2016 にする場合など)How do I upgrade my Operating System (for example from Windows Server 2012 to Windows Server 2016)?

Microsoft はエクスペリエンスの改善に取り組んでいますが、現時点ではお客様の責任でアップグレードを行っていただく必要があります。While we're working on an improved experience, today, you are responsible for the upgrade. クラスターの仮想マシンで OS イメージをアップグレードする場合は、一度に 1 つの VM で行う必要があります。You must upgrade the OS image on the virtual machines of the cluster one VM at a time.

クラスター ノード タイプ (仮想マシン スケール セット) で接続されたデータ ディスクを暗号化することはできますか?Can I encrypt attached data disks in a cluster node type (virtual machine scale set)?

はい。Yes. 詳細については、データ ディスクをアタッチしたクラスターの作成に関するページおよび仮想マシン スケール セット用の Azure Disk Encryption に関するページを参照してください。For more information, see Create a cluster with attached data disks and Azure Disk Encryption for Virtual Machine Scale Sets.

クラスター ノード タイプ (仮想マシン スケール セット) で、優先度の低い VM を使用することはできますか?Can I use low-priority VMs in a cluster node type (virtual machine scale set)?

いいえ。No. 優先度の低い VM はサポートされていません。Low-priority VMs are not supported.

クラスターでウイルス対策プログラムを実行するときに除外する必要があるディレクトリとプロセスWhat are the directories and processes that I need to exclude when running an anti-virus program in my cluster?

ウイルス対策の対象外ディレクトリAntivirus Excluded directories
Program Files\Microsoft Service FabricProgram Files\Microsoft Service Fabric
FabricDataRoot (クラスター構成による)FabricDataRoot (from cluster configuration)
FabricLogRoot (クラスター構成による)FabricLogRoot (from cluster configuration)
ウイルス対策の対象外プロセスAntivirus Excluded processes
Fabric.exeFabric.exe
FabricHost.exeFabricHost.exe
FabricInstallerService.exeFabricInstallerService.exe
FabricSetup.exeFabricSetup.exe
FabricDeployer.exeFabricDeployer.exe
ImageBuilder.exeImageBuilder.exe
FabricGateway.exeFabricGateway.exe
FabricDCA.exeFabricDCA.exe
FabricFAS.exeFabricFAS.exe
FabricUOS.exeFabricUOS.exe
FabricRM.exeFabricRM.exe
FileStoreService.exeFileStoreService.exe

アプリケーションを Key Vault に対して認証してシークレットを取得するにはどうすればよいですか?How can my application authenticate to Key Vault to get secrets?

アプリケーションを Key Vault に対して認証するための資格情報を取得する方法を次に示します。The following are means for your application to obtain credentials for authenticating to Key Vault:

A.A. アプリケーションのビルド/パッキング ジョブ中に、SF アプリのデータ パッケージに証明書をプルし、これを使用して Key Vault に対して認証することができます。During your applications build/packing job, you can pull a certificate into your SF app's data package, and use this to authenticate to Key Vault. B.B. 仮想マシン スケール セットの MSI 対応ホストの場合は、SF アプリ用の単純な PowerShell SetupEntryPoint を開発して、MSI エンドポイントからアクセス トークンを取得し、Key Vault からシークレットを取得することができます。For virtual machine scale set MSI enabled hosts, you can develop a simple PowerShell SetupEntryPoint for your SF app to get an access token from the MSI endpoint, and then retrieve your secrets from Key Vault.

アプリケーションの設計Application Design

Reliable Collection のパーティション全体のデータを照会する最善の方法は何ですか?What's the best way to query data across partitions of a Reliable Collection?

Reliable collection は、通常は、パフォーマンスとスループットを高めるためのスケールアウトを実行できるようにパーティション分割されます。Reliable collections are typically partitioned to enable scale out for greater performance and throughput. これは、特定のサービスの状態が、数十から数百台のコンピューターに分散されることを意味します。That means that the state for a given service may be spread across tens or hundreds of machines. このデータ セット全体に対して操作を実行するには、いくつかのオプションがあります。To perform operations over that full data set, you have a few options:

  • 別のサービスのすべてのパーティションを照会して必要なデータを引き出すサービスを作成します。Create a service that queries all partitions of another service to pull in the required data.
  • 別のサービスのすべてのパーティションからデータを受信できるサービスを作成します。Create a service that can receive data from all partitions of another service.
  • 各サービスから外部ストアにデータを定期的にプッシュします。Periodically push data from each service to an external store. 外部ストアのデータは古くなるため、この方法は、実行する照会が中核となるビジネス ロジックの一部ではない場合のみに適しています。This approach is only appropriate if the queries you're performing are not part of your core business logic, as the external store's data will be stale.
  • あるいは、あらゆるレコードにクエリを実行しなければならないデータについては、信頼できるコレクションではなく、データ ストアに直接、格納してください。Alternatively, store data that must support querying across all records directly in a data store rather than in a reliable collection. これで古いデータの問題が解消されますが、信頼できるコレクションの長所は活用できません。This eliminates the issue with stale data, but doesn't allow the advantages of reliable collections to be leveraged.

アクター全体のデータを照会する最善の方法は何ですか。What's the best way to query data across my actors?

アクターは、状態とコンピューティングに依存しないように設計されているため、実行時にアクターの状態を広範に照会することは推奨されていません。Actors are designed to be independent units of state and compute, so it is not recommended to perform broad queries of actor state at runtime. アクターの状態のフル セットを照会する必要がある場合は、次のいずれかを検討してください。If you have a need to query across the full set of actor state, you should consider either:

  • アクター サービスをステートフルな信頼できるサービスに置き換えて、すべてのアクターからすべてのデータを収集するネットワーク要求の数がサービス内のパーティションの数と同じになるようにします。Replacing your actor services with stateful reliable services, so that the number of network requests to gather all data from the number of actors to the number of partitions in your service.
  • 状態を外部ストアに定期的にプッシュして簡単に照会できるようにアクターを設計します。Designing your actors to periodically push their state to an external store for easier querying. 上記と同じように、この方法は、実行する照会が実行時の動作で必須でない場合のみに実行可能です。As above, this approach is only viable if the queries you're performing are not required for your runtime behavior.

Reliable Collection には、どのくらいの量のデータを格納できますか?How much data can I store in a Reliable Collection?

Reliable Services は通常はパーティション分割されるため、格納できる量は、クラスター内のコンピューターの台数とこれらのコンピューターで使用できるメモリの量によってのみ制限されます。Reliable services are typically partitioned, so the amount you can store is only limited by the number of machines you have in the cluster, and the amount of memory available on those machines.

たとえば、サービスに 100 個のパーティションと 3 つのレプリカがある Reliable Collection があり、平均サイズが 1 KB のオブジェクトを格納するとします。As an example, suppose that you have a reliable collection in a service with 100 partitions and 3 replicas, storing objects that average 1 kb in size. ここで、クラスターが 10 台のコンピューターで構成され、各コンピューターのメモリが 16 GB であるとします。Now suppose that you have a 10 machine cluster with 16gb of memory per machine. 単純かつ控えめに見積もるために、オペレーティング システム、システム サービス、Service Fabric ランタイム、および使用するサービスで 6 GB が消費され、各コンピューターで残りの 10 GB、つまりクラスターで 100 GB を使用できるものと想定します。For simplicity and to be conservative, assume that the operating system and system services, the Service Fabric runtime, and your services consume 6gb of that, leaving 10gb available per machine, or 100 gb for the cluster.

各オブジェクトは 3 回格納される必要があること (1 回はプライマリに、2 回はレプリカに) に留意すると、容量全部を使用して運用した場合は、約 3,500 万個のオブジェクトをコレクションに格納するのに十分なメモリがあります。Keeping in mind that each object must be stored three times (one primary and two replicas), you would have sufficient memory for approximately 35 million objects in your collection when operating at full capacity. ただし、障害ドメインとアップグレード ドメインが同時に失われた場合の回復力を備えておくことが推奨されます。これは容量の約 1/3 に当たるため、この数値は約 2,300 万個に減少します。However, we recommend being resilient to the simultaneous loss of a failure domain and an upgrade domain, which represents about 1/3 of capacity, and would reduce the number to roughly 23 million.

この計算では、以下も想定されています。This calculation also assumes:

  • パーティション間のデータの分散はほぼ一定であるか、クラスター リソース マネージャーに負荷メトリックを報告すること。That the distribution of data across the partitions is roughly uniform or that you're reporting load metrics to the Cluster Resource Manager. 既定では、Service Fabric は、レプリカの数に基づいて負荷を分散します。By default, Service Fabric loads balance based on replica count. 前の例では、クラスター内の各ノードに 10 個のプライマリ レプリカと 20 個のセカンダリ レプリカが配置されます。In the preceding example, that would put 10 primary replicas and 20 secondary replicas on each node in the cluster. パーティション間で負荷が均等に分散される場合は問題はありません。That works well for load that is evenly distributed across the partitions. 負荷が均等でない場合は、負荷をレポートして、小さなレプリカがリソース マネージャーによって 1 つにまとめられ、大きなレプリカが個々のノードでより多くのメモリを消費できるようにする必要があります。If load is not even, you must report load so that the Resource Manager can pack smaller replicas together and allow larger replicas to consume more memory on an individual node.

  • 問題の Reliable Service が、クラスターで格納状態にある唯一のサービスであること。That the reliable service in question is the only one storing state in the cluster. 複数のサービスをクラスターにデプロイできるため、実行する必要があるリソースとその状態の管理を意識する必要があります。Since you can deploy multiple services to a cluster, you need to be mindful of the resources that each needs to run and manage its state.

  • クラスター自体が拡大も縮小もしないこと。That the cluster itself is not growing or shrinking. コンピューターが追加された場合、Service Fabric は、追加された容量を活用するためにレプリカの再分散を実行します。個々のレプリカは複数のコンピューターにまたがることはできないため、この動作はコンピューターの数がサービス内のパーティションの数を上回るまで続けられます。If you add more machines, Service Fabric will rebalance your replicas to leverage the additional capacity until the number of machines surpasses the number of partitions in your service, since an individual replica cannot span machines. 逆に、コンピューターを削除することでクラスターのサイズが減少した場合、レプリカはより緊密にパックされ、全体の容量が小さくなります。By contrast, if you reduce the size of the cluster by removing machines, your replicas are packed more tightly and have less overall capacity.

アクターには、どのくらいの量のデータを格納できますか?How much data can I store in an actor?

Reliable Services と同じように、アクター サービスに格納できるデータの量は、ディスク領域の合計とクラスター内のノードで使用できるメモリによってのみ制限されます。As with reliable services, the amount of data that you can store in an actor service is only limited by the total disk space and memory available across the nodes in your cluster. ただし、個々のアクターは、小さな分量の状態とそれに関連付けられたビジネス ロジックをカプセル化するために使用すると、最も効果があります。However, individual actors are most effective when they are used to encapsulate a small amount of state and associated business logic. 原則として、個々のアクターには、キロバイト単位で測定される状態を格納してください。As a general rule, an individual actor should have state that is measured in kilobytes.

Azure Service Fabric リソース プロバイダーでは、顧客データはどこに格納されていますか?Where does Azure Service Fabric Resource Provider store customer data?

Azure Service Fabric リソース プロバイダーによって、デプロイされているリージョン外に顧客データが移動または格納されることはありません。Azure Service Fabric Resource Provider doesn’t move or store customer data out of the region it is deployed in.

その他の質問Other questions

Service Fabric はコンテナーとどのように関連していますか?How does Service Fabric relate to containers?

コンテナーは、サービスとそれに依存するものをパケージ化して、それらがすべての環境で一貫性をもって実行され、1 台のコンピューター上で隔離された方法で運用できるようにします。Containers offer a simple way to package services and their dependencies such that they run consistently in all environments and can operate in an isolated fashion on a single machine. Service Fabric には、コンテナーにパッケージ化されたサービスも含めて、サービスをデプロイして管理する方法が用意されています。Service Fabric offers a way to deploy and manage services, including services that have been packaged in a container.

Service Fabric をオープン ソース化する予定はありますか?Are you planning to open-source Service Fabric?

GitHub では Service Fabric のオープン ソース化された部分 (Reliable Services フレームワークReliable Actors フレームワークASP.NET Core 統合ライブラリService Fabric ExplorerService Fabric CLI) が提供されており、これらのプロジェクトにはコミュニティの皆さんにも参加していただいています。We have open-sourced parts of Service Fabric (reliable services framework, reliable actors framework, ASP.NET Core integration libraries, Service Fabric Explorer, and Service Fabric CLI) on GitHub and accept community contributions to those projects.

Service Fabric ラインタイムをオープン ソース化する予定であることは、最近発表しました。We recently announced that we plan to open-source the Service Fabric runtime. 現時点では、GitHub には、Linux のビルドおよびテスト ツールを含む、Service Fabric リポジトリがアップされており、このリポジトリを複製し、Linux 用の Service Fabric をビルドして、基本的なテストを実行し、問題を開き、pull request を送信することができます。At this point, we have the Service Fabric repo up on GitHub with Linux build and test tools, which means you can clone the repo, build Service Fabric for Linux, run basic tests, open issues, and submit pull requests. 完全な CI 環境と共に、Windows ビルド環境の移行にも全力で取り組んでいます。We’re working hard to get the Windows build environment migrated over as well, along with a complete CI environment.

詳しくは、Service Fabric ブログでの発表をご覧ください。Follow the Service Fabric blog for more details as they're announced.

次のステップNext steps

Service Fabric の中心概念ベスト プラクティスを学習するLearn about core Service Fabric concepts and best practices