Aurora のクラスターエンドポイントとリーダーエンドポイントの違い ── 読み取りをレプリカに逃がす

概要

データベースの負荷が上がったとき、原因が「読み取りの多さ」にあることはよくあります。一覧画面の表示や集計のクエリが大量に流れると、同じインスタンスで処理している書き込みまで待たされ、更新の応答が遅くなります。

このとき考えるべきなのは、読み取りを別のインスタンスに逃がすことです。Amazon Aurora では、同じクラスターに Aurora レプリカ（リーダーインスタンス）を足し、アプリケーションが読み取りをリーダーエンドポイント、書き込みをクラスターエンドポイントへ送るように分けます。Aurora レプリカはライターとストレージを共有しているため、データのコピーを持たずに読み取りを肩代わりできます。

この記事では、読み取りの負荷を逃がす方法（Aurora レプリカ、RDS のリードレプリカ、マルチ AZ のスタンバイ、キャッシュ）の違いと、Aurora のエンドポイントの使い分けを整理します。実践では、ライターだけの Aurora クラスターにリーダーを足し、2 つのエンドポイントで接続先と読み取り専用かどうかが変わることを確かめます。

クラウドおさる

猿山の帳場で、バナナの出し入れの記帳と在庫の問い合わせを 1 匹がさばいていたら、記帳がいつまでも終わらないでござる。今日は問い合わせ係を別に立てて、窓口を分けるところまで確かめるでござるよ。

この記事のメリット

• 読み取りの負荷を逃がす方法（Aurora レプリカ・RDS リードレプリカ・マルチ AZ のスタンバイ・キャッシュ）を使い分けられるようになる
• Aurora レプリカがストレージを共有する仕組みと、レプリカラグの目安が分かる
• クラスターエンドポイント・リーダーエンドポイント・インスタンスエンドポイントの役割を説明できるようになる
• リーダーエンドポイントが「接続」を振り分ける仕組みであることと、その注意点が分かる
• Aurora レプリカがフェイルオーバー先にもなることと、優先度の考え方が分かる

執筆者とキャラクター紹介

執筆者：土肥（とひ）

株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる

クラウドおさる

はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。

クラウドおさる

基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。

クラウドおさる

猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。

技術解説

前提知識先に基礎編で手を動かしておくと、この記事がすっと入ります

Amazon RDS でデータベースを作成し EC2 から接続するこの記事では：Aurora クラスターのライターを作り、EC2 から接続する Amazon ElastiCache でキャッシュを置いて読み込みを速くするこの記事では：読み取りをキャッシュに逃がす方法と比べる

読み取りの負荷を逃がす方法

読み取りが書き込みの足を引っ張っているとき、候補になる方法は複数あります。似た名前のものが多いので、「読み取りに使えるか」で区別します。

Aurora を使っているなら、まず候補になるのは Aurora レプリカです。別の Aurora クラスターを作ってつなぐ必要はなく、同じクラスターにリーダーを足すだけで済みます。

クラウドおさる

マルチ AZ のスタンバイは、控えにいても問い合わせには答えない当番でござる。「読み取りを分けたい」ときに選ぶのは、リーダーとして窓口に立てるほうでござるぞ。

Aurora レプリカの仕組み

Aurora の DB クラスターは、1 台のライター（プライマリインスタンス）と、最大 15 台の Aurora レプリカで構成できます。

• ライターと Aurora レプリカは、クラスターボリュームのデータを 1 つの論理ボリュームとして共有する。レプリカごとにデータのコピーを持たないため、レプリカを足すときの追加の作業は小さい
• ライターに書き込まれたデータは、複数の AZ にまたがる 6 つのストレージノードに同期的に複製される
• Aurora レプリカは読み取り専用で、書き込みはライターが処理する
• ライターが書き込んでから Aurora レプリカで読めるまでのラグは、通常 100 ミリ秒未満。書き込みが非常に多いときは増えることがある

Aurora レプリカは、ライターが使えなくなったときのフェイルオーバー先にもなります。

エンドポイントの使い分け

Aurora のクラスターには、用途の違うエンドポイントがあります。アプリケーション側で、書き込みと読み取りの接続先を分けて設定する必要があります。

リーダーエンドポイントの振り分けは接続単位で、クエリ単位ではありません。1 本の接続を張りっぱなしにすると、その接続のクエリはずっと同じレプリカに届きます。クエリごとに読み取りを分散させたい場合は、クエリごとにリーダーエンドポイントへ新しい接続を開きます。

クラウドおさる

リーダーエンドポイントは「窓口の案内係」で、来た客をどの係に通すかを決めるのは最初の 1 回だけでござる。同じ客が居座れば、ずっと同じ係が相手をするのでござるな。

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

• ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
• ✓未経験から入社した社員の声を含む社員アンケートを掲載
• ✓応募フォームから 1 分で応募できます

採用ページを見る

実践

ハンズオンガイド5 ステップ画面 5 枚

コンソールの横に開いて、チェックしながら進めましょう。

ガイドを開く

別タブで開きます。チェックはこのブラウザに保存されます。

ライターだけで動いている Aurora MySQL クラスターにリーダーを 1 台追加し、EC2 からクラスターエンドポイントとリーダーエンドポイントの両方に接続して、つながる先と読み取り専用かどうかを確かめます。

前提条件

• リージョン: ap-northeast-1（東京）
• RDS・EC2・Systems Manager の操作権限を持つ IAM ユーザーまたはロールでコンソールにログイン済みであること

以下のリソースが作成済みであることを前提とします。Aurora クラスターには、まだライターが 1 台あるだけです。

まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。

このハンズオンで作成するリソースは以下のとおりです。

Aurora の DB インスタンスは、起動している間ずっと 1 台ごとに課金されます。リーダーを足すとそのぶん料金が増えます。検証が終わったら必ず削除してください。

手順 1: リーダーを足す前のエンドポイントを確かめる

AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。

上部の検索バーに RDS と入力し、「Aurora and RDS」を選択します。左側ナビゲーションの「データベース」を選択し、aurora-lab-cluster の配下に aurora-lab-writer（ロール: ライターインスタンス）だけがあることを確認します。

aurora-lab-cluster を開き、「接続とセキュリティ」タブを選択します。「エンドポイントタイプ」が クラスターエンドポイント の状態で、「接続先」を ライター と リーダー に切り替えると、表示される接続コマンドのホスト名が変わります。ライターは aurora-lab-cluster.cluster-…、リーダーは aurora-lab-cluster.cluster-ro-… です。リーダーがまだ無いため、この時点ではリーダーエンドポイントもライターに接続します。

手順 2: リーダーを追加する

aurora-lab-cluster の画面右上の「アクション」→「リーダーの追加」をクリックします。「リーダーの追加」の画面で、以下を設定します。

• DB インスタンス識別子: aurora-lab-reader-1
• DB インスタンスクラス: バースト可能クラス の db.t4g.medium（デフォルト）
• アベイラビリティーゾーン: ap-northeast-1c（デフォルトは「指定なし」）
• パブリックアクセス: パブリックアクセス不可（デフォルト）

その他の項目はデフォルトのままにして、「リーダーを追加」をクリックします。作成には 10 分ほどかかります。

aurora-lab-reader-1 のステータスが「利用可能」になり、ロールが「リーダーインスタンス」になったことを確認します。

手順 3: 2 つのエンドポイントに接続して違いを確かめる

上部の検索バーに EC2 と入力し、「EC2」を選択します。左側ナビゲーションの「インスタンス」から aurora-lab-client を選択し、「接続」→「Session Manager」タブ→「接続」をクリックします。

開いたターミナルで、次のコマンドを実行します。エンドポイントはクラスターの情報から、パスワードは Secrets Manager から取得します。パスワードは画面に表示せず、環境変数 MYSQL_PWD で mysql クライアントに渡します。

export AWS_DEFAULT_REGION=ap-northeast-1
WRITER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].Endpoint' --output text)
READER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].ReaderEndpoint' --output text)
SECRET_ARN=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].MasterUserSecret.SecretArn' --output text)
export MYSQL_PWD=$(aws secretsmanager get-secret-value --secret-id "$SECRET_ARN" \
    --query SecretString --output text | jq -r .password)

export AWS_DEFAULT_REGION=ap-northeast-1
WRITER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].Endpoint' --output text)
READER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].ReaderEndpoint' --output text)
SECRET_ARN=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab-cluster \
    --query 'DBClusters[0].MasterUserSecret.SecretArn' --output text)
export MYSQL_PWD=$(aws secretsmanager get-secret-value --secret-id "$SECRET_ARN" \
    --query SecretString --output text | jq -r .password)

それぞれのエンドポイントに接続し、つながったインスタンスと、読み取り専用かどうかを表示します。

mysql -h "$WRITER" -u admin -e "SELECT @@aurora_server_id AS server, @@innodb_read_only AS read_only;"
mysql -h "$READER" -u admin -e "SELECT @@aurora_server_id AS server, @@innodb_read_only AS read_only;"

mysql -h "$WRITER" -u admin -e "SELECT @@aurora_server_id AS server, @@innodb_read_only AS read_only;"
mysql -h "$READER" -u admin -e "SELECT @@aurora_server_id AS server, @@innodb_read_only AS read_only;"

クラスターエンドポイントでは server が aurora-lab-writer、read_only が 0 になります。リーダーエンドポイントでは server が aurora-lab-reader-1、read_only が 1 になります。

リーダーが「利用可能」になった直後は、リーダーエンドポイントの DNS がまだライターを指していて、server が aurora-lab-writer になることがあります。今回は切り替わるまでに数分かかりました。その場合は少し待ってから実行し直します。

手順 4: 書き込みはライター、読み取りはリーダーで行う

クラスターエンドポイントでテーブルを作り、データを書き込みます。

mysql -h "$WRITER" -u admin -e "
CREATE DATABASE IF NOT EXISTS lab;
CREATE TABLE IF NOT EXISTS lab.orders (id INT AUTO_INCREMENT PRIMARY KEY, item VARCHAR(20));
INSERT INTO lab.orders (item) VALUES ('banana'), ('apple');"

mysql -h "$WRITER" -u admin -e "
CREATE DATABASE IF NOT EXISTS lab;
CREATE TABLE IF NOT EXISTS lab.orders (id INT AUTO_INCREMENT PRIMARY KEY, item VARCHAR(20));
INSERT INTO lab.orders (item) VALUES ('banana'), ('apple');"

続けて、リーダーエンドポイントで読み取ります。ライターで書いたデータが、すぐにリーダーからも読めます。

mysql -h "$READER" -u admin -e "SELECT * FROM lab.orders;"

mysql -h "$READER" -u admin -e "SELECT * FROM lab.orders;"

最後に、リーダーエンドポイントで書き込みを試します。

mysql -h "$READER" -u admin -e "INSERT INTO lab.orders (item) VALUES ('grape');"

mysql -h "$READER" -u admin -e "INSERT INTO lab.orders (item) VALUES ('grape');"

読み取り専用モードで動いているため実行できない、という ERROR 1836 (HY000) at line 1: Running in read-only mode が返ります。リーダーは読み取り専用なので、書き込みはクラスターエンドポイントに送る必要があります。

クラウドおさる

「読み取りが書き込みを遅くしている」と言われたら、読み取り用の窓口を足して接続先を分ける話でござる。マルチ AZ のスタンバイやキャッシュと取り違えず、「読めるか」「エンドポイントは何か」で見分けるのが肝でござるな。

まとめ

• Aurora レプリカはクラスターボリュームを共有し、データのコピーを持たない。ラグは通常 100 ミリ秒未満で、1 クラスターに最大 15 台
• 書き込みはクラスターエンドポイント、読み取りはリーダーエンドポイント。アプリケーション側で接続先を分ける
• リーダーエンドポイントは接続単位で振り分ける。クエリ単位では分散しない
• Aurora レプリカはフェイルオーバー先にもなる。優先度は tier-0（最も高い）〜 tier-15

参照先

• Amazon Aurora でのレプリケーション – Amazon Aurora
• Amazon Aurora エンドポイント接続 – Amazon Aurora
• Amazon Aurora のリーダーエンドポイント – Amazon Aurora
• DB クラスターに Aurora レプリカを追加する – Amazon Aurora
• Amazon Aurora の高可用性 – Amazon Aurora
• DB インスタンスのリードレプリカの操作 – Amazon Relational Database Service
• Amazon RDS のマルチ AZ DB クラスターデプロイ – Amazon Relational Database Service

キャリア相談

独学の先に、AWS の仕事がある ── ジュニアおさるのキャリア相談

CLF には受かったけれど、次に何をすればいいのか分からない。独学で AWS を学ぶジュニアおさるの相談に、株式会社ジェニュイン代表の土肥が答えています。

• ✓資格はゴールか、CLF の次に何から手を付けるか
• ✓EC2 の次に作ってみる構成と、IaC・コスト管理
• ✓実務経験ゼロでも、面接で話せる「これまで」の作り方

相談を読む

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

• ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
• ✓未経験から入社した社員の声を含む社員アンケートを掲載
• ✓応募フォームから 1 分で応募できます

採用ページを見る