NYSE、WSJのシステム停止はなぜ起きた？

今日もまたコンピュータが動かない――その理由と対策（2/2 ページ）

公開 2015年08月11日 12時01分

更新 2015年08月11日 12時02分

著者

Nick Martin

[TechTarget]

印刷する

ジム・オライリー氏（米Volanto）

　“フェイルセーフシステムもフェイルするのか？”（二重安全装置も落ちるのか？）　矛盾のある言い回しに聞こえるかもしれないが、United AirlinesもNYSEもトラブルに陥った。彼らのITインフラのどこがいけなかったのか？

　問題の一因は複雑化が進んでいるところにある。これは、修正プログラムを何度も適用し、度重なる拡張を繰り返してきた古いシステムに見られ、ハードウェアとソフトウェアの脆弱性につながりやすい。United Airlinesのシステム障害の原因はルータの異常だったらしいが、高度な冗長システムになぜ単一障害点が存在したのかという疑問が湧く。

　通信関連の問題はUnited Airlinesに限ったことではない。クラウドの巨人、Amazon Web Services（AWS）も、少し前にルータのソフトウェア更新の不備が原因でゾーンを失った。このようなシステム障害の背後には、運用手順の欠陥や、セットアップのチェックとバランスの欠如、信頼性低下の有無を調べていない怠慢が垣間見える。

　NYSEのシステム障害は、AWSのゾーン障害同様、ソフトウェア更新が原因だった。売り注文と買い注文をマッチングさせるエンジンに対する更新がトラブルを起こしたという。

　ハードウェアやソフトウェアに原因があるように言われているものの、これらのシステム障害の元凶は全て、人的エラーだ。先進的システムでは、システム障害は想定すべきものであり、各種プラットフォームや適用アプローチに応じて管理者が調整しなければならない。ネットワークトポロジーの不備や、未検証の更新の適用、更新の誤適用はどれも避けることのできるエラーである。問題は、法外なコストを掛けずにどうやってそれらを回避するかだ。

　更新に関しては、自動化がその答えとなる。「Windows」ユーザーならそのアップグレードアプローチになじみがあるだろう。バックグラウンドで自動実行される場合と、質問に答えて実行する場合があるが、その手続きの大部分と新しいコードの再構成は、ソフトウェアによって処理される。

　これに対し、コマンドラインインタフェースの伝統が息づく「Linux」では、更新の実行に管理者の手入力が必要となる確率が極めて高い。スクリプティングは最先端技術と目されるが、当然ながら、スクリプトが正しく機能するためには微調整が不可欠となる。

　ハイレベルの手動操作が必要なシステムはその性質上、誤操作が発生しやすく、AWSとNYSEの事故はその典型的な結果である。United Airlinesの問題はこれとは別のところにあり、単一障害点が存在していたことは明らかだ。これを防ぐのは難しいことではない。ルーティング構造の手動レビューさえ実施していれば、1つのルータがシステム障害を引き起こしかねない状況を発見できただろう。ただ、公正を期すために付け加えると、アプリケーションスイートと基本プラットフォームのトポロジーが流動的な場合、手動チェックは簡単ではない。

　このような場合にシステムの障害点を検出するのに役立つソフトウェアもある。米Continuity Softwareのような会社から構成の問題への対策が提供されている。ビッグデータアナリティクスでアプローチの洗練度を高めることも可能だ。

　それでも、設計品質の低いアプリケーションの場合、それも耐障害性の低いレガシーシステムの場合は、これからも悩みは続く。この種の問題への対策は、サンドボックス（テスト環境）における徹底的なテストだろう。

　システム障害のないデータセンターは実現可能か？　この問いに対していえるのは、理想の実現には程遠いにせよ、改善の余地は大いにあるということだ。