【ITニュース解説】Goodbye Redis, Hello Postgres: How Deleting Our Cache Layer Made Production Faster

Webアプリケーションは、ユーザーのリクエストに応じてデータを処理し、表示する仕組みである。このとき、何度も同じデータが必要になる場合がある。そのたびにデータベースにアクセスすると時間がかかり、システムの応答速度が低下する。この問題を解決するために、多くのシステムでは「キャッシュ」と呼ばれる仕組みを利用する。キャッシュは、よく使うデータを一時的に記憶しておき、次に同じデータが必要になったときに、データベースよりも高速にそのデータを提供できるようにする技術である。

これまで、多くの開発者はこのようなキャッシュとして、Redisのような専用のキャッシュシステムを導入してきた。Redisは非常に高速なデータストアであり、キャッシュに特化しているため、Webアプリケーションのパフォーマンス向上に大きく貢献してきた。しかし、このアプローチには潜在的な問題が存在する。それは「二重の真実源（Two Sources of Truth）」と呼ばれる状況を生み出すことである。アプリケーションのデータがメインのデータベース（例えばPostgreSQL）に存在し、さらにそのデータのコピーがキャッシュ（Redis）にも存在する状態を指す。

この二重の真実源の問題は、システムに複雑さをもたらし、運用上の課題を引き起こす可能性がある。データベースとキャッシュの間でデータの内容が異なる「不整合」が発生するリスクが高まるのだ。例えば、データベースのデータが更新されたにもかかわらず、キャッシュのデータが古いまま残ってしまうと、ユーザーは誤った情報を受け取ることになる。この不整合を防ぐためには、データが更新された際に、データベースだけでなくキャッシュも同時に更新または無効化するといった複雑な同期処理が必要になる。この同期処理は開発者の負担を増やし、バグの原因にもなりかねない。また、専用のキャッシュシステムを運用することは、追加のサーバーやリソース、監視体制が必要となり、運用コストも増加する。

今回のニュース記事は、この一般的なキャッシュ戦略に対する大胆な解決策を提示している。それは、Redisのような専用のキャッシュ層を完全に削除し、代わりに既存のリレーショナルデータベースであるPostgreSQLをキャッシュとして利用するという方法である。そして驚くべきことに、この変更によって本番環境のシステムが以前よりも高速になったという。

この解決策の鍵となるのが、PostgreSQLの「UNLOGGEDテーブル」という特殊な機能である。通常のPostgreSQLテーブルは、データが変更されるたびに、その変更内容を「WAL（Write-Ahead Log）」と呼ばれる特別なログファイルに記録する。WALは、データベースの信頼性を保証するための非常に重要な仕組みである。もしシステムが予期せずクラッシュした場合でも、WALに記録された情報に基づいてデータベースの状態を正確に復旧できるからだ。しかし、このWALへの書き込み処理は、データの書き込み性能に一定のオーバーヘッドをもたらす。

UNLOGGEDテーブルは、このWALへの書き込みを「行わない」テーブルである。WALに記録されないため、データの書き込み処理が通常のテーブルよりも大幅に高速になる。これは、キャッシュのように一時的で、高速な読み書きが求められるデータには非常に適した特性である。もちろん、UNLOGGEDテーブルにはデメリットもある。データベースがクラッシュした場合、UNLOGGEDテーブルに保存されていたデータは失われてしまう。しかし、キャッシュのデータは本来一時的なものであり、もし失われてもメインのデータベースから再生成できるため、このデメリットは問題にならないことが多い。むしろ、高速な書き込み性能が優先されるキャッシュ用途においては、大きなメリットとなる。

つまり、記事で紹介されたアプローチは、アプリケーションが必要とする一時的なデータをPostgreSQLのUNLOGGEDテーブルに保存することで、Redisのような外部のキャッシュシステムを不要にしたのである。これにより、「二重の真実源」の問題が解消され、データ管理の複雑さが大幅に軽減された。メインのデータベースであるPostgreSQLが、アプリケーションの唯一の真実源となり、キャッシュの役割も兼ねるようになったため、データの一貫性を保つための同期処理が不要になったのだ。

なぜキャッシュ層を削除したのに本番環境が高速になったのだろうか。それは、システム全体の複雑さが減ったことが主な要因と考えられる。Redisのようなキャッシュシステムを運用するには、ネットワークを介した通信、キャッシュの管理ロジック、データの一貫性を保つための複雑なコードなど、さまざまなオーバーヘッドが発生する。これらのオーバーヘッドが積み重なることで、見かけ上は高速なキャッシュ層があったとしても、システム全体のスループットや応答速度を低下させてしまう場合があるのだ。キャッシュを削除し、PostgreSQLに一本化することで、これらの余計な処理や複雑な管理が不要になり、結果としてアプリケーションのシンプルな構造が性能向上に繋がったのである。特に、PostgreSQL自体が非常に高速で効率的なデータベースであるため、UNLOGGEDテーブルを活用することで、専用キャッシュシステムにも匹敵するパフォーマンスを実現できたと言える。

この事例は、必ずしもすべてのシステムでキャッシュを削除すべきだと主張しているわけではない。しかし、システム設計において、安易に外部のキャッシュシステムを導入する前に、その必要性と、それがもたらす複雑性や運用コストを慎重に検討することの重要性を示唆している。特に、PostgreSQLのような高機能なデータベースが持つ「UNLOGGEDテーブル」のような特性を理解し、適切に活用することで、よりシンプルで高速、そして運用しやすいシステムを構築できる可能性があることを教えてくれる貴重な事例である。システムエンジニアを目指す者にとって、既存の技術やアプローチに囚われず、本質的な課題解決のための最適な方法を追求する視点がいかに重要であるかを改めて認識させてくれるだろう。