第 2 回 JAZUG Tokyo NightAzure Service Fabric / Actor

Takekazu Omi takekazu.omi@kyrt.in

2016/6/16 R.0.9

2kyrt inc2016/6/16

自己紹介近江　武一JAZUG Azure Storage 担当（自称）Microsoft MVP for Azure http://www.slideshare.net/takekazuomi

kyrt inc 3

kyrt.in

github.com/takekazuomi

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 inc2016/6/16

5

復習2016/6/16 kyrt inc

6

Reliable Collection の 特徴高可用で低レイテンシーな永続化機構 Replicated ：状態の変更がレプリケートされ高可用 Persisted: データがディスクに永続化されるため、大規模な障害に強い ( 例 : データセンターの電源障害 ) Transactional : 複数の Reliable Collection 跨ったトランザクションが可能 Low latency: read はローカル、 write は最小 Network I/O

kyrt inc2016/6/16

7

プログラミングモデル

kyrt inc2016/6/16

reliable service reliable actor guest executable

stateless service stateful service

8

Actor では、 Reliable Collection と同じ仕組を使って、 state を保存しています。

kyrt inc2016/6/16

9kyrt inc2016/6/16

10

ActorActor model, Actor pattern

2016/6/16 kyrt inc

kyrt inc 11

Actor とは何か？Carl Hewitt 1973 、 Wikipedia ： Actorモデル

Code and state encapsulationSingle-thread Isolated componentsAsynchronous communication結構昔からあるけど、メジャーにはなれず・・・・

2016/6/16

12

背景 マルチコアになり、複数インスタンスも普通になった。

Concurrency （並行性）処理に適した環境の普及は新らたな可能性をもたらした しかし、マルチスレッド、共有メモリ等を使った、 Concurrency は、人類にはオーバーテクノロジー気味 いわゆる Actor モデルには、並行処理に適したアイディアが多く含まれる Actor モデルは、 Concurrency 処理のモデルVaughn Vernon 2013 InfoQ: Actorモデルとドメイン駆動設計

kyrt inc2016/6/16

13kyrt inc2016/6/16

Shop:FoodNudle:10Bread:10

Person:NeoAge:40

Person:TrinityAge:30

Shop:HardwareHammer:5Saws:10

Buy:Bread,10

Buy:Bread, 5

Buy:Hammer, 1

14

状態内部状態を持つ個々の Actor は独立していて、状態を共有しない

kyrt inc2016/6/16

Person:NeoAge:40

Shop:FoodNudle:10Bread:10

Shop:HardwareHammer:5Saws:10

15

メッセージ 非同期メッセージ 送信メッセージは、キューに積まれ。送信側は処理完了時に非同期に通知を受ける 各 Actor は Address を持ち、メッセージは Address へ送信する

kyrt inc2016/6/16

Shop:FoodNudle:10Bread:10

Person:NeoAge:40

Buy:Bread,10

Bread,10

16

処理メッセージを受けると処理が動く内部状態を変更

kyrt inc2016/6/16

Shop:FoodNudle:10Bread:10 -> 0

Person:NeoAge:40

Buy:Bread,10

Bread,10

在庫が１０から０へ

17

メッセージは逐次メッセージは１つづつ届き順番は保証されないメッセージはキューイングされ、 Actor 内の処理では、ロックの必要が無い

kyrt inc2016/6/16

Shop:FoodNudle:10Bread:10

Buy:Bread,10

Buy:Bread,10

Buy:Bread,10

キューイングされる

キューから取り出して逐次処理在庫をロックする必要なし

18

まとめActor には、状態を持つ。Actor の状態を変更できるのは、 Actor 自身 (self) だけActor へメッセージを送ることが出来るActor はメッセージを受けて逐次 (serialized) ＝シングルスレッド処理する Actor は、シングルスレッド動作なのでロックの必要は無い非同期メッセージしか無い Object

kyrt inc2016/6/16

19

オブジェクト＋非同期メッセージ＝Actor

kyrt inc2016/6/16

20

オブジェクト＋メッセージ＝オブジェクト指向プログラミングkyrt inc2016/6/16

？継承とか、メッセー

ジのデフォルトルート

宣言だったのでは？ パラダイム的に親しみやすい

21kyrt inc2016/6/16

22

Actor in Service FabricService Fabric に置ける Actor

2016/6/16 kyrt inc

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 inc2016/6/16

24

３つの特徴Scalable by Default数百以上の sever にスケールLow Latency状態の柔軟な保存、 Persisted

state、 Volatile state、 No persisted stateSimplified Concurrency

turn base concurrency

kyrt inc2016/6/16

25

Actor Pattern 得手不得手状態とロジックの小さな分離されて独立したユニットが多数 (1,000 以上 ) あるActor を跨った横断的な処理は苦手

kyrt inc2016/6/16

26

Distributed ActorsService Fabric Cluster に分散Actor として配置Actor の内部状態は、 Reliable Collection へ保存Service Fabric では、 Actor は、パーティション分割されたステートフルな Reliable Service.NET のコードからは、 Actor型のインスタンスとして扱う

kyrt inc2016/6/16

27

Virtual Actor

Actor の有効期間≠メモリ内表現Reliable Actors ランタイムは、 Actor

ID （ Actor address ） に要求が来た時に自動的にその Actor をアクティブ化一定期間未使用なアクティブな Actor は、非アクティブ化される

kyrt inc2016/6/16

28

Service Fabric に置ける Actor

Stateful と Stateless の 2種類ActorProxy経由の簡単な呼び出し

kyrt inc2016/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

29kyrt inc2016/6/16

30

Concurrency

2016/6/16 kyrt inc

31

同時実行性 1 つの actor instance は、一度に複数のリクエストを処理することはできない ①のように actor instance に同時にリクエストが来た時は順次処理される。この場合は actor instance が スループットのボトルネックになる可能性がある ②、③のようなリクエストパターンが望ましい

kyrt inc2016/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 inc2016/6/16

33

Concurrency のスコープ lock は、 per-actor で、異なった Actor instance の turn は同時に実行 turn の同時実行制御は、 Actor 全体ではなく、 Actor instance 毎 例：下図では、 ActorId1 の Method1 と、 ActorId2 の Method2 が同時に実行

kyrt inc2016/6/16

34

Reentrancy Actor Runtime では、既定で再入が許可右図では C->A のメッセージは許可 logical call context-based reentrancy  ReentrancyMode 属性で制御

kyrt inc2016/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 inc2016/6/16

36

Actor Pattern 得手不得手状態とロジックの小さな分離されて独立したユニットが多数 (1,000 以上 ) ある

⇨Actor毎に別々に動作するので、スケールし易いActor を跨った横断的な処理は苦手

⇨A1->A2->A3 ---- An と順番に呼んで、同じ context になるものは lock 時間が長くなる。参加する Actorが増えると循環参照も・・・kyrt inc2016/6/16

37kyrt inc2016/6/16

38

Lifecycle

2016/6/16 kyrt inc

39

LifecycleActor は、その Actor ID に初めてメッセージが送信されたときに、自動的にアクティブ化される規定の時間後、 Actor オブジェクトはガベージ コレクトされる。その後、もう一度その Actor ID を使用すると、新しい Actor オブジェクトが構築されるActor の state は、 State Manager に格納されると、オブジェクトの有効期間よりも長く保持されるユーザーが明示的に Actor とその状態を削除可能

kyrt inc2016/6/16

40

Actor の lifecycle

kyrt inc2016/6/16

Actorのライフ サイクル、自動ガベージ コレクション、および手動による削除

※timer callback は、 idle time をリセットしない

41

Actor と state の削除GC の対象となった場合、 Actorは、 deactivated されメモリ上から居なくなるだけで、 state は残りますState Manager 上から削除する場合は下記のように DeleteActorAsync を実行します

kyrt inc2016/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 inc2016/6/16

Inactive Actor

Active ActorMessage

GC

DeleteAsyn

c

DeleteAsyn

c

removed from active actors list and is deactivated. - Its state is deleted permanently

state is deleted permanently

Message が来ると、 Active へ

規定時間 idle で Inactive へ

43kyrt inc2016/6/16

kyrt inc 44

State management

2016/6/16

45

State PersistenceActor の 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 inc2016/6/16

46

State Manager

SaveStateAsync で明示的に保存 State Manager は、辞書のようなデータ構造で、キーと値のペアを保持 ( Reliable Collection)≒ ローリングアップデートしても Volatile -> Persisted の変更は無保証 replica 数の変更は可 状態の削除は、 StateManager.RemoveStateAsync(“count ”)

kyrt inc2016/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 inc2016/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

終kyrt inc2016/6/16

49

Actor libraries and frameworks⇨https://en.wikipedia.org/wiki/Actor_model#Act

or_libraries_and_frameworksMicrosoft Orleans 

⇨http://dotnet.github.io/orleans/

kyrt inc2016/6/16