ログの量は、どこから問題になるのか
ログの量が問題になるのは、次の3つのどれかが起きたときです。運用担当者が使うのをやめてしまうほどログの検索画面が遅い。利用者はそれほど増えていないのに、クラウドの保存費用が毎月上がっていく。障害が起きたときに、見たい時間帯のログを誰も取り出せない。
「数千万件」という件数そのものは、まだ問題ではありません。PostgreSQLやMySQLでも、テーブルを時間で区切り(パーティション)、検索の条件に必ず日時を入れていれば、その規模は扱えます。VAONがこれまで見直したシステムでは、原因はむしろ次のようなところにありました。
- ログが業務データと同じデータベースに入っていて、ログを書くたびにアプリケーション自身と資源を取り合っている。
- 開発時に有効にしたデバッグログが、本番環境でも出力されたままになっている。
- 古いログを `DELETE` で1行ずつ消していて、処理が長引き、テーブルが軽くなるどころか膨らんでいく。
- アクセスログも管理者の操作ログも、すべて同じ保存期間になっている。
ですから、最初に考えるべきなのは「どの技術に変えるか」ではありません。「どんなログを持っていて、誰が、いつまで読む必要があるのか」です。
ログはどのくらいの期間、すべて残す必要があるのか
ログの保存期間に、すべてのシステムに共通する数字はありません。業種、お客様との契約、ログの種類によって決まります。
よく引き合いに出される3つの決まりを見ると、そのことがわかります。
- 個人情報保護法。個人情報保護委員会のガイドライン(通則編)は、安全管理措置の例として、情報システムの利用状況(ログイン実績、アクセスログ等)の記録や、ログ等の定期的な分析による不正アクセスの検知を挙げています。ただし、システムのログを何年残すかという期間は定めていません。
- PCI DSS(クレジットカード情報のセキュリティ基準)。要件10.5.1は、監査ログの履歴を少なくとも12か月保存し、そのうち直近3か月はすぐに分析できる状態にしておくことを求めています。
- GDPR(EU一般データ保護規則)。保存制限の原則により、個人データを必要以上に長く持つことはできません。IPアドレスや利用者IDを含むログも対象になります。「すべてを、いつまでも」残すこと自体が、リスクになります。
つまり、「費用を抑えるためにログを消すのは違法」という言い方は正確ではありません。必要なのは、ログの種類ごとに期間を決め、その理由を記録しておくことです。
ログの保存コストを抑える4つの方法 小さな変更から順に
次の4つは、システムへの変更が小さいものから順に並べています。1と2だけで十分に軽くなるシステムも多いため、この順番で進めることをおすすめします。
時間で区切る方法は、いちばん見落とされがちです。ログのテーブルを日や月ごとに区切っておけば、期限の切れたログは区切りを1つ捨てるだけで消えます。何百万行もの `DELETE` を流す必要はありません。
古いログを安い保管先へ移す方法(ホット/コールドの階層化)では、直近のログはすぐ検索できる場所に置き、古いログはAmazon S3などのオブジェクトストレージへ移します。先ほどのPCI DSSの例なら、直近3か月は速い保管先、残りの9か月は安い保管先、という分け方になります。移す前に、古いログを1日分取り出してみて、どれだけ時間がかかるかを測っておいてください。障害の調査中に、何時間も待つことはできないからです。
列指向データベース(ClickHouseなど)は列ごとにデータを保存するため、同じ値が何度も出てくるログは、たいてい圧縮がよく効きます。ClickHouseではTTL(保存期限)を設定して、古くなったデータを別のディスクへ移したり、自動で消したりできます。たとえば、エラーのログは6か月、それ以外は1か月で消す、といった指定です。ただ、実際にどれだけ圧縮できるかはデータによります。一般的な数字を当てにするより、実際のログを1週間分入れて測るほうが確かです。
ログを非同期で書き込めば、アプリケーションは速くなるのか
ログを非同期で書き込むと、アプリケーションはログの書き込みが終わるのを待たずに、利用者へ応答を返せます。ログはいったんキューや収集用のプロセス(VectorやFluent Bitなど)に渡され、保管先への書き込みはそちらが受け持ちます。
一方で、判断する立場の方に知っておいていただきたい代償もあります。
1. ログが失われることがある。一時的な置き場がメモリだけだと、プロセスが止まった時点で、まだ書かれていないログは消えます。監査ログには、ディスクに書き出すキューと、再送の仕組みが必要です。
2. 止まっても誰も気づかないことがある。ログの経路が止まっても、アプリケーションは普段どおり動き続けます。PCI DSSも要件10.7で、監査ログの仕組みの故障を速やかに検知し、対処することを求めています。保管先に届くログの量が急に減ったら、通知が来るようにしておく必要があります。
3. 運用するものが増える。Kafkaや専用のキューを入れれば、サーバー、更新作業、故障しうる箇所がそれだけ増えます。
非同期にしても、遅延がゼロになるわけではありません。重い処理をリクエストの流れの外へ出す代わりに、ログの経路そのものの信頼性を自分たちで守ることになります。
ログの仕組みを変えないほうがよいのは、どんな場合か
ログの量がまだ少ない、今の検索で十分に間に合っている、新しい仕組みに慣れた運用担当者がいない。こうした場合は、ログの仕組みを変えないほうがよいでしょう。ClickHouseやKafkaを自社で運用すれば、監視、バックアップ、バージョンアップを担う人が必要です。月に数百万件程度のログであれば、保存費用で浮く金額より、運用する人の費用のほうが大きくなることもあります。
クラウド事業者が提供するログのサービスを使うのも、筋のよい選択です。ただしその場合、取り込むデータ量に応じて費用が増えるため、やはり1の「不要なログを止める」から始める必要があります。
1と2を済ませた時点で検索が十分に速く、請求額も落ち着いたのであれば、そこで止めるのが正しい判断です。
VAONはログの見直しを、どこから始めるのか
VAONには、サーバーの運用からセキュリティの検査までを担当するインフラチームがあります。お客様からログの見直しを頼まれたとき、インフラチームは技術の選定からではなく、実際の数字から始めます。種類ごとの1日あたりのログの量、運用担当の方がよく使う検索、そしてお客様の契約や規程が求める保存期間です。そのうえで、3で挙げた4つの方法のどこまで進めるかを決めます。
保存期間は、設定ファイルの中だけでなく、文書にしておくことも大切です。VAONが運用するAIチャットボット「ONEBOT」の利用規約では、契約終了後のお客様のデータは30日間保持したあと削除または匿名化すること、バックアップと監査ログはシステムの更新周期に沿って削除されることを明記しています。利用する側が、自分たちのログがどこにあり、いつ消えるのかを前もって知ることができます。
複数のお客様の運用を受けるSIer・代理店は、契約に何を書いておくべきか
固定の月額で複数のお客様のシステム運用を受けているSIer・代理店は、ログが増えたときの影響をいちばん受けやすい立場です。保存の費用は増えても、受け取る運用費は変わらないからです。次の5点は、最初に取り決めておくことをおすすめします。
1. ログの種類ごとの保存期間と、それを変えるときに誰が決めるか。
2. 誰が、どのツールでログを閲覧できるか。
3. ログをどの国の、どのクラウド事業者に保存するか。
4. 契約終了時に、ログをどの形式で引き渡すのか、それとも削除するのか。
5. ログの量が一定を超えたとき、運用費をどう見直すか。
5は特に抜けやすい項目です。月あたりの容量などで基準をあらかじめ決めておけば、請求額が膨らんでから交渉し直す必要がなくなります。3は、お客様のセキュリティ部門がSaaSを審査するときに最初に確認する点でもあります。詳しくはAIチャットボット導入のセキュリティ審査 承認前に答えておきたい5つの質問をご覧ください。AIチャットボットをお客様向けに提供する立場の方は、データの扱いについて同じような確認点をAIチャットボットを自社商材にしたいSIer・代理店へ 自社開発、取次販売、OEMの選び方にまとめています。
ログのせいでシステムが遅い、クラウドの請求額が毎月上がる、とお困りではありませんか。 ログの量と種類、残す必要のある期間を伺い、どこまで手を入れるのがよいかをVAONのインフラチームと一緒に整理します。[無料相談](/ja/contact)
参考資料
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」10-3、10-6：https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
- Microsoft Learn「Microsoft Entra ID and PCI-DSS Requirement 10」(要件10.5.1の原文を掲載)：https://learn.microsoft.com/en-us/entra/standards/pci-requirement-10
- ClickHouse Docs「Manage data with TTL (time-to-live)」：https://clickhouse.com/docs/guides/developer/ttl