RDS（Aurora）のログ関連のパラメータグループについて考えてみた

作成者: tsuyoshi.watanabe｜2023年12月17日

はじめに

クラウドインテグレーション部の渡邊です。
今回は、Relational Database – Amazon Aurora MySQL PostgreSQLのパラメータグループについて、ログに絞って考えました。
Aurora MySQLを例にまとめます。
クラスターを作成するとインスタンスパラメータグループとクラスターパラメータグループがありますが、それらの挙動や設定方針についても説明します。
本記事では、それぞれ以下のように呼ぶこととします。

インスタンスパラメータグループ = PG
クラスターパラメータグループ = CPG
PGとCPGの総称 = パラメータグループ

なお、本記事は、データベースのログのエクスポート設定で、CloudWatchLogsに発行するログタイプをすべて有効化している前提です。

※オプショングループは本記事では触れません。

パラメータグループの設定値を考える前に

PGはインスタンスに適用するパラメータグループです。
CPGはクラスター内のすべてのインスタンスに適用するパラメータグループです。
この章では、これらのパラメータについて主に説明します。

パラメータの差分

公式の資料では見つかりませんでしたが、PGのパラメータ一覧とCPGのパラメータ一覧は、少なくとも本検証で使用するファミリー（aurora-mysql8.0）において包含関係がございました。
PGに含まれているパラメータはすべてCPGにもあり、CPGに含まれていてPGに含まれていないパラメータがありました。
コマンドによる確認の流れと、実施内容を以下に示します。

CPGとPGの各一覧を、整理した形でCSVで保存
diffでパラメータ情報の差分比較
- 「<」はdb_parameters.csv、「>」はcluster_parameters.csvの行を表します。
- 以下の実行コマンドでは、db_parameters.csvにあって、cluster_parameters.csvには存在しない行を表示します。

aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 \
    | jq -r '["名前","値","許可された値","変更可能","送信元","適用タイプ","データ型","説明","ApplyMethod","MinimumEngineVersion"], (.Parameters[] | [.ParameterName,.ParameterValue,.AllowedValues,.IsModifiable,.Source,.ApplyType,.DataType,.Description,.ApplyMethod,.MinimumEngineVersion]) | @csv' \
    | iconv -t sjis \
    > db_parameters.csv
  
aws rds describe-db-cluster-parameters --db-cluster-parameter-group-name default.aurora-mysql8.0 \
    | jq -r '["名前","値","許可された値","変更可能","送信元","適用タイプ","データ型","説明","ApplyMethod","MinimumEngineVersion"], (.Parameters[] | [.ParameterName,.ParameterValue,.AllowedValues,.IsModifiable,.Source,.ApplyType,.DataType,.Description,.ApplyMethod,.MinimumEngineVersion]) | @csv' \
    | iconv -t sjis \
    > cluster_parameters.csv

diff db_parameters.csv cluster_parameters.csv | grep '^<'

cluster_parameters.csvにあって、db_parameters.csvには存在しない行を、以下コマンドで表示します。

diff db_parameters.csv cluster_parameters.csv | grep '^>'

実行結果を一部抜粋しますが、かなりたくさんありました。

> "server_id","{ServerId}",,false,"system","dynamic","integer","Integer value used to identify the instance in a replication group","pending-reboot",
> "skip-character-set-client-handshake",,"0,1",true,"engine-default","static","boolean","Ignore character set information sent by the client.","pending-reboot",
> "skip_name_resolve","1","0,1",false,"system","static","boolean","Host names are not resolved. All Host column values in the grant tables must be IP numbers or localhost.","pending-reboot",

※なお、aurora-mysql5.7で同様に試したところ、secure_authの変更可否だけ異なりました。

< "secure_auth",,"1",false,"engine-default","dynamic","boolean","Blocks connections from all accounts that have passwords stored in the old (pre-4.1) format.","pending-reboot",
---
> "secure_auth",,"1",true,"engine-default","dynamic","boolean","Blocks connections from all accounts that have passwords stored in the old (pre-4.1) format.","pending-reboot",

条件次第でパラメータの差分は簡単にできる

余談ですが、以下3つの条件をすべて満たすことで、コンソール画面からパラメータの差分を比較することはできます。（今回は①に合致しないためできない）

① 両方ともPGであるか、両方ともCPG
② 同じDBエンジン
③ 同じバージョン

該当のパラメータグループを選択後、[アクション]>[比較]から比較できます。

PGとCPG間のパラメータの優先度

PGとCPGは共通のパラメータがあります。
これらの設定値の優先度について説明します。
以下の2点が公式ドキュメントで記載されておりました。

PGがデフォルト値の場合、CPGが優先される
PGがカスタムされていた場合、CPGよりPGが優先される

変更した DB パラメータ設定は、構成設定を変更してデフォルト値に戻した場合でも、DB クラスターパラメータグループ値より優先されます。

プロビジョニングされたインスタンスと Aurora Serverless v2 インスタンス化の場合、DB クラスターパラメータグループで変更した設定値は、DB パラメータグループのデフォルト値をオーバーライドします。DB パラメータグループ内の対応する値を編集すると、これらの値によって DB クラスターパラメータグループの設定が上書きされます。

引用元：Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ

PGとCPGの関係について、理解は深まりましたか。
これらの挙動を理解した上で、設定しましょう。
私は、以下の設定方針としています。

インスタンス間で設定の差分がない
- CPG：カスタム
- PG：デフォルト
インスタンス間で設定の差分がある
- CPG：カスタム（CPGにしかない値をカスタムできるようにするため）
- PG：カスタム

ログにフォーカスしてパラメータグループを考える

今回は、インスタンス間の設定の差分がないという想定のもと、私の設定方針に則り、CPGのみ言及します。

CloudWatchLogsで、4種類のログが出力できます。
エラーログは、デフォルトで生成されるため、パラメータグループによる設定は不要です。

監査ログ
エラーログ
全般ログ
スロークエリログ

Aurora MySQL のエラーログはデフォルトで生成されます。

引用元：Aurora MySQL データベースログの概要

Aurora MySQL データベースログの概要を参考に、パラメータを下表にまとめました。

ログタイプごとのパラメータ名	パラメータ	個人的オススメ設定値	パラメータの説明
監査ログ	server_audit_logging	1	監査ログの有効化または無効化
	server_audit_logs_upload	1	CloudWatcg Logsへのアップロードの有効化または無効化
	server_audit_events	TABLE,CONNECT,QUERY	ログ記録するイベント
全般ログ	general_log	0	全般ログの有効化または無効化
スロークエリログ	slow_query_log	1	スロークエリログの有効化または無効化
	long_query_time	要件に合わせる	ログに記録されるクエリの最短実行時間
	log_queries_not_using_indexes	0	インデックスを使用していないすべてのクエリのログ記録の有効化または無効化

server_audit_eventsは、QUERYイベントと重複する、以下イベントを除外しました。

QUERY_DCL
QUERY_DDL
QUERY_DML

なお、有効化しているイベントの説明は以下の通りです。

イベント	説明
TABLE	クエリ実行の影響を受けたテーブルの記録
CONNECT	接続の成否、および切断の記録
QUERY	すべてのクエリの記録 (構文またはアクセス権限エラーで失敗したエラーを含む)

監査ログはログ量が多くなりやすいため、コストが増加しやすい点に注意しましょう。
上表に記載はありませんが、CPGに含まれる以下のパラメータで制御することで、コストの削減が期待できます。

イベント	説明
server_audit_incl_users	ログを記録するユーザ名を指定する
server_audit_excl_users	ログを記録しないユーザ名を指定する

全般ログは大量に出力されるため、コストを考慮して、general_logを無効化しました。
long_query_timeは、デフォルト値10sだと長いと思うので、デフォルト値から変更することをオススメします。
log_queries_not_using_indexesの有効化によって、long_query_timeの閾値より短いことで、スローログの特定の妨げになることを防ぐために無効化しました。

log_queries_not_using_indexes: インデックスを使用しないすべてのクエリをスロークエリログに記録するには、1 に設定します。インデックスを使用しないクエリは、その実行時間が long_query_time パラメータの値未満であってもログに記録されます。デフォルトは 0 です。

引用元：Aurora MySQL のスロークエリと一般ログ

まとめ

インスタンスパラメータグループの値がデフォルトである場合を除き、クラスターパラメータグループより優先される。
少なくとも、執筆時点（2023/11/9）でサポートするaurora-mysqlX.Xのファミリーにおいて、クラスターパラメータグループとインスタンスパラメータグループの項目は包含関係にある。
- クラスターパラメータグループにはあるが、インスタンスパラメータグループにないパラメータがある。
- インスタンスパラメータグループにあって、クラスターパラメータグループにないパラメータはない。
CloudWatchLogsで、4種類のログが出力できる。エラーログはパラメータグループの設定をしなくても出力される。
- 監査ログ
- エラーログ
- 全般ログ
- スロークエリログ

【参考】

DIFF

Aurora MySQL のスロークエリと一般ログ

Aurora MySQL データベースログの概要

Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用

Aurora MySQL 設定パラメータ

Amazon RDS for MySQL のパラメーターを設定するためのベストプラクティス。パート 3: セキュリティ、操作管理性、および接続タイムアウトに関連するパラメーター

Amazon Auroraの監査ログをCloudWatch Logsへ出力できるようになりました

完全な記事を表示