Service Fabric に関してよく寄せられる質問
Service Fabric で実行できる内容とその使用方法に関してよく寄せられる多数の質問があります。 このドキュメントでは、これらのよく寄せられる質問とその回答を示します。
Note
Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。
クラスターのセットアップと管理
Service Fabric クラスターの証明書はどのようにロールバックするのですか?
アプリケーションに対するアップグレードをロールバックするには、Service Fabric クラスター クォーラムが変更をコミットする前の正常性エラー検出が必要です。コミットされた変更にはロールフォワードしか実行できません。 何らかの理由で監視対象外の破壊的な証明書の変更が発生した場合、クラスターを回復するために、エスカレーション エンジニアによる初めから終わりまでのカスタマー サポート サービスが必要になる場合があります。 Service Fabric アプリケーションのアップグレードは、Application アップグレード パラメーターに適用され、ダウンタイムが発生しないアップグレードが確約されています。 推奨されるアプリケーション アップグレードである監視モードに従えば、更新ドメインを通した自動進行は正常性チェックの合格に基づいたものとなり、既定のサービスの更新が失敗した場合は自動的にロールバックが行われます。
クラスターが Resource Manager テンプレート内で従来の証明書サムプリント プロパティをまだ使用している場合は、証明書サムプリントから共通名にクラスターを変更して、現代的なシークレット管理機能を適用することをお勧めします。
複数の Azure リージョンまたは自らのデータセンターにまたがるクラスターを作成することはできますか?
はい。
Service Fabric コア クラスタリング テクノロジを使用すると、相互にネットワーク接続されているのであれば、世界中で実行されているコンピューターを組み合わせることができます。 ただし、そのようなクラスターの構築と実行は複雑になる可能性があります。
このシナリオに関心がある場合は、Service Fabric GitHub Issues List から、あるいはサポート窓口を通じて連絡を行い、詳しいガイダンスを入手してください。 Service Fabric チームでは、このシナリオをさらに明確にし、ガイダンスや推奨事項を追加できるよう取り組んでいます。
以下の点を考慮してください。
- 現在、Azure での Service Fabric クラスター リソースは、クラスターが構築される仮想マシン スケール セットと同じように、地域に限定されています。 つまり、地域的な障害が発生したとき、Azure Resource Manager または Azure Portal を使用してクラスターを管理できなくなることがあります。 クラスターが実行し続けていて、直接やり取りできる場合にも、そのような状況になることがあります。 また、現在の Azure はリージョンにまたがって使用できる単独の仮想ネットワークを作成する機能は提供してません。 つまり、Azure の複数リージョン クラスターは、仮想マシン スケール セット内の各 VM に対するパブリック IP アドレス、または Azure VPN ゲートウェイを必要とします。 これらのネットワーク オプションにより、コストやパフォーマンスがさまざまな影響を受けます。ある程度まではアプリケーション設計にも影響があります。このため、このような環境を立ち上げるには、事前に注意深い分析と計画が必要です。
- 特に、異なるクラウド プロバイダーやオンプレミス リソースと Azure など、複数の環境の タイプ が混在する場合、これらのマシンのメンテナンス、管理、監視は複雑になります。 そのような環境で実稼働ワークロードを実行する前には、クラスターとアプリケーションの両方のアップグレード、監視、管理、診断についてよく理解する必要があります。 Azure 内または自身のデータセンターでこのような問題を解決した経験がある場合は、Service Fabric クラスターを構築または実行する際にもそれと同じ解決策を適用できると考えられます。
Service Fabric ノードでは、OS の更新は自動的に受信されますか?
現在、仮想マシン スケール セットによる OS イメージの自動アップグレード一般公開機能を使用できます。
Azure で実行されていないクラスターの場合は、Service Fabric ノードのオペレーティング システムにパッチを適用するためのアプリケーションが提供されています。
SF クラスターで大規模な仮想マシン スケール セットを使用できますか?
簡単な回答 - いいえ。
詳しい回答 - 大規模な仮想マシン スケール セットでは、最大 1000 台の VM インスタンスにスケーリングできますが、これは配置グループ (PG) を使用して実行されます。 障害ドメイン (FD) とアップグレード ドメイン (UD) は、Service Fabric が FD と UD を使用してサービス レプリカ/サービス インスタンスの配置を決定する配置グループ内でのみ整合性が維持されます。 FD と UD を比較できるのは配置グループ内においてだけであるため、SF でこれを使用することはできません。 たとえば、PG1 内の VM1 が FD=0 というトポロジを持っており、PG2 内の VM9 が FD=4 というトポロジを持っているとしても、VM1 と VM2 が 2 つの異なるハードウェア ラック上にあることにはならないため、SF はこのケースで FD 値を使用して配置を決定することはできません。
レベル 4 の負荷分散をサポートしていないなど、現在、大規模な仮想マシン スケール セットに関する問題がほかにもあります。 詳細については、大規模なスケール セットに関する記事をご覧ください。
Service Fabric クラスターの最小サイズとは何ですか? もっと小さくできないのはなぜですか?
運用ワークロードを実行する Service Fabric クラスターでサポートされる最小サイズは、5 つのノードです。 開発シナリオでは、1 つのノード (Visual Studio での迅速な開発エクスペリエンスのために最適化) と 5 つのノード クラスターがサポートされます。
次の 3 つの理由により、運用クラスターには少なくとも 5 つのノードが必要です。
- ユーザー サービスが実行中でない場合でも、Service Fabric クラスターでは一連のステートフル システム サービス (ネーム サービスやフェールオーバー マネージャー サービスなど) が実行されるためです。 クラスターを運用可能な状態のままにするには、これらのシステム サービスが不可欠です。
- 常に、1 ノードにつきサービスのレプリカを 1 つ配置します。そのため、サービス (実際にはパーティション) が保持できるレプリカの数の上限はクラスター サイズになります。
- クラスターのアップグレード時は少なくとも 1 つのノードがダウンするため、少なくとも 1 つのノードのバッファーを用意する必要があります。そのため、運用クラスターには、最小限の数のノードの "ほかに"、少なくとも 2 つのノードが必要です。 最小限とは、以下で説明しますが、システム サービスのクォーラム サイズです。
クラスターは、2 つのノードに同時に障害が発生しても使用できる必要があります。 Service Fabric クラスターを使用できるようにするには、システム サービスが使用できなければなりません。 クラスターにデプロイされているサービスと現在のホスト場所を追跡するステートフル システム サービス (ネーム サービスやフェールオーバー マネージャー サービスなど) は、強い一貫性に依存しています。 この強い一貫性は、これらのサービスの状態に対する特定の更新の "クォーラム" を取得する能力に依存しています (クォーラムは特定のサービスに対するレプリカの strict majority (N/2 +1) を表します)。 そのため、2 つのノードの同時喪失 (システム サービスの 2 つのレプリカの同時喪失) に対する回復性を実現したい場合は、ClusterSize - QuorumSize >= 2 となるようにしなくてはならず、その結果、最小サイズは強制的に 5 になります。
注意すべき点として、上記の議論ではすべてのノードがシステム サービスのレプリカを持っていると想定しているため、クォーラム サイズはクラスター内のノードの数に基づいて計算されています。 ただし、TargetReplicaSetSize を変更することで、クォーラム サイズを (N/2 + 1) よりも小さくすることができます。それによって、5 ノード未満のクラスターでも、クォーラム サイズ以外に 2 つの追加ノードを用意できるという印象を受けるかもしれません。 たとえば、4 ノードのクラスターで TargetReplicaSetSize を 3 に設定した場合、TargetReplicaSetSize に基づくクォーラム サイズは (3/2 + 1)、つまり 2 です。したがって、ClusterSize - QuorumSize = 4-2 >= 2 となります。 ただし、ペアのノードが同時に失われた場合に、システム サービスがクォーラム以上であるという保証はありません。失われた 2 つのノードが 2 つのレプリカをホストしていたため、システム サービスはクォーラム損失となり (残っているレプリカが 1 つだけとなり)、利用不可になるということが考えられます。
これを背景として、考えられるいくつかのクラスター構成を検討してみます。
1 つのノード: 何らかの理由による 1 つのノードの喪失がクラスター全体の喪失を意味するため、このオプションでは高可用性を実現できません。
2 つのノード: 2 つのノード (N = 2) 間でデプロイされるサービスのクォーラムは 2 です (2/2 + 1 = 2)。 1 つのレプリカが失われると、クォーラムを作成することが不可能になります。 サービスのアップグレードを実行するには、レプリカを一時的に停止させる必要があるため、これは有用な構成ではありません。
3 つのノード: 3 つのノード (N = 3) でも、クォーラムを作成するためのノードの要件は 2 つのままです (3/2 + 1 = 2)。 つまり、1 つのノードが失われてもクォーラムを維持できますが、2 つのノードに同時に障害が発生すると、システム サービスがクォーラム損失になり、クラスターが使用できなくなります。
4 つのノード: 4 つのノード (N = 4) では、クォーラムを作成するためのノードの要件は 3 つです (4/2 + 1 = 3)。 つまり、1 つのノードが失われてもクォーラムを維持できますが、2 つのノードに同時に障害が発生すると、システム サービスがクォーラム損失になり、クラスターが使用できなくなります。
5 つのノード: 5 つのノード (N = 5) でも、クォーラムを作成するためのノードの要件は 3 つのままです (5/2 + 1 = 3)。 つまり、同時に 2 つのノードが失われても、システム サービスのクォーラムを維持できます。
運用ワークロードでは、少なくとも 2 つのノードに (たとえば、1 つがクラスターのアップグレードで、もう 1 つが他の理由によって) 同時に障害が発生した際の回復性を備えておかなければならないため、5 つのノードが必要です。
コストを節約するために夜間/週末にクラスターをオフにすることはできますか?
通常はできません。 Service Fabric はローカルのエフェメラル ディスクに状態を保存します。これは、仮想マシンが別のホストに移動されても、データはそれと一緒に移動しないことを意味します。 通常の運用では、新しいノードは他のノードによって最新の状態になるため、これは問題にはなりません。 ただし、すべてのノードを停止し、後で再起動した場合は、ほとんどのノードが新しいホスト上で開始され、システムが回復できない状態になる可能性が非常に高くなります。
アプリケーションをデプロイする前にテスト用のクラスターを作成したい場合は、継続的インテグレーション/継続的デプロイ パイプラインの一部としてこれらのクラスターを動的に作成することをお勧めします。
オペレーティング システムはどのようにアップグレードすればいいですか? (Windows Server 2012 を 2016 にする場合など)
Microsoft はエクスペリエンスの改善に取り組んでいますが、現時点ではお客様の責任でアップグレードを行っていただく必要があります。 クラスターの仮想マシンで OS イメージをアップグレードする場合は、一度に 1 つの VM で行う必要があります。
クラスター ノード タイプ (仮想マシン スケール セット) で接続されたデータ ディスクを暗号化することはできますか?
はい。 詳細については、データ ディスクをアタッチしたクラスターの作成に関するページおよび仮想マシン スケール セット用の Azure Disk Encryption に関するページを参照してください。
クラスター ノード タイプ (仮想マシン スケール セット) で、優先度の低い VM を使用することはできますか?
いいえ。 優先度の低い VM はサポートされていません。
クラスターでウイルス対策プログラムを実行するときに除外する必要があるディレクトリとプロセス
| ウイルス対策の対象外ディレクトリ |
|---|
| Program Files\Microsoft Service Fabric |
| FabricDataRoot (クラスター構成による) |
| FabricLogRoot (クラスター構成による) |
| ウイルス対策の対象外プロセス |
|---|
| Fabric.exe |
| FabricHost.exe |
| FabricInstallerService.exe |
| FabricSetup.exe |
| FabricDeployer.exe |
| ImageBuilder.exe |
| FabricGateway.exe |
| FabricDCA.exe |
| FabricFAS.exe |
| FabricUOS.exe |
| FabricRM.exe |
| FileStoreService.exe |
アプリケーションを Key Vault に対して認証してシークレットを取得するにはどうすればよいですか?
アプリケーションを Key Vault に対して認証するための資格情報を取得する方法を次に示します。
A. アプリケーションのビルド/パッキング ジョブ中に、SF アプリのデータ パッケージに証明書をプルし、これを使用して Key Vault に対して認証することができます。 B. 仮想マシン スケール セットの MSI 対応ホストの場合は、SF アプリ用の単純な PowerShell SetupEntryPoint を開発して、MSI エンドポイントからアクセス トークンを取得し、Key Vault からシークレットを取得することができます。
サブスクリプションを別の Microsoft Entra テナントに譲渡できますか?
いいえ。 現時点では、サブスクリプションが別の Microsoft Entra テナントに譲渡された後に、新しい Service Fabric クラスター リソースを作成する必要があります。
Microsoft Entra テナント間でクラスターを移動または移行できますか?
いいえ。 現時点では、新しいテナントに新しい Service Fabric クラスター リソースを作成する必要があります。
サブスクリプション間でクラスターを移動/移行することはできますか?
いいえ。 現時点では、新しいサブスクリプションに新しい Service Fabric クラスター リソースを作成する必要があります。
クラスターまたはクラスター リソースを、他のリソース グループに移動または移行する、または名前を変更することはできますか?
いいえ。 現時点では、新しいリソース グループに、または新しいリソース名で新しい Service Fabric クラスター リソースを作成する必要があります。
アプリケーションの設計
Reliable Collection のパーティション全体のデータを照会する最善の方法は何ですか?
Reliable collection は、通常は、パフォーマンスとスループットを高めるためのスケールアウトを実行できるようにパーティション分割されます。 これは、特定のサービスの状態が、数十から数百台のコンピューターに分散されることを意味します。 このデータ セット全体に対して操作を実行するには、いくつかのオプションがあります。
- 別のサービスのすべてのパーティションを照会して必要なデータを引き出すサービスを作成します。
- 別のサービスのすべてのパーティションからデータを受信できるサービスを作成します。
- 各サービスから外部ストアにデータを定期的にプッシュします。 外部ストアのデータは古くなるため、この方法は、実行する照会が中核となるビジネス ロジックの一部ではない場合のみに適しています。
- あるいは、あらゆるレコードにクエリを実行しなければならないデータについては、信頼できるコレクションではなく、データ ストアに直接、格納してください。 これで古いデータの問題が解消されますが、信頼できるコレクションの長所は活用できません。
アクター全体のデータを照会する最善の方法は何ですか。
アクターは状態とコンピューティングの独立した単位となるように設計されているため、実行時にアクター状態の広範なクエリを実行することは推奨されません。 アクターの状態のフル セットを照会する必要がある場合は、次のいずれかを検討してください。
- アクター サービスをステートフルな信頼できるサービスに置き換えて、すべてのアクターからすべてのデータを収集するネットワーク要求の数がサービス内のパーティションの数と同じになるようにします。
- 状態を外部ストアに定期的にプッシュして簡単に照会できるようにアクターを設計します。 上記と同じように、この方法は、実行する照会が実行時の動作で必須でない場合のみに実行可能です。
Reliable Collection には、どのくらいの量のデータを格納できますか?
Reliable Services は通常はパーティション分割されるため、格納できる量は、クラスター内のコンピューターの台数とこれらのコンピューターで使用できるメモリの量によってのみ制限されます。
たとえば、サービスに 100 個のパーティションと 3 つのレプリカがある Reliable Collection があり、平均サイズが 1 KB のオブジェクトを格納するとします。 ここで、クラスターが 10 台のコンピューターで構成され、各コンピューターのメモリが 16 GB であるとします。 単純かつ控えめに見積もるために、オペレーティング システム、システム サービス、Service Fabric ランタイム、および使用するサービスで 6 GB が消費され、各コンピューターで残りの 10 GB、つまりクラスターで 100 GB を使用できるものと想定します。
各オブジェクトは 3 回格納される必要があること (1 回はプライマリに、2 回はレプリカに) に留意すると、容量全部を使用して運用した場合は、約 3,500 万個のオブジェクトをコレクションに格納するのに十分なメモリがあります。 ただし、障害ドメインとアップグレード ドメインが同時に失われた場合の回復力を備えておくことが推奨されます。これは容量の約 1/3 に当たるため、この数値は約 2,300 万個に減少します。
この計算では、以下も想定されています。
パーティション間のデータの分散はほぼ一定であるか、クラスター リソース マネージャーに負荷メトリックを報告すること。 既定では、Service Fabric は、レプリカの数に基づいて負荷を分散します。 前の例では、クラスター内の各ノードに 10 個のプライマリ レプリカと 20 個のセカンダリ レプリカが配置されます。 パーティション間で負荷が均等に分散される場合は問題はありません。 負荷が均等でない場合は、負荷をレポートして、Resource Manager が小さなレプリカを 1 つにまとめ、大きなレプリカが個々のノードでより多くのメモリを使用することを許可できるようにする必要があります。
問題の Reliable Service が、クラスターで格納状態にある唯一のサービスであること。 複数のサービスをクラスターにデプロイできるため、実行する必要があるリソースとその状態の管理を意識する必要があります。
クラスター自体が拡大も縮小もしていないこと。 マシンを追加した場合、Service Fabric は、追加された容量を活用するためにレプリカの再調整を実行します。個々のレプリカは複数のマシンにまたがることはできないため、この動作はマシンの数がサービス内のパーティションの数を上回るまで続けられます。 逆に、コンピューターを削除することでクラスターのサイズが減少した場合、レプリカはより緊密にパックされ、全体の容量が小さくなります。
アクターには、どのくらいの量のデータを格納できますか?
Reliable Services と同じように、アクター サービスに格納できるデータの量は、ディスク領域の合計とクラスター内のノードで使用できるメモリによってのみ制限されます。 ただし、個々のアクターは、小さな分量の状態とそれに関連付けられたビジネス ロジックをカプセル化するために使用すると、最も効果があります。 原則として、個々のアクターには、キロバイト単位で測定される状態を格納してください。
Azure Service Fabric リソース プロバイダーでは、顧客データはどこに格納されていますか?
Azure Service Fabric リソース プロバイダーによって、顧客データがデプロイされたリージョン外に移動または保存されることはありません。
その他の質問
Service Fabric はコンテナーとどのように関連していますか?
コンテナーは、サービスとそれに依存するものをパケージ化して、それらがすべての環境で一貫性をもって実行され、1 台のコンピューター上で隔離された方法で運用できるようにします。 Service Fabric には、コンテナーにパッケージ化されたサービスも含めて、サービスをデプロイして管理する方法が用意されています。
Service Fabric をオープン ソース化する予定はありますか?
GitHub では Service Fabric のオープン ソース化された部分 (Reliable Services フレームワーク、Reliable Actors フレームワーク、ASP.NET Core 統合ライブラリ、Service Fabric Explorer、Service Fabric CLI) が提供されており、これらのプロジェクトにはコミュニティの皆さんにも参加していただいています。
Service Fabric ラインタイムをオープン ソース化する予定であることは、最近発表しました。 現時点では、GitHub には、Linux のビルドおよびテスト ツールを含む、Service Fabric リポジトリがアップされており、このリポジトリを複製し、Linux 用の Service Fabric をビルドして、基本的なテストを実行し、問題を開き、pull request を送信することができます。 完全な CI 環境と共に、Windows ビルド環境の移行にも全力で取り組んでいます。
詳しくは、Service Fabric ブログでの発表をご覧ください。