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

AsiaQuest Advent Calendar 2023 - ADVENTAR

https://adventar.org/calendars/8650

本記事はAsiaQuest Advent Calendarの15日目です。

はじめに

クラウドインテグレーション部の渡邊です。
今回は、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_eventsは、QUERYイベントと重複する、以下イベントを除外しました。

• QUERY_DCL
• QUERY_DDL
• QUERY_DML

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

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

全般ログは大量に出力されるため、コストを考慮して、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へ出力できるようになりました