こんにちは、検索チームのよこやまです。最近はもっぱらハイラルにいます。世界を救うことを放棄して行う探索と工作はとても楽しいですね。検索チームでは複数のプロダクトにわたり検索機能を管理しています。その中で、ある検索エンドポイントのみレスポンス速度が常に数秒かかっており、サービス体験に影響が出ていました。今回はそのエンドポイントのレスポンス速度改善に向けて行った取り組みについてご紹介させていただきます。公式ベストプラクティスに基づいたもので、特別新しい対策ではありません。遅いエンドポイントの現状確認まずは「遅い」と言っているエンドポイントのレスポンス速度が、実際にはどれぐらい遅いのか明確にします。出して改善のベースラインとしました。当時の一部期間の計測値が以下になります。秒近くになっており、改善が必要であることを再認識しました。いう検査速度改善のためのベストプラクティスが記載されているページがあります。今回は調査の前にこのページを改めて確認し、行えそうな対応の把握に務めました。いうインデキシング速度改善に関するページも確認していたのが功を奏しました。インデキシング速度改善が負荷の軽減となり、結果として検索速度の向上に繋がりました。仮説列挙レスポンス速度が遅い要因を可能な限り列挙しました。今回は要因の目処がついていなかったため、計測中に方向性を見失わないように、事前に考えうる要因を列挙し、「自分が今何を計測して、何のためにそれを行っているのか」を常に確認しながら進めました。原因ではないのでは?」など、まずは粒度を考えず列挙してから整理し、荒い粒度の仮説は更に掘り下げを行いました。これらの仮説を後の計測で確認していきました。その過程で新たな洞察を得ることも多く、その都度新たな仮説を追加し検証を進めました。仮説の列挙と整理が終わったところで、計測と考えうる対応の効果の確認に取り掛かりました。現時点で遅いことが確認できているのは検索機能エンドポイントのレスポンス速度であるため、上段のアプリケーションレイヤーから計測していきました。リクエストが、検索機能自体のレスポンス速度の主要因であることを確定させます。遅さの主要因であることを明らかにしました。プロファイラを利用しました。下記のようなコードを差し込むと、それぞれの関数ごとにどれぐらい時間がかかっているか計測できるので非常に有用です。mapping、インデックスされているデータを確認しました。このときに前述の仮説と一致するものや、公式ベストプラクティスと反している内容を記録しておき、追々の計測でそこを修正した場合にどれぐらい速度が改善されるか確認しました。利用して単発のクエリで遅いリクエストが再現できないか確認しました。Profilerを利用すると見やすいのでオススメです。利用するのが良いでしょう。確認できない項目があります。詳細は公式ドキュメントを参照してください。変更を試し、速度に改善が見られないか確認します。回実行」のシナリオを行い、その結果を集計することで単発リクエストに依存しない計測をしました。使用方法についてはこちらの過去の記事をご参照ください。tech.visasq.com過去記事と同様に既存のインデックスを利用してカスタムトラックを作成しました。注意点として、カスタムトラックを使用する場合、指定したインデックスのデータをそのまま利用します。そのため、対象インデックスにセンシティブなデータが入っている場合、取り扱いに注意が必要です。計測時に発行するクエリは、本番環境のクエリログを利用しました。今回はゼロヒットクエリを除くことはせず、クエリ文字列の長い順にソートして間引きしました。計測結果が安定しなかった今回の計測は独立した環境を用意し実施していましたが、同一のシナリオ・インデックス設定・データセット・クエリ集合を利用しても計測結果にブレが生じ、評価が非常に難しいものになりました。そのため、計測結果を安定させるため下記に取り組みました。回実行」という非常にシンプルなものでした。このシナリオを採用した理由として、該当の検索機能はリクエスト数やインデキシング頻度が非常に多いものではなく、負荷による影響は少ないと判断したためです。利用目的は負荷試験の文脈よりも、複数回検索リクエストを試行した場合のレスポンス速度の統計取得に重きを置いていました。延長が有効であることがわかり、この判断は誤りだったことがわかりました。parallelを利用し、インデキシングと検索の並列実行をシナリオに含めるべきでした。よる検索対象フィールドの集約」が候補に上がりました。台と大幅に改善しました。最後に結果としてレスポンス速度の改善は達成しましたが、調査・計測はとても上手く行ったとは言えません。計測で明らかにしきれなかった要因がありました。今回の取り組みは自分自身にとっても非常に有意義なものでした。この経験を元に今後もビザスクの検索の改善を進めていきたいと思います。*1:当初はリクエスト都度ランダムにクエリを選択し発行していましたが、事前にランダムにクエリ発行順を決めておき、すべての計測でその発行順に従うようにしました*2:今回の対応とは別で、他の検索機能におけるインデキシング負荷を軽減する試みも進めておりました。reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。