Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Azure Service Fabric Actor

1 171 vues

Publié le

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

Publié dans : Technologie
  • Soyez le premier à commenter

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

×