【ITニュース解説】Audit Log with Short-Lived Online Data

システムエンジニアとしてサービスを開発・運用する上で、何らかの変更が起こったときに「何が、誰によって、いつ、どのように変わったのか」を正確に把握することは非常に重要だ。例えば、設定が意図せず変更されてしまった場合、エンジニアはすぐにその原因を特定し、元の状態に戻すための情報を必要とする。このような情報を記録する仕組みを「監査ログ」と呼ぶ。監査ログは、サービスの安定稼働を支えるだけでなく、法的な要件（コンプライアンス）を満たす上でも欠かせない。

しかし、監査ログに対する要求は常に同じではない。例えば、直近数時間の変更履歴は、問題が発生した際に即座に対応するために、非常に高速に表示できる必要がある。特に、ある設定の変更前後の値を素早く確認し、すぐに元の状態に戻す（ロールバック）準備を整えるような緊急時には、数秒の遅延も許されない。一方で、数ヶ月、あるいは数年前の履歴を調査するようなケースでは、即座の応答速度は求められず、多少の遅延は許容されることが多い。このような長期的な履歴は、過去の傾向分析や、特定の時期に何が起きたかを詳しく調べるために利用される。つまり、監査ログの設計は、これら異なる二つの要求、すなわち「高速な直近の参照」と「効率的な長期保存と分析」を両立させる必要がある。

これまでの監査ログの設計にはいくつかの方法があった。例えば、一つのリレーショナルデータベースのテーブルに全ての監査ログを記録する方法は、非常にシンプルで実装しやすい。しかし、時間が経つにつれてログの量が増えれば増えるほど、テーブルの性能が低下し、通常の業務処理に悪影響を及ぼす可能性が高くなる。また、データベースが提供する監査機能を使う手もあるが、これは主にデータベースの操作履歴を記録するものであり、「プロジェクト設定が変更された」といった具体的なビジネス上の意味合いや、実際に操作したエンドユーザーを特定するのには向いていない場合が多い。他にも、ログデータを検索システムに送り、柔軟に探索できるようにする方法や、専門のマネージド監査サービスを利用する方法、あるいはイベントストリームと呼ばれる仕組みで変更を耐久性のある形で記録する方法もあるが、これらにはそれぞれ運用コストや機能の柔軟性、リアルタイム性などの面で課題がある。また、最初から全ての監査データを長期保存用のデータウェアハウスに直接送り込む方法もあるが、この方法では直近の変更を高速に参照するという要件を満たすのが難しい。データウェアハウスは大量のデータを効率的に分析することに特化しており、個々のエンティティの最新履歴を即座に提供するようには作られていないからだ。

そこで提案されるのが、「二つのオンラインテーブルと一つのデータウェアハウス」を組み合わせる設計アプローチだ。このアプローチでは、直近の監査ログを扱うために二つのオンラインテーブルを用意する。一つ目のテーブルは「タイムラインテーブル」と呼び、これは特定の設定やプロジェクト（これを「エンティティ」と呼ぶ）に対していつ、どんなイベントが起きたかを示すためのコンパクトなインデックスのような役割を果たす。具体的には、どのテナント（顧客）のどのエンティティで変更があったかをキーとして、変更が起こった日時と、その変更を一意に識別するイベントID、そしてリスト表示に必要な最小限の情報だけを保持する。これにより、特定のエンティティの最新の変更履歴を非常に素早く見つけることができる。

二つ目のテーブルは「ペイロードテーブル」と呼び、ここではタイムラインテーブルで取得したイベントIDを使って、その変更の詳細な内容を保管する。具体的には、変更がどのエンティティに対して行われたか、いつ、誰が、どのようなアクションを実行したか、そして変更前の値と変更後の値、データの形式を示すスキーマバージョンなどが全て格納される。このペイロードテーブルの各レコードは自己完結型であり、他のテーブルと結合することなく、そのイベントの全ての情報を読み取ることができる。この二つのテーブルを分けることで、タイムラインテーブルは軽量に保たれ、直近の履歴を素早く参照できる一方で、ペイロードテーブルは大量の詳細データを効率的に格納できる。ペイロードテーブルへの書き込みが成功し、タイムラインテーブルへの書き込みが失敗すると、データは存在するがリストに表示されない「孤立した」イベントが生じる可能性があるため、実際には書き込み順序や再試行の仕組みを工夫し、両者の整合性を保つための工夫が必要となる。

これらのオンラインテーブルのデータは、永遠に保存するのではなく、一定期間（例えば数日間や数週間）が経過すると自動的に削除されるように設定される。これを「TTL（Time To Live）」と呼ぶ。データは物理的に削除されるだけでなく、読み取り時にも「発生日時が現在から一定期間内であるイベントのみを表示する」といったルールを適用する。これにより、オンラインテーブルのデータ量を常に管理可能な範囲に保ち、パフォーマンスを維持できる。一方で、長期的に保存すべき過去の監査ログは、オンラインテーブルから定期的に「データウェアハウス」へエクスポートされ、ここに蓄積される。データウェアハウスは、コスト効率よく大量の過去データを保存し、複雑な分析を行うのに適した場所だ。ここで重要なのは、オンラインテーブルでデータが自動的に削除されたとしても、それがデータウェアハウスから削除されることを意味しない点だ。データウェアハウスは、オンラインテーブルとは独立した独自の認証、保持期間、削除ポリシーを持つべきであり、一度アーカイブされた履歴は永続的に保持されるのが原則である。

ユーザーが監査ログを参照する際には、「この変更は直近だからオンラインテーブルから、これは古いからデータウェアハウスから」といったようにデータ源を意識させるべきではない。理想的には、単一の履歴APIを提供し、そのAPIが内部的にオンラインテーブルとデータウェアハウスの両方から必要なデータを取得し、重複を排除し、指定された順序で結果を返すようにする。例えば、ある期間の履歴を要求された場合、まずオンラインテーブルから該当するデータを探し、次にデータウェアハウスから残りの期間のデータを補完するといった形だ。もしデータウェアハウスが一時的に利用できない場合でも、「履歴なし」と表示するのではなく、その範囲の履歴が確認できないことを明示的に示すべきだ。

監査ログの正確性を確保するためには、変更が実際にサービスに反映された「後」にログを記録するなどの注意が必要だ。もし変更がコミットされる前にログを記録してしまうと、最終的に行われなかった変更がログに残ってしまう可能性がある。逆に、変更がコミットされた「後」にログを記録しようとして、その間にシステムがクラッシュすると、変更は行われたのにログが残らないという事態が発生しうる。これを防ぐためには、「トランザクショナルアウトボックス」のような仕組みを使ったり、変更前の値を正確に記録するためにデータベースのトランザクションやバージョンチェックを利用したりする工夫が求められる。また、システムの信頼性を確保するために、データが重複して記録される可能性、一部のデータだけが書き込まれる可能性、同時に複数の変更が行われる可能性、オンラインテーブルからのデータ削除とアーカイブへのエクスポートの遅延、そして認証されていないユーザーによるログの読み取りといった、様々なシナリオを想定した厳密なテストが不可欠となる。

このように、「二つのオンラインテーブルと一つのデータウェアハウス」を組み合わせるアプローチは、最新の変更を素早く参照して即座に対応するニーズ（例えば、直前の変更前後の値を確認して安全にロールバックするような場合）と、コストを抑えながら長期的な変更履歴を調査するニーズの両方を満たすことができる。タイムラインテーブルがエンティティごとの読み取りを軽量に保ち、ペイロードテーブルが変更の詳細を保持し、データウェアハウスがオンラインテーブルのデータが期限切れになった後も履歴を永続的に保持する。この設計には、データの書き込み回数が増えること、データを復元する際の複雑さ、データの整合性を維持するための課題、そしてページネーション（大量のデータを分割して表示する仕組み）を慎重に設計する必要があるというトレードオフも存在する。しかし、サービスの要件や運用上の制約によっては、よりシンプルな設計やマネージドサービスを選択することももちろん可能だ。どのようなストレージを選択するにしても、ログの再試行時には同じイベントを一意に識別するIDを使い続けること、監査記録が主張する内容を正確に反映していること、そして履歴の一部が欠落している場合に、それが「履歴がない」と誤って認識されないように明示することが、監査ログ設計における普遍的かつ最も重要な原則である。