【SRE】サービスのSLO(サービスレベル目標)と可用性について

最近時間を作ってGoogleのSREの本を毎日読んでます。

この本の序盤でSLA、SLO、SLIという3つの言葉が出てきます。おそらくSLAは一般的に馴染み深い用語だと思うのですが、SLOとSLIはこの本を読むまで聞いたことがなかったです。

SLAとSLO、SLIについて

SLAはServiceLevelAgreementの略で、サービス提供事業者とその利用者の間で結ばれるサービスレベルの水準のことです。よく稼働率99.99%なんて表したりしますが、SLAはある種の契約に基づいたものであって、これを満たさなかったら金銭的に払い戻しペナルティが課されることが前提だったりするので、社内で内部的に持つ基準としてはふさわしい呼び方ではなく、別途SLO(ServiceLevelObjectives)というサービスレベル目標の方が意味的には近かったりするようです。

SLOは何をもって定めるのかというと、SLI(ServiceLevelIndicators)、つまりサービスレベルの指標を使い、通常SLIがどれくらいの範囲に属するかということで評価します。例えば、サービスが提供する可用性という指標について99.9%以上、99.99%未満みたいな使い方です。

可用性について

ところで、可用性とはシステムが継続して稼働できる能力のことですが、よく可用性99.9%みたいな表現って実際どれくらいの継続率なのかちょっと調べてみました。

可用性99%とは

1年間は31536000秒 × 0.01 = 315360 秒
それを時間に換算すると、315360秒 ÷ 3600秒 = 87.6時間
つまり年間で87.6時間停止相当
1ヶ月あたりだと7.3時間

1ヶ月に7時間もサービスとしてダウンする状態のことを指すんですね、99%って。
これって全然サービス提供のレベルとしては高くないですよね。毎月7時間ダウンしているサービス。

可用性99.9%とは

99.9%になるとどうでしょう。
こちらは年間で 8.76 時間停止することに相当します。
月間では43.8 分停止することに相当。

99%よりは遥かにレベルが高いものの、毎月1時間近くダウンしてるサービスちょっと不安ですね。

可用性99.99%(フォーナイン)とは

9が4つ並んでフォーナインと呼ぶらしいですが、これくらいになると
年間で 52.56 分停止することに相当
月間で 4.38 分停止することに相当

というわけでなかなか優秀そうですが、それでもユーザーから信頼されるサービスとしてはどうなんでしょうという気がしなくもないです。

可用性99.999%(ファイブナイン)とは

9が5つ並んだファイブナイン。
年間で 5.256 分停止することに相当
月間で 26.28 秒停止することに相当

これはなかなかすごいですね、月間で26秒です。
ほぼゼロに近づいて来てます。なかなかの信頼性ではないでしょうか。

可用性99.9999%(シックスナイン)とは

シックスナインまでいくと
年間で 31.536 秒停止することに相当
月間で 2.628 秒停止することに相当

月間2秒、ゼロではないものの、かなりの信頼性です。

ところでAWSとかの信頼性ってどれくらい?

ここまで可用性の9が一個増えるとどれくらいの稼働率を表すかを調べてみましたが、ぼくらがよく使っているAWSさんとかってどれくらいのサービスレベルを提供しているのかということが気になって調べてみました。

S3の可用性

S3の可用性は99.99%(フォーナイン)でした。
つまり
・年間で 52.56 分停止することに相当
・月間で 4.38 分停止することに相当
思ったよりは高くないのかというような印象です。

そーいえば先日、障害が発生してSlackが使えなくなったりしてましたもんね。
ただ、S3がすごいのが耐久性でした。

耐久性とはデータを失うかどうかという意味合いですが、S3はデータを入れる箱なだけに例え使えない時間帯が発生したとしても預かっているデータをロストするようなことがあってはいけないのです。

S3が提供する耐久性はなんと99.999999999%(イレブン・ナイン)。
イレブン・ナインです。これ、どれくらいのすごさなのかというと、1万個のオブジェクトを保存したとして、そのうち1つが障害によって失われるには平均で1000万年かかる計算らしいです。もうよく分かんないですが、それだけデータが失われないように設計されているということでした。

よく分かんないですが、すごそうですね。

EC2の可用性

EC2の可用性はS3と同じく99.99%(フォーナイン)でした。
ただし、2018年3月まで99.95%だったようです。99.95%は

・年間で 4.384.38 時間停止することに相当
・月間で 21.921.9 分停止することに相当

なのでだいぶ向上されてますね。

参考:AWSが主要サービスのSLA稼働率を引き上げた背景

Auroraの可用性

Auroraの場合、シングルAZかマルチAZかによってだいぶ異なります。
シングルAZの場合は、データを3つのAZに分けて2つずつ保存、6個のレプリケーションが存在し、堅牢性はS3と同じ99.999999999%
つまりデータとしては失われづらい構造になっているということですね。これはDBという特性上、データを失うことが一番怖いので素晴らしいことだと思います。

可用性としては、故障しても10分未満に自動回復。リードレプリカを設定していれば120秒以内に自動回復だそうです。
例えば、このブログなんかだと十分すぎる可用性ですね。
商用プロダクションサービスだとどうでしょう、ちょっと10分は場合によっては致命的になりそうです。

これをマルチAZにして複数のAZ分散するとどうなるでしょう。
故障した場合は30秒以内に自動回復、このときの可用性は99.99%だということでした。

マルチAZのデメリットはコストがシングルAZの2倍かかるというところですが、重要なサービスであれば必須かなと思います。
テスト環境や個人ブログ程度だったらコスト2倍は辛いので必要ないのではないでしょうか。

DynamoDBの可用性

DynamoDBの可用性は99.999%(ファイブナイン)でした。
つまり
・年間で 5.256 分停止することに相当
・月間で 26.28 秒停止することに相当
ですね。かなりの可用性の高さです。

DynamoDBにはクロスリージョンレプリケーション機能があり、非同期でデータを別リージョンにレプリケーションできるようです。
それによりリージョンでの障害が発生したときに別リージョンにフェイルオーバーでき可用性をさらに高めることができそうです。

サービスクレジット

AWSはSLAを定めていて、月間利用時間がSLAを下回ると利用料金の一部の返金請求ができるようになります。
注意点としては返還請求ができるというところで、申請しないと返金してくれないようです。

また、S3の月間利用可能時間が、99.0%以上99.9%未満の場合(21.6分以上)、利用金額の10%が、99.0%未満の場合(7.2時間以上)利用金額の25%が返金対象となるようです。

EC2の場合は、月間利用可能時間が99.0%以上99.9%未満の場合(21.6分以上)は利用金額の10%が、99.0%未満の場合(7.2時間以上)が利用金額の30%が返金対象となるようです。

まとめ

自社サービスのSLOを定めようとしたときに、使っているクラウドサービスの可用性、SLAには自ずと引っ張られることにはなるよなーという印象を持ちました。

コメントを残す