サーバーやアプリケーションを運用していると、必ずと言っていいほど登場するのが「ログ」です。エラーが起きたときの調査、処理の流れの確認、セキュリティ監査など、ログはシステムの状態を知るための大切な手がかりになります。
ただし、ログは放っておくとどんどん増えていきます。気づいたらディスクがいっぱいになってサービスが止まってしまった、というのは現場ではよくある話です。そこで重要になるのが ログローテーション という仕組みです。
この記事では、ログローテーションの基本的な考え方から、仕組み、設計のポイントまでを、初心者の方にもわかるように丁寧に解説していきます。運用に関わり始めたばかりの方や、「なんとなく設定しているけど実はよくわかっていない」という方にも役立つ内容を目指します。
ログローテーションとは何か
ログが増え続けると何が困るのか
まず前提として、なぜログを管理する必要があるのかを整理しておきます。
ログファイルは、アプリケーションが動くたびに追記されていくのが一般的です。たとえばWebサーバーであれば、アクセスがあるたびに1行ずつログが増えていきます。1日では数MBでも、1か月、半年、1年と積み重なると、数GBや数十GBになることも珍しくありません。
この状態で困るのが、以下のような問題です。
- ディスク容量を圧迫してしまう
- ログが大きすぎて開くのに時間がかかる
- 必要な情報を探すのが大変になる
ログは「残すこと」も大事ですが、「適切なサイズに保つこと」も同じくらい大切です。
ログローテーションの基本的な役割
ログローテーションとは、簡単に言うと ログを定期的に区切って整理する仕組み です。
たとえば、
- 今日までのログを別ファイルに退避する
- 新しいログファイルを作って、そこに書き込みを続ける
- 古くなったログは削除する、または圧縮する
といった一連の流れを自動で行います。
日記帳に例えると、1冊がいっぱいになる前に次のノートに切り替え、古いノートは本棚にしまったり、不要なら処分したりするイメージです。ログローテーションは、システムの「ログ日記帳」を整理整頓する役割を担っています。
ログローテーションの仕組み
ローテーションのタイミング
ログローテーションには、いくつか代表的な実行タイミングがあります。
よく使われるのは次の2つです。
- 時間ベース 1日ごと、1週間ごと、1か月ごとなど、時間を基準に切り替える方法です。 アクセスログやアプリケーションログでよく使われます。
- サイズベース ログファイルが一定サイズを超えたら切り替える方法です。 突発的にログが増えるシステムで有効です。
実際の現場では、「1日ごとにローテーションし、サイズが大きすぎる場合は途中でも切り替える」といった組み合わせもよく見られます。
ローテーション時に行われる処理
ログローテーションが実行されると、内部では次のような処理が行われます。
- 現在のログファイルをリネームする
- 新しいログファイルを作成する
- 古いログを圧縮する（必要に応じて）
- 保存期間を超えたログを削除する
たとえば app.log というファイルがある場合、ローテーション後に app.log.1 や app.log.20250101 のような名前に変わり、新しい app.log が作られます。
この仕組みによって、アプリケーションは意識することなく、常に同じファイル名にログを書き続けられます。
代表的なツールと考え方
Linux環境では logrotate という仕組みが広く使われています。設定ファイルに「いつ」「どのログを」「どう扱うか」を書いておくと、定期的に自動実行されます。
ここで重要なのは、ツールそのものよりも 考え方 です。どのツールを使うにしても、次の点は共通しています。
- ログを無限に増やさない
- 必要な期間だけ保存する
- 運用を自動化する
この3点を押さえておくと、環境が変わっても応用が利きます。
ログローテーション設計の基本
保存期間をどう決めるか
ログをどれくらい残すかは、システムの性質によって変わります。
目安としては次のように考えると整理しやすくなります。
- 障害調査にどれくらい過去の情報が必要か
- 法的・社内ルールで保存期間が決まっていないか
- ログのサイズとディスク容量のバランス
たとえば、障害対応で「過去1か月分あれば十分」なら、それ以上は削除しても問題ないケースが多いです。一方、監査目的で半年や1年の保存が必要な場合もあります。
圧縮は積極的に使う
古いログは 圧縮 することで、ディスク使用量を大幅に減らせます。
テキストログは圧縮効率が高く、半分以下、場合によっては10分の1程度になることもあります。最近のCPU性能を考えると、圧縮・解凍の負荷が問題になるケースはそれほど多くありません。
「すぐに見る可能性が低いログは圧縮する」という考え方は、かなり実用的です。
アプリケーションとの連携に注意する
ログローテーション設計で意外と見落とされがちなのが、アプリケーション側との相性です。
アプリケーションによっては、
- ログファイルがリネームされると書き込みが止まる
- 再起動しないと新しいログに書けない
といった挙動をするものがあります。
この場合、ローテーション後にログ出力を再オープンする仕組み（シグナル送信など）が必要になります。設計時には、「このアプリはどうやってログを書いているのか」を一度確認しておくと安心です。
実務で押さえておきたいポイント
障害時に役立つログを残す
ログローテーションは整理のための仕組みですが、「消しすぎない」ことも重要です。
障害が起きた直後に、「原因を調べようと思ったらログがもう消えていた」というのは避けたいところです。少なくとも、一次対応に必要な期間分は必ず残るように設計します。
実務では、「通常は7日、重要システムは30日」といったように、システムごとに基準を分けることがよくあります。
本番環境ほど慎重に
検証環境では多少雑でも問題になりにくいですが、本番環境のログローテーションは慎重に行う必要があります。
- ローテーションのタイミングでログが欠けないか
- ディスクが逼迫したときの挙動はどうなるか
- 想定外のログ増加に耐えられるか
一度設定したら終わりではなく、定期的にログのサイズや増え方を確認し、必要に応じて見直すことが大切です。
「見える化」しておくと安心
ログローテーションが正しく動いているかは、放置していると気づきにくいものです。
ディスク使用量を監視したり、ログファイルのサイズや数を定期的にチェックしたりすることで、「何かおかしい」に早めに気づけます。運用は仕組みとセットで考えるのがポイントです。
一問一答：よくある疑問
- ログローテーションを設定しないとどうなる？
-
ログが無制限に増え、最終的にはディスク不足でサービス停止につながる可能性があります。
- サイズベースと時間ベースはどちらが良い？
-
一概には言えません。アクセス量が安定しているなら時間ベース、変動が激しいならサイズベースが向いています。
- 圧縮すると調査が大変にならない？
-
多少手間は増えますが、必要なときだけ解凍すれば問題ありません。ディスク節約のメリットの方が大きいケースが多いです。
まとめ
ログローテーションは、派手さはないものの、安定したシステム運用を支える重要な仕組みです。
ポイントを振り返ると、
- ログは放置すると必ず問題になる
- ログローテーションは整理と安全のための仕組み
- 保存期間、圧縮、アプリとの連携を意識する
- 設定後も定期的な見直しが大切
という点が挙げられます。
最初は少しとっつきにくく感じるかもしれませんが、一度考え方を理解すると応用が利きます。ログローテーションをきちんと設計できるようになると、運用全体の見通しも良くなり、トラブル対応にも自信が持てるようになります。
日々の運用を少し楽にするためにも、ぜひこの機会にログローテーションの仕組みを整理してみてください。
