AWS RDS入門｜マルチAZ・リードレプリカ設定で可用性と拡張性を向上させる

AWS RDSでデータベースの可用性と拡張性を飛躍的に向上させるには、マルチAZ配置とリードレプリカの活用が必須です。障害発生時の自動フェイルオーバーを実現するマルチAZ配置と、読み取り負荷を分散するリードレプリカを適切に設定することで、本番環境の安定稼働を保証します。本記事では、AWS RDSの基本設定から始まり、具体的なマルチAZ配置の手順、リードレプリカの構築方法、そして運用時のベストプラクティスまで、実務で即座に活用できる知識を網羅的に解説します。AWS RDSを初めて触る方でも、このガイドを読み終える頃には、プロダクション環境に適した堅牢なデータベースアーキテクチャを構築できるようになります。

目次

AWS RDSとは何か？メリットと主要機能

AWS RDS（Relational Database Service）は、クラウド上でリレーショナルデータベースを簡単に構築・運用できるマネージドサービスです。従来のオンプレミスデータベースと比較して、運用負荷の大幅な削減とコスト効率の向上が実現されています。RDSが提供する主なメリットと機能を理解することで、なぜ多くの企業がAWS RDSを採用しているのかが明確になります。

RDSが提供する主要なメリット

AWS RDSを利用することで得られる具体的なメリットは以下の通りです。

メリット具体的な内容実務への影響
自動バックアップ毎日自動的にスナップショットを作成し、指定した保持期間（最大35日間）で保存データ損失リスクの大幅低減
ソフトウェアパッチ適用データベースエンジンの自動パッチ適用を実施セキュリティ脆弱性への迅速な対応
スケーリング垂直スケーリング（インスタンスタイプ変更）と水平スケーリング（リードレプリカ）が可能負荷に応じた柔軟なリソース調整
高可用性構成マルチAZ配置により、障害発生時の自動フェイルオーバーを実現ダウンタイムの最小化
モニタリングとアラートCloudWatchとの統合により、パフォーマンスメトリクスをリアルタイム監視問題発生時の早期検知と対応

サポートされているデータベ…

AWS RDSでは、複数のリレーショナルデータベースエンジンをサポートしています。用途に応じて最適なエンジンを選択できます。

データベースエンジン主な用途特徴
Amazon Aurora高性能・高可用性が求められるアプリケーションMySQL/PostgreSQL互換で、5倍のスループットを実現
MySQLオープンソースの汎用データベースコスト効率に優れ、幅広い用途に対応
PostgreSQL高度な機能が必要なアプリケーションJSONサポートや地理空間データなど豊富な機能
MariaDBMySQL互換でパフォーマンスを重視MySQLよりも高速な処理が可能
Oracle Database企業システムやミッションクリティカルなアプリケーションOracle固有の機能をフル活用可能
SQL ServerWindows環境や.NETアプリケーションMicrosoft製品との高い親和性

RDSの料金体系とコスト最適化

AWS RDSの料金は、以下の要素で構成されます。

  • DBインスタンス料金：稼働時間に応じた課金（秒単位）
  • ストレージ料金：プロビジョンドIOPS SSD（io1/io2）はGB単位、汎用SSD（gp2/gp3）はGB+IOPS単位
  • データ転送料金：リージョン間のデータ転送に応じた課金
  • バックアップストレージ料金：自動バックアップの保存期間に応じた課金

コスト最適化のための具体的な戦略として、以下のポイントがあります。

  1. 適切なインスタンスタイプの選択：ワークロードに応じたサイズを選定（例：t3.microからr5.2xlargeまで）
  2. ストレージタイプの最適化：汎用SSD（gp3）はコストパフォーマンスに優れ、io1/io2は高いIOPSが必要な場合に適切
  3. マルチAZ配置の検討：高可用性が求められる場合は必須だが、開発環境ではシングルAZでコスト削減
  4. リードレプリカの活用：読み取り負荷が高い場合はリードレプリカを活用し、メインインスタンスの負荷を軽減
  5. 予約インスタンスの活用：1年または3年の予約により最大75%のコスト削減が可能

実際のコスト試算例として、MySQLをシングルAZで運用する場合、t3.mediumインスタンス（4vCPU、4GiB RAM）で月額約30米ドル程度から利用できます。一方、マルチAZ配置の場合は約2倍のコストがかかりますが、高可用性を確保できます。

マルチAZ配置がもたらす可用性向上の仕組み

AWS RDSのマルチAZ配置は、データベースの可用性を飛躍的に向上させる機能です。障害発生時の自動フェイルオーバーを実現し、ダウンタイムを最小限に抑えることができます。マルチAZ配置の仕組みと具体的なメリットを理解することで、なぜこれが重要なのかが明確になります。

マルチAZ配置の基本概念

マルチAZ配置では、プライマリDBインスタンスとスタンバイDBインスタンスが異なるアベイラビリティーゾーン（AZ）に配置されます。以下は、その基本的な構成です。

  • プライマリAZ：実際の読み書き処理を実行するDBインスタンス
  • スタンバイAZ：プライマリAZと同期されたスタンバイDBインスタンス
  • 同期レプリケーション：プライマリからスタンバイへのデータ同期が常に行われる
  • 自動フェイルオーバー：プライマリAZで障害が発生した場合、スタンバイAZが自動的にプライマリに昇格

この構成により、AZ障害が発生してもサービスを継続できる高可用性が実現されます。

マルチAZ配置のメリット

マルチAZ配置を導入することで得られる具体的なメリットは以下の通りです。

DBエンジンのアップグレードやパッチ適用時に、フェイルオーバーが発生しサービスへの影響を最小化
メリット具体的な内容実務への影響
高可用性AZ障害時の自動フェイルオーバーにより、99.95%の可用性を実現サービス停止リスクの大幅低減
データ durability自動バックアップと同期レプリケーションにより、データ損失リスクを最小化災害時のデータ回復が迅速かつ確実
メンテナンス時の影響軽減計画的なメンテナンス時のダウンタイム削減
透過的な運用アプリケーション側の変更不要で、自動的にフェイルオーバーが実行される運用負荷の軽減

マルチAZ配置の仕組みと動…

マルチAZ配置の動作フローを具体的に解説します。

  1. データ書き込み処理：
    1. アプリケーションから書き込み要求が発生
    2. プライマリDBインスタンスがデータを書き込み、同時にスタンバイDBインスタンスへ同期レプリケーションを実行
    3. 両方のDBインスタンスでデータが書き込まれたことを確認後、アプリケーションにレスポンスを返す
  2. AZ障害発生時のフェイルオーバー：
    1. プライマリAZで障害が発生（例：AZ停止、ネットワーク障害）
    2. AWS側で障害を検知し、自動的にフェイルオーバーを開始
    3. スタンバイDBインスタンスが新しいプライマリに昇格し、DNSエントリが更新される
    4. アプリケーションは新しいプライマリDBインスタンスに接続し、処理を再開
  3. フェイルオーバー後の動作：
    1. 元のプライマリAZが復旧すると、新しいスタンバイDBインスタンスとして再構築される
    2. データの同期が再開され、プライマリとスタンバイ間のレプリケーションが再確立される

フェイルオーバーにかかる時間は、通常1〜2分程度です。この間、アプリケーションからの接続が一時的に失敗する可能性がありますが、RDSのエンドポイントを使用することで、自動的に新しいプライマリDBインスタンスに接続が再確立されます。

マルチAZ配置の制限事項と…

マルチAZ配置を導入する際には、以下の制限事項と注意点を理解しておく必要があります。

  • リージョン間の制限：マルチAZ配置は同一リージョン内のAZ間でのみ実行可能。リージョン間のマルチリージョン配置は別の機能（クロスリージョンリードレプリカ）で実現
  • エンジン固有の制限：
    • Amazon Aurora：マルチAZがデフォルトで有効
    • MySQL/PostgreSQL：明示的に有効化が必要
    • Oracle/SQL Server：一部のバージョンでのみマルチAZがサポート
  • パフォーマンスへの影響：同期レプリケーションにより、書き込み処理のレイテンシが若干増加する可能性あり
  • コスト増加：スタンバイDBインスタンス分のコストが発生するため、シングルAZと比較して約2倍のコストがかかる
  • ストレージサイズの制限：マルチAZ配置時のストレージサイズは最大64TiB（2023年12月現在）

これらの制限を踏まえ、マルチAZ配置が本当に必要かどうかを検討することが重要です。例えば、開発環境やテスト環境ではシングルAZで十分な場合もあります。

リードレプリカで読み取り負荷を分散する方法

AWS RDSのリードレプリカ機能を活用することで、読み取り負荷の高いアプリケーションのパフォーマンスを大幅に向上させることができます。リードレプリカは、プライマリDBインスタンスから非同期でデータを複製し、読み取り専用のエンドポイントを提供します。この機能により、データベースの負荷分散とスケーラビリティの向上が実現されます。

リードレプリカの基本概念と…

リードレプリカは、以下のような特徴を持ちます。

  • 非同期レプリケーション：プライマリDBインスタンスからリードレプリカへのデータ複製は非同期で行われる
  • 読み取り専用：リードレプリカは読み取り専用であり、書き込み処理はできない
  • 独立したエンドポイント：リードレプリカごとに独立したエンドポイントが提供される
  • リージョン間複製：リードレプリカは同一リージョン内だけでなく、異なるリージョンに配置することも可能

リードレプリカを活用することで得られる具体的なメリットは以下の通りです。

メリット具体的な内容実務への影響
読み取り負荷の分散複数のリードレプリカに読み取り処理を分散することで、プライマリDBインスタンスの負荷を軽減データベースのパフォーマンス向上とレスポンス時間の短縮
スケーラビリティの向上リードレプリカを追加することで、読み取り処理のスケールアウトが可能トラフィックの増加に柔軟に対応
地理的な負荷分散リージョン間リードレプリカを活用することで、地理的に離れたユーザーへのレスポンスを向上グローバルなアプリケーションのパフォーマンス最適化
障害時の影響軽減リードレプリカがプライマリDBインスタンスの負荷を分担するため、障害発生時の影響を軽減システム全体の安定性向上

リードレプリカの使用シーン

リードレプリカは、以下のようなシーンで特に有効です。

  1. レポートや分析処理：
    • 大量のデータを扱うレポート作成や分析処理をリードレプリカ上で実行することで、プライマリDBインスタンスの負荷を軽減
    • 例：毎月の売上レポート、顧客分析、ログ集計など
  2. 読み取り負荷の高いWebアプリケーション：
    • ECサイトやSNSなど、読み取り処理が多いアプリケーションでリードレプリカを活用
    • 例：商品検索、ユーザープロフィールの表示、ニュースフィードの取得など
  3. グローバルなアプリケーション：
    • リージョン間リードレプリカを活用することで、地理的に離れたユーザーへのレスポンスを向上
    • 例：世界各国にユーザーがいるSaaSアプリケーション
  4. バッチ処理：
    • 夜間のバッチ処理など、大量の読み取り処理を実行する際にリードレプリカを活用
    • 例：データの集計、バックアップ処理、データ移行など

リードレプリカの設定方法

リードレプリカの設定は、AWS Management Console、AWS CLI、またはAWS SDKを使用して行うことができます。以下では、AWS Management Consoleを使用したリードレプリカの設定手順を解説します。

リードレプリカの作成手順

  1. AWS Management Consoleにログイン：
    • AWSアカウントにログインし、AWS Management Consoleにアクセス
    • RDSサービスを選択
  2. リードレプリカを作成するDBインスタンスを選択：
    • 「データベース」セクションから、リードレプリカを作成するDBインスタンスを選択
    • 「アクション」メニューから「リードレプリカの作成」を選択
  3. リードレプリカの設定を指定：
    • DBインスタンス識別子：リードレプリカの名前を入力
    • DBインスタンスタイプ：リードレプリカに使用するインスタンスタイプを選択（プライマリと同じか、それよりも小さなサイズを推奨）
    • アベイラビリティーゾーン：リードレプリカを配置するAZを選択（同一リージョン内）
    • セキュリティグループ：リードレプリカに適用するセキュリティグループを選択
    • パブリックアクセス：リードレプリカへのパブリックアクセスを有効化するかどうかを選択
  4. リードレプリカを作成：
    • 設定を確認し、「リードレプリカの作成」ボタンをクリック
    • リードレプリカの作成が開始され、数分で利用可能な状態になる

リードレプリカの接続方法

リードレプリカは読み取り専用のエンドポイントを提供します。アプリケーションからリードレプリカに接続するには、以下の手順に従います。

  1. リードレプリカのエンドポイントを取得：
    • AWS Management ConsoleのRDSダッシュボードからリードレプリカを選択
    • 「接続とセキュリティ」タブからエンドポイント（読み取りエンドポイント）を取得
  2. アプリケーションの接続設定を更新：
    • リードレプリカを使用するようにアプリケーションのデータベース接続設定を更新
    • 例：MySQLの場合は接続文字列のホスト名をリードレプリカのエンドポイントに変更
  3. 読み取り処理をリードレプリカに振り分ける：
    • アプリケーション側で読み取り処理をリードレプリカに振り分けるロジックを実装
    • 例：特定のクエリをリードレプリカに送信するように設定

リードレプリカのパフォーマ…

リードレプリカのパフォーマンスを最適化するための具体的な方法を解説します。

リードレプリカのサイジング

リードレプリカのインスタンスタイプは、処理する読み取り負荷に応じて適切に選択する必要があります。以下は、一般的なワークロードに対する推奨インスタンスタイプです。

ワークロードタイプ推奨インスタンスタイプ用途
軽負荷（例：小規模Webサイト）db.t3.micro月間数千PV程度のWebサイト
中負荷（例：中規模ECサイト）db.t3.medium / db.t3.large月間数万PV程度のECサイト
重負荷（例：大規模SNS）db.r5.large / db.r5.xlarge高トラフィックなSNSや分析処理
高IOPSが必要な場合db.io1.2xlarge / db.io2.4xlarge大量のランダムI/Oが発生する処理

リードレプリカの監視とスケーリング

リードレプリカのパフォーマンスを監視し、必要に応じてスケーリングを行うことが重要です。以下は、リードレプリカの監視に使用できる主なメトリクスです。

  • CPU使用率：リードレプリカのCPU使用率を監視し、過負荷状態を検知
  • 接続数：リードレプリカへの接続数を監視し、接続制限に近づいていないか確認
  • レイテンシ：リードレプリカへのクエリ実行時間を監視し、パフォーマンス低下を検知
  • ストレージ使用量：リードレプリカのストレージ使用量を監視し、容量不足を防ぐ
  • レプリケーション遅延：プライマリDBインスタンスとリードレプリカ間のレプリケーション遅延を監視

これらのメトリクスをCloudWatchで監視し、以下のようなアラートを設定することを推奨します。

  • CPU使用率が80%以上で継続的に推移している場合
  • 接続数が最大接続数の80%に達した場合
  • レプリケーション遅延が1秒以上発生している場合
  • ストレージ使用量が80%を超えた場合

これらのアラートが発生した場合は、リードレプリカのインスタンスタイプをアップグレードするか、新しいリードレプリカを追加することを検討してください。

リードレプリカのメンテナンス

リードレプリカのメンテナンスは、以下のような手順で行います。

  1. DBエンジンのアップグレード：
    • リードレプリカのDBエンジンをアップグレードする場合は、まずプライマリDBインスタンスをアップグレード
    • リードレプリカは自動的にアップグレードされる
  2. パラメータグループの更新：
    • リードレプリカのパラメータグループを更新する場合は、プライマリDBインスタンスと同じパラメータグループを使用
    • リードレプリカはプライマリと同じパラメータで動作する
  3. セキュリティパッチの適用：
    • リードレプリカは自動的にセキュリティパッチが適用される
    • 手動での適用は不要

マルチAZ・リードレプリカの実践的な設定手順

AWS RDSでマルチAZ配置とリードレプリカを実際に設定する手順を、具体的な画面操作と共に解説します。このセクションを読み終える頃には、実際のAWSコンソール上でこれらの機能を設定できるようになります。

マルチAZ配置の設定手順

マルチAZ配置を設定するには、以下の手順に従います。ここでは、Amazon RDS for MySQLを例に解説しますが、他のエンジンでも基本的な手順は同様です。

1. RDSインスタンスの作成（シングルAZ）

まず、シングルAZでRDSインスタンスを作成します。その後、マルチAZ配置に切り替えます。

  1. AWS Management Consoleにログイン：
    • AWSアカウントにログインし、AWS Management Consoleにアクセス
    • 「RDS」サービスを選択
  2. データベースの作成を開始：
    • 「データベースの作成」ボタンをクリック
    • 「標準作成」を選択
  3. エンジンの選択：
    • 「エンジンの種類」で「Amazon Aurora」または「MySQL」を選択
    • 「バージョン」で使用するバージョンを選択（例：MySQL 8.0）
  4. テンプレートの選択：
    • 「テンプレート」で「プロダクション」または「開発/テスト」を選択
    • プロダクション環境では「プロダクション」を選択し、高可用性を確保
  5. 設定の指定：
    • DBインスタンス識別子：任意の名前を入力（例：my-mysql-db）
    • マスターユーザー名：管理者ユーザー名を入力
    • マスターパスワード：強力なパスワードを入力（8文字以上、大文字・小文字・数字・記号を含む）
    • DBインスタンスタイプ：用途に応じたインスタンスタイプを選択（例：db.t3.medium）
    • ストレージタイプ：汎用SSD（gp2）またはプロビジョンドIOPS（io1）を選択
    • ストレージサイズ：必要なストレージ容量を入力（例：20GB）
    • アベイラビリティーゾーン：シングルAZを選択（例：ap-northeast-1a）
      • 【編集・制作ポリシー】
      本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
      ABOUT ME
      たから
      サラリーマンをしながら開業して経営やってます。 今年、本業で独立・別事業を起業予定です。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900/FE/サーティファイC言語 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営