Database Reliability Engineering

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
Database Reliability Engineering により Mind Map: Database Reliability Engineering

1. 第1章: イントロダクション

1.1. 1. 現代のデータベースのプロフェッショナルはエンジニアでなければならない

1.1.1. 1. 問題点を洗い出すことができる

1.1.1.1. 設計

1.1.1.2. ビルド

1.1.1.3. データ構造

1.1.2. 2. 最適化するための行動を行う

1.1.2.1. コードを書く

1.1.2.2. ビルドを行う

1.1.3. 3. 技術の変化を理解し追従していける

1.2. 2. DBRE の指針

1.2.1. 1. データを守れ

1.2.1.1. 1. これまでの(?) アプローチ

1.2.1.1.1. アクセス可能な領域及び権限を適切に設定する

1.2.1.1.2. 一貫したバックアップとリストアの実施

1.2.1.1.3. セキュリティ脆弱性

1.2.1.1.4. 高い耐障害性を保証する

1.2.1.1.5. 高い上調整を保証する

1.2.1.2. 2. 新しいアプローチ

1.2.1.2.1. チーム間に壁を設けない

1.2.1.2.2. バックアップとリストアの方法

1.2.1.2.3. 方針を自動化プロセスに組み込む

1.2.1.2.4. データの要求仕様を考慮する

1.2.1.2.5. 権限設定の適切な実施

1.2.1.2.6. 大事にすること

1.2.1.2.7. デプロイや自動化の際

1.2.2. 2. 周囲を巻き込め

1.2.2.1. 2. 優秀なDBRE

1.2.2.1.1. メンバーやチームの力を引き出し正しい方向に導く

1.2.3. 3. 骨折り仕事を減らせ

1.2.3.1. 決まりきっていて何度も繰り返している作業

1.2.3.1.1. 創造性もやりがいもない

1.2.4. 4. サーバーの家畜化は時代の流れ

1.2.4.1. データベースに対するご意見版ではない

1.2.4.2. データベースを特別扱いする必要はない

1.2.4.2.1. ペットサーバー

1.2.4.2.2. 家畜サーバー

1.2.5. 5. 分業制に囚われるな

1.2.5.1. データベースエンジニアだからと自分の守備範囲を狭めない

1.2.5.1.1. データベースもソフトウェアの一部

1.2.5.1.2. ソフトウェアの開発の一連のサイクルについて積極的に学ぶ

1.2.5.1.3. オペレーションチームよりは開発チーム寄りの立ち位置と考える

1.2.5.1.4. 組織内のチームの壁をなくし改善が進む

1.2.5.2. 1. DBRE は希少

1.2.5.2.1. 他のメンバーやチームの協力が必要不可欠

1.2.5.2.2. 必要なタスク

1.3. 4. 欲求段階説

1.3.1. 1. 生存と安全の欲求

1.3.1.1. 1. データベースに絶対必要となる欲求

1.3.1.1.1. バックアップ

1.3.1.1.2. レプリケーション

1.3.1.1.3. フェイルオーバー

1.3.1.2. 2. スケールのパターン

1.3.1.2.1. スケールアップ

1.3.1.2.2. スケールアウト

1.3.1.2.3. シャーディング

1.3.2. 2. 愛と貴族の欲求

1.3.2.1. 1. データをエンジニアリングの中心にする

1.3.2.1.1. システム全体を管理することと同じ

1.3.2.1.2. 開発文化として推進していく

1.3.2.1.3. root を用いて王様のように仕事をすることはなくなる

1.3.2.2. 2. 開発チームの誰もがデータベース環境を自分ごととして捉えるように誘導する

1.3.2.2.1. コードレビューとデプロイを習慣として根付かせる

1.3.2.2.2. 構築と変更管理についても他のコンポーネントと同じやり方で進める

1.3.2.3. 3. データベースを恐ろしいものというイメージをメンバーに植え付けるのはやめる

1.3.2.3.1. メンバー自身がデータベースを正しい方法で行えるように教育、自信を持たせる

1.3.2.3.2. 間違いが起こり得ないようにガードレールを敷く

1.3.2.3.3. 間違いが発生しても修復可能であるように構築する

1.3.2.4. 4. Etsy のガードレール

1.3.2.4.1. 変更管理に際してレビューを実施そてスキーマ定義がおかしくなるのを防ぐ

1.3.2.4.2. 変更管理はスクリプト化され、正しくその変更を適用できるかを事前にテスト実行する

1.3.2.4.3. 適用前の状態をエンジニアが確認できる

1.3.2.4.4. 影響の大きい変更についてはローリングアップデートを行う

1.3.2.4.5. ワークフローを細分化して手戻りをしやすくする

1.3.3. 3. 承認の欲求

1.3.3.1. 1. 欲求のピラミッドの中で最も高い

1.3.3.2. 2. データベースにおける承認

1.3.3.2.1. 2つの観点

1.3.3.3. ストレージを理解し、そこで起きているイベントがどのように関係しているかを結びつけて理解できること

1.3.3.3.1. 観測可能なこと

1.3.3.3.2. デバッグ可能なこと

1.3.3.3.3. 内部で起こっていることが把握可能なこと

1.3.3.3.4. ツールによる分析が可能なこと

1.3.4. 4. 自己実現の欲求

1.3.4.1. 1. 各組織がデータベースに求めるものも多様である

1.3.4.1.1. 理想のデータ基盤は会社のフェーズ等によって異なってくる

1.3.4.2. 2. データベースにおける自己実現欲求

1.3.4.2.1. データベースが実現したいものの推進力になる

1.3.4.2.2. 開発者の仕事を引き受ける

1.3.4.2.3. 必要に応じてどうやってスケールさせるかについて計画を練っておく

1.3.4.2.4. 課題を解決することを楽しむ

1.4. 3. オペレーションの本質

1.4.1. 1. オペレーションは決して軽視されるものではない

1.4.1.1. システムとソフトウェアに対するスキルと知識の集大成

1.4.1.1.1. 構築

1.4.1.1.2. 運用

1.4.1.1.3. 保守

1.4.2. 2. ネガティブなイメージがついて回る

1.4.2.1. 良いオペレーション文化が育っていないと誰もその会社の製品を顔とは思わない

1.4.2.1.1. オペレーション文化は組織の試金石

1.4.3. 3. オペレーションを行うサービスは無数に存在する

1.4.3.1. サービス

1.4.3.1.1. Google

1.4.3.1.2. AWS

1.4.3.1.3. PagerDuty

1.4.3.1.4. Datadog

1.4.3.2. これらを使いこなす必要がある

1.4.3.2.1. アプリケーションエンジニアも知る必要がある

2. 第2章: サービスレベルマネジメント

2.1. 1. SLO の必要性

2.1.1. 1. SLO を適用することの難しさ

2.1.1.1. 数字を計算する上での問題よりも数字をどのように捉えるかの難しさがある

2.1.2. 2. 指標の反映

2.1.2.1. ユーザー体験、ユーザー満足度を反映しているかどうか

2.2. 2. SLO の指標

2.2.1. 1. レイテンシ

2.2.1.1. 1リクエストに対するレスポンスにかかる時間を表す

2.2.1.2. ユーザー中心主義で考える

2.2.1.2.1. E2E で測定することが望ましい

2.2.2. 2. 可用性

2.2.2.1. システムが利用可能である状態を時間枠に対してパーセンテージで表したもの

2.2.2.2. 利用可能である状態を、どの時間に対して適用するかを定めてはいけない

2.2.2.3. レスポンスタイムと可用性を一緒に定義しなければいけない

2.2.3. 3. スループット

2.2.3.1. 一定時間において正常に処理されたリクエストの割合

2.2.3.1.1. 一般的には秒単位で測定される

2.2.3.2. レイテンシをテストするときにスループットの目標も同時に定めるべき

2.2.3.2.1. レイテンシは閾値を超えるとその後固定値となる場合がほとんど

2.2.3.2.2. 閾値に達した時点でのスループットを知る必要がある

2.2.4. 4. 耐久性

2.2.4.1. ストレージに対して一定の成功率で書き込みができるかどうか

2.2.5. 5. 費用対効果

2.2.5.1. ユーザー行動に対して効果として測定されるべき

2.3. 3. サービス目標の定義

2.3.1. 1. レイテンシ指標

2.3.1.1. ユーザー体験に決定的な影響を与える最重要指標

2.3.1.2. 下限を0に設定することは機能不全を起こしてしまう

2.3.1.2.1. 「リクエストのレイテンシは100msを決して超えないこと」

2.3.1.2.2. 「リクエストのレイテンシは25msから100msの間でなければならない」

2.3.1.3. 収集するのは生データが基本

2.3.1.3.1. データの加工は後でいくらでもできる

2.3.1.3.2. 集計されたデータを集めると算出する計算が違ってしまい間違ったものが出力されてしまう

2.3.1.4. 画面描画

2.3.1.4.1. レイテンシをSLOに記載する際には外れ値を考慮したものにしなければいけない

2.3.2. 2. 可用性の指標

2.3.2.1. MTBF

2.3.2.2. MTTR

2.3.2.3. SLOの可用性評価のポイント

2.3.2.3.1. 障害発生時に回避策があるか?

2.3.2.3.2. 障害の影響範囲が一部だった場合に全停止ではなく別の対応策が可能か?

2.3.2.3.3. ダウンタイムが長引くに連れて1人のユーザーのサービス体験はどのように変化するか?

2.3.2.3.4. 記載すべき可用性

2.3.2.3.5. SLO の表記例

2.3.2.4. ダウンタイムの上限をどうするか

2.3.2.4.1. 数週間お時間軸で捉えた場合、それぞれ1週間あたりの可用性を計算して、その平均が99.9%であること

2.3.2.4.2. 障害が発生した場合、10.08 分間以内に復旧すること

2.3.2.4.3. ダウンタイムとは全体のユーザー数の5%以上に影響を与える事象とする

2.3.2.4.4. 1年に1回は4時間のダウンタイムを許容する、ただし、以下を満たさなければならない

2.4. 4. スループットの指標

2.4.1. 1. サービスが対応可能な最大値にすべき

2.4.1.1. レイテンシや可用性は最大値ではなく一定時間の制限や全体ユーザー数におけるパーセンテージを盛り込まない

2.4.1.2. スループットが上限に達したからといってパフォーマンスや可用性に必ずしも影響を及ぼすわけではない

2.4.1.3. ボトルネックになるケースがある

2.4.1.4. 外れ値による平均の罠などがある

2.5. 5. 費用対効果の指標

2.5.1. 1. かかったコストを何に対しての効果と捉えるべきか

2.5.1.1. コンテンツプロバイダであればページビュー

2.5.1.2. オンラインサービスであればユーザー数

2.5.1.3. 小売業であればトランザクション数

2.5.2. 2. 注意すべき点

2.5.2.1. あれもこれも欲張らない

2.5.2.1.1. ダッシュボード一ページに収まる簡潔なものとする

2.5.2.2. ユーザー中心であること

2.5.2.2.1. ユーザーにとって最も失われてはならないものは何か、を自問する

2.5.2.3. 定期的に見直す

2.6. 6. SLO に基づいた監視とレポート

2.6.1. 1. 可用性の監視

2.6.1.1. 監視の手法

2.6.1.1.1. Real User Monitoring

2.6.1.1.2. 定点モニタリング

2.6.1.2. 可用性監視のポイント

2.6.1.2.1. 可用性が上下するタイミングとその要因を把握

2.6.1.2.2. 時間単位の SLO を遵守できるかどうかを予測

2.6.1.2.3. 以上事態の発生を事前に見抜き、発生する前に対応すること

2.6.2. 2. レイテンシの監視

2.6.2.1. 時間に対しての値であり、SLOで定義した値を満たせているかどうかを判断する

2.6.3. 3. スループットの監視

2.6.3.1. 秒単位でトランザクションを記録する

2.6.4. 4. 費用対効果の監視

2.6.4.1. 定量かできないものもあり困難になることがある

2.6.4.2. 考慮ポイント

2.6.4.2.1. 請求書から読み解く

2.6.4.2.2. インフラ固定費

2.6.4.2.3. 人件費