Zenn
🐕

【2章】データベースリライアビリティエンジニアリングの読書メモ

2021/06/16に公開
O'Reilly
DBRE
tech

O'Reilly Japan - データベースリライアビリティエンジニアリング の 2 章の読書メモです。
SlideServe はこちら。

2. サービスレベルマネジメント

サービスがあるべき運用レベルを見定めること。
これがサービスの設計、ビルド、デプロイにあたって最初にすべきことです。

2.1. SLO の必要性

サービスを設計し構成するにあたり、一通りの仕様を定める必要がある。これがSLAである。
一方、SLO は設計及び運用に関して遵守すべき事柄をまとめたもの。

ただし、サービスレベルマネジメントは理解が難しい。

例:

  • SLO として API がリクエストを正常に処理したパーセンテージを記載する場合
    • その情報取得元をどうするか。API 自身？ 全面のロードパランサー？ サーバー？ DB？
    • 正常な場合はステータス 200 を返すが、異常な場合は何を返すか。
  • ユーザーの要望に合わせてサービスの重要度を設定しているか
    • ユーザーが API サービスについては 99.95%、バッチサービスについては 97%の可用性を許容している場合、両方を折衷した 98%の可用性を SLO とするのは正しくない
  • ユーザーはどの程度コントロール可能か
    • API サービスを 98%の可用性で運用しているが、失敗時には自動でリトライされるため、実質的には 99.99%が保証可能
    • この場合、SLO の数字として正確なのはどちらか
  • ユーザーの行う無効・不正なリクエストは、どう取り扱うべきか
  • その数字はユーザーにとって意味のある数字か
    • 99.999%の可用性で機能するページがある
    • ただし、そのうち 15%のケースでレイテンシが 5 秒を超える
    • この場合、この数字は SLO として正しいか。ユーザーにとって意味のある数字か
  • 98%のユーザーには 99.999%の可用性、2%のユーザーには 30%~70%の可用性しか提供できない場合、可用性はどのように計算すべきか
  • データベース関連
    • シャードやバックエンドがダウンした場合
    • ソフトのアップグレードの途中で新しいバージョンのバグのために 2%のデータ消失が発生した場合
    • 1 日分のデータが消失したが、影響範囲が特定のテーブルだけの場合
    • ユーザーがその損失に気づかない場合
    • 実際に消失したわけではなく、データが見つからない場合でもデータ消失として扱うべきか
  • こちらに責任がない場合
    • 特定のユーザーのお粗末な wifi 環境やネット事情、中継ルータの問題で可用性が 95%となった場合、責任の所在は？
  • エラー発生率は全体の時間で平均すべきか、それとも単位あたりのエラー発生率の閾値を決めておき、その単位で閾値を超えたエラー発生率を定義すべきか

ユーザーの視点から SLO を捉えた場合、もっとも重要なことは、その指標がユーザー体験、ひいてはユーザー満足度を反映しているかどうかです。1 人のユーザーに対して、もしくはある目的に照らして、ひとかたまりのデータをすくいあげたときに、サービスが指標となる数字を持っているかどうか。これが極めて重要なのです。

2.2. SLO の指標 (2.3. サービス目標の定義)

SLO はサービスが持つ特性によって変わる。
ただし、SLO の中心として考えるべきはあくまでもユーザー。

2.2.1. レイテンシ

別名:レスポンスタイム、RTT(ラウンドトリップタイム)
1 リクエストに対するレスポンスにかかる時間を表す。
エンドツーエンドで測定するのがもっとも望ましい。

レイテンシは、ある数値以上ある数値以下で定義される(ex. 100 ミリ秒以下)。
以下に示すように、レイテンシが 100 ミリ秒を超えると、ビジネスに多くの影響を及ぼす。

また、ネットワークの通信速度は 0 にはならない。
そして、レイテンシの実測値の中には極端に低いものや高いものがあるため、これらの外れ値を取り除く必要がある。そのため SLO は、

リクエストの 99%において、レイテンシは 25 ミリ秒から 100 ミリ秒の間でなければならない

となる。

また、追加でレイテンシの範囲も定める必要がある。

  • ex
    • API のレスポンス取得までか
    • ページの描画までか

ただし、ページの描画までを含める場合は、レスポンス取得とページの描画とで数値を分けたほうが良い。2 つのレスポンスの間に他の処理が挟まることが多いため。

2.2.1. 可用性

システムが利用可能である状態を時間枠に対してパーセンテージで示したもの。
利用可能である状態を、どの時間に対して適用するかを定めてはいけない。その時間枠のすべてのリクエストが測定の対象。

指標として、以下がある。

  • 平均故障間隔: (MTBF: Mean Time Between Failures)
    • ダウンタイムがどれくらいの長さで発生するか示す
  • 平均修復時間: (MTTR: Mean Time To Recover)
    • ダウンタイムからどれくらい早く回復するかを示す
回復力のあるシステム VS 高い可用性のシステム
  • 回復力のあるシステム
    • 障害を検知する優れた監視システムを持つ
    • 障害児の自己修復機能を備えている
    • 高い冗長性の確保
    • 洗練されたドキュメント、事前トレーニングにより、障害対応は特別な業務ではなく通常業務の一部となっている

以上から、SLO の可用性を評価する際は、以下を自問自答すると良い。

  • 障害発生時に回避策があるか
  • 障害の影響範囲が一部のユーザーのみの場合、サービスの全面停止よりも別の対応策が可能か
  • ダウンタイムが長引くにつれて、1 人のユーザーのサービス体験はどう変わるか
    • リクエストが 1 回失敗した場合、30 秒～ 1 時間以上のダウンタイムが発生した場合

上記を踏まえると、SLO の可用性について、以下を再検討しなければならない。

  • 測定の時間間隔
  • ダウンタイム時に許容される最長時間
  • その事象によって影響があるユーザー数のパーセンテージ

また、サービスメンテナンスのために、しっかりと管理・計画されたダウンタイムを設ける必要がある。

  • Google では、可用性を過度に高めないようにするため、定期的にダウンタイムを実施している。

まとめると、SLO には以下の表記が並ぶ。

  • 数週間の時間軸で捉えた場合、それぞれの 1 週間あたりの可用性を研鑽して、その平均が 99.9%であること
  • 障害が発生した場合、10.08 分以内に復旧すること
  • ダウンタイムとは、全体のユーザー数の 5%以上に影響を与える事象とする
  • 1 年に 1 回は 4 時間のダウンタイムを許容する。ただし、以下を満たす
    • 2 週間前にユーザーへ通知
    • 1 度にユーザー数の 10%以上に影響を与えない

2.2.3. スループット

一定時間において正常に処理されたリクエストの割合のこと。
サービスが対応可能な最大値を設定する。

参考: SLO の導入  |  Cloud アーキテクチャ センター  |  Google Cloud

2.2.4. 耐久性

ストレージに対して一定の成功率で書き込みができるかどうか。

例:
Amazon S3 の耐久性

2.2.5. 費用対効果

費用は、1 ページビューや 1 購読数、購入 1 件といった行動に対して効果として測定されるべき。

サービスを運用するにあたり、次のアクションが求められる。

  • 新しいサービスの場合
    • 新しいサービスを開始するにあたり、運用の指針となる SLO(以下 SLA)を定義する
    • 新しいサービスの SLA として参照されるメトリクスに対して、目標及び実測値を適切に評価できるような監視システムを設定する
  • 既存サービスの場合
    • サービスの過去と現在の状態を踏まえ、今までに達成した SLA と違反した SLA に対して、定期的なレビューを行う
  • SLO 遵守率
    • SLO で定義した指標について、達成できているものとできていないものを確認する
  • サービスに付随する問題
    • サービスレベルに影響をあたる不安要素を整理し、特定の不具合に対する回避策や修正度合いを検討する

費用対効果の指標を定義するにあたって重要なのは、かかったコストを何に対しての効果と捉えるべきか。

  • ex.
    • コンテンツプロバイダ: ページビュー
    • オンラインサービス: ユーザー数
    • EC サイト: トランザクション数

SLO を定義する際に注意すること

2.4. SLO に基づいた監視とレポート

SLO の各指標を監視する上で重要なのは、SLO を遵守することではなく、達成を妨げる潜在的なリスクを洗い出し、その対策をすること。
SLO 違反のアラートを受けてから行動するのではなく、アラートを受ける前から、不測の事態に対して SLO を遵守すべく適切な対応を取る。
そのために、以下の 3 つは監視する値を決定する時点で考えておく。

  • 収集と分析の自動化
  • 問題発生時のアラートの対応とその後のレポート
  • 分析結果の視覚化

2.4.1. 可用性の監視

可用性の SLO が上記の場合、

  • RUM(Real User Monitoring)に着目する
    • ユーザーからのリクエストに対するエラー発生率
    • 累積したデータ近い将来のエラー発生率を予測し、週あたりのダウンタイムを超過しないか判断できるようにする
    • ただし、サービスの状態は刻々と変化するので、なかなか難しい
    • 累積されたデータから将来の数値を予測する方法は多くあるので、それらを使う
    • 潜在的な問題に対し、データドリブンな観点から目を光らせ、深刻な障害を未然に防ぐ
  • 定点モニタリング
    • 故意に作成したデータセットを用いたテストを走らせることも、異常検知に役立つ
    • カバレッジ計測にその効果を発揮する
      • チューニングされたクエリとカバレッジによって、異なる時間、地域の測定を行う

2.4.2. レイテンシの監視

レイテンシの SLO が上記の場合、HTTP のリクエストログを、時系列のデータとして保存する
上位 1%のデータを分析から除外した上で、各 1 秒毎の時間枠において、データの 99%が 100 ミリ秒を超えていた場合、SLO 違反としてダウンタイムを計上すべき。

2.4.3. スループットの監視

スループットは、測定、収集、そして可用性とレイテンシの SLO と絡めたレビューが必要。
秒単位でトランザクション数を記録しておき、スループットがトランザクション数を超えているか確認する。
超えられない場合、低規定に実施する負荷テストにおいて、度のタイミングで出力が落ちたのかを把握すべき。

2.4.4. 費用対効果の監視

クラウド環境でサービスを運用している場合、ストレージ、CPU、メモリ等々でどれだけコストが発生しているのかを読み解く必要がある。
サービスを運営する人件費も考慮する。人件費についても定期的に見直しが必要。
これらの事務作業は自動化は難しいが、サービスを運用するために発生するコストを把握する上で、とても価値がある。

サービスが生み出した価値と、それにかかる費用をエンジニアが理解することで、技術的な観点から無駄を省き、燃費の良いアーキテクチャを設計する動機が生まれ、結果的に効率の良いコスト削減ができるようになるでしょう。

2.5. まとめ

SLO を定義管理することは、インフラストラクチャを設計し運用する上での要石です。
サービス対するすべての施策は、SLO を遵守するための手段に過ぎません。
SLO が日々の活動全ての基礎なのです。

参考

SLA, SLO, SLI の違い

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

Ref. SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud Blog

GitHubで編集を提案

Discussion