Generating unique id numbers in Azure
Download as PPTX, PDF3 likes12,966 views
Global Windows Azure Boot Camp 2014 Japan の資料です。
![[Azure Deep Dive] Azure ネットワーキングを理解しよう!](https://cdn.slidesharecdn.com/ss_thumbnails/20151004madazurenetworking-151216085343-thumbnail.jpg?width=560&fit=bounds)
![[G-Tech2014講演資料] Microsoft Azureで負荷分散された仮想マシンを作ってみよう ～Amazon Web Servicesと比べな...](https://cdn.slidesharecdn.com/ss_thumbnails/c-4microsoftazure-141020195818-conversion-gate01-thumbnail.jpg?width=560&fit=bounds)
![AIシステムのセキュリティ：脅威となりつつあるAIの現状と課題 [English] Security of AI Systems: The Current...](https://cdn.slidesharecdn.com/ss_thumbnails/20241023css2024-250829030738-876ce56e-thumbnail.jpg?width=560&fit=bounds)
Generating unique id numbers in Azure
- 1. Generating unique ID numbers in Microsoft Azure kyrt Takekazu Omi [email protected] @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