Download to read offline
![5.2.3 Chord (4)
• ノード1が k=26 を解決する手順
1. ノード1にて、
FT[5] <= k < FT[1]
なので、ノード5に要求を送る
2. ノード18 にて、
FT[2] <= k < FT[3]
なので、ノード20 に要求を送る
3. ノード20にて、
FT[1] <= k < FT[2]
なので、ノード21に要求を送る
4. ノード21にて、kのsuccessorは
ノード28だと知っているので、
28にデータを問い合わせる
フィンガーテーブルを用いると、システムを構成するノード
をN個として、O(logN)
ステップでデータを発見できる！
2013/04/27
第4回 分散システム本読書会
14
/
25](https://image.slidesharecdn.com/naming-130426073512-phpapp01/85/Naming-14-320.jpg)
![5.3.3 名前空間の実装
• 名前空間の分散
– 大規模な分散システムの名前空間は、通常階層的に構成される
– [Cheriton
and
Mann,
1989]
は、以下の３つの層に分割した
– グローバル層
• ルートノードと論理的に近いディレクトリノードで形成される
• ディレクトリテーブルの内容がほとんど書き換えられない、安定性がある
– 部門管理層
• １つの組織の中で一緒に管理されるディレクトリノードによって形成される
• グローバル層のノードよりは変化が多いが、比較的安定している
– マネージャ層
• よく変化する可能性があるノードから成り立つ
• ローカルネットワークのホストに相当するノードが、この層に属する
2013/04/27
第4回 分散システム本読書会
21
/
25](https://image.slidesharecdn.com/naming-130426073512-phpapp01/85/Naming-21-320.jpg)
![分散型DNSの実装
• DNSのスケーラビリティ
– 上位レベルのノードほど、下位レベルのノードに比べて多くの
要求を受信する
– キャッシュを使うことで、現状この問題を回避している
• 分散ハッシュテーブル(DHT)を用いたDNSの実装
– CoDoNS
[
Ramasubramanian
and
Sirer,
2004a]
にて検討されている
– 利点
• DHTベースの実装にマッピングすることで、スケーラビリティの問題を解決
– 欠点
• 名前構造を失っている
– ある特定のドメイン内のすべての子を探索することが困難
– DHTでは範囲検索を行うのが難しい
2013/04/27
第4回 分散システム本読書会
25
/
25](https://image.slidesharecdn.com/naming-130426073512-phpapp01/85/Naming-25-320.jpg)
![[Cloud OnAir] BigQuery の仕組みからベストプラクティスまでのご紹介 2018年9月6日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/dddddd-180906091548-thumbnail.jpg?width=640&height=640&fit=bounds)
Naming
- 1. 第4回 分散システム本読書会 名前付け /Naming @nishio_dens 2013/04/27 第4回 分散システム本読書会
- 2. 本章の目標 名前と識別子から、いかにしてアドレスを 解決するかが本章の重要なテーマ • 様々な名前解決の仕組みを理解する – フラットな名前から、どのようにしてエンティティを 見つけるかを理解する – 構造化された名前から、どのようにしてエンティティ を見つけるかを理解する – 分散システムでよく用いられる属性ベース名前付けを 理解する 2013/04/27 第4回 分散システム本読書会 2 / 25
- 3. 5.1 名前・識別子・アドレス • 名前 – エンティティ（ホストやファイル等)を参照するため に使われるビット列、または文字列 • 識別子 (Identifier / ID ) – エンティティを一意に識別するための名前 • アドレス – アクセスポイントの名前 – アクセスポイントとは? • エンティティにアクセスする際に利用するエンティティ 2013/04/27 第4回 分散システム本読書会 3 / 25
- 4. ヒューマンフレンドリーな名前 • 人間にとって扱いやすいように作られた名前を ヒューマンフレンドリーな名前と呼ぶ • 例) – ファイル名 • UNIXの場合、255文字以内の文字列をユーザが定義可能 – ドメイン名 • DNSではドメイン名からIPアドレスを検索 • ドメイン名は人間が覚えやすい 2013/04/27 第4回 分散システム本読書会 4 / 25
- 5. 5.2 フラットな名前付け • フラットな名前 – アクセスポイントを特定するような情報を含まない名前のこと • フラットな名前からどのようにしてエンティティを 特定するか? – 5.2.1 ブロードキャストとマルチキャスト – 5.2.1 転送ポインタ – 5.2.2 ホームベースアプローチ – 5.2.3 分散ハッシュテーブル – 5.2.4 階層的アプローチ 2013/04/27 第4回 分散システム本読書会 5 / 25
- 6. 5.2.1 ブロードキャストとマルチキャスト • エンティティの識別子を含んだメッセージを全員に ブロードキャストして探す • アドレス解決プロトコル(ARP)がこの手法を利用 • 問題点 – ネットワークが大きくなると要求メッセージだけで帯域を浪費して しまう マルチキャスト（特定のグループにのみメッセージを送る方式） を利用することで、ネットワーク帯域浪費を押さえられる 2013/04/27 第4回 分散システム本読書会 6 / 25 IP: 192.168.10.2 は 誰ですか? 私です！
- 7. 5.2.1 転送ポインタ • アドレスが変わりやすいモバイルエンティティを特定するための 方法 • エンティティがAからBに移動する際に、Bの位置を参照する ポインタをAに残しておく • 問題点 – 特別な工夫をしない限り、チェーンが長くなる – エンティティの特定が必要な期間、チェーンを保持する必要がある – リンクの障害を受けやすい スケーラビリティに問題あり！ 2013/04/27 第4回 分散システム本読書会 7 / 25 A BいつもAにアクセス すれば良い
- 8. 5.2.2 ホームベースアプローチ(1) • 大規模ネットワークにおいて効率的にモバイルエンティティの特定 をサポートする方法 • エンティティの現在位置を保持するホーム位置(home location) を 用いる • モバイルIP(下図)は、ホームベースアプローチの後続の例 2013/04/27 第4回 分散システム本読書会 8 / 25
- 9. 5.2.2 ホームベースアプローチ(2) • ホームベースアプローチの欠点 – 固定されたホーム位置を用いること • 問題点 – ホーム位置が変わってしまった場合、エンティティとの通信が 不可能になる可能性がある – モバイルエンティティと通信するためには、最初にホームと通 信する必要がある • ホームが、モバイルエンティティと全く異なる場所にあった場合は 通信遅延が増大する • クライアントが日本、相手のモバイルエンティティが日本にいて ホームがアメリカにあると考えると。。。 2013/04/27 第4回 分散システム本読書会 9 / 25
- 10. 5.2.3 分散ハッシュテーブル(DHT) • 識別子(ID)に関連付けられたエンティティのアドレス 解決を、DHTに参加しているノード同士で行う – アドレス解決のための特別なエンティティを用意する必要が ないため、スケールする • DHTのアルゴリズム – Chord (次ページで仕組みを説明) – CAN, Pastry, Tapestry, etc… ChordはDHTの最も有名なアルゴリズム 2013/04/27 第4回 分散システム本読書会 10 / 25
- 11. 5.2.3 Chord (1) • データは誰が持つ? – データとノードにIDを割り当てる – ID割当にはmビットの識別子空間を持ったhash関数を用いる – データとノードのIDをhashを用いて決める – 例) • Node2 のID – hash( Node2 ) = 66 • データA のID – hash (データA) = 41 – kというキーを持つデータは、識別子 idが id >= k となる最初のノードが 保持する – このノードをサクセッサ ( successor )と呼ぶ 右図ではデータA のサクセッサはNode2 2013/04/27 第4回 分散システム本読書会 11 / 25 ノード名 ( ID ) 図の丸がノード、四角がデータ
- 12. 5.2.3 Chord (2) • データをどのように探す? – 各ノードは自身の近接ノードについての情報( successor, predecessor) の情報を持っている – 単純に successor をたどっていけば、データを見つけられる – 線形アプローチは明らかにスケーラブルではない フィンガーテーブルを利用することで、検索効率を改善 2013/04/27 第4回 分散システム本読書会 12 / 25
- 13. 5.2.3 Chord (3) • フィンガーテーブル – 最大m個のエントリを保持 ( m = 識別子空間のビット数) • ノードpのi番目のFinger • 右図Node1 の Finger Table – m = 5 なので、Fingerを5個持つ 2013/04/27 第4回 分散システム本読書会 13 / 25
- 14. 5.2.3 Chord (4) • ノード1が k=26 を解決する手順 1. ノード1にて、 FT[5] <= k < FT[1] なので、ノード5に要求を送る 2. ノード18 にて、 FT[2] <= k < FT[3] なので、ノード20 に要求を送る 3. ノード20にて、 FT[1] <= k < FT[2] なので、ノード21に要求を送る 4. ノード21にて、kのsuccessorは ノード28だと知っているので、 28にデータを問い合わせる フィンガーテーブルを用いると、システムを構成するノード をN個として、O(logN) ステップでデータを発見できる！ 2013/04/27 第4回 分散システム本読書会 14 / 25
- 15. ネットワーク近傍性の問題 • Chordの問題点 – アンダーレイネットワークを考慮していない • 問題の解決策 – 近傍ルーティング – 近傍近隣ノード選択 2013/04/27 第4回 分散システム本読書会 15 / 25 日本 アメリカ 日本 アメリカ
- 16. 5.2.4 階層的アプローチ (1) • 特徴 – ネットワークはドメインの集合に分割される – 最下位のドメインはリーフドメインと呼ばれる – ディレクトリノードは、ドメイン内のエンティティの情報を 持っている DNSと同じ構造 2013/04/27 第4回 分散システム本読書会 16 / 25
- 17. 5.2.4 階層的アプローチ (2) • ノード情報が見つかるまで、親に要求を転送しながら エンティティを探す • 最悪の場合は、ルートノードまで探索が続く 2013/04/27 第4回 分散システム本読書会 17 / 25
- 18. 5.3 構造化された名前付け • 人間が読みやすい名前からなる構造化された名前 • 名前空間 – 分散システムにおける名前は、共通的に参照される名前空間で 管理される – 名前空間は、リーフノード、ディレクトリノードからなるラベル 付き有向グラフで表現される – リーフノード • 出力辺を持たない – ディレクトリノード • 出力辺を複数持つ • ラベル付けされている 2013/04/27 第4回 分散システム本読書会 18 / 25
- 19. 5.3.2 名前解決 • 名前空間を使って、パス名が与えられたときに、その名前に よって参照されるノードが持つ情報を調べること • クロージャメカニズム – どのように、どこから名前解決を開始するかを知ること • リンクとマウント – 別名(alias)の使用は、名前解決と強く関連している – 別名(alias)とは？ • 同じエンティティに対する 異なる名前 – 別名を実現する方法 • ハードリンク (前ページ図） • シンボリックリンク(右図) 2013/04/27 第4回 分散システム本読書会 19 / 25
- 20. ファイルシステムのマウント • 異なる名前空間を参照できる – 異なる名前空間のディレクトリノードの識別子を保存 し、そこで異なる名前空間を参照できる 2013/04/27 第4回 分散システム本読書会 20 / 25
- 21. 5.3.3 名前空間の実装 • 名前空間の分散 – 大規模な分散システムの名前空間は、通常階層的に構成される – [Cheriton and Mann, 1989] は、以下の３つの層に分割した – グローバル層 • ルートノードと論理的に近いディレクトリノードで形成される • ディレクトリテーブルの内容がほとんど書き換えられない、安定性がある – 部門管理層 • １つの組織の中で一緒に管理されるディレクトリノードによって形成される • グローバル層のノードよりは変化が多いが、比較的安定している – マネージャ層 • よく変化する可能性があるノードから成り立つ • ローカルネットワークのホストに相当するノードが、この層に属する 2013/04/27 第4回 分散システム本読書会 21 / 25
- 22. DNSの名前空間 2013/04/27 第4回分散システム本読書会 22 / 25 項目 グローバル層 部門管理層 マネージャ層 地理的スケール 世界 組織 部課 ノード総数 少ない 多い 膨大 探索の応答時間 秒 ミリ秒 即座 更新の伝播 遅い 早い 早い レプリカの数 多数 なし / ごくわずか なし キャッシュの有効性 有効 有効 場合による
- 23. 名前解決の実装 (1) • 反復名前解決 (左図) – 利点) 名前サーバの負荷が(再帰的な方法に比べて)少なくてすむ – 欠点) 通信コストが大きくなる場合がある • 再帰名前解決 (右図) – 利点) 結果のキャッシュが効率的になる / 通信コストが減少する – 欠点) 名前サーバに高い性能が要求される 2013/04/27 第4回 分散システム本読書会 23 / 25
- 24. 名前解決の実装 (2) • 長距離の通信の場合 – 再帰名前解決は長距離通信が1回 – 反復名前解決は長距離通信が3回 • 名前空間のグローバル層の名前サーバは反復名前解決のみサポート 2013/04/27 第4回 分散システム本読書会 24 / 25
- 25. 分散型DNSの実装 • DNSのスケーラビリティ – 上位レベルのノードほど、下位レベルのノードに比べて多くの 要求を受信する – キャッシュを使うことで、現状この問題を回避している • 分散ハッシュテーブル(DHT)を用いたDNSの実装 – CoDoNS [ Ramasubramanian and Sirer, 2004a] にて検討されている – 利点 • DHTベースの実装にマッピングすることで、スケーラビリティの問題を解決 – 欠点 • 名前構造を失っている – ある特定のドメイン内のすべての子を探索することが困難 – DHTでは範囲検索を行うのが難しい 2013/04/27 第4回 分散システム本読書会 25 / 25