この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。
AWS 上にシステムを構築する際の可用性設計について考えてみます。
可用性の定義は幅広いですが「サービスが利用できている時間の割合」として今回は考えます。
AWS の SLA
AWS は SLA を公開しています。英語版が最新なので言語を English にしてご覧ください。
AWS Service Level Agreements
サービスごとに定義された稼働率を実現するように AWS が商業的な努力を払い
それを満たさない場合に契約者はサービスクレジットを受け取る権利があります。
AWS が公開しているベストプラクティスに従った構成が必要といった前提や
除外事項がサービスごとに定義されていますのでご確認ください。
更新日は少々前になりますが、日本語でまとめてあるブログもあります。
※ 最新は公式を参照ください。
Amazon Compute Service Level Agreement
Compute の SLA を例としてあげます。
2020年7月22日版では以下のようにサービスクレジットが定義されています。
Included Services
- Amazon Elastic Compute Cloud (Amazon EC2)*
- Amazon Elastic Block Store (Amazon EBS)
- Amazon Elastic Container Service (Amazon ECS)
- AWS Fargate for Amazon ECS and Amazon EKS
Service Credits
| Monthly Uptime Percentage | Service Credit Percentage |
|---|---|
| Less than 99.99% but equal to or greater than 99.0% | 10% |
| Less than 99.0% but equal to or greater than 95.0% | 30% |
| Less than 95.0% | 100% |
Multi-AZ で構成した場合 99.99% が目安になりそうなことは理解できそうです。
それでは
我々のようなベンダー、または、AWS 上で自社サービスを提供する事業社の担当者が運用設計を行う場合、この値を利用するべきなのでしょうか？
一部の AWS のサービスの可用性設計
運用設計を行う前に必ず目を通して理解しておきたいドキュメントが「AWS Well-Architected フレームワーク」です。
そのなかの 信頼性の柱 に付録として 付録 A: 一部の AWS のサービスの可用性設計 に興味深い記述があることを発見しました。
ドキュメントから抜粋すると、ここの記述されているものは以下の意味があるようです。
一部の AWS サービスが達成目標とする可用性について下記にまとめます。これらの値は、サービスレベルアグリーメント (SLA) または保証を表すものではなく、各サービスの設計目標に対するインサイトとなるものです。
我々が運用設計を行う場合は、こちらのドキュメントを参照したほうが良さそうです。
SLA と比較するために EC2 と EBS の項目を抜き出してみます。
| サービス | コンポーネント | 可用性の設計目標 |
|---|---|---|
| Amazon EC2 | コントロールプレーン | 99.950% |
| シングル AZ データプレーン | 99.950% | |
| マルチ AZ データプレーン | 99.990% | |
| Amazon Elastic Block Store | コントロールプレーン | 99.950% |
| データプレーン (ボリュームアベイラビリティー) | 99.999% |
ここに書かれている「コントロールプレーン」とはマネージメントコンソールや CLI 等の API 部分、
「データプレーン」とは仮想サーバーやボリューム等のサービス実体だと私は理解しています。
コントロールプレーンとデータプレーンが分かれているのがミソで
EC2 は稼働しているけど API 受け付けない (例：再起動、スナップショット取得) ことも可能性としてはあるということです。
どこまで運用設計に落とし込むかはプロジェクトに依ると思います。
例えば、独自 Lambda で EC2 停止/起動を行っている場合は、コントロールプレーンの可用性設計目標が99.950%であることを考慮して
Lambda 実行の通知、成功失敗の通知を行っておかないと API 呼び出し失敗に気が付かず停止/起動が行われないといった事態もあり得ます。
(Lambda 関数呼び出し自体も99.950%のようですし)
まとめ
AWS は随分前から Design for Failure という言葉を使い、障害が起こる前提での設計や万が一が発生した際の復旧方法まで考えることが重要だと説いています。
自身の担当するシステムの可用性をどの程度に設計するか、そのために AWS サービス自体の可用性根拠をどこから参照するかを考えてみました。
全ての運用設計者の助けになれば幸いです。
Well-Architected for Startups -信頼性の柱- 導入編
参考
AWS Service Level Agreements
AWS Customer Agreement
AWS Well-Architected フレームワーク 信頼性の柱
AWS クラウドでの耐障害性のあるアプリケーションの設計
以上、吉井 亮 がお届けしました。