SLAという言葉をご存知でしょうか。システムの可用性や安定を語るうえで非常に重要なキーワードとなります。例えばクラウドサービスにおけるSLAには保証される稼働率などが含まれます。
この記事では、クラウドサービスにおけるSLAの詳細や、SLAが適用されないユーザ側の責任範囲について解説します。
Contents
SLAとは？
SLAとはService Level Agreement(サービスレベルアグリーメント)の略で、事業者が提供するサービスについてその範囲・内容を明確にし、利用者側と合意できるようにしたものです。そのサービスの品質水準を数値化して、もし守られなかった場合には利用金額の減額や返金といったどのような補償をするのかについても明確にされています。
SLAがあることでユーザーは安心感を持ってサービスを利用することができ、また提供者側も事前にサービスの品質水準について合意が取れるため不用意なトラブルを防ぐことができます。
SLAに設けられる項目
SLAには複数の項目が設けられている場合が多いです。例えばシステム運用サービスに関するSLAでは以下のような項目が含まれます。
・バックアップの保存をどの程度の期間保証するか
・サービス要求があった際に何分以内に対応するか
・稼働率を何%以上保証するか
・作業ミスによる重大障害を年間何件以下とするか
・障害が起きた際に何分以内に連絡をするか
・障害が起きた際の復旧時間を何時間以内とするか
このうち特に障害に関する項目は、サービスの継続に関わるため大きく注目されます。中でも稼働率は、障害によるシステム停止の時間である「ダウンタイム」がどのくらいかを測るために大切な指標です。ダウンタイムは主に、1年間でどの程度の時間システムが停止してしまうかという「年間ダウンタイム」が基準となります。稼働率と年間ダウンタイムの関係は以下の通りです。
・稼働率99%の場合……年間ダウンタイム3.65日
・稼働率99.9%の場合……年間ダウンタイム8.76時間
・稼働率99.99%の場合……年間ダウンタイム52.56分
・稼働率99.999%の場合……年間ダウンタイム5.26分
稼働率の小数点が1つ違うだけで、ダウンタイムの数値に大きな変化があることがわかります。このような基準があることで、システムによって必要な稼働率を逆算してそれに合ったサービスを選択することも可能です。特に一部のインフラのような、わずかな時間でもサービス停止が重大な影響につながるシステムについては、できる限りダウンタイムを少なくする設計を行います。逆にある程度のダウンタイムが許されるシステムであれば、SLAの数値を基準にコスト面を重視したサービス選択ができるのです。運用するシステムに合った稼働率のサービスを選択することが重要といえます。
SLOとは
SLAによく似た言葉として「SLO」があります。これらの違いをおさえておきましょう。
SLOとは、Service Level Objective(サービスレベルオブジェクティブ)の略で、サービス提供者が目標値として設定する品質水準を意味します。SLAとの決定的な違いは、項目を守れなかった際の罰則が無いということです。
SLOはあくまで目標値であるため利用者と内容の合意を行う必要がなく、具体的な項目が開示されていない場合もあります。そのため、SLOはSLAよりもより厳しい基準で設けられていることが多く、サービス提供者側が内部の目標項目としてより厳しいSLOを設定してそれをもとに運用を行うことで、利用者と合意したSLAを守る用途で使われることもあります。
クラウドサービスの責任共有モデルとSLA
それでは、クラウドサービスにおけるSLAはどのように考えるべきなのでしょうか。実はクラウドサービスはその種類によってサービス提供者の責任範囲が大きく異なるため、SLAがどこまで適用されるのかを十分把握しておく必要があります。これは「責任共有モデル」と呼ばれ、代表的な分類は以下のとおりです。
SaaS
SaaS（Software as a Service）とは、クラウド経由で提供されるアプリケーションのサービスです。利用者側はアプリケーション上で扱うデータについては破損・紛失などに責任を負う必要がありますが、そのソフトウェアが提供されるまでに至るネットワーク・ハードウェア・OS・アプリケーションが正常に稼働するかどうかはサービス事業者側の責任範囲です。よってSLAが適用される範囲も広いものとなります。
PaaS
PaaS（Platform as a Service）とは、アプリケーションを実行するためのプラットフォームを提供するクラウドサービスです。ここではSaaSと比べてアプリケーション自体も利用者側が自由に設定することができるため、それらはサービス提供者の責任範囲ではなくなり、SLAは適用されません。
IaaS
IaaS（Infrastructure as a Service）とは、ITインフラそのものをクラウド経由で提供するサービスです。PaaSよりもさらに自由度が高く、OSやミドルウェアなど開発環境まで利用者側が設計できます。そのためサービス提供者側はインフラを提供するまでのネットワークとハードウェアだけが責任範囲となり、それ以降のソフトウェア環境の不具合についてはSLAは適用されないのです。
主なクラウドサービスにおけるSLA
具体的にクラウドサービスにはどのようなSLAが設けられているのでしょうか。ここでは有名なクラウドサービスである4社で設定されているSLAについて解説します。
AWS(Amazon Web Service)
AWSは、Amazon社が提供しているクラウドサービスです。サーバ、データベース、ストレージなどサービスの範囲は多岐にわたり、それぞれSLAの項目や数値が異なります。例えば仮想サーバを提供する「Amazon EC2」におけるSLAは月間稼働率99.99%以上の保証です。もし稼働率がこれを下回ってしまった場合、その数値に応じてサービス利用料金の一部が返金されます。ただしこの数値は「マルチAZ」と呼ばれる複数の地域のサーバにまたがったサービスを利用することが条件です。複数地域のサーバを連携することで、1地域のネットワークに支障が出た場合でも他地域のサーバを利用して冗長性を担保できるためSLA数値が高くなっています。
また、ストレージサービスである「Amazon S3」では可用性が99.99%になるよう設計されているとSLAで述べられています。さらに保存したファイルがAWS起因で破損・紛失しない耐久性は99.999999999%を保証しています。このAmazon S3についても、SLAの数値はマルチAZによる利用が条件です。大きなサービスで世界中にデータセンターを展開しているAWSだからこそ提供できる高可用性といえます。
さらにAWSのSLAについて詳しく知りたい方は、下記の記事も参考にしてみてください。
AWSのSLAとAmazon EC2上のシステム障害対策方法とは？
Microsoft Azure
Microsoft社が提供しているクラウドサービスであるAzureもSLAによって高い稼働率を保証していますが、サービスの利用方法によって数値が異なります。例えば代表的なサービスとして仮想マシンを提供する「Azure Virtual Machines」がありますが、稼働率は以下のように変動します。
- 単一の仮想マシンであれば99.9%以上
- 複数の仮想マシンを同一可用性セットに配置している場合は99.95%以上
- 同一リージョン内にある複数の可用性ゾーンに配置している場合は99.99%以上
このように、システムごとに必要とされる要件によってサービスの動かし方を選択することができ、稼働率とコストのバランスを取りやすくなっています。
Azureに関するさらに詳しい情報は、下記の記事もご覧ください。
GCP(Google Cloud Platform)
Google社から提供されているGoogle Cloud Platformでもさまざまなクラウドサービスが展開されています。そのうち基本的な仮想マシンを提供するGoogle Compute EngineにおけるSLAは、Azureと同様にサービス利用方法によって変動します。具体的な稼働率は以下のとおりです。
- 単一の仮想マシンであれば99.5%以上
- 複数地域にまたがった構成であれば99.99%以上
- ロードバランシングを用いていれば99.99%以上
「ロードバランシング」とは、複数の仮想マシンを組み合わせる機能です。自動的に負荷分散を行いパフォーマンスを高めたり、障害の際には自動的に他地域の物理マシンに切り替えたりといった冗長性の担保が可能となっています。
OCI(Oracle Cloud Infrastructure)
こちらはデータベース管理ソフトウェアで有名なOracle社が提供しているクラウドサービスです。OCIのSLAは、同一リージョン内の独立したインフラである「可用性ドメイン(AD)」や、同一可用性ドメイン内の複数のハードウェアグループである「フォルト・ドメイン(FD)」により冗長化されているかどうかで変わります。具体的には、仮想マシンを提供する「Compute」のSLAは以下の通りです。
- 単一の仮想マシンであれば99.9%以上
- 複数のFDにより冗長化されていれば99.95%以上
- 複数のADにより冗長化されていれば99.99%以上
ユーザーの責任範囲に対応するには？
ここまで見てきたように、クラウドサービスはSLAが細かく設定されているのと同時に、サービスの種類によって事業者の責任範囲が明確になっています。逆に言うと、ユーザーの責任範囲部分に関してはきちんとユーザー側で対策を施す必要があるということです。特にIaaSを利用している場合、物理的なハードウェア・ネットワーク以外はすべてユーザー側の管理責任となります。当然、これらの範囲にSLAは適用されません。具体的には、ファイアウォールなどのセキュリティ設定、OSやミドルウェアの脆弱性対策、アプリケーションが正常稼働しているかの監視など多岐にわたります。
ユーザー側の責任範囲に対応する有効な手段の一つとして、HAクラスターの活用があります。
HAクラスターとは、複数台のサーバを相互接続してシステムの可用性を高める連携構成です。何らかの障害が発生した際に、待機している予備のサーバへ即座にサービスを引継ぎ、運用を継続します。クラウドサービス内の復旧システムとは異なりアプリケーションの障害検知も可能であるため、システム全体の障害対策を可能にしつつ監視コストを抑えることが可能です。
また、HAクラスターの導入はベンダー側が起因の障害対策にも有効であるのも重要な点です。 例えば最大手であるAWSでも、2019年8月にはデータセンターの冷却設備の不具合によりサーバがダウンする事象が発生しています。このような障害には当然SLAが適用され、ダウンタイムに応じて返金がされますが、サービスに影響が出ることには変わりありません。しかしユーザ側でHAクラスター導入など可用性を高める対策をしておくことによって、万が一障害が発生した際も継続してシステム運用をすることが可能となるのです。
HAクラスターを活用してSLA範囲外の障害対策を
このようにSLAは利用するサービスを選定する上で大きな指標となりますが、クラウドサービスにおいては必ずしもシステム障害の全てに適用されるとは限りません。ユーザ側の責任範囲の対策としては、HAクラスターの導入がオススメです。
