マルチAZとリードレプリカ｜基礎を学ぶ

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

要件の文が「止まらないこと」を求めているのか「速く読めること」を求めているのかを見分けて、マルチAZ配置とリードレプリカを迷わず振り分けられるようになります。SAA のデータベース分野で最も多く問われる論点です。

要件の文から入る

ある会社が、EC サイトの RDS for MySQL を1台で運用しています。AZ の障害やパッチ適用でデータベースが停止するとサイト全体が止まるため、単一障害点を排除したいと考えています。あわせて、日中は商品一覧ページの参照が集中し、書込より読取が10倍多く、参照のせいでレスポンスが悪化しています。

この文には要件が2つ入っています。「単一障害点を排除」は可用性の要件、「読取が多くて遅い」は性能の要件です。SAA では、この2つを1つの構成で解こうとすると必ず外します。可用性はマルチAZ配置、読取性能はリードレプリカで、担当が完全に分かれているからです。

2つの構成の線引き

観点	マルチAZ配置	リードレプリカ
目的	可用性の確保	読取性能の拡張
レプリケーション	同期	非同期
待機側に接続できるか	できない(普段は読めない)	できる(読取専用として使う)
切り替わり方	自動フェイルオーバー	手動で昇格させる
接続先	同じエンドポイントの向き先が変わる	別のエンドポイントが増える
置ける場所	同一リージョンの別AZ	同一AZ・別AZ・別リージョン

同期か非同期かが、そのまま用途を決めています。マルチAZ配置は書込をスタンバイに同期で反映してから完了とするので、切り替わってもデータが欠けません。その代わりスタンバイは常に追従に専念していて、参照を受け付けません。リードレプリカは非同期なので本番の書込を待たせませんが、わずかな遅れが生じます。だから可用性の担保には使えず、読取を逃がす用途に向きます。

目的の言葉で機械的に振り分ける

本文を読むとき、次の順で判定します。

止まる話をしているか。「単一障害点」「AZ 障害でも継続」「計画メンテナンス中も停止しない」「復旧時間を短く」があればマルチAZ配置
遅い話をしているか。「読取が重い」「参照が集中する」「分析クエリが本番に影響する」があればリードレプリカ
両方書いてあれば両方使う。マルチAZ配置の上にリードレプリカを足す構成は普通に成立します。この組み合わせが正解の設問は多いので、片方だけの選択肢に飛びつかないでください

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

要件の言い回し	選ぶもの
単一障害点を排除したい	マルチAZ配置
AZ 全体の障害でも継続したい	マルチAZ配置
パッチ適用中もダウンタイムを最小にしたい	マルチAZ配置
読取が集中して遅い	リードレプリカ
集計やレポートを本番と分けたい	リードレプリカ
別リージョンにも読める複製を置きたい	クロスリージョンのリードレプリカ
可用性と読取性能の両方	マルチAZ配置 + リードレプリカ

よくある引っ掛け

引っ掛け1、リードレプリカで可用性要件も満たせると考える。 レプリカは昇格させれば単体のデータベースになりますが、昇格は手動の操作で、レプリケーションは非同期です。直前の書込が届いていない可能性があるため、「復旧時間を短く」「データを失わない」という要件の文では落ちます。

引っ掛け2、マルチAZ配置のスタンバイでレポートを流す。 標準のマルチAZ配置のスタンバイは接続を受け付けないので、この選択肢は動きません。読取を逃がしたいならレプリカが要ります。なお本記事執筆時点では、待機側が読取を受けられる「マルチAZ DB クラスター」という別方式も提供されています。設問が単に「マルチAZ配置」と書いているときは、読めないスタンバイの方だと読んでください。

まとめ

マルチAZ配置は可用性、リードレプリカは読取性能。目的が違うので置き換えられない
同期で読めないのがスタンバイ、非同期で読めるのがレプリカ
切り替えは、マルチAZ配置が自動、レプリカの昇格が手動
要件が2つ書いてあれば、構成も2つ重ねるのが正解になりやすい