小山 凌太

検索エンジンをElastic Cloudに移行したことから、AWSを使うメリットが薄れ、他チームのシステムとの連携なども考えてGoogle Cloudへの移行を開始しました。 その中で、検索エンジンへの更新システムを大きく刷新し、Google Cloudで作り直しました。 元々は更新API→Kafka→更新workerという構成でScalaを使ったアプリケーションを運用していましたが、Scalaのメンテナンスができていなかったのと、Kafkaは中のデータ確認などが難しく、更新データを細かく辿ることが難しかったことからGoogle Cloudでは中間にMySQLを配置した以下のような構成にしました。 更新API→Pub/Sub→更新worker→MySQL→Logstash MySQLをCloud SQLで運用しており、メンテナンスが定期的に発生することから、一時的なコネクションエラーを救うためにPub/Subを導入しており、またElasticsearchへの更新がデフォルトで機能として備わっているLogstashを使うことでアプリケーションの開発コストを下げる狙いがありました。実際にはこれまで使ってこなかったツールを様々使っているため、現状運用は日々苦労しているところはありますが、MySQLを挟んだことで、これまで検索チームではあまり意識できていなかった細かなデータ分析なども可能になりました。

これまでAWS上でEKSを利用してSolrを運用していましたが、Kubernetes自体の運用負荷の高さと、StatefulSetでのSolrの運用の難しさが重なって、検索改善やSolrのバージョンアップなどができていませんでした。 そこで、マネージドな検索エンジンを使って運用負荷を下げる + 検索エンジンとして機能が充実しており、様々なグロース施策に繋げられるElastic Cloudへの移行を実施しました。 自分は主に、SolrからElasticsearchに検索エンジンを移行するにあたって、改めて検索ユースケースを整理し、Elasticsearch上ではどのようなクエリを構成することで同様のユースケースを満たすことができるかを整理する部分で、要件定義から開発前の調査をメインで行いました。 また、実際の開発の中ではElastic Cloud自体のTerraform運用を検討し、インフラ部分の整備を中心に実施、その後性能試験などを担当しました。