ステートフルサービスをいつ使用し、Azure Service Fabricの外部永続性に依存するかを理解する
私は夜に現在のWebApp/CloudServicesスタックの代わりとしてAzure Service Fabricを評価しています。外部的に永続化された状態（Azure SQL、Azure Storage、およびDocumentDB）。私はこれがかなり新しい製品であることを知っています（少なくとも一般には）、したがってこれに関してはまだ多くのベストプラクティスはおそらくないでしょうが、ほとんどの documentation madeを読みましたこれに対する明確な答えを見つけることなく、Microsoftが利用できます。
私が近づいている現在の問題領域は、イベントストアです。アプリケーションの一部はイベントソーシングとCQRSに基づいており、このイベントストアをService Fabricプラットフォームに移行する方法を評価しています。イベントストアには多くの時系列データが含まれますが、そこに保存されるデータの唯一の真実のソースであるため、一貫性があり、レプリケートされ、何らかの永続ストレージに保存される必要があります。
これを行うことを検討した1つの方法は、ステートフルな「EventStream」アクターを使用することです。イベントソーシングを使用する集約の各インスタンスは、分離されたストリーム内にイベントを保存します。つまり、ステートフルアクターは自身のストリームのすべてのイベントを追跡でき、データの保存方法（トランザクション、レプリケート、永続）に関する要件を満たしていたはずです。ただし、一部のストリームは非常に大きくなる可能性があり（数百万ではないにしても、数十万のイベント）、これが私が不安になり始めているところです。大量の状態を持つアクターがいると、これらの大きなデータモデルをディスクにシリアル化またはシリアル化解除する必要がある場合、システムのパフォーマンスに影響を与えると思います。
別のオプションは、これらのアクターをステートレスに保ち、Azure SQLなどの外部ストレージからデータを読み取らせるか、アクターの代わりにステートレスサービスを使用することです。
基本的に、アクター/サービスの状態の量が「多すぎる」場合、状態を処理する他の方法の検討を開始する必要がありますか？
また、 Service Fabric Actorsのデザインパターン：いくつかのアンチパターン ドキュメントのこのセクションでは、少し戸惑っています：
Azure Service Fabricアクターをトランザクションシステムとして扱います。 Azure Service Fabricアクターは、ACIDを提供する2フェーズコミットベースのシステムではありません。オプションの永続性を実装せず、アクターが実行されているマシンが停止した場合、現在の状態はそれに伴います。アクターは別のノードで非常に高速に起動しますが、バッキング永続性を実装していない限り、状態は失われます。ただし、再試行、重複フィルタリング、およびべき等設計を活用することで、高レベルの信頼性と一貫性を実現できます。
ここで「オプションの永続性を実装しない場合」とはどういう意味ですか？私は、状態を変更するトランザクションが成功する限り、データは永続ストレージに永続化され、少なくともレプリカのサブセットに複製されるという印象を受けました。この段落では、アクター/サービス内の状態が失われる状況があるかどうか、そしてこれが自分で処理する必要があるかどうか疑問に思っています。ドキュメントの他の部分のステートフルモデルから得た印象は、この声明に反するようです。
あなたが持っている1つのオプションは、アクターに状態の「一部」を保持し（すぐに利用可能にする必要があるホットデータと考えられるものを言いましょう）、SQL Azureなどの「従来の」ストレージインフラストラクチャに他のすべてを保存することです、DocDB、....ローカル状態が多すぎるという一般的なルールを持つことは困難ですが、ホットデータとコールドデータの両方を考えると役立つかもしれません。信頼性の高いアクターは、StateProviderをカスタマイズする機能も提供しているため、データ量、待機時間の点で要件をより効率的にする必要がある特定のポリシーを使用して、カスタマイズされたStateProviderを実装することも検討できます（IActorStateProviderを実装することにより） 、信頼性など（注：StateProviderインターフェースのドキュメントはまだ非常に最小限ですが、これがあなたが追求したいものであれば、サンプルコードを公開できます）。
アンチパターンについて：このメモは、複数のアクターにまたがるトランザクションの実装に関するものです。 Reliable Actorsは、アクターの境界内のデータの信頼性を完全に保証します。アクターモデルは分散的で疎結合であるため、複数のアクターが関与するトランザクションを実装するのは簡単な作業ではありません。 「分散」トランザクションが強力な要件である場合、Reliable Servicesプログラミングモデルがおそらくより適しています。
私はこれが答えられていることを知っていますが、最近CQRS/ESシステムと同じ苦境に陥ったことに気づきました。
- 各集合体は、現在の状態のみが格納されたアクターでした。
- コマンドでは、集約は状態の変化をもたらし、イベントを発生させます。
- イベント自体はDocDbに保存されていました。
- アクティブ化時に、AggregateActorインスタンスは、状態を再作成するために利用可能な場合、DocDbからイベントを読み取ります。これは明らかに、アクタのアクティベーションごとに1回だけ実行されます。これにより、アクターインスタンスが1つのノードから別のノードに移行されるケースが処理されました。
@Trondのsedcondaryの質問に答えるには、「「オプションの永続性を実装しない場合」とはどういうことですか？」
アクターは常にステートフルサービスであり、その状態は、アクタークラスの属性を使用して、3つのモードのいずれかで動作するように構成できます。
- 永続的。状態はすべてのレプリカインスタンスに複製され、ディスクにも書き込まれます。この状態は、すべてのレプリカがシャットダウンされても維持されます。
- 揮発性。状態は、メモリ内のみで、すべてのレプリカインスタンスに複製されます。これは、1つのレプリカインスタンスが動作している限り、状態が維持されることを意味します。ただし、すべてのレプリカがシャットダウンされると、状態は失われ、再起動後に復元できなくなります。
- 永続性はありません。状態は、他のレプリカインスタンスにもディスクにも複製されません。これにより、最小限の状態保護が提供されます。
このトピックの詳細な説明は Microsoftのドキュメント にあります。