感想
タイトルだけみて「データベースに関する書籍かな？なんか面白そうだし読んでみるかー」ぐらいに思って手に取ったが、奥深き本だった。データベースそのものというより、データベースを軸にビジネスをどう発展させるか？より良いシステムを作るにはどうすればいいか？が具体的に書いてあり、面白かった。保守性って大事なんだなと、しみじみ、、、。
後半の内容は私にはレベルが高すぎてパラパラ読んでしまった。
以下印象に残った部分。
速度こそ全て
一時的なシステムダウンより、恒常的なレイテンシが遅いサービスのほうがより多くのユーザ離れを引き起こす。
Googleの実験1によると、100ミリ秒から400ミリ秒の遅延に対して0.2%から0.6%のユーザが離脱することが確認された。
回復力のあるシステム
障害のない堅牢なシステムは、堅牢であるがゆえに、一旦障害が発生して対応を迫られた場合の影響度が深刻なものとなってしまう。しばしば障害を起こすものの、その都度すぐ回復するサービスのほうがユーザビリティが高いといえる。
回復力のあるシステムとは以下の特徴を持つ。
- 障害を検知する優れた監視システムを持ち、さらに自己修復機能を備えているため平均修復時間が短くなる。
- 分散システム採用により高い冗長性を確保しているため、１つの障害が全体に与える影響が小さくなる
- 障害に対する自動修復機能、洗練されたドキュメント、事前トレーニングといった組織全体での回復力を高めることで、障害対応はもはや特別なものではなくなり、通常業務の１つとなる。
1.SLOを定義する
- レイテンシ指標を定義する
- リクエストの99%においてレイテンシは25ミリ秒から100ミリ秒の間におさめること
- 可用性の指標を定義する
- 1週間あたりの可用性の平均が99.9%であること
- 障害が発生した場合、10.08分間以内に復旧すること
- ダウンタイムとは、全体のユーザ数の5%以上に影響を与える事象とする
- 1年に1回は4時間のダウンタイムを許容する。ただし以下を満たさなければならない
- 2週間前にユーザへ通知すること
- 1度にユーザ数の10%以上に影響を与えないこと
- スループットの指標を定義する
- 費用対効果の指標を定義する
定義したSLOは定期的に見直すこと。
SLOを定義するさいにはダッシュボード1ページに収まる簡潔なものとし、ユーザ中心で優先順位を組み立てること。
2.SLOに基づいた監視とレポートを行う
- 監視システムによる 生データ を収集する
- 可用性の監視を行う
- ユーザからのリクエストに対するエラー発生率(RUM - Real User Monitoring)に着目する
- レイテンシの監視を行う
- ユーザからのリクエストに対するレスポンスにかかった時間に着目する
- スループットの監視を行う
- 秒単位でトランザクションを記録し、どのタイミングで出力が落ちてきたのかを把握する
- 費用対効果の監視を行う
3.SLOに基づいたリスクマネジメントを行う
- 監視とレポートを基にSLOを脅かすリスクを認識する
- リスクが現実となって起こりうる可能性及び発生した場合にもたらす影響を考慮して各リスクに対して優先順位づけを行う
- 非常に深刻な影響を与える(Severe: 即SLO違反となる)
- 深刻な影響を与える(Major: SLO違反ギリギリ)
- 中程度の影響を与える(Moderate: 他のケースが同時発生した場合SLO違反となりうる)
- 軽微な影響を与える(Minor: 軽微)
- 各リスクに対して、回避・低減・需要の意思決定を行う
用語集
SLO - サービスレベル目標
設計及び運用に関して遵守すべき事柄をまとめたもの。
レイテンシ
1リクエストに対するレスポンスにかかる時間を表すもの。
ユーザ側の環境からエンドツーエンドでどの程度かかるか。
可用性
サービスにリクエストに対して決めれらた基準内でレスポンスを返すことができる状態であり、パーセンテージで表される。
スループット
一定時間において正常に処理されたリクエストの割合のこと。一定時間とは一般的に秒単位で測定される。
耐久性
ストレージに対して一定の成功率で書き込みができるかどうか。
費用対効果
ユーザがとる１つの行動（１ページビュー、１購読数、購入１件、、、）に対する効果。費用対効果の結果は、オンラインマガジンなどであればページビューであるし、オンラインサービスならばユーザ数、小売業ならトランザクション数になる。
-
Speed Matters(https://ai.googleblog.com/2009/06/speed-matters.html) ↩