Naming

第4回分散システム本読書会
名前付け / Naming
@nishio_dens
2013/04/27

本章の目標
名前と識別子から、いかにしてアドレスを

解決するかが本章の重要なテーマ

•  様々な名前解決の仕組みを理解する

–  フラットな名前から、どのようにしてエンティティを
見つけるかを理解する

–  構造化された名前から、どのようにしてエンティティ
を見つけるかを理解する

–  分散システムでよく用いられる属性ベース名前付けを
理解する

2013/04/27
2
/
25

5.1 名前・識別子・アドレス
•  名前

–  エンティティ（ホストやファイル等)を参照するため
に使われるビット列、または文字列

•  識別子
(Identiﬁer
/
ID
)

–  エンティティを一意に識別するための名前

•  アドレス

–  アクセスポイントの名前

–  アクセスポイントとは?

•  エンティティにアクセスする際に利用するエンティティ

2013/04/27
3
/
25

ヒューマンフレンドリーな名前
•  人間にとって扱いやすいように作られた名前を
ヒューマンフレンドリーな名前と呼ぶ

•  例)

–  ファイル名

•  UNIXの場合、255文字以内の文字列をユーザが定義可能

–  ドメイン名
•  DNSではドメイン名からIPアドレスを検索

•  ドメイン名は人間が覚えやすい

2013/04/27
4
/
25

5.2 フラットな名前付け
•  フラットな名前

–  アクセスポイントを特定するような情報を含まない名前のこと

•  フラットな名前からどのようにしてエンティティを

特定するか?

–  5.2.1
ブロードキャストとマルチキャスト

–  5.2.1
転送ポインタ

–  5.2.2
ホームベースアプローチ

–  5.2.3
分散ハッシュテーブル

–  5.2.4
階層的アプローチ

2013/04/27
5
/
25

5.2.1 ブロードキャストとマルチキャスト
•  エンティティの識別子を含んだメッセージを全員に

ブロードキャストして探す

•  アドレス解決プロトコル(ARP)がこの手法を利用

•  問題点

–  ネットワークが大きくなると要求メッセージだけで帯域を浪費して
しまう

マルチキャスト（特定のグループにのみメッセージを送る方式）
を利用することで、ネットワーク帯域浪費を押さえられる
2013/04/27
6
/
25

IP:
192.168.10.2
は

誰ですか?
私です！

5.2.1 転送ポインタ
•  アドレスが変わりやすいモバイルエンティティを特定するための

方法

•  エンティティがAからBに移動する際に、Bの位置を参照する

ポインタをAに残しておく

•  問題点

–  特別な工夫をしない限り、チェーンが長くなる

–  エンティティの特定が必要な期間、チェーンを保持する必要がある

–  リンクの障害を受けやすい

スケーラビリティに問題あり！

2013/04/27
7
/
25

A
BいつもAにアクセス
すれば良い

5.2.2 ホームベースアプローチ(1)
•  大規模ネットワークにおいて効率的にモバイルエンティティの特定
をサポートする方法

•  エンティティの現在位置を保持するホーム位置(home
location)
を

用いる

•  モバイルIP(下図)は、ホームベースアプローチの後続の例

2013/04/27
8
/
25

5.2.2 ホームベースアプローチ(2)
•  ホームベースアプローチの欠点

–  固定されたホーム位置を用いること

•  問題点

–  ホーム位置が変わってしまった場合、エンティティとの通信が
不可能になる可能性がある

–  モバイルエンティティと通信するためには、最初にホームと通
信する必要がある

•  ホームが、モバイルエンティティと全く異なる場所にあった場合は
通信遅延が増大する

•  クライアントが日本、相手のモバイルエンティティが日本にいて
ホームがアメリカにあると考えると。。。

2013/04/27
9
/
25

5.2.3 分散ハッシュテーブル(DHT)
•  識別子(ID)に関連付けられたエンティティのアドレス

解決を、DHTに参加しているノード同士で行う

–  アドレス解決のための特別なエンティティを用意する必要が

ないため、スケールする

•  DHTのアルゴリズム

–  Chord
(次ページで仕組みを説明)

–  CAN,
Pastry,
Tapestry,
etc…

ChordはDHTの最も有名なアルゴリズム

2013/04/27
10
/
25

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
11
/
25

ノード名
(
ID
)
図の丸がノード、四角がデータ

5.2.3 Chord (2)
•  データをどのように探す?

–  各ノードは自身の近接ノードについての情報(
successor,

predecessor)
の情報を持っている

–  単純に
successor
をたどっていけば、データを見つけられる

–  線形アプローチは明らかにスケーラブルではない

フィンガーテーブルを利用することで、検索効率を改善

2013/04/27
12
/
25

5.2.3 Chord (3)
•  フィンガーテーブル

–  最大m個のエントリを保持
(
m
=
識別子空間のビット数)

•  ノードpのi番目のFinger

•  右図Node1
の
Finger
Table

–  m
=
5

なので、Fingerを5個持つ

2013/04/27
13
/
25

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
14
/
25

ネットワーク近傍性の問題
•  Chordの問題点

–  アンダーレイネットワークを考慮していない

•  問題の解決策

–  近傍ルーティング

–  近傍近隣ノード選択

2013/04/27
15
/
25

日本
アメリカ
日本
アメリカ

5.2.4 階層的アプローチ (1)
•  特徴

–  ネットワークはドメインの集合に分割される

–  最下位のドメインはリーフドメインと呼ばれる

–  ディレクトリノードは、ドメイン内のエンティティの情報を

持っている

DNSと同じ構造

2013/04/27
16
/
25

5.2.4 階層的アプローチ (2)
•  ノード情報が見つかるまで、親に要求を転送しながら

エンティティを探す

•  最悪の場合は、ルートノードまで探索が続く
2013/04/27
17
/
25

5.3 構造化された名前付け
•  人間が読みやすい名前からなる構造化された名前

•  名前空間

–  分散システムにおける名前は、共通的に参照される名前空間で
管理される

–  名前空間は、リーフノード、ディレクトリノードからなるラベル
付き有向グラフで表現される

–  リーフノード

•  出力辺を持たない

–  ディレクトリノード

•  出力辺を複数持つ

•  ラベル付けされている
2013/04/27
18
/
25

5.3.2 名前解決
•  名前空間を使って、パス名が与えられたときに、その名前に
よって参照されるノードが持つ情報を調べること

•  クロージャメカニズム

–  どのように、どこから名前解決を開始するかを知ること

•  リンクとマウント

–  別名(alias)の使用は、名前解決と強く関連している

–  別名(alias)とは？

•  同じエンティティに対する

異なる名前

–  別名を実現する方法

•  ハードリンク (前ページ図）

•  シンボリックリンク(右図)

2013/04/27
19
/
25

ファイルシステムのマウント
•  異なる名前空間を参照できる

–  異なる名前空間のディレクトリノードの識別子を保存
し、そこで異なる名前空間を参照できる

2013/04/27
20
/
25

5.3.3 名前空間の実装
•  名前空間の分散

–  大規模な分散システムの名前空間は、通常階層的に構成される

–  [Cheriton
and
Mann,
1989]
は、以下の３つの層に分割した

–  グローバル層

•  ルートノードと論理的に近いディレクトリノードで形成される

•  ディレクトリテーブルの内容がほとんど書き換えられない、安定性がある

–  部門管理層

•  １つの組織の中で一緒に管理されるディレクトリノードによって形成される

•  グローバル層のノードよりは変化が多いが、比較的安定している

–  マネージャ層

•  よく変化する可能性があるノードから成り立つ

•  ローカルネットワークのホストに相当するノードが、この層に属する

2013/04/27
21
/
25

DNSの名前空間
2013/04/27
22
/
25

項目グローバル層部門管理層マネージャ層
地理的スケール世界組織部課
ノード総数少ない多い膨大
探索の応答時間秒ミリ秒即座
更新の伝播遅い早い早い
レプリカの数多数なし
/
ごくわずかなし
キャッシュの有効性有効有効場合による

名前解決の実装 (1)
•  反復名前解決
(左図)

–  利点)
名前サーバの負荷が(再帰的な方法に比べて)少なくてすむ

–  欠点)
通信コストが大きくなる場合がある

•  再帰名前解決
(右図)

–  利点)
結果のキャッシュが効率的になる
/
通信コストが減少する

–  欠点)
名前サーバに高い性能が要求される

2013/04/27
23
/
25

名前解決の実装 (2)
•  長距離の通信の場合

–  再帰名前解決は長距離通信が1回

–  反復名前解決は長距離通信が3回

•  名前空間のグローバル層の名前サーバは反復名前解決のみサポート
2013/04/27
24
/
25

分散型DNSの実装
•  DNSのスケーラビリティ

–  上位レベルのノードほど、下位レベルのノードに比べて多くの
要求を受信する

–  キャッシュを使うことで、現状この問題を回避している

•  分散ハッシュテーブル(DHT)を用いたDNSの実装

–  CoDoNS
[
Ramasubramanian
and
Sirer,
2004a]
にて検討されている

–  利点

•  DHTベースの実装にマッピングすることで、スケーラビリティの問題を解決

–  欠点

•  名前構造を失っている

–  ある特定のドメイン内のすべての子を探索することが困難

–  DHTでは範囲検索を行うのが難しい

2013/04/27
25
/
25

Naming

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Naming

Similar to Naming (6)

Recently uploaded

Recently uploaded (9)

Naming