サービスをできるだけ落とさず安定させようとするのは当然ですが、ハードウェアの故障がある限りはサービスが落ちることを当然として構築・運用をします。
環境によってはマンパワーのベストエフォートでそれなりにいけちゃったりしますが、サーバ台数が増えたり、キチンと設計したり、組織の自分以外に性質を示したり、社会にアピールしたり するために安定度を可視化する必要が出てきます。
公開されている例
少し前の記事ですがわかりやすくGoogle先生から。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から
一般的なパブリック・クラウドが提供するサービスの稼働率は、スリーナイン(99.9%)程度と言われます。これに対してプライベート・クラウドでは、データセンター内のサーバーやストレージなどのIT資源を一貫してメンテナンスすることが可能なため、ファイブナイン(99.999%)やシックスナイン(99.9999%)といった稼働率を実現できます。
稼働率の時間換算
ここまで、さも当然のように9が並んでますが、わかりやすく時間に換算してみます。稼働率を年間当たりのダウンタイムに計算すると・・・
稼働率 | 1年365日当たりの停止時間 | |
99.9999% | six nine | 31秒 |
99.999% | five nine | 5分 |
99.99% | four nine | 52分 |
99.9% | three nine | 8時間45分 |
99% | two nine | 3日15.6時間 |
9% | one nine | 332日3.6時間 |
計画的なメンテナンスだとしてもユーザからしたら使えないわけで、サーバダウン、キャパシティオーバー、全て含めるとスリーナインも難しいのがわかります。
one nine は冗談です(キリリッ
RASISとは
この稼働率を含む、サービスの信頼性を評価する基準にRASISというものがあり、5つの要素で構成されています。Reliability(信頼性)
システム機能の時間的安定性(平均故障間隔で示される)。
1 2 |
(算出方法) MTBF(Mean Time Between Failures) = 累積使用時間 / 故障件数 |
Availability(可用性)
故障による稼動不能から可能状態に回復できる度合い。
1 2 |
(算出方法) 稼働率 = MTBF / (MTBF + MTTR) |
Serviceability(保守性)
システムの故障発生時の保守の容易さ。平均修理時間(故障修理時間の平均)で示される。
1 2 |
(算出方法) MTTR(Mean Time To Repair) = 累積修理時間 / 故障件数 |
Integrity(保守性、完全性)
故意または過失によるシステムやデータの破壊がないことを示す。Security(機密性)
システム内情報の機密保持等を示す。具体例
MTBFが大きくMTTRが小さいシステムほど可用性が高く、総合的な信頼性が高いシステムであるといえます。具体的に例を出してみます。
設定値
1 2 3 4 |
1年365日 = 365日 * 24時間 = 8760時間 累積使用時間 = 8760時間 故障件数 = 5回 累積修理時間 = 20時間 |
Reliability(信頼性)
1 2 |
MTBF = 8760時間 / 5回 = 1752時間 |
Serviceability(保守性)
1 2 |
MTTR = 20時間 / 5回 = 4時間 |
Availability(可用性)
1 2 3 |
稼働率 = 1752時間 / (1752時間 + 4時間) * 100 = 0.9977220956719818 * 100 = 99.77% |
1年に4時間を5回落としただけでもうトゥーナインになります。
平均1752時間に1回は落ちるし、落ちたら復旧に平均4時間かかりますよ、と。
IntegrityとSecurityについては数値で出るものじゃないので、計算できる3つでRASともいいます。
運用について
例えば、今、自分のサービスはどの程度の質なのだろうかと気になった時に、都度調べて数値化するなんてことはありえません。サーバ単位・クラスタ単位・サービス単位でそれぞれ自動的に可視化しておくことが望ましいです。RASは自動化し、それ以外はチェック項目を作成し、かつ部分的に自動化といった感じでしょうか。クラスタ単位だとVirtualAddressに対するチェックになったり、サービス単位だと、WANやPublicDNSが落ちても接続できなくなるので、ユーザと似た条件のネットワーク経路でのチェックにする必要があります。
実際の運用においては、レスポンスタイムを何秒までをHealthyと定めるか、何箇所の同時故障まで対応するか、どの部分を自動復旧にするか、といった質を上げるための様々な要素を考え、適度に堅牢なシステムに練りあげていくことになります。
そのためにも信頼性の可視化を先にしておくと、成果を確認できてモチベアップしたり、あと何をどれくらいやるべきかを判断できるようになるので、早めに取り組むと幸せになれること間違いなしです。