はじめに

『design for failure』という考え方をご存知でしょうか。障害は必ず発生するという前提に立ったシステム設計の考え方です。障害が必ず発生するとはどういうことでしょうか。これはシステムを構成するあらゆるものを『いつかは故障するもの』として扱うことです。話が少し抽象的なので具体例で考えてみましょう。

1台のサーバーでWebサイトを運用している場合、どのような部分の故障が想定できるでしょうか。『サーバーがダウンした』と言ってもその原因となる故障箇所は様々です。まずはハードウェアの観点で見てみましょう。

ハードウェア

サーバーを構成する要素として、CPUやメモリ、ディスクだけでなくマザーボードや電源ユニット、冷却ファンが挙げられます。また、LANやFC(Fibre Channel)、RAID ※の拡張ボードを追加していたら、それらもサーバーを構成する要素となります。故障する頻度(耐久性)に違いはあれど『design for failure』の考え方では、これらすべては『いつかは故障するもの』として扱います。

ソフトウェア

次にソフトウェアの観点ではどうでしょうか。まずは OS(Operating System)自体の障害です。OSのバグ(プログラム的な不具合)やセキュリティの脆弱性に起因するような障害などが考えられます。また、Webサイトの機能を提供するようなアプリケーションについても、バグやセキュリティの脆弱性など同様の障害は考えられます。他にはWebサイトへの急激なアクセス増加による高負荷状態も障害として想定しておく必要があります。

ネットワーク

さて、1台のサーバーに対してハードウェア、ソフトウェアそれぞれの観点でどのような障害が起こりえるのか見てみましたがこれで終わりではありません。今回の例では『Webサイトを運用』しているので、Webサイトが稼働しているサーバーとWebサイトにアクセスしてくるユーザーをつなぐネットワークまわりについても視野を広げる必要があります。

まずはサーバーと繋がっているネットワーク機器やケーブルの障害です。ケーブルの障害とは多くの場合、ケーブルの断線を意味します。また、高性能なネットワーク機器になると専用のOSが稼働しているため、OSのバグやセキュリティの脆弱性に起因する障害も加味する必要があります。Webサイトとして想定しているので、今回はインターネット回線を提供している回線業者側のネットワーク障害も想定しておく必要があります。

まとめ

どうでしょうか。1台のサーバーでWebサイトを運用しているシンプルな構成であってもこれだけの障害を想定しシステムを設計する必要があります。そしてその考え方を示したものが『design for failure』であり、システムを設計する際の原則とも言われています。いつ起きるかわからない障害にビクビクするのではなく、必ず障害は起きるものとして備えておくことで信頼性の高いシステムが設計できるわけですね。

おまけ・・・実はサーバーを設置している建屋自体の障害(大規模災害による停電や倒壊など)も想定する必要があるのですが、それはまたの機会に。

次の記事はこちら：HAクラスター入門 ～第2回 あらゆるものを冗長化？～

お問い合わせ