SLO、SLI、SLA について考える : CRE が現場で学んだこと

前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。

今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。

SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所にあるサービスの第 2 インスタンスを稼働させて負荷を分散するなど、何とか可用性を上げる必要があるかもしれません。

なぜ SLO があるのか

これで物事は簡単になりました。時々システムが 1 時間ダウンしても気にしなくていいからです。実際、新サービスのリリースや停止と再開の際にダウンタイムが発生するのは普通なのですから。

ところが、残念なことにお客様はそれを知りません。以前はちゃんと使えていたシェイクスピア検索が、突然エラーばかり起こすようになったとしか感じないのです。

サポート担当者は優先度の高いチケットを発行し、エラー率を確認して担当者にエスカレーションします。オンコール対応のエンジニアが調査し、それが既知の問題であることを確認したら、お客様に対して「これはよく起こることですので、エスカレーションの必要はありません」と返答します。

SLO がない場合、どの程度のダウンタイムであれば許されるのかを原理に基づいて語ることができないのです。発生した問題がサービスにとって重大かどうかを判断する基準さえ存在せず、「シェイクスピア検索サービスは現在 SLO に沿って運用しています」と言ってエスカレーションを終えることもできません。

Google での同僚である Perry Lorier は決まってこう言います。「SLO がなければ、君たちの仕事はとても大変だ」と。

SLO を決めるとそれがユーザーの期待値に

そこで、可用性のターゲットを最低 99 %、つまり 1 週間のダウンタイムを 1.68 時間と設定したとしましょう。しかし、実際にはシステムに結構な回復力が備わっており、6 か月間 99.99 % の可用性で稼働し、ダウンタイムは 1 か月に数分でした。

しかし、あるときシステムのどこかで障害が発生し、数時間にわたってシステムがダウンしてしまいました。地獄のような事態です。

お客様はオンコールの担当者に連絡し、何時間もシステムが 500 エラーになると苦情を伝えようとします。しかし、その連絡に気づく人はいません。というのも、オンコール担当者はページャーを机に置いたまま帰宅してしまったからです。SLO の規定によると、サポートは営業時間内のみとなっていました。

問題は、いつでもサービスが利用できる状況にお客様が慣れてしまったことです。お客様は、常にサービスが利用できるという想定のもとで、自社のビジネス システムにサービスを組み入れるようになりました。6 か月間も継続して利用できていた中で、数時間も停止してしまうと、確実に何らかの問題が起こっていることになります。これまで高可用性を保っていたために期待値もそこに合わせられ、問題となってしまったのです。

だからこそ、「SLO は上からのターゲットでもあり、下からのターゲットでもある」という言葉があるのです。もし非常に信頼性の高いシステムを作ろうとは思っていなかったり、高信頼性を約束できなかったりするのであれば、そこまでシステムの信頼性を高くしなくてよいということなのです。

Google では、可用性を過度に高めないようにするため、一部のサービスで定期的にダウンタイムを実施するようにしています。Google の Marc Alvidrez は SRE 本の中で、内部ロック システムの Chubby について語っています。

また、テストに利用する内部サービス用テスト フロントエンド サーバーも用意されており、外部からサービスにアクセスできるようになっています。このフロントエンド サーバーは便利ですが、決して本番サービスで使うためのものではありません。サービス レベル契約（SLA）も 1 営業日となっているため、サポート チームが修復にとりかかるまで 48 時間ダウンしていてもいいことになっています。

フロントエンドで使われていた実験サービスは、時が経つと徐々に重要なものとなっていきます。そのため、フロントエンドで数時間のダウンタイムが発生すると大騒ぎになってしまいます。

Google は現在、このフロントエンドに対して四半期ごとに計画的ダウンタイムを実施しています。担当者が警告を送信し、一部のホワイト リストを除きフロントエンドのすべてのサービスをブロックするのです。そして、この状態を数時間続けます。もしくは、ブロックによって大きな問題が発生するまで続けます。問題が発生した場合は、迅速にブロックをリバースすることが可能です。

ダウンタイムの最後に、担当者はフロントエンドを不適切に利用しているサービスのリストを受け取り、より適した場所にサービスを移動することをサービスの担当者と検討します。この計画的ダウンタイムにより、フロントエンドの可用性は適度に低く保たれ、不適切な依存関係を事前に検知して修復できます。

SLA は SLO とは違う

上記のことから、また原則可用性は SLO を大きく超えるものであってはならないことから、SLA は通常、SLO より緩めの目標を定めます。目標は可用性の数値で表すこともあります。

たとえば、1 か月の可用性は SLA で 99.9 %、内部的な可用性は SLO で 99.95 %、といった具合です。もしくは、SLO を構成する基準のサブセットのみを SLA として明記することも可能です。

シェイクスピア検索サービスの場合、API として提供することに決め、課金ユーザーは 1 日 100 万回まで検索を送信可能という条件で月額 1 万ドルを支払うとしましょう。

課金することになったため、契約書にはサービスの可用性がどの程度なのか、その契約を違反した場合どうなるかも明記しなくてはなりません。最低 99 % の可用性でサービスを提供するとし、以前お話ししたように成功クエリの定義も示すといった具合です。また、サービスの可用性が 1 か月 99 % 以下になった場合は 2,000 ドルを返金し、80 % 以下になった場合は 5,000 ドルを返金するといったことも明記します。

SLO とは異なる SLA を定めている場合（ほとんどのケースはそうなのですが）、SLA にきちんと準拠しているかを監査担当者が評価することが重要となります。SLA の期間に沿ってシステムの可用性を確認できるようにしておきたいでしょうし、SLA が満たされない危機が迫っていることも簡単に見極めたいと思うはずです。

また、一般的にはログや分析などにより、契約が守られていることを正確に評価する必要もあります。（SLA という形で）課金ユーザーに対して新たな責任を背負うことになったため、課金ユーザーのクエリをその他のクエリとは別に計測する必要も出てきます（ロード シェディングが必要となったときに、無料ユーザーのクエリが落ちてもあまり気にしなくていいかもしれませんが、課金ユーザーからのクエリについては適切に処理できないと大変です）。これが SLA を設定するもう 1 つの利点で、トラフィックの優先順位を決める明確な方法なのです。

SLA を定義する際は、どのクエリを正当なものとして数えるかに細心の注意を払う必要があります。

たとえば、主要ユーザー（サービスのトラフィックの大半を占めている）3 人に対し、1 人につき 1 日 100 万クエリを割り当てたとしましょう。ユーザーの 1 人がモバイル クライアントのバグだらけのバージョンをリリースし、変更を取り消すまで 1 日 200 万クエリを 2 日間発行しました。30 日の間に、うまくレスポンスを返した回数は約 9,000 万回、エラーの回数は 200 万回でした。つまり成功率は 97.8 % です。

このことで、全ユーザーに返金するのはいやだと思ってしまいますよね。2 人のユーザーの場合は全クエリが成功に終わっているし、3,200 万クエリのうち 200 万回のクエリを拒否されたユーザーの場合は自業自得だったわけですから。つまり、SLA を計算するときは「割り当て外」のレスポンス コードをすべて除外するようにしたほうがよいでしょう。

一方、帰宅前に担当者が誤って空の割り当て仕様ファイルをサービスにプッシュしてしまったとします。全ユーザーはデフォルトで 1 日 1,000 クエリを割り当てられています。上位 3 人のユーザーは、翌朝担当者が出社して問題に気づき変更を取り消すまでの 12 時間にわたって、常に「割り当て外」エラーになってしまいました。

この時点で、月間 9,000 万クエリのうち 150 万のクエリが拒否されたことになり、成功率は 98.3 % になっています。これはすべて担当者の責任です。100 % 成功している 8,850 万クエリをカウントするのはポイントがずれていますし、SLA を測定するうえでモラル的な失敗を犯していると言えるでしょう。

まとめ

一からシステムを構築しているのであれば、SLI、SLO、SLA をシステム要件に入れるようにしてください。すでにシステムが稼働しているのに明確な SLI、SLO、SLA を定めていない場合は、これらを定義することが最優先です。

以上のことをまとめると次のようになります。

• 信頼性のあるサービスを提供したいのであれば、まず「信頼性」を定義してください。実際には、信頼性は可用性を意味することがほとんどです。
• サービスの信頼性を把握したいのであれば、成功クエリと失敗クエリの率を測定する必要があります。これが SLI の基となります。
• サービスの信頼性が上がれば上がるほど、運用コストも高くなります。何とかやっていける最低レベルの信頼性を定義し、それを SLO としましょう。
• SLA がなければ、サービスの信頼性を高めるべきか（コストが増加し開発速度が落ちます）、信頼性をより低くするべきか（開発速度が上がります）、チームも関係者も原理的な判断ができません。
• ユーザーに課金するのであれば、SLA が必要となるでしょう。SLA は、SLO より少し緩めに設定しましょう。

前回の記事にコメントや質問を送っていただいた皆さんにとって、今回の投稿が役立つものであれば幸いです。今後もフィードバックをお待ちしています。

注 : Google Cloud Next '17 開催まで 1 か月を切りました。Google Cloud の SVP である Diane Greene や、Google の CEO である Sundar Pichai、その他著名人らによる基調講演やコードラボ、認証プログラム、さらには 200 以上にも上るテクニカル セッションにぜひご登録ください。ちなみに今回のイベントでは、Google の SRE や開発オペレーションのエキスパートとイベント参加者が交流できるような専用の場を初めて設けています。

* この投稿は米国時間 1 月 31 日、Customer Reliability Engineers である AJ Ross と Adrian Hilton、および Director of Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿はこちら）の抄訳です。

- By AJ Ross and Adrian Hilton, Customer Reliability Engineers, and Dave Rensin, Director of Customer Reliability Engineering