障害対策の基礎知識 RASIS

サービスをできるだけ落とさず安定させようとするのは当然ですが、ハードウェアの故障がある限りはサービスが落ちることを当然として構築・運用をします。

環境によってはマンパワーのベストエフォートでそれなりにいけちゃったりしますが、サーバ台数が増えたり、キチンと設計したり、組織の自分以外に性質を示したり、社会にアピールしたり するために安定度を可視化する必要が出てきます。



公開されている例

少し前の記事ですがわかりやすくGoogle先生から。
  • Destination: Dial Tone — Getting Google Apps to 99.99%

  • In 2010, Gmail was available 99.984 percent of the time, for both business and consumer users. 99.984 percent translates to seven minutes of downtime per month over the last year.

    2010年のGmailの稼働率は99.984%
    しかも計画停止は無しということです。

    もう1つ、IBMから
  • IBM 官公庁のクラウド・コンピューティング活用の最適解はどこに?

  • 一般的なパブリック・クラウドが提供するサービスの稼働率は、スリーナイン(99.9%)程度と言われます。これに対してプライベート・クラウドでは、データセンター内のサーバーやストレージなどのIT資源を一貫してメンテナンスすることが可能なため、ファイブナイン(99.999%)やシックスナイン(99.9999%)といった稼働率を実現できます。


    稼働率の時間換算

    ここまで、さも当然のように9が並んでますが、わかりやすく時間に換算してみます。
    稼働率を年間当たりのダウンタイムに計算すると・・・

    稼働率1年365日当たりの停止時間
    99.9999%six nine31秒
    99.999%five nine5分
    99.99%four nine52分
    99.9%three nine8時間45分
    99%two nine3日15.6時間
    9%one nine332日3.6時間

    計画的なメンテナンスだとしてもユーザからしたら使えないわけで、サーバダウン、キャパシティオーバー、全て含めるとスリーナインも難しいのがわかります。

    one nine は冗談です(キリリッ


    RASISとは

    この稼働率を含む、サービスの信頼性を評価する基準にRASISというものがあり、5つの要素で構成されています。

    Reliability(信頼性)

    システム機能の時間的安定性(平均故障間隔で示される)。

    Availability(可用性)

    故障による稼動不能から可能状態に回復できる度合い。

    Serviceability(保守性)

    システムの故障発生時の保守の容易さ。平均修理時間(故障修理時間の平均)で示される。

    Integrity(保守性、完全性)

    故意または過失によるシステムやデータの破壊がないことを示す。

    Security(機密性)

    システム内情報の機密保持等を示す。

    具体例

    MTBFが大きくMTTRが小さいシステムほど可用性が高く、総合的な信頼性が高いシステムであるといえます。

    具体的に例を出してみます。

    設定値

    Reliability(信頼性)

    Serviceability(保守性)

    Availability(可用性)

    1年に4時間を5回落としただけでもうトゥーナインになります。
    平均1752時間に1回は落ちるし、落ちたら復旧に平均4時間かかりますよ、と。

    IntegrityとSecurityについては数値で出るものじゃないので、計算できる3つでRASともいいます。

    運用について

    例えば、今、自分のサービスはどの程度の質なのだろうかと気になった時に、都度調べて数値化するなんてことはありえません。サーバ単位・クラスタ単位・サービス単位でそれぞれ自動的に可視化しておくことが望ましいです。RASは自動化し、それ以外はチェック項目を作成し、かつ部分的に自動化といった感じでしょうか。

    クラスタ単位だとVirtualAddressに対するチェックになったり、サービス単位だと、WANやPublicDNSが落ちても接続できなくなるので、ユーザと似た条件のネットワーク経路でのチェックにする必要があります。

    実際の運用においては、レスポンスタイムを何秒までをHealthyと定めるか、何箇所の同時故障まで対応するか、どの部分を自動復旧にするか、といった質を上げるための様々な要素を考え、適度に堅牢なシステムに練りあげていくことになります。

    そのためにも信頼性の可視化を先にしておくと、成果を確認できてモチベアップしたり、あと何をどれくらいやるべきかを判断できるようになるので、早めに取り組むと幸せになれること間違いなしです。