Site Reliability Engineering #7
今回から要約をしていきます。
7章 Googleにおける自動化の進化
自動化によるメリットが述べられている。
- 同じ手順を間違いなく行う一貫性
- プラットフォーム化したときの間違いの集約とバグ修正コストの低さ
- 人手を介さない高速な修復によるMTTRの削減
- 時間の節約と、副次的な属人性の排除
Google SREはプロダクトやサービスが地球全体に及ぶ規模を持っており、限られた人員でサポートするには自動化は避けられない。
2章で述べられていたモノリシックなリポジトリで運用することで、他の組織のプロダクトやサービスにいつでもアクセスできる環境を整えている。 また、重要なコンポーネントはAPI化もして自動化を阻害しうる要因を排除することが会社として移管している。 自動化のためにはベンダー製品であってもAPIを内製して推進をしている。
これらは「プロダクション環境下のプロダクトを所有する」というGoogle SREのミッションに基づいた行動になっている。
自動化に取り組むにあたって抽象度の高い自動化ツール(Puppet、Chef)やPOSIXレベルの抽象度の低いPerlとの使い分けが述べられている。 高レベルでは要点を押さえた簡潔な処理が書きやすいが、抽象化に漏れがあると構造的な失敗が繰り返され、一貫性が損なわれやすい。 例えばクラスタのバージョン更新にあたって上手くいく処理は書きやすいが、更新中に障害が起きたときに「どちらでもない状態」が生まれ人手を介することになる。 一方抽象度の低いツールは部品化され、再利用がしやすいメリットが述べられている。
自動化の進化はデータベースの例に取ると、SRE個人が所有するフェイルオーバーのスクリプトを実行する外部からメンテナンスする状態から、データベース自身がフェイルオーバーを備える内部でメンテンナンスする状態を辿ると延べらている。
自動化のユースケースでは本質的な問題に腰を据えることで、人手を極力排除した例が述べられている。
- MySQLをサーバからBorgに載せ替えて自動フェイルオーバーを実現して、運用コストを95％下げた
- 1週間で5つのBorgクラスタを立ち上げために、クラスタの初期状態からネットワーク構築、クラスタ利用者が登録した構築手順まで自動化する自律システム
自動化の勧めとしては時間で投資対効果で測るだけではなく、自律的な運用を設計段階で組み込むことで運用を省力化にすることが役立つと述べている。
Site Reliability Engineering #6
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 適切な計測の粒度の選択
システムの様々な側面が粒度のレベルを変えて測定するべきである。 粒度を細かくしすぎると収集、保存、分析のコストが増大するため、バランスに注意する。
バランスを取るにはバケット化することで知りたい粒度にしながらコストを軽減できる。
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％トイルで埋め尽くす傾向があるためである。
トイルの下限も設定しており、６人が６週間ごとに２習慣のオンコールシフトと割り込み対応にあてる場合、潜在的なトイルの下限は
になる。
5.3 エンジニアリングであるための条件
5.1, 5.2をまとめると典型的なSREの活動は次の分類に沿う。
- ソフトウェア・エンジニアリング
- コードの作成や修正を含む作業
- システムエンジニアリング
- プロダクションシステムの設定、システムのドキュメント作成が含まれ、１回の作業で改善効果が持続する方法で行われる。
- といる
- オーバーヘッド
5.4 トイルは常に悪なのか？
トイルは常に悪いものではなく、エンジニアリリングに関わる全ての職務にとって多少のトイルは避けられないものである。 トイルが大量になった場合、次の面で有害になる。
- キャリアの停滞
- モラルの低下
- 混乱の発生
- 進捗速度の低下
- 習慣づけ
- 摩擦の発生
- 信義違反
5.5 まとめ
イノベーションを増やし、トイルを減らそう。
「入門 監視」を読んで
監視の原則やデザインパターンを体系だって学ぶことで、自己流の監視のアンラーニングを目的に読みました。
本書は監視の原則から始まり、知りたいことが体系立って書かれていました。
- 監視の定石であるデザインパターン
- 障害に対する適切なアラートのコントロール方法
- 統計的なデータの扱い方の特徴と注意点
- 平均値 vs 中央値
- パーセンタイル
- サービスの成長に伴う監視システムの内製/SaaSの選定、戦略
- ビジネスKPIに紐づく監視戦略と監視項目、各社の具体例
- ネットワーク〜Linuxカーネル〜アプリの技術スタックと監視内容
- セキュリティ監視
特にIaaSの技術スタックに関する知識に偏りがちだった自分にとって、監視SaaSを組み合わせたメリットやデザインパターンはインプットになりました。
並行して読んでいるSite Reliability Engineeringが抽象度高く書かれており、具体例を補うものとして本書はとても役に立ちました。
Site Reliability Engineering #4
4章サービスレベル目標
ユーザに対するサービスレベルを定義する。 定義するものはサービスレベル目標(SLI)、サービスレベル目標(SLO)、サービスレベルアグリメーメント(SLA)になる。
4.1 サービスレベルに関する用語
- SLI
SLO
- SLIで計測されるサービスレベルのターゲット、または範囲を指す
- ターゲットの場合は
の関係が成り立つ状態を目指す
- 範囲の場合は
の関係が成り立つ状態を目指す
- ユーザの動向によって決まるメトリクス(ex. QPS)をSLOにすることは現実的ではない
-
- ユーザとの間で結ぶ契約のこと
- SLOを満たした場合/満たさなかった場合の規定を含む
- 「SLOを満たさなかったときにはどうなるのか？」から分かる
SLOにはユーザの関心事を反映させ公表して期待を設定する。 期待を設定することでユーザのサービスに対する独自の期待や過剰な信頼を取り除くことができる。
4.2 指標の実際
提供するサービスの性質によってSLIを選択する。
指標の収集結果を分布で捉えると、スパイクといった5％が全体の95％に影響を与える動作を見つけられる。 収集結果を算術平均で捉えると埋もれてしまう。
4.3 目標の実際
サービスの性質によって決まり、パーセンタイルを活用する。
パフォーマンスカーブが重要な場合
- Get RPC呼び出しの90％が1m以下で完了すること
- Get RPC呼び出しの99％が10m以下で完了すること
- Get RPC呼び出しの99.9％が100m以下で完了すること
スループット、レイテンシそれぞれが気なるユーザがいる場合
SLOを常に満たし続けるのはデプロイ頻度の低下を招き、高価で過剰に保守的なソリューションが必要になることに繋がる。
SLOは経営に関わる次の制約の中で満たす必要があり、議論する必要がある。
- スタッフ、市場投入までの期間、利用できるハードウェア、資金
現実的な期待をユーザのために設定するには安全マージンを確保する、過剰達成を避けて計画的なサービス停止を導入するなどができる。
4.4 アグリーメントの実際
SLAはビジネス、法務のチームが規定やペナルティを選択できるようにする。 顧客の属性が幅広いほどSLAの変更削除が難しくなるため、開示する内容は控えめにする。
Site Reliability Engineering #3
第Ⅱ部 原則
トイルを撲滅することはSREにとって最も重要なタスクの一つである。 トイルの定義は日常的に繰り返される価値を生み出さない、サービスの成長に比例してスケールする運用作業である。
3章リスクの受容
Googleは過度の信頼性がプロダクトの提供速度の鈍化、過剰なコストの増大を生むと考えている。
3.1 リスクの管理
システムの信頼性とコストの関係は比例ではなく、次の要因によってコストが100倍になることもある。
- 設備の冗長化による、定期/予定外のメンテナンスコスト
- ユーザに見えない、リスクを減らすためのシステムや機能の構築
SREはサービスの信頼性を管理する要因としてリスク管理を重視している。
3.2 サービスリスクの計測
システムの特徴を表す客観的なメトリクスを見出し、パフォーマンスの評価や改善、劣化の追跡ができるようになる。
メトリクスの例として次の指標が挙げられる。
- 計画外の停止時間
- 可用性を99.99％か、99.99999%を目指すかが明快
ただし、googleはグローバルに分散したサービスなのでどこかの地域がレスポンスを返すため常に稼働中に見えてしまう。
代わりにリクエスト成功率を可用性として定義する。
このメリットはユーザに直接見えないバックエンドのシステムに対しても同一のメトリクスを適用しやすくなる。 バッチシステムの場合は成功したレコード数、失敗したレコード数に置き換えて計算できる。
3.3 サービスのリスク許容度
多くの場合、アプリケーションのビジネスを担当するプロダクトマネージャーがいて、サービスの信頼性を議論する。 リスク許容度を議論するにあたって次の要素を元に検討する。
- 可用性のレベル
- サービスの性質、競合他社のレベル、BtoB、BtoCかなど
- 障害の種類によるサービスへの影響の違い
- ビジネスの時間帯に稼働していれば済むのか
- リスク曲線上サービスを伸ばすことが優先されるか(機能開発速度が重視されるか)
- 可用性を1桁上げた場合の収益と追加コスト
- 考慮すべきその他重要メトリクス
- ユーザの体感速度に応じたレイテンシの設定ができたら、コストを抑制できる
インフラストラクチャの場合はコンシューマと違い異なる特性を持つ多様なクライアントの要求が存在する。
- 可用性のレベル
- 低レイテンシ高可用性のサービス vs スループット重視のサービス
- 同一インフラで実現することはコストが掛かりすぎるので、インフラを分割し、独立したレベルのサービスとして扱う。
インフラストラクチャは明示的に示したサービスレベルでサービスを提供することで、クライアント側がリスクとコストの適切なトレードオフを選択できる。
3.4 エラーバジェット
プロダクト開発者のパフォーマンス指標の開発速度と、SREのパフォーマンス指標の信頼性で評価すると緊張が生まれる。
評価の指標をエラーバジェットに置き換えてイノベーションと信頼性の適切なバランスを見出す。
エラーバジェットのルールは次の通り。
- SLOに基づくエラーバジェットはプロダクトマネージャーが規定する
- 稼働時間は第三者のモニタリングシステムで計測する
- 目標と実績の差異を四半期の「損失可能な信頼性」という「予算」として管理する
- 稼働時間がSLOを超えていれば、リリース可能とする。
エラーバジェットにより、プロダクトの開発チームが自己統制をするように促せるメリットがある。
参考
Site Reliability Engineering #2
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に相当するストレージが利用でき、多くのレイヤーから構成される
- 最も下のレイヤーは物理のHDD or SSD
- 次にColossusでファイルシステムとレプリケーション、暗号化を提供する。GFSの後継
- Colossus上にはNoSQLのBigtableとSQLに似たSpannerが稼働する
- 他にもBlobstoreなどのDBが利用できる
ネットワークは世界中に分散配置されたシステムから、サービスのレイテンシを最小化する最も近いデータセンターにユーザを振り分ける。 ユーザの振り分けはGSLBで行われ、3つのレベルでロードバランスをする。
2.3 他のシステムソフトウェア
これらに加えて非同期の合意形成に利用するPaxosプロトコルを持つChubbyというストレージがある。
モニタリングとアラートのためにBorgmanというインスタンスがサーバのメトリクスをスクレイプしている。
2.4 Googleのソフトウェアインフラストラクチャ
極度にマルチスレッド化、かつRPCを使った通信に揃えたソフトウェアアーキテクチャとすることで、分散化を容易にしている。
また、protocol buffersによりXMLと比較してサイズが最大1/10、最大100倍高速化している。
2.5 Googleの開発環境
Googleは単一の共有リポジトリを使って作業することで、次のメリットを得ている
- プロジェクト外のコンポーネントに対して変更提案の”Changelist”をコンポーネントの所有者に贈り、メインラインに投入してもらうことができる
- ”Changelist”が投入されるたびに依存関係を持つコンポーネントのテストが実行され、所有者が異常に素早く気がつける
2.6 シェークスピア：サンプルのサービス
具体例としてシェークスピアの全作品から単語を検索できるサービスの提供を考えてみる。
ユーザからのリクエストは次のデータフローに沿って処理される
ユーザのリクエスト受付からユーザへのレスポンス開始まで数百ミリ秒の時間で実現している。
