AuroraとリレーショナルDBを理解する

Auroraでは、SQLを実行するDBインスタンスとデータを保持するクラスタボリュームを分けて考えます。writerとreader、エンドポイント、容量調整の役割を整理します。

この単元で学ぶこと

Auroraの互換性と構成を説明する
writerとreaderの接続先を区別する
可用性とスケーリングの条件を判断する

本文解説

1. 互換エンジンを確認 AuroraにはMySQL互換とPostgreSQL互換のエンジンがあります。既存アプリのSQLやドライバーを活用しやすい一方、全ての版や拡張が同じとは限りません。移行では互換性の検証を行い、OracleやSQL Server等を無変更でそのまま実行するサービスと誤解しないようにします。

2. 計算と保存の分離 Auroraクラスタは一つ以上のDBインスタンスと、複数AZにまたがるクラスタボリュームで構成します。DBインスタンスはSQLの実行、保存部分はデータの保持を担います。一台のDBインスタンスだけでもクラスタと呼べるのは、保存側が複数の保存ノードを使うためです。

3. writerの役割通常のAurora DBクラスタでは一つのwriterがデータの変更を行います。writerは読取りにも対応します。利用者がreaderを追加しても、その全てが同時に書込みを受けるwriterになるわけではありません。ここでは通常のクラスタを対象とし、別の分散DB方式等へ一般化しません。

4. readerの役割 Aurora Replicaは同じクラスタボリュームに接続して読取りを提供し、writerの読取り負荷を軽減できます。readerを別AZへ配置すると、writer障害時の昇格先としても利用できます。保存が複数AZであることと、計算用の切替先を別AZに用意していることを分けて確認します。

5. エンドポイントクラスタのwriterエンドポイントは現在のwriterへ、readerエンドポイントは読取り用の接続へ使います。readerエンドポイントは接続の分散であり、一本の接続内のSQLを一つずつ均等に各readerへ割り振る保証ではありません。readerがない場合の挙動等もあるので実構成を確認します。

6. フェイルオーバー writerが利用できなくなった場合、対応するreaderを昇格させる等の復旧を行います。アプリ側では接続の切断、再接続、再試行の整合性も考えます。エンドポイントが役割の変化を追えることと、実行中の全処理が何の影響も受けないことは同じではありません。

7. Serverlessの容量調整 Aurora Serverlessは負荷に応じて計算容量を調整する方式です。最小・最大容量や対応版・リージョン等を確認し、需要に応じた動作を評価します。Serverlessという名称だけで全てのデータ保持やI/Oも無料になったり、上限なく瞬時に処理できたりするものではありません。

8. 運用と復旧点マネージドでもSQL、索引、業務権限、接続先、バックアップや復元の要件は利用者が確認します。readerや多AZ保存は高可用性・読取り拡張に役立ちますが、誤更新前の状態を残すバックアップの代わりではありません。互換性、性能、切替え、復元を実際のアプリで検証します。

図解

SQLを実行する部分と保存部分 — readerを追加しても、通常クラスタの同時writer数を増やす意味ではありません。

重要ポイント

計算インスタンスと保存ボリュームを分ける。
reader追加は同時writerの追加ではない。
reader endpointの分散単位と接続の扱いを確認する。

間違えやすい点

保存が複数AZなら計算の切替先も自動で全て揃うと考える。
Serverlessを無料や無制限と読み替える。

用語解説

writer: 通常のAuroraクラスタで変更を処理するプライマリDBインスタンス。
Aurora Replica: 同じクラスタの保存領域を用いて読取りを提供するDBインスタンス。
クラスタボリューム: クラスタのデータを複数AZに保持する保存領域。
昇格: reader等へwriterの役割を引き継がせること。

参考資料

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

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