分散システムでいう非同期と、プログラミングモデルでいう非同期呼び出しとは、少しニュアンスが違う。

Masayoshi Hagiwara @masayh

分散システムでいう非同期と、プログラミングモデルでいう非同期呼び出しとは、少しニュアンスが違う。まず、非同期とは何かを理解することが分散では重要。それにより、同期がいかに例外的なことで、同期プログラミングになれきっていることへの振り返りができる。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@masayh この「非同期」というのは人によって”微妙に”解釈が違うので、話が合わないことが多いです。自分は割と広義に取るので、ある特定の典型のみを非同期という言い方をする場合とは、差が出てしまいますね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

個人的には「ほとんど全ての処理は非同期が原則で、むしろ同期が例外（よってペナルティが発生する）」というスタンス。多分、普通のオープン系の人とは違うと思う。UIのない業務系の処理は、ほとんど非同期で、同期でやった方がよい場合ですら、コストを見て非同期処理をしたりするわけで。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

世の中の大半は非同期処理なんで、システムもそうなっている方が都合が良い、ということもある。ただその「非同期処理」なのに、スループットを要求するケースとレイテンシーを要求する場合があり、後者はかぎりなく（語弊のあるところの）”リアルタイム”とやらに近いのよね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

分散処理って言う意味だと非同期の復権みたいなところがあるので、その辺は見直した方がいいと思う。ただし、ありがちな”従来”の分散処理みたいに、ループで回った部分取り出して分散しますよ的な発想では全然駄目なんで。I-P-Oあたりから、ゆっくり考えるといいと思いますが。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

とはいえ、MAみたいな話が本筋のはずが、モナ中、俳優API、とか関数型ラブな人が乱入して残念ことは避けて頂きたくお願いしたい。（遠い目

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

ただ対障害性は同期の方が多分高いだろうな〜とは思う。非同期は設計時点から障害設計を織り込んでいないと残念どころか、まったく使い物にならないわけで。まーなんというか、ローレベル（なIT)かつハイレベル（な設計）な感じで、個人的には職人芸の領域なので好きです。

Masayoshi Hagiwara @masayh

プログラマはmessagingやEDAなどを非同期と見ていますが、これらは非同期的な動作をさせる手段に過ぎない。分散システムでいう非同期はシステムの持つ特性で、遅延、障害、ネットワークの切断などをいう。このあたりが誤解の原因かな。

Masayoshi Hagiwara @masayh

確かに、この点は重要ですね。@okachimachiorz1 ただその「非同期処理」なのに、スループットを要求するケースとレイテンシーを要求する場合があり、

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@masayh ですね。かなり狭義に見てしまっている部分があるので、その辺りのギャップは埋まりにくいです。ただ、業務系のハイレベルなプロトコル設計をやった人は基本は非同期で遅延・障害と折り込むので、そういった人は実は分散にはなじみやすいです。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

非同期ってかなり上のレイヤーまで持って来れる（下手するとユーザーレベル）ので、そこまで来るとかなりはっきりするかな、と思います。

ICHIRO SATOH @ichiro_satoh

非同期を各計算機の計算がバラバラに動くという意味と、(予測不可能な)通信遅延により同時性が保証できない意味で使う場合があるのも誤解の原因かと。RT @masayh 分散システムでいう非同期はシステムの持つ特性で、遅延、障害、ネットワークの切断などをいう。このあたりが誤解の原因かな

ICHIRO SATOH @ichiro_satoh

続き。分散システムの本質的な制約は(予測不可能な)通信遅延。非同期性も結局はその通信遅延の結果のひとつに過ぎません。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

個人的には「元CBLerで古いバッチができた人の復権」とかいう単純な図式ではなく、非同期レイヤーでの障害設計に秀でたというある意味「真のコボラーな達人」の出番ではないかと思っているわけですよ。分散クラウドでの設計や実装では。ま、このレベルの人は普通にどこもで神クラスですが。

ICHIRO SATOH @ichiro_satoh

続き。逆にいえば分散システムに(予測不可能な)通信遅延がなければ同期システムとして構築できるわけで、つまり非同期は遅延の結果の一つということ。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ichiro_satoh 予測不可能な通信遅延をどのレイヤーで、処理するかというのが面白いところかと思っています。ミドルで隠蔽するのが基本だと思いますが、手練な人がいるのであれば、かなり上のレイヤーで処理させてしまうということも可能ではないかな、と思います。強烈に人を選びますが

ICHIRO SATOH @ichiro_satoh

非同期を前提に処理を書くのは難しく、作れてもクローズな非同期システムが限界では（その意味ではコボラーが得意な世界）。クラウドも1社のクローズなシステムだから構築・運用できているのが現実ですから。RT @okachimachiorz1 非同期レイヤーでの障害設計に秀でたというある…

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

あとは、処理自体の非同期処理と、処理対象のデータの非同期・同期は分けた方がいいかな〜と最近は思う訳で。この辺が絡みだすとかなりややこしい。

ICHIRO SATOH @ichiro_satoh

非同期系でも、ミドルのレベルでは開放系でも、アプリからは閉じた系として扱えるのならば、レイヤーをあげるのは一つの方法だと思います。RT @okachimachiorz1 … かなり上のレイヤーで処理させてしまうということも可能ではないかな、と思います。強烈に人を選びますが

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ichiro_satoh ですね〜。勿論閉じた世界（それこそ一定のビジネスルールが暗黙で想定される）場合ですね。これはアプリ・レイヤーでもハンドルできるのではないか？とは思っています。・・・ただ何人できるのかwっていう問題はありますが。

ICHIRO SATOH @ichiro_satoh

分散システムって、遠い星との通信みたいなもの。相手の星が見えていても、光の速度は有限だから、通信遅延が避けられないわけで、そうなると、その星はすでに超新星爆発を起こしているかもしれない。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

そーいえば、この間TX本で、処理の交換可能性の話のなかで、SWIFTの例まで出てきて、レイヤーを一気にそこまであげることもあるのか、とびっくりした。必要に応じてレイヤーリングを代えることで下位の制限を上位のセマンティクスで解消するという凄い話だったけど、なるほどと感心した。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

だから結論的には上位レイヤーから下位レイヤーまで押さえた人が貴重ですね、という非常に当たり前過ぎて絶望するような結論が出てまして。

ICHIRO SATOH @ichiro_satoh

下位層はサーバ追加されるし、接続先のクライアントの数は不定で、開いた系。ミドルもその対処が前提。でも上位層で閉じた系を構築できるならばその方が楽かと。RT @okachimachiorz1 ですね〜。勿論閉じた世界（それこそ一定のビジネスルールが暗黙で想定される）場合ですね。…

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ichiro_satoh ですね。ただその場合は上位で障害（というか本質的な遅延と非決定性）をハンドルするノウハウが必要なので、相当なベテランか強者が前提になります。