Knight Capital：45分で4.6億ドルを溶かしたデプロイ事故

何が起きたか

横にスクロール

2012年8月1日午前9時30分、ニューヨーク証券取引所の取引開始のベルが鳴った直後から、市場は奇妙な動きを見せ始めた。特定の銘柄に、まるで意思を持たない機械が撃ち続けるかのような大量の売買注文が殺到したのだ。その発生源が、当時の米国株式市場で最大級のマーケットメイカーだったKnight Capital Groupのシステムであると判明するまでに、そう時間はかからなかった。

Knight Capitalは、投資家の注文を受けて株式を売買し、市場に流動性を供給することを生業とする会社だった。米国株の取引高の相当な割合が同社を経由していたとされ、その存在は業界の土台の一部を成していた。しかしこの日、同社が前夜に更新したばかりの発注システムは、完全に制御を失っていた。人間のトレーダーが何も指示していないのに、システムが勝手に高値で買い、安値で売るという、損失を生むためだけの取引を猛烈な速度で繰り返したのである。

暴走が始まってから止まるまで、およそ45分。この短い時間に、システムは数百万株規模の意図しない注文を市場へ送り込み続けた。現場の担当者たちは何が起きているのかを即座には把握できず、原因の切り分けに手間取った。ようやくシステムを完全に停止させたときには、Knight Capitalは約4.6億ドルという、会社の存続そのものを揺るがす規模の損失を抱えていた。

前日まで健全だった優良企業の株価はこの一件で暴落し、自己資本は事実上吹き飛んだ。同社は数日のうちに外部から緊急の資本注入を受けて辛うじて延命し、その後まもなく同業他社に買収されて、独立した企業としての歴史に幕を下ろした。たった一つのソフトウェアのリリースが、45分で一つの大企業を葬ったのだ。

技術的な根本原因

この事故の本質は、派手なアルゴリズムの欠陥ではない。ごく地味な、しかしどの現場でも起こりうるデプロイの不備だった。

Knight Capitalは、新しい取引プログラムを本番環境の8台のサーバーへ配布しようとしていた。ところが、この配布は自動化されておらず、人間の手作業で行われていた。エンジニアが各サーバーへ新しいコードを順に置いていく過程で、8台のうち1台への配置を見落としてしまったのである。結果として、7台には新しいコードが載り、1台だけには古いコードが残るという、ノード間で状態の食い違った危険なリリースが完成した。

問題をさらに深刻にしたのが、フラグの再利用だ。新しい機能は、発注ロジックのある動作を切り替えるために、システム内の設定フラグを一つ使っていた。だがこのフラグは新設されたものではなく、以前は別の目的で使われていた古いフラグを流用したものだった。

更新に成功した7台のサーバーでは、新しいコードがこのフラグを新しい意味で解釈したため、何の問題も起きなかった。ところが更新から漏れた1台は、古いコードのままこのフラグを受け取った。その古いコードにとって、このフラグは「Power Pegを起動せよ」という命令を意味した。こうして、何年も眠っていたはずの旧機能が、本番環境でただ一台のサーバー上だけで、突如として目を覚ましたのである。

Power Pegは、その設計上、際限なく注文を出し続ける性質を持っていた。かつては別の仕組みがその動作に歯止めをかけていたが、その歯止め役の機能は先の改修で別の場所へ移されており、復活した旧コードとはもはや噛み合わなかった。ブレーキの外れた旧エンジンが、1台のサーバー上でフル回転を始めたのだ。

さらに悪いことに、この異常を即座に止める仕組みが十分に働かなかった。暴走を検知して自動的に取引を遮断するkill switchや、確実なフェイルセーフが機能として整っておらず、稼働直後に届いていた警告の兆候も、明確な非常停止へは結びつかなかった。担当者は人手で原因を探りながら止めるしかなく、その間ずっと損失は膨らみ続けた。異常を「見つける」ことと「止める」ことのあいだに開いた時間が、そのまま損失額へ換算されていった。

教訓

この事故は金融という特殊な舞台で起きたが、そこから引き出せる教訓はソフトウェア開発の全分野に通じる。数々の障害事例を貫く原則が、ここに凝縮されている。

第一に、デプロイは自動化し、全ノードの一致を検証せよということだ。8台のうち1台を人が置き忘れるという事象は、手作業のデプロイでは避けがたい。配布を自動化し、すべてのサーバーが同一バージョンで動いていることを機械的に確認していれば、この事故はそもそも成立しなかった。今日のGitHub Actionsのような自動化パイプラインと、デプロイ後の状態検証は、まさにこの種の食い違いを潰すために存在している。

第二に、デッドコードと未使用フラグは危険な資産だということだ。Power Pegは何年も使われていなかったのに、コードとしてシステムに残り続けた。使わないなら消す。これは整理整頓の美学ではなく、安全上の要請である。眠っているコードは、いつか誰かの手で誤って起こされる。

第三に、機能フラグを再利用してはならない。古いフラグを新しい意味で使い回したことが、旧コードと新コードの解釈を真っ二つに分岐させた。フラグの意味がリリースをまたいで固定されている保証はどこにもない。新しい機能には新しいフラグを割り当て、退役したフラグは、それが制御していたコードごと確実に撤去するべきだ。

第四に、暴走を止めるkill switchと監視を最初から備えよということだ。どれほど注意深くリリースしても、異常はいつか必ず起きる。本当に重要なのは、それを何分で止められるかだ。取引を自動で遮断する非常停止装置と、異常な発注量を即座に捉えるモニタリングがあれば、45分という致命的な長さは何桁も短縮できたはずである。過去の大きな事故を振り返っても、最終的な被害の規模は初動の速さでほぼ決まっている。

そして最後に、リリース手順そのものをレビューの対象とせよということだ。コードのレビューは丁寧に行われても、それをどう本番へ届けるかという手順は、しばしば個人の記憶と慣れに委ねられてしまう。誰が、どのサーバーへ、どの順番で、何をどう検証しながら配るのか。この手順書こそ、コード以上に厳格な点検を要する対象なのだ。

まとめ

Knight Capitalの45分は、たった一台のサーバーへの配置漏れと、消し忘れた旧コードを起こしてしまう古いフラグの再利用という、二つの地味なミスが重なって生まれた惨事だった。高度な技術的難問ではなく、リリースの規律の問題だったと言ってよい。デプロイの自動化、全ノード一致の検証、デッドコードと未使用フラグの排除、そして暴走を即座に止める仕組み。どれも派手さのない基本ばかりだが、それらを怠った代償が4.6億ドルと一社の消滅だったという事実は重い。他の事例は大惨事の一覧から辿れる。