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.
Generating unique ID numbers
in Microsoft Azure
kyrt Takekazu Omi
takekazu.omi@kyrt.in
@takekazuomi
2014/3/29 1.0.1
Generating unique ID numbers
in Microsoft Azure
スケーラブルなID生成手法の比較と、twitter snowflakeに見る工夫
2014/2/26 kyrt @takekazuomi 2
Agenda
• Challenge
• スケーラブルなサービスとスケーラブルな採番
• twitter snowflake
• スケーラブルな分散採番サービスの例
• Cloud Design Patterns
• 応用例
kyrt @tak...
Challenge
スケーラブルなサービスには、スケーラブルな採番が必須
課題と背景的な話
「またの名をChallengeを課題と訳さないで」
2014/2/26 kyrt @takekazuomi 4
ID生成の要件
1. ユニークである
重複が無い。これはIDをキーにしたいので当然ですね。
2. 時系列で増えていく(または減っていく)
IDが生成される度に増加していくのは連番での重要な性質の一つ
3. 秒間の発行数
採番を一箇所で行わずに分...
ID生成のパターン
1. SQL Databaseの自動連番を使う
• スケールしない、耐障害性を考慮すると複数台必要
2. ID Providerが完全に独立して存在する
• GUID等、128bit 16 byte
3. 擬似ID Prov...
最初の2つ
• SQL Database の利用
• 秒間の発番数、同時接続数に問題なければ、従来どおり利用可能
• 上記の問題があるなら、複数のDBを使う(sharding)という方法もある
• しかし、仕組みとしてはちょっと重い。コストも高...
時系列のキーの例
.Netなら、Tikcs などを使う
こんな感じ
var id =
string.Format("{0:D19}{1:N}",DateTime.UtcNow.Ticks, Guid.NewGuid());
var revers...
擬似ID Provider パターン
• Clientで擬似的にIDを生成し
て、UNIQUE性は、永続化レ
イヤーで担保
• retryの発生頻度にパフォーマ
ンスが依存
• 性能が永続化レイヤーに依存
• スケールのためには永続化レ
イヤー...
CacheなどのNetwork Service を利用
• RBDの自動連番より小さなレ
イテンシー(1-2ms)
• IDは時系列で増える
• 耐障害性に課題
• HA構成、永続化オプションを
考慮
• 工夫
• 起動時の時間+increme...
課題整理
1. latency(レイテンシー)
HAのために、Node間通信、永続化に時間がかかる。retryが発生すると
時間がかかる
2. reliability(信頼性)
採番系が一箇所なのは、UNIQUEの担保には有利だが、障害に弱くな...
特性の比較
kyrt @takekazuomi 12
latency reliability scalability data size
SQL 自動連番 ◯ × × ◯
GUID等 ◯ ◯ ◯ ×
Pseudo ID and Retry △※...
ここまでのまとめ
• 永続化ストレージ
• latency(↓)、 reliability(↑)、 scalability(↓)、 data size(↑)
• scalability改善には、パーティショニングが必要 → パーテーションを
跨...
こんなのがあったら
•GUIDのように速く
•SQL の自動採番のように並んで
•簡単に使える
•そんなに長くない(longぐらいで入ると嬉し
い)
kyrt @takekazuomi 14
twitter snowflake
https://github.com/twitter/snowflake/
kyrt @takekazuomi 15
snowflake の短い説明
• snowflake は、Twitter 社が作成した、UNIQUEなID生成のネッ
トワークサービス。いくつかの簡単な保証で高いスケーラビリ
ティを実現
• Twitter 社が、MySQLから Cassan...
基本的なアイディア
• Clock Skew (クロックスキュー)に上手く対応することで、
オンメモリの計算だけでUNIQなIDを生成する
• 永続化レイヤーの支援無しにUNIQなIDが生成できる、ID生成
はオンメモリなので速い(10k id...
データ構造
• snowflake では、64bitを上記のように分割して使います
• timeが時間由来の数字でミリ秒単位
• machine id は、datacenter id と、worker id で構成されていて、
Cluster内...
ポイント
• 時間由来のデータが先頭 41bit なので発番の時間順に並びます
• ms で41bit だと (2^41)*(10^-3)/60/60/24/365 で約69年
• 各インスタンスは、 クラスター内でUNIQUEな、machin...
コード上の工夫
• なかなか興味深かったので、 IdWorker.scala をC#で写経
https://gist.github.com/takekazuomi/9571376
kyrt @takekazuomi 20
time skew対策
• 最後に発番してからtimestampが戻っていないか確認 L63
• 巻き戻っていればエラーで帰る(呼び出し側が再試行する)
kyrt @takekazuomi 21
time 41bit の有効利用
• 開始時間を採番の開始時間と合わせてbitを有効利用
• TwEpoch は、2010/11/04。2010/11/01 + 69年
kyrt @takekazuomi 22
sequence
• 同一timestampなら、_sequence をインクリメントして採番
`L72 <https://gist.github.com/takekazuomi/9571376#file-
idworker-cs-L72>`_...
起動時に
Worker Idの重複を確認
構成
• snowflake のWorkerは複数の
Nodeで構成
• Nodeの起動時にWorker Idの
重複をzookeeperを使って担
保
• GUID では、MAC Address
48...
machine idを重複させない仕組
• snowflakeでは、 machine id の下位5bitの Worker Idを
zookeeperで管理しています
• 起動時にWorker Idで、 Ephemeral Nodes を作成
...
Micorosoft Azure でどうするか
• Azure Blobのリースを使うとほぼ同じことができます
• Worker Idのpathのleaseが取れば、重複なしで起動Ok
• インスタンスが生きてる間は、Leaseを更新
• 参考...
まとめ
• snowflakeは、on memory で時間情報を元に高速にIDを生成す
る
• IDの一部にはmachine idが含まれていて、nodeの起動時に
zookeeperを使って重複を確認する
• 起動後は、node-zooke...
Appendix
2014/2/26 kyrt @takekazuomi 28
リファレンス
• Twitter IDs, JSON and Snowflake
• https://dev.twitter.com/docs/twitter-ids-json-and-snowflake
• snowflake source ...
Prochain SlideShare
Chargement dans…5
×

Generating unique id numbers in Azure

12 210 vues

Publié le

Global Windows Azure Boot Camp 2014 Japan の資料です。

Publié dans : Technologie
  • Soyez le premier à commenter

Generating unique id numbers in Azure

  1. 1. Generating unique ID numbers in Microsoft Azure kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi 2014/3/29 1.0.1
  2. 2. Generating unique ID numbers in Microsoft Azure スケーラブルなID生成手法の比較と、twitter snowflakeに見る工夫 2014/2/26 kyrt @takekazuomi 2
  3. 3. Agenda • Challenge • スケーラブルなサービスとスケーラブルな採番 • twitter snowflake • スケーラブルな分散採番サービスの例 • Cloud Design Patterns • 応用例 kyrt @takekazuomi 32014/2/26
  4. 4. Challenge スケーラブルなサービスには、スケーラブルな採番が必須 課題と背景的な話 「またの名をChallengeを課題と訳さないで」 2014/2/26 kyrt @takekazuomi 4
  5. 5. ID生成の要件 1. ユニークである 重複が無い。これはIDをキーにしたいので当然ですね。 2. 時系列で増えていく(または減っていく) IDが生成される度に増加していくのは連番での重要な性質の一つ 3. 秒間の発行数 採番を一箇所で行わずに分散してするとスケールする 4. 連続性 連続した欠落の無い番号の生成 kyrt @takekazuomi 52014/2/26
  6. 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. 7. 最初の2つ • SQL Database の利用 • 秒間の発番数、同時接続数に問題なければ、従来どおり利用可能 • 上記の問題があるなら、複数のDBを使う(sharding)という方法もある • しかし、仕組みとしてはちょっと重い。コストも高い。 • 秒間100程度まで • GUIDの利用 • クライアントで完結するので、速くてスケールする しかし • 128bit あって長い(16 byte) • 時系列で並ばない→ 時間由来のデータをprefixにすることで解決 kyrt @takekazuomi 7
  8. 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. 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. 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. 11. 課題整理 1. latency(レイテンシー) HAのために、Node間通信、永続化に時間がかかる。retryが発生すると 時間がかかる 2. reliability(信頼性) 採番系が一箇所なのは、UNIQUEの担保には有利だが、障害に弱くなる。 →分散すればOk 3. scalability(スケーラビリティ) 分散が必要。ID生成が分散してNode間通信が少なければ、スケーラビリ ティが上がる 4. data size(データサイズ) data sizeを大きくして冗長性を増せば、retryの頻度は下がる kyrt @takekazuomi 11
  12. 12. 特性の比較 kyrt @takekazuomi 12 latency reliability scalability data size SQL 自動連番 ◯ × × ◯ GUID等 ◯ ◯ ◯ × Pseudo ID and Retry △※1 ◯ ◯ △ Cache ◯ × △ ◯ Snowflake ◯ ◯ ◯ ◯ ※1 Data Sizeを小さくすると、衝突が起きやすくなるのでレイテンシーが上がる
  13. 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 ↑:良 ↓:悪
  14. 14. こんなのがあったら •GUIDのように速く •SQL の自動採番のように並んで •簡単に使える •そんなに長くない(longぐらいで入ると嬉し い) kyrt @takekazuomi 14
  15. 15. twitter snowflake https://github.com/twitter/snowflake/ kyrt @takekazuomi 15
  16. 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. 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. 18. データ構造 • snowflake では、64bitを上記のように分割して使います • timeが時間由来の数字でミリ秒単位 • machine id は、datacenter id と、worker id で構成されていて、 Cluster内のNode固有の値 • sequence number は、同一時間の連番 kyrt @takekazuomi 18
  19. 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. 20. コード上の工夫 • なかなか興味深かったので、 IdWorker.scala をC#で写経 https://gist.github.com/takekazuomi/9571376 kyrt @takekazuomi 20
  21. 21. time skew対策 • 最後に発番してからtimestampが戻っていないか確認 L63 • 巻き戻っていればエラーで帰る(呼び出し側が再試行する) kyrt @takekazuomi 21
  22. 22. time 41bit の有効利用 • 開始時間を採番の開始時間と合わせてbitを有効利用 • TwEpoch は、2010/11/04。2010/11/01 + 69年 kyrt @takekazuomi 22
  23. 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. 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. 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名では1つのみ 2. sessionが切れるとnodeは消える
  26. 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. 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
  28. 28. Appendix 2014/2/26 kyrt @takekazuomi 28
  29. 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

×