RASIS検索サービスをできるだけ落とさず安定させようとするのは当然ですが、ハードウェアの故障がある限りはサービスが落ちることを当然として構築・運用をします。するために安定度を可視化する必要が出てきます。前の記事ですがわかりやすくGoogle先生から。year.2010年のGmailの稼働率は99.984%。計画停止は無しということです。官公庁のクラウド・コンピューティング活用の最適解はどこに?一般的なパブリック・クラウドが提供するサービスの稼働率は、スリーナイン(99.9%)程度と言われます。これに対してプライベート・クラウドでは、データセンター内のサーバーやストレージなどのIT資源を一貫してメンテナンスすることが可能なため、ファイブナイン(99.999%)やシックスナイン(99.9999%)といった稼働率を実現できます。稼働率の時間換算ここまで、さも当然のように9が並んでますが、わかりやすく時間に換算してみます。計画的なメンテナンスだとしてもユーザからしたら使えないわけで、サーバダウン、キャパシティオーバー、全て含めるとスリーナインも難しいのがわかります。冗談です(キリリッRASISとはこの稼働率を含む、サービスの信頼性を評価する基準にRASISというものがあり、5つの要素で構成されています。Reliability(信頼性)システム機能の時間的安定性(平均故障間隔で示される)。故障件数Availability(可用性)故障による稼動不能から可能状態に回復できる度合い。MTTR)Serviceability(保守性)システムの故障発生時の保守の容易さ。平均修理時間(故障修理時間の平均)で示される。故障件数Integrity(保守性、完全性)故意または過失によるシステムやデータの破壊がないことを示す。Security(機密性)システム内情報の機密保持等を示す。具体例MTBFが大きくMTTRが小さいシステムほど可用性が高く、総合的な信頼性が高いシステムであるといえます。具体的に例を出してみます。99.77%1年に4時間を5回落としただけでもうトゥーナインになります。平均1752時間に1回は落ちるし、落ちたら復旧に平均4時間かかりますよ、と。IntegrityとSecurityについては数値で出るものじゃないので、計算できる3つでRASともいいます。運用について例えば、今、自分のサービスはどの程度の質なのだろうかと気になった時に、都度調べて数値化するなんてことはありえません。サーバ単位・クラスタ単位・サービス単位でそれぞれ自動的に可視化しておくことが望ましいです。RASは自動化し、それ以外はチェック項目を作成し、かつ部分的に自動化といった感じでしょうか。クラスタ単位だとVirtualAddressに対するチェックになったり、サービス単位だと、WANやPublicDNSが落ちても接続できなくなるので、ユーザと似た条件のネットワーク経路でのチェックにする必要があります。実際の運用においては、レスポンスタイムを何秒までをHealthyと定めるか、何箇所の同時故障まで対応するか、どの部分を自動復旧にするか、といった質を上げるための様々な要素を考え、適度に堅牢なシステムに練りあげていくことになります。そのためにも信頼性の可視化を先にしておくと、成果を確認できてモチベアップしたり、あと何をどれくらいやるべきかを判断できるようになるので、早めに取り組むと幸せになれること間違いなしです。23:34お世話になっております。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。