AWS CLF(Cloud Practitioner)対策

RDSとAurora

RDSとAurora

このレッスンを終えると、マネージドなリレーショナルデータベースが何を肩代わりしてくれるかを説明でき、マルチ AZ 配置とリードレプリカの違いを取り違えずに答えられるようになります。この2つの取り違えは CLF で最も狙われる論点の1つです。

まず、自分でサーバーを建てるなら

EC2 に MySQL を自分でインストールして運用する場面を考えます。あなたの仕事は次のように積み上がります。

  1. OS を入れ、MySQL をインストールし、設定ファイルを書く
  2. 毎晩バックアップを取り、別の場所へ退避する
  3. セキュリティパッチが出たら、停止時間を調整して適用する
  4. ディスクが足りなくなったら増設する
  5. 機械が壊れたときに備えて、待機系をもう1台組み、切り替え手順を用意する
  6. 参照が増えて重くなったら、読み取り専用の複製を足す

Amazon Relational Database Service (RDS) を使うと、1から4までを AWS が引き受けます。そして5と6も、設定を1つ入れるだけで手に入るようになります。この5と6にあたるのがマルチ AZ 配置とリードレプリカです。

ただし、責任共有モデルは残ります。テーブル設計・スキーマ・データの中身・アクセス権限は利用者の責任です。RDS を使っても SQL の設計を AWS がやってくれるわけではありません。

RDS が対応するエンジン

RDS は既存のリレーショナルデータベースをそのまま動かせます。本記事執筆時点で MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、そして Amazon Aurora が選べます。

Aurora は AWS が作ったエンジンで、MySQL と PostgreSQL に互換性があります。同じ SQL とドライバがそのまま使える一方で、ストレージ層が AWS 独自に作られており、性能と可用性が高められています。試験では「MySQL 互換で、高い性能と可用性が要る」という文が Aurora の合図になります。

マルチ AZ 配置は「壊れても止まらない」ため

マルチ AZ 配置を有効にすると、RDS は別のアベイラビリティゾーンにスタンバイ (待機系) を1台作り、プライマリの内容を同期的に複製します。

  • 目的は高可用性と災害対策です。性能を上げるためのものではありません
  • スタンバイには普段アクセスできません。読み取りにも使えません
  • プライマリに障害が起きると、AWS が自動でスタンバイへ切り替えます (フェイルオーバー)。接続先のエンドポイント名は変わらないので、アプリケーション側の設定変更は不要です

覚え方は「マルチ AZ は保険」です。普段は何も仕事をしていない待機要員が、倒れたときだけ立ち上がります。

リードレプリカは「重いから分散する」ため

リードレプリカは、プライマリの内容を非同期に複製した、読み取り専用のデータベースです。

  • 目的は読み取り性能の向上 (スケーラビリティ) です
  • レプリカにはアプリケーションから接続して読める。参照系のクエリをここへ逃がします
  • 書き込みはできません。書き込みは常にプライマリへ向きます
  • 非同期なので、プライマリの更新がレプリカに反映されるまでわずかな遅れが出ることがあります
  • 別リージョンにも作れるので、遠隔地からの参照を速くする目的にも使えます

覚え方は「リードレプリカは分身」です。普段から一緒に働いて、参照の負荷を引き受けます。

2つを並べる

マルチ AZ 配置リードレプリカ
目的高可用性・災害対策読み取り性能の向上
複製の方式同期非同期
普段アクセスできるかできないできる (読み取りのみ)
障害時の自動切り替えある自動ではない
増やせる数待機系は1つ複数作れる

この2つは排他ではありません。可用性も性能も要るなら、両方を同時に使います。「どちらか一方しか使えない」という選択肢が出たら誤りです。

試験ではこう出る

問題文の目的を表す言葉から、どちらを問われているかを判定します。

  • 「高可用性を確保したい」「AZ の障害に備えたい」「ダウンタイムを最小にしたい」「自動でフェイルオーバーしたい」 → マルチ AZ 配置
  • 「参照クエリが増えて遅い」「レポート集計の負荷をデータベースから逃がしたい」「読み取りをスケールさせたい」 → リードレプリカ
  • 「MySQL 互換で、より高い性能が欲しい」「AWS がクラウド向けに設計したエンジン」 → Aurora
  • 「データベースのパッチ適用やバックアップの手間をなくしたい」 → RDS などのマネージドサービスへの移行
  • 「データベース内のデータそのものの保護と、アクセス権限の設定は誰の責任か」 → 利用者

最頻出の引っ掛けは「可用性を上げたいのでリードレプリカを追加する」という誤答です。リードレプリカは非同期で、自動フェイルオーバーもしないので可用性の答えにはなりません。逆に「読み取りが遅いのでマルチ AZ にする」も誤りです。スタンバイは読み取りに使えないからです。可用性ならマルチ AZ、性能ならリードレプリカと、目的の言葉で機械的に振り分けてください。

もう1つ、「地理的に離れた場所へ」と書かれていたら AZ ではなくリージョンの話です。マルチ AZ は同一リージョン内の話である点も押さえておきます。

まとめ

  • RDS はインストール・パッチ・バックアップ・冗長化を肩代わりするマネージドなリレーショナルデータベース
  • Aurora は MySQL と PostgreSQL に互換性のある AWS 製エンジンで、性能と可用性が高い
  • マルチ AZ 配置は同期複製の待機系。目的は可用性で、普段は読めない
  • リードレプリカは非同期複製の読み取り専用。目的は性能で、普段から読める
  • 目的の言葉が「可用性」か「性能」かで、どちらを答えるか決まる
生田 陸人
ゆめさくエンジニア / 現役ソフトウェアエンジニア
編集 LuaGate編集部

復習ミニクイズ

Amazon RDS で稼働する分析用データベースがあります。日中に実行される参照系のレポートクエリが増え、アプリケーション本体の応答が遅くなってきました。書き込み処理には影響を与えずに参照の負荷を下げたいです。最も適した対応はどれですか。