オンラインセミナー

データセンタのホスティングサービスを検討したことがある方なら経験があると思いますが、サービス品質を評価する基準の一つとして、稼働率やSLAを確認されたのではないでしょうか。

SLAは、サービスの稼働実績や、もしも稼働率が一定基準を下回った場合の補償などが定義されており、サービスの信頼性を測る指標として用いられています。

AWSでも主要なサービスではSLAが定義されているのはご存知でしょうか。

ただし、AWSをはじめとしたパブリッククラウドのサービスでは、前述のホスティングサービスとはSLAの考え方が違うようです。今回はこのあたりに触れて書いてみたいと思います。

AWSのSLAとは

現在、AWSでSLAが明記されているのは以下のサービスです。
それぞれサービスコミットメントの目標値と、それが守れなかった場合のサービスクレジットの割合が定義されています。

サービスサービスコミット定義使用可能
時間の割合
サービス
クレジット
停止時間目安
(1ヶ月=30日)
EC2 月間使用可能時間の割合 99.0%以上
99.95%未満
10% 21.6分以上
99.0%未満 30% 7.2時間以上
EBS 月間使用可能時間の割合 99.0%以上
99.95%未満
10% 21.6分以上
99.0%未満 30% 7.2時間以上
S3 月間使用可能時間の割合 99.0%以上
99.95%未満
10% 43.2分以上
99.0%未満 30% 7.2時間以上
RDS 月間使用可能時間の割合 99.0%以上
99.95%未満
10% 21.6分以上
99.0%未満 25% 7.2時間以上
CloudFront 月間使用可能時間の割合 99.0%以上
99.95%未満
10% 43.2分以上
99.0%未満 25% 7.2時間以上
Route 53 使用可能時間割合が100%でなかった期間 5~30分 1日分 5~30分
31分~4時間 7日分 31分~4時間
4時間以上 30日分 4時間以上

Amazon EC2 サービスレベルアグリーメントを引用すると、サービスコミットの基準となる月間使用可能時間の割合については

「月間使用可能時間の割合」は、1月の間に、Amazon EC2またはAmazon EBS(適用される場合)が「地域(Region)使用不能」の状態になった時間(単位は分)の割合を100%から減じて計算される。

とあります。

「地域(Region)使用不能」とはあまりなじみのない言葉ですが、

「地域(Region)使用不能」とは、同一地域(Region)内で、サービス利用者がインスタンスを実行している複数のAvailability Zoneが、サービス利用者にとって「使用不能」となることをいう。

「使用不能」とは、Amazon EC2については、サービス利用者の実行する全てのインスタンスの外部との接続性がない状態をいう。(以下略)

との説明があります。

1ヵ月で20分前後、の停止状態を許容できるかどうかはさておき、仮にサービスが停止したとしても、即座に返金されるとは限りません。

SLAには例外事由が(i)~(vii)まで併記されており、それに該当する状態はサービスの停止とは認められないケースがあります。分かりやすいところでは以下のような場合が該当します。

(iv)サービス利用者 の機器、ソフトウェアもしくはその他の技術、および/または第三者の機器、ソフトウェアもしくはその他の技術(アマゾンの直接支配の範囲にある第三者の機 器を除く)により生じたものである場合、(v)地域(Region)使用不能に帰因するものでない、個別のインスタンスまたはボリュームの障害の結果生じたものである場合、

つまり、インスタンスやアベイラビリティゾーンの障害や停止が、一箇所あるいは利用中のサービス全体の一部に留まる場合は、使用不能時間に数えられません。ユーザが独自に持ち込んだ機器やソフトに起因するものも同様です。

これらの例外に該当せず、地域使用不能によってサービスが停止してしまった場合は、サービスクレジットの返還を申請できます。自動的に返金されるわけではない点に注意です。AWS側で状況が確認されれば、サービスクレジットが発行されます。

申請の際、ユーザにはサービス停止を裏付ける証拠(エラーログなど)の提出が求められます。ユーザはサービス停止が起きた時のために、それが個別の障害なのか、リージョン使用不能状態にあたるのか、また何分間停止状態にあったのか、などを常に把握できるようにモニタリングが不可欠です。

 

 

おそらくこのとき、監視にはAWSのCloudWatchなどが用いられるでしょう。

しかしここにはもう一つリスクがあります。

クラウド上の仮想基盤で問題が発生した場合にそれを検知できないケースです。

AWSの上で稼働するCloudWatchや、サーバインストール型の監視ツールではその仮想基盤をホストしている物理サーバの状態やパフォーマンスを測ることが困難です。

監視情報に残せなければ、サービスの停止が認められないなどのケースも予想されます。

この問題に対しては、クラウドの外側からクラウド基盤のパフォーマンスを測定する必要があります。

CloudTriageを用いてクラウドマイグレーションを成功に導くための4つのメリットをご紹介。

クラウド上の仮想化基盤のリソースを把握できない部分をリモート監視で補うことで、異常を検知します。詳しい情報はこちらからご覧ください。

関連記事:

ホスティングサービスなどとの大きな違い

自社のサービスをアウトソーシングする際は、実現したい稼働率をベンダーと取り決めたものをSLAとして保証してもらうこともできますが、AWSのSLAとは、いわゆる「保証(Assurance)」ではなく、設定した値に関する「合意(Agreement)」です。

このように、AWSを始めとしたパブリッククラウドのサービス事業者はSLAをあらかじめ提示しており、ユーザがそれに同意するという形式が一般的です。そこに交渉の余地はありません。ユーザが選択できるのは、Amazonなどのクラウド事業者から提示されたSLAを受け入れるか、納得できなければ、より高いサービスレベルを提供するベンダーと契約するかです。

先のとおり、AWSでも「SLA値に達しない場合はサービスクレジットを返還する」という合意規定となっていますが、これは別の見方をすれば、「返金さえすれば値に達しなくても良い」ともとれます。EC2などは最大で30%の返還ですが、サービス別に月額費用の3割といえば、そう大きな額ではないはずです。停止に伴う損失と釣り合う金額でしょうか。このSLAの数値をみて、例えば99.95%の稼働率が「保証」(あるいは「補償」) されるものと考えているとしたら、もう一度検討し直すべきかもしれません。

AWSのサービスレベルの考え方

このような書き方をすると、クラウド事業者はある種無責任なように捉えられてしまうかもしれませんが、それなりに背景があります。

AWSでは、基本的にサーバやDCは落ちるもの、という前提があります。この規模になれば、偶発的に発生する故障をゼロにするのは現実的ではありません。従ってAWSは利用者に対し個別に稼働率などの保証はしません。そのかわり、障害が発生してもサービスを継続させる仕組みと、それを実現するための空きリソースを常に提供しています。実際に、EC2のSLAの例外事由の中には以下のような記述もあります。

(iii)回復ボリュームを認識することを怠った場合を含む、サービス利用者または第三者の作為もしくは不作為の結果である場合

手軽に利用できる一方で、高いサービスレベルを維持することを望むなら、ユーザにはAWSから提供された機能を適切に使いこなす責任が課せられているともいえます。

たとえばEC2のインスタンスが障害で停止してしまったなら、即座に別のリソースを確保して保存したバックアップをリストアすることで復旧できます。可用性を高める目的であれば、インスタンスの追加、削除が手軽なことを活かして、複数のサーバを分散構成で構築することが容易ですし、アベイラビリティゾーン(AZ)と呼ばれる複数のデータセンタ間で冗長構成を組むことも可能です。リージョンが丸ごと停止することも想定するのであれば、海外のリージョンと冗長構成を組むことも選択肢に含まれます

当然、可用性を高めればそれに伴ってコストも高騰します。しかし無停止に近い状態を確実に作り出したいのであれば、それ相応のコストとエンジニアリングを必要とするのはオンプレミスでも同様です。

一方で、可用性は考慮しなくてもよいのでとにかく安く、今すぐ使いたい、というユーザもいるでしょう。その場合は極力シンプルに組めばいいだけの話です。

どちらを求めるユーザにも、同じプラットフォームで対応できるのが、AWSのようなサービス形態とも言えます。

まとめ

以前のSLAは、ユーザの要件とのすり合わせの結果をお互いに同意するためのものでした。AWSをはじめとしたクラウド事業者の提示するSLAは、これとは意味合いが異なり、事業者側のサービス品質維持の努力目標と捉えるべきです。ユーザはその目標が自社のサービスを稼働させるのに十分か、あるいは問題が発生した時の保障は損失に見合うものかなどを検討したうえでSLAに同意し、サービスを契約することになります。

特にAWSでは、サーバやDCは落ちるもの、という非常に割り切った考え方が前提にあります。一方で、AWSでは、障害が起きても停止しない仕組みを構築することが可能な仕組みとリソースが常に用意されており、ユーザの求めるSLAの達成はユーザの手で実現することができるともいえます。

自社の求めるサービスレベルに合わせた構成と運用監視が一つのキーとなりそうです。

参考

Amazon EC2 サービスレベルアグリーメント
Amazon S3 サービスレベルアグリーメント
Amazon RDSサービスレベルアグリーメント
Amazon CloudFront サービスレベルアグリーメント
Amazon Route 53 サービスレベルアグリーメント

関連資料・おすすめのコンテンツ・人気の動画 など

banner_ebook01new.jpg

クラウドのサービスレベルが気になる方へオススメ

急にクラウドを検討することになったものの、クラウドやハイブリッドクラウドの運用はどうすればいいのか?そんな理由から情報収集のためにこのページをご覧いただいた方もいらっしゃるのではないでしょうか。

本書はそんな方たちへ向けた解説書です。クラウドとオンプレミスが一体となって提供されるサービスの健康状態を知り、問題を効率的に解決できる仕組みづくりに必要なものは何か?という疑問に対し、7つのチェックポイントを挙げて解説しています。

最新記事