はじめに
こんにちはrilmayerです。
この記事はアドベントカレンダー「Search&Discovery 全部俺」23日目の記事となります。（遅刻
本日は検索システムについて、どんなことに注意してモニタリングをすれば良いかというのをまとめてみたいと思います。
この記事では「具体的にどんなツールを使うか」というよりもどのような考え方をしてモニタリングをするかということをまとめていければと思います。
検索システムとモニタリングの基本的な考え方
一口に検索システムと言ってもその範囲や構成には様々な種類があります。
ある程度独立したマイクロサービスとしての検索システムもあれば、バックエンドの一機能（ファンクション）としての検索システムもあると思われます。
とはいえ、基本的な考え方としてはどんな理由で、何のメトリクスを、どのように測って、それを元にどのようなアクションをするかというのを考えていくことになります。
システムモニタリングの6観点
『入門 監視』というモニタリングについて書かれた非常に参考になる書籍があります。
この本の中では、以下のように6つのモニタリング戦略を考える上で有用な切り口が章立てとして用意してあります。
- ビジネス
- フロントエンド
- アプリケーション
- サーバー
- ネットワーク
- セキュリティ
検索システムではこれらの観点を横断的に考慮する必要がありますが、これらの観点は「どんな理由で」を考える際に有効となります。
ということで、以下は上記の観点を参考に検索システムをモニタリングする際の目的を大きく3つの項目として落としてみました。
検索システムモニタリングの3つの目的
経験上なので特にどこかの書籍にあるとかではないのですが、検索システムのモニタリングでは主に3つの目的を考えることができます。
- ユーザーが意図した通りに動いているかを確認する（ユーザーに対する期待）
- システムが意図した通りに動いているかを確認する（システムに対する期待）
- 不正やセキュリティ上の危険を確認する
ここで言う確認と言うのは、「テスト」のような個別の具体例ではなく、統計値などで測ることができる「指標等の変動」の確認になります。
またモニタリングは「定常的な確認」と「施策効果の確認」の2つの観点から考えることも可能ですので、以下にその例を紹介します。
定常的な確認
定常的な確認については、検索に関するいくつかの指標を用意しておいてそれらの数値が「変わらないこと」を確認します。
もし変化があった場合は「システム」もしくは「ユーザー」のどちらかが変化したと仮定して、その都度なぜ数値が変化したかという原因を探していくことになります。
良い変化であれば問題ありませんが、「急に検索結果のアイテムヒット数がいつもよりかなり少なくなった」などの変化などは何か問題があるかもしれません。
そうしたシステムとしては動作していているため気付きにくいトラブルにいち早く対応することも目的です。
施策効果の確認（≒評価）
システム変更の前後では以下のように考えることができます。
例えば「検索システムでヒットするアイテムの再現率が良くないことが分かり、再現率を上げることによりユーザーがより多くのアクションを行うといった仮説をたて、それを検証するためにシノニム辞書を用いてより多くのアイテムがヒットするようにする」といった施策を行った場合を考えてみます。
システムとしてが意図通りに動いているかは「システムが理想的に動作したとして、どのように検索結果が変化するか」と言った観点から整理することができます。
上記の例ではシノニム辞書に含まれるキーワードについて「平均ヒット件数」が上昇するかどうかなどで確認することができます。（他のキーワードが変わらない場合は全体的に上昇することが期待されます）
ただし、アイテムに時期変動がある場合やユーザーがそれらのキーワードを検索しない場合などは数値として期待通りにならない場合があることに注意が必要です。
ユーザーが意図通りに動いているかを確認するには行動ログなどから算出したオンライン指標等を確認することで達成されます。
上記の例では「詳細遷移率等の指標」が上昇することなどが期待されます。
ここからは以下に3つの観点それぞれを少しだけ詳しく見ていこうと思います。
ユーザーが意図した通りに動いているかを確認する
『入門 監視』における「ビジネス」の観点が多分に含まれます。
理由
どのような検索システムも多くは目的が存在しているはずで、それが企業としてのものであれば多くは売り上げや利益を上げることにあります。
そこで「検索システムがビジネスに貢献しているか」を監視する必要があります。
メトリクス
通常は売り上げそのものよりも、検索システムを使って操作できそうなこと、例えばユーザーが検索行動を促す（検索UU）や、検索結果で目的のアイテムを見つけることができているか（CTR）などを確認していきます。
例えばビジネス観点からはこちらの記事で紹介したオンラインメトリクスが役にたちます。
計測方法
アプリケーションログなどから、メトリクスを計算して算出します。定期的にそうしたメトリクスが欲しい場合はデータパイプラインなどを作成してビジネス用のデータレイク等を作成することが多いかと思います。
可視化もセットで考えられることもあり、SaaSのデータ可視化ツールであるLookerやDatastudioなどのサービスを活用してダッシュボードを構築することもあります。
ランキングを考慮したビジネスKPIがある場合は、アイテムの表示順に関するログをアプリケーションで用意する必要があるので注意です。
アクション
それぞれのメトリクスに対してはそれを元に施策や戦略を考えていくということになります。
またシステマティックにアクションが自動化できるケースはそう多くないのもビジネス観点のモニタリングの特徴かもしれません。
システムが意図した通りに動いているかを確認する
『入門 監視』における以下の観点を多分に含みます。
- フロントエンド
- アプリケーション
- サーバー
- ネットワーク
理由
検索システムでは最低限システムとしての期待される挙動があるので、それらが行えているかを確認する必要があります。
この観点では主に「システムの動作状況を知ること」と「システムで何が起こっていたかを知ること」がモニタリングの目的になります。
メトリクス（ログ）・計測方法
基本的にはユーザーからどのようなリクエストが来て、どのようなレスポンスを返せているかをログやメトリクスとして取得します。
検索結果（SERPs: Search Results Pages）上の統計情報などもシステムの挙動として計測することができます。
システムのレイヤーによって計測方法や特徴的なメトリクスも異なります。
フロント（ブラウザ上での動作）のモニタリングではjavascriptなどを用いて、ログ情報を送ったりすることによって「ページロードの時間」などをモニタリングします。
アプリケーションのモニタリングでは、ヘルスエンドポイントパターンなどを作成したり、ロガーによるログの書き出し、内部の通信などのキャッチによってモニタリングを行うことができます。
ログの書き出しの仕組みとてしはファイルに書き出してそれを定期的にデータレイクに蓄積していくものや、ログが発生するたびにデータレイクに書き出していくものがありますが、検索システムでは検索結果一覧にどんなアイテムがどのような順番で表示されたかは比較的重要な情報ですのでアプリケーションのログとして残しておくのが良いです。
これらによって、「正常なレスポンスが返っているか（死活監視）」、「SERPの統計情報」などをモニタリングすることができます。
サーバーやネットワークの監視ではクラウドサービスでセットになっているものや、DatadogやMackerelなどのSaaSを利用することができます。
よく行われるのは「CPU」や「メモリ利用率」、「ディスクの空き容量」などです。
アクション
システムダウンや挙動が怪しいことが確認される場合は復旧を行います。
バグの場合はアプリケーションの修正を行い、トラフィックを捌けないなどの場合はリソースの拡張などの対応をします。
セキュリティ観点のモニタリング
理由
検索サービスで特に気をつけたい脅威としてアルゴリズムやデータの流出、悪意のある攻撃によるサービスの停止などがあります。
例えば、「アルゴリズムやデータの流出」については検索ロジックがユーザーに把握されてしまうとそれを悪用される場合があったり、データベースとしてのサービスでデータを取得されると外部で同様のサービスを展開される危険があるためモニタリングが必要です。
「悪意のある攻撃によるサービスの停止」については悪意のあるユーザーによってシステムに負荷がかけられダウンしてしまうことや、侵入による想定外の操作などを検知する必要もあります。
メトリクス（ログ）・計測方法
ネットワーク侵入検知システムやホスト型侵入検知システムで不正侵入を確認するのは通常のモニタリングですが、アクセス元のIPアドレスの取得やauditdなどで操作コマンドのログ取得を行います。
アクション
接続IPが同一で大量のアクセスがあったり事前に用意してあるブラックリストに引っかかる場合にアクセスを遮断したり、特定の操作を行った場合に管理者に連絡が行くようにして個別に対処していきます。
おわりに
今回は検索システムのモニタリングについて紹介し、モニタリングの観点と「理由」、「メトリクス（ログ）」、「計測方法」、「アクション」で整理してみました。
今回の内容をより細かく知りたい場合は『入門 監視』をが確認いただけると良いかもしれません。