2016/5/18 Jazug Tokyo Night 第１回 Azure Fabric Service Reliable Collection の紹介 Azure の Microservice Platform として登場した、Service Fabric 。その中でも、特徴的な機能であるReliable Collection に迫ります。 5/20 lock 関連を更新しました。 詳しくは、こちらも合わせてお読み下さい。 http://kyrt.in/2016/05/20/reliable_collection_lock.html

1. 第1回 JAZUG Tokyo Night
Azure Service Fabric /
Reliable Collection
Takekazu Omi
takekazu.omi@kyrt.in
2016/5/20 R.1.1

2. kyrt inc 22016/5/18

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/5/18

4. はじめに
 ４回ほどに分けて、Service Fabric の話をする（予定）
 (1) Reliable Collection, (2) Actor, (3) Cluster の作成、(4) Cluster の管理
運用 （予定）、今回はReliable Collection
 先日のGABCで、概要的な話をしたので、ここではもう少しだけ、中に入って
Service Fabric の特徴的な部分の話をします。（あまり、Microservice という
話はしません）
 Global Azure Bootcamp で話したService Fabricの概要の動画
⇨ https://youtu.be/bVWHPjcjeoc?t=38m
 過去に、話した時の資料
⇨ http://www.slideshare.net/takekazuomi/presentations
 概要は週末に「C#ユーザー会 //build/ 2016振り返り 勉強会」で話します
⇨ https://csugjp.doorkeeper.jp/events/43951
kyrt inc 42016/5/18

5. 概要
2016/5/18 kyrt inc 5

6. API Gateway
kyrt inc 62016/5/18
APIGateway/stateless
Naming Service
P1
P2
Pn
S2
S3
Sn
S1
Service Fabric Cluster
P S S
P S S
P S S
statefulservice

7. プログラミングモデル
kyrt inc 72016/5/18
reliable service reliable actor guest executable
stateless service stateful service

8. Reliable Collection
Service Fabric(以下SF) の重要なビルディン
グブロックの１つ
永続化付きのコレクション
⇨ 高可用（replicated）
⇨ スケーラブル（partitioned）
⇨ 低レイテンシー
⇨ transacted
kyrt inc 82016/5/18

9. stateless services + external store
kyrt inc 92016/4/16

10. stateful services
kyrt inc 102016/4/16

11. kyrt inc 112016/5/18

12. 基本的構造
高可用で低レイテンシーな永続
化機構
 書き込みは、Primaryのみ
 全てのwriteは、 primary +
replicas の majority quorum
３台構成なら、自分自身と他１
台に書ければ完了
 read はローカルから
kyrt inc 122016/5/18
Node 1/Primary
Node 2/Secondary Node 3/Secondary

13. 特徴
 Replicated：状態の変更がレプリケートされ高可用
 Persisted: データがディスクに永続化されるため、大規模な
障害に強い(例: データセンターの電源障害)
 Asynchronous: API は非同期で、IO の実行時にもnon-
blocking
 Transactional : 複数の Reliable Collection 跨ったトランザ
クションが可能
kyrt inc 132016/5/18

14. Microsoft.ServiceFabric.Data.Collections
Microsoft.ServiceFabric.Data.Collections は次
の 2 つだけ。
Reliable Dictionary<T>: key/value コレクション、
ConcurrentDictionary の Reliable Collection
版
Reliable Queue<T>: FIFO コレクション、
ConcurrentQueueの Reliable Collection 版
kyrt inc 142016/5/18

15. Collections.Concurrent との比較
Asynchronous: 操作は非同期、タスクを返す
No out parameters: out の代わりに、
ConditionalValue<T> を使う
Transactions: トランザクション オブジェクトを
使用することで、トランザクション内で複数の
Reliable Collection に対してユーザーがグ
ループ操作が可能
kyrt inc 152016/5/18

16. 例；
kyrt inc 162016/5/18
protected override async Task RunAsync(CancellationToken cancellationToken)
{
var myDic = await StateManager.GetOrAddAsync<IReliableDictionary<string, long>>("myDictionary");
var myQueue = await StateManager.GetOrAddAsync<IReliableQueue<long>>("myQueue");
var i = 0;
while (true) {
cancellationToken.ThrowIfCancellationRequested();
using (var tx = StateManager.CreateTransaction()){
ConditionalValue<long> rd = await myDic.TryGetValueAsync(tx, "Counter");
long rq = await myQueue.GetCountAsync(tx);
ServiceEventSource.Current.ServiceMessage(this, "Current Counter Value: {0}, {1}",
rd.HasValue ? rd.Value.ToString() : "Value does not exist.", rq);
var l = await myDic.AddOrUpdateAsync(tx, "Counter", 1, (key, value) => ++value);
// if (++i%10 == 0) continue;
await myQueue.EnqueueAsync(tx, l);
await tx.CommitAsync();
}
await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
}
}
https://gist.github.com/takekazuomi/c17e497424dfc7e03e0bfa4d1e9c2877

17. 使用上の注意
Reliable Collections のデータは、Data
Contract Serializer でシリアライズ
Types Supported by the Data Contract
Serializer
https://msdn.microsoft.com/en-
us/library/ms731923(v=vs.110).aspx
kyrt inc 172016/5/18

18. kyrt inc 182016/5/18

19. Isolation level
Reliable Collections では、操作とノードのロール(Primary/Secondary）に
よって自動的に 下記のisolation level のどちらかが選択される。
Transaction内は、Read Your Writes で、すべての書き込みは、後続の読
み取りによって認識される
 Repeatable Read
同じトランザクション中では同じデータは何度読み取りしても毎回同じ値
 Snapshot
トランザクション中は開始時のスナップショットを読む
kyrt inc 192016/5/18

20. Role/Operation別 Isolation level
Operation ＼ Role Primary Secondary
Single entity read Repeatable Read Snapshot
Enumeration ＼ Count Snapshot Snapshot
kyrt inc 202016/5/18
Operation ＼ Role Primary Secondary
Single entity read Snapshot Snapshot
Enumeration ＼ Count Snapshot Snapshot
Reliable Dictionary
Reliable Queue
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-reliable-collections/#isolation-levels

21. Persistence Model(1)
 DataContractSerializer でシリアライズされて永続化
 logとcheck point を使った永続性モデル（古典的な）、変更はlogに書き
込まれ、時折完全な状態を書き込む(checkpoint)
この方法だと、sequential append-only writes なのでパフォーマンスが
出る
kyrt inc 212016/5/18
開始 変更１ 変更２ 開始
開始＋変更１
P
S 開始 開始＋変更１＋変更２ 開始
① ③②

22. Persistence Model(2)
commit の時の時に、Reliable State Manager が、
log に記録し、log record をレプリカに配布。 （①と
②、check point が走らなかったとき）
Reliable Collection はメモリー内の操作だけを管理
ノードに障害が起きて再起動した場合、 Reliable
State Managerが、ローカルの log から Reliable
Collectionを復元
kyrt inc 222016/5/18

23. Persistence Model(３)
 check point ③ では、 Reliable State Manager が、
Reliable Collection に全データを DISK に書込むように要
求。書き込み終了後 Reliable State Managerは、log を切り
捨てる
 ②の段階では、Primary, Secondary のどちらの log にも変
更１と変更２の内容が書き込まれている。もし、DISK容量が
無限ならば、原理的にはこのまま続けていっても論理適には
破綻しない。実際DISKは有限なので、いちど全データを同
期し直すタイミングを設けている。③（これがcheck point）
kyrt inc 232016/5/18

24. Lock
 Reliable Collection では、全てのトランザクションは２フェーズ。
ロックは、トランザクションが abort または commit で終了するまで
解放されない
 Reliable Collection は、基本 Exclusive locks を取得する。読み
取りの場合、いくつかの要因に依存して lock が変わる。
 snapshot isolation の場合は lock free。 repeatable read
operation の場合は、デフォルトは shared locks です。ただし、
repeatable read operation の場合は、ユーザーは shared locks
では無く、 update lock を要求できます。
kyrt inc 242016/5/18

25. Lock compatibility matrix
Request ＼ Granted None Shared Update Exclusive
Shared No conflict No conflict Conflict Conflict
Update No conflict No conflict Conflict Conflict
Exclusive No conflict Conflict Conflict Conflict
kyrt inc 252016/5/18
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-reliable-collections/
https://technet.microsoft.com/ja-jp/library/ms175519(v=sql.105).aspx
Task<ConditionalValue<TValue>> TryGetValueAsync(
ITransaction tx,
TKey key,
LockMode lockMode
)
Default/Update
Granted：既に取られてるロック
Request：要求されたロック
Timeoutは４秒

26. G(U)/R(S)時のSQL Serverとの違い
 前図のmatrix の赤枠の部分は、 Reliable Collection と、SQL
Serverで違います
 この差によって、Reliable Collectionは、書込に最適化され、 SQL
Serverは読み込みに最適化されるという違いが生まれます。
 Reliable Collection では、update lockの期間は短くほとんどの場
合、exclusive に昇格して終わることを前提としています。
 それに対して、SQL Serverでは書込はshard lock が開放される
まで待機されます。
kyrt inc 262016/5/18

27. 動作比較
 上が、Reliable Collection,下がSQL Server
 横軸が時間で、それぞれ、２つのtransactionがある
 黄色線が、tnxid 2 が、shard lock を要求したタイミング
kyrt inc 272016/5/18
UTxnId 1
STxnId 2
U->X
S
UTxnId 1
STxnId 2
U->X
Reliable Collection
SQL ServerSQL Server

28. 動作解説
TxnId1が、update lockを掛けている時、TxnId2
がShard Lockを要求した場合、Reliable
CollectionではUpdate Lock が、Exclusive
Lock になって更新が終わりlockが開放されるま
で待機
それに対して、SQL Serverでは、Shard Lockは
成功します。Shard lockが開放されてから、
Exclusive lock ->更新という処理に流れる
kyrt inc 282016/5/18

29. 基本的な動き
2016/5/18 kyrt inc 29

30. ITransaction
Reliable Collection の全ての操作は、
ITransaction が必要
ITransaction は、StateManager の
CreateTransaction で取得
kyrt inc 302016/5/18
参照：Working with Reliable Collections
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-work-with-reliable-collections/

31. code sample
https://gist.github.com/takekazuomi/7d75b
61cbb4596e5f638f40e0196a32d
kyrt inc 312016/5/18
private async Task MyFunction(string dictionaryName, string key, long value, CancellationToken cancellationToken)
{
var myDic = await StateManager.GetOrAddAsync<IReliableDictionary<string, long>>(dictionaryName);
retry:
try
{
using (ITransaction tx = StateManager.CreateTransaction())
{
await myDic.AddAsync(tx, key, value);
await tx.CommitAsync();
}
}
catch (TimeoutException)
{
await Task.Delay(100, cancellationToken); goto retry;
}
}
https://gist.github.com/takekazuomi/7d75b61cbb4596e5f638f40e0196a32d

32. lock
dictionary methods がkeyを受け取ると、keyに
関連付けて、reader/writer lock を確保します。
この例(AddAsync)では write lock を取りますが、
読むだけの場合は、read lock を取ります
もし２つ以上のスレッドから同時に同じキーで更
新をかけようとすると、１つのスレッドだけが更新
でき、残りはblock されます。デフォルトでは4秒
でタイムアウトし TimeoutException が発生しま
す
kyrt inc 322016/5/18

33. read-your-own-writes
lock が取れると、 key と value object の references
をITransaction オブジェクトに関連付けられた、内部
的なディクショナリに設定します。こうやって、read-
your-own-writes の semantics を実装しています。
commit 前でも更新されたように見えるってことです。
次に、 AddAsync は、 key と value objects は、byte
array にシリアライズして、local node の log file に追
記し、全ての secondary replicas にkey/valueの情報
が配布します。しかし、commit されるまでは、ディク
ショナリのデータの一部とはみなされません。
kyrt inc 332016/5/18

34. commit
 CommitAsync が呼ばれると、local node のlog file にコ
ミット情報を書込んで、全てのreplica に配布します。 返信
が、quorum (majority) になれば、書き込み成功で、ロック
はリリースされ、他のスレッドでもその値を操作できるよう
になります
 CommitAsync が呼ばれない場合 、ITransaction object
はdispose されます。 その場合、Service Fabric はabort
情報をlocal node の log file に追記します。この場合は、
secondary replica には何も送信する必要はありません。
その後、すべてのロックがリリースされます。
kyrt inc 342016/5/18

35. 最後に
2016/5/18 kyrt inc 35

36.  Reliable Collection は、Service Fabric の要の１つです。
 残念ながら、現時点は、Service Fabric On Linux、.NET
以外のクライアント（guest executable) では使えません。
 単体でも使いたいところですが、Service Fabric の パー
テーション分割、リプリケーションを活用した機能なので、
切り離してしまうと利点半減以下かもしれません。
 足回りは、RDBのストレージエンジン並に気合が入ってる
ようです。
 Backup/Restoreなどもあります
 次回は、Actorをやります。
kyrt inc 362016/5/18

37. 履歴
2016/5/18 初版
2016/5/20 lock 部分を更新
kyrt inc 372016/5/18