Generating unique id numbers in Azure
•Als PPTX, PDF herunterladen•
3 gefällt mir•12,952 views
Global Windows Azure Boot Camp 2014 Japan の資料です。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Generating unique id numbers in Azure
Ähnlich wie Generating unique id numbers in Azure (20)
Mehr von Takekazu Omi
Mehr von Takekazu Omi (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (12)
Generating unique id numbers in Azure
- 1. Generating unique ID numbers in Microsoft Azure kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi 2014/3/29 1.0.1
- 2. Generating unique ID numbers in Microsoft Azure スケーラブルなID生成手法の比較と、twitter snowflakeに見る工夫 2014/2/26 kyrt @takekazuomi 2
- 3. Agenda • Challenge • スケーラブルなサービスとスケーラブルな採番 • twitter snowflake • スケーラブルな分散採番サービスの例 • Cloud Design Patterns • 応用例 kyrt @takekazuomi 32014/2/26
- 4. Challenge スケーラブルなサービスには、スケーラブルな採番が必須 課題と背景的な話 「またの名をChallengeを課題と訳さないで」 2014/2/26 kyrt @takekazuomi 4
- 5. ID生成の要件 1. ユニークである 重複が無い。これはIDをキーにしたいので当然ですね。 2. 時系列で増えていく（または減っていく） IDが生成される度に増加していくのは連番での重要な性質の一つ 3. 秒間の発行数 採番を一箇所で行わずに分散してするとスケールする 4. 連続性 連続した欠落の無い番号の生成 kyrt @takekazuomi 52014/2/26
- 6. ID生成のパターン 1. SQL Databaseの自動連番を使う • スケールしない、耐障害性を考慮すると複数台必要 2. ID Providerが完全に独立して存在する • GUID等、128bit 16 byte 3. 擬似ID Providerが、擬似IDを生成し、UNIQUE性は別システムで 担保される 4. ID Provider のNetwork Service を使う • Azure Cache, memcached, redis のincrement 等 5. ID Provider のCluster Serviceが実装されていてCluster内で合意を とってIDを生成する • snowflake kyrt @takekazuomi 6
- 7. 最初の２つ • SQL Database の利用 • 秒間の発番数、同時接続数に問題なければ、従来どおり利用可能 • 上記の問題があるなら、複数のDBを使う(sharding)という方法もある • しかし、仕組みとしてはちょっと重い。コストも高い。 • 秒間100程度まで • GUIDの利用 • クライアントで完結するので、速くてスケールする しかし • 128bit あって長い（16 byte) • 時系列で並ばない→ 時間由来のデータをprefixにすることで解決 kyrt @takekazuomi 7
- 8. 時系列のキーの例 .Netなら、Tikcs などを使う こんな感じ var id = string.Format("{0:D19}{1:N}",DateTime.UtcNow.Ticks, Guid.NewGuid()); var reverseId = string.Format("{0:D19}{1:N}“,long.MaxValue-DateTime.UtcNow.Ticks, Guid.NewGuid()); 結果 0635317467093215594d1931d619d7041c69ececd37383ca4ae 85880545697615502266d18953688dc4fbdb84da60f4d8e25c8 しかし長い・・・・・19+32で51文字。（工夫の余地はあるけど） kyrt @takekazuomi 8
- 9. 擬似ID Provider パターン • Clientで擬似的にIDを生成し て、UNIQUE性は、永続化レ イヤーで担保 • retryの発生頻度にパフォーマ ンスが依存 • 性能が永続化レイヤーに依存 • スケールのためには永続化レ イヤーの分散が必要 • SQL Database ＜ Storage Table (分散の容易度) kyrt @takekazuomi 9 SQL Database (Windows Azure) Storage Table or ④ retry Client 永続化レイヤー ① 擬似IDでInsert ② 重複無しで成功 ③ 重複有りで失敗
- 10. CacheなどのNetwork Service を利用 • RBDの自動連番より小さなレ イテンシー(1-2ms) • IDは時系列で増える • 耐障害性に課題 • HA構成、永続化オプションを 考慮 • 工夫 • 起動時の時間＋incremental number • 障害後にかぶらないように kyrt @takekazuomi 10 Client Cache IDを取得 Windows Azure Cache memcached or redis or
- 11. 課題整理 1. latency（レイテンシー） HAのために、Node間通信、永続化に時間がかかる。retryが発生すると 時間がかかる 2. reliability（信頼性） 採番系が一箇所なのは、UNIQUEの担保には有利だが、障害に弱くなる。 →分散すればOk 3. scalability（スケーラビリティ） 分散が必要。ID生成が分散してNode間通信が少なければ、スケーラビリ ティが上がる 4. data size（データサイズ） data sizeを大きくして冗長性を増せば、retryの頻度は下がる kyrt @takekazuomi 11
- 12. 特性の比較 kyrt @takekazuomi 12 latency reliability scalability data size SQL 自動連番 ◯ × × ◯ GUID等 ◯ ◯ ◯ × Pseudo ID and Retry △※１ ◯ ◯ △ Cache ◯ × △ ◯ Snowflake ◯ ◯ ◯ ◯ ※１ Data Sizeを小さくすると、衝突が起きやすくなるのでレイテンシーが上がる
- 13. ここまでのまとめ • 永続化ストレージ • latency（↓）、 reliability（↑）、 scalability（↓）、 data size（↑） • scalability改善には、パーティショニングが必要 → パーテーションを 跨いだUNIQUE性に制限、data size（↓） • On Memory • latency（↑）、 reliability（↓）、 scalability（↓）、 data size（↓） • reliability改善 • 複数NodeでHA構成にすれば良い。しかし、更新の度に、Node間で通信して合 意をとると latency が悪化 • scalability改善 • シングルNodeだとNodeの性能上限＝スケールの上限になってしまうので、複数 Node構成にしたい。しかし、 kyrt @takekazuomi 13 ↑：良 ↓：悪
- 16. snowflake の短い説明 • snowflake は、Twitter 社が作成した、UNIQUEなID生成のネッ トワークサービス。いくつかの簡単な保証で高いスケーラビリ ティを実現 • Twitter 社が、MySQLから Cassandra に移行するにあたって、 Cassandra には シーケンシャルな id 生成の仕組みが無かった ことから作成 • 参考： Twitter IDs, JSON and Snowflake https://dev.twitter.com/docs/twitter-ids-json-and-snowflake • ソースは https://github.com/twitter/snowflake/ に公開 • ライセンス、 Apache License, Version 2.0 kyrt @takekazuomi 162014/2/26
- 17. 基本的なアイディア • Clock Skew （クロックスキュー）に上手く対応することで、 オンメモリの計算だけでUNIQなIDを生成する • 永続化レイヤーの支援無しにUNIQなIDが生成できる、ID生成 はオンメモリなので速い（10k ids per second per process Snowflake https://github.com/twitter/snowflake/ ）というのが特 徴 • GUID v1と似ているが、半分のデータ量 64bit(long) で、おおよ そ時系列で増えていく「(Roughly) Time Ordered」 kyrt @takekazuomi 17
- 18. データ構造 • snowflake では、64bitを上記のように分割して使います • timeが時間由来の数字でミリ秒単位 • machine id は、datacenter id と、worker id で構成されていて、 Cluster内のNode固有の値 • sequence number は、同一時間の連番 kyrt @takekazuomi 18
- 19. ポイント • 時間由来のデータが先頭 41bit なので発番の時間順に並びます • ms で41bit だと (2^41)*(10^-3)/60/60/24/365 で約69年 • 各インスタンスは、 クラスター内でUNIQUEな、machine idを 持ちます • machine id が重複しない限りはIDは重複しない • 同時間内の発番では、 sequence number がインクリメントさ れます • ms 内の発番は、2^12 = 4096 まで 採番情報は on memory のみで処理 kyrt @takekazuomi 19
- 20. コード上の工夫 • なかなか興味深かったので、 IdWorker.scala をC#で写経 https://gist.github.com/takekazuomi/9571376 kyrt @takekazuomi 20
- 21. time skew対策 • 最後に発番してからtimestampが戻っていないか確認 L63 • 巻き戻っていればエラーで帰る（呼び出し側が再試行する） kyrt @takekazuomi 21
- 22. time 41bit の有効利用 • 開始時間を採番の開始時間と合わせてbitを有効利用 • TwEpoch は、2010/11/04。2010/11/01 + 69年 kyrt @takekazuomi 22
- 23. sequence • 同一timestampなら、_sequence をインクリメントして採番 `L72 <https://gist.github.com/takekazuomi/9571376#file- idworker-cs-L72>`_ • timestamp が進んでいれば、_sequence = 0 で採番 `L82 <https://gist.github.com/takekazuomi/9571376#file-idworker-cs- L82>`_ • 同一 timestamp 内で、_sequence がオーバーフローした場合は、 timestampが変わるまで待つ `L75 <https://gist.github.com/takekazuomi/9571376#file-idworker-cs- L75>`_ kyrt @takekazuomi 23
- 24. 起動時に Worker Idの重複を確認 構成 • snowflake のWorkerは複数の Nodeで構成 • Nodeの起動時にWorker Idの 重複をzookeeperを使って担 保 • GUID では、MAC Address 48bit が、machine Id相当 kyrt @takekazuomi 24 Client snowflake cluster ID要求 zookeeper cluster
- 25. machine idを重複させない仕組 • snowflakeでは、 machine id の下位5bitの Worker Idを zookeeperで管理しています • 起動時にWorker Idで、 Ephemeral Nodes を作成 kyrt @takekazuomi 25 /workerIdZkPath / /0 /1 /2 /n worker id の ephemeral node 1. 同じNode名では１つのみ 2. sessionが切れるとnodeは消える
- 26. Micorosoft Azure でどうするか • Azure Blobのリースを使うとほぼ同じことができます • Worker Idのpathのleaseが取れば、重複なしで起動Ok • インスタンスが生きてる間は、Leaseを更新 • 参考：Cloud Design Patterns • patterns & practices • Leader Election Pattern 、BlobDistributedMutex kyrt @takekazuomi 26 /workerIdZkPath / /0 /2 /n/1 Blob Lease で BlobDistributedMutex 利用
- 27. まとめ • snowflakeは、on memory で時間情報を元に高速にIDを生成す る • IDの一部にはmachine idが含まれていて、nodeの起動時に zookeeperを使って重複を確認する • 起動後は、node-zookeeper間の通信は ephemeral nodes の keep aliveのみ • 時間の巻き戻り対策がされている（time service対策） • zookeeper の ephemeral nodes 相当の機能はAzure Blobで実装 できる kyrt @takekazuomi 27
- 29. リファレンス • Twitter IDs, JSON and Snowflake • https://dev.twitter.com/docs/twitter-ids-json-and-snowflake • snowflake source code • https://github.com/twitter/snowflake/ • Cloud Design Patterns / patterns & practices • Leader Election Pattern http://msdn.microsoft.com/en-us/library/dn568104.aspx • BlobDistributedMutex Code http://aka.ms/cloud-design-patterns-sample • Apache ZooKeeper • http://zookeeper.apache.org/ • http://zookeeper.apache.org/doc/r3.2.1/zookeeperProgrammers.html#Ephemeral+Nodes • Twitterのsnowflakeについて（お勧め） • http://www.slideshare.net/moaikids/20130901-snowflake • 全ての情報は2014/3/29 時点のものです。 2014/2/12 kyrt @takekazuomi 29