Tweet
Tweet

Slide 1

Slide 1 text

OpenSearchでレガシーな検索処理の 大幅改善をやってやろう PHPカンファレンス小田原2025

Slide 2

Slide 2 text

自己紹介 ● 堂薗 伸樹(どうぞの のぶき) / DPon（@DPontaro） ○ 󰢄園　󰢐薗 ● 職業：エンジニア ● 所属：スターフェスティバル株式会社 ● 家族：妻󰠀 子👦👦 犬 ● ゲーム好き ● 大阪からきました ● 🎉 カンファレンス初登壇 🎉

Slide 3

Slide 3 text

会社とサービスの話 ● https://gochikuru.com/ ● 法人・団体向けの宅配弁当 ケータリング・オードブルの デリバリーサービス。

Slide 4

Slide 4 text

前段 プロジェクトの説明

Slide 5

Slide 5 text

プロジェクトの特徴 ● ごちクルとは別の特定業界向けのお弁当デリバリーサービス ● Initial Commitは2015年 ● コロナ禍で需要減。リソース都合もあり、しばらく専任のエンジニアがついていない 状態。 ● ときどき改善依頼があった際、手が空いてる人がスポットでアサインされる

Slide 6

Slide 6 text

パフォーマンスの課題 ● 2024年春、サイトのパフォーマンスは少し触れただけでも体感できるくらいに悪い ● 需要が戻りつつあるなか、マイナスの印象を与えるわけにもいかない

Slide 7

Slide 7 text

レガシーな環境

Slide 8

Slide 8 text

初手の改善

Slide 9

Slide 9 text

ボトルネックをみつける 商品検索のController。 リクエストされる頻度高く、かつ重い ページ。 中央値が 1.9 sec これに加え、ページ表示までに画像や cssのダウンロードなども発生する

Slide 10

Slide 10 text

初手の改善 スロークエリに手を入れてみる ● INDEXの追加 ● 該当箇所のコードを調整し、発行されるクエリを修正 結果200msec くらいは改善したが焼け石に水。

Slide 11

Slide 11 text

さてどうしたものか 長年専任がついていないプロジェクト、コードはツギハギで無駄も多い。 複雑に絡み合ったコードの解消のために、検索ロジック全体を組み直す必要がありそ う。 → それならもう OpenSearch に移行してもいいのでは？

Slide 12

Slide 12 text

OpenSearchとは ● 分散型の検索エンジン。Elasticsearchのフォーク版 ● クラスタ構成、複数のノードにデータ分散。 ● 高速な全文検索が可能

Slide 13

Slide 13 text

簡単に用語解説：Document ● Document：データを格納する単位。JSON形式。 ○ 学生のデータベースでは、 Documentは1人の学生を表せる ○ RDBにおける行に相当

Slide 14

Slide 14 text

簡単に用語解説：Index ● Index：Documentの集まり ○ RDBでいうテーブル ○ 学生のデータベースでは、 Indexはすべての学生を表す

Slide 15

Slide 15 text

簡単に用語解説：Clusterとか ● Cluster, Node ○ Clusterは、Nodeの集まり。 ○ Nodeはデータを保存、検索リクエストを処理 するサーバ。 ● Shard ○ いわゆる水平分割。 ○ Indexのdocumentを行単位でシャード分割し て分散 ○ シャードの分割目安：シャードのサイズを 10 ～ 50 GB に制限することです。（公式いわく）

Slide 16

Slide 16 text

OpenSearchへの移行

Slide 17

Slide 17 text

OpenSearch公式のPHPクライアント まぁバージョン下げたら対応してるやつあるやろ。 https://github.com/opensearch-project/opensearch-php

Slide 18

Slide 18 text

おっかしいなー

Slide 19

Slide 19 text

真面目にどうするか 理想はPHPのバージョンアップ。そうはいっても ● スポット的なアサインでもあり、メインは別プロジェクトの人員 ● 元のミッションはパフォーマンス改善。 →バージョンアップはスコープ外では？ ● 認知負荷の高いコードの理解、スロークエリの対応など既にある程度時間もかけて いる。 →このタイミングからバージョンアップまでやる？ ※言わずもがなテストはメンテされておらず

Slide 20

Slide 20 text

戦略的後回し // TODO PHPバージョンアップ 結局公式のPHP7.3が対応してるバージョンのクライアントを落としてから、7.1で動くよう にエラーが出る箇所をつぶして対応させました。 ※バージョンアップはパフォーマンス改善後に対応しました(7.4までですけど...

Slide 21

Slide 21 text

バッチの実装 毎時 RDS -> OpenSearch へデータ投入するバッチを実行。 その際”YYYYMMDD-HH”のサフィックスを持つINDEXが作成される。 　例：product-index-20250412-15 INDEX作成後、アプリケーションが参照している OpenSearchのINDEXのエイリアスを変更。 　実行前：product_index -> product-index-20250412-14 　実行後：product_index -> product-index-20250412-15

Slide 22

Slide 22 text

マッピングの話 マッピングはOpenSearchに、ドキュメントとそのフィールドの保存方法とインデックスを指示します。 各フィールドのデータ型を指定することで (例えば、年を日付にするなど )、保存やクエリをより効率的に行うこと ができます。 Dynamic mapping （動的マッピング） 　新しいデータやフィールドが自動的に追加される。 Explicit mapping （明示的マッピング） 　推奨。正確な構造とデータ型を前もって定義できる。 　パフォーマンスや正確性を高めることができる

Slide 23

Slide 23 text

マッピング一例 "id": map[string]string{"type": "integer"}, "product_name": map[string]interface{}{ "type": "text", "analyzer": "product_index_analyzer", "search_analyzer": "product_search_analyzer", },

Slide 24

Slide 24 text

analyze 文字列を検索に使えるように「分かち書き（トークン化）」＆「正規化」する処理

Slide 25

Slide 25 text

analyzer と search_analyzer "product_name": map[string]interface{}{ "type": "text", "analyzer": "product_index_analyzer", "search_analyzer": "product_search_analyzer", }, analyzer：インデックス時（保存時）に使用する analyzer を指定。 search_analyzer：検索時に使用する analyzer を指定

Slide 26

Slide 26 text

synonym_filter search_analyzer には上記のsynonym_filterという同義語の設定がされている。 この設定により曖昧検索に対応できる "synonym_filter": map[string]interface{}{ "type": "synonym", "synonyms": []string{ "ウナギ,ウナジュウ", "子供,お子様",

Slide 27

Slide 27 text

やってみてどうだった

Slide 28

Slide 28 text

🎉結果発表🎉 before 中央値：1.9sec after 中央値：0.92sec

Slide 29

Slide 29 text

売上につながった？ ここ1年で売上の数値はしっかり伸びている 🎉 複数要因があるものではありますが、パフォーマンス改善で下支えが出来た ※余談　社内の営業の方々から直接 DMでめちゃ助かったと何人か声かけていただいて、好感触

Slide 30

Slide 30 text

他改善するなら ● 毎時のバッチ実行 ○ 日々商品のデータは更新されているが、最大 1時間の遅延を許容している状態 ○ よりリアルタイムに更新したい場合、イベント駆動な仕組みを取り入れたり ● インフラのあいのり ○ ごちクルと同じインスタンスなので障害発生した際は、どちらも検索処理が機能しなくなる（今のとこ ろ発生はしていない） ○ 切り離せば懸念はなくなるが、コスト増にはなるのでバランス考えて ● synonym_filterなどがコード中に定義されている ○ 変更の際にエンジニアの手が入る状態となっているので、できれば外部ファイルに逃がしたほうが 良い