【AWS】RDS（PostgreSQL）の本番運用で知っておくべきこと — バックアップ、スケーリング、トラブル対応

RDSはマネージドサービスとはいえ、運用で気をつけるべきポイントは多くあります。特にPostgreSQLは設定パラメータが豊富で、デフォルトのままでは本番環境に適さない場合があります。この記事では本番RDSの運用ノウハウをまとめます。

パラメータグループのチューニング

デフォルトのパラメータグループは変更できないため、必ずカスタムパラメータグループを作成して適用します。

resource "aws_db_parameter_group" "postgres" {
  family = "postgres16"
  name   = "production-postgres16"

  # スロークエリログの有効化
  parameter {
    name  = "log_min_duration_statement"
    value = "1000"  # 1秒以上のクエリをログ出力
  }

  # 接続数の上限
  parameter {
    name  = "max_connections"
    value = "200"
  }

  # shared_buffersはインスタンスメモリの25%が目安
  parameter {
    name  = "shared_buffers"
    value = "{DBInstanceClassMemory/4}"
  }

  # work_mem: ソートやハッシュ結合に使うメモリ
  parameter {
    name  = "work_mem"
    value = "65536"  # 64MB
  }
}

バックアップ戦略

RDSの自動バックアップ（スナップショット）は保持期間を最大35日に設定できます。本番環境では最低でも14日は確保しましょう。加えて、リージョン障害に備えてクロスリージョンバックアップも検討すべきです。

ポイントインタイムリカバリ（PITR）を使えば、過去5分前までの任意の時点にデータベースを復元できます。ただし復元先は新しいインスタンスになるため、エンドポイントの切り替え手順もあらかじめ準備しておきましょう。

Performance Insightsの活用

Performance Insightsを有効にすると、どのSQLがリソースを消費しているか一目で分かります。Top SQLビューで待機イベント別にボトルネックを特定し、EXPLAIN ANALYZEで実行計画を確認する流れが定石です。

メンテナンスウィンドウの設計

RDSのマイナーバージョンアップやOSパッチはメンテナンスウィンドウ中に適用されます。Multi-AZ構成であればフェイルオーバーにより数十秒のダウンタイムで済みますが、それでもアクセスの少ない深夜帯に設定するのが安全です。

まとめ

RDSは「マネージド」ですが「放置していい」わけではありません。パラメータチューニング、バックアップ設計、Performance Insightsによる監視、メンテナンスウィンドウの管理など、やるべきことは多くあります。これらを最初に設計しておくことで、安定した運用を実現できます。