NGINX キャッシュを削除すると、重大なリンク解除エラーがエラー ログに記録される

この投稿の情報は、Ubuntu Server 14.04 x64 で実行されている NGINX 1.4.6 の FastCGI キャッシュに基づいています。他のバージョンでは有効ではない可能性があります。

(2025 年更新: 最初の投稿を書いたときから現在までの間に、多くのことが変わりました。サーバーはより高速で安価になったため、動的コンテンツを数世代余分に保存するためだけにキャッシュの有効期限を細かく管理しようとするこの投稿で説明したアプローチは、実際にはお勧めしません。将来の参考のため、また、何らかの理由で実際に誰かが必要とする場合に備えて、ここにコンテンツを残しておきます。ただし、これが現在のバージョンの NGINX でも機能するかどうかは確認していませんが、機能すると思います。)

いくつかのサイトを Apache から NGINX に移行した後、私はその組み込みキャッシュ機能に非常に満足するようになりました。この機能は、私があまり干渉しなくても、ほとんどの状況で非常にうまく機能します。

しかし、サイトの 1 つでは、キャッシュを自分でクリアする機能 (完全にクリアすることも、個々のエントリを削除することも) が本当に必要でした。NGINX の無料コミュニティ エディションは、時間ベースのキャッシュ有効期限のみをサポートしています (つまり、1 時間後、1 日後などに何かが変更されたかどうかを確認するように設定できます)。しかし、特定のリソースがいつ変更されるかを事前に確実に判断する方法がない場合はどうなるでしょうか。たとえば、この投稿に戻って何かを編集するまでに 1 時間、1 日、または 1 年かかるかどうかはわかりません。また、1 日キャッシュしても問題ないのに、なぜ 1 時間しかキャッシュしないのでしょうか。

ここで、キャッシュを手動でクリアする機能（または、Web アプリケーションから NGINX に何かを消去する必要があることを通知する機能）が必要になります。この機能は NGINX の有料版でサポートされているため、NGINX の開発者はこの機能の必要性を明確に認識しています。ただし、ライセンスを自由に設定できる権利は確かにありますが、この機能が私にとって本当に必要な唯一の有料機能である場合、価格は私にとって少し高すぎます。

幸いなことに、キャッシュ ディレクトリからファイルを自分で削除するだけで、NGINX がこれを検出し、問題なくバックエンドから新しいコピーを取得します。ただし、構成を調整せずにこれを行うと、しばらくするとエラー ログに次のようなメッセージが大量に表示される可能性があります。

これらのエラーは、 fastcgi_cache_pathディレクティブのinactiveパラメータで指定された時間が経過した後に、NGINX 自体がキャッシュ エントリを削除しようとしたときに発生するようです。このデフォルトは 10 分ですが、任意の値に設定できます。たとえば、10 年に設定すると、その間にサーバーを再起動していない可能性は低いため、その間にメモリ内のキー インデックスがクリアされているはずです。これを行うと、キャッシュを自分でクリアする必要があります。NGINX はもうそれを実行しなくなります。

キャッシュ エントリが存在しないために削除できないことが重大なエラーと見なされるのは、本当に奇妙だと思います。重大度分類が非常に高いということは、特定のしきい値を下回るログ エントリを無視するだけでは取り除くことができないことを意味します。バックエンドから新しいコピーが取得されるとすぐにエントリが再び存在するようになるため、これはせいぜい警告であるべきだと思います。

さて、権限の問題や第三者の何かが原因でキャッシュ エントリを削除できなかった場合、NGINX が有効期限を過ぎてもキャッシュされたコンテンツを提供し続ける可能性があるため、これは重大なエラーになりますが、クリーンアップ プロセスではこの区別が行われないようです。