Site Reliability Engineering #6

SRE

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

6.1 定義

  • モニタリング
    • システムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと
  • ホワイトボックスモニタリング
    • システム内部のメトリクスでログ、JavaVM Profiling interfaceなど統計情報が得られるインプット
  • ブラックボックスモニタリング
    • ユーザが目にする外部の振る舞い
  • ダッシュボード
    • 主要メトリクスのサマリビュー
  • アラート
    • 人間に読まれることを意図した通知
    • チケット、メールアラート、ページに分類される
  • 根本原因
    • 修正されたら同一の事象が起きないと確信できる原因
  • ノードとマシン
  • プッシュ
    • サービス動作中のソフトウェア、設定への変更

6.2 モニタリングの必要性

システム自身が壊れた、壊れる予兆を次のモニタリングとアラートによって人間に通知ができる。

人間へページすれば貴重な時間を消費することになる。 効率的なアラートは人間が取り組む対象に絞られた室の高いシグナルに絞り、ノイズを低く抑える。

6.3 モニタリングにおける妥当な期待値の設定

GoogleのSREチームでは10人〜12人のメンバのうち、担当するサービスのモニタリングシステムの構築とメンテナンスに1人か2人を割り当てる。

重要なのはプロダクション環境での人間へのページ、切り分け、デバッギングに至るクリティカルパスをチーム全員でシンプルかつ包括的に保つこと。

6.4 症状と原因

モニタリングシステムは何が壊れたか、なぜ壊れたのかという2つの疑問に答えなければならない。

症状は観測された振る舞い、原因は振る舞いを起こしたメカニズムである。

6.5 ブラックボックスとホワイボックス

ブラックボックスは「現在、システムが正常に動作していない」という症状を扱う。 ホワイトボックスはログやHTTPエンドポイントといったシステム内部を調査する機能に依存する。

6.6 4大シグナル

6.7 テイルレイテンシに関する懸念(あるいはインスツルメンテーションとパフォーマンス)

レイテンシの傾向を判断するには算術平均よりも、ヒストグラムが優れている。 例えばリクエストの1％が低速の原因を占めることが起きうる。

6.8 適切な計測の粒度の選択

システムの様々な側面が粒度のレベルを変えて測定するべきである。 粒度を細かくしすぎると収集、保存、分析のコストが増大するため、バランスに注意する。

バランスを取るにはバケット化することで知りたい粒度にしながらコストを軽減できる。

  1. CPU使用率を毎秒記録する
  2. 記録した使用率を5%刻みのバケットに入れてインクリメントする
  3. 1分単位でバケットを集計する

6.9 可能な限りシンプルに、ただしやりすぎないこと

モニタリングシステムの設計はシンプルさに目を向ける。 モニタリングシステムが複雑になりすぎると、複雑でメンテンナンスが負担になりうる。

モニタリングの対象を選択するには次のガイドラインに沿って検討する。

  • 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで予想しやすく信頼できるものであるべき
  • 四半期に1回未満のデータの収集、集計、アラートの設定は削除すべき –　収集されていてもダッシュボードに表示されない、アラートに使われていないシグナルは削除の候補である

6.10 原則の取りまとめ

モニタリングやアラートのルールを作成する際には以下の質問に沿って要否を判断する。

  • ユーザに近い将来含めて影響を及ぼす、ルールなしでは検出されないものか
  • アラートを放置しても影響がないものか
  • ユーザに悪影響が生じていいることを示しているか
  • アラートに対してアクションが取れるか、不要不急なものか
  • ページを受ける人が複数か、そうであるならば1人にできないか

6.11 長期間に渡るモニタリング

今日発生している一つ一つのページに人が対応するのは、明日のためのシステム改善にあてる時間がなくなる、というトレードオフの関係にある。 システムの長期的な展望を改善するために可用性なパフォーマンスの短期的な低下を受け入れることもある。

6.12 まとめ

メールアラートの価値は限定的でノイズになりやすい。代わりにダッシュボードでモニタリングすると良い。 長期的にはオンコールのローテーションとプロダクションを成功に導くため、達成可能な目標にターゲットを合わせてモニタリングシステムが素早い診断を確実に支援できることが必要である。

Site Reliability Engineering #5

５章トイルの撲滅

通常運用中のシステムに人手が必要なら、それはバグだ。 通常の定義は、システムの成長と共に変化する。

-----Carla Geisser、Google SRE

5.1 トイルの定義

トイルは「労苦」を表します。 プロダクションサービスの動作に関係する作業で手作業で繰り返され、長期的な価値を持たず作業量がサービスの成長に比例する傾向を持つ。 自動化することが可能な作業である。 トイルの度合いが高い仕事は次の特徴がある

  • 手作業
  • 繰り返される
  • 自動化できる
  • 戦術的である
  • 長期的な価値を持たない
  • サービスの成長に対してO(n)

トイルと混同されやすい作業にオーバーヘッドがある。 管理上の雑務でプロダクションサービスの稼働に結びつかない仕事を含む、次のものである。

  • チームミーティング
  • ゴールの設定と評価
  • スニペット
  • 人事の事務作業

5.2 トイルは少ない方が良い理由

GoogleのSREは作業時間の50％以上を将来のトイル削減、またはサービスに機能を追加する作業に確保するべきである。 トイルの作業は50％以下に抑える目標がある。

トイルの作業を50％にするのはトイルに目を向けなければ自然に増えていき、全員の時間を100％トイルで埋め尽くす傾向があるためである。

トイルの下限も設定しており、６人が６週間ごとに２習慣のオンコールシフトと割り込み対応にあてる場合、潜在的なトイルの下限は

\frac{2}{6} = 33 \%

になる。

5.3 エンジニアリングであるための条件

5.1, 5.2をまとめると典型的なSREの活動は次の分類に沿う。

  • ソフトウェア・エンジニアリング
    • コードの作成や修正を含む作業
  • システムエンジニアリング
    • プロダクションシステムの設定、システムのドキュメント作成が含まれ、１回の作業で改善効果が持続する方法で行われる。
  • といる
  • オーバーヘッド

5.4 トイルは常に悪なのか？

トイルは常に悪いものではなく、エンジニアリリングに関わる全ての職務にとって多少のトイルは避けられないものである。 トイルが大量になった場合、次の面で有害になる。

  • キャリアの停滞
  • モラルの低下
  • 混乱の発生
  • 進捗速度の低下
  • 習慣づけ
  • 摩擦の発生
  • 信義違反

5.5 まとめ

イノベーションを増やし、トイルを減らそう。

「入門 監視」を読んで

書籍−ノウハウ SRE

監視の原則やデザインパターンを体系だって学ぶことで、自己流の監視のアンラーニングを目的に読みました。

www.oreilly.co.jp

本書は監視の原則から始まり、知りたいことが体系立って書かれていました。

  • 監視の定石であるデザインパターン
  • 障害に対する適切なアラートのコントロール方法
  • 統計的なデータの扱い方の特徴と注意点
    • 平均値 vs 中央値
    • パーセンタイル
  • サービスの成長に伴う監視システムの内製/SaaSの選定、戦略
  • ビジネスKPIに紐づく監視戦略と監視項目、各社の具体例
  • ネットワーク〜Linuxカーネル〜アプリの技術スタックと監視内容
  • セキュリティ監視

特にIaaSの技術スタックに関する知識に偏りがちだった自分にとって、監視SaaSを組み合わせたメリットやデザインパターンはインプットになりました。

並行して読んでいるSite Reliability Engineeringが抽象度高く書かれており、具体例を補うものとして本書はとても役に立ちました。

Site Reliability Engineering #4

書籍−ノウハウ SRE

4章サービスレベル目標

ユーザに対するサービスレベルを定義する。 定義するものはサービスレベル目標(SLI)、サービスレベル目標(SLO)、サービスレベルアグリメーメント(SLA)になる。

4.1 サービスレベルに関する用語

  • SLI
    • 提供されているサービスの性質に応じて定義される
    • リクエストのレイテンシ、エラー率、システムスループット。可用性、耐久性

  • SLO

    • SLIで計測されるサービスレベルのターゲット、または範囲を指す
    • ターゲットの場合は SLI \leqq ターゲット の関係が成り立つ状態を目指す
    • 範囲の場合は 下限 \leqq SLI \leqq 上限 の関係が成り立つ状態を目指す
    • ユーザの動向によって決まるメトリクス(ex. QPS)をSLOにすることは現実的ではない

  • SLA

    • ユーザとの間で結ぶ契約のこと
    • SLOを満たした場合/満たさなかった場合の規定を含む
    • 「SLOを満たさなかったときにはどうなるのか？」から分かる

SLOにはユーザの関心事を反映させ公表して期待を設定する。 期待を設定することでユーザのサービスに対する独自の期待や過剰な信頼を取り除くことができる。

4.2 指標の実際

提供するサービスの性質によってSLIを選択する。

指標の収集結果を分布で捉えると、スパイクといった5％が全体の95％に影響を与える動作を見つけられる。 収集結果を算術平均で捉えると埋もれてしまう。

4.3 目標の実際

サービスの性質によって決まり、パーセンタイルを活用する。

  • パフォーマンスカーブが重要な場合

    • Get RPC呼び出しの90％が1m以下で完了すること
    • Get RPC呼び出しの99％が10m以下で完了すること
    • Get RPC呼び出しの99.9％が100m以下で完了すること

  • スループット、レイテンシそれぞれが気なるユーザがいる場合

    • スループットタイプのクライアントのSet RPC呼び出しの95％が、1s以下で完了すること
    • レイテンシタイプのクライアントの、1kB以下のペイロードを持つSet RPC呼び出しの99％が、10ms以下で完結すること

SLOを常に満たし続けるのはデプロイ頻度の低下を招き、高価で過剰に保守的なソリューションが必要になることに繋がる。

SLOは経営に関わる次の制約の中で満たす必要があり、議論する必要がある。

  • スタッフ、市場投入までの期間、利用できるハードウェア、資金

現実的な期待をユーザのために設定するには安全マージンを確保する、過剰達成を避けて計画的なサービス停止を導入するなどができる。

4.4 アグリーメントの実際

SLAはビジネス、法務のチームが規定やペナルティを選択できるようにする。 顧客の属性が幅広いほどSLAの変更削除が難しくなるため、開示する内容は控えめにする。

Site Reliability Engineering #3

SRE

第Ⅱ部 原則

トイルを撲滅することはSREにとって最も重要なタスクの一つである。 トイルの定義は日常的に繰り返される価値を生み出さない、サービスの成長に比例してスケールする運用作業である。

3章リスクの受容

Googleは過度の信頼性がプロダクトの提供速度の鈍化、過剰なコストの増大を生むと考えている。

  • 99%の信頼性をもつスマートフォンを使っているユーザに、サービスが99.99%の場合と99.999%の場合で違いは分からない

3.1 リスクの管理

システムの信頼性とコストの関係は比例ではなく、次の要因によってコストが100倍になることもある。

  • 設備の冗長化による、定期/予定外のメンテナンスコスト
  • ユーザに見えない、リスクを減らすためのシステムや機能の構築

SREはサービスの信頼性を管理する要因としてリスク管理を重視している。

3.2 サービスリスクの計測

システムの特徴を表す客観的なメトリクスを見出し、パフォーマンスの評価や改善、劣化の追跡ができるようになる。

メトリクスの例として次の指標が挙げられる。

  • 計画外の停止時間
    • 可用性 = \frac{稼働時間}{稼働時間 + 停止時間}
    • 可用性を99.99％か、99.99999%を目指すかが明快

ただし、googleはグローバルに分散したサービスなのでどこかの地域がレスポンスを返すため常に稼働中に見えてしまう。

代わりにリクエスト成功率を可用性として定義する。

  • 可用性 = 成功したリクエスト数 / 総リクエスト数

このメリットはユーザに直接見えないバックエンドのシステムに対しても同一のメトリクスを適用しやすくなる。 バッチシステムの場合は成功したレコード数、失敗したレコード数に置き換えて計算できる。

3.3 サービスのリスク許容度

多くの場合、アプリケーションのビジネスを担当するプロダクトマネージャーがいて、サービスの信頼性を議論する。 リスク許容度を議論するにあたって次の要素を元に検討する。

  • 可用性のレベル
    • サービスの性質、競合他社のレベル、BtoB、BtoCかなど
  • 障害の種類によるサービスへの影響の違い
    • ビジネスの時間帯に稼働していれば済むのか
  • リスク曲線上サービスを伸ばすことが優先されるか(機能開発速度が重視されるか)
    • 可用性を1桁上げた場合の収益と追加コスト
  • 考慮すべきその他重要メトリクス
    • ユーザの体感速度に応じたレイテンシの設定ができたら、コストを抑制できる

インフラストラクチャの場合はコンシューマと違い異なる特性を持つ多様なクライアントの要求が存在する。

  • 可用性のレベル
    • 低レイテンシ高可用性のサービス vs スループット重視のサービス
    • 同一インフラで実現することはコストが掛かりすぎるので、インフラを分割し、独立したレベルのサービスとして扱う。

インフラストラクチャは明示的に示したサービスレベルでサービスを提供することで、クライアント側がリスクとコストの適切なトレードオフを選択できる。

3.4 エラーバジェット

プロダクト開発者のパフォーマンス指標の開発速度と、SREのパフォーマンス指標の信頼性で評価すると緊張が生まれる。

評価の指標をエラーバジェットに置き換えてイノベーションと信頼性の適切なバランスを見出す。

エラーバジェットのルールは次の通り。

  • SLOに基づくエラーバジェットはプロダクトマネージャーが規定する
  • 稼働時間は第三者のモニタリングシステムで計測する
  • 目標と実績の差異を四半期の「損失可能な信頼性」という「予算」として管理する
  • 稼働時間がSLOを超えていれば、リリース可能とする。

エラーバジェットにより、プロダクトの開発チームが自己統制をするように促せるメリットがある。

参考

www.oreilly.co.jp

Site Reliability Engineering #2

SRE

2章 SREの観点から覽たGoogleのプロダクション環境

2.1 ハードウェア

Googleが設計した独自のデーターセンタ群から構成される

  • マシン
    • 一つのハードウェアまたは1つのVM
  • サーバ
    • サービスを実装しているソフトウェア

マシンは抽象化を施すことで、Googleのクラスタオペレーティングシステムである「Borg」がプログラムの実行に必要なリソースの割当を受け持つ。

データセンター内のマシン間の通信を支えるためにJupiterと呼ばれる高速な仮想スイッチをGoogleは開発した。 JupiterはClosネットワーク装置であり、サーバ間で1．3Pbsの帯域幅をサポートする。 データーセンタ群はSDNにより地球規模のバックボーンネットワークで相互接続されている。

2.2 ハードウェアを「組織化」するシステムソフトウェア

Googleはスケーラビリティが高いソフトウェアによりハードウェアの障害によりユーザが影響を受けないようにしている

BorgはApache Mesosに似た分散クラスタオペレーティングシステムでジョブをクラスタのレベルで管理する - ジョブは同一タスクが1つ以上含まれることがある

Borgは障害ドメインを考慮して、タスクをマシンに配置する

  • #注釈 Borgはkubernetesの祖先にあたるシステム

タスクはHDPSに相当するストレージが利用でき、多くのレイヤーから構成される

ネットワークは世界中に分散配置されたシステムから、サービスのレイテンシを最小化する最も近いデータセンターにユーザを振り分ける。 ユーザの振り分けはGSLBで行われ、3つのレベルでロードバランスをする。

  • DNSリクエストへの地理的なロードバランス
  • ユーザサービスレベルのロードバランシング
  • RPCレベルのロードバランシング

2.3 他のシステムソフトウェア

これらに加えて非同期の合意形成に利用するPaxosプロトコルを持つChubbyというストレージがある。

モニタリングとアラートのためにBorgmanというインスタンスがサーバのメトリクスをスクレイプしている。

2.4 Googleのソフトウェアインフラストラクチャ

極度にマルチスレッド化、かつRPCを使った通信に揃えたソフトウェアアーキテクチャとすることで、分散化を容易にしている。

また、protocol buffersによりXMLと比較してサイズが最大1/10、最大100倍高速化している。

2.5 Googleの開発環境

Googleは単一の共有リポジトリを使って作業することで、次のメリットを得ている

  • プロジェクト外のコンポーネントに対して変更提案の”Changelist”をコンポーネントの所有者に贈り、メインラインに投入してもらうことができる
  • ”Changelist”が投入されるたびに依存関係を持つコンポーネントのテストが実行され、所有者が異常に素早く気がつける

2.6 シェークスピア：サンプルのサービス

具体例としてシェークスピアの全作品から単語を検索できるサービスの提供を考えてみる。

ユーザからのリクエストは次のデータフローに沿って処理される

  1. ユーザ -> DNS
  2. ユーザ -> GFE -> アプリケーションフロントエンド -> アプリケーションバックエンド -> Bigtable

ユーザのリクエスト受付からユーザへのレスポンス開始まで数百ミリ秒の時間で実現している。

Site Reliability Engineering #1

SRE

GoogleのSRE本を読み始めました。

www.oreilly.co.jp

1章イントロダクション

1.1 サービス管理へのシステム管理者のアプローチ

歴史的に企業はサービスを動作させるために既存のソフトウェアコンポーネントを組合わあせて動かせるシステム管理者を雇用してきた。 「シスアド」とも呼ばれるこの役割は開発者とは異なるスキルセットを持つので、「dev」と「ops」という別々のチームで分けられてきた。 シスアドという役割の利点はあり、業界では馴染みのあるパラダイムであり導入しやすいことである。

一方で「シスアド」とも呼ばれる役割を作ることで「dev」と「ops」の分断によりデメリットも生まれた

  • 直接的には手動運用が中心の「ops」チームはサービスの成長やトラフィックの増大によるシステムの運用負荷が増えるに連れてチームを拡大せざるを得なくなる
  • 間接的には「dev」と「ops」が異なるバックグラウンド、スキルセット、動機づけが異なるためプロダクト開発において安定性やリスクの捉え方について異なる解釈をして衝突が生まれる
    • 「好きなものを好きな時にローンチしたい」vs「いったん動いたシステムは一切変更したくない」

開発者は衝突を迂回する方法を学び、レビューの実効性が失われていく。

1.2 サービス管理者へのgoogleのアプローチ：サイトリライアビリティエンジニアリング

「dev」と「ops」の衝突に対して、Googleはサイトリライアビリティエンジニアリング(以降、SRE)チームはソフトウェアエンジニアを採用した SREはシスアドによって手作業で行われたであろう作業を自動化するシステムを構築する

  • SREのうち、60％はGoogleの標準的なソフトウェアエンジニア採用を経て雇用されたメンバである

  • 残り40％はソフトウェアエンジニアリングの必須条件を85%-99%満たす候補者である

  • 後者のほぼ必須条件を満たすメンバは、ソフトウェアエンジニア採用よりもエンジニアリングやUNIXシステム、ネットワーキングに関する専門知識をもつ

SREを採用していった結果、(a)手作業でタスクをこなすことにすぐ飽きる、(b)複雑でも手作業のシステムを自動化できるスキルをもつ、エンジニアのチームができた GoogleではすべてのSREに対してチケット、オンコール、手作業といった「運用」業務の合計を50％以下にする上限を設けた 上限を超えた場合、開発チームに差し戻したり新たな人員をチームに加えることができる システムの稼働、メンテンナンス、改善に必要なSREの人数はシステムのサイズに対して比例しない

1.3 SREの信条

サポートするサービスに対する一連の基本的な責任と、中核となる信条の尊重はすべてのSREチームに共通する。 SREチームはサービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負う。

  • 信条
    • SREが運用作業に書ける時間は50％
    • 「エラーバジェット」を導入して、サービスのSLOを下回らずに変更速度の最大化を追求する
      • 「サービス障害をゼロに」する目標から「エラーバジェット」に目標を変えることで、開発とSREの間で起きる構造的な競合を解決する
    • モニタリングは人間がメールを読んでアクションの必要性を判断するシステムは根本的な欠点を持つと考える
      • 効果的なモニタリングとして人間に即座のアクションを促すアラート、人間に日次のアクションを促すチケット、フォレンジックのっために記録するロギングの3要素を持つ
    • SREは70%のサービス障害は動作中のシステムへの変更によって生じることを発見し、自動化で以下を実現するベストプラクティスを得た
      • 漸進的なロールアウト
      • 高速かつ正確な問題の検出
      • 問題が生じたときの安全なロールバック