[アップデート] 32秒でパフォーマンス回復!Aurora PostgreSQL でクラスタキャッシュ管理がサポートされました! #AWSSummit

昨日、Aurora PostgreSQL においてフェイルオーバー後のパフォーマンスを改善するクラスタキャシュ管理に関する機能アップデートがありましたので紹介します。

何がうれしいのか

Amazon Aurora はマスターのインスタンスで障害が発生した場合、リードレプリカのインスタンスが昇格するかたちでフェイルオーバーすることが出来ます。これまでクラスタキャシュ管理がない場合に、フェイルオーバーによって昇格したインスタンスには、マスターが使用していたウォームキャッシュは引き継がれていないため、ストレージから読み込む必要がありパフォーマンスが一時的に低下してしまいます。

クラスタキャシュ管理のサポートによって、あらかじめ指定されていた特定のリードレプリカにのみウォームキャッシュを同期することが出来るようになりました。これにより、フェイルオーバーによって昇格した場合でも直ちにパフォーマンスを発揮することが可能となりました。

AWS Summit Tokyo 2019 Day2 のセッション「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」の中で紹介されたパフォーマンス測定によれば

  • クラスタキャッシュ管理がない状態でフェイルオーバー
    • 32秒でデータベース起動
    • パフォーマンスが90%回復するっまでに340秒
  • クラスタキャッシュ管理がある状態でフェイルオーバー
    • 32秒でデータベース起動し、パフォーマンスは回復

(お察しのとおり記事タイトルの「32秒」はココから来ています。)

ほぼデータベースの起動と同時にもとどおり、といった内容ですね。すばらしい。

【AWS Summit Tokyo 2019 セッションレポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit

試してみる

こんな数字みせられたら設定しておかない理由はないですね。ということで設定手順を公式ガイドに従ってまとめました。(本記事では設定手順までであり、パフォーマンスの検証などは行っておりませんので、あしからず)

検証環境

  • 東京リージョン
  • Aurora PostgreSQL
  • db.r5.large

注意点

クラスタキャッシュ管理の設定はクラスターパラメータグループで行います。デフォルトのパラメータグループでは値の変更ができないため、デフォルト以外のクラスターパラメータグループが必要です。

クラスタキャッシュ管理の有効化

RDS ダッシュボードから[パラメータグループ]を開き、対象の Aurora PostgreSQL クラスターが使用しているクラスターパラメータグループを選択し、[パラメータグループアクション]から[編集]をクリックします。

apg_ccm_enabled の値を 1 に設定し、[変更の保存]をクリックします。

書き込み DB の優先順位設定

RDS ダッシュボードから対象の Aurora PostgreSQL クラスターを展開し、書き込み DB インスタンスを選択。[変更]をクリックします。

フェイルオーバーパネルの優先度を[範囲-0]に変更し、直後に適用するには[すぐに適用]を選んで[DB インスタンスの変更]をクリックします。

読み込み DB の優先順位設定

同じ Aurora PostgreSQL クラスターから、1つの読み込み DB インスタンスを選択。[変更]をクリックします。

同様にフェイルオーバーパネルの優先度を[範囲-0]に変更し、直後に適用するには[すぐに適用]を選んで[DB インスタンスの変更]をクリックします。

今回は読み込み DB が1台でしたが複数ある場合は、この作業によって書き込み DB インスタンスに昇格される順序が上位になります。

設定は以上です!

さいごに

このアップデートでどれくらい改善されるのかなーと疑問に思ってたところ、本日の Summit で具体的な数字が出てきて「へぇー!」と思ったので記事にしてみました。Aurora PostgreSQL のフェイルオーバー直後のパフォーマンスでもしお悩みの方がおられましたら、試してみてはいかがでしょうか。

以上!大阪オフィスの丸毛(@marumo1981)でした!