SRE study group 3rd slide

Slide 1

Slide 1 text

Site Reliability Engineering  3rd  DevOps unit study group  Makoto Korenaga   

Slide 2

Slide 2 text

アジェンダ  1. リスクの受容  2. サービスレベル目標  3. トイルの撲滅  4. 分散システムのモニタリング     

Slide 3

Slide 3 text

リスクの受容 

Slide 4

Slide 4 text

リスクの管理  信頼性のないシステムはユーザーの信頼を失う  →システム障害の可能性を減らす必要がある  信頼性とコストは比例関係ではない 

Slide 5

Slide 5 text

リスクの管理  コストの特徴  ● 冗長なマシン/コンピュートリソースのコスト  設備の冗長化へのコスト   ● 機会のコスト  新機能開発でなく、リスクを減らすための対策にエンジニアリングリソースを割り当てることによるコスト  コスト/メリット分析を行い、サービス/ビジネスにとって適切な障害許容レベルを定める   →必要以上に信頼を高めようとしない  

Slide 6

Slide 6 text

サービスリスクの計測  最適化したいシステムの特徴を表す客観的なメトリクスを見つける  例）計画外の停止時間   　可用性=稼働時間/(稼働時間+停止時間)   　年間の停止時間を52分33秒以内に収めれば99.99%を満たせる   例）リクエスト成功率   　可用性=成功したリクエスト数/総リクエスト数   　1日250万リクエスト処理するシステムの場合エラーが250回以内なら99.99%を満たせる  

Slide 7

Slide 7 text

サービスリスクのリスク許容度  SREがプロダクトマネージャーと共同で作業を行い、一連のビジネスゴールをエンジニアリング可能な、明確な目標として設定する  コンシューマサービスはプロダクト責任者が明確だが、インフラストラクチャサービスにはプロダクト責任者が不在であることが普通なので、リスク許容度の明確化のアプローチも異なる 

Slide 8

Slide 8 text

サービスリスクのリスク許容度  コンシューマサービスの場合  ● 必要な可用性のレベル  ● 障害の種類の違いによるサービス影響の差  ● サービスコスト  ● 考慮すべき重要なサービスメトリクス 

Slide 9

Slide 9 text

サービスリスクのリスク許容度  必要な可用性のレベル  ● ユーザーが期待するサービスレベル  ● サービスが直接的に収入につながっているか  ● サービスは有料か、無料か  ● 市場に競合がある場合、その競合が提供しているサービスレベル  ● サービスはコンシューマ向けか、企業向けか 

Slide 10

Slide 10 text

サービスリスクのリスク許容度  障害の種類  ● 完全なサービス障害なのか、部分的なサービス障害なのか  ● 頻度はどれくらいか  ユーザーの使用時間帯が明確に分かっているサービスでは、使用時間帯を外して定期メンテナンスを入れることが可能になる 

Slide 11

Slide 11 text

サービスリスクのリスク許容度  コスト  ● 可用性を1桁改善するようにシステム構築と運用をした場合、収入がどのように増加するか  ● この追加の収入は信頼性をそのレベルに高める為のコストに見合うか  例）可用性の改善案: 99.9% → 99.99%(0.09%改善)   　　サービスの収益: 10,000 万円/月   　　改善された可用性の価値: 10,000(万円/月)x0.0009=9(万円/月)  

Slide 12

Slide 12 text

サービスリスクのリスク許容度  サービスメトリクス  ● レイテンシー  レイテンシーの要求が緩い場合は、サービスの地理的な配置を集約しコストを削減することも可能 

Slide 13

Slide 13 text

サービスリスクのリスク許容度  インフラストラクチャサービスの場合  可用性の要求がサービス、使用するユーザーによって異なる  例）Bigtableの場合  ユーザーサービスでリクエストで使用　低レイテンシーと高可用性   分析チームで使用　高スループット   Bigtableの場合、低レイテンシーのクラスタと高スループットのクラスタの2種類を構築できる  

Slide 14

Slide 14 text

エラーバジェットの活用  プロダクト開発が主にプロダクト開発速度で評価される一方で、SREはサービスの信頼性を基に評価される  ● ソフトウェア障害の許容度  ● テスト  ● プッシュの頻度  ● カナリアテストの期間と規模 

Slide 15

Slide 15 text

エラーバジェットの活用  エラーバジェットの形成  エラーバジェットとはエラーに対する予算のこと SLO(Service Level Objective)に基づく四半期のエラーバジェットを規定   ● PdMがSLOを規定 = 四半期内に期待されるサービスの稼働時間設定   ● 実稼働時間は、中立な第三者であるモニタリングシステムによって計測   ● 上記2つの差異が、その四半期内の損失可能な信頼性という予算残分となる   ● 計測された稼働時間がSLOを超えている(エラーバジェットが残っている)なら新しいリリースをプッシュできる 

Slide 16

Slide 16 text

エラーバジェットの活用  メリット  ● プロダクト開発者とSREに共通のインセンティブを提供 ● 両者がイノベーションと信頼性の適切なバランスを見出すことに注力できるエラーバジェットを使い切りそうな場合、リリースは一時的に停止させ、システムの弾力性を増したり、パフォーマンス改善にリソース追加する →プロダクト開発者はローンチできなくなるリスクを減らすために、テストを追加したりしてリリースの安定性を高めたりするようになる

Slide 17

Slide 17 text

サービスレベル目標 

Slide 18

Slide 18 text

サービスレベルに関する用語  ● サービスレベルアグリーメント(Service Level Agreements,SLA)  ユーザーとの間で結ぶ明示的あるいは暗黙の契約   SLOを満たせなかった場合は払い戻しやペナルティなど   ● サービスレベル目標(Service Level Objectives,SLO)  SLI ≤ ターゲットもしくは下限 ≤ SLI ≤ 上限  ● サービスレベル指標(Service Level Indicators,SLI)  リクエストのレイテンシー、エラー率、システムスループット、可用性  

Slide 19

Slide 19 text

指標の実際  ● サービス提供者とユーザーの関心事を指標とする  ユーザーとやり取りするサーバーシステムの場合、可用性、レイテンシー、スループット   ● 収集  Prometheusのようなモニタリングシステムやログ分析、クライアント側で収集の仕組みが必要な場合も  ● 集計  平均よりも分布で考える。パーセンタイルを指標として 50%(中央値)近辺を使えば典型的なケースに重点を置ける。   

Slide 20

Slide 20 text

指標の実際  ● 標準化  例）  ○ 集計のインターバル: 「集計時間は1分とする」   ○ 集計の対象領域: 「クラスタ内のすべてのタスク」   ○ 計測の頻度: 「10秒ごと」   ○ 対象となるリクエスト: 「ブラックボックスモニタリングジョブからのHTTP GET」   ○ データの取得方法: 「モニタリングシステムを通じて、サーバーで計測」   ○ データアクセスのレイテンシー: 「最後のバイトまでの時間」  

Slide 21

Slide 21 text

目標の実際  ● 定義  計測方法と計測値が適性である条件を指定するべき   例）GETリクエスト呼び出しの 99%が100ミリ秒以下で完了すること   ● ターゲットの選択  ○ 現在のパフォーマンスに基づいてターゲットを選択してはならない   ○ シンプルさを保つ  ○ 「絶対」は避ける  ○ SLOは最小限にとどめる   ○ 最初から完璧でなくてもよい  

Slide 22

Slide 22 text

目標の実際  ● 計測値のコントロール  ○ システムのSLIモニタリングと計測を行う   ○ SLOに対してSLIを比較し、アクションが必要か判断する   ○ アクションが必要な場合、改善点を明らかにし改善行動を取る   ● SLOによる期待の設定  ○ 安全マージンを確保する   公開しているSLOより内部的なSLOを厳しくしておく   ○ 過剰達成を避ける  高可用性に依存した設計となり過度に依存されることを避ける為    

Slide 23

Slide 23 text

アグリーメントの実際  顧客が幅広くいるほどSLAの変更はしづらくなる為、ユーザーに開示する内容は控えめにしておくことが賢明。  SREは、SLOを満たせる可能性や難易度をビジネス及び法務チームに理解させ違反の際の規程やペナルティを適切に選択できるよう支援する。 

Slide 24

Slide 24 text

トイルの撲滅 

Slide 25

Slide 25 text

トイルの定義  プロダクションサービスを動作させることに関係する作業  以下の1つ以上に当てはまる仕事はトイル度合いが高い  ● 手作業であること  ● 繰り返されること  ● 自動化できること  ● 戦術的であること  ● 長期的な価値を持たないこと  ● サービスの成長に対してO(n)であること 

Slide 26

Slide 26 text

トイルが少ない方が良い理由  GoogleのSREではトイル比率は各人の作業時間の50%以下という目標  トイルを減らし、サービスをスケールさせる作業がSREにおけるエンジニアリング  →SREの組織規模がサービスのサイズや数に比例せずに効率的に管理できる 

Slide 27

Slide 27 text

エンジニアリングであるための条件  典型的なSREの活動 ● ソフトウェアエンジニアリング ● システムエンジニアリング ● トイル ● オーバーヘッド四半期あるいは1年を通して平均で50%以上エンジニアリングの作業に当てられなかった場合は何が問題なのか把握し改善が必要

Slide 28

Slide 28 text

トイルは常に悪なのか？  個人的なデメリット ● キャリアの停滞 ● モラルの低下　→　燃え尽きや倦怠、不満に繋がることも

Slide 29

Slide 29 text

トイルは常に悪なのか？  組織的なデメリット ● 混乱の発生　→　旧来のシステム管理者と変わらない ● 進捗速度の低下 ● 習慣づけ ● 摩擦の発生　→　チーム内でトイルに対する扱い ● 信義違反　→　採用や異動でSREとして加入した場合モラルに悪影響

Slide 30

Slide 30 text

分散システムのモニタリング 

Slide 31

Slide 31 text

定義  ● モニタリングシステムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと。 ● ホワイトボックスモニタリングシステム内部に公開されているメトリクスに基づくモニタリング。 ● ブラックボックスモニタリングユーザーが目にする外部の振る舞いをモニタリング。 ● ダッシュボードサービスの主要メトリクスのサマリビューを提供するアプリケーション。

Slide 32

Slide 32 text

定義  ● アラート人間に読まれることを意図した通知。チケット、メールアラート、ページに分類。 ● 根本原因ソフトウェアの欠陥やヒューマンエラーで、修正されれば同じことが同様に発生しないと確信できるものを指す。 ● ノードとマシン物理サーバー、仮想マシン、コンテナ内で動作しているカーネルの 1つのインスタンスを示す。 ● プッシュサービス動作中のソフトウェア、あるいはその設定に対する変更。

Slide 33

Slide 33 text

モニタリングの必要性  ● 長期的なトレンドの分析データベースの余裕や DAUの増加ペースなど ● 時間や実験グループ間での比較どちらのクエリの高速か、 memcacheのヒット率はなど ● アラート ● ダッシュボードの構築 ● アドホックな振り返り分析の進行（デバッギングなど）レイテンシーが急上昇したが、他に何か同時期に生じていることがないか

Slide 34

Slide 34 text

4大シグナル  ● レイテンシーリクエストを処理してレスポンスを返すまでの時間 ● トラフィックシステムに対するリクエストの量 ● エラー処理に失敗したリクエストのレート ● サチュレーションサービスがどれだけ飽和状態になっているか(メモリ、I/Oなど)

Slide 35

Slide 35 text

適切な計測粒度の選択  粒度を細かくすると収集、保存、分析のコストが非常に大きくなる一方で粒度を大きくすると一時的なスパイクが平均で均されて気づけなくなる

Slide 36

Slide 36 text

可能な限りシンプルに、やり過ぎない  ● 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべき ● ほとんど実施されない(四半期に1回未満のような)データの収集、集計、アラートの設定は削除すべき ● 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示されず、どのアラートにも使われていないシグナルは削除候補

Slide 37

Slide 37 text

モニタリングやアラートでの確認点  ● ルールが検出する状況は、そのルールなしで検出されない状況で、緊急対応が可能で現時点あるいは近い将来にユーザーに影響を及ぼすか？ ● そのアラートが無害なものだと判断して対応せずにできるものか？ (どのような時に、どのような理由で無視できるか？ ) ● そのアラートが間違いなくユーザーに悪影響を及ぼしているか？ (トラフィックのドレイン済やテスト用のデプロイなど除外すべきケースは？ ) ● そのアラートに対応してアクションが取れるか？そのアクションは緊急か、翌朝まで待つことができるか？安全に自動化できないか？そのアクションの修正効果は短期的か長期的か？ ● その問題でページを受ける人は他にもいるか？その場合少なくともページの 1つが不要ではないか？

Slide 38

Slide 38 text

ページ及びページャーでの確認点  ● ページが来る度に緊急事態という感覚で対応が必要。(緊急事態の感覚で対応可能なのは1日に数回が限度、それを超えると疲弊し始める) ● すべてのページは具体的な対応が可能であることが必要。 ● あらゆるページは対応に人の判断が必要。自動化が可能なものはページとすべきではない。 ● ページは新たな問題か、これまで見られたことがないイベントに関するものであるべき。

Slide 39

Slide 39 text

次回予告 

Slide 40

Slide 40 text

Googleにおける自動化の進化  リリースエンジニアリング  時系列データからの  実践的なアラート  オンコール対応    第肆回 

Slide 41

Slide 41 text

ありがとうございました  参照:  SRE  サイトリライアビリティ   エンジニアリング  Googleの信頼性を支えるエンジニアリングチーム   (オライリー・ジャパン)    