データベース監査機能の負荷への懸念から、本番環境のトランザクションを再現した環境で性能試験を実施した結果、そのインパクトはわずか0.4%、問題なしと判断

個人情報保護の観点からデータベースでの操作ログを取得する必要に迫られた通信会社様。2,000TPSのデータベースシステムで非常に性能要件がシビアな環境のため、操作ログ取得手法としてOracle標準のAudit機能を導入することには非常に懐疑的でした。
データベースのAudit機能は負荷が高いということがよく言われていますが、それは適切な設定をしていない条件下の“風評”であり、負荷は最適化できることをご説明し、本番相当のアクセスを再現した環境での負荷検証をご提案しました。お客様からのご要望でAudit機能に加え、メモリ参照手法の場合の負荷を、システム運用を担当する運用管理会社と一緒に検証することになりました。

採用すべき適正なAudit設定とは

Oracle標準のAudit機能は負荷が高い—その理由のほとんどは、操作ログ出力を行うAudit設定が不適切であるためです。
不適切な設定は、操作ログを取得すること＝すべての操作のログを取得することという誤解から生じた設定をとられてしまうため引き起こされます。あるいは特にOracleデータベースではAudit設定がきめ細かく行えるため、マイナーなスキルであるAudit機能に精通していないエンジニアによって単純な設定がされてしまうということでも引き起こされます。例えばselect (レコード参照) 操作のログを出力する、という設定をすると、Oracleが内部処理で実行しているリカーシブルSQLのような意味のない操作ログを大量に出力させ、結果負荷が高くなってしまうのです。
そもそも、操作ログに必要のないものが大量に含まれてしまうことは、負荷の心配以前に可監査性の観点から問題です。せっかくログを取得したとしても、モニタリングできない量のものであれば、ログの価値が低下します。広大な砂漠から一粒の異なる色の砂を見つけるのではなく、その砂漠からすくったコップの中から見つけるようにすること。必要なものは逃さずに、いかにコップ容量を少なくできるか、それも重要なログの要件でしょう。
では適正なAudit設定とは何か。それは必要なログ“のみ”を取得する設定です。必要なログのみを取得するには、個人情報や、監査対象の財務会計情報など、まずは守るべき情報を特定し、それらに対する参照や更新操作を条件にして設定することが肝要です。また、不正なアクセスの試行(失敗操作)、ユーザーや権限に関わる操作、管理者の操作は対象いかんに関わらずすべて取得すべきです。
きめ細かなAudit設定が可能なOracleの場合、Enterprise Editionであれば、対象のテーブルやDBユーザー、プログラム、アクセス元のユーザーIPアドレス等を組み合わせた細かいログ条件を設定することができます。また操作ログをOSファイル出力にすることによって出力負荷は更に低減されます。
今回の検証では、対象がEnterprise Editionであったこともあり、細かな出力条件を設定する手法をとりました。セキュアにデータベースアクセスされることが確認されているアプリケーションからの操作はログ取得の必要がないということで、対象テーブルとプログラムを組み合わせた条件で、OSファイルに出力をすることになりました。取得が必要な操作ログを絞り込んでいった結果、監査対象となるテーブルに対する操作は全体の5%未満、その上でアプリケーションまで絞り込むと実際にログ出力される操作はさらに少なくなりました。

負荷検証の結果得られたもの

アクアシステムズの性能検証サービスを使った負荷検証では、本番で流れているSQLをキャプチャリングして、SQLのバリエーション、頻度を検証環境で再現した疑似本番環境を作り検証を行います。何も設定しない状態と比較して、Audit設定でログ取得をした場合、メモリ参照手法によるログ取得をした場合で負荷検証をしました。

検証方法

本番環境でキャプチャしたSQLを、検証機に対して同等の頻度で実行します。監査設定をなにもしない場合、Oracle標準の監査機能 (FGA/Audit) によるログ出力、メモリ参照形式によるログ取得の3パターンについて、データベース性能・負荷並びにログサイズ、取得件数（全件取得できているか）を検証しました。

テストパターン

1. ウォームアップ
   テストトランザクションを30分以上流し続けてOSメモリ、Oracleキャッシュ状態を安定させます。スループットが本番機同等で安定していることを確認。テストトランザクションは、これ以降の試験期間中、同じ頻度で流し続けることとします。
   
2. 通常性能試験
   監査ログ取得設定なしでの性能を測定する。監査設定後の性能と比較する基準とします。
   
3. 標準監査性能試験
   Oracle標準の監査機能 (FGA/Audit) によるログ出力設定を行って性能を測定。
   
4. メモリ参照監査性能試験
   メモリ参照形式によるログ取得設定を行って性能を測定。

検証結果

• CPU使用率
  (A) 監査ログ出力/取得設定なし (B) Oracle標準の監査機能 (FGA/Audit) によるログ出力 (C) メモリ参照形式によるログ取得 各ケースにおいて、vmstat によりCPU 使用率を10秒間隔で取得。結果、(A) と比較して、(B) (C) いずれの場合も、CPU 使用率に大きな変化は見られませんでした。
  Oracle標準の監査機能 (FGA/Audit)では、CPU上昇はなんと、わずか0.4% にしかなりませんでした。

• SQL単位での性能比較
  更に詳しくSQL単位での実行時間を確認した結果が次の表になります。 (A) 監査ログ出力/取得設定なし (B) Oracle標準の監査機能 (FGA/Audit) によるログ出力 (C) メモリ参照形式によるログ取得 各ケースにおいて、V$SQL で取得したSQL性能情報を比較しました。 いずれの場合も、性能指標に大きな変化はなく、ほぼ誤差の範囲内という結果になりました。

SQL全体

	(A) 設定なし		(B) FGA/Audit		(C) メモリ参照
	10,000SQL	平均	10,000SQL	平均	10,000SQL	平均
ELAPSED	23,909	2.39	24,658	2.47	24,920	2.49
CPU_TIME	22,423	2.24	23,132	2.31	23,268	2.33

監査対象でないテーブルを参照するケース(ログ出力なし)

–SQL (TOP 5)での性能比較

	(A) 設定なし		(B) FGA/Audit		(C) メモリ参照
	10,000SQL	平均	10,000SQL	平均	10,000SQL	平均
ELAPSED	45,417	4.54	42,945	4.29	44,106	4.41
CPU_TIME	41,403	4.14	39,119	3.91	39,857	3.99

監査対象となるテーブルを参照するケース(ログ出力あり)

–SQL (TOP 5)での性能比較

	(A) 設定なし		(B) FGA/Audit		(C) メモリ参照
	10,000SQL	平均	10,000SQL	平均	10,000SQL	平均
ELAPSED	4,898	0.49	6,816	0.68	5,054	0.51
CPU_TIME	4,133	0.41	6,111	0.61	3,867	0.39

• 取得されたログについて
  取得されるべきログに対して、Audit機能では当然100%取得できたことを改めて確認しました。一方、メモリ参照形式においては、約60%にとどまる結果になりました。

結論

Oracle標準の監査機能 (FGA/Audit)においても、Oracleデータベースサーバへの負荷は非常に軽微で、スループット、SQL時間、サーバ/インスタンスへの影響もほとんどみられませんでした。

検証結果はお客様に報告され、これを元に方針を大きく転換、データベース操作ログを取得する手法としてAudit機能を採用することに至りました。 これまでもAudit設定での負荷は懸念するほどではないことをご説明してきましたが、実際にお客様環境でも証明され、その結果も十分な説得力を持ってお客様にご理解いただきました。