【AWS】Aurora MySQL、RDS SQL Server クエリログを取得する方法

Aurora MySQL の場合

Aurora MySQL は以下のログファイルをモニタリングできます。

• IAM データベース認証エラーログ
• エラーログ（Error Log）
• スロークエリログ（Slow Query Log）
• 全般ログ（General Log）
• 監査ログ（Audit Log）
• インスタンスログ

IAM データベース認証エラーログ（IAM DB 認証エラーログ）

IAM DB 認証に失敗した理由を見るためのログです。IAM DB 認証とは、DB ユーザーのパスワードではなく、IAM 認証トークンを使って Aurora MySQL に接続する方式です。クエリログは出力されません。

エラーログ

Aurora MySQL のエラーログはデフォルトで生成されます。Aurora MySQL は mysql-error.log ファイルにエラーを書き込みます。基本的にログのタイムスタンプは UTC（Coordinated Universal Time）で出力されます。エラーログは DB エラーのログなので通常のクエリログは出力されません。DB起動・停止、クラッシュ、内部エラー、接続エラー、レプリケーション系エラーなどのログが出力されます。

スロークエリログ（Slow Query Log）

スロークエリログ（Slow Query Log）は、性能調査が目的となります。一定時間以上かかったSQLを記録するログです。

slow_query_log = 1
long_query_time = 1
log_output = FILE

slow_query_log を1 にするとスロークエリログが作成されます。

ログへの記録対象にするクエリの最短実行時間はlong_query_time で秒単位で指定できます。上記は 1秒を超えた SQL が記録対象になります。ただし、long_query_time の値を小さくしすぎるとログ量と負荷が増えます。ワークロードに応じて調整することが推奨されます。

log_queries_not_using_indexes

log_queries_not_using_indexes を有効にすると、実行時間に関係なくインデックスを使わないクエリも記録できます。これは、スロークエリログに記録される条件が増えるという意味です。

通常、スロークエリログは以下のような条件で記録されます。これは実行時間が1秒以上かかったSQLをスロークエリログに記録するという意味です。

slow_query_log = 1
long_query_time = 1

さらに以下を有効にします。

log_queries_not_using_indexes = 1

そうすると、実行時間が 1秒未満でも、インデックスを使っていない SQL もスロークエリログに記録されます。

log_queries_not_using_indexes を利用する具体例

例えば、テーブルがこうだとします。

CREATE TABLE users (
  id bigint primary key,
  email varchar(255),
  name varchar(255),
  created_at datetime
);

email にインデックスがない状態で、以下を実行します。

SELECT *FROM usersWHERE email = 'test@example.com';

このSQLは、email にインデックスがないため、MySQLがテーブル全体を上から順に探す可能性があります。

つまり、users テーブルを全件スキャンするという動きになります。このSQLが 0.05秒で終わった としても、log_queries_not_using_indexes = 1 ならスロークエリログに出る可能性があります。遅くはないけど、将来的に危ないSQLを見つけられます。

例えば今はデータが少ないので、0.05秒で終わる。でも、将来データが増えると、5秒かかったり、DB負荷が高くなるというSQLがあります。log_queries_not_using_indexes は、こういう 将来遅くなりそうなSQL を早めに見つけるための設定です。

全般ログ（General Log）

Aurora MySQL の全般ログ（General Log）は、DB に対して発生した接続・切断・実行 SQL など細かく記録するログです。MySQL が受け取った処理を記録するログです。ただし、本番環境で常時ONにするログというより、調査時に短時間だけ有効化するログと考えた方が安全です。

• 接続　…　どのユーザーが接続したか
• 切断　…　接続が終了したこと
• 実行 SQL　…　SELECT / INSERT / UPDATE / DELETE など
• 管理系コマンド　…　SET, SHOW, COMMIT, ROLLBACK など

有効な調査

• アプリが本当にSQLを投げているか　…　SQL実行有無が分かる
• 想定外のSQLが流れていないか　…　SQL本文を確認できる
• 特定テーブルにアクセスしているか　…　SQL内のテーブル名から確認できる
• どのユーザーで接続しているか　…　DBユーザー情報を確認できる
• トランザクションが発生しているか　…　BEGIN, COMMIT, ROLLBACK などが見える

しかし、以下は全般ログをだけでは分かりません。

• このSQLで何件返ったか
• どんな個人情報が返却されたか
• どのWeb画面の操作で発生したか

本番で常時ONにしない方がよい理由

全般ログは便利ですが、本番では注意が必要です。理由は主に3つです。

1. ログ量が非常に多くなる
2. DB性能に影響する可能性がある
3. SQL本文に個人情報が含まれる可能性がある

特に個人情報保護の観点では、以下のようなSQLがログに残る可能性があります。

SELECT *FROM usersWHERE email = 'test@example.com';

この場合、メールアドレスがログに残ります。

また、アプリの実装によっては以下のように、個人情報そのものがSQL本文に出る可能性もあります。

INSERT INTO customers (name, email, tel)VALUES ('山田太郎', 'yamada@example.com', '090-xxxx-xxxx');

そのため、全般ログを CloudWatch Logs に出す場合は、CloudWatch Logs自体が機微情報の保管場所になると考えた方がよいです。

監査ログ（Audit Log）

Aurora MySQL の 監査ログ（Audit Log） は、誰が、いつ、DBに接続して、どのような操作をしたかを記録するためのログです。Aurora MySQL では、この機能は Advanced Auditing と言います。DBクラスターのパラメータを設定して有効化します。

• 誰が　…　DBユーザー
• いつ　…　実行時刻
• どこから　…　接続元ホスト/IP
• 何を　…　接続、切断、SQL実行、DDL、DML、DCLなど
• どのDBで　…　対象データベース
• どのSQLを　…　設定によってSQL本文

全般ログとの違い

監査ログと全般ログは似ていますが、目的が違います。

• 全般ログ　…　実際に流れているSQLを広く確認する
• 監査ログ　…　監査証跡として、接続や操作を記録する

全般ログは「とにかくSQLを見る」用途です。

一方、監査ログは、監査対象のイベントを選んで記録するという使い方ができます。そのため、個人情報保護や不正操作調査では、通常は全般ログより監査ログの方が向いています。