ヌーラボ
3ヶ月ぶりの開催だったので、3章を対象とした
- ある一線を越えると、信頼性を向上させることはサービス（及びそのユーザー）にとって、むしろマイナスになる
- 過度の信頼性はコストに跳ね返る
- 99% の信頼性を持つスマートフォンを使っているユーザーには、サービスの信頼性が99.99% の場合と 99.999% の場合との違いはわからない
- 単純に稼働時間を最大化するよりも、可用性におけるリスクと、イノベーションの速度及びサービス運用の効率性というゴールとのバランスを取っている
コストは2つの特徴がある
- 冗長なマシン / コンピュートリソースのコスト
- 定期メンテナンスや予定外のメンテナンスの際にシステムをオフラインにする
- 機会のコスト
- リファクタリングやシステムアーキテクチャ見直しなど、エンドユーザー使う機能に時間をさかないこと
ゴールはサービスの取るリスクと、そのビジネスで許容できるリスクの歩調をあわせることである。
サービスを十分信頼できるようにする努力はするが、必要以上に信頼性を高めようとはしない
一定値以上の信頼性をあげようとするとチャンスを失う
- システムへの機能の追加
- 技術的な負債の払拭
- 運用コスト削減
サービスの障害が発生した場合に影響を及ぼすもの
- ユーザーの不満、損害、信頼の喪失
- 直接的または間接的な売上の損失
- ブランドや計画へのインパクト
- 望ましくない報道
これらの問題をわかりやすくするために、計画外の停止時間に注目する
可用性 = 稼働時間 ÷ ( 稼働時間 + 停止時間 )
Google では時間を基にしたメトリクスは使わない、なぜなら分散システムなので、世界中のどこかは稼働中になっているため
そのためリクエスト成功率という観点から可用性を定義する
可用性 = 成功したリクエスト数 ÷ 総リクエスト数
- 200系と500系のリクエストで可用性をみている
- エラー（アプリケーションログのエラー）数で可用性をみている
このメトリクス（可用性 = 成功したリクエスト数 ÷ 総リクエスト数）の考え方を応用し、パッチ、パイプライン、ストレージ、トランザクションシステム等、ある単位の作業の成否を示すことができる
例えばデータ取り込み用のバッチでの、成功した処理のレコード数と失敗した処理のレコード数という観点でリクエスト成功率をみる
Google ではサービスのリスク許容度は明確に定義されていない
SREがプロダクトマネージャーと共同で作業を行い一連のビジネスゴールをエンジニアリング可能な、明確な目標に変換しなければならない
サービスのパフォーマンスと信頼性に直接的なインパクトを持つが、この共同作業は簡単なことではない
サービスによっても違う、例えばコンシュマーサービスとインフラストラクチャサービスの違い
Google ではプロダクト毎にプロダクトマネージャーがいて、信頼性について議論する。専任のプロダクトマネージャーがいない場合にはシステムを構築したエンジニアが役割を果たす
サービスリスクの許容度の評価
- 必要な可用性のレベル
- 障害の種類の違いによってサービスへの影響に差はないか
- リスク曲線上にサービスを位置づける上で、サービスコストはどのようにりようできるか
- 考慮すべき重要なサービスメトリクスとして、他にはどのようなものがあるか
サービスが提供する機能と、市場におけるそのサービスの位置づけによって可用性のターゲットレベルがきまる。
- ユーザーが期待するサービスのレベル
- サービスが直接的に収入につながっているか
- サービスは有料か、無料か
- 市場に競合がいる場合に、その競合が提供しているサービスのレベル
- サービスはコンシューマ向けか。それとも企業向けか
ビジネスのインパクトによってユーザーによって損なわれる信頼が違うために障害の種類によって対応を分ける
画像が表示されない問題と違うユーザーの情報がみれる状態は障害の種類としては違うよねという話
Adsの例をあげている、リクエストの成否が直接的な収入の増減になるためわかりやすい
サービスのリスク許容度を検討する際に、可用性以外のメトリクスも合わせて考えると有益である。
ここの定義は各プロダクトによって違ってくる
インフラストラクチャとコンシューマ製品だと求められる要求は違う
インフラストラクチャのコンポーネントは複数のクライアントを持っているため要求が多様になる
Bigtable を例に、ユーザーからの使われ方は違うので、すべてのインフラストラクチャサービスの信頼性をエンジニアリングによって極限まで高めることはコストがかかるため、ユーザーのリクエストキューの状態がどういったものか調べてみると良い
ユーザー間での成功と失敗は対象的なもので、低レイテンシーを望む場合とスループットを望む場合で違う
- 低レイテンシーのユーザーはリクエストキューが空になり、処理待ちのリクエストがきたらすぐに処理すること
- オフライン分析を気にかけているユーザーは、システムのスループットに関心があり、リクエストキューが空にならないことを望む、なぜならリクエストをまってアイドル状態になってほしくない
インフラストラクチャに関する重要な方針は、明示的に示されたサービスレベルの下でサービスを提供することによって、システム構築の際に、クライアント側がリスクとコストの適切なトレードオフを選択できるようにすることです。サービスレベルが明示されていれば、そのインフラストラクチャのプロバイダは、指定されたレベルでクライアントにサービスを提供祭のコストを変分を、事実上外部化できる
コストを公開すれば、クライアント側は、自分たちの要求を満たす範囲で最も低コストのサービスレベルを選択するようになる
インフラストラクチャのシステムのフロントエンドはバックエンドのリクエストの失敗がダイレクトに信頼性の低下につながるため高い信頼性を必要とする
プロダクト開発のパフォーマンスは、主にプロダクトの開発速度で評価される
SREのパフォーマンスはサービスの信頼性を基に評価される
お互いがベクトルが違うため緊張が生まれる
そして、エンジニアリングの実施に費やすべき労力のレベルについての意見の相違に反映される
-
ソフトウェア障害の許容度
-
テスト
テストが少なければ、問題の検出されず、信頼性を損なう。逆にテストをやりすぎると市場を失うことになる
- プッシュの頻度（リリースの頻度）
リスク低減と、他の作業の時間とのバランスをどう取るべきか
- カナリアテストの期間と規模
カナリアテストの期間と規模をどのように定めるべきか
リスクと労力の線引が必要な部分については既存チームの中で、非公式にバランスは取っている
バランスが最適なものであるかは自明ではなく、関わりのあるエンジニアの交渉スキルだけで決定されている
そういった判断は、政治、恐怖、あるいは願望によってきめられているかもしません
Google SRE の非公式のモットーは「希望は戦略にあらず」である。
私達のゴールは、交渉を生産的な方向へ導くためにに利用できる客観的なメトリクスを定義し、両者に合意してもらう必要がある。
判断はデータに基づいて行われるとなおよい
こういった判断を客観的なデータに基づいて下せるようにするために、２つのチームは協力しあい、サービスレベルの目標すなわり、SLO（サービスレベル目標）に基づく四半期のエラーバジェットを規定する
エラーバジェットが提供するのは、１つの四半期内でサービスの信頼性がどの程度損なわれても許容できるかを示す、明確で客観的なメトリクスです
このメトリクスは、許容されるリスクをSREとプロダクト開発者とで判断する際の交渉から政治を取り除きます。
具体的には。。
- プロダクトマネージャーがSLOを規定する。これは、四半期内に期待されるサービスの稼働時間を設定する
- 実際の稼働時間は、中立的な第三者であるモニタリングシステムによって測定される
- この２つの差異が、その四半期ないの「損失可能な信頼性」という「予算」の残分となる
- 計測された稼働時間がSLOを超えている、言い換えればエラーバジェットが残っているなら新しいリリースをリリースできる
エラーバジェットの主なメリットは、プロダクト開発者とSREに共通のインセンティブを提供し、両者がイノベーションと信頼性の適切なバランスを見出すことに注力できるようになることです。
システムのSLOを満たしている限り、リリースは継続できる。SLOを満たさないことを頻繁に生じ、エラーバジェットを使い切りそうであればリリースは一時的に停止、システムの弾力性を増したり、パフォーマンス改善したりするために、システムのテストや開発へのリソース投資を追加する
エラーバジェットが残っていれば、開発者はリスクを大きく取ることができる。エラーバジェットがなければリスクを取りたくないのでリリースに慎重になる。プロダクト開発者はエラーバジェットを知っているので自分たちでリスクコントロールできるようになる。ただし、SLOを超えた場合のローンチを実際に止める権限をSREチームがもっている
ネットワークやデータベースの障害もSLOに含める
稼働時間に対する責任は全員が共有するものでありエラーバジェットの削減はチーム全員が支持する
新しい機能のローンチに関してチームが問題を抱えているなら、SLOを緩める（エラーバジェットを増やす）ことによってイノベーションを加速させる選択をとることはできる。
- サービスの信頼性管理の大部分はリスク管理に関係することであり、リスク管理には多くのコストがかかることがあります。
- 信頼性のターゲットとして100%が適切であることはほぼありえません。これは達成可能であるだけではなく、通常はサービスのユーザーが求めるレベルでも認識できるレベルでもありません。サービスの性質とビジネス上取るべきリスクを合致させるべきである。
- エラーバジェットは、SREとプロダクト開発者との間でインセンティブを一致させると共に、共同所有ということを強調します。エラーバジェットによって、リリースの頻度を判断することや、サービス障害に関するステークホルダーとの議論を効果的に落ち着かせることができ、プロダクトのリスクについて複数のチームがもめることなく同じ結果に到達できるようになります。