たまにはプログラムとバグの話（その２）
さて、色々書きましたが、プログラムにはバグがつきものです。平均的なプログラマが１万行に１つバグを仕込むとすると、100万行のプログラムには平均して100個のバグがあるという事になります。このバグ率を前提とした場合、あるステップ数のプログラムにバグが含まれない確率というのは、「(9999/10000)^ステップ数」になります。１万ステップあったらバグが無い確率は5PPM、100万ステップあったらプランク定数より１０桁も小さな値*1となります。まあ、１万行に１つのバグという確率が高いか低いかはありますが、１桁２桁くらい減っても結果は大差ありません。問題はそのうちどれくらいが致命傷となるのかという事です。
前回のお話で、「たまたま発覚した」と書いたのは、安全を見越した上で数百件程度確保すれば良い領域が、「たまたま仕様のミスで大きいエリアをとろうとしすぎていたために、結果的に89件分もの領域確保がなされていた。そのため、なかなか限界を超えなかった」としても全くおかしくないからであります。つまり、２重のミスで今まで影響が相殺されていたという事です。
まあ、動いているプログラムなんてこんなものですｗ
達観しすぎかなぁ。
あと、
板情報を配信するプログラムが動くゲートウエイサーバーは計6台。22日午前は、午前9時の立会取引が始まる前の寄付き時点で問い合わせ銘柄数が89を超えた3台がダウン。午前9時の取引開始直後にそれ以外の2台のパフォーマンスが極度に低下した。午前9時15分頃まで最後に残った1台のパフォーマンスも低下したため、午前9時21分から派生商品の立会取引を停止した。
「東証のシステム障害、設定ミスをテストでも見抜けず 」
とありますが、これはフォールトレランスをかねた負荷分散だと思います。１台がハードウエア障害でダウンしても残りの５台に負荷を分散させる事で全体としては、１台が止まったことに気づかれないようにできているという事です。厳密に言うと、たとえば１台につき３００件の処理能力が必要だとして、１台ダウンしたら３００件×6/5の３６０件分の処理能力が必要です。同時２台ダウンまでまで想定しているのなら、４５０件ですね。
で、こんなことをクドクド書いたのは、負荷が低いときに１台ダウンに対処することは可能ですが、負荷が高いときは別だと言う事です。通常は処理能力オーバーの問い合わせがあった時には、エラーを返して無視する仕様だと思いますが。運が悪い利用者からはダウンしているように見えるますが、これは「仕様」って奴です。それでもダウンしているように見えちゃうのです。今回たまたまバグにより３台がダウンしましたが、ダウンしないで負荷オーバーでエラーを返したとしても同じです。１台が処理能力オーバーしたら、その処理を他のゲートウエイに振り分けますので、順次連鎖的に同じように負荷オーバーとなっていき、最終的に全滅してしまいます。
「フォールトレランスの仕組みが導入されている」というと、どんな事態でも絶対ダウンしないように思えてしまいがちですが、それは概念的な話にすぎません。想定外の事象に対してはトレラントではなく、意外な脆弱性が隠れている事は忘れてはならないと思います。
３台がパフォーマンスの低下だけで、踏ん張って残っていたという事は、今回のアップデートでバグを仕込まれたのは３台だけで、残りの３台は元のままだったという事なのかも知れません*2。そして、そのような対処をしても、勝利能力オーバーに対しては、脆弱なままなのです。
← 「へぇ」と思ったらクリックを！
