NYSE、WSJのシステム停止はなぜ起きた？今日もまたコンピュータが動かない――その理由と対策 (1/2)

仮想化と自動化のソフトウェアのおかげでシステム障害への対応は迅速に行われるようになったものの、有名企業はいまだにシステム停止の憂き目に遭っている。

[Nick Martin，TechTarget]

米Netflixの「Chaos Monkey」はクラウド上での耐障害性をテストするツール。オープンソースで公開されている《クリックで拡大》

　このところ、米紙The Wall Street Journal、米ニューヨーク証券取引所（以下、NYSE）、米航空会社United Airlinesなど、有名企業がデータセンターのシステム障害トラブルに見舞われる事態が相次いでいる。システム障害を完全に防ぐことは不可能だが、こうしたトラブルが大々的に報じられれば金銭的損失も大きく、顧客が企業に抱くイメージにも響く。そこで米TechTargetの顧問委員に話を聞いた。企業が高いレベルのアップタイムを維持するにはどうすればいいのか？　ダウンタイムを招く過ちにはどのようなものがあるのか？　平均的なデータセンターの堅牢性や耐障害性は顧客が期待するレベルなのか、それでも時折システム停止が発生するのは仕方ないことなのか？

併せて読みたいお薦め記事

大規模システム障害の教訓

• その日何が？　ニューヨーク証券取引所“3時間システム停止の謎”を追う
• Gmail消失事故で分かった「だからテープバックアップが必要なんだ」

データセンターの課題

• ユーザーも知りたい「データセンターの寿命を10年延ばすコツ」
• データセンターの40GbE導入をけん引する、2つの動向

クラウドバックアップ

• よく知られている「クラウドバックアップ」のメリット、ではデメリットは？
• クラウドへのDRを簡単に「Azure Site Recovery」3つの利用シナリオ

ブライアン・キルシュ氏（米ミルウォーキー地域技術カレッジ）

　可用性とその他の要件のバランスはITの重要課題の1つだ。システムは必要な限り常に稼働しているべきだと誰もが考えており、企業の管理職や経営陣もそれは同じだろう。問題は、可用性とそれを確保するために必要な代償のバランスをどう取るかにある。それは単なるコストだけの話ではなく、総合的な運用性を実現する複雑さとテストがカギになる。1つのハードウェア製品やソフトウェア製品だけで可用性を確保できるという考えはもう通用しない。バックアップとディザスタリカバリ（DR）の製品はますます幅広く効果的になっているものの、アプリケーションの方はどんどん複雑化している。アプリケーションと可用性は常にせめぎ合っており、現行のDR製品がアプリケーションのニーズとデザインについていけなくなったとき、大規模なシステム障害を招くことになる。

　だが、ハードウェアとソフトウェアはシステム障害というパズルの1つのピースにすぎない。システム障害の原因の多くは、システムエラーと変更だ。システムエラーを防ぐ設計、不正な変更を封じる安全対策は実施されているだろう。しかし、いくらフロントエンドでこうした対策を講じても、システム障害を完全に防ぐことはできない。そろそろディザスタリカバリとシステム障害に関する考え方を改めるときが来ている。これからは、単にシステム障害を防ごうとするのではなく、システム障害が発生するという前提でシステムを設計すべきだ。システム障害の発生を想定し、表面的なものにとどまらない対策を用意すれば、アプリケーションは真の耐障害性を確保できる。そのためには、システム障害を正しく処理できることをテストして確認することだ。

　これをどこよりも如実に実践したのが、米Netflixと同社の「Chaos Monkey」エンジニアリンググループだ。同社は「Amazon EC2」クラウドでサービスを運用しており、EC2クラウドの大規模リブートが実施されたとき、サービスを維持する必要があった。多くの企業がEC2クラウドのリブートは自分たちに影響しないと考え、そのほとんどはシステム停止対策を講じなかった。だが、NetflixとChaos Monkeyエンジニアリンググループは違った。Chaos Monkeyは日常的にシステム障害を繰り返し発生させるツールだ。Netflixは可用性を確保するために、大規模なシステム停止が発生する前に日ごろから継続的にテストして問題を修正し、システム障害を念頭に置いたサービスを作成した。

デイヴ・ソーベル氏（英LogicNow）

　NYSE、The Wall Street Journal、United Airlinesのような企業でシステム停止が発生するのは不面目といえる事態だ。システム停止は高くつく。比較的安価なコンピューティングリソースで対策を講じておけば、ダウンタイムを最小限に抑えることができる。クリティカルニーズのある企業は、クラウドでバックアップシステムを簡単に構築でき、それを緊急時にのみ使用することが可能だ。例えば、「Microsoft Azure」はアクティブコンピューティングロードについてのみ課金されるので、問題が発生するまでは、バックアップネットワーク全体をコールドスタンバイ状態で待機させることができる。ホットスタンバイも最小限の利用レベルに設定でき、いつでもフェイルオーバー可能にしておける。既に利用しているであろうモニタリングと管理のソフトウェアも進化を続けており、予測分析でダウンタイムに備えることができる。

　だが、システム停止の影響を緩和するには、コミュニケーションが最も重要だ。United Airlinesのシステム障害で実際に足止めされた乗客の話のように、情報の欠如は最も不満を招く。企業は一刻も早く状況の把握に努め、慎重な見通しを示し、期待以上の結果を出すべきだ。ソーシャルメディアへの発信もなく、従業員にも情報が伝えられていないようでは、顧客サービスは最悪になる。