合同会社DMM.comのElastic Cloud導入事例
参考になった
0
合同会社DMM.com / 小山凌太
メンバー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Goldプラン | 全文検索・集計機能など一般的な検索機能、セキュリティ機能、サポートケースなど | 11名〜50名 | 2025年3月 | B to C |
| 利用プラン | Goldプラン |
|---|---|
| 利用機能 | 全文検索・集計機能など一般的な検索機能、セキュリティ機能、サポートケースなど |
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2025年3月 |
| 事業形態 | B to C |
アーキテクチャ
アーキテクチャの意図・工夫
背景
Amazon EKS
元々SolrをEKS上で検索・更新でクラスタ分離して運用していたことから、Solrから脱却した現在でも検索用のシステムと更新用のシステムでEKSクラスタを分離しています。
Elastic Cloud
Solrからの移行後にパフォーマンス課題が出たことから、元々は1つのDeployment(Elastic Cloudにおけるクラスタ)で運用していたものを、サービスごとに分離するようにしました。現在全てのサービスを分離できてはいないため、一部のサービスはIndexのみ分離して横断検索用のDeployment内に乗せています。
意図や工夫
エイリアスを用いた検索と更新先Index
DMMのECサイトでは検索窓で「すべて」を選択して検索すると対応している全てのサービスを横断した検索をすることができます。この機能を提供するために、複数Indexを一つのエイリアスに紐づけることで、そのエイリアスに検索すれば全てのIndexのデータを集約して取得できるようにしています。
一方で更新については意図的にエイリアスではなく直接Indexを指定して更新するようにしています。これはElastic Cloudの reindex という機能を利用するためです。例えば何かしらのIndexの設定を変更する場合にはDMMでは以下のような手順で実施します。
- Index Templateを更新する
- 新しいIndexを作成する
- 古いIndexから新しいIndexにreindexする
- 古いIndexと新しいIndexに並行で更新データを投げる
- 古いIndexと新しいIndexのデータ同期が取れたら新しいIndexをエイリアスに紐づけ、古いIndexをエイリアスから外す
- 古いIndexを削除する
この手順の中で、データ同期が取れる前に新しいIndexをエイリアスに紐づけてしまうと古いデータが検索結果に表示されてしまいます。それを避けるためにエイリアスに紐づける前のIndexに直接更新データを投げられるようにしています。
Elastic Cloudの複数Deployment
背景にも記載した通り、移行してしばらく運用する中でパフォーマンス課題が出てきました。この原因の一つが、全ての検索リクエストを横断検索用のエイリアスにしていたことによって、不要なIndexへの検索が動いていたことです。
そこで、サービスを横断した検索をしない直接サービスを指定する検索についてはIndexやDeploymentを分離することでパフォーマンス改善を行いました。ただし、そうしたサービスもサービス横断検索の対象ではあるので、横断検索用のDeploymentにIndex自体は残し、専用DeploymentのIndexと合わせて並行更新することでサービス横断の検索にも対応しています。
Cloud Dataflowの利用
purchased indexはユーザの購入済商品のデータをBigQueryから取得して更新しているのですが、Google CloudのDataflowには公式でElastic CloudとBigQueryを連携する機能が存在するため、その機能を使って更新する仕組みを実装しました。
モニタリング用Deploymentの分離
Elastic Cloudを利用していると、クライアントからの検索・更新のリクエストに関するログだけでなく、様々な内部Indexのログが流れてきます。これらのログを通常全文検索用途で利用しているDeployment上で一緒に処理してしまうと無駄なストレージ処理が発生し、性能面への影響が少なからず発生します。そのため、ログやメトリクスについては専用のDeploymentに分離・集約しています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- AWSのEKS上で構築していたSolrの運用コストが高く、本来やるべき検索改善に着手できていなかった
- 上記運用コストの高さからSolrのバージョンアップなども実施できておらず、十分に検索エンジンの機能を使えていなかった
どのような状態を目指していたか
- 運用コストを削減することで、検索改善に注力できるようになっている
- 検索エンジンの機能を使って、これまで実施できなかった検索改善施策を実施できるようになっている
比較検討したサービス
既に別サービスでElastic Cloudを利用していたため、細かい比較などは実施していませんが、候補としては以下の3つは想定していました。
- Amzon OpenSearch Service
- AWSのマネージドなElasticsearchベースの検索エンジン
- Vespa
- 検索エンジンとして機械学習などの機能が充実している
- (Elasticsearch/Solr) on EC2
- これまで検索エンジンを運用してきた知見を活かしつつ、Kubernetesからの脱却のみを目指す
比較した軸
- 運用コストの低減に繋がること
- 既存の検索ユースケースに対して同様の機能を提供できること
- 検索エンジンの機能としてベクトル検索や機械学習などが備わっており、検索改善が実現できること
選定理由
- マネージドなサービス
- 運用コストの低減を考える上で、自分たちでクラスタを細かく管理する必要がないというのは重要な指標
- 豊富なドキュメント
- 他の検索エンジンに比べてドキュメントやブログなどが豊富なため、情報が集めやすく、運用コストの低減に繋がる
- 検索エンジンの機能としてベクトル検索や機械学習の機能が充実している
- 検索改善チームによる改善施策が打ちやすい
- Luceneライブラリによる検索ユースケースへの対応
- Solrと同一のライブラリで作られているため、移行ハードルが低い
導入の成果
改善したかった課題はどれくらい解決されたか
運用面で最も課題だったSolrのEKS運用から解放されたため、まだAPIはEKS上に残っていますが、EKSのバージョンアップ作業についてはかなり運用コストが下がりました。しかし、Elastic Cloudにしたことで新しくreindexの運用負荷が高まったため、総合的に見て大きな改善とはいかないのが現状です。これについては既存の更新システムそのものを新しくすることで改善したいと考えています。
また、検索改善施策については既にいくつか検討がされており、これまでよりもかなり活発に議論ができています。下にも記載したように既に効果の出ている施策もあるため、こちらは解決したと言えます。
どのような成果が得られたか
検索改善施策で過去一の売上リフト
Elasticsearchの機能としてrerankとterms_lookupの機能を用いて、一部のサービスを対象に購入済商品を検索結果の後ろに並べ替え、ユーザごとにより良い検索結果が上位に並ぶような施策を実施しました。
この結果、これまで実施してきた検索改善施策の中でも一番の売上リフトとなりました。
Amazon EKSのアップデート作業にかかる時間が1/3以下に短縮
これまで複数のSolrをEKS上でPod管理していました。SolrをEKSで運用するにあたり、ウォームアップによってメモリ上にIndexデータを乗せることで検索を高速化しているため、再起動に時間を要していました。具体的には1Podあたり10~12分程度の起動時間だったため、EKSのクラスタを1台アップデートするだけで、最大で6時間程度の作業時間がかかっていました。
EKS上からSolrを削除することができたため、残ったAPIだけならばアップデートにはあまり時間がかからないため、最大でも1環境あたり2時間程度まで短縮することができました。
導入時の苦労・悩み
Elastic CloudとSolrで検索結果を一致させること
移行前に本番のログを使ってSolrとElastic Cloudで検索結果に差がないことを保証するための機能試験を実施しました。 多くのクエリで検索結果が一致したのですが、一部の特殊なクエリで考慮漏れや細かな機能の差による差分が発生しました。 これらの課題に対して以下のように解決していきました。
- SolrのAnalyzeやElastic CloudのProfile機能を用いてクエリがどのように検索されるのかを細かく分析
- 分析した結果からAPIの修正やElastic Cloudの設定変更などをしつつ何度も機能試験
- ときにはElasticsearch自体のコードも確認しながら挙動を確認
特定のスロークエリで検索レイテンシの悪化
実際に移行してしばらく運用していると、移行前の性能試験では見えなかった性能面での課題が見えてきました。性能試験時には全体のSLOだけに注目して監視をしており、平均的に見たら性能が良くなっていると結論付けましたが、一部のクエリのみレイテンシが悪化していることが分かりました。 この課題に対して、以下のような対応をしました。
- 検索対象Indexを分離する
- DMMでは横断検索という複数サービスをまとめて検索する機能があるのですが、この機能のために全てのサービスのIndexを集約するような構成を取っていました
- このような構成のため、他のサービスの性能に引きずられて本来よりもレイテンシが悪化してしまう状態にあったため、特定のサービスのみを指定するようなクエリでは専用のIndexに検索するように修正しました
- プライマリシャード数のチューニング
- 元々性能試験のタイミングで横断検索Indexでプライマリシャード数を1と2の2パターンで性能検証をしていました
- このときは性能差はほとんどないと判断しましたが、再度より多くのプライマリシャード数で性能検証を実施したところ性能改善が見られました
- 1文字検索の要件見直し
- 1文字での検索は検索ヒット数が多く、データの取得に時間がかかっていました
- 元々1文字の場合には後ろにワイルドカードをつけることで、その文字を検索対象フィールドに含む全てのデータを検索していましたが、あまり意味のない検索結果になっていたこともあり、1文字の場合には形態素解析の結果のみを返すようにしました
導入に向けた社内への説明
上長・チームへの説明
今回の移行にあたっては、上長も検索システムの運用に大きな課題があることを理解してくださっていたため、細かな説明まではしませんでした。マネージドなサービスを使うことによる運用コストの低減に期待が持てることと、今後の検索改善に大きな期待が持てることから、既存のシステムを運用し続けるよりも、移行に工数をかけてでも切り替える方が期待値が高いだろうと判断し、合意を得ました。
活用方法
DMMのECサイト上での検索にはほとんど全て検索基盤チームで管理しているElastic Cloudが利用されています。主に検索窓からのキーワード検索と検索結果のリストから様々なパラメータに合わせて絞り込む用途で利用されています。また、一部のサービスではユーザごとに検索結果の並び順を最適化するためのスコアリングにも利用しています。
よく使う機能
Elastic Cloudレベル
- マネジメントコンソールからのサポートケース起票
- Deployment内でKibanaのDev Toolsを用いたクエリやデータ、Index設定などの確認
- Traffic Filterによるアクセス制限
- モニタリング用Deploymentで各Deploymentの負荷確認
Elasticsearchレベル
- 全文検索機能
- Aggregationを利用した検索結果のファセット
- SortやFilterなどの一般的な検索機能
- TermsLookupによる別Indexへの検索結果のスコアリング
- Index TemplateによるIndex設定管理
クエリレベル
- multi_matchクエリ
- 全文検索は主にmulti_matchで実装
- boolクエリ
- AND検索やOR検索、NOT検索などで利用
- function scoreクエリ
- 検索結果のスコアリングで利用
ツールの良い点
- 豊富な検索機能で検索改善も検索エンジン内の機能を用いて実施できる
- 既に記載している通り、Elasticsearchとしての機能を使うことで成果にもつながっています
- マネージドなサービスならではのサポートとの情報共有・課題改善
- まだ使い始めたばかりということもあり、技術的な相談などをさせていただいています
- マネジメントコンソールの機能が充実しており、確認・分析が手軽に行える
- KibanaのDev Toolsなどで手軽にクエリやデータの確認ができています
- ただし、こちらは使い方を間違えると本番のデータに影響を及ぼす可能性もあるため、権限管理などに注意する必要があります
ツールの課題点
- ログをDatadogなどの監視ツールに連携できない
- 監視基盤をDatadogに集約しているが、Elastic CloudのDeploymentレベルのログなどはKibana上でしか見ることができない
- 負荷対策
- 検索と更新のDeploymentを分離できない
- 検索と更新はビジネス観点でもライフサイクルが異なるため、影響を分離したいが、現状分離はできない
- 負荷に応じたオートスケールができない
- Elastic Cloudでは負荷ベースのオートスケール機能がないため、マネージドサービスとは言え、クラスタのスペックなどにはかなり意識を向ける必要があります
- また、1ノードあたりのスペックに最大値があり、それを超えるスペックを指定するとスケールアウトしてノード数が増える仕組みです。そのため、大きいノードを少数管理したいというケースや、小さいノードを横にスケールしたいというケースでの利用はできません
- 検索と更新のDeploymentを分離できない
ツールを検討されている方へ
Elasticsearch自体はかなりドキュメントも多く、困ったときの解決方法が他の検索エンジンよりも情報として集まりやすいため、その点は大きなメリットだと思います。 マネージドのサービスだからこそ、初期段階でクラスタを構築してテストするという点ではかなり素早く実装ができて便利ですが、運用する上では全てを任せるというわけにはいかず、技術的な難しさもあるため、そこまで気にして色々なツールを比較検討してみてください。
今後の展望
Deployment分離
引き続き、サービスごとのDeployment分離を進めてパフォーマンス改善をしていきたいと考えています。また、これによってパフォーマンスの改善だけでなく、サービスごとに最適化したスキーマ構成なども考えていきたいと考えています。現在はサービス横断の検索に合わせて各サービスのIndexも共通化したスキーマ構成を取っていますが、よりサービスの特性に合わせたスキーマにすることでより使いやすいものにしていく予定です。
検索改善
これまで実施してきた検索のランキング改善だけでなく、マッチング改善などにも手を付けていきたいと考えています。
合同会社DMM.com / 小山凌太
メンバー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名
合同会社DMM.com / 小山凌太
メンバー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法