Harmonic Society
オンライン予約 お問い合わせ
プログラミング

AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング

kento_morota 17分で読めます

「データベースサーバーの運用に手が回らない」「バックアップやアップデートの対応に追われている」――中小企業のIT担当者にとって、データベースの管理は大きな負担です。

AWS RDS（Relational Database Service）を使えば、データベースの構築・バックアップ・パッチ適用といった運用作業の大部分をAWSに任せられます。この記事では、RDSの構築手順からバックアップ戦略、パフォーマンスチューニングまで、実務で役立つ具体的なノウハウを解説します。

AWS RDSとは？マネージドデータベースの価値を理解する

AWS RDS（Relational Database Service）は、リレーショナルデータベースの構築・運用・スケーリングをAWSが管理してくれるマネージドサービスです。

自前でデータベースサーバーを構築する場合、OS・ミドルウェアのインストール、パッチ適用、バックアップ設計、レプリケーション構成など、膨大な作業が必要です。RDSを使えば、これらの運用作業の大部分をAWSが代行してくれます。

対応するデータベースエンジン

エンジン 特徴 推奨用途
Amazon Aurora（MySQL互換） 高性能・高可用性、MySQLの最大5倍の性能 本番環境のメインDB
Amazon Aurora（PostgreSQL互換） 高性能・高可用性、PostgreSQLの最大3倍の性能 地理空間データ、高度な分析
MySQL 広く普及、豊富な情報量 WordPress、既存MySQL移行
PostgreSQL 高機能、標準SQL準拠 複雑なクエリ、拡張性重視
MariaDB MySQL互換、オープンソース MySQL互換環境
SQL Server Microsoft製、Windows連携 .NET環境、Windows系システム
Oracle エンタープライズ向け 既存Oracle移行

新規プロジェクトでは、Amazon Aurora（MySQL互換またはPostgreSQL互換）を推奨します。コストパフォーマンスと可用性のバランスが最も優れています。

RDSとEC2上のデータベースの比較

項目 RDS EC2上に自前構築
パッチ適用 AWS が自動実施 手動で対応
バックアップ 自動バックアップ標準装備 自前で設計・構築
高可用性 Multi-AZ設定のみ レプリケーションを自前構築
スケーリング 数クリックでインスタンスサイズ変更 移行作業が必要
OS・カーネル設定 不可 完全にカスタマイズ可能

RDSインスタンスの構築手順

ここでは、Aurora MySQL互換のインスタンスをAWS CLIで構築する手順を解説します。

ステップ1：サブネットグループの作成

RDSインスタンスは、VPC内のプライベートサブネットに配置するのがベストプラクティスです。

# DBサブネットグループの作成（2つ以上のAZにまたがるサブネットが必要）
aws rds create-db-subnet-group \
  --db-subnet-group-name mycompany-db-subnet \
  --db-subnet-group-description "DB subnet group for production" \
  --subnet-ids '["subnet-0123456789abcdef0","subnet-0123456789abcdef1"]'

ステップ2：パラメータグループの作成

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

# パラメータグループの作成
aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name mycompany-aurora-mysql \
  --db-parameter-group-family aurora-mysql8.0 \
  --description "Custom parameter group for production"

# 文字コードをUTF-8に設定
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name mycompany-aurora-mysql \
  --parameters \
    "ParameterName=character_set_server,ParameterValue=utf8mb4,ApplyMethod=pending-reboot" \
    "ParameterName=collation_server,ParameterValue=utf8mb4_unicode_ci,ApplyMethod=pending-reboot" \
    "ParameterName=time_zone,ParameterValue=Asia/Tokyo,ApplyMethod=pending-reboot"

ステップ3：Auroraクラスターの作成

# Auroraクラスターの作成
aws rds create-db-cluster \
  --db-cluster-identifier mycompany-prod-cluster \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username admin \
  --manage-master-user-password \
  --db-subnet-group-name mycompany-db-subnet \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-cluster-parameter-group-name mycompany-aurora-mysql \
  --backup-retention-period 14 \
  --preferred-backup-window "18:00-19:00" \
  --preferred-maintenance-window "sun:19:00-sun:20:00" \
  --storage-encrypted \
  --deletion-protection

# ライターインスタンスの作成
aws rds create-db-instance \
  --db-instance-identifier mycompany-prod-writer \
  --db-cluster-identifier mycompany-prod-cluster \
  --engine aurora-mysql \
  --db-instance-class db.r6g.large \
  --publicly-accessible false

# リーダーインスタンスの作成（別AZ）
aws rds create-db-instance \
  --db-instance-identifier mycompany-prod-reader \
  --db-cluster-identifier mycompany-prod-cluster \
  --engine aurora-mysql \
  --db-instance-class db.r6g.large \
  --publicly-accessible false \
  --availability-zone ap-northeast-1c

構築時の重要なポイントを解説します。

  • manage-master-user-password：マスターパスワードをSecrets Managerで自動管理
  • backup-retention-period: 14：自動バックアップの保持期間を14日に設定
  • storage-encrypted：保存データの暗号化を有効化
  • deletion-protection：誤削除防止機能を有効化
  • publicly-accessible: false：インターネットからの直接アクセスを禁止

バックアップ戦略の設計

データベースのバックアップは「有事の際の保険」です。RDSには複数のバックアップ手段が用意されています。

自動バックアップとスナップショット

種類 自動バックアップ 手動スナップショット
実行タイミング 毎日自動（指定時間帯） 任意のタイミング
保持期間 1〜35日（設定可能） 明示的に削除するまで保持
ポイントインタイムリカバリ 対応（5分前まで復元可能） スナップショット時点への復元
コスト DB容量と同等まで無料 ストレージ料金が発生

バックアップのベストプラクティス

# 自動バックアップの設定確認
aws rds describe-db-clusters \
  --db-cluster-identifier mycompany-prod-cluster \
  --query 'DBClusters[0].{BackupRetention:BackupRetentionPeriod,BackupWindow:PreferredBackupWindow}'

# 手動スナップショットの作成（リリース前など）
aws rds create-db-cluster-snapshot \
  --db-cluster-identifier mycompany-prod-cluster \
  --db-cluster-snapshot-identifier mycompany-prod-pre-release-20260322

バックアップ運用のポイントは以下の通りです。

  • 自動バックアップの保持期間は14日以上を推奨（デフォルトは7日）
  • バックアップウィンドウはアクセスの少ない時間帯に設定（日本時間の深夜〜早朝）
  • リリース前には手動スナップショットを必ず取得
  • 定期的にリストアテストを実施して、バックアップの有効性を確認

クロスリージョンバックアップ

災害対策（DR）のために、別リージョンにバックアップをコピーすることもできます。

# スナップショットを別リージョンにコピー
aws rds copy-db-cluster-snapshot \
  --source-db-cluster-snapshot-identifier arn:aws:rds:ap-northeast-1:123456789012:cluster-snapshot:mycompany-prod-pre-release-20260322 \
  --target-db-cluster-snapshot-identifier mycompany-prod-dr-20260322 \
  --region ap-southeast-1 \
  --kms-key-id arn:aws:kms:ap-southeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

パフォーマンスチューニングの実践

データベースのパフォーマンス問題は、ユーザー体験に直結します。RDSには、パフォーマンスの分析と改善に役立つツールが用意されています。

Performance Insightsの活用

Performance Insightsは、RDSのパフォーマンスを視覚的に分析できるツールです。データベースの負荷がどのSQL文に起因しているかを簡単に特定できます。

# Performance Insightsを有効にする
aws rds modify-db-instance \
  --db-instance-identifier mycompany-prod-writer \
  --enable-performance-insights \
  --performance-insights-retention-period 731 \
  --performance-insights-kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx

Performance Insightsのダッシュボードで、以下の指標を監視しましょう。

  • DB Load（データベース負荷）：vCPU数を超えていれば、ボトルネックが存在する
  • Top SQL：負荷の高いクエリを特定
  • Wait Events：CPUなのか、I/Oなのか、ロック待ちなのかを識別

スロークエリログの分析

# スロークエリログの有効化（パラメータグループで設定）
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name mycompany-aurora-mysql \
  --parameters \
    "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
    "ParameterName=long_query_time,ParameterValue=1,ApplyMethod=immediate" \
    "ParameterName=log_output,ParameterValue=FILE,ApplyMethod=immediate"

# スロークエリログの確認
aws rds download-db-log-file-portion \
  --db-instance-identifier mycompany-prod-writer \
  --log-file-name slowquery/mysql-slowquery.log \
  --output text

インデックス設計の基本

パフォーマンス問題の多くは、適切なインデックスの欠如が原因です。以下のガイドラインに従ってインデックスを設計しましょう。

  • WHERE句で頻繁に使用するカラムにはインデックスを作成
  • 結合（JOIN）に使用するカラムにはインデックスが必須
  • カーディナリティ（値の種類）が低いカラムのインデックスは効果が薄い
  • 複合インデックスはカラムの順序が重要（左端のカラムから使用される）
-- 実行計画の確認
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND status = 'active';

-- 複合インデックスの作成例
CREATE INDEX idx_orders_customer_status ON orders (customer_id, status);

-- 未使用インデックスの確認（MySQL 8.0以降）
SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'mydb';

高可用性とMulti-AZ構成

本番環境のデータベースには、障害時の自動フェイルオーバーが不可欠です。

Aurora Multi-AZ構成

Auroraはストレージレイヤーが3つのAZにまたがって6つのコピーを保持するため、ストレージレベルでは標準でMulti-AZです。さらに、リーダーインスタンスを別AZに配置することで、コンピュートレイヤーの冗長性も確保できます。

# フェイルオーバーの手動実行（テスト用）
aws rds failover-db-cluster \
  --db-cluster-identifier mycompany-prod-cluster \
  --target-db-instance-identifier mycompany-prod-reader

Auroraのフェイルオーバーは通常30秒以内に完了します。アプリケーション側では、クラスターエンドポイントを使用していれば、フェイルオーバー後も自動的に新しいライターに接続されます。

接続エンドポイントの使い分け

エンドポイント 用途 接続先
クラスターエンドポイント 書き込み操作 常にライターインスタンス
リーダーエンドポイント 読み取り専用クエリ リーダーインスタンス（ラウンドロビン）
インスタンスエンドポイント 特定インスタンスへの接続 指定したインスタンス

アプリケーションからは、書き込みにはクラスターエンドポイント、読み取りにはリーダーエンドポイントを使い分けることで、負荷分散と高可用性を両立させましょう。

RDSのコスト最適化

RDSのコストを最適化するための具体的な施策を紹介します。

インスタンスタイプの選定

必要以上に大きなインスタンスタイプを選ぶと、コストが無駄になります。Performance Insightsでリソース使用率を確認し、適切なサイズに調整しましょう。

  • CPU使用率が常時20%以下：インスタンスのダウンサイジングを検討
  • メモリ使用率が常時90%以上：インスタンスのアップサイジングを検討
  • 開発・検証環境：Graviton（ARM）ベースのインスタンス（db.r7g系）でコスト削減

リザーブドインスタンスの活用

# 現在のRDSインスタンスの料金を確認
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,Class:DBInstanceClass,Engine:Engine}'

1年以上の利用が確定している本番環境のインスタンスには、リザーブドインスタンスを購入することで最大60%のコスト削減が可能です。

Aurora Serverless v2の検討

トラフィックの変動が大きいワークロードには、Aurora Serverless v2が有効です。0.5 ACU（Aurora Capacity Unit）から自動的にスケールし、使った分だけ課金されます。

# Aurora Serverless v2のインスタンスを追加
aws rds create-db-instance \
  --db-instance-identifier mycompany-prod-serverless \
  --db-cluster-identifier mycompany-prod-cluster \
  --engine aurora-mysql \
  --db-instance-class db.serverless \
  --publicly-accessible false

# スケーリング設定
aws rds modify-db-cluster \
  --db-cluster-identifier mycompany-prod-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16

クラウド全体のコスト最適化については、クラウドコスト削減の具体的な方法も参考にしてください。

まとめ｜RDSでデータベース運用の負荷を最小化する

AWS RDSを活用すれば、データベースの構築・バックアップ・パッチ適用といった煩雑な作業をAWSに任せ、アプリケーション開発に集中できます。本記事のポイントを振り返りましょう。

  • エンジン選択：新規プロジェクトにはAurora（MySQL/PostgreSQL互換）を推奨
  • セキュアな構築：プライベートサブネット配置、暗号化、削除保護を有効化
  • バックアップ：自動バックアップの保持期間は14日以上、リリース前には手動スナップショット
  • パフォーマンス：Performance Insightsとスロークエリログで継続的に監視
  • 高可用性：Multi-AZ構成とエンドポイントの使い分けで可用性と負荷分散を実現
  • コスト最適化：適切なインスタンスサイジングとリザーブドインスタンスの活用

データベースはアプリケーションの心臓部です。ECS/Fargateでアプリケーションをコンテナ化し、S3でファイルを管理し、RDSでデータを安全に保管する――この三位一体の構成が、クラウドネイティブなWebアプリケーションの基本形です。

#AWS#RDS#データベース
共有:
無料メルマガ

週1回、最新の技術記事をお届け

AI・クラウド・開発の最新記事を毎週月曜にメールでお届けします。登録は無料、いつでも解除できます。

※ プライバシーポリシーに基づき管理します

関連記事

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説
AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド

AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド
AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化

AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化
AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術

AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術
AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド

AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド
AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法

AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法
AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践

AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践
AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成
AWS Well-Architected Frameworkの実践｜中小企業でも使える設計原則ガイド

AWS Well-Architected Frameworkの実践｜中小企業でも使える設計原則ガイド

AI活用のヒントをお探しですか？お気軽にご相談ください。

まずは話だけ聞いてもらう