【書評】 データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

はじめに

『データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用』（Laine Campbell, Charity Majors 著 / 八木和生 訳 / オライリー・ジャパン）を読みました。

本書は、データベース管理者（DBA）が データベースリライアビリティエンジニア（DBRE） へ進化するためのフレームワークを示した一冊です。特定のDBMSの操作手順を網羅する本ではなく、どのデータベース・どの組織にも通用する考え方と優先順位 を扱っています。

設計・アーキテクチャに関心のあるエンジニアにとって、「データを持つ部分をどう設計し、どう運用し続けるか」を体系的に整理できる内容でした。本記事では、全13章を私なりに整理し、設計の観点で刺さったポイントをまとめます。

この記事は書評であり、本書の内容を要約・再構成したものです。細かい図表や事例は書籍をご確認ください。

こんな方におすすめ

• データベースの設計・運用に関わるバックエンド／インフラ／SRE のエンジニア
• 「DBはDBAに任せている」状態から一歩踏み込みたい方
• SLO・リスク・可観測性といった概念をデータ層に適用したい方
• 分散データベースやデータパイプラインのアーキテクチャ選定に携わる方

本書の全体像

章	テーマ	ひとことで言うと
1	イントロダクション	DBREの指針と欲求段階説
2	サービスレベルマネジメント	SLOを定義し、測る
3	リスクマネジメント	不確実性を評価し、優先順位をつける
4	オペレーションの見える化	OpVizで「何が起きているか」を把握する
5	インフラストラクチャエンジニアリング	物理・仮想・コンテナ・DBaaSの選択
6	インフラストラクチャマネジメント	インフラのコード化と自動化
7	バックアップとリカバリ	データを失わないための設計
8	リリースマネジメント	CI/CDとデータベース変更
9	セキュリティ	盗難・破壊からデータを守る
10	ストレージ、インデックス、レプリケーション	データの格納と複製の仕組み
11	データストアフィールドガイド	データベースの特性比較
12	さまざまなデータアーキテクチャ	複数DBを組み合わせた構成
13	実践DBRE	組織にリライアビリティ文化を根づかせる

前半（1〜9章）は 運用（Ops）寄り、後半（10〜12章）は データそのものの設計 という二部構成です。著者の主張は一貫していて、「よいDBREになるには、まずよいエンジニアであり、よいリライアビリティエンジニアであること」という立場です。

1章：DBREの指針と欲求段階説

5つの指針

1章では、DBREの基本姿勢が5つの指針として示されます。

1. データを守れ：バックアップ・リストアの定期テスト、権限設計、セキュリティ監査など
2. 周囲を巻き込め：DBREは希少。標準化・自動化でチームを支える
3. 骨折り仕事（toil）を減らせ：繰り返しの手作業は自動化する
4. サーバーの家畜化は時代の流れ：データベースだけを「ペット」扱いしない
5. 分業制に囚われるな：インフラ・設定・スキーマもすべてソフトウェアの一部

特に印象的だったのは「ペットと家畜」の比喩です。サーバーに名前をつけて手厚く世話をする時代から、壊れたら捨てて作り直す時代に移っています。データベースは最後に残ったペットでしたが、「データを持つから特別」という理由で手作業を温存すると、属人化と疲弊を招きます。

マズローの欲求段階説をDBに当てはめる

本書の特徴的なフレームワークが、マズローの欲求段階説をデータベースの成熟度に重ねた考え方です。

自己実現  ── 開発の障害にならず、推進力になる
承認      ── 観測でき、デバッグでき、分析できる
愛と帰属  ── データをエンジニアリングの一級市民にする
生存と安全 ── バックアップ・レプリケーション・フェイルオーバー

下の段が満たされていないのに、上の段に手を出さない。これが優先順位づけの軸です。バックアップすら不確かな状態で、動的にシャードを追加するスクリプトを書くのは順序が逆だ、という指摘は耳が痛いところです。

また、スケールの4パターン（垂直・水平・機能パーティショニング・シャーディング）を早い段階から意識しておくべき、という点も設計観点で重要です。

2章：サービスレベルマネジメント

サービスが満たすべき運用レベルを最初に決める、という章です。

SLOの指標

指標	要点
レイテンシ	ユーザー視点のエンドツーエンドで測る
可用性	時間枠に対するパーセンテージ。レイテンシとセットで定義する
スループット	レイテンシと必ず併せて評価する
耐久性	書き込みの成功率。ストレージ／DBで特に重要
費用対効果	1ページビューや1購入あたりのコストで捉える

平均の罠

レイテンシは正規分布にならず、外れ値を含むロングテールになります。そのため 平均・中央値・標準偏差は事実を歪める と本書は強調します。

• 監視では 生データを収集 する（平均の平均は誤差が増える）
• SLOは「リクエストの99%が25〜100ミリ秒」のように パーセンタイルで定義 する
• 下限も設ける（これ以上速くしてもユーザーに届かないため）

可用性の「数字」の読み方

99.9%の可用性は、年間で約526分（約9時間）のダウンタイムを許容する計算になります。ただし、526分の停止が1回なのか、1分の停止が526回なのかでユーザー体験はまったく違います。そこで MTBF（平均故障間隔）と MTTR（平均修復時間） の両面で考えます。

「障害を起こさないシステム」より「障害から素早く回復するシステム」を目指す、というのが本書の一貫した立場です。めったに落ちないシステムは、落ちたときの対応が誰にも身についておらず、かえって脆いというわけです。

SLOは「達成できたかの採点表」ではなく、達成を妨げるリスクを早めに見つけるための道具 として扱う、という考え方も腹落ちしました。

3章：リスクマネジメント

SLO違反の原因となる不確定要素を、どう評価し、どう扱うかの章です。

リスク評価のサイクル

1. リスクを洗い出す
2. 発生可能性と影響度を評価する
3. 分類する
4. 低減策を考える
5. 優先順位をつける
6. 監視と対応策を実装する
7. 繰り返す

人と集団にまつわるリスク

技術的なリスクだけでなく、人間側の傾向も明示されているのが特徴です。

• ありふれたリスクを軽視する：珍しい大障害に備える一方、ディスク残量の逼迫には無策
• 極端な楽観主義：「3本同時にディスクが壊れることはない」と思い込む
• アラート疲れ：不要なアラートが対応者を消耗させる
• 集団極性化・リスク転移・意思決定の転嫁：組織としての判断の偏り

起こりやすさ × 影響度のマトリクス

起こりやすさを「ほぼ確実（50%以上）」〜「まず起きない（5%以下）」に、影響度を「甚大」〜「軽微」に分け、マトリクスで 許容しない／高リスクとして許容／中リスク／許容 を判断します。

具体例として、書き込みサーバー障害に対して自動フェイルオーバーを採用し、テスト環境で何度も切り替えを試して時間を計測し、最終的に30秒以内を目指す流れが紹介されています。ここでも「最初から完璧を目指さず、小さく始めて改善を回す」姿勢が貫かれています。

4章：オペレーションの見える化（OpViz）

可観測性の章です。可視化を BI（ビジネスインテリジェンス）のように扱う という発想が出発点です。

押さえたいポイント

• 動的に入れ替わるクラスタでは、メトリクスを ホスト名ではなくロール単位 で蓄積する
• 重要なメトリクスは 高分解能（秒以下） で収集する。1分平均ではスパイクが消える
• 収集間隔の種類は増やしすぎない（5種類以下）
• 最初にSLOへ直結するもの（レイテンシ・可用性・コールレート・利用率）から見る
• ノイズを増やさない。人間の手が必要なものだけ アラートにする

メトリクスの4タイプ

タイプ	内容
カウンタ	累積する値
ゲージ	増減する現在値
ヒストグラム	分布の把握
サマリ	時間枠単位の集計

「サバイバルキット」の3問

最低限の監視として、次の問いに答えられる状態を目指します。

1. データは安全か（レプリカ数、レプリケーション状態、直近バックアップ）
2. サービスは落ちていないか（エンドツーエンドのヘルスチェック）
3. 顧客の体験に痛みが出ていないか（レイテンシとエラー率）

ヘルスチェック自体がDBの負荷になって障害を起こす「ヘルスチェック地獄」のエピソードは、実務でも起こり得る話で印象に残りました。

データベース内部の見える化

接続レイヤ（利用率・飽和・エラー）、コミット／ジャーナル、レプリケーション、メモリ構造、ロックと並行性、オブジェクトのサイズ、クエリまで、層ごとに見るべき指標が整理されています。レプリケーションについては、遅延・失敗・ドリフト（気づかないうちに内容がズレる） の3段階で考える視点が有用です。

5章：インフラストラクチャエンジニアリング

データベースを動かす基盤の選択肢を比較する章です。

選択肢	長所	留意点
物理サーバー	リソースを専有できる	調達・運用コスト、柔軟性
仮想化	柔軟・自動化しやすい	リソース競合、可視化の限界
コンテナ	再現性・軽量	永続データの扱い
DBaaS	運用負荷の軽減	ブラックボックス化、依存

DBaaSについては、「使えば運用から解放される」わけではなく、適切に使いこなすための知識がむしろ必要 と述べています。エンジン選定、データモデル、権限、セキュリティ、キャパシティ計画といった判断は依然としてDBREの仕事です。さらに、DBaaSから別環境へ移行できる余地を残しておくことも推奨されています。

6章：インフラストラクチャマネジメント

インフラのコード化（Infrastructure as Code）を扱う章です。

• コード、設定、OSイメージ、DBバイナリのバージョンを すべてバージョン管理 する
• アプリのリポジトリとインフラのリポジトリが分断されないようにする
• 構築したインフラが意図通りかを テストとコンプライアンスチェック で確認する
• サービスカタログや開発環境（サンドボックス）まで含めて再現性を担保する

ここでの狙いは、手作業の繰り返しを排除し、同じものを何度でも正確に作れる 状態にすることです。開発環境も本番と同じイメージ・同じ設定で用意すれば、コミット前に安心して変更を試せます。

7章：バックアップとリカバリ

本書の中でも、気持ちが引き締まる章です。

バックアップとリカバリは退屈な作業として扱われがちだが、データこそ最重要であり、VIP扱いにすべき。

基本の分類

• 物理 vs 論理：ファイルそのものか、抽出したデータか
• オンライン vs オフライン
• フル / インクリメンタル / 差分

リカバリ戦略の考え方

障害を「想定内／想定外」「影響範囲」「重大度」で分類し、次の4つの計画で組み立てます。

1. 問題の発見
2. 階層化ストレージ
3. リカバリに役立つツール
4. テスト

ストレージの特性ごと（高性能オンライン、低性能オンライン、オフライン、オブジェクトストレージ）に向き不向きがあり、適材適所で組み合わせる のが肝です。

リストアできないバックアップは、バックアップではありません。継続的にリカバリをテストし、メトリクスを追跡する運用が必須です。

章末の「いつも心にリカバリを」という言葉が、本書全体を貫くメッセージの一つだと感じました。

8章：リリースマネジメント

データベース変更を、CI/CDの流れの中でどう安全に扱うかの章です。

門番から教育者へ

かつてはDBAが変更の最終確認者として「門番」を務めていました。しかしデプロイが高頻度になった今、その体制ではDBAがボトルネックになり、燃え尽きます。そこで DBRE は次の役割にシフトします。

• データベース情報の キュレーター
• データベースに関する議論の 触媒
• 部門間の壁を取り払う存在

テストとデプロイ

• コミット後の自動テスト
• 完全なデータセットを使ったテスト
• ダウンストリームへの影響確認
• マイグレーションとバージョン管理、影響分析

自動化については慎重な姿勢も示されています。頻繁に行うものは自動化するべきですが、失敗時の影響が大きいものは、フォールバックと迅速なリカバリ手段が整ってから 進めるべきだとされています。

9章：セキュリティ

データはもっとも狙われる資産です。本章は「守る対象」と「脅威」を整理します。

セキュリティの目的

• 盗難からの保護
• 意図的な破壊からの保護
• 意図しない破壊からの保護（うっかり事故を防ぐ）
• データを外部に晒さない
• コンプライアンスと監査への対応

「悪意ある攻撃者から守るだけがセキュリティではない」という点は、1章の「ガードレール」の考え方とつながります。

脅威モデリングと対策

• 脅威の分類にSTRIDE、リスク評価にDREADを用いる
• DoS、SQLインジェクション、ネットワークや認証プロトコルの弱点への備え
• 機密性に応じたデータ分類
• 転送中・保存中・ファイルシステム上のデータの暗号化

暗号化の検討では、データ分類・暗号スイートの標準・鍵のローテーションと管理・自動侵入テストといった項目が、チェックリストとして提示されています。ここでもDBRE単独ではなく、InfoSec・SWE・Opsとの協力 が前提です。

10章：ストレージ、インデックス、レプリケーション

ここから後半、データそのものの設計に入ります。

ストレージの基本

• 行はブロック（ページ）単位で読み書きされる。1行読むだけでもブロック単位のI/Oが発生する
• DBのブロックサイズとファイルシステムのブロックサイズの不整合はI/Oの無駄になる
• B-tree系とLSM（ログ構造マージツリー）では書き込み・読み込み特性が異なる
• インデックスは検索を速くする代わりに、書き込みと容量のコストを払う

レプリケーションの3方式

方式	特徴
単一リーダー	構成が単純。書き込みの順序が保たれる
複数リーダー	書き込み拠点を分散できるが、衝突解決が必要
リーダーなし	耐障害性が高いが、結果整合性を前提にする

リーダーなし方式では、ヒンテッド・ハンドオフ、リードリペア、反エントロピー（マークルツリーなど）が整合性を支える仕組みとして登場します。アプリケーションが書き込み順序に鈍感で、古い読み込みを許容できるなら強力な選択肢になる、という整理でした。

11章：データストアフィールドガイド

データベースを自然界の動植物にたとえ、特性で分類する章です。

アプリ開発者の視点

• データモデル：リレーショナル／キーバリュー／ドキュメント／グラフ
• トランザクション：ACIDと分離レベルの違い
• BASE：可用性を重視した考え方

アーキテクト・運用の視点

• ストレージエンジン（B-tree か LSM か）
• CAP定理と、一貫性・可用性・レイテンシのトレードオフ
• 障害を局所化し、処理能力（yield）を保つために結果の完全性（harvest）を減らすという割り切り

「新しいクールなDBを使いたい」という要望に対して、特性とトレードオフを根拠に議論するための物差しを得られる章です。

12章：さまざまなデータアーキテクチャ

単一のDBだけで完結するサービスは稀であり、複数のコンポーネントを組み合わせます。

主なコンポーネント

• フロントエンドデータベース（OLTP）
• データアクセスレイヤ
• データベースプロキシ
• イベント／メッセージシステム
• キャッシュ・メモリストア

アーキテクチャパターン

• Lambda / Kappa：バッチとストリームの扱い方
• イベントソーシング：状態ではなく変更イベントを保存する
• CQRS：書き込み（コマンド）と読み込み（クエリ）のモデルを分離する

CQRSはイベントソーシングとセットでなくてもよく、ビューやフラグを使った 軽量な導入 も可能だと述べられています。複雑さと運用コストの沼にはまらないよう、データのライフサイクルを理解してから構成を選ぶ、という姿勢です。

最悪なのはデータの整合性を失うことです。アーキテクチャの複雑さと引き換えに、これだけは失ってはいけない、というのが本章の結論です。

13章：実践DBRE

最終章は、技術ではなく 文化 の話です。

リライアビリティ文化の要素

• 非難なしのポストモーテム
• 繰り返し作業の自動化
• 構造化された合理的な意思決定

チームの壁を破る

孤高のDBAではなく、チーム横断で貢献する技術顧問を目指します。

• アーキテクチャの意思決定プロセスに早期から参加する
• データドリブンに意思決定する
• データ整合性の問題を集め、リカバリの仕組みの必要性を示す

そして、変化は一気には起きません。小さく始めて信頼を積み上げ、波紋を広げていく というのが著者の結びです。

本書から得た学び

全体を通して、特に設計・アーキテクチャの観点で持ち帰ったポイントは次の4つです。

1. 「回復できること」を設計の中心に置く

障害をゼロにするより、MTTRを縮め、回復を日常業務にする。ドキュメント、自動復旧、定期的なリストア訓練が、結果的に高い信頼性につながります。

2. 数字は「ユーザー体験」から逆算する

SLOはユーザーにとって意味のある指標で定義し、平均ではなく分布で見る。平均が良くても、外れ値のユーザーは不幸なままです。

3. 優先順位は下から積み上げる

バックアップ・レプリケーション・フェイルオーバーが先、可観測性や最適化はその後。今の段階で何をやるべきか を見誤らないための地図として、欲求段階説は優れています。

4. ガードレールで安全に速く動く

事故を起こさない仕組み（レビュー、事前テスト、段階的適用、切り戻し）を用意し、メンバーが怖がらずにデータベースへ変更を加えられるようにする。教育と自動化で、DBREがボトルネックにならない体制をつくります。

気になった点・読む際のヒント

• 技術的な具体例（Cassandra、MySQL、PostgreSQL、MongoDBなど）は刊行時点のものが中心です。製品の細部は最新ドキュメントで補完しながら読むのがおすすめです。
• ツール名の網羅が目的の本ではないため、考え方を自分の環境に置き換える 読み方が向いています。
• 前半は運用寄りで、やや抽象度が高く感じるかもしれません。10章以降を先に読んで、必要になった章に戻る読み方も有効だと思います。

まとめ

『データベースリライアビリティエンジニアリング』は、データベースを 「守る対象」から「設計し、進化させる対象」 へと捉え直させてくれる一冊でした。

• SLOとリスクで「何を守るか」を決める
• 見える化と自動化で「どう守るか」を仕組みにする
• バックアップ・セキュリティ・リリースで「失わない」「壊さない」を担保する
• ストレージ・レプリケーション・アーキテクチャの知識で「どう作るか」を選ぶ
• 文化づくりで「続ける」

データ層の設計や運用に責任を持つ方はもちろん、アプリケーション側のエンジニアにとっても、データベースとの付き合い方を見直すきっかけになるはずです。気になった方はぜひ手に取ってみてください。

参考

• Laine Campbell, Charity Majors 著 / 八木和生 訳『データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用』オライリー・ジャパン
• 書籍紹介ページ（オライリー・ジャパン）