コンテンツにスキップ

AWS Aurora＠AWSリソース

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. AWS Auroraとは

AWS RDSをよりマネージドにしたAWSリソースである。


02. セットアップ

コンソール画面の場合

▼ DBエンジン

設定項目 説明 補足
エンジンタイプ ミドルウェアのDBMSの種類を設定する。
エディション エンジンバージョンでAWS Auroraを選択した場合の互換性を設定する。
エンジンバージョン DBエンジンのバージョンを設定する。DBクラスター内の全てのDBインスタンスに適用される。 ・AWS Auroraであれば、SELECT AURORA_VERSION()を使用して、エンジンバージョンを確認できる。

▼ AWS AuroraのDBクラスター

ベストプラクティスについては、以下のリンクを参考にせよ。

設定項目 説明 補足
レプリケーション 単一のプライマリーインスタンス (シングルマスター) または複数のプライマリーインスタンス (マルチマスター) とするかを設定する。 フェイルオーバーを利用したダウンタイムの最小化時に、マルチマスターであれば変更の順番を気にしなくてよくなる。ただし、AWS AuroraのDBクラスターをクローンできないなどのデメリットもある。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html#aurora-multi-master-terms
AWS AuroraのDBクラスター識別子 AWS AuroraのDBクラスター名を設定する。 インスタンス名は、最初に設定できず、AWS RDSの作成後に設定できる。
VPCとサブネットグループ AWS AuroraのDBクラスターを配置するVPCとサブネットを設定する。 DBが配置されるサブネットはプライベートサブネットにする、これには、data storeサブネットと名付ける。アプリケーション以外は、踏み台サーバー経由でしかDBにリクエストできないようにする。
subnet_component-type
パラメーターグループ グローバルオプションを設定する。 デフォルトを使用せずに自前定義する場合、事前に作成しておく必要がある。クラスターパラメーターグループとインスタンスパラメーターグループがあるが、全てのインスタンスに同じパラメーターループを設定する必要があるなため、クラスターパラメーターを使用すれば良い。各パラメーターに適用タイプ (dynamic/static) があり、dynamicタイプは設定の適用に再起動が必要である。新しく作成したクラスタパラメーターグループにて以下の値を設定すると良い。
・time_zone=Asia/Tokyo
・character_set_client=utf8mb4
・character_set_connection=utf8mb4
・character_set_database=utf8mb4
・character_set_results=utf8mb4
・character_set_server=utf8mb4
・server_audit_logging=1 (監査ログをAWS CloudWatchに送信するか否か)
・server_audit_logs_upload=1
・general_log=1 (通常クエリログをAWS CloudWatchに送信するか否か)
・slow_query_log=1 (スロークエリログをAWS CloudWatchに送信するか否か)
・long_query_time=3 (スロークエリと見なす最短秒数)
DB認証 DBに接続するための認証方法を設定する。 AWS Auroraの各DBインスタンスに異なるDB認証を設定できるが、全てのAWS AuroraのDBインスタンスに同じ認証方法を設定すべきなため、AWS AuroraのDBクラスターでこれを設定すれば良い。
マスタユーザー名 DBのroot権限の実行ユーザーを設定
マスターパスワード DBのroot権限の実行ユーザーのパスワードを設定
暗号化キー AWS KMSを使用して、データを暗号化して保管する。
バックアップ保管期間 AWS AuroraのDBクラスター がバックアップを保管する期間を設定する。 7日間にしておく。
ログのエクスポート AWS CloudWatch Logsに送信するデータエンジン (例：MySQL) のログを設定する。データベースエンジンの一般ログ、エラーログ、スロークエリログ、監査ログなどを選択できる。 全てのログを選択するとよい。
セキュリティグループ AWS AuroraのDBクラスターのセキュリティグループを設定する。 コンピューティングからのリクエストのみを許可するように、これらのプライベートIPアドレス (*.*.*.*/32) を設定する。
認証機関 AWS AuroraのDBクラスターに紐づけるSSL証明書を署名するルート認証局を設定する。 アプリケーションがAWS AuroraのDBクラスターにHTTPSで通信する場合に必要である。
削除保護 AWS AuroraのDBクラスターの削除を防ぐ。 AWS AuroraのDBクラスターを削除するとクラスターボリュームも削除されるため、これを防ぐ。補足として、AWS AuroraのDBクラスターの削除保護になっていてもAWS AuroraのDBインスタンスは削除できる。AWS AuroraのDBインスタンスを削除しても、再作成すればクラスターボリュームに接続されて元のデータにリクエストを送信できる。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DeleteCluster.html#USER_DeletionProtection

▼ AWS AuroraのDBインスタンス

ベストプラクティスについては、以下のリンクを参考にせよ。

設定項目 説明 補足
インスタンスクラス AWS AuroraのDBインスタンスのスペックを設定する。サーバーレス、メモリ最適化、バースト可能などを選択できる。 バースト可能クラスを選択するとよい。補足として、AuroraのDBサイズは自動的にスケーリングするため、設定する必要がない。
パブリックアクセス AWS AuroraのDBインスタンスにIPアドレスを割り当てるか否かを設定する。
キャパシティタイプ
マルチAZ配置 プライマリーインスタンスとは別に、リードレプリカをマルチAZ配置で追加するか否かを設定する。 後からでもリードレプリカを追加できる。また、フェイルオーバー時にリードレプリカが存在していなければ、昇格後のプライマリーインスタンスが自動的に作成される。
最初のDB名 AWS AuroraのDBインスタンスに自動的に作成されるDB名を設定
マイナーバージョンの自動アップグレード AWS AuroraのDBインスタンスのDBエンジンのバージョンを自動的に更新するかを設定する。 開発環境では有効化、本番環境とステージング環境では無効化しておく。開発環境で新バージョンに問題が起こらなければ、ステージング環境と本番環境にも適用する。

OSの隠蔽

▼ OSの隠蔽とは

AWS Auroraは、EC2内にDBMSが稼働したものであるが、このほとんどが隠蔽されている。

そのためDBサーバーのようには操作できず、OSのバージョン確認やSSH公開鍵認証を行えない。

▼ 確認方法

Linux x86_64 (AMD64) が使用されているところまでは確認できるが、Linuxのバージョンは隠蔽されている。

AWS RDSでも確認方法は同じである。

-- AWS Auroraの場合
SHOW variables LIKE '%version%';

+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| aurora_version          | 2.09.0                       |
| innodb_version          | 5.7.0                        |
| protocol_version        | 10                           |
| slave_type_conversions  |                              |
| tls_version             | TLSv1,TLSv1.1,TLSv1.2        |
| version                 | 5.7.12-log                   |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | Linux                        |
+-------------------------+------------------------------+


接続方法

▼ SSH公開鍵認証を使用する場合

SSH公開鍵認証を使用する場合、ユーザーが自前でDB接続者を管理する必要がある。

▼ AWS SSM Session ManagerのSSHセッションを使用する場合

▼ AWS SSM Session ManagerのStartPortForwardingSessionToRemoteHostを使用する場合

AWS SSM Session Managerの認証を使用する場合、AWS IAMでDB接続者を管理する。

事前に、踏み台AWS EC2のセキュリティグループのインバウンドルールでポート番号を開放しておく。

また、AWS Session Managerプラグインをインストールしておく。

その後、aws ssmコマンドでポートフォワーディングを実行する。

# ローカルPC

# ポートフォワーディングのコマンドを実行する (事前にAWS Session Managerプラグインをインストールしないとエラーになる)
$ aws ssm start-session --target <踏み台のAWS EC2インスタンスID> \
    --document-name AWS-StartPortForwardingSessionToRemoteHost \
    --parameters '{"host":["<AWS Auroraのクラスターエンドポイント>"],"portNumber":["<踏み台AWS EC2インスタンスのポート番号>"], "localPortNumber":["<ローカルPCのポート番号>"]}'

# 別のターミナルでmysqlコマンドを実行する
$ mysql -u <AWS Auroraのユーザー> -p<AWS Auroraのパスワード> -h localhost -P <ローカルPCのポート番号>


03. AWS AuroraのDBクラスター

AWS AuroraのDBクラスターとは

DBエンジンにAWS Auroraを選択した場合にのみ使用できる。

AWS AuroraのDBインスタンスとクラスターボリュームから構成されている。

コンピューティングとして動作するAWS AuroraのDBインスタンスと、ストレージとして動作するクラスターボリュームが分離されているため、AWS AuroraのDBインスタンスが誤って全て削除されてしまったとしても、データを守れる。

また、両者が分離されていないエンジンタイプと比較して、再起動が早いため、再起動に伴うダウンタイムが短い。

aurora-db-cluster


空のAWS AuroraのDBクラスター

▼ 空のAWS AuroraのDBクラスターとは

コンソール画面にて、AWS AuroraのDBクラスター内の全てのAWS AuroraのDBインスタンスを削除すると、AWS AuroraのDBクラスターも自動的に削除される。

一方で、AWS-APIをコールして全てのAWS AuroraのDBインスタンスを削除する場合、AWS AuroraのDBクラスターは自動的に削除されずに、空の状態になる。

例えば、Terraformを使用してAWS AuroraのDBクラスターを作成する時に、インスタンスの作成に失敗するとAWS AuroraのDBクラスターが空になる、

これは、TerraformがAWS-APIをコールした作成を行っているためである。


04. AWS AuroraのDBインスタンス

AWS AuroraのDBインスタンスとは

コンピューティング機能を持ち、クラスターボリュームを操作できる。


AWS AuroraのDBインスタンスの種類

プライマリーインスタンス リードレプリカ
ロール 読み出し/書き込みインスタンス 読み出しオンリーインスタンス
CRUD制限 制限なし。ユーザーの認可スコープに依存する。 ユーザーの認可スコープに関係なく、READしか実行できない。
エンドポイント AWS Auroraの各DBインスタンスに、リージョンのイニシャルに合わせたエンドポイントが割り振られる。 AWS Auroraの各AWS AuroraのDBインスタンスに、リージョンのイニシャルに合わせたエンドポイントが割り振られる。
データ同期 AWS AuroraのDBクラスターに対するデータ変更を受けつける。 読み出し/書き込みインスタンスのデータの変更が同期される。


エンドポイント

rds_endpoint

エンドポイント名 役割 送信先 エンドポイント：ポート番号 説明
クラスターエンドポイント 書き込み/読み出し プライマリインスタンスのみ <AWS AuroraのDBクラスター名>.cluster-<id>.ap-northeast-1.rds.amazonaws.com:<ポート番号> プライマリーインスタンスに通信できる。プライマリーインスタンスがダウンし、フェイルオーバーによってプライマリーインスタンスとリードレプリカが入れ替わった場合、エンドポイントの転送先は新しいプライマリーインスタンスに変更される。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Cluster
リーダーエンドポイント 読み出し 複数のリードレプリカに分散 <AWS AuroraのDBクラスター名>.cluster-ro-<id>.ap-northeast-1.rds.amazonaws.com:<ポート番号> リードレプリカに通信できる。AWS AuroraのDBインスタンスが複数ある場合、クエリが自動的に割り振られる。フェイルオーバーによってプライマリーインスタンスとリードレプリカが入れ替わった場合、エンドポイントの転送先は新しいプライマリーインスタンスに変更される。もしリードレプリカが全てダウンし、プライマリーインスタンスしか稼働していない状況の場合、プライマリーインスタンスに転送するようになる。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Reader
インスタンスエンドポイント 書き込み/読み出し (指定したAWS AuroraのDBインスタンスによる) 特定のAWS AuroraのDBインスタンス <AWS AuroraのDBインスタンス名>.cwgrq25vlygf.ap-northeast-1.rds.amazonaws.com:<ポート番号> 選択したAWS AuroraのDBインスタンスに通信できる。フェイルオーバーによってプライマリーインスタンスとリードレプリカが入れ替わっても、エンドポイントそのままなため、アプリケーションが影響を付ける。非推奨である。
カスタムエンドポイント


データベースエンジンのログ

▼ スロークエリログ

AWS CloudWatch Logsの/aws/rds/cluster/<AWS AuroraのDBクラスター名>/slowqueryというロググループにスロークエリログが出力される。

▼ エラークエリログ

AWS CloudWatch Logsの/aws/rds/cluster/<AWS AuroraのDBクラスター名>/errorというロググループにエラーログが出力される。


05. アップグレード

ZDP (ゼロダウンタイムパッチ適用)

zero-downtime-patching

AWS Auroraをエンジンバージョンに選択した場合に使用できる。

特定の条件下のみで、アプリケーションとプライマリーインスタンスの接続を維持したまま、プライマリーインスタンスのパッチバージョンをアップグレードできる。

ゼロダウンタイムパッチ適用が発動した場合、AWS RDSのイベントが記録される。

ただし、この機能に頼り切らない方が良い。

ゼロダウンタイムパッチ適用の発動はAWSから事前にお知らせされるわけでもなく、ユーザーが条件を見て発動の有無を判断しなければならない。

また、実際に発動していても、ダウンタイムが発生した事例が報告されている。

ゼロダウンタイムパッチ適用時、以下の手順でエンジンバージョンがアップグレードされる。

(1)

プライマリーインスタンスのエンジンがアップグレードされ、この時にダウンタイムが発生しない代わりに、5秒ほどプライマリーインスタンスの性能が低下する。

(2)

リードレプリカが再起動され、この時に20～30秒ほどダウンタイムが発生する。これらの仕組みのため、アプリケーションでは読み出しエンドポイントを接続先として使用しないようにする必要がある。


アップグレード可能かのバリデーション

AWS AuroraにSSH接続した上で、DBに対して以下のコマンドを実行すると、v5.7からv8系へのアップグレードで問題が起こるかを解析できる

ただ、アプリ側のSQLのロジックを解析することはできず、あくまでMySQLの設定値のみを解析でき、廃止予定のロジックを使っているかまでは見つけられない。

$ mysqlsh util.checkForServerUpgrade()


ダウンタイム

▼ ダウンタイムとは

AWS Auroraでは、設定値 (例：OS、エンジンバージョン、MySQL) のアップグレード時に、AWS AuroraのDBインスタンスの再起動が必要である。

再起動に伴ってダウンタイムが発生し、アプリケーションからDBに接続できなくなる。

この間、アプリケーションの利用者に与える影響を小さくできるように、計画的にダウンタイムを発生させる必要がある。

▼ ダウンタイムの発生条件

AWS RDSにはダウンタイムに関する情報が多いが、AWS Auroraには情報が少ない。

ただし、経験上同じ項目でダウンタイムが発生しているため、他の項目についてもRDSのダウンタイムも参考になる。

変更する項目 ダウンタイムの有無 補足
エンジンバージョン あり 20～30秒のダウンタイムが発生する。この時間は、ワークロード、クラスターサイズ、バイナリログデータのサイズ、ゼロダウンタイムパッチ適用の発動可否、によって変動する。
・https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.html
・https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.AMVU
また、メジャーバージョンのアップグレードには10分のダウンタイムが発生する。
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.Major.Overview

▼ エンジンタイプによるダウンタイムの最小化

コンピューティングとストレージが分離しているAWS Auroraはエンジンタイプの中でもダウンタイムが短い。

▼ ダウンタイムの計測例

アプリケーションにリクエストを送信する方法と、AWS RDSにクエリを直接的に送信する方法がある。

レスポンスとAWS RDSイベントログから、ダウンタイムを計測する。

＊実装例＊

AWS Aurora MySQLのアップグレードに伴うダウンタイムを計測する。

踏み台サーバーを経由してAWS RDSに接続し、現在時刻を取得するSQLを送信する。

この時、for文やwatchコマンドを使用する。

ただし、watchコマンドはプリインストールされていない可能性がある。

平常アクセス時のも同時に実行することにより、より正確なダウンタイムを取得する。

また、ヘルスチェックの時刻を正しくロギングできるように、ローカルマシンから時刻を取得する。

#!/bin/bash

set -x

BASTION_HOST=""
BASTION_USER=""
DB_HOST=""
DB_PASSWORD=""
DB_USER=""
SECRET_KEY="~/.ssh/foo.pem"
SQL="SELECT NOW();"

ssh -o serveraliveinterval=60 -f -N -L 3306:${DB_HOST}:3306 -i ${SECRET_KEY} ${BASTION_USER}@${BASTION_HOST} -p 22

# 約15分間コマンドを繰り返す。
for i in {1..900}; do
  echo "---------- No. ${i} Local PC: $(date +"%Y-%m-%d %H:%M:%S") ------------" >> health_check.txt
  echo "$SQL" | mysql -u "$DB_USER" -P 3306 -p"$DB_PASSWORD" >> health_check.txt 2>&1
  # 1秒待機する。
  sleep 1
done

#!/bin/bash

set -x

BASTION_HOST=""
BASTION_USER=""
DB_HOST=""
DB_PASSWORD=""
DB_USER=""
SECRET_KEY="~/.ssh/foo.pem"
SQL="SELECT NOW();"

ssh -o serveraliveinterval=60 -f -N -L 3306:${DB_HOST}:3306 -i ${SECRET_KEY} ${BASTION_USER}@${BASTION_HOST} -p 22

# 1秒ごとにコマンドを繰り返す。
watch -n 1 'echo "---------- No. ${i} Local PC: $(date +"%Y-%m-%d %H:%M:%S") ------------" >> health_check.txt && \
  echo ${SQL} | mysql -u ${DB_USER} -P 3306 -p${DB_PASSWORD} >> health_check.txt 2>&1'

上記のシェルスクリプトにより、例えば次のようなMySQLのログを取得できる。

このログからは、15:23:09 〜 15:23:14の間で、接続に失敗していることを確認できる。

---------- No. 242 Local PC: 2021-04-21 15:23:06 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
NOW()
2021-04-21 06:23:06
---------- No. 243 Local PC: 2021-04-21 15:23:07 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
NOW()
2021-04-21 06:23:08
---------- No. 244 Local PC: 2021-04-21 15:23:08 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2026 (HY000): SSL connection error: error:00000000:lib(0):func(0):reason(0)
---------- No. 245 Local PC: 2021-04-21 15:23:09 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
---------- No. 246 Local PC: 2021-04-21 15:23:10 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
---------- No. 247 Local PC: 2021-04-21 15:23:11 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
---------- No. 248 Local PC: 2021-04-21 15:23:13 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
---------- No. 249 Local PC: 2021-04-21 15:23:14 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
---------- No. 250 Local PC: 2021-04-21 15:23:15 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
NOW()
2021-04-21 06:23:16
---------- No. 251 Local PC: 2021-04-21 15:23:16 ------------
mysql: [Warning] Using a password on the command line interface can be insecure.
NOW()
2021-04-21 06:23:17

アップグレード時のプライマリーインスタンスのAWS RDSイベントログは以下の通りで、ログによるダウンタイムは、再起動からシャットダウンまでの期間と一致することを確認する。

rds-event-log_primary-instance

補足として、リードレプリカは再起動のみを実行していることがわかる。

rds-event-log_read-replica


フェイルオーバー

▼ AWS Auroraのフェイルオーバーとは

プライマリーインスタンスで障害が起こった場合に、リードレプリカをプライマリーインスタンスに自動的に昇格する。

AWS AuroraのDBクラスター内の全てのAWS AuroraのDBインスタンスが同じAZに配置されている場合、あらかじめ異なるAZにリードレプリカを新しく作成する必要がある。

また、フェイルオーバー時に、もしAWS AuroraのDBクラスター内にリードレプリカが存在していない場合、異なるAZに昇格後のプライマリーインスタンスが自動的に作成される。

リードレプリカが存在している場合、これがプライマリーインスタンスに昇格する。

▼ フェイルオーバーによるダウンタイムの最小化

AWS AuroraのDBインスタンスがマルチAZ構成の場合、以下の手順を使用してダウンタイムを最小化できる。

(1)

アプリケーションの接続先をプライマリーインスタンスにする。

(2)

リードレプリカにダウンタイムの発生する変更を適用する。

AWS Auroraではフェールオーバーが自動的に実行される。

(3)

フェイルオーバー時に約1～2分のダウンタイムが発生する。

フェイルオーバーを使用しない場合、AWS AuroraのDBインスタンスの再起動でダウンタイムが発生する。

ただし、これよりは時間が短いため、相対的にダウンタイムを短縮できる。

▼ AWS AuroraのDBインスタンスの昇格優先順位

AWS Auroraの場合、フェイルオーバーによって昇格するAWS AuroraのDBインスタンスは次の順番で決定される。

AWS AuroraのDBインスタンスごとにフェイルオーバーの優先度 (0～15) を設定でき、優先度の数値の小さいAWS AuroraのDBインスタンスほど優先され、昇格対象になる。

優先度が同じだと、インスタンスクラスが大きいAWS AuroraのDBインスタンスが昇格対象になる。

インスタンスクラスが同じだと、同じサブネットにあるAWS AuroraのDBインスタンスが昇格対象になる。

(1)

優先度の順番

(2)

インスタンスクラスの大きさ

(3)

同じサブネット

▼ ダウンタイムを最小化できない場合

エンジンバージョンのアップグレードは両方のAWS AuroraのDBインスタンスで同時に実行する必要があるため、フェイルオーバーを使用できず、ダウンタイムを最小化できない。


B/G式アップグレード

アップグレード時に、新しいバージョンからなるAWS AuroraのDBクラスター (グリーン環境) を作成する。

クラスターエンドポイントを起点として、アプリのクエリの向き先を既存のAWS AuroraのDBクラスター (ブルー環境) から新AWS AuroraのDBクラスター (グリーン環境) に切り替える。

グリーン環境でアプリが問題なく動作すれば、既存のAWS AuroraのDBクラスター (ブルー環境) を削除する。


06. 負荷対策

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

AWS AuroraのDBインスタンスに応じたエンドポイントが用意されている。

アプリケーションからのCRUDの種類に応じて、アクセス先を振り分けることにより、負荷を分散させられる。

読み出しオンリーエンドポイントに対して、READ以外の処理を行うと、以下の通り、エラーとなる。

/* SQL Error (1290): The MySQL server is running with the --read-only option so it cannot execute this statement */


リードレプリカの手動追加、AWS Auto Scalingグループ

リードレプリカの手動追加もしくはAWS Auto Scalingグループによって、AWS Auroraに関するメトリクス (例：平均CPU使用率、平均DB接続数など) がターゲット値を維持できるように、リードレプリカの自動水平スケーリング (リードレプリカ数の増減) を実行する。

注意点として、AWS RDSのスケーリングは、ストレージサイズを増加させる垂直スケーリングであり、AWS Auroraのスケーリングとは仕様が異なっている。


クエリキャッシュの利用

MySQLやRedisのクエリキャッシュ機能を利用する。

ただし、MySQLのクエリキャッシュ機能は、バージョン8で廃止されることになっている。


ユニークキーまたはインデックスの利用

スロークエリを検出し、そのSQLで対象としているカラムにユニークキーやインデックスを設定する。

スロークエリを検出する方法として、AWS RDSのlong_query_timeパラメーターによる閾値や、EXPLAIN句による予想実行時間の比較などがある。

CloudWatch Logsインサイト上で、閾値以上の実行時間のスロークエリを実行時間の昇順で取得できる。

fields @timestamp, @message
| parse @message /Query_time:\s*(?<Query_time>[0-9]+(?:\.[0-9]+)?)\s*[\s\S]*?;/
| display @timestamp, Query_time, @message
| sort Query_time desc
| limit 100


テーブルを正規化し過ぎない

テーブルを正規化すると保守性が高まるが、アプリケーションのSQLでJOIN句が必要になる。

しかし、JOIN句を含むSQLは、含まないSQLと比較して、実行速度が遅くなる。

そこで、戦略的に正規化し過ぎないようにする。


インスタンスタイプのスケールアップ

インスタンスタイプをスケールアップさせることにより、接続過多のエラー (ERROR 1040 (HY000): Too many connections) に対処する。

補足として現在の最大接続数はパラメーターグループの値から確認できる。

コンソール画面からはおおよその値しかわからないため、SQLで確認した方が良い。

SHOW GLOBAL VARIABLES LIKE 'max_connections';

+-----------------+-------+
| Variable_name  | Value |
+-----------------+-------+
| max_connections | 640  |
+-----------------+-------+
1 row in set (0.00 sec)


07. イベント

コンソール画面ではイベントが英語で表示されているため、リファレンスも英語でイベントを探した方が良い。


08. AWS Aurora Global DB

AWS Aurora Global DBとは

リージョン間に跨いだAWS AuroraのDBクラスターから構成されている。

メインリージョンにあるプライマリークラスターのクラスターボリュームと、DRリージョンのセカンダリークラスターのクラスターボリュームのデータは、定期的に同期される。

プライマリーインスタンスは、プライマリークラスターのみに存在している。

aurora-db-cluster_global


クラスターボリュームのみのセカンダリーDBクラスター (ヘッドレスセカンダリーAWS AuroraのDBクラスター)

『ヘッドレスセカンダリーDBクラスター』ともいう。

コスト削減などを目的として、クラスターボリュームのみのセカンダリAWS AuroraのDBクラスターがある。

セカンダリーDBクラスターのリードレプリカを削除すると、ヘッドレスセカンダリーDBクラスターを作成できる。

aurora-db-cluster_global_secondary-headless


仕組み

▼ ウォームスタンバイ構成

ウォームスタンバイ構成の場合、メインリージョンにはプライマリーインスタンスとリードレプリカ (クラスターボリュームを含む) がおり、DRリージョンにはリードレプリカ (クラスターボリュームを含む) のみがいる。

メインリージョンで障害が起こった場合は、DRリージョンのリードレプリカがプライマリインスタンスに昇格する。

(1)

メインリージョンで障害が発生する。

(2)

DRリージョンのセカンダリークラスターがプライマリークラスターに昇格し、クラスター内のリードレプリカインスタンスがプライマリーインスタンスになる。

(3)

メインリージョンのプライマリーインスタンスをフェイルオーバーさせる。

各種エンドポイントが無効化され、アクセスできなくなる (NXDOMAINになる) 。

(4)

メインリージョンの障害が復旧する。

(5)

DRリージョンをフェイルオーバーさせる。

メインリージョンのクラスターがプライマリークラスター、DRリージョンのクラスターがセカンダリークラスターになる。

注意点として、通常のAWS AuroraのDBクラスターと比較して、機能が制限される。

▼ コールドスタンバイ構成

コールドスタンバイ構成の場合、メインリージョンにはプライマリーインスタンスとリードレプリカがおり、DRリージョンにクラスターボリュームのみがいる。

つまり、DRリージョンにAWS AuroraのDBインスタンスがない。


アップグレード

AWS Aurora Global DBでは、プライマリークラスターとセカンダリークラスターを同時にアップグレードできない。

マイナーバージョンのアップグレードの場合は、セカンダリーDBクラスターからアップグレードする。

メジャーバージョンのアップグレードの場合は、AWS Aurora Global DB自体をアップグレードする。


スナップショット

AWS Aurora Global DBでは、リージョン間でデータをコピーしている。

そのため、メインリージョンのプライマリークラスターでスナップショットを作成し、これをDRリージョンにコピーするようにする。