概要
アプリケーションの高速化のため、サーバー上のオンメモリでキャッシュを保持する構成はよく使われます。 しかし、冗長化構成で複数サーバーにリクエストが分散される場合、キャッシュがサーバーごとに独立してしまい、ヒット率が低下することがあります。
この記事では、オンメモリキャッシュの限界と、共通キャッシュとしてインメモリデータベースを活用するメリットを整理してみようと思います。
背景：オンメモリキャッシュの導入
アプリケーションのパフォーマンスを求める部分があり調査の結果、Webサーバーで行っている情報取得処理の処理時間に改善の必要がありました。
対象の情報は頻繁に更新されるようなデータではなかったので、重たい処理の結果をオンメモリにキャッシュする改善を図りました。
オンメモリなので速度面も改善し、同じリクエストに対して2度目以降は高速に応答出来るようになりました。
課題：オンメモリキャッシュの課題
しかし、負荷分散により、サーバーを複数台に増やして分散させると問題が発生することになります。
"サーバー1"にキャッシュがあっても、次のアクセスが"サーバー2"に振られると再び重たい処理が走ります。 結果としてキャッシュヒット率が下がり、想定していた高速化が得られませんでした。
このように、分散構成ではオンメモリキャッシュは孤立してしまって、全体最適にならないという課題が浮き彫りになります。
共有キャッシュの必要性
課題を解決するためには、「どのサーバーからも参照できる共通キャッシュ」が必要です。
共有キャッシュの候補として真っ先に挙がるのは、既存のリレーショナルデータベース（以下：RDB）ですが、RDBの場合は以下のような点がネックになりそうという懸念がありました。
- ディスクＩ/Ｏによる速度低下
- TTL（有効期限）や削除ポリシーの自前実装
- 同時アクセス時のロック競合やスループット低下の懸念
- トランザクション制御や永続性など、キャッシュ用途には過剰な仕組み
これらの懸念から結果としてRDBを使うのは非効率と判断しました。
インメモリデータベースの採用
- 複数サーバーで共有できる
- オンメモリ並みの速さを保てる
この2つの両立を実現するための仕組みはいくつかありますが、その中の一つであるインメモリデータベースを採用しました。
インメモリデータベースは、メモリ上でデータを保持しつつネットワーク経由で複数ノードからアクセス可能です。
以下のようなメリットがあります。
キャッシュ共通化
- どのサーバーからのアクセスでもキャッシュを参照
高速な応答性能
- ディスクアクセス不要でオンメモリ並みの速度
TTL管理が標準搭載
- 自動的に指定の期間でキャッシュをクリアなども出来て、運用負荷も軽減
スケールアウトも容易
- キャッシュサーバーの増設や設定変更するだけで冗長化/高可用性にも対応
結果として、オンメモリキャッシュの弱点を克服しつつ、分散構成でも安定した高速応答を実現できました。
まとめ
キャッシュ戦略はシステム構成や負荷パターンに強く依存します。
特に最近多くなっている、冗長化やスケールアウトを前提とするシステムの場合は、"どこでキャッシュを保持するか"を最初に設計することが、結果的に効果的なチューニングに繋がると考えます。
また共通キャッシュの手法はいろいろあると思いますが、インメモリデータベースは非常に強力な選択肢になるので是非採用を検討ください。
本記事は以上となります。
今回の内容は当たり前の内容かもしれませんが、システムのパフォーマンス面の課題を事前に解消する一助になれば幸いです。
最後までご覧いただきありがとうございました。
