Amazon RDS・AuroraとリレーショナルDBの全体像

リレーショナルDBをAWSで運用する方法として、RDSとAuroraの位置付けを学びます。表とSQLを使うアプリの要件から、管理負担、可用性、読取り負荷、バックアップを分けて考えます。

この単元で学ぶこと

リレーショナルDBとマネージド運用を説明する
RDSとAuroraの位置付けを区別する
可用性・読取り拡張・復旧の目的を整理する

本文解説

1. 表同士の関係を扱うリレーショナルDBは行と列を持つ表でデータを管理し、SQL等で検索や更新を行います。例えば顧客表と注文表を顧客IDで関連付け、どの顧客が何を注文したかを調べます。整合性を守る制約やトランザクションも、業務の条件に合わせて設計します。

2. 運用方法の選択 EC2へDBソフトを入れる方法では、利用者がOSやDBの更新、バックアップ等を管理します。RDSではインフラや一般的なDB管理作業をAWSが担い、運用負担を軽減できます。管理される範囲が広がっても、データの設計やSQLの改善、誰が何を操作できるかの判断は利用者に残ります。

3. RDSの位置付け RDSではMySQL、PostgreSQL、MariaDB、Oracle Database、SQL Server、Db2等のエンジンを利用できます。エンジンやバージョン、リージョンにより機能の対応が異なります。既存アプリが使うSQL方言、拡張機能、ライセンス等を確認し、リレーショナルという分類だけで無変更移行を保証しません。

4. Auroraの位置付け AuroraはMySQL互換・PostgreSQL互換のリレーショナルDBで、RDSの管理機能と組み合わせて利用します。計算を担うDBインスタンスと、複数AZへ分散したクラスタボリュームを分けた構成です。全てのRDSエンジンと互換なのではなく、対応エンジンやバージョンを確認します。

5. 可用性のための複製 RDSのMulti-AZは障害時の切替えに備える構成です。ただし従来のMulti-AZ DBインスタンス配置と、読取り可能なDBクラスター配置を区別します。前者のスタンバイは読取り要求の分散先として使いません。「Multi-AZなら読める・読めない」と全方式へ一律に当てはめないことが重要です。

6. 読取りを増やすリードレプリカは読取り負荷を分散するための複製です。通常のRDS DBインスタンスのリードレプリカは非同期で、更新が届くまで遅延する場合があります。直前の更新を確実に反映して読む必要がある業務では、どこへ接続するかも考えます。読取り用を増やすことと書込み先を増やすことは別です。

7. 過去の状態へ戻すバックアップやスナップショットは復旧点を残すために使います。可用性のための複製先にも誤更新が反映され得るので、複製だけを過去状態の保管とみなさないようにします。保持期間、復元先、復元後の接続と動作確認を用意し、必要な復旧時間に収まるかを評価します。

8. 利用者に残る設計マネージドDBでも、アプリの接続先、認証情報、ネットワーク許可、テーブル設計、クエリを管理します。単にDBを大きくする前に遅いSQLやアクセスパターンを確認します。選択するDBインスタンス、保存量、I/O、バックアップ、構成等の費用を見積もり、必要条件に合う案を比較します。

図解

重要ポイント

マネージドDBでもデータ・SQL・権限は利用者の設計。
Multi-AZの方式を区別する。
読取り拡張と過去状態への復元は別。

間違えやすい点

RDSの全エンジンがAurora互換と考える。
複製があれば誤削除にも自動で戻れると考える。

用語解説

DBエンジン: MySQL等のデータベースソフトウェアの種類。
リードレプリカ: 読取り負荷を分散するためのDB複製。
フェイルオーバー: 障害等で稼働するDBへ役割を切り替えること。
トランザクション: 関連する処理を一まとまりとして扱う単位。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。