Azure Service Fabric Actor
Download as PPTX, PDF3 likes1,464 views
2016/6/16 Jazug Tokyo Night 第2回 Azure Service Fabric Actor の紹介 Service Fabric の特徴的な機能 として、２回目はActor に迫ります。
![State Manager
SaveStateAsyncで明示的に保存
State Managerは、辞書のようなデータ構造で、キーと値のペアを保持(≒Reliable Collection)
ローリングアップデートしてもVolatile -> Persistedの変更は無保証
replica数の変更は可
状態の削除は、StateManager.RemoveStateAsync(“count ”)
kyrt inc 462016/6/16
[StatePersistence(StatePersistence.Persisted)]
class Calc : Actor, ICalc {
public async Task<int> GetCountAsync() {
return await StateManager.GetOrAddStateAsync<int>("count", 0);
}
public async Task<int> AddCountAsync() {
var result = await StateManager.GetOrAddStateAsync<int>(“count”, 0);
await StateManager.SetStateAsync("count", ++result);
return result;
}
}
SateManager からキーでアクセス
最初のアクセス時に、state object がメモリに
キャッシュ
Addの場合、Stateに0が保存
Actorのmethod のreturn で永続化(commit)
Exceptionを返すとrollback
SetStateAsyncでメモリ上を更新
state provider の種別を選択](https://image.slidesharecdn.com/20160616jazugtokyonight2servicefabric-160615181147/85/Azure-Service-Fabric-Actor-46-320.jpg)
![永続性設定の自動生成
kyrt inc 472016/6/16
[StatePersistence(StatePersistence.Persisted)]
class Calc : Actor, ICalc
{
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ….>
<Parameters>
<Parameter Name="CalcActorService_PartitionCount" DefaultValue="10" />
<Parameter Name="CalcActorService_MinReplicaSetSize" DefaultValue="3" />
<Parameter Name="CalcActorService_TargetReplicaSetSize" DefaultValue="3" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="CalcPkg" ServiceManifestVersion="1.0.0" />
</ServiceManifestImport>
<DefaultServices>
<Service Name="CalcActorService" GeneratedIdRef="dba570a3-f793-4c20-9636-0038d9e6aac7|Persisted">
<StatefulService ServiceTypeName="CalcActorServiceType“
TargetReplicaSetSize="[CalcActorService_TargetReplicaSetSize]“
MinReplicaSetSize="[CalcActorService_MinReplicaSetSize]">
<UniformInt64Partition PartitionCount="[CalcActorService_PartitionCount]“
LowKey="-9223372036854775808" HighKey="9223372036854775807" />
</StatefulService>
</Service>
</DefaultServices>
</ApplicationManifest>
Visual Studio actor build tools
The build tools automatically
generate a default service for the
actor service in
ApplicationManifest.xml. Parameters
are created for min replica set size
and target replica set size.](https://image.slidesharecdn.com/20160616jazugtokyonight2servicefabric-160615181147/85/Azure-Service-Fabric-Actor-47-320.jpg)
Azure Service Fabric Actor
- 1. 第2回 JAZUG Tokyo Night Azure Service Fabric / Actor Takekazu Omi takekazu.omi@kyrt.in 2016/6/16 R.0.9
- 3. 自己紹介 近江 武一 JAZUG Azure Storage 担当（自称） Microsoft MVP for Azure http://www.slideshare.net/takekazuomi kyrt inc 3 kyrt.in github.com/takekazuom i white paper 監訳 2016/6/16
- 4. はじめに 第1回 5/18 Reliable Collection 第2回 6/16 Actor 第3回 7/20 Partition、 Cluster への展開 第4回 ? Cluster の管理運用 （予定） Global Azure Bootcamp で話したService Fabricの概要の動画 ⇨ https://youtu.be/bVWHPjcjeoc?t=38m 過去に、話した時の資料 ⇨ http://www.slideshare.net/takekazuomi/presentations kyrt inc 42016/6/16
- 6. Reliable Collection の 特徴 高可用で低レイテンシーな永続化機構 Replicated：状態の変更がレプリケートされ高可用 Persisted: データがディスクに永続化されるため、大規模な 障害に強い(例: データセンターの電源障害) Transactional : 複数の Reliable Collection 跨ったトランザ クションが可能 Low latency: read はローカル、writeは最小 Network I/O kyrt inc 62016/6/16
- 7. プログラミングモデル kyrt inc 72016/6/16 reliable service reliable actor guest executable stateless service stateful service
- 8. Actorでは、 Reliable Collection と同じ仕組を 使って、state を保存しています。 kyrt inc 82016/6/16
- 10. Actor Actor model, Actor pattern 2016/6/16 kyrt inc 10
- 11. Actor とは何か？ Carl Hewitt 1973、Wikipedia：Actorモデル Code and state encapsulation Single-thread Isolated components Asynchronous communication 結構昔からあるけど、メジャーにはなれず・・・・ kyrt inc 112016/6/16
- 12. 背景 マルチコアになり、複数インスタンスも普通になった。 Concurrency （並行性）処理に適した環境の普及は新らたな 可能性をもたらした しかし、マルチスレッド、共有メモリ等を使った、Concurrency は、人類にはオーバーテクノロジー気味 いわゆるActorモデルには、並行処理に適したアイディアが 多く含まれる Actorモデルは、 Concurrency 処理のモデル Vaughn Vernon 2013 InfoQ: Actorモデルとドメイン駆動設計 kyrt inc 122016/6/16
- 13. kyrt inc 132016/6/16 Shop:Food Nudle:10 Bread:10 Person:Neo Age:40 Person:Trinity Age:30 Shop:Hardwar e Hammer:5 Saws:10 Buy:Bread,10 Buy:Bread, 5 Buy:Hammer, 1
- 15. メッセージ 非同期メッセージ 送信メッセージは、キューに積まれ。送信側は処理完了時に非同 期に通知を受ける 各ActorはAddressを持ち、メッセージはAddressへ送信する kyrt inc 152016/6/16 Shop:Food Nudle:10 Bread:10 Person:Neo Age:40 Buy:Bread,10 Bread,10
- 16. 処理 メッセージを受けると処理が動く 内部状態を変更 kyrt inc 162016/6/16 Shop:Food Nudle:10 Bread:10 -> 0 Person:Neo Age:40 Buy:Bread,10 Bread,10 在庫が１０か ら０へ
- 18. まとめ Actor には、状態を持つ。 Actor の状態を変更できるのは、Actor自身(self)だけ Actorへメッセージを送ることが出来る Actorはメッセージを受けて逐次(serialized) ＝シング ルスレッド処理する Actorは、シングルスレッド動作なのでロックの必要は 無い 非同期メッセージしか無いObject kyrt inc 182016/6/16
- 22. Actor in Service Fabric Service Fabric に置けるActor 2016/6/16 kyrt inc 22
- 23. 由来 Service Fabric のActorは、MSR の Orleans Virtual Actors から Orleans: Distributed Virtual Actors for Programmability and Scalability Orleansは、.NET Foundation に寄贈されて OSS ⇨https://github.com/dotnet/orleans kyrt inc 232016/6/16
- 24. ３つの特徴 Scalable by Default 数百以上のseverにスケール Low Latency 状態の柔軟な保存、Persisted state、 Volatile state、No persisted state Simplified Concurrency turn base concurrency kyrt inc 242016/6/16
- 25. Actor Pattern 得手不得手 状態とロジックの小さな分離されて独立した ユニットが多数 (1,000 以上) ある Actorを跨った横断的な処理は苦手 kyrt inc 252016/6/16
- 26. Distributed Actors Service Fabric Cluster に分散Actorとして配置 Actorの内部状態は、Reliable Collectionへ保存 Service Fabricでは、Actorは、パーティション分割さ れたステートフルな Reliable Service .NET のコードからは、Actor型のインスタンスとして扱 う kyrt inc 262016/6/16
- 27. Virtual Actor Actorの有効期間≠メモリ内表現 Reliable Actors ランタイムは、Actor ID （Actor address） に要求が来た時に自動的 にそのActorをアクティブ化 一定期間未使用なアクティブなActorは、非ア クティブ化される kyrt inc 272016/6/16
- 28. Service Fabric に置けるActor StatefulとStatelessの2種類 ActorProxy経由の簡単な呼び出し kyrt inc 282016/6/16 ActorId actorId = new ActorId(new Guid()); string applicationName = "fabric:/CalculatorActorApp"; ICalculatorActor calculatorActor = ActorProxy.Create<ICalculatorActor>(actorId, applicationName); double result = calculatorActor.AddAsync(2, 3).Result; Garbage Collection ⇨Active Actor table へのadd/remove ⇨Actor lifecycle and Garbage Collection
- 31. 同時実行性 1 つの actor instance は、一 度に複数のリクエストを処理 することはできない ①のように actor instance に 同時にリクエストが来た時は 順次処理される。この場合は actor instanceが スループッ トのボトルネックになる可能 性がある ②、③のようなリクエストパ ターンが望ましい kyrt inc 312016/6/16 ① ② ③
- 32. Concurrency ActorId1には、Methodが２つとTimer がある 処理は、actor instance 毎の turn制で行わる。右の 例では、Method1のturn -> Method2のturn -> Timerのturn の順に進む Actor Runtime は、各turnの最初で、actor instance の lock を取得しturn終了時にlockを解放する Method1の処理中に、Method2が呼ばれるが、 Method1処理中はlockを取れないのでwait Timerが起動しても同様にlock待ちでwait Method1,Method2,Timer の順で turn は、シリアル に実行 kyrt inc 322016/6/16
- 33. Concurrency のスコープ lock は、per-actor で、異なったActor instanceの turnは同時に実行 turn の同時実行制御は、 Actor 全体ではなく、 Actor instance 毎 例：下図では、ActorId1のMethod1と、 ActorId2のMethod2が同時に実行 kyrt inc 332016/6/16
- 34. Reentrancy Actor Runtimeでは、既定で再入が 許可 右図ではC->Aのメッセージは許可 logical call context-based reentrancy ReentrancyMode 属性で制御 kyrt inc 342016/6/16 A B C public enum ReentrancyMode { LogicalCallContext = 1, Disallowed = 2 } Reliable Actors reentrancy
- 35. dead lock 2 つのActor間に循環参照があると、デッド ロックの危険がある Actor Runtime は、dead lock 解消で、自動 的に actor call をtimeout させcallerで例外を throwする kyrt inc 352016/6/16
- 36. Actor Pattern 得手不得手 状態とロジックの小さな分離されて独立したユ ニットが多数 (1,000 以上) ある ⇨Actor毎に別々に動作するので、スケールし易い Actorを跨った横断的な処理は苦手 ⇨A1->A2->A3 ---- An と順番に呼んで、同じcontext になるものはlock時間が長くなる。参加するActorが 増えると循環参照も・・・ kyrt inc 362016/6/16
- 38. Lifecycle 2016/6/16 kyrt inc 38
- 39. Lifecycle Actorは、そのActor ID に初めてメッセージが送信さ れたときに、自動的にアクティブ化される 規定の時間後、Actor オブジェクトはガベージ コレクト される。その後、もう一度そのActor ID を使用すると、 新しいActor オブジェクトが構築される Actorのstateは、State Manager に格納されると、オ ブジェクトの有効期間よりも長く保持される ユーザーが明示的にActorとその状態を削除可能 kyrt inc 392016/6/16
- 40. Actorのlifecycle kyrt inc 402016/6/16 Actorのライフ サイクル、自動ガベージ コレクション、および手動による削除 ※timer callback は、idle time をリセットしない
- 41. Actorとstateの削除 GCの対象となった場合、Actorは、deactivated さ れメモリ上から居なくなるだけで、state は残ります State Manager上から削除する場合は下記のよう にDeleteActorAsync を実行します kyrt inc 412016/6/16 ActorId actorToDelete = new ActorId(id); IActorService myActorServiceProxy = ActorServiceProxy.Create( new Uri("fabric:/MyApp/MyService"), actorToDelete); await myActorServiceProxy.DeleteActorAsync(actorToDelete, cancellationToken)
- 42. lifecycle まとめ kyrt inc 422016/6/16 Inactive Actor Active Actor removed from active actors list and is deactivated. - Its state is deleted permanently state is deleted permanently Messageが来ると、Activeへ 規定時間idle でInactiveへ
- 44. State management 2016/6/16 kyrt inc 44
- 45. State Persistence ActorのState管理の3つのstate storage optionがある。StatePersistence 属 性で State Provider を指定する。下が、low latency Persisted state: State はディスクに永続化され、3 つ以上のreplicaに複 製される。最も 信頼性（durable）のある state storage option で、 complete cluster outage でも state は失われない Volatile state: Stateは 3 つ以上のreplicaへ複製が memory にだけ保持 される。これにより、node障害、actor障害、upgrade中や resource balancing 中の回復性(resilience)がある。注：Stateはディスクに永続化さ れない、全replicaが同時に失われると、stateを喪失する No persisted state: State は他のnodeへ複製されず、ディスクへの書か れない。state に信頼性が必要無い場合に仕様 kyrt inc 452016/6/16
- 46. State Manager SaveStateAsyncで明示的に保存 State Managerは、辞書のようなデータ構造で、キーと値のペアを保持(≒Reliable Collection) ローリングアップデートしてもVolatile -> Persistedの変更は無保証 replica数の変更は可 状態の削除は、StateManager.RemoveStateAsync(“count ”) kyrt inc 462016/6/16 [StatePersistence(StatePersistence.Persisted)] class Calc : Actor, ICalc { public async Task<int> GetCountAsync() { return await StateManager.GetOrAddStateAsync<int>("count", 0); } public async Task<int> AddCountAsync() { var result = await StateManager.GetOrAddStateAsync<int>(“count”, 0); await StateManager.SetStateAsync("count", ++result); return result; } } SateManager からキーでアクセス 最初のアクセス時に、state object がメモリに キャッシュ Addの場合、Stateに0が保存 Actorのmethod のreturn で永続化(commit) Exceptionを返すとrollback SetStateAsyncでメモリ上を更新 state provider の種別を選択
- 47. 永続性設定の自動生成 kyrt inc 472016/6/16 [StatePersistence(StatePersistence.Persisted)] class Calc : Actor, ICalc { <?xml version="1.0" encoding="utf-8"?> <ApplicationManifest ….> <Parameters> <Parameter Name="CalcActorService_PartitionCount" DefaultValue="10" /> <Parameter Name="CalcActorService_MinReplicaSetSize" DefaultValue="3" /> <Parameter Name="CalcActorService_TargetReplicaSetSize" DefaultValue="3" /> </Parameters> <ServiceManifestImport> <ServiceManifestRef ServiceManifestName="CalcPkg" ServiceManifestVersion="1.0.0" /> </ServiceManifestImport> <DefaultServices> <Service Name="CalcActorService" GeneratedIdRef="dba570a3-f793-4c20-9636-0038d9e6aac7|Persisted"> <StatefulService ServiceTypeName="CalcActorServiceType“ TargetReplicaSetSize="[CalcActorService_TargetReplicaSetSize]“ MinReplicaSetSize="[CalcActorService_MinReplicaSetSize]"> <UniformInt64Partition PartitionCount="[CalcActorService_PartitionCount]“ LowKey="-9223372036854775808" HighKey="9223372036854775807" /> </StatefulService> </Service> </DefaultServices> </ApplicationManifest> Visual Studio actor build tools The build tools automatically generate a default service for the actor service in ApplicationManifest.xml. Parameters are created for min replica set size and target replica set size.
- 49. Actor libraries and frameworks ⇨https://en.wikipedia.org/wiki/Actor_model#Act or_libraries_and_frameworks Microsoft Orleans ⇨http://dotnet.github.io/orleans/ kyrt inc 492016/6/16
Editor's Notes
- #8: 今回は、赤枠のところの実装で出てくる、Reliable Collection の話をします。
- #12: カール ヒューイット
- #13: オブジェクト指向は、コンピュータの処理を人間の理解を
- #18: STA
- #20: もともと、オブジェクト指向プログラミングの特徴は、オブジェクト＋メッセージだったような・・・・？ 継承とか、メッセージのデフォルトルート宣言だったのでは？
- #21: もともと、オブジェクト指向プログラミングの特徴は、オブジェクト＋メッセージだったような・・・・？ 継承とか、メッセージのデフォルトルート宣言だったのでは？
- #24: オーリンズ オルレアン MSRは、Virtual Actorって言っている。厳密性は
- #32: ①Website、全てのクライアントが同じ内容を見る ②Shopping Cart ③ 計算系を分散させるようなやつかな
- #46: Reliable Collection にも、ボラタイル（Volatile） ってあったけ？