第 1 回 JAZUG Tokyo NightAzure Service Fabric /

Reliable Collection

Takekazu Omi takekazu.omi@kyrt.in

2016/5/20 R.1.1

2kyrt inc2016/5/18

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

kyrt inc 3

kyrt.in

github.com/takekazuomi

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

5

概要2016/5/18 kyrt inc

6

API Gateway

kyrt inc2016/5/18

API Gateway/stateless

Naming Service

P1

P2

Pn

S2

S3

Sn

S1

Service Fabric Cluster

P S S

P S S

P S S

stat

eful s

ervice

ServiceP

artition

Resolver

7

プログラミングモデル

kyrt inc2016/5/18

reliable service reliable actor guest executable

stateless service stateful service

8

Reliable Collection

Service Fabric( 以下 SF) の重要なビルディングブロックの１つ永続化付きのコレクション

⇨ 高可用（ replicated ）⇨ スケーラブル（ partitioned ）⇨ 低レイテンシー⇨ transacted

kyrt inc2016/5/18

9

stateless services + external store

kyrt inc2016/4/16

10

 stateful services

kyrt inc2016/4/16

11kyrt inc2016/5/18

12

基本的構造高可用で低レイテンシーな永続化機構 書き込みは、 Primary のみ 全ての write は、 primary +

replicas の majority quorum３台構成なら、自分自身と他１台に書ければ完了 read はローカルから

kyrt inc2016/5/18

Node 1/Primary

Node 2/Secondary Node 3/Secondary

13

特徴 Replicated ：状態の変更がレプリケートされ高可用 Persisted: データがディスクに永続化されるため、大規模な障害に強い ( 例 : データセンターの電源障害 ) Asynchronous: API は非同期で、 IO の実行時にも non-

blocking Transactional : 複数の Reliable Collection 跨ったトランザクションが可能

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

kyrt inc 15

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

2016/5/18

16

例；

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

Serializerhttps://msdn.microsoft.com/en-us/library/ms731923(v=vs.110).aspx

kyrt inc2016/5/18

18kyrt inc2016/5/18

19

Isolation level

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

kyrt inc2016/5/18

20

Role/Operation 別 Isolation level

Operation ＼ Role Primary Secondary

Single entity read Repeatable Read Snapshot

Enumeration ＼ Count Snapshot Snapshot

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

kyrt inc 21

Persistence Model(1) DataContractSerializer でシリアライズされて永続化 log と check point を使った永続性モデル（古典的な）、変更は logに書き込まれ、時折完全な状態を書き込む (checkpoint)この方法だと、 sequential append-only writes なのでパフォーマンスが出る

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

kyrt inc 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

2016/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 は４秒

kyrt inc 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 が開放されるまで待機されます。

2016/5/18

27

動作比較

上が、Reliable Collection, 下がSQL Server 横軸が時間で、それぞれ、２つの transaction がある 黄色線が、 tnxid 2 が、shard lock を要求したタイミング

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

29

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

30

ITransaction

Reliable Collection の全ての操作は、 ITransaction が必要

ITransaction は、 StateManager の CreateTransaction で取得

kyrt inc2016/5/18

参照： Working with Reliable Collectionshttps://azure.microsoft.com/en-us/documentation/articles/service-fabric-work-with-reliable-collections/

31

code sample

https://gist.github.com/takekazuomi/7d75b61cbb4596e5f638f40e0196a32d

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

kyrt inc 32

lock

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

2016/5/18

kyrt inc 33

read-your-own-writeslock が取れると、 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 されるまでは、ディクショナリのデータの一部とはみなされません。2016/5/18

34

commitCommitAsync が呼ばれると、 local node の log file にコミット情報を書込んで、全ての replica に配布します。 返信が、 quorum (majority) になれば、書き込み成功で、ロックはリリースされ、他のスレッドでもその値を操作できるようになりますCommitAsync が呼ばれない場合 、 ITransaction object は

dispose されます。 その場合、 Service Fabric は abort 情報を local node の log file に追記します。この場合は、 secondary replica には何も送信する必要はありません。その後、すべてのロックがリリースされます。kyrt inc2016/5/18

35

最後に2016/5/18 kyrt inc

36

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

kyrt inc2016/5/18

kyrt inc 37

履歴2016/5/18 初版2016/5/20 lock 部分を更新

2016/5/18