過負荷耐性の不足とバグの違い

くまぎ @kumagi

ソフトウェアの過負荷耐性の不足ってつまり異常系をまともに実装してなかったってのとどう違うんですか。

犬島@アルカディット @inutty_eng

@kumagi 滞留制御とかの話だとすると、異常系とは違うような。

くまぎ @kumagi

@takehik0 輻輳制御は信頼性とレイテンシのトレードオフになるんじゃないかと思うので、異常系と呼ぶよりは見積もりを誤っただけのような感じですね。

SODA Noriyuki @n_soda

@kumagi 実装じゃなくて設計とか仕様とか回線容量とかハードウェアとかいったレベルのこともあります。容量溢れが起きるケースで流量制御の仕組みがないとか追いつかないとか破綻するとか。過負荷時に性能が飽和するのならOKなんですが、飽和じゃなくてガタ落ちしちゃうんですね。

くまぎ @kumagi

@n_soda なるほど。ハードウェアに限界があるのは仕方ない事だけど、そこに当たった時の挙動次第で耐性が無いという判断もされる、と。

SODA Noriyuki @n_soda

@kumagi ハードウェアに限らず、なんらかのバッファが溢れるケースで、適切に負荷を制御する仕組みがないと起きますね。よくある簡単な例だと、サーバで、使用メモリ量とかプロセス数の制限が甘くてメモリから溢れて、スラッシング状態になって性能大幅低下とか。

鯉江 @koie

過負荷っていうとログ書こうとしたらENOSPCとか代替サーバに通知しようとしたらENOBUFSとか例外を送出しようとしたらENOMEMとかsleep(1)が戻ってくるのに30秒かかるとかそういうことかな。

鯉江 @koie

あとNICの受信バッファがあふれまくってTCPが先に進まないとか。

SODA Noriyuki @n_soda

@kumagi これ、メモリ→スワップの話だけだと設定甘いんだよみたいに思うかもしれませんが、扱うデータ量が増えてCPUのデータキャッシュから溢れてメインメモリにアクセスするようになって性能低下ってのも（性能低下の度合いが少ないとは言え）本質的には同じ話ですからなかなか難しいです

SODA Noriyuki @n_soda

@koie @kumagi TCPは普通はwindow sizeが自動縮小してなんとかなる筈なんですが、昔のD-Link製のプリンタポートにささるNICは、2パケット分のバッファもなくてwindow自動縮小では救済できず、OSレベルで受信ウィンドウサイズを縮小して対処したりとか。

くまぎ @kumagi

@n_soda 本来ならばプログラムがどういう挙動を示すべきだったか、というのが定義されうるのであれば、究極的にはソフトウェアの設計ミスという言葉に集約されかねませんが、無限大のデータを処理対象とするようなプログラムは途方もなく効率が悪くなるでしょうし議論しにくいですね。

SODA Noriyuki @n_soda

@kumagi @takehik0 そもそも見積もりができなかったりするんですよ。広域でのTCPの輻輳制御が、経由する（自分の制御できる範囲外の）ルータのバッファサイズが足りないせいで破綻したりとか。世界中のルータのバッファサイズを直して回るなんてムリですし。

SODA Noriyuki @n_soda

@kumagi 単機能のプログラムなら厳密に性能仕様を定義することも可能ですが、大規模なシステムだと、システムを構成するありとあらゆる場所でこの種の定義をする必要があるわけで、仕様定義段階で完璧を期すのは無理でしょうね。

くまぎ @kumagi

@n_soda @takehik0 なるほど…納得が行きました。ありがとうございます。

犬島@アルカディット @inutty_eng

@n_soda @kumagi インターネット系のシステムだと上限ないですからね。その中でどう戦っていくかはテクノロジー＋ビジネス、最後は運。