Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Azure Service Fabric Actor

1,039 views

Published on

2016/6/16 Jazug Tokyo Night 第2回
Azure Service Fabric Actor の紹介
Service Fabric の特徴的な機能 として、2回目はActor に迫ります。

Published in: Technology
  • Be the first to comment

Azure Service Fabric Actor

  1. 1. 第2回 JAZUG Tokyo Night Azure Service Fabric / Actor Takekazu Omi takekazu.omi@kyrt.in 2016/6/16 R.0.9
  2. 2. kyrt inc 22016/6/16
  3. 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. 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
  5. 5. 復習 2016/6/16 kyrt inc 5
  6. 6. Reliable Collection の 特徴 高可用で低レイテンシーな永続化機構  Replicated:状態の変更がレプリケートされ高可用  Persisted: データがディスクに永続化されるため、大規模な 障害に強い(例: データセンターの電源障害)  Transactional : 複数の Reliable Collection 跨ったトランザ クションが可能  Low latency: read はローカル、writeは最小 Network I/O kyrt inc 62016/6/16
  7. 7. プログラミングモデル kyrt inc 72016/6/16 reliable service reliable actor guest executable stateless service stateful service
  8. 8. Actorでは、 Reliable Collection と同じ仕組を 使って、state を保存しています。 kyrt inc 82016/6/16
  9. 9. kyrt inc 92016/6/16
  10. 10. Actor Actor model, Actor pattern 2016/6/16 kyrt inc 10
  11. 11. Actor とは何か? Carl Hewitt 1973、Wikipedia:Actorモデル Code and state encapsulation Single-thread Isolated components Asynchronous communication 結構昔からあるけど、メジャーにはなれず・・・・ kyrt inc 112016/6/16
  12. 12. 背景  マルチコアになり、複数インスタンスも普通になった。 Concurrency (並行性)処理に適した環境の普及は新らたな 可能性をもたらした  しかし、マルチスレッド、共有メモリ等を使った、Concurrency は、人類にはオーバーテクノロジー気味  いわゆるActorモデルには、並行処理に適したアイディアが 多く含まれる  Actorモデルは、 Concurrency 処理のモデル Vaughn Vernon 2013 InfoQ: Actorモデルとドメイン駆動設計 kyrt inc 122016/6/16
  13. 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
  14. 14. 状態 内部状態を持つ 個々のActorは独立していて、状態を共有し ない kyrt inc 142016/6/16 Person:Neo Age:40 Shop:Food Nudle:10 Bread:10 Shop:Hardwar e Hammer:5 Saws:10
  15. 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. 16. 処理 メッセージを受けると処理が動く 内部状態を変更 kyrt inc 162016/6/16 Shop:Food Nudle:10 Bread:10 -> 0 Person:Neo Age:40 Buy:Bread,10 Bread,10 在庫が10か ら0へ
  17. 17. メッセージは逐次 メッセージは1つづつ届き順番は保証されない メッセージはキューイングされ、Actor内の処理 では、ロックの必要が無い kyrt inc 172016/6/16 Shop:Food Nudle:10 Bread:10 キューイングされ る キューから取り出 して逐次処理 在庫をロックする 必要なし
  18. 18. まとめ Actor には、状態を持つ。 Actor の状態を変更できるのは、Actor自身(self)だけ Actorへメッセージを送ることが出来る Actorはメッセージを受けて逐次(serialized) =シング ルスレッド処理する Actorは、シングルスレッド動作なのでロックの必要は 無い 非同期メッセージしか無いObject kyrt inc 182016/6/16
  19. 19. オブジェクト + 非同期メッセージ = Actor kyrt inc 192016/6/16
  20. 20. オブジェクト + メッセージ = オブジェクト指向プログラミング kyrt inc 202016/6/16 パラダイム的に 親しみやすい
  21. 21. kyrt inc 212016/6/16
  22. 22. Actor in Service Fabric Service Fabric に置けるActor 2016/6/16 kyrt inc 22
  23. 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. 24. 3つの特徴 Scalable by Default 数百以上のseverにスケール Low Latency 状態の柔軟な保存、Persisted state、 Volatile state、No persisted state Simplified Concurrency turn base concurrency kyrt inc 242016/6/16
  25. 25. Actor Pattern 得手不得手 状態とロジックの小さな分離されて独立した ユニットが多数 (1,000 以上) ある Actorを跨った横断的な処理は苦手 kyrt inc 252016/6/16
  26. 26. Distributed Actors Service Fabric Cluster に分散Actorとして配置 Actorの内部状態は、Reliable Collectionへ保存 Service Fabricでは、Actorは、パーティション分割さ れたステートフルな Reliable Service .NET のコードからは、Actor型のインスタンスとして扱 う kyrt inc 262016/6/16
  27. 27. Virtual Actor Actorの有効期間≠メモリ内表現 Reliable Actors ランタイムは、Actor ID (Actor address) に要求が来た時に自動的 にそのActorをアクティブ化 一定期間未使用なアクティブなActorは、非ア クティブ化される kyrt inc 272016/6/16
  28. 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
  29. 29. kyrt inc 292016/6/16
  30. 30. Concurrency 2016/6/16 kyrt inc 30
  31. 31. 同時実行性  1 つの actor instance は、一 度に複数のリクエストを処理 することはできない  ①のように actor instance に 同時にリクエストが来た時は 順次処理される。この場合は actor instanceが スループッ トのボトルネックになる可能 性がある  ②、③のようなリクエストパ ターンが望ましい kyrt inc 312016/6/16 ① ② ③
  32. 32. Concurrency  ActorId1には、Methodが2つと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. 33. Concurrency のスコープ  lock は、per-actor で、異なったActor instanceの turnは同時に実行  turn の同時実行制御は、 Actor 全体ではなく、 Actor instance 毎  例:下図では、ActorId1のMethod1と、 ActorId2のMethod2が同時に実行 kyrt inc 332016/6/16
  34. 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. 35. dead lock 2 つのActor間に循環参照があると、デッド ロックの危険がある Actor Runtime は、dead lock 解消で、自動 的に actor call をtimeout させcallerで例外を throwする kyrt inc 352016/6/16
  36. 36. Actor Pattern 得手不得手 状態とロジックの小さな分離されて独立したユ ニットが多数 (1,000 以上) ある ⇨Actor毎に別々に動作するので、スケールし易い Actorを跨った横断的な処理は苦手 ⇨A1->A2->A3 ---- An と順番に呼んで、同じcontext になるものはlock時間が長くなる。参加するActorが 増えると循環参照も・・・ kyrt inc 362016/6/16
  37. 37. kyrt inc 372016/6/16
  38. 38. Lifecycle 2016/6/16 kyrt inc 38
  39. 39. Lifecycle Actorは、そのActor ID に初めてメッセージが送信さ れたときに、自動的にアクティブ化される 規定の時間後、Actor オブジェクトはガベージ コレクト される。その後、もう一度そのActor ID を使用すると、 新しいActor オブジェクトが構築される Actorのstateは、State Manager に格納されると、オ ブジェクトの有効期間よりも長く保持される ユーザーが明示的にActorとその状態を削除可能 kyrt inc 392016/6/16
  40. 40. Actorのlifecycle kyrt inc 402016/6/16 Actorのライフ サイクル、自動ガベージ コレクション、および手動による削除 ※timer callback は、idle time をリセットしない
  41. 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. 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へ
  43. 43. kyrt inc 432016/6/16
  44. 44. State management 2016/6/16 kyrt inc 44
  45. 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. 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. 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.
  48. 48. 終 kyrt inc 482016/6/16
  49. 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

×