Google Cloud
可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと
2017年2月14日
Google Cloud Japan Team
そこで今回は、最初の原理に立ち戻り、そもそも成功とは何を意味するのかを追究し、実際にシステムが成功しているかどうかを把握する方法について考えてみたいと思います。
成功の前提となるのは可用性です。可用性のないシステムは機能を実行できませんし、最初の段階で失敗します。では、可用性とは一体何なのでしょうか。まずはこの言葉を定義しなくてはなりません。
可用性とは、システムが意図した機能をある時点で実行できるかどうかということです。可用性の測定はレポーティング ツールとして活用されるほか、過去の可用性を見ることで、今後もシステムが期待どおりに動くかどうかも把握できます。
可用性は、直接時間で計測されるだけでなく、時にはリクエスト数によって計測されることもあります。いずれにしても数式の構造は同じで、合計の単位を成功の単位で割ることになります。
たとえば、稼働時間 /（稼働時間 + 停止時間）や、成功したリクエスト数 /（成功したリクエスト数 + 失敗したリクエスト数）という数式で可用性を計測できます。どの単位を使用するかにかかわらず、計測の結果は 99.9 % や 99.999 % といった割合で示され、これをスリー ナイン、ファイブ ナインと呼ぶこともあります。
可用性を高める一番の方法は、失敗（停止時間や失敗リクエストなど）の要因に焦点を当てることです。時間ベースの可用性を例に説明しましょう。
一定の期間（たとえば 30 日、または 4 万 3,200 分）と、可用性の目標値 99.9 %（スリー ナイン）があったとします。単純計算では、このシステムには 30 日間のうち 43.2 分以上の停止時間が認められていません。43.2 分という数字は、計画時の非常に具体的な数値となっており、エラー予算と呼ばれることがあります。30 日の間に 43.2 分以上システムが停止すると、可用性の目標が達成できなかったことになるのです。
エラー予算を理解し計画するにあたって、より深い 2 つの概念が使われることがあります。
1 つは Mean Time Between Failures（MTBF）であり、失敗の間隔の平均時間を表します。数式は、（稼働時間の合計）/（失敗の回数）です。
もう 1 つは Mean Time to Repair（MTTR）で、失敗から回復するまでの平均時間です。数式は、（停止時間の合計）/（失敗の回数）です。
こうした数値は（過去 3 か月や過去 1 年など）過去にさかのぼって計算でき、（合計期間 / MTBF）× MTTR という数式で予想停止時間を計算することも可能です。先ほどの例から引き続き計算すると、過去の MTBF が 10 日間で、過去の MTTR が 20 分となり、停止時間は 60 分となることが予想されます（計算式は（30 日 / 10 日）× 20 分です）。
つまり、スリー ナインという可用性の目標値を達成するうえでのエラー予算である 44 分をオーバーしてしまいます。目標を達成するには、MTBF を（20 日ごとといったように）低減させるか、MTTR を（10 分などに）抑えるか、もしくはその両方を組み合わせるしかありません。
可用性を定義する際に、エラー予算や MTBF、MTTR などの概念を念頭に置くと、なぜ目標値がそのように設定されたのかを正当化するのに役立ちます。単に目標としていくつのナインが必要だというのではなく、その目標値を、許容された停止時間や停止頻度、回復までの時間といったユーザー エクスペリエンスと結びつけることが可能になるのです。
次に、可用性の計測時にユーザー エクスペリエンスに焦点を当てる方法について考えてみましょう。
可用性の計測
システムの可用性が担保されていることを、どのようにして把握すればよいのでしょうか。ここで、架空の「シェイクスピア」というサービスを想定してみましょう。シェイクスピアは、シェイクスピアの小説に登場する特定の言葉やフレーズが言及されていることを探し出すサービスです。これは標準的な例であり、Google でもトレーニングの際によく使われていて、SRE（サイト信頼性エンジニアリング）の本でも数多く引用されています。
では、架空シェイクスピア システムの可用性を判定する科学的な手法を試してみましょう。
- 問題 : システムはどの程度稼働していますか？
- 観察 : shakespeare.com にアクセスすると、通常は “200 OK” というステータス コードと HTML blob が返ってきます。滅多にありませんが、500 Internal Server Error や接続失敗となることもあります。
- 仮説 : 1 日間のリクエストにおいて 200 OK となる率が可用性だとすると、システムは 99.9 % の可用性を担保しています。
- 測定 : シェイクスピア サービスのウェブ サーバーのレスポンス ログを追いかけ、ログ処理システムでダンプします。
- 分析 : 1 日の可用性を、200 OK となるレスポンス率と、リクエスト数の合計で計算します。
- 解明 : 7 日後、どの日も最低 99.7 % の可用性が担保されていました。
この可用性の数値を上司（Dave）に上機嫌で報告し、帰宅します。うまく仕事をこなせましたね。
翌日、Dave はサポート フォーラムに注目します。ユーザーが、shakespeare.com で検索しても何も結果が出てこないと文句を言っているのです。問題が起こっていることは明らかなのに、なぜ可用性ダッシュボードには昨日 99.7 % の可用性を担保していると示されているのか、Dave は問いただします。
ログを確認してみると、過去 24 時間にウェブ サーバーはちょうど 1,000 件のリクエストを受信し、3 件は 500 Internal Server Error となったものの、他はすべて 200 OK となっていました。1 秒あたり少なくとも 100 クエリがあったとすると、ダッシュボード上では何も問題がないのにユーザーがフォーラムで文句を言っている理由がわかります。
つまり、可用性を定義する際の測定方法がユーザーの期待値や事業目標に合っていないという典型的な間違いを起こしてしまったのです。
ブラック ボックスを監視し、ユーザー エクスペリエンスに基づいた可用性を再定義する
シェイクスピアのフロントエンド サービスがバックエンドにまで届くことを防ぐように、（設定ファイルのタイプ ミスという）致命的な問題を修正したら、今度はシステムの可用性の意味をもう一度考えてみましょう。「shakespeare.com で 200 OK となる率」が適切な可用性の測定法でないのだとしたら、どうやって可用性を測定すればよいのでしょうか。
Dave は、ユーザーが感じる可用性を知りたいと考えています。shakespeare.com が稼働しているとユーザーが感じるのはどんな場合なのでしょうか。あれこれと活発に議論した結果、システムが稼働しているという状況は、ユーザーが shakespeare.com にやって来て、質問を入力し、5 秒以内に 100 % その結果が返される状況だということで落ち着きました。
そこで、ブラック ボックスの「探査機」を作ることにします（ブラック ボックスとしているのは、シェイクスピア サービスの実装に関しては何も想定しないためです。SRE 本の第 6 章を参照してください）。
この探査機を用いて、（モバイルやデスクトップなど）完全なクライアント サービスをエミュレートします。それぞれのタイプのクライアントから shakespeare.com にアクセスし、「生きるべきか死ぬべきか」というフレーズを入力し、その結果にハムレットへのリンクが含まれているかを確認します。
この探査機を 1 週間稼働させた後、1 日の最小の可用性を再計算してみます。その結果、5 秒以内にハムレットという結果を返したのは 80 % で、18 % は 5 秒以上かかり、1 % はタイムアウトに、残り 1 % はエラーとなっていました。つまり、可用性の定義上、20 % ものクエリが完全に失敗に終わっていたのです。
事業目標に即した可用性を設定する
ショックから立ち直った Dave は素朴な疑問を抱きます。「なぜ 5 秒以内に 100 % の結果を返せないのだろうか？」最初に思いつく理由は、停電やファイバーが切れたといった、ありきたりのものばかりでした。約 1 時間後、ようやく Dave は、5 秒以内に 100 % クエリに応答することは到底無理なのだと認めるようになります。
「じゃあ、どの程度の可用性であれば提供できるのだろうか？」と Dave は考えます。
その質問に対し、Dave にさらなる質問を投げかけてみましょう。「事業目標を達成するために必要な可用性とは何なのか？」
Dave の目が輝きました。事業目標としているのは年間売上高 2,500 万ドルです。1 回のクエリにつき平均 0.01 ドルの売上げは立っています。（1 秒あたり 100 クエリ）×（年間 3,153 万 6,000 秒）×（成功率 80 %）×（1 クエリあたり 0.01 ドル）で計算すると、年間売上高は 2,523 万ドルとなります。つまり、失敗率が 20 % だとしても、売上目標は達成できるのです。
とはいえ、失敗率 20 % というのはちょっといただけません。売上目標が達成できそうだとしても、あまりいいユーザー エクスペリエンスとは言えませんし、その結果何らかの影響があるかもしれません。この状況を改善すべきでしょうか。もし改善するのであれば、可用性の目標はどうすべきでしょうか。
コストと利益の妥協点、機会費用を考える
エンジニアが 6 か月かけて問題を修復し、クエリの返答に 5 秒以上かかる率を 0.5 % まで低減できるとしましょう。この問題の修復に着手すべきかどうか、どうやって決めればよいのでしょうか。まず、20 % の失敗率が製品のライフにおいてどの程度の売上損失につながるのか（リトライするのをやめてしまうユーザーがどの程度いるのか）、見積もってみましょう。問題の修復にかかるコストはだいたい把握できています。単純に、エラー率によって失われる売上げが問題修復にかかるコストを上回っているのであれば修復する、と決めてしまうことも可能です。
ただし、これは重要な要素を無視しています。問題修復における機会費用です。問題の修復にかかる時間を他に回せばエンジニアはどんなことができるのか、考えてみてください。
シェイクスピア サービスの検索結果の関連性を高める新しい検索アルゴリズムがあるとしましょう。そのアルゴリズムを導入すれば、可用性は変わらなくても検索トラフィックが 20 % 増加するかもしれません。こうしたトラフィックの増加で、可用性が低いことによる売上げの損失は簡単に相殺できる可能性があるのです。
SRE でよく言われていることに、「必要とされるだけ可用性が高くなるようにシステムを設計せよ。ただし、それ以上のシステムは必要ない」という言葉があります。Google ではシステム設計時に、特定の MTBF や MTTR といった数値ではなく、（99.9 % というような）可用性を目標値として定めます。この可用性が達成できれば、今度は MTBF よりも MTTR のほうに重点を置き、迅速に修復を行えるような運用の形態に最適化します。失敗は避けられないものであり、「希望は戦略ではない」ことを認めるのです。
ほとんどの場合、SRE はユーザーにとって明らかに影響のある大きな問題を数分で軽減させることができます。そのため、Google のエンジニア チームは、迅速な開発と高可用性を両立させているという評判を得ているのです。
可用性と開発速度の妥協点は、最終的には事業側で決めることです。製品に対する可用性を正確に定義することで、本質的な議論ができ、満足のいく選択が可能になるのです。
注 : Google Cloud Next '17 開催まで 1 か月余りとなりました。Google Cloud の SVP である Diane Greene や、Google の CEO である Sundar Pichai、その他著名人らによる基調講演やコード ラボ、認証プログラム、さらには 200 以上ものテクニカル セッションにぜひご登録ください。ちなみに今回のイベントでは、Google の SRE や開発のエキスパートとイベント参加者が交流できるような専用の場を初めて設けています。
* この投稿は米国時間 1 月 26 日、Customer Reliability Engineers である AJ Ross、Matt Brown、Adrian Hilton と、Director of Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿はこちら）の抄訳です。
- By AJ Ross, Matt Brown and Adrian Hilton, Customer Reliability Engineers, and Dave Rensin, Director of Customer Reliability Engineering
