分散ロックサービス「Chubby」のPaxosプロトコルにおける分散トランザクションとP2Pの関係性に関するつぶやきメモ

6
(・∀・)キムティ♪@荒浪一城 @kimtea

グローバルトランザクションの問題を解決するには、「非同期」があるわけですが・・・

2010-01-10 16:57:16
(・∀・)キムティ♪@荒浪一城 @kimtea

リソース・マネージャー同士で一定の範囲(Kind)を決めて、非同期で更新。メッセージパッシングするような形で、次のリソース・マネージャーが更新処理を行う

2010-01-10 16:57:40
(・∀・)キムティ♪@荒浪一城 @kimtea

分散ロックサービスのChubbyを見ると、分散合意問題を非同期的に解決するのは Paxos プロトコルとあって、TCMPプロトコルも信頼性の確保でACK(応答確認)=メッセージパッシングと解釈する説 http://bit.ly/7Bu4pU

2010-01-10 16:58:03
(・∀・)キムティ♪@荒浪一城 @kimtea

信頼性の確保でACK(応答確認)=メッセージパッシング このあたりとか → ロック・サービスは結果を告知するメカニズムのサポートに適している

2010-01-10 16:58:44
(・∀・)キムティ♪@荒浪一城 @kimtea

そんなことしたら完全にカオスになると思うのですが、「サービス開発者に連続的なプログラミングを幻想を提供する」ってこのことかと思ったり

2010-01-10 16:59:16
(・∀・)キムティ♪@荒浪一城 @kimtea

これってどういう意味かな(・∀・)? → 粒度の細かい (fine-grained) ロックではなく、粒度の粗い (coarse-graind) ロックのみを提供する

2010-01-10 16:59:46
(・∀・)キムティ♪@荒浪一城 @kimtea

ACID思考なロックではなく、BASE思考によるロックを提供するという解釈があるけど・・・

2010-01-10 17:00:18
(・∀・)キムティ♪@荒浪一城 @kimtea

粒度の粗いロックは数時間~数日という長い期間保持される・・・・・・・・ゴクリ。数時間~数日だと!?

2010-01-10 17:00:41
(・∀・)キムティ♪@荒浪一城 @kimtea

(^・ω・^).....ンニュニュ? 待てよ、数時間~数日保持されるって、DNSのキャッシュのような考えだね。

2010-01-10 17:00:58
(・∀・)キムティ♪@荒浪一城 @kimtea

ネットワークのネットワークであるインターネットを、実証済みである最強の分散コンピューティング環境として模倣したのかな?

2010-01-10 17:01:15
(・∀・)キムティ♪@荒浪一城 @kimtea

コンシステントハッシング自体が、ネットワークのプロトコルだから当たり前かε('∞'*)フゥー

2010-01-10 17:01:28
(・∀・)キムティ♪@荒浪一城 @kimtea

Paxosプロトコルが、仮にBASE思考でコンシステントハッシングに基づく、プロトコルだとすると

2010-01-10 17:01:43
(・∀・)キムティ♪@荒浪一城 @kimtea

そのロックの対象となる粒度(Kind)の数 = 分散ハッシュテーブルにおけるサーバーの数と同じにならないだろうか?

2010-01-10 17:01:58
(・∀・)キムティ♪@荒浪一城 @kimtea

この場合、データの整合性が一番問題とされるわけですが、それをどのように確保するかは、首藤先生がクラウドの技術の中で言及していて

2010-01-10 17:02:08
(・∀・)キムティ♪@荒浪一城 @kimtea

データの整合性を完全に防ぐには、サーバー一覧表をひとつだけにしてしまう(全クライアントから単一中継サーバーを使う)か、すべてのサーバー一覧表の間で、一貫性を保つ必要がある。

2010-01-10 17:02:25
(・∀・)キムティ♪@荒浪一城 @kimtea

どちらにせよ、性能上極めて不利であるか、現実的ではない。この点、完全な一貫性よりは条件を緩めて、一時的、過渡的な不整合は許容するという方針、つまりはACIDの代わりにBASEに従わざるを得ない。

2010-01-10 17:02:37
(・∀・)キムティ♪@荒浪一城 @kimtea

こうした方法は、ネットワークの負荷がかかるし、果たして何台まで通用する方法なのか?この問いについても答えていて

2010-01-10 17:02:51
(・∀・)キムティ♪@荒浪一城 @kimtea

分散したサーバー一覧表の間で、これらの一貫性を保とうとするから大変になるのであって、ここでも一貫性の条件を緩める必要がある。つまり、問い合わせの「サーバー間での転送」を許すのである

2010-01-10 17:03:13
(・∀・)キムティ♪@荒浪一城 @kimtea

そのサーバー間での転送を実現し、かつ末端のサーバーにまで情報がいきわたるような技術が既にあって、それがP2Pにおける分散ハッシュテーブルである、だそうです。

2010-01-10 17:03:34
(・∀・)キムティ♪@荒浪一城 @kimtea

ルーティング用語の世界では、サーバー一覧表=経路表、一覧表の維持管理=ルーティング、転送=フォワーディングが、相当する

2010-01-10 17:03:53
(・∀・)キムティ♪@荒浪一城 @kimtea

このときに用いられる現時点で考えられるアルゴリズムでは、一台当たりの経路表のサイズも「O(log N)」まで抑えらている。ID空間の大きさが2の160乗の場合、どんなにサーバー台数が増えてもフィンガーテーブルが持つエントリ数はたかだが160である。

2010-01-10 17:04:02
(・∀・)キムティ♪@荒浪一城 @kimtea

その結果、サーバー間での一貫性の確保による維持コストは台数に比例し、これら「転送」によってネットワークの負荷が高まるわけですが、担当ノードに「直接到達させる」という方法によって、この問題を解決することができ、これを首藤先生は”「転送なし」の構造化オーバーレイ”と呼んでいます。

2010-01-10 17:04:14
(・∀・)キムティ♪@荒浪一城 @kimtea

つまり、これはグローバルトランザクションの「一貫性の確保」という観点にも、BASE思考を用いることで解決できるのではないかということなんだけど、どうでしょう(・∀・)?

2010-01-10 17:04:30
(・∀・)キムティ♪@荒浪一城 @kimtea

ちなみに、12月のスティルハウスの書庫 Paxosお勉強メモ エントリーはこちら http://bit.ly/4VBxTk

2010-01-10 17:04:42
(・∀・)キムティ♪@荒浪一城 @kimtea

簡略化されたPaxos 故障を許容する形で分散コンピュータシステムを運用するフォールトトレラントな簡略化アルゴリズム http://bit.ly/7DV8Tu

2010-01-10 17:05:03