👁

RDS概要

この章では、AWSのマネージドデータベースサービスであるRDSについて学びます。これにより、マルチAZ・リードレプリカ・バックアップなど、可用性の高いデータベース運用の仕組みが理解できます。

1. 本章の概要

1.1 本章の目的

アプリケーションのデータを永続化するデータベース基盤として、AWSではRDSがマネージド提供されています。パッチ適用・バックアップ・可用性設計といった運用の負担をAWS側に寄せられる点が大きな特徴で、実務のWebシステムでは標準採用される選択肢です。

1.2 本章で学ぶ内容

RDSの基本構成とセキュリティ設計、マルチAZ構成による高可用性、リードレプリカによる読み取りスケーリングを扱います。あわせて、バックアップ・メンテナンスウィンドウ・Amazon Auroraなど周辺要素も押さえます。

2. RDSの概要

2.1 データベースが必要な理由

通常、アプリケーションは処理をメモリ上で行うため、アプリケーションの終了とともにデータは消えてしまい、それ単体では永続的なデータ管理ができません。

サーバ内部にファイルとして保存する方法もありますが、この方法は頻繁な書き込みや検索に向かず、処理が複雑になってしまいます。また、オートスケーリングのような環境では、特定のサーバ内にデータを保存してしまうと、増減する他のサーバとデータが共有できないため望ましくありません。

そのため、データをサーバから切り離して永続的に保存し、効率的に検索などができる「データベース」が必要となります。

2.2 データベースとは

データベースとは、データを永続的に保存し、効率的に管理するためのシステムのことです。

その中でも、データを列と行からなる「表形式」で整理して扱う「リレーショナルデータベース(RDB)」と呼ばれる種類が最も多く利用されており、データの操作には「SQL」という専用の言語を使用します。

代表的なリレーショナルデータベースには、MySQLやPostgreSQL、Oracle Databaseなどがあります。

一般的なアプリケーションでは、このような「リレーショナルデータベース」と組み合わせて、データの保存を行うことが多いです。

2.3 RDSとは

RDSは、AWSが提供するリレーショナルデータベースの構築・運用を容易にするサービスです。

EC2インスタンスにMySQLやPostgreSQLなどをインストールして構築することも可能ですが、その場合はOSの管理やパッチ適用、バックアップ、冗長化などの設定をすべて自力で行う必要があります。RDSを利用すれば、これらの煩雑な運用作業をAWSに任せることができ、簡単な設定だけで管理が可能になります。

AWSでリレーショナルデータベースを扱う場合は、基本的にRDSを利用するのが一般的です。

RDSはMySQL、PostgreSQL、Oracleなど様々なデータベースエンジンに対応しています。また、後述するAWS独自の「Amazon Aurora」を選択することで、クラウドのメリットを最大限に活かした構成をとることができます。

3. RDSの基本構成

RDSの基本的な構成例を説明します。

まず、RDSはVPCのサブネットに「インスタンス」として配置されます。このインスタンスは、EC2と同じように「RDSとして起動する個別のサーバ」とイメージすると分かりやすいでしょう。

このインスタンスは、原則としてプライベートサブネットに配置することが推奨されます。データベースは最も重要な資産であるため、インターネットから直接到達できるパブリックサブネットに配置すると、不正アクセスや情報漏洩のリスクが高まるからです。

データベースを利用する際は、アプリケーションを配置したサーバから接続して操作するのが基本です。その際、セキュリティグループの設定では、接続元のEC2インスタンスが所属するセキュリティグループからの、必要なポート(MySQLなら3306番など)への通信のみを許可するのが一般的です。

また、RDSのデータメンテナンスを直接行うために、「踏み台サーバ」と呼ばれる作業用のEC2インスタンスを別途用意することもあります。

4. RDSの主要機能

RDSの主要機能について説明します。

4.1 リードレプリカ

リードレプリカは、RDSの読み取り専用の複製(レプリカ)を作成し、検索などの参照処理をそちらに任せることで、メインのデータベースへの負荷を軽減する仕組みです。

リードレプリカによる読み取り負荷分散の流れを以下に示します。

graph TD
    App["アプリケーション"]
    Primary["プライマリ<br>(読み書き)"]
    Replica1["リードレプリカ1<br>(読み取り専用)"]
    Replica2["リードレプリカ2<br>(読み取り専用)"]

    App -- "書き込み" --> Primary
    App -- "読み取り" --> Replica1
    App -- "読み取り" --> Replica2
    Primary -- "非同期レプリケーション" --> Replica1
    Primary -- "非同期レプリケーション" --> Replica2

基本的に、書き込みを行うデータベースをEC2のように複数台並べて処理を分散させることは容易ではありません。データベースは「データの整合性」が最優先されるため、複数のサーバで同時に書き込みを行うとデータに矛盾が生じ、システムとして致命的な問題になりかねないためです。

しかし読み取り処理であれば、正解となるデータのコピーを作成して参照させることで、安全に処理を分散できます。これにより、レプリカの数を増やすことでEC2のオートスケーリングのように、読み取り性能(スループット)を向上させることが可能になります。

4.2 フェイルオーバー

RDSは原則として書き込みを行うインスタンスを1台に限定するため、そのままだと1台の故障でシステムが停止する単一障害点となるリスクがあります。そのため、RDSではマルチAZ機能を利用して予備機を準備する構成をとることができます。

マルチAZ構成によるフェイルオーバーの仕組みを以下に示します。

graph TD
    App["アプリケーション"] --> DNS["RDSエンドポイント<br>(DNS)"]

    subgraph AZ-a["AZ-a"]
        Primary["プライマリ<br>(稼働中)"]
    end

    subgraph AZ-c["AZ-c"]
        Standby["スタンバイ<br>(待機中)"]
    end

    DNS -- "通常時" --> Primary
    Primary -- "同期レプリケーション" --> Standby
    DNS -. "障害時に自動切替" .-> Standby

具体的には、メインのAZに稼働する本体(プライマリ)を配置し、別のAZに予備(スタンバイ)を配置します。スタンバイ機は通常はデータベースとしてのアクセスを受け付けずに待機していますが、プライマリのデータは常に同期(同期レプリケーション)され続けています。

そして、AZ障害やインスタンスの故障などでプライマリが使用不能になった際、自動的にスタンバイ機へ役割が切り替わるフェイルオーバーが実行されます。

この仕組みにより、RDSインスタンスの可用性を大きく高めることができます。

4.3 バックアップ

RDSにはデータのバックアップを行う仕組みも標準で用意されています。データはアプリケーションのように「壊れたら再構築すれば良い」というわけにはいきません。そのため、万が一の事態に備えて復元できるよう、適切なバックアップ戦略をとることが重要です。

自動バックアップ

AWSが毎日自動でバックアップを取得してくれる自動バックアップ機能があります。これを利用するとポイントインタイムリカバリ(PITR)が可能となり、例えば「昨日の14:00時点の状態に戻したい」といった、特定の時刻を指定した復元ができます。アプリケーションのバグや操作ミスなどでデータが破損してしまった際の命綱になります。

手動スナップショット

手動でバックアップを取得する手動スナップショット機能もあります。これを利用すれば、任意のタイミングでデータを保存し、必要な時に復元できます。また、取得したスナップショットを元に、別のRDSインスタンスへデータを複製・移行することも容易に行えます。

5. 設定変更とメンテナンス

5.1 パラメータグループ

RDSはOSへログインできないため、設定ファイル(my.cnfなど)を直接編集することができません。その代わり、パラメータグループという機能を使って、タイムゾーンや文字コードなどのデータベース設定を管理します。

これにより、通常はサーバ上で設定ファイルを書き換えて行う設定変更を、AWSの管理画面上などから行うことができます。

5.2 メンテナンスウィンドウ

AWSが行うパッチ適用などのメンテナンスを週のいつ行うか指定するメンテナンスウィンドウを設定することで、業務影響の少ない時間帯にアップデートをコントロールすることができます。

これを設定していないと、意図せずアクセスが集中する時間帯にメンテナンスが実行されてしまうなど、運用上の問題が生じるリスクがあります。

6. Amazon Aurora

AWSがクラウド専用に開発したAmazon Auroraについて解説します。

6.1 Auroraとは

Auroraは、AWSがクラウド時代に合わせて再設計したデータベースです。MySQLおよびPostgreSQLと互換性があり、これらを使っている既存のデータベースからの移行は比較的容易に行えます。

6.2 スケーリング

Auroraは、データ量に応じてストレージ容量が自動的に拡張される機能を持っています。

また、処理性能に関しては、書き込みを行う本体(プライマリ)はスペックを上げる「垂直スケーリング」で対応し、読み取りはリードレプリカを増やす「水平スケーリング」で対応するという組み合わせが有効です。Auroraはリードレプリカの追加や削除が非常に高速に行えるため、この水平スケーリングを効果的に活用できます。

6.3 ストレージ構造

Aurora最大の特徴はそのストレージ構造にあります。Auroraのデータは、3つのアベイラビリティゾーン(AZ)にまたがって、合計6つのコピー(各AZに2つずつ)が自動的に保存されます。

これにより、仮に1つのAZ全体がダウンしたり、複数のディスクに障害が発生したりしてもデータは守られ、極めて高い耐久性と可用性を実現しています。

6.4 使い分け

新規でデータベースを構築する場合は、高機能なAuroraを使うことが理想的です。ただし、既存のデータベースを移行する場合、MySQLやPostgreSQL以外からの移行は困難なため、通常のRDSを使用することもあります。

また、AuroraはRDSに比べてコストが割高になりがちで、無料利用枠も用意されていません。そのため、コストを抑えたい場合や、学習用として無料枠を使いたい場合は、通常のRDS(MySQLなど)を選択するのが良いでしょう。

6.5 Aurora Serverless

Auroraにはインスタンスタイプ(サーバのスペック)を固定せずに、負荷に応じて自動的に容量を拡張・縮小してくれるAurora Serverlessというモードも用意されています。

通常のAuroraは起動しているだけで一定の料金が発生し続けますが、Serverlessを利用すれば、アクセスが少ない夜間などは自動的に最小限のスペックまで縮小されます。そのため、アクセス頻度が予測できないシステムや、夜間は使わない開発環境などで、コストを最適化することができます。

ただし、常に一定のアクセスや高い負荷がかかり続けるシステムの場合、通常のインスタンスを稼働させるよりも料金が割高になってしまう傾向があります。また、利用量に応じて料金が常に変動するため、月々の予算が立てにくいという点にも注意が必要です。

そのため、基本的には通常のインスタンス(プロビジョンド)で運用する構成をとり、負荷が予測できない場合や変動が激しい場合、あるいは特定の時間帯のみ使用されるような場合に、Serverlessを選択するのが有効です。

7. 主なユースケース

RDSは、リレーショナルデータベースが必要なあらゆるシステムで活用されています。以下に代表的なユースケースを紹介します。

7.1 Webアプリケーションのバックエンドデータベース

ユーザ情報、商品データ、注文履歴などの構造化されたデータを保存・管理します。マルチAZ構成による高可用性と、リードレプリカによる読み取りスケーリングにより、大規模なトラフィックにも対応できます。

7.2 業務システムのデータ基盤

販売管理、在庫管理、人事システムなど、企業の基幹業務を支えるデータベースとして利用されます。自動バックアップとポイントインタイムリカバリにより、重要なビジネスデータを確実に保護できます。

7.3 レガシーシステムのクラウド移行

オンプレミスで運用していたOracle、SQL Server、MySQLなどのデータベースをRDSに移行することで、ハードウェア管理やパッチ適用といった運用負荷を大幅に軽減できます。既存のアプリケーションとの互換性を保ちながら、クラウドのメリットを享受できます。

8. 設計のポイント

RDSを設計する際の主要な検討項目を以下にまとめます。

設計項目 検討内容 推奨・注意事項
データベースエンジン MySQL/PostgreSQL/Aurora等を選ぶ 新規構築ならAuroraを推奨する。既存システムからの移行は互換性を考慮する
インスタンスクラス スペックを選ぶ 小さいサイズから開始し、負荷に応じてスケールアップする
マルチAZ配置 可用性を確保する 本番環境では必須。自動フェイルオーバーでダウンタイムを最小化できる
リードレプリカ 読み取り処理をスケールする 読み取り負荷が高い場合に追加する。レポート処理などの分離にも有効に使える
ストレージタイプ gp3/io1/io2を選ぶ 通常はgp3で十分。高IOPSが必要な場合はio1/io2を検討する
バックアップ保持期間 自動バックアップを設定する 本番環境は7日以上を推奨する。要件に応じて最大35日まで設定できる
メンテナンスウィンドウ パッチ適用のタイミングを決める 業務影響の少ない時間帯(深夜・早朝)に設定する
暗号化 保存データを暗号化する 新規作成時の有効化を推奨する(後から有効化する場合は再作成が必要になる)

9. まとめ

この章では、AWSのデータベースサービスであるRDSについて学びました。

  • RDSは、リレーショナルデータベースの構築・運用をマネージドで提供するサービスである
  • データベースはプライベートサブネットに配置し、セキュリティグループで接続元を制限する
  • リードレプリカにより読み取り処理を分散でき、マルチAZ構成によりフェイルオーバーで可用性を確保できる
  • 自動バックアップと手動スナップショットにより、データを保護できる
  • パラメータグループで設定を管理でき、メンテナンスウィンドウでアップデート時間を制御できる
  • Auroraはクラウド専用に設計されたRDS互換DBで、高い耐久性とスケーラビリティを備える

次の章では、RDSを使ったデータベース構築をハンズオン形式で体験します。

この教材は役に立ちましたか?

いいねをたくさんいただけると、制作者の励みになり、より多くのセクションが作れるようになります。

感想を一言(任意)

いただいたコメントは次の制作のヒントになります。ぜひお気軽にご投稿ください。

このコメントは他の受講生には公開されません。DevOps Camp運営が、教材改善のために確認します。

0 / 2000