SRE (サイト信頼性エンジニアリング) は、Web プロジェクトの可用性を確保するためのアプローチです。 これは DevOps のフレームワークとみなされ、DevOps プラクティスの適用で成功を収める方法について説明します。 この記事の翻訳 第 4 章 サービスレベル目標 図書 サイト信頼性エンジニアリング Googleから。 私はこの翻訳を自分で作成し、監視プロセスを理解する上での私自身の経験に基づいて作成しました。 電報チャンネルでは モニターリム_it и ハブレに関する最後の投稿 また、サービス レベルの目標に関する同書の第 6 章の翻訳も出版しました。

猫による翻訳。 読書を楽しむ！

実際にどのような指標が重要で、どのように測定・評価するのかを理解していなければ、サービスを管理することは不可能です。 この目的を達成するために、当社はユーザーが内部 API を使用するか公開製品を使用するかに関係なく、一定レベルのサービスを定義し、ユーザーに提供します。

私たちは、サービス レベル インジケーター (SLI)、サービス レベル目標 (SLO)、およびサービス レベル アグリーメント (SLA) を理解したいというユーザーの欲求に対する直感、経験、理解を利用します。 これらのディメンションは、監視する必要があり、期待されるサービス品質を提供できない場合に対応する主要な指標を記述します。 最終的に、適切なメトリクスを選択することは、何か問題が発生した場合に適切なアクションを導くのに役立ち、また、SRE チームにサービスの健全性に対する自信を与えることにもなります。

この章では、メトリックのモデリング、メトリックの選択、およびメトリック分析の問題に対処するために使用するアプローチについて説明します。 例を使わずに説明することがほとんどなので、実装例（シェイクスピア作品の検索）で説明したシェイクスピアサービスを使って要点を説明します。

サービスレベルの用語

多くの読者は SLA の概念に精通していると思われますが、一般に SLA という用語は多用されており、文脈に応じてさまざまな意味をもつため、SLI と SLO という用語は慎重に定義する必要があります。 わかりやすくするために、これらの値を分離したいと思います。

インジケータ

SLI はサービス レベル指標であり、提供されるサービス レベルの一側面を表す慎重に定義された定量的尺度です。

ほとんどのサービスでは、主要な SLI はリクエストの遅延、つまりリクエストに対する応答を返すまでにかかる時間とみなされます。 その他の一般的な SLI には、受信したすべてのリクエストの一部として表されるエラー率や、通常 XNUMX 秒あたりのリクエストで測定されるシステム スループットが含まれます。 多くの場合、測定値は集計されます。まず生データが収集され、次に変化率、平均値、またはパーセンタイルに変換されます。

理想的には、SLI は対象のサービス レベルを直接測定しますが、元のメトリックの取得または解釈が難しいため、関連するメトリックのみが測定に使用できる場合があります。 たとえば、多くの場合、クライアント側の遅延の方がより適切な指標ですが、遅延がサーバー上でのみ測定できる場合もあります。

SRE にとって重要な SLI のもう 100 つのタイプは、可用性、つまりサービスを使用できる時間の部分です。 多くの場合、リクエストの成功率として定義され、歩留りとも呼ばれます。 (データ ストレージ システムでは、データが長期間保持される可能性であるライフタイムも重要です。) 100% の可用性は不可能ですが、99% に近い可用性は多くの場合達成可能です。可用性の値は次のように表されます。 「99,999」の数 » 可用性の割合。 たとえば、2% および 5% の可用性は、「99,95 ナイン」および「XNUMX ナイン」とラベル付けされる場合があります。 Google Compute Engine が現在定めている可用性目標は、「スリー・アンド・ハーフ・ナイン」、つまり XNUMX% です。

目標

SLO はサービス レベル目標です。SLI によって測定されるサービス レベルの目標値または値の範囲です。 SLO の通常の値は、「SLI ≤ 目標」または「下限 ≤ SLI ≤ 上限」です。 たとえば、SLO を 100 ミリ秒未満の平均検索クエリ待ち時間に設定することで、シェイクスピアの検索結果を「速く」返すと決定するかもしれません。

適切な SLO を選択するのは複雑なプロセスです。 まず、特定の値を常に選択できるわけではありません。 サービスへの外部受信 HTTP リクエストの場合、XNUMX 秒あたりのクエリ (QPS) メトリクスは主にユーザーのサービスへのアクセス希望によって決定されるため、それに対して SLO を設定することはできません。

一方、各リクエストの平均レイテンシーを 100 ミリ秒未満にしたいとも言えます。 このような目標を設定すると、低レイテンシでフロントエンドを作成するか、そのようなレイテンシを提供する機器を購入する必要が生じる可能性があります。 (100 ミリ秒は明らかに任意の数値ですが、レイテンシの数値はさらに低い方が良いです。遅い速度よりも速い速度の方が優れていることを示唆する証拠があり、ユーザー リクエストの処理のレイテンシが特定の値を超えると、実際に人々が近づかなくなるという証拠があります。あなたのサービスから。）

繰り返しますが、これは一見したよりも曖昧です。計算から QPS を完全に除外すべきではありません。 実際のところ、QPS とレイテンシは互いに強く関連しています。QPS が高いほどレイテンシが高くなることが多く、サービスは通常、特定の負荷しきい値に達するとパフォーマンスが急激に低下します。

SLO を選択して公開すると、サービスがどのように機能するかについてのユーザーの期待が決まります。 この戦略により、パフォーマンスの低下など、サービス所有者に対する根拠のない苦情を減らすことができます。 明示的な SLO がないと、ユーザーは多くの場合、サービスを設計および管理する人々の意見とは何の関係もない、望ましいパフォーマンスについての独自の期待を作成します。 この状況は、ユーザーがサービスが実際よりもアクセスしやすいと誤って信じた場合にサービスに対する期待が膨らみ、システムの信頼性が実際より低いとユーザーが信じた場合に不信感を引き起こす可能性があります。

契約

サービス レベル アグリーメントは、ユーザーが含まれる SLO を満たす (または満たさない) 場合の結果を含む、ユーザーとの明示的または暗黙的な契約です。 結果は、割引や罰金などの金銭的なものである場合に最も容易に認識されますが、他の形をとる場合もあります。 SLO と SLA の違いについて説明する簡単な方法は、「SLO が満たされていない場合はどうなりますか?」と尋ねることです。 明確な結果がない場合は、ほぼ確実に SLO を検討していることになります。

SLA はビジネスおよび製品の意思決定と密接に結びついているため、SRE は通常、SLA の作成には関与しません。 ただし、SRE は、SLO の失敗による影響を軽減することに関与しています。 また、SLI を決定するのにも役立ちます。当然のことながら、契約には SLO を測定する客観的な方法がなければなりません。そうしないと、意見の相違が生じることになります。

Google 検索は、公的な SLA がない重要なサービスの一例です。Google は誰もが検索をできるだけ効率的に使用できるようにしたいと考えていますが、世界と契約を結んでいません。 ただし、検索が利用できない場合には、依然として影響が生じます。検索が利用できないと、当社の評判が低下し、広告収入も減少します。 Google for Work など、他の多くの Google サービスには、ユーザーとの明示的なサービス レベル契約があります。 特定のサービスに SLA があるかどうかに関係なく、SLI と SLO を定義し、それらを使用してサービスを管理することが重要です。

理論はこれだけですが、今度は体験してみましょう。

実際の指標

サービス レベルを測定するには適切な指標を選択することが重要であるという結論に至ったとして、サービスやシステムにとってどの指標が重要であるかをどのようにして知ることができるのでしょうか?

あなたとあなたのユーザーは何を重視していますか?

監視システムで追跡できる SLI としてすべてのメトリクスを使用する必要はありません。 ユーザーがシステムに何を求めているかを理解すると、いくつかの指標を選択するのに役立ちます。 選択するインジケーターが多すぎると、重要なインジケーターに焦点を当てることが難しくなりますが、少数を選択すると、システムの大部分が放置される可能性があります。 通常、システムの健全性を評価および理解するために、いくつかの重要な指標を使用します。

通常、サービスは、それに関連する SLI の観点からいくつかの部分に分類できます。

• カスタム フロントエンド システム (この例の Shakespeare サービスの検索インターフェイスなど)。 これらは利用可能であり、遅延がなく、十分な帯域幅を備えている必要があります。 したがって、「リクエストに応じることはできますか?」という質問が発生する可能性があります。 リクエストに応答するまでにどれくらい時間がかかりましたか? どれくらいのリクエストを処理できますか?
• ストレージシステム。 彼らは、短い応答遅延、可用性、耐久性を重視しています。 関連する質問: データの読み取りまたは書き込みにはどのくらい時間がかかりますか? リクエストに応じてデータにアクセスできますか? データは必要なときに利用できるのでしょうか? これらの問題の詳細については、第 26 章「データの整合性: 読み取った内容が書き込み内容と一致する」を参照してください。
• データ処理パイプラインなどのビッグ データ システムは、スループットとクエリ処理のレイテンシに依存します。 関連する質問: 処理されるデータの量はどれくらいですか? リクエストの受信からレスポンスの発行までにデータが送信されるまでにどれくらいの時間がかかりますか? (システムの一部の部分でも、特定の段階で遅延が発生する可能性があります。)

インジケーターのコレクション

サービス レベル インジケーターの多くは、Borgmon (以下を参照) などの監視システムを使用してサーバー側で収集されるのが最も自然です。 第 10 章 時系列データに基づくアラートの実践) または Prometheus、または単純にログを定期的に分析して、ステータス 500 の HTTP 応答を識別します。ただし、一部のシステムにはクライアント側のメトリクス収集を装備する必要があります。これは、クライアント側の監視が欠如していると、影響を与える多くの問題が見逃される可能性があるためです。ユーザーには影響しますが、サーバー側のメトリクスには影響しません。 たとえば、シェイクスピア検索テスト アプリケーションのバックエンド応答レイテンシに焦点を当てると、JavaScript の問題によりユーザー側でレイテンシが発生する可能性があります。この場合、ブラウザがページを処理するのにかかる時間を測定することがより良い指標となります。

集計

シンプルさと使いやすさのために、生の測定値を集計することがよくあります。 これは慎重に行う必要があります。

200 秒あたりのリクエストなど、一部のメトリクスは単純に見えますが、この一見単純な測定でも、時間の経過に伴うデータが暗黙的に集計されます。 測定値は特に 0 秒あたり 100 回受信されますか、それとも XNUMX 分あたりのリクエスト数の平均値ですか? 後者のオプションでは、数秒しか続かない、はるかに多くの瞬間的なリクエストを非表示にすることができます。 偶数で XNUMX 秒あたり XNUMX のリクエストを処理し、残りの時間は XNUMX であるシステムを考えてみましょう。 XNUMX 秒あたり XNUMX リクエストの平均値という定数と XNUMX 倍の瞬間的な負荷は同じではありません。 同様に、クエリ レイテンシの平均化は魅力的に見えるかもしれませんが、重要な詳細が隠されています。つまり、ほとんどのクエリは高速になる可能性がありますが、遅いクエリも多数存在する可能性があります。

ほとんどの指標は、平均ではなく分布として見る方が適切です。 たとえば、SLI レイテンシーの場合、一部のリクエストはすぐに処理されますが、一部のリクエストは常に時間がかかり、場合によってはさらに長くかかります。 単純な平均によって、このような長い遅延を隠すことができます。 図は例を示しています。一般的なリクエストの処理には約 50 ミリ秒かかりますが、リクエストの 5% は 20 倍遅くなります。 平均レイテンシーのみに基づいた監視とアラートでは、XNUMX 日を通しての動作の変化は示されませんが、実際には一部のリクエストの処理時間に顕著な変化があります (最上部の行)。

50、85、95、99 パーセンタイルのシステム遅延。 Y 軸は対数形式です。

インジケーターにパーセンタイルを使用すると、分布の形状とその特性を確認できます。99 や 99,9 などの高いパーセンタイル レベルは最悪の値を示し、50 パーセンタイル (中央値とも呼ばれる) は最も頻繁に発生する状態を示します。メトリック。 応答時間のばらつきが大きくなるほど、長時間実行されるリクエストがユーザー エクスペリエンスに影響を与えます。 この効果は、高負荷時やキューが存在する場合にさらに高まります。 ユーザー エクスペリエンスに関する調査によると、人々は一般に、応答時間の分散が高く、低速のシステムを好むことがわかっています。そのため、一部の SRE チームは、99,9 パーセンタイルでのメトリクスの動作が良好であれば、ほとんどのユーザーは問題を経験しないだろうという根拠に基づいて、高いパーセンタイル スコアのみに焦点を当てています。 。

統計誤差に関する注意事項

一般に、一連の値の平均 (算術平均) ではなく、パーセンタイルを使用することを好みます。 これにより、平均とは大きく異なる (そしてより興味深い) 特性を持つことが多い、より分散した値を考慮することができます。 コンピューティング システムの人為的な性質により、メトリック値は偏ることがよくあります。たとえば、0 ミリ秒未満で応答を受信できるリクエストはなく、1000 ミリ秒のタイムアウトは、それより大きな値を持つ成功した応答がないことを意味します。タイムアウトよりも。 結果として、平均値と中央値が同じ、または互いに近いということは受け入れられません。

事前のテストを行わず、また特定の標準的な仮定や近似が当てはまらない限り、データが正規分布していると結論づけないように注意しています。 分布が予想どおりでない場合は、問題を修正する自動化プロセス (たとえば、異常値が検出された場合、リクエスト処理の待ち時間が長くなった状態でサーバーを再起動します) の実行頻度が多すぎるか、または十分でない可能性があります (どちらも適切ではありません)。とても良い）。

指標の標準化

SLI の一般的な特性を標準化して、毎回推測する必要がないようにすることをお勧めします。 標準パターンを満たす機能は、次のように個々の SLI の仕様から除外される場合があります。

• 集計間隔: 「1 分間の平均」
• 集約エリア: 「クラスター内のすべてのタスク」
• 測定の頻度: 「10 秒ごと」
• 含まれるリクエスト: 「ブラック ボックス監視ジョブからの HTTP GET」
• データの取得方法: 「サーバー上で測定されたモニタリングのおかげで」
• データアクセス遅延:「最後のバイトまでの時間」

労力を節約するには、共通メトリックごとに再利用可能な SLI テンプレートのセットを作成します。 また、特定の SLI の意味を誰もが理解しやすくなります。

実践での目標

まずは、測定できるものではなく、ユーザーが何を気にしているかを考える (または見つけ出す!) ことから始めましょう。 多くの場合、ユーザーが関心を持っていることは測定するのが困難または不可能であるため、最終的にはユーザーのニーズに近づくことになります。 ただし、測定しやすいものから始めると、SLO の有用性が低くなります。 その結果、最初に望ましい目標を特定してから特定の指標を使用する方が、指標を選択してから目標を達成するよりもうまく機能することが判明することがあります。

目標を定義する

最大限に明確にするために、SLO の測定方法と、SLO が有効となる条件を定義する必要があります。 たとえば、次のように言えます (XNUMX 行目は最初の行と同じですが、SLI のデフォルトを使用します)。

• Get RPC 呼び出しの 99% (1 分間の平均) は 100 ミリ秒未満で完了します (すべてのバックエンド サーバーで測定)。
• Get RPC 呼び出しの 99% は 100 ミリ秒以内に完了します。

パフォーマンス曲線の形状が重要な場合は、複数の SLO を指定できます。

• Get RPC 呼び出しの 90% が 1 ミリ秒未満で完了しました。
• Get RPC 呼び出しの 99% が 10 ミリ秒未満で完了しました。
• Get RPC 呼び出しの 99.9% が 100 ミリ秒未満で完了しました。

ユーザーが異種ワークロード、つまり一括処理 (スループットが重要な場合) と対話型処理 (レイテンシが重要な場合) を生成する場合、負荷クラスごとに個別の目標を定義する価値がある場合があります。

• 顧客リクエストの 95% はスループットを必要とします。 実行される RPC 呼び出しの数を 1 秒未満に設定します。
• 99% のクライアントは遅延を気にしています。 トラフィックが 1 KB 未満、実行時間が 10 ミリ秒未満の RPC 呼び出しの数を設定します。

SLO が 100% 満たされると主張するのは非現実的であり、望ましくありません。これにより、新しい機能の導入と展開のペースが低下し、高価なソリューションが必要になる可能性があります。 代わりに、エラー バジェット (許容されるシステム ダウンタイムの割合) を許可し、この値を毎日または毎週監視することをお勧めします。 上級管理職は、月次または四半期ごとの評価を必要とする場合があります。 (エラー バジェットは、別の SLO と比較するための単なる SLO です。)

SLO 違反のパーセンテージは、エラー バジェットと比較できます (第 3 章およびセクションを参照) 「エラーバジェットの動機」)、その差分値は、新しいリリースをいつデプロイするかを決定するプロセスへの入力として使用されます。

目標値の選択

計画値 (SLO) の選択は、選択された SLI、SLO (および場合によっては SLA) に反映される必要がある製品とビジネスの利益のため、純粋に技術的な作業ではありません。 同様に、人員配置、市場投入までの時間、機器の可用性、および資金調達に関する問題に関して情報交換が必要になる場合があります。 SRE はこの会話に参加し、さまざまなオプションのリスクと実行可能性を理解するのに役立つ必要があります。 より生産的な議論を確実にするために役立つかもしれないいくつかの質問を考えてみました。

現在のパフォーマンスに基づいて目標を選択しないでください。
システムの強みと限界を理解することは重要ですが、根拠なくメトリクスを適応させると、システムの維持が妨げられる可能性があります。目標を達成するには、大幅な再設計なしには達成できない英雄的な努力が必要になります。

複雑にしないでおく
複雑な SLI 計算により、システム パフォーマンスの変化が隠蔽され、問題の原因を見つけることが困難になる可能性があります。

絶対値を避ける
待ち時間を増加させることなく、無限に増大する負荷を処理できるシステムを実現したいという誘惑に駆られますが、この要件は非現実的です。 このような理想に近づくシステムは、設計と構築に多くの時間がかかり、運用コストが高くつき、それ以下のもので十分というユーザーの期待に応えられすぎます。

可能な限り少ない SLO を使用する
システム属性を適切にカバーできるように、十分な数の SLO を選択してください。 選択した SLO を保護する: 特定の SLO を指定しても優先順位に関する議論に決して勝てない場合は、おそらくその SLO を検討する価値はありません。 ただし、すべてのシステム属性が SLO に従うわけではありません。SLO を使用してユーザーの満足度を計算するのは困難です。

完璧を追い求めないでください
負荷時のシステムの動作について詳しく学ぶにつれて、SLO の定義と目標をいつでも調整できます。 達成不可能だとわかったら緩和する必要がある厳しすぎる目標を選択するよりも、流動的な目標から始めて、時間をかけて改善していく方が良いでしょう。

SLO はユーザーへの懸念を反映しているため、SRE や製品開発者にとって作業の優先順位を決定する際の主要な推進要因となる可能性があり、またそうあるべきです。 優れた SLO は、開発チームにとって有用な実施ツールです。 しかし、SLO の設計が不十分だと、チームが過度に積極的な SLO を達成するために英雄的な努力をした場合には無駄な作業が発生する可能性があり、SLO が低すぎる場合には粗悪な製品が完成する可能性があります。 SLO は強力な手段なので、賢明に使用してください。

測定値を管理する

SLI と SLO は、システムの管理に使用される重要な要素です。

• SLI システムを監視および測定します。
• SLI と SLO を比較し、アクションが必要かどうかを判断します。
• 行動が必要な場合は、目標を達成するために何が必要かを考えます。
• このアクションを完了してください。

たとえば、ステップ 2 でリクエストがタイムアウトになり、何もしなければ数時間以内に SLO を破ってしまうことが示されている場合、ステップ 3 では、サーバーが CPU バウンドであり、サーバーを追加すると負荷が分散されるという仮説をテストすることが含まれる可能性があります。 SLO がなければ、行動を起こすべきかどうか (あるいはいつ行動すべきか) がわかりません。

SLO を設定する - ユーザーの期待が設定されます
SLO を公開すると、システム動作に対するユーザーの期待が設定されます。 ユーザー (および潜在的なユーザー) は、多くの場合、サービスが使用に適しているかどうかを理解するために、サービスに何を期待できるかを知りたいと考えています。 たとえば、写真共有 Web サイトを使用したい人は、たとえ同じサービスがアーカイブ レコード管理システムには理想的であっても、可用性がわずかに低下する代わりに寿命と低コストが約束されているサービスの使用を避けたいと思うかもしれません。

ユーザーに現実的な期待を設定するには、次の戦術のいずれかまたは両方を使用します。

• 安全マージンを確保してください。 ユーザーに公開されているものよりも厳格な内部 SLO を使用します。 これにより、問題が外部に明らかになる前に対応する機会が得られます。 また、SLO バッファを使用すると、システムのパフォーマンスに影響を与えるリリースをインストールするときに安全マージンを確保できるため、ダウンタイムでユーザーをイライラさせることなく、システムの保守が容易になります。
• ユーザーの期待を超えないでください。 ユーザーはあなたが言うことではなく、あなたが提供するものに基づいています。 サービスの実際のパフォーマンスが、記載されている SLO よりもはるかに優れている場合、ユーザーは現在のパフォーマンスに依存することになります。 システムを意図的にシャットダウンするか、軽負荷時のパフォーマンスを制限することで、過度の依存を回避できます。

システムがどの程度期待に応えているかを理解することは、システムを高速化し、アクセスしやすく復元力を高めることに投資するかどうかを決定するのに役立ちます。 あるいは、サービスのパフォーマンスが良すぎる場合は、スタッフの時間を技術的負債の返済、新機能の追加、新製品の導入など、他の優先事項に費やす必要があります。

実際の協定

SLA を作成するには、ビジネス チームと法務チームが、SLA に違反した場合の結果と罰則を定義する必要があります。 SRE の役割は、SLA に含まれる SLO を満たす際に起こり得る課題を理解できるように支援することです。 SLO を作成するための推奨事項のほとんどは、SLA にも適用されます。 ユーザーに約束する内容は控えめにすることが賢明です。約束が多ければ多いほど、不合理または遵守が難しいと思われる SLA を変更または削除することが困難になるためです。

訳文を最後まで読んでいただきありがとうございます。 モニタリングに関する私の電報チャンネルを購読してください モニターリム_it и Medium のブログ.

出所： habr.com