原子時計とクラウド

Suguru ARAKAWA @ashigeru

@kazunori_279 古くからRPCのセマンティクスとして教科書に載ってる感じですね。ぼくも多分そこから言葉を引っ張ってきてる

Suguru ARAKAWA @ashigeru

@kazunori_279 見直されているというか、インフラ層でないエンジニアも気にしなきゃいけないほど表面化してきた、って感じでしょうか

Suguru ARAKAWA @ashigeru

@kazunori_279 これが過渡期ならではなのか、そうでもないのかはちょっと不明ですけどねぇ。ただ、exactly once semanticsは分散システムでは本来相性が悪いです

ICHIRO SATOH @ichiro_satoh

クラウドとともに分散システムが基本になってしまいましたからね。分散システムの基礎知識は必須なのかもしれません。RT @kazunori_279: タネ先生の分散本を見たらp343とp345にありました。これやっぱ一度読み通さないとダメな時代になりつつありますね

Shinpei Ohtani @shot6

@ichiro_satoh @kazunori_279 私も見返したり調べたりしていますが今後もっと必要になるかもしれないですね。

ICHIRO SATOH @ichiro_satoh

Tushar Chandraですか。コンセンサスプロトコルとアトミックブロードキャストの関係などの分散アルゴリズム同士の関係を定式化した方。ただ論文は難解。@Nakada_itpro: Googleの基調講演が「Sibyl: A system for large scale …

ICHIRO SATOH @ichiro_satoh

昨年はOSの会議(SOSP)の併設でしたから実装ネタが多かったですが、今年は純粋な分散アルゴリズムの会議(PODC)と併設だから、ちょっと雰囲気違うかも。RT @Nakada_itpro: 来週はスイスで、みんな大好きLADIS 2010が開催されますが、

ICHIRO SATOH @ichiro_satoh

Tushar Chandraは分散システムの故障検出の論文が有名かなぁ。ただ、正直に告白するとこの論文は難解で挫折しました。日本で読める人いるのかなぁ。http://www.cs.cornell.edu/home/sam/FDpapers/CT96-JACM.ps

Shinpei Ohtani @shot6

@kazunori_279 今後のミドルウェアではどんどん避けられなくなる傾向にあるとおもいます。

ICHIRO SATOH @ichiro_satoh

これもまた分散アルゴリズムの大御所が著者に入っていますね。@Nakada_itpro: そんなLADIS 2010でMSRが発表するのは、分散ストレージだそうな Data-Centric Reconfiguration with… http://bit.ly/ciEw0h

Shinpei Ohtani @shot6

@frsyuki ただしそうなると本当のアプリケーションのレイヤと、プリミティブな操作の間に一層必要な気はします。アプリで全部やってもいんだけど非効率かなと。

ICHIRO SATOH @ichiro_satoh

いまごろプログラムを見ていますが、PODCコミュニティというか、純粋分散アルゴリズムの会議になっていますね。併設先でこれほど性格の変わる会議も珍しい。RT @Nakada_itpro: 来週はスイスで、みんな大好きLADIS 2010が開催されますが、

ICHIRO SATOH @ichiro_satoh

今年のLADISは、分散アルゴリズムに興味のある方を除くと、基調講演だけウォッチしておけば十分かも。昨年のLADISのコミュニティはSOCCに流れたような印象を持っています。RT @Nakada_itpro: 去年は佐藤先生の日記で開催後に知ったLADISですが、今年は開催前に…

Sadayuki Furuhashi @frsyuki

全順序を保証する何かをネットワーク全体で使うなら、冪等性はそちらのクロックを使って実現できるから、より高度なメッセージングシステムは１対１ではなくネットワーク全体の通信を管理するサービスになるはずだけど、それは１対１の通信を使って実装されるに違いない。

ICHIRO SATOH @ichiro_satoh

わかっていて書かれていると思いますが、送信側が正常と仮定できた場合の話ですよね。RT @frsyuki: ただ再送を繰り返すほど届く確率は向上していくから、X%の可用性を得るために、N回･M秒まで再送を繰り返す、という考え方が必要になるんじゃないかな。

Suguru ARAKAWA @ashigeru

@frsyuki ネットワーク全体で全順序である必要ってありますかね？作用に関して冪等であることを保証するなら、なんとなく作用の因果に関する半順序だけでもいいイメージが

Sadayuki Furuhashi @frsyuki

@ichiro_satoh 送信側のメッセージは正常だという仮定で、あとネットワークの障害はいつかは復旧するという仮定です。

Sadayuki Furuhashi @frsyuki

@ashigeru 作用が複数のホストにまたがる場合は不足すると思います。例えば、あるRowがサーバAに保存されているという情報を、サーバBに移動中だと書き換える処理と、サーバCに移動中だと書き換える処理が同時に走っても、整合性を保ちたい場合…わかりにくいですねw

Sadayuki Furuhashi @frsyuki

@ashigeru いまの例は適切ではなかったですね…参照するホストとか、いろいろ抜けてました。分散トランザクション（あるいはレプリケーション）を考えるのが一番簡単ですね。作用が複数のホストにまたがります。

Sadayuki Furuhashi @frsyuki

DynamoでVector Clockが衝突するケースが、半順序で困る分かりやすい例か。

Suguru ARAKAWA @ashigeru

@frsyuki 私が誤読してるだけかもしれないですが、ご指摘いただいた例って冪等かどうかの問題というより、常にその問題が発生しうる状況で、再試行時にインターバルが長くなるから実用的でなくなる、って話も混ざってるのではないかなと (それが一番の問題なんですが)

Sadayuki Furuhashi @frsyuki

@ashigeru んー…冪等性と全順序の話題が混ざりましたね。メッセージに全順序が保証されていれば、冪等性を実現するのは簡単ですから（最後に届いたメッセージのクロックを覚えておけば良い）、順序を付けない場合に冪等性を実現どうするか、という問題は確かに別ですね。

Suguru ARAKAWA @ashigeru

@frsyuki やはり原子時計を搭載するしか！

ICHIRO SATOH @ichiro_satoh

質問ですが、@frsyuki 様の冪等性と全順序はどのように定義されますか。全順序も、到着順レベルか因果関係レベルかいろいろありますので。RT @frsyuki: んー…冪等性と全順序の話題が混ざりましたね。メッセージに全順序が保証されていれば、冪等性を実現するのは簡単ですから

Suguru ARAKAWA @ashigeru

@kazunori_279 ビルで反射して30cmくらい迂回しただけで、1GHzのCPUで1クロックずれちゃいますぜ