🚀

WordPressでAmazon Auroraのパフォーマンスは最大？可用性ある？クラスターエンドポイントの設定方法とHyperDB利用

2023/07/04に公開

WordPress

この記事で話したいこと

Amazon Auroraの特徴のひとつとして、複数のインスタンスから1つのクラスターが構成され、データベースとして（高パフォーマンス・高可用性を発揮して）機能するということがあげられます。これに付随して、Auroraにアクセスする際には、いくつかの接続方法や接続先として指定できるエンドポイントが存在します。今回はこの点に着目して、WordPressのDBとしてAmazon Auroraを利用する際には、例えばどういうアクセスの場合に、どの接続先を利用するかという設定をすれば、Auroraを最大限活用することができるのか（できるのではないだろうか？自信なさげ）という話になります。

いきなりの結論

基本的な情報の整理や、筆者の個人語りは一旦置いておいて、まず（こういうことなのではないだろうか？的な）結論です。

WordPress では基本的に一つの接続先しか設定できない（冗長構成はそもそも想定されていない）
基本的にできないのであれば、拡張機能（HyperDBというプラグインがよさそう）を利用する
HyperDBの設定で、読み込み時（または書き込み時）にのみ利用する接続先エンドポイントを設定することで、負荷を軽減し、パフォーマンスを向上する。
Amazon Aurora 独自のクラスター（複数インスタンスで構成）単位のエンドポイントを指定することで、フェイルオーバーやプライマリ（ライター）インスタンス昇格が自動で実行される（高可用性の実現！！）。

手順・設定例

プラグインでHyperDBをインストールして有効化する
wp-config.phpでdefine('DB_CONFIG_FILE', ABSPATH . 'db-config.php');と記載する
wp-config.phpと同じディレクトリにdp-config.phpを作成し、以下のように記載する

db-config.php

<?php
$wpdb->add_database(array(
	# Auroraライターエンドポイント。.clusterがクラスター単位のエンドポイントの目印。
        'host'     => 'XXAurora_IdXX.cluster-XXXXXX.XXRegionXX.rds.amazonaws.com',
        'user'     => 'wpuser',
        'password' => 'wppassword',
        'name'     => 'wordpressdb',
        'write'    => 1, # 書き込み時、最優先（1）のDBとする
        'read'     => 0, # 読み込み時、対象外（0）のDBとする。
));

$wpdb->add_database(array(
	# Auroraリーダーエンドポイント。.cluster-roが目印。read only。
        'host'     => 'XXAurora_IdXX.cluster-ro-XXXXXX.XXRegionXX.rds.amazonaws.com',
        'user'     => 'wpuser',
        'password' => 'wppassword',
        'name'     => 'wordpressdb',
        'write'    => 0, # 書き込み時、対象外（0）のDBとする
        'read'     => 1, # 読み込み時、最優先（1）のDBとする
));

本記事に関連するAmazon Auroraの設定や機能の自分なりまとめ

Amazon Auroraのエンドポイントには以下のような種類があります。

ライターインスタンスエンドポイント（1つ・変動）
リーダーインスタンスエンドポイント（0以上）
ライター（クラスタ-）エンドポイント（1つ・固定）
リーダー（クラスター）エンドポイント（1つ・固定）
カスタムエンドポイント

今回の話に関わる部分に限定して整理すれば、

クラスター内の特定のインスタンスにアクセスしたい場合:「インスタンス」と名の付くエンドポイント
クラスター内のインスタンスを特に指定せず、内部的に上手い具合にアクセス先を変えてほしい場合: （クラスター）エンドポイント
「読み込み時にのみ」アクセスの場合：「リーダー」と名の付くもの
「書き込み時に」アクセスしたい場合：「ライター」と名の付くもの

となります。
これを踏まえると、Auroraを利用する際は、

（クラスター）エンドポイントで指定すること
読み込み時と書き込み時でエンドポイントを変えて指定すること

というのが原則になるのかなと、思っています。

この記事作成のきっかけ（なぜか最後に）

Amazon Aurora 使いこなせていますか？（挙動不審）
筆者は正直自信がありません。この記事が正しいのかどうかも。資格学習やハンズオンを通して、ある程度Amazon Auroraの特徴やメリットは理解できているつもりです。ただ実装となるとまた話は別。今回はWordPressのDBとして、Amazon Auroraを利用する際に、ネットで「（AWS）Aurora WordPress （エンドポイント）」などと検索して出てくる記事の設定や手順ではどうにも最大限にAuroraのメリットを発揮できていると確信を持てなかったので、これでいいのかな？と思いながらも、設定例を紹介してみました（チャレンジ！）。ここまで読んで頂き、ありがとうございました。

2023年6月28日現在、検索でヒットする記事に紹介されている設定としては

Auroraのクラスターエンドポイントではなく、（ライター）インスタンスのエンドポイントを指定している
AuroraクラスターのライターエンドポイントのみをWordPressで設定している

となっておりました。
これらはすべて、WordPressを「稼働させるまで」であれば問題なく動作します。
ただ稼働後、前者であればライターインスタンスが潰れてリーダーインスタンスがライターに昇格した際にはサービス停止になりますし、後者はリーダーインスタンスの存在はあくまでも何かあったときにライターインスタンスに昇格できる要員としてしか機能せず、リードレプリカ的にパフォーマンスを向上する機能は発揮しないことになります。