カスタムメトリクスでキャッシュヒットを追跡し、パフォーマンスを向上させた実践ガイド

AppSignalを利用するアプリケーションが稼働しているすべてのサーバーは、30秒ごとにサンプルとメトリクスのコレクションをPush APIへ送信しています。

各リクエストにはキーが付与されており、このキーをもとにデータがどのアプリケーションから送られたものかを判別します。そのためには、受信したリクエストごとにデータベースへ問い合わせて該当アプリを検索する必要があります。月間300億件ものリクエストを処理している私たちは、AppSignalをより高速に動かすため、常にクエリ数を削減する方法を模索しています。

キャッシュを導入したのにクエリは減らなかった

データベースクラスタへの負荷を軽減するため、キャッシュ機構を実装しました。データベースからアプリ情報を取得するたびに、その結果をMemcachedに1分間保存する仕組みです。ところが、この変更を本番環境へデプロイしてみると、なんと以前よりもクエリ数が増えていることが判明しました。キャッシュが必要以上に頻繁に無効化されているようだったのです。

そこで原因を突き止めるため、キャッシュが不適切に無効化されている箇所を特定するカスタムメトリクスを追加しました。

キャッシュを無効化する箇所は複数あります。たとえば、push処理の完了時刻が更新されたときや、新しい名前空間（ネームスペース）を検出したときなどです。

どの無効化処理が原因なのかを特定するため、複数のカウンターを追加しました。この例では、無効化の総数を記録するapp.cache.invalidateカウンターをインクリメントし、個別の処理にはapp.cache.invalidate_push_timeやapp.cache.invalidate_namespacesといった専用キーを使用しています。

グラフ化で一目瞭然になった原因

これらのカスタムメトリクスを追加したことで、キャッシュヒット数を時間軸に沿ってグラフ化できるようになりました。すると、どのキャッシュキーがクエリ急増の引き金になっているのかが即座に明らかになりました。app.cache.invalidate_namespacesキーが、リクエストごとに無効化されていたのです。

キャッシュ可能なリクエストの総数はapp.cache.maybeとしてカウントしています。

この問題への修正をデプロイした後は、アプリの名前空間が更新されない限り、無効化回数はゼロまで低下しました。

まとめ：可視化がトラブルシューティングを加速する

カスタムメトリクスを追加すれば、「何が・どこで・いつ・どのくらいの頻度で起きているのか」を容易に把握できるようになります。今回のケースでは、キャッシュ無効化の回数を数値として捉え、見やすいグラフで表示できたことで、問題を素早く発見できました。必要なのは、特定の値をインクリメントしてダッシュボードを作成するための、わずか数行のコードだけです。

カスタムメトリクスについてご質問がある場合や、アプリケーションへの導入でお手伝いできることがあれば、お気軽にお問い合わせください。喜んでサポートいたします！

Robert Beekman（ロバート・ビークマン）

共同創業者として、Robertは私たちの最初のコミットを書いた人物です。サポートチームの手本となる存在であり、コードの細部まで熟知しています。趣味は旅行と写真撮影（同時に楽しむのが流儀）です。