Auroraの特性｜基礎を学ぶ - ゆめさくコード

このレッスンでできるようになること

要件の文から、通常の RDS で足りるのか、Aurora が要るのか、さらに Aurora の中で Global Database と Serverless のどちらを選ぶのかを判断できるようになります。

要件の文から入る

ある SaaS 企業が MySQL 互換のデータベースを使っています。北米と日本の両方に利用者がいて、日本からの参照の遅延を下げたいという要望があります。加えて、リージョン全体の障害に備えて別リージョンへ短時間で切り替えたいという要件も出ています。一方、社内向けの検証環境は平日の日中しか使わず、夜間と週末は無利用です。

1つの文の中に、性能の要件と災害対策の要件と稼働パターンの要件が混ざっています。Aurora の設問はこの形が多く、どの語がどの機能を指しているかを拾えるかで決まります。

Aurora が RDS と何が違うか

Aurora はストレージが計算ノードから切り離されていて、書込は3つのアベイラビリティゾーンに複製されます。ここから試験で使う性質が出てきます。

観点	RDS(MySQL / PostgreSQL)	Aurora
ストレージ	インスタンスに付く	クラスターで共有し、複数AZに複製
レプリカの数	比較的少ない	多く追加でき、参照エンドポイントで束ねられる
レプリカの遅れ	非同期で相対的に大きい	共有ストレージ参照のため小さい
障害時の切替	スタンバイへフェイルオーバー	レプリカが昇格。レプリカがあるほど速い
バックアップ	スナップショット中心	継続的にバックアップし、指定時点へ復元しやすい

「読取のスケールと復旧の速さを同時に求められている」という文が出たら Aurora を疑ってください。RDS のリードレプリカでも読取は逃がせますが、レプリカを可用性の担保に使えない点が Aurora との差になります。

Global Database と Serverless の線引き

機能	何を解決するか	選ぶ要件語
Aurora レプリカ(同一リージョン)	読取の集中と、AZ 障害からの復旧	「読取が重い」「AZ 障害でも継続」
Aurora Global Database	別リージョンへの複製と、そのリージョンからの低遅延な読取	「海外拠点の参照が遅い」「リージョン障害に備える」
Aurora Serverless	使う量に合わせた容量の自動調整	「利用が読めない」「間欠的」「検証環境」

Global Database は、書込を受けるのは主リージョンだけで、副リージョンは読取専用です。だから「海外拠点でも書き込みたい」という文にそのまま当てると外します。一方で、副リージョンを昇格させてリージョン障害から復旧する使い方は正解になりやすく、「リージョン全体の障害」という語が出たら真っ先に候補にします。

Serverless は負荷に応じて容量が上下します。夜間や週末に使われない検証環境、キャンペーン時だけ跳ねる用途、開発用の共有データベースといった稼働が読めないワークロードで、常時大きなインスタンスを立てておくより無駄が出ません。逆に、負荷が一日中平坦で読める本番系では、容量を固定した通常の Aurora の方が素直です。

要件語から構成への対応表

要件の言い回し	選ぶもの
読取のレプリカを多数並べたい	Aurora レプリカ
別リージョンの利用者の参照を速くしたい	Aurora Global Database
リージョン障害から短時間で復旧したい	Aurora Global Database の副リージョン昇格
使用量が読めない・間欠的	Aurora Serverless
指定した時点にデータを戻したい	Aurora の継続的バックアップからの復元

よくある引っ掛け

引っ掛け1、Global Database なら世界中で書き込めると考える。 書込を受けるのは主リージョンです。副リージョンからの書込を含む要件では、この選択肢は外れます。

引っ掛け2、負荷が安定しているのに Serverless を選ぶ。 「一日を通してほぼ一定の負荷」と書かれていれば、自動調整の利点が効きません。常時同じ容量が要るワークロードで自動調整を持ち出す選択肢は、動きはしても要件に対して最適ではない、という落とし方をされます。

まとめ

Aurora の特徴は共有ストレージ。読取のスケールと復旧の速さがここから出る
別リージョンの語が出たら Global Database。ただし書込は主リージョンだけ
稼働が読めない・間欠的という語が出たら Serverless
負荷が一定と明記されていたら、自動調整は選ばない