クラウド選びの勘所〜稼働率とSLAを読み解く〜

クラウド選びの勘所 ~稼働率とSLAを読み解く~

近年クラウドサービスの利用率はますます高まってきています。
利用企業の業種としては、これまでは主にネット系企業で利用されていたものが一般企業にも浸透してきました。また、システム用途としては、これまでテストや開発用途で使われたものが本番系のシステムへ、時には基幹系のシステムでも使われるようになってきています。
このように、より重要性の高いシステムでクラウドを利用するようになると、クラウドサービスの可用性、安定性などが気になってくるでしょう。今回は、クラウドの可用性/安定性指標としてよく使われている稼働率やSLAの意味について考えます。
(2012年9月 掲載開始)

SLA≠稼働率

サービスレベルの指標=稼働率

サービスレベルとしてどんな指標が使われているでしょうか。クラウドサービスや通信サービスで、最もよく使われているのが可用性の指標としての「稼働率」でしょう(次いで、ネットワークの遅延時間が多いと思います)
クラウドサービスを開発用途ではなく、本番系で利用するようになれば、特にシステムの可用性、安定性が気になるところです。その指標として稼働率はよく使われる指標です。

稼働率とは?

稼働率の定義

ところで、「稼働率」とはなんでしょうか。
ある一定期間の稼働率=(全時間-システム停止時間)/全時間 なお、ここでいう「システム停止時間」はシステムが停止してから復旧するまでの時間の合計となります。つまり「故障回数が少ない」または「故障から復旧するまでの時間が短い」と高い稼働率となります。

具体的な稼働率の試算

稼働率の定義だけでは、クラウドの可用性/安定性指標としてイメージしにくいかと思いますので、具体的な稼働率と停止時間の概算を試算してみましょう。

この表から稼働率ごとの停止時間を参照して、この程度の時間システムが止まったらどうなるかをクラウド化を考えているシステムごとにイメージしてみるとよいでしょう。システムによっては、年間丸4日間(稼働率=99%の場合)の停止は許されないでしょうし、年間9時間(稼働率=99.9%の場合)の停止でも厳しいシステムもあるでしょう。

もちろん、システムの停止時間は短い(高可用性/高稼働率)に越したことはありませんが、一般的には、高い稼働率を目指すほどコストも上がります。つまり、「稼働率とコストはトレードオフの関係」にありますので、自社システムにあった稼働率の目安を検討しておくことが重要です。

なお、日本情報システム・ユーザー会の調査によると、日本の大企業での基幹系システムの稼働率目標は99.8%だそうです(99.8%は稼働率の「目標」で、稼働率の「実績」はこれをほぼクリアしている状態)。

▽稼働率と停止時間

稼働率 停止時間概算(年間)
99% 4日
99.9% 9時間
99.99% 1時間
99.999% 5分
99.9999% 32秒

▽稼働率と停止時間

稼働率 コスト

稼働率とシステム構成

参考として、稼働率ごとのシステム構成イメージを示すと以下のようになります。
※もちろん、正確には、機器・運用形態などによって異なりますが、目安となります。

稼働率目安 システム構成イメージ
99% シングル構成
99.9% シングル構成に加えて、バックアップ取得、常時監視、運用マニュアル整備など適切な運用を行なっている
99.99% コールドスタンバイ構成+適切な運用
99.999% ホットスタンバイ構成(冗長構成)+適切な運用

SLAとは?

サービスの稼働率目安としてよく使われるのが「SLA(Service Level Agreement)」です。クラウドサービスの可用性/安定性指標としても使われるようになりました。SLAは、最近よく耳にするようになってきましたが、一口にSLAといっても複雑ですので、注意が必要です。

SLAのタイプ

1.SLA対象の指標

SLAの指標は、いろいろなものが考えられます。SLA指標として最も一般的なのは先に上げた「稼働率」でしょう。それ以外に「遅延時間」「保守連絡までの応答時間」など幾つかの項目がありえます。

2.SLA値の対象期間

指標以外にSLA値を算出する対象期間にも注意が必要です。稼働率を積算する期間としては、「1ヶ月」または「1年間」が一般的です。どちらでも同じように見えますが、例えば、稼働率99.9%のSLAの場合、対象期間が1ヶ月であれば、1回1時間の停止があればSLA違反ですが、対象期間が1年間であれば、1回8時間の停止があってもそれ以外の期間稼働していればSLA違反とはなりません(稼働率99.9%の場合の停止時間。[1年間]9時間、[1ヶ月]43分)。例えば、Amazon EC2では稼働率を算出する期間を「サービス年度における年間使用可能時間割合」としています。

3.SLA値算出の対象

期間以上に注意が必要なのは、SLA値算出の対象です。
どこの値を取るか、稼働率であれば、どの部分の稼働率をSLA対象とするかは、各社のサービスによってまちまちになっています。
1つの顧客ごとのサービス(例えば、対象のサーバ)で設定されるSLA、インフラ全体として設定されるSLAなどがあります。例えば、Amazon EC2ではSLAの対象を、「リージョン」としています。つまり、システムダウンがあっても、一つのリージョン内で他のシステムが動いていれば、「稼働中」とみなされます。

SLA=保証という勘違い

SLAに関する最もよくある勘違いが、SLA値が稼働率であれば「その稼働率以下の値にはならないことを保証している(可用性を保証している)」ということでしょう。
SLAとは、いわゆる「保証(Assurance)」ではなく、設定した値に関する「合意(Agreement)」です。クラウド事業者との間で「SLA値に達しない場合は一定金額を返金する」などの合意規定がある場合が一般的です。
よって、クラウド事業者は極端な話「返金さえすれば値を超過しても良い」わけです。このためSLAで設定された値をそのまま信じるのは危険であり「SLAの設定は利用者にとって意味が無い」と考える専門家もいます。
(実際、クラウドサービスにおいても「SLA100%」を謳った「保証」であればありえないSLA値設定を行なっているサービスもあります)。

どうやって自社にあったクラウドサービスを選ぶか?

先に述べたように、SLAは返金規定さえ用意すればよいため、クラウド選びにおいてSLAの値をそのまま可用性/安定性の目安にするのは危険です。よって、単にSLAの値だけでなく、これまでの稼働率の実績、システム構成(冗長性)などを参考にして総合的にクラウドの選定を行う必要があるでしょう。

クラウドサービスにおいて、SLAの値は「契約」なので、必ず公表されています。しかし、稼働率の「実績」やシステム構成などは利用者にとって「ブラックボックス」となっていることがほとんどです。よって、クラウドサービスの選定においては、SLA以外に稼働率実績やシステム構成などをクラウドサービスの可用性/安定性指標として可能な限り確認するとよいでしょう。現在クラウドサービスご利用の場合は、自社の可用性要求にマッチしているのか一度確認してみてはいかがでしょうか。

この記事を読んだ方にオススメのコラム

社内システムクラウド化の意外な課題
近年、これまでクラウドサービスの利用が進んでいなかった一般企業の情報システム用途などにも、クラウドは浸透してきています。このコラムでは社内システムをクラウドへ移行する上でのメリットとその際の課題を解説します。

システム障害対策の勘所 ~復旧時間とコストのトレードオフ~
このコラムでは特に機器障害に的を絞り、システム構成とシステム障害時の復旧時間(システムダウン対策)について解説致します。また、合わせて各構成をとった場合のコストについても考えます。

コラム 一覧
ITインフラに関する、トレンド情報やお客様が抱えている課題などを、ビットアイル・エクイニクス独自の視点で解説する、各種コラムを掲載中です。