運用¶
データベース運用では、接続できること、速いこと、戻せること の3点をまず押さえる。
実務でまず見るポイント¶
- どの DB エンジンを使っているか
- 接続先ホスト / ポート / 認証情報は何か
- スキーマ変更はどう管理しているか
- バックアップと復旧方法はあるか
- 負荷が高いときに CPU / メモリ / I/O のどこが詰まるか
- 読み込み主体か、書き込み主体か
- レプリカを使っているか
- メンテナンス時間やフェイルオーバー影響はどこに出るか
実務での扱い方¶
- アプリ設定に DB 接続情報を入れる
- マイグレーションでスキーマ変更を管理する
- バックアップやスナップショットを取る
- メトリクスやスロークエリを監視する
- 接続数の上限を意識する
- バッチ処理や大量更新の影響を見る
障害や運用でよく見る論点¶
接続できないセキュリティグループ、DNS、認証情報、証明書、接続上限を確認する遅いスロークエリ、インデックス、CPU、ストレージ IOPS、ロック待ちを確認する容量不足ディスク使用量、不要データ、ログ肥大化、自動拡張設定を確認する切り替わったフェイルオーバー時に接続先、DNS キャッシュ、アプリの再接続実装を確認する
バックアップと可用性¶
バックアップ定期取得して、必要時点へ戻せるようにするリードレプリカ読み込み分散や参照系の負荷軽減に使うマルチAZ障害時の継続性を高める
バックアップは「取っているか」より「戻せるか」が重要。
プラクティス集¶
接続まわり¶
- DB へ直接つなぐ前に、接続元、ポート、認証情報、名前解決を整理する
- アプリごとに接続ユーザーを分け、権限を最小化する
- 接続数上限を意識し、アプリ側でコネクションプールを使う
- 長時間アイドル接続が増え続けていないかを見る
スキーマ変更¶
- 手作業変更ではなく、マイグレーションで管理する
- 本番前に、追加・変更・削除の影響範囲を確認する
- 大きいテーブルへの
ALTER TABLEはロックや時間を意識する - 破壊的変更は一度にやらず、段階的に進める
クエリと性能¶
- 遅い SQL を先に特定してから対処する
- まずは
WHEREJOINORDER BYに注目する - インデックスは「検索が速くなる代わりに更新が重くなる」と理解する
SELECT *を常用せず、必要な列だけ取る- 一括更新や大量削除は、分割実行を検討する
バックアップと復旧¶
- バックアップ取得だけでなく、復元手順まで確認する
- 復旧目標として
どこまで戻すかとどれくらいで戻すかを意識する - 定期的にスナップショットや復元テストの結果を残す
- 障害時に必要な接続先変更やアプリ再起動手順も整理する
監視¶
- CPU、メモリ、ストレージ、接続数、レイテンシを見る
- スロークエリを継続的に確認する
- 急な負荷増加がバッチ、障害、アプリ変更のどれに起因するか切り分ける
- 監視は DB 単体ではなく、アプリ側のタイムアウトやリトライ設定も合わせて見る
セキュリティ¶
- public 配置を避け、private サブネットに置く
- 接続元をセキュリティグループで絞る
- 認証情報はコードへ直書きせず、Secrets Manager などで管理する
- 暗号化 at rest / in transit を確認する
障害対応¶
接続不可遅延容量不足フェイルオーバーの4系統で切り分ける- 変更直後の障害では、アプリ変更と DB 変更を両方疑う
- DB ログ、アプリログ、メトリクスの時刻をそろえて確認する
- まずは原因特定より影響範囲の把握を優先する
メモ¶
- 運用では
設計の美しさより戻せるか止まらないかが重要 - SQL の理解と監視の理解を分けずに見た方が実務では役立ちやすい