Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Azure Fabric Service Reliable Collection

3 110 vues

Publié le

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

Publié dans : Technologie
  • Soyez le premier à commenter

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

×