『High Performance MySQL 第4版』を読んだ内容を章ごとにまとめています。
この章では「監視」と「信頼性エンジニアリング（SRE）」について整理しています。
MySQLの監視を「CPUやディスクだけを見る作業」から、「ユーザー体験を維持するための仕組み」として再定義していく章です。
第2章 監視と信頼性エンジニアリング
概要
本章では、MySQLを安定して運用するための「監視」の考え方を整理する。
特にSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）の視点から、SLI（サービスレベル指標） と SLO（サービスレベル目標） を用いて、システムの状態をどのように測り、改善していくかを解説する。
監視の目的は単なる「エラー検出」ではなく、お客様が快適に使える状態を維持すること にある。
SREの考え方とDBAへの影響
目的
SREの導入により、運用担当者（DBA）は「感覚的な判断」ではなく、「原則に基づく信頼性管理」を行うようになった。
SLOを明確に定めることで、どこまでを「許容できる障害」とし、どこからを「改善すべき問題」とするかの線引きが可能になる。
判断のための問い
- どの機能が絶対に止まってはいけないのか
（例：ECサイトの購入処理） - どの機能は一時的に止まっても致命的ではないのか
（例：レコメンド機能） - 障害が発生した場合、どの程度の時間で復旧できるべきか
（例：フェイルオーバー完了まで数分以内など）
SREでは「100%稼働」は非現実的であると考える。
重要なのは「どの程度の失敗を許容できるか」をあらかじめ定義することであり、それが SLO（サービスレベル目標） である。
信頼性エンジニアリング登場前の運用スタイル
従来の運用（Ops）
SREが登場する以前（2010年代前半まで）は、障害が起きてから対応する「反応的（Reactive）」な運用が主流であった。
監視対象は主にCPU・メモリ・ディスクといったサーバー資源に偏っており、ユーザー体験の視点はほとんど考慮されていなかった。
特徴
- 障害発生後に手動で対応するスタイル
- 監視は死活監視中心（ping応答など）
- SLOや可用性目標は明確に定義されていない
- 開発と運用が分離し、責任が分断される（DevとOpsの壁）
SREによる変化
SREは「運用をエンジニアリングとして扱う」という発想を導入した。
運用を定量的に評価し、信頼性を測定・改善・自動化のサイクルで管理する。
| 観点 | 旧来のOps | SRE |
|---|---|---|
| アプローチ | 手動対応中心 | 自動化とデータ駆動 |
| 目標 | 障害を減らす | 信頼性を定義し維持する |
| 監視項目 | CPU/メモリ/ディスク | SLI（可用性・レイテンシ・エラー率） |
| 判断基準 | 経験・勘 | SLOに基づく意思決定 |
| 組織文化 | 開発と運用が分断 | DevOpsとして協働 |
監視の基本指標（SLIとSLO）
1. 可用性（Availability）
- サービスが利用可能な時間の割合を測定する
- 外形監視（
SELECT 1の応答や、実際のデータ読み書き）で確認する
2. レイテンシ（Latency）
- クエリの実行速度を測定する
- サーバー内部の計測だけでなく、アプリケーション側で「ユーザーが体感する遅延」も計測する
- ツール例：Datadog、SolarWinds DPM、Percona Monitoring and Management（PMM）
3. エラー率（Errors）
- エラーの総数や割合を監視する
- 短期間でのエラー率上昇は障害の兆候とみなす
代表的な指標
Lock wait timeout：ロック競合の増加を示すAborted connections：接続不安定やリトライ過多を示す
可用性とパフォーマンス監視の実践
可用性
Threads_runningが増加し続けている場合は、クエリが滞留している可能性が高いmax_connectionsに近づいている場合は、接続過多によるパフォーマンス低下を警戒する- CPUコア数を超えるスレッド数が続くと危険である
レイテンシ
- 遅いクエリは、ユーザー体験の低下を引き起こす
- DatadogやPMMなどのメトリクスツールでクエリ実行時間を継続的に可視化する
- 遅延の原因追跡には、分散トレーシング（HoneycombやLightstepなど） が有効である
壊れる前に気づくための監視（プロアクティブ監視）
目的
トラブル発生後に対応するのではなく、「壊れる前に異常を検知する」ことを目的とする。
主な項目
I/Oとディスク
IOwaitやIOutilの継続的な高止まりは、全表走査や非効率クエリの可能性- ディスク増加率を監視し、閾値を超える前に通知を出す
IOwaitとIOutilの詳細
IOwait はCPUがディスクI/Oを待機している時間の割合を示す。
- IOwaitが高いほどCPUは「待っている」状態であり、I/O性能がボトルネックであることを示す。
- 高IOwaitはメモリ不足・スワップ・バックアップ処理の競合などが原因になる。
IOutil はストレージ装置がどれほど稼働しているかを表す指標である。
- 100%に近い場合は、ディスクが常にリクエストを処理中であり、I/Oが飽和している。
- 改善策としては、インデックス最適化・クエリ修正・ディスク性能向上などが挙げられる。
両者を組み合わせて監視することで、CPUが待っているのか、ディスクが詰まっているのかを見極めることができる。
バックアップとリストア
- リストアにかかる実際の時間を計測しておく
- 障害時に必要な復旧時間を正確に把握できる
接続数の変化
- 時間帯やトラフィックの傾向に応じて、接続数を定期的に確認する
- 増加傾向が続く場合は、設定や接続プールを見直す
AUTO_INCREMENTの枯渇
- ID列の最大値に近づいていないか監視する
information_schemaで残量を確認、またはPMMの-collect.auto_increment.columnsで可視化
長期的なパフォーマンス測定
ビジネスリズムの理解
システム負荷は季節やイベントで変動する。
ECサイトであれば年末商戦、保険業界なら加入受付期間など、ピーク時でもSLOを維持できる設計が求められる。
平均値ではなく分布を見る
- 平均値ではピーク時の問題を見逃す可能性がある
- パーセンタイル（p95/p99） を用いて、上位遅延の傾向を把握する
継続的なトレンド分析
- 短期的な指標と長期的な傾向を両方見ることで、拡張・最適化の判断がしやすくなる
SLOを活かした設計判断
SLOは単なる監視指標ではなく、設計やスケーリング判断の基準でもある。
- SLOを維持できない場合は、データベースの分割（シャーディング）を検討する
- 機能ごとにサーバーを分離するなど、負荷分散の再設計を行う
- メトリクスとSLOの両方を見て、投資・改善の優先度を決定する
まとめ
- SLI/SLOは固定ではなく、サービス成長や利用変化に応じて定期的に見直すべきである
- 問題検出だけでなく、予防的な監視（I/O、接続数、AUTO_INCREMENT、バックアップ）に注力することが重要
- まずは 可用性・レイテンシ・エラー率 の3つに焦点を当てる
- 監視データをもとに、信頼性を「数字」で説明できる状態を目指す
業務での活かし方
- SLOをチーム共通の指標として使う
- 「何を優先すべきか」の判断を数値で共有できる
- 監視ダッシュボードの整備
- DatadogやPMMで主要指標を一画面に集約する
- 予兆検知の仕組み化
- 接続数やI/O利用率の異常をアラート化し、障害発生前に対応できるようにする
- 長期データの活用
- パフォーマンス傾向を分析し、次期インフラ設計や容量計画に反映する
🔙 前回：第1章 MySQLアーキテクチャ
→ tech-high-performance-mysql-ch01
コメント