IGINブルネイ/syasudaの日記(MT版)

非同期メッセージ通信を扱う限り、輻輳制御問題は避けて通れません。

ところがどっこい、OSには輻輳制御のための機能は一切搭載されていません。

せいぜいフロー制御のための機能がいくつかあるだけです。

ようするに後は自分でがんばれよ、というメッセージです。

輻輳制御が容易ならざるものであることは、通信工学を少しでもかじった人ならわかると思います。

例えば大地震が起きたときに、電話がかかりにくくなりますが、あれがどうして技術的に解決できないかご存知ですか？

また、MMOゲームにおいて、新機能実装時に人大杉でサーバが落ちてしまう理由をこんな風に理解しているのではありませんか？

バックボーンがしょぼすぎ

サーバ台数が少なすぎ

ロードバランサの設計が甘すぎ

MMO運営のノウハウがなさすぎ

学生バイトGMじゃだめだめ

BSDなんかじゃ・・・（略

Linuxが実務に使えるわけ（略

Windowsで運用するヤツは厨（略

１分あたりの性能で考えましょう。

通信帯域もサーバーの処理性能も、１分当たり1万件の処理がこなせるとしましょう。そのときに、１分当たり１万件の処理をこなせるようにシステムを作り上げるのが設計の目標値です。あるいはカネに目がくらんだビジネス側の要求仕様です。

ここに１分当たり2万件の処理が飛び込んだらそれはもうどうしようもないこと、ここまではコンセンサスが得られやすいです。

しかし１分当たり１万と１件の処理なら、「それくらいならなんとかなるでしょ？」と本気で言うエセ技術者が如何に多いことか。

うまいこと動いて定常的に処理できるのが１分当たり5000件として、5001件/分が飛び込んでくるなら「一時的にならなんとかなるかもしれない」。

その辺をある程度定量的に扱えるのが待ち行列理論です。

ところがどっこい、待ち行列理論の入門編くらいでは、「電話交換機ごっこ」くらいの現象しか解析できません。現実の問題にはさっぱりです。現実の複雑なシステムに適用できるモデルは複雑で、数学的にもややこしくなります。勢い出てくる結論も曖昧というか、『入力条件次第』となってしまいます。

そこでみなさんシミュレータに逃避するわけです。

さて、非同期メッセージ通信が輻輳制御問題であることは疑う余地のないことなのですが、サーバ屋さんと同様にシステム屋さんも、複雑怪奇なシステムを作ってしまってから、解析モデルを作れずに頭をひねり続けます。挙句、現実にはありえない線形の入力条件や負荷条件を与えて、むりやり安定解を得て自己満足で終わるのです。そうして不安定なシステムを前にしても「こんな負荷は想定外」と吐き捨てる。学者バカじゃないんですからもうちょっとまともなことは言えないのでしょうかね。

待ち行列理論の入門編だけでなく初級・中級編くらいまで学んだ上で、非同期メッセージ処理を「設計」してほしいものですね。実装する人は入門編だけでよいです。余計な知識は余計な実装を生みますので。

待ち行列理論的に解析できないような仕組みを作りこむこと、それ自体が不安定なシステムの挙動を生んでいると言うことを覚えておいて欲しいのです。

強度が足りない柱はどうやたって強度不足になります。それに鉄板を巻こうが補強のハスカイを入れようが、どうせ接合部分に応力が集中していざというときにはあっさり崩壊するのです。それはパッチ当てと呼ばれ忌み嫌われる行為です。

問題は、梁の強度は断面２次モーメントで決まると言うような学部１年生でも知ってる基礎知識を設計者が知らないという事実です。これは材料力学の初歩なわけですが、非同期メッセージ通信を堅牢に実装するためには、待ち行列理論の基礎知識が当然必要なのです。

＃だから情報処理の教科書には申し訳程度に通信工学の一部として待ち行列が載っています

鉄筋の足りないコンクリートの柱の外側にコンクリートを塗り足しても何の補強にもなりません。それとおなじことをソフトウェアの世界でやっているわけです。

つまりそれは３匹の子豚以下なわけです。敢えて書くならアネハ以下。