Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Azure Fabric Service Reliable Collection

3,112 views

Published on

2016/5/18 Jazug Tokyo Night 第1回
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

Published in: Technology
  • Be the first to comment

Azure Fabric Service Reliable Collection

  1. 1. 第1回 JAZUG Tokyo Night Azure Service Fabric / Reliable Collection Takekazu Omi takekazu.omi@kyrt.in 2016/5/20 R.1.1
  2. 2. kyrt inc 22016/5/18
  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/5/18
  4. 4. はじめに  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. 5. 概要 2016/5/18 kyrt inc 5
  6. 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. 7. プログラミングモデル kyrt inc 72016/5/18 reliable service reliable actor guest executable stateless service stateful service
  8. 8. Reliable Collection Service Fabric(以下SF) の重要なビルディン グブロックの1つ 永続化付きのコレクション ⇨ 高可用(replicated) ⇨ スケーラブル(partitioned) ⇨ 低レイテンシー ⇨ transacted kyrt inc 82016/5/18
  9. 9. stateless services + external store kyrt inc 92016/4/16
  10. 10. stateful services kyrt inc 102016/4/16
  11. 11. kyrt inc 112016/5/18
  12. 12. 基本的構造 高可用で低レイテンシーな永続 化機構  書き込みは、Primaryのみ  全てのwriteは、 primary + replicas の majority quorum 3台構成なら、自分自身と他1 台に書ければ完了  read はローカルから kyrt inc 122016/5/18 Node 1/Primary Node 2/Secondary Node 3/Secondary
  13. 13. 特徴  Replicated:状態の変更がレプリケートされ高可用  Persisted: データがディスクに永続化されるため、大規模な 障害に強い(例: データセンターの電源障害)  Asynchronous: API は非同期で、IO の実行時にもnon- blocking  Transactional : 複数の Reliable Collection 跨ったトランザ クションが可能 kyrt inc 132016/5/18
  14. 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. 15. Collections.Concurrent との比較 Asynchronous: 操作は非同期、タスクを返す No out parameters: out の代わりに、 ConditionalValue<T> を使う Transactions: トランザクション オブジェクトを 使用することで、トランザクション内で複数の Reliable Collection に対してユーザーがグ ループ操作が可能 kyrt inc 152016/5/18
  16. 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. 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. 18. kyrt inc 182016/5/18
  19. 19. Isolation level Reliable Collections では、操作とノードのロール(Primary/Secondary)に よって自動的に 下記のisolation level のどちらかが選択される。 Transaction内は、Read Your Writes で、すべての書き込みは、後続の読 み取りによって認識される  Repeatable Read 同じトランザクション中では同じデータは何度読み取りしても毎回同じ値  Snapshot トランザクション中は開始時のスナップショットを読む kyrt inc 192016/5/18
  20. 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. 21. Persistence Model(1)  DataContractSerializer でシリアライズされて永続化  logとcheck point を使った永続性モデル(古典的な)、変更はlogに書き 込まれ、時折完全な状態を書き込む(checkpoint) この方法だと、sequential append-only writes なのでパフォーマンスが 出る kyrt inc 212016/5/18 開始 変更1 変更2 開始 開始+変更1 P S 開始 開始+変更1+変更2 開始 ① ③②
  22. 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. 23. Persistence Model(3)  check point ③ では、 Reliable State Manager が、 Reliable Collection に全データを DISK に書込むように要 求。書き込み終了後 Reliable State Managerは、log を切り 捨てる  ②の段階では、Primary, Secondary のどちらの log にも変 更1と変更2の内容が書き込まれている。もし、DISK容量が 無限ならば、原理的にはこのまま続けていっても論理適には 破綻しない。実際DISKは有限なので、いちど全データを同 期し直すタイミングを設けている。③(これがcheck point) kyrt inc 232016/5/18
  24. 24. Lock  Reliable Collection では、全てのトランザクションは2フェーズ。 ロックは、トランザクションが 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. 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は4秒
  26. 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. 27. 動作比較  上が、Reliable Collection,下がSQL Server  横軸が時間で、それぞれ、2つの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. 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. 29. 基本的な動き 2016/5/18 kyrt inc 29
  30. 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. 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. 32. lock dictionary methods がkeyを受け取ると、keyに 関連付けて、reader/writer lock を確保します。 この例(AddAsync)では write lock を取りますが、 読むだけの場合は、read lock を取ります もし2つ以上のスレッドから同時に同じキーで更 新をかけようとすると、1つのスレッドだけが更新 でき、残りはblock されます。デフォルトでは4秒 でタイムアウトし TimeoutException が発生しま す kyrt inc 322016/5/18
  33. 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. 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. 35. 最後に 2016/5/18 kyrt inc 35
  36. 36.  Reliable Collection は、Service Fabric の要の1つです。  残念ながら、現時点は、Service Fabric On Linux、.NET 以外のクライアント(guest executable) では使えません。  単体でも使いたいところですが、Service Fabric の パー テーション分割、リプリケーションを活用した機能なので、 切り離してしまうと利点半減以下かもしれません。  足回りは、RDBのストレージエンジン並に気合が入ってる ようです。  Backup/Restoreなどもあります  次回は、Actorをやります。 kyrt inc 362016/5/18
  37. 37. 履歴 2016/5/18 初版 2016/5/20 lock 部分を更新 kyrt inc 372016/5/18

×