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

1. 第2回 JAZUG Tokyo Night
Azure Service Fabric / Actor
Takekazu Omi
takekazu.omi@kyrt.in
2016/6/16 R.0.9

2. kyrt inc 22016/6/16

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

5. 復習
2016/6/16 kyrt inc 5

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

9. kyrt inc 92016/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

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. メッセージ
 非同期メッセージ
 送信メッセージは、キューに積まれ。送信側は処理完了時に非同
期に通知を受ける
 各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
在庫が１０か
ら０へ

17. メッセージは逐次
メッセージは１つづつ届き順番は保証されない
メッセージはキューイングされ、Actor内の処理
では、ロックの必要が無い
kyrt inc 172016/6/16
Shop:Food
Nudle:10
Bread:10
キューイングされ
る
キューから取り出
して逐次処理
在庫をロックする
必要なし

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

19. オブジェクト
＋
非同期メッセージ
＝
Actor
kyrt inc 192016/6/16

20. オブジェクト
＋
メッセージ
＝
オブジェクト指向プログラミング
kyrt inc 202016/6/16
パラダイム的に
親しみやすい

21. kyrt inc 212016/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

29. kyrt inc 292016/6/16

30. Concurrency
2016/6/16 kyrt inc 30

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

37. kyrt inc 372016/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へ

43. kyrt inc 432016/6/16

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.

48. 終
kyrt inc 482016/6/16

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