update.Webサービスでは、Solr、Elasticsearchをはじめとする検索エンジンの結果をキャッシュしたいことは比較的よくあるはなしではないだろうか。ユーザー向けに提供している検索では、人気のワードで検索されやすく、それ相応の負荷になる。コンテンツに付加されているタグをクリックすると同じタグが付けられているコンテンツが検索される事例など、おなじようなクエリが投げられやすい状況は容易に推測できる。このような場合検索エンジンにおいてはどのようなキャッシュ戦略をとれば良いか。Solr、Elasticsearchなどの検索エンジンに内蔵されているキャッシュ機能を利用するElasticsearchではFilterCache、SolrではさらにFilterCache、QueryResultCache、documentCacheなどより細かなキャッシュ機能を利用できる。これらのキャッシュはすべてメモリキャッシュであり、それほど大きなキャッシュ容量は期待出来ないが、最低限のキャッシュとしては有効だ。検索エンジン自体に内包されているキャッシュであるため、インデックス更新などで適切に破棄される。アプリケーション側でキャッシュする次に思いつくのがアプリケーション側で取得した検索結果をキャッシュする方法である。アプリケーション側でRDB、KVS等のデータストアを用意し、検索結果をキャッシュする。ミドルウェアとしてはMemcached、Redisなどが一般的だろうか。アプリケーションの性質に合わせたきめ細かな設定ができるのが特徴だ。反面、キャッシュ機能がアプリケーションと密結合してしまうため、APIとキャッシュの両方の面倒を見なければならず、コードの可読性は低下し、メンテナンスしづらくなる。1つのミドルウェアのAPIを複数のアプリケーションから参照している場合、それぞれのアプリケーションでキャッシュ機能を実装する必要も出てくる。メリット:アプリケーション固有のキャッシュ機能を提供できる。アプリケーションの変更だけで設定変更が出来る。APIをプロキシ経由にすることでキャッシュする3番目の方法は、アプリケーションとAPIをもつミドルウェアの間にプロキシを設置しキャッシュを行う方法である。Server、Squidなどが挙げられる。これらは特にミドルウェアに特有のキャッシュ機能を提供するわけではなく、標準的なHTTPレスポンスの殆どをキャッシュすることが出来る。この方法では、アプリケーションに変更を加えることなく、キャッシュ機能を提供できる。インメモリではなくディスクを利用したキャッシュも可能であり、大容量のキャッシュを実現できる。アプリケーションに手を加えないため、API側の負荷に応じて適切なキャッシュの有効期限を設定することが可能だ。弊社では、この方法でSolrの検索結果をキャッシュしている。銀の弾丸はないまあ、だいたいの場合そんなものはない。どの方法も一長一短あるし、組み合わせて使うこともできる。アプリケーション特有のキャッシュであればアプリケーションでカバーすればよいし、そうでなければプロキシキャッシュも候補に入るだろう。Kusabanaのようにアプリケーション特有のキャッシュ機能をもったプロキシもあることはある。そもそもSolrやElasticsearchではリソースにあわせて必要十分なキャッシュ設定を行うべきであろう。注意しなくてはいけないのは、実際のWebアプリケーションではこの3つをうまく組み合わせて作る技術が必要になる。透過的ではないキャッシュ機構はシステムの複雑性を確実に増加させる。それぞれの場合に応じて、適切な判断が必要だ。アプリケーションの速度と開発速度のトレードオフを見極め、ユーザーに適切に価値を提供できるシステムを目指さなくてはならない。ハードウェアの進歩を夢見るかである。requestStockLike24はるかさん@harukasanよろしくおねがいします。