「臭いものには蓋をしろ」的な解決方法としてのキャッシュ

特に最近のWebアプリでは、キャッシュという考え方が流行っていて、あらゆるところにキャッシュの仕組みが適応されている。パフォーマンスのために処理結果をキャッシュすること自体は、よいアイデアだと思う。それにしても最近の流れは、最初からキャッシュに頼りすぎているんではないかと思う。

キャッシュを使うことのデメリットを考えてみる。

複雑なバグを生む可能性が増える

単純に処理の多い関数をメモ化するようなキャッシュの使い方なら特に問題は起きないだろうけど、データストア、view、viewのコンポーネントなど複数の層でキャッシュするようになると、最終的な出力が正しいのかを確認するのが難しくなる。更に、アプリ全体で使用するキャッシュ、ユーザ毎別々のキャッシュのように、キャッシュを適応すべきかどうかを場合によって区別する必要が出てくると、相当複雑になってくる。重たい処理を、軽く見せようとして導入したキャッシュが、問題の種になるのは、滑稽な話。

ユーザに新たなストレスを感じさせるかもしれない

例えば、重たい処理をキャッシュを利用することで、軽く見せることに成功したとしても、キャッシュが無い状態でアクセスされた場合には、重たい処理の時間分、ユーザを待たせることになる。また、別の問題として、ユーザが重たい処理だと思っていない処理(キャッシュとは関係無い処理)が、キャッシュを適応したページより重たいという状況が発生する可能性が出てくる。ユーザは、動的になんかの統計を取って画像を生成するような処理が含まれるページは遅いだろうと推測できるから、数秒待つことはできる。でも、特に重たい処理があると思えないページの表示には、数秒も待てないんじゃないだろうか?単純に「全てのページが3秒以内に表示できたからパフォーマンステスト合格」というのは、意味のあるテストじゃないかもしれない。

開発者が対面すべき本当の問題を隠してしまう

ページが表示されるのが遅いというのは、何かしらの問題があるはず。本来は、まずその根本原因を解決しようとするべきだと思う。キャッシュを利用して解決するという方法が、「臭いものには蓋をしろ」的な解決方法の場合、あんまり頼りすぎてはいけない。キャッシュに頼ったらある意味半分詰んでると思った方がいいかも。


というようなことを、Myはてなのページが異常に重たいのを見てて考えてた。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です


reCaptcha の認証期間が終了しました。ページを再読み込みしてください。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください