読書メモ: データベースリライアビリティエンジニアリング――回復力のあるデータベースシステムの設計と運用
概要
データベースリライアビリティエンジニアリング――回復力のあるデータベースシステムの設計と運用 の読書メモ
第1章 イントロダクション
データベースの家畜化について、概ね賛成できるが、結局保持したいデータが存在している限りステートレスなアプリよりは家畜度が下がってしまうのでは…
マズローの話はポエムかなと思った
第2章: サービスレベルマネジメント
2.1 SLO の必要性
SLO は数値を書けばよいというわけではなく、実質的な表記であるべき
例えば "可用性が99%" という表記をしたとき、実際には多様な可能性が考えられる
2.2 SLO の指標
- レイテンシ
- 可用性
- スループット
- 耐久性
- 費用対効果
2.3 サービス目標の定義
2.3.1 レイテンシ
レイテンシは 100ms 以下
データ取得の方法論: 一般にレイテンシの統計はきれいな分布にはならないので、実態を表すグラフを描画するべき
監視ではまず生データを取得する。その後でいくらでも人間が見やすい加工を行うことができる
1分間ウィンドウの最小値・最大値・平均を描画するというのは効果的な例
2.3.2 可用性
99.9%の可用性:
- 1年に1回、526分の停止
- 週に1回、10.08分の停止
回復力のあるシステム: MTTR が短い・回避策が用意されている
可用性が高いシステム: MTBF が長い
1回のダウンタイムの長さ・影響のあるユーザー数の割合
2.3.3 スループット
1リクエストに対してのレイテンシが短くても、例えば秒間10リクエストしか処理できない場合に100リクエスト来たら長く待たされる人が存在してしまう
2.3.4 費用対効果
エンジニアが費用対効果まで考えるのかと思うのも分かるが、程度の差だけで費用対効果を考えなくていいい人というのは存在しない
例えばDBの応答速度を高速化すれば、全体のコストが下がるかもしれない
2.4 SLO に基づいた監視とレポート
2.4.1 可用性
低レベルなチェック(ホストが電源オンか、ping が通るか etc.)から、分散アーキテクチャに合った方法への転換: リクエストのエラー率 Real User Monitoring
加えて、QAチームなどが仮想的に準備したリクエストを実際のサービスに処理させる定点モニタリングを行う
2.4.2 レイテンシ
単純に値をとる
2.4.3 スループット
値をとる
2.4.4 費用対効果
定量化できないコストがあるので測定が難しいが、定量化できる部分の数値を把握することは価値がある
Discussion