皆さんはアマゾン ウェブ サービス（AWS）のSLAをご存じですか？
AWSでは200近くある各サービスごとにSLAが決められています。※2021年8月現在
「サービスごとのSLAが知りたい」
「SLAのパーセントからダウンタイムを知りたい」
「システムがダウンしたらどうしよう」
こういった疑問をお持ちの方のために、AWSの主要サービスのSLAとダウンタイムの計算方法をご紹介。最後に、万が一障害が起きた場合に備えたおすすめの対策についても解説いたします。
そもそもSLAとは？
SLAとは、サービスレベルアグリーメントの略で、サービス提供者がサービス利用者に補償するサービスレベル（内容、品質水準など）を定義したものです。
サービスレベルを下回った場合の補償についても定められており、クラウドサービスの場合、利用サービスの利用料のうち数パーセントのサービスクレジットが利用できます。
SLAが定められている各サービスには、SLAに応じたサービスクレジットパーセンテージが設けられています。サービスクレジットパーセンテージは該当するサービスの将来の支払いに対して適用することができます。
つまり、SLAを下回った場合は返金されるのではなく、将来の同サービスの利用料から割引されるということです。またサービスクレジットはクレジットリクエストという申告を自ら行う必要があります。手続き方法は下記引用元を参照してください。
画像引用元：Amazon Compute Service Level Agreement
良く使われるAWSサービスのSLA
利用者が多いAWSサービスのSLAは以下の通りです。各サービスにはそれぞれSLAが適用される条件が決まっていますので自分の利用するサービスについては必ず確認してみてください。
| サービス名 | SLA | 補足 |
| Amazon Elastic Compute Cloud (Amazon EC2) | 99.99% | マルチAZの場合 |
| Amazon Elastic Block Store (Amazon EBS) | 99.99% | マルチAZの場合 |
| Amazon S3 | 99.9% | |
| Amazon RDS | 99.95% | マルチAZの場合 |
この中でも利用者の多いAmazon EC2のSLAについて詳しく見てみましょう。
単一のEC2インスタンスのSLAは99.5%
公式サイトを見ると、単一のEC2インスタンスのSLAは99/5%との記載があります。
インスタンスレベルのSLA
個々のAmazonEC2インスタンス（「シングルEC2インスタンス」）ごとに、AWSは商業的に合理的な努力を払い、インスタンスレベルの稼働率が少なくとも99.5％のシングルEC2インスタンスを利用できるようにします。いずれの場合も、毎月の請求サイクル（ 「インスタンスレベルのSLA」）。単一のEC2インスタンスがインスタンスレベルのSLAを満たさない場合、以下に説明するように、サービスクレジットを受け取る資格があります。
引用元：Amazon Compute Service Level Agreement
単一のEC2のSLAは2021年8月24日に、90%から99.5%に変更されています。
実際に90%と99.5%では稼働時間にどれだけ差が出るのか見てみましょう。
月間ダウンタイムを計算してみる
稼働率は以下計算式から算出できます。
月間稼働率＝（月間総稼動時間－累計障害時間）÷月間総稼動時間×100
24時間30日稼働するシステムの場合、
SLA90%の場合のダウンタイム | 72時間／月 |
SLA99.5%の場合のダウンタイム | 3.6時間／月 |
SLA90%と99.5%ではダウンタイムが月間68時間も減り、利用者にとってはより安心して使えるようになったことがわかります。
とは言え、月間3.6時間のダウンタイムも許容できない、止められないシステムではどのように稼働時間を確保すればいいのでしょうか。
Amazon EC2上のシステム障害対策
単一のEC2インスタンスの障害対策としては、EC2インスタンスやアプリケーションの再起動を行うという方法があります。普段使っているPCでExcelが固まったのでPCを再起動するイメージです。
EC2にはAuto RecoveryというEC2インスタンスを再起動する機能がありますが、Auto RecoveryはEC2のハードウェア障害や電源障害など、物理的な故障を検知した際に、EC2インスタンスを自動で再起動してくれます。
しかしながら、EC2インスタンスの上で動いているアプリケーションの障害は検知できないため、アプリケーションの故障時はAuto Recoveryでは対応できません。
そこで便利なのが、アプリケーション保護ソフトウェアSingle Server Protection（SSP）です。
SSPはOS上のアプリケーションを監視し、障害を検知するとアプリケーションの再起動やEC2インスタンスの再起動により復旧を試みるソフトウェアです。障害対策は必要だけど、あまりコストは掛けられない場合に適しています。
AWSはマルチAZ配置を推奨
単一のEC2インスタンスのSLAや障害対策について触れましたが、実はAWSとしてはEC2インスタンスを単一で使うことは推奨していません。
アプリケーションの可用性とパフォーマンスに関心を払うお客様は、耐障害性と低レイテンシーを実現するために、アプリケーションを同一リージョン内の複数 AZ にデプロイすることを望んでいるということです。各 AZ は高速なプライベート光ファイバーネットワークで相互に接続されているため、アプリケーションのフェイルオーバーを、AZ 間で中断なく自動的に実行できるようなアーキテクチャを簡単に設計できます。
「複数AZにデプロイし、アプリケーションのフェイルオーバーを、AZ感で中断なく自動的に実行できるようなアーキテクチャ」を実行するのにおすすめの手法がHAクラスターです。コストはそれなりにかかりますが、金融業や製造業などでシステムが止まると金銭的損失が出てしまうような場合に適した障害対策です。
HAクラスターソフトウェアの中でもAWS上での導入実績が多いのがLifeKeeperです。
LifeKeeperは、システムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことで、システムダウンタイムの時間を短縮し、ビジネス損失を最小限にします。
資料ダウンロード
AWS上でのHAクラスターの具体的な構築手順書は下記からダウンロードいただけます。
ダウンロード資料一覧
- クラウド環境で可用性要件が出てきたら読む資料
- AmazonEC2環境でのHAクラスター構成パターン
- 【Linux】Amazon EC2環境でのHAクラスター構築 Step by Step ガイド【ルートテーブルシナリオ編】
- 【Linux】Amazon EC2環境でのHAクラスター構築 Step by Step ガイド【Amazon Route 53編】
- 【Windows】Amazon EC2環境でのHAクラスター構築 Step by Step ガイド【ルートテーブルシナリオ編】
- 【Windows】Amazon EC2環境でのHAクラスター構築 Step by Step ガイド【Amazon Route 53編】
- 【Linux】Amazon EC2環境でのHAクラスター構築ガイド
まとめ
AWSのSLAとAmazon EC2上でのシステムの障害対策について紹介してきましたが、以下の3点覚えておいていただけると嬉しいです。
- AWSの各サービスにはSLAがありサービスレベルが保証される条件も違うので利用前には必ず確認
- EC2インスタンスは99.99%の可用性を担保するなら複数AZへの配置が必須
- 複数AZに配置したEC2インスタンスを障害発生時にフェイルオーバーさせるのがHAクラスター
