トップ > 検索 > DMMの検索基盤をSolrからElasticsearchにリプレイスしました

DMMの検索基盤をSolrからElasticsearchにリプレイスしました

検索 運用/監視

サムネイル

はじめに

データ基盤開発部・検索基盤チームで検索システムの開発・運用をしている小山です。

我々はこれまで検索基盤システムの根幹となる検索エンジンにSolrを運用してきましたが、2025年5月にElastic Cloudへの移行を完了しました。
この記事では移行に至った背景や移行後の現状について紹介をさせていただきます。 なお、移行プロセスについては概要の記載はしますが、詳細は別記事にて掘り下げて紹介をさせていただきます。

Solr運用における課題

移行背景を説明するために、まずもともとの検索システム構成と抱えていた課題について説明させていただきます。

Solrを用いた検索システム構成

Solrを用いた検索システムは以下の図のような構成で管理されていました。

Solrを用いた検索システム

2つのEKSクラスタを利用し、更新用(indexer)クラスタと検索用(searcher)クラスタで役割を分けることで影響範囲を限定できる構成になっています。
もともとはSolrCloud構成で運用していましたが、KubernetesとしてのライフサイクルにSolrCloudとしてのライフサイクルを合わせるのが難しく、障害発生頻度が上がっていたため、過去にSolrCloudから今回の構成に変更した経緯があります。

  • indexerクラスタ: 更新リクエストのみを受けるLeader Solrの他、更新用のAPIやETLジョブなどの更新系統システムを配置するクラスタ
  • searcherクラスタ: 検索リクエストのみを受けるFollower Solrの他、検索用のAPIや検索キャッシュ用のRedisなど検索系統システムを配置するクラスタ

Follower Solrへのデータ更新は、indexer - searcher間にプライベートALBを設置し、ALB経由でFollower SolrからLeader Solrにレプリケーションリクエストを送信することで実施していました。
Solrのレプリケーション機能は基本的にFollowerがLeaderのデータを取得するPull型であり、LeaderとFollowerをネットワークレベルで分離している本システムにおいて、シンプルかつ堅牢なデータ同期方法として採用しました。
レプリケーションは10分おきに動くため、実際にLeaderのSolrにデータ更新されてから最大で10分後に検索に表示されることになります。

また、Solrが永続ボリュームによるデータ管理を必要とするため、KubernetesのStatefulSetリソースを利用していました。
永続ボリュームとしてEBSをアタッチする必要があるのですが、AZ障害により特定のAZでPodの起動ができなくなった場合に、EBSがアタッチされているために他AZでの再起動が困難になる問題が考えられます。 そこでノードグループを各AZごとに用意し、balance-similar-node-groupsの設定で各ノードグループ均等にPodが配置されるように設計していました。

Solr構成における課題

上記構成を運用してみるといくつかの課題が見つかりました。

EKSクラスタの定期的なアップデート

もっとも大きな課題は、EKSクラスタの定期的なアップデート作業です。
Kubernetesのバージョンは3ヶ月ごとに更新されるため、それに追従する必要があります。厳密に3ヶ月ごとの追従ができたわけではありませんが、利用可能なバージョンの期限が決まっているため、その期限内には更新作業を完了させる必要がありました。
上記構成の通り、各環境で2種類のクラスタを運用しているため、それら全てのクラスタで更新作業が発生していました。

また、EKSは公式でアドオンが多く用意されているわけではないため、cluster-autoscalerやdescheduler、tektonなど必要に応じて様々なサードパーティ製ツールも導入しています。 Kubernetesバージョンアップに合わせてこれらのツールのバージョン追従もしていく必要がありました。

これに加えて後述するSolrという検索エンジンの仕組み上の問題が重なり、一度のバージョンアップ作業で1クラスタあたり6時間程度かかることもありました。

前述したようにノードグループをAZごとに用意しており、更新作業は影響範囲を限定するために1AZずつローリングアップデートで実施していました。
各ノードグループのアップデート完了を待って次のノードグループのアップデートを実施するなど、完全に自動化された作業ではないため、更新作業中は常にサービス影響を監視しつつ、手作業によるコンテキストスイッチが発生するなど、非常に神経を使う作業になっていました。

Solrのウォームアップによる起動時間の長さ

Solrは検索性能を最大化するためにウォームアップを必要とします。具体的にはSolr起動時に全データをメモリに読み込むスクリプトを実行していたため、1台あたりの起動時間が長期化し、リリースやバージョンアップ作業に多大な時間を要していました。
DMMではサービス横断の検索を提供している関係で、巨大なコアには約1000万件のドキュメントが登録されており、この規模のデータをウォームアップするには1台あたり10分を超える時間がかかっていました。

これによるもっとも大きな問題は突発的な負荷に対してオートスケールさせることができないことです。
急激なリクエスト増に対して1台あたりの起動に10分もかかっていてはリクエスト処理が間に合わないため、結果的に負荷に対するオートスケールは諦めて、ある程度余裕を持ったPod数にすることで対応していました。
スペックもEC2インスタンスで言うとm5.8xlargeとかなりの大きさのため、費用も増大していました。

検索改善施策への対応

以上のようなクラスタ運用の手間やSolr起動の問題に多くの労力が割かれていたため、Solr自体のバージョンアップやそれに伴う最新機能の活用は全くできていない状況でした。
社内の検索改善チームがランキング改善などの施策を進めてくれていたものの、最新の検索エンジンの機能を利用できないことが足かせになっており、検索基盤チームとしても検索に対する施策がほとんどできていない状況となっていました。

Elastic Cloudに決定した理由

上記課題の通り、クラスタ運用に労力を割かれており、検索に関わる施策には手が回っていない状態であったため、運用コストの削減を最優先事項としました。
マネージドな検索エンジンを採用することで、検索エンジン自体の運用コストを最小限に抑え、検索機能の改善に注力できる状態を目指しました。

その中で候補として挙がったのがElastic Cloudです。
Solr構成として採用していた、検索システムと更新システムの分離などは例がなく、検索と更新の処理が競合しないかなど性能面での懸念もありましたが、以下の点に期待して移行先をElastic Cloudに決定しました。

  • Google Cloudへの集約: 前提として社内の連携システムのGoogle Cloud移行が進む中で検索システムもGoogle Cloudに寄せていきたいというモチベーションがあった
  • Elastic Cloud Serverlessへの期待: 将来的に負荷ベースでのオートスケールや検索と更新の分離など運用負荷の低減見込みがあること
  • BigQueryとの連携: 更新システム利用事業部においてデータ管理をBigQueryに移行する動きがあり、Dataflowを用いてBigQueryと連携できるElastic Cloudを利用することで、独自の更新システムからも脱却できる可能性があったこと
  • 最新のElasticsearchバージョンの利用: 検索エンジン内の機械学習機能などを活用し、検索施策のサイクルを加速できること
    • Elastic CloudではEKSにおけるKubernetesバージョン同様に、利用できるElasticsearchのバージョンに期限があるため、必然的に最新のElasticsearchバージョンに追従していくことになる

移行方法

ここからはElastic Cloudへの移行をどのようなプロセスで実施したかを記載します。
はじめに記載したとおり、詳細な移行プロセスについては別で記事を投稿予定なので、こちらでは概要の説明をさせていただきます。

初期段階で重視したのは以下の2点です。

  • 既存機能の提供: Solrで使っている機能に相当する機能がElasticsearchにも存在し、既存の検索・更新機能が継続して提供できること
  • Solr同等の性能: Solrと同等、もしくはそれ以上の性能が発揮できること

既存機能の提供

まず機能面では、利用しているユースケースを洗い出し、それぞれのユースケースで利用できるElasticsearchの機能を調査しました。
ここではどの機能を使えば何が実現できるかを詳細までは深堀りせず、以下の表のようにユースケースから要件に落とし込み、それを満たす機能があるかという観点で調査を進めました。

ユースケース 要件 Elasticsearchの機能(クエリ)
複数のキーワードを含む商品を検索したい AND検索やOR検索ができる 下記AND検索の例を参照
商品タイトルの略称でもヒットさせたい 類義語辞書を更新・検索時の形態素解析に利用できる 下記Index Settingsの例を参照
検索結果からフィールドごとの件数を表示したい ファセットが利用できる 下記ファセットの例を参照
クエリに対してより関連する商品を上位に表示したい 複数のフィールドに重みを設定することでクエリへの関連度を調整できる 下記重み付けの例(titleにcommentの3倍のスコアリング)を参照
複数サービスで同時に検索したい インデックスを跨いで検索することができ、複数のインデックスの検索結果をマージしてソートすることができる 下記複数Indexの横断検索例を参照

各ユースケースの具体的なElasticsearchの例

AND検索の例

curl -X GET "${ES_URL}/${INDEX}/_search" \
  -H "Authorization: ApiKey "${API_KEY}"" \
  -H "Content-Type: application/json" \
  -d '
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "service": "search"
          }
        },
        {
          "term": {
            "floor": "dmm"
          }
        }
      ]
    }
  }
}'

Index Settingsの例

{
    "analysis": {
        "filter": {
            "test_synonyms": {
                "type": "synonym_graph",
                "synonyms_path": "test/synonyms.txt",
                "expand": "true"
            }
        },
        "analyzer": {
            "text_ja_test": {
                "filter": [
                    "test_synonyms"
                ],
                "type": "custom",
                "tokenizer": "text_ja"
            }
        },
        "tokenizer": {
            "text_ja": {
                "mode": "normal",
                "user_dictionary": "test/userdict.txt",
                "type": "kuromoji_tokenizer",
                "discard_punctuation": "true"
            }
        }
    }
}

ファセットの例

curl -X GET "${ES_URL}/${INDEX}/_search" \
  -H "Authorization: ApiKey "${API_KEY}"" \
  -H "Content-Type: application/json" \
  -d '
{
  "query": {
    "exists": {
      "field": "maker"
    }
  },
  "aggs": {
    "makers": {
      "terms": {
        "field": "maker"
      }
    }
  }
}

重み付けの例(titleにcommentの3倍のスコアリング)

curl -X GET "${ES_URL}/${INDEX}/_search" \
  -H "Authorization: ApiKey "${API_KEY}"" \
  -H "Content-Type: application/json" \
  -d '
{
  "query": {
    "multi_match" : {
      "query": "dmm",
      "fields": [
        "title^3",
        "comment"
      ]
    }
  }
}'

複数Indexの横断検索例

curl -X POST "${ES_URL}/${INDEX},${ANOTHER_INDEX}/_search" \
  -H "Authorization: ApiKey "${API_KEY}"" \
  -H "Content-Type: application/json" \
  -d '
{
  "query": {
    "match_phrase": {
      "title_ja": "index test"
    }
  }
}'

ここでユースケースを満たす目処がついたタイミングで、実際に検索APIを改修してElasticsearch用のクエリ変換を実装しました。
実装時にどの機能を使うことがよりユースケースを満たせるかなどを調査し、最終的に実装した機能が正しく動作することを確認するために本番のクエリをミラーリングする(下図参照)ことでSolrとElasticsearchのレスポンスから検索結果を比較していきました。
ここで差があったものを一つずつ修正していき、Solr側で意図した機能を提供できていなかったと判明した場合にはElasticsearchの結果を正とし、その差分を許容する判断をしました。

ミラーリング方法

この機能開発部分を別記事にて紹介させていただきます。

Solr同等の性能

性能面については2段階に分けて調査しました。

1段階目はElastic Cloudにおけるクラスタ構成の決定のための性能試験です。
性能試験は、既存システムに設定されたRate Limit(検索のリクエスト制限RPS)程度の検索リクエストと、Kafkaキューを巻き戻して大量の更新リクエストを流すことで実施しました。
Elastic Cloudでのクラスタ構成パターンをいくつか洗い出し、それぞれのクラスタの運用コストを考慮し、運用コストの低そうなパターンから性能試験をしていき、求める性能が出るかを確認しました。
基本的に運用コストが低い構成で性能が出ればそれで良いので、決定した段階で他の構成についてはいったん検討しないこととし、クラスタ構成をFIXしました。
この時点では詳細なチューニングまでは行わず、クラスタのスペックやシャード数を増やすことで将来的な性能向上が見込めるか、という観点で判断しました。

実際に決定した構成が以下の図です。

Elasticsearchの構成

主に意識したのはMaster Nodeの分離と、モニタリングを別クラスタに切り出したことです。
ユースケースとしてIndexing周りで細かなElastic Cloud側での事前加工などはなかったため、Ingest Nodeなどは分離せず、Master Nodeのみを分離しました。 各hot nodeそれぞれがCoordinating Nodeとしての役割も担当しており、検索・更新しています。
性能確認時点でstorage最適化では負荷に耐えられなかったため、CPU最適化オプションにしています。
また、Elastic Cloudでは1ノードあたりの最大スペックがメモリベースで64GiBなので、これを超えるメモリを指定するとそれに合わせて1段階ごとに3台(AZ数次第)ずつノードが増えるため、現在は12台のノードが動いています。

その後、2段階目として全ての機能実装が完了した段階で、あらためて実装した機能での性能試験を実施しました。 ここでは実際に本番での運用を想定して、チームで定めるSLOを満たしているかに焦点を当てて試験しました。 SLOについては以下の2つを基準としています。

  • Latency: 検索リクエストに対するレスポンスタイムの95%ileが500ms以内であること
  • Availability: 検索リクエストに対する応答率が95%ileで99.95%以上であること

また、ここで行った性能試験の内容としては以下のような試験を実施しました。

項目 詳細
検索負荷100% + 全件更新 ピーク時間帯の検索リクエスト数で30分間の負荷がけ
同時にKafkaのキューを戻すことでまとまった更新を再現
検索負荷Max + 全件更新 既存のSolrへの検索制限リクエスト数で30分間の負荷がけ
同時にKafkaのキューを戻すことでまとまった更新を再現
主要サービスのIndexを分割しての検索負荷100% + 全件更新 上記試験をIndex分離して実施
主要サービスのIndexを分割しての検索負荷Max + 全件更新 上記試験をIndex分離して実施
各種オペレーション実施時の検索負荷100% + 全件更新 reindexやスペックアップ・ダウン、スナップショット実行などのオペレーション影響を上記試験条件で調査

移行してみて

実際に移行して運用を開始してから2ヶ月程度が経過しましたが、正直なところ現在は課題が山積みで、移行によって当初の課題が全て解決できたとは言い切れない状況です。
それでも、移行して良かったことなどもあるため、いくつか紹介させていただきます。

良かったこと

Solrからの脱却

良かったことの1つにはSolrからの脱却が挙げられます。
全てのリクエストを完全にElasticsearchに切り替えることができたため、EKSからSolrを撤去し、EKSのクラスタアップデートなどはかなり楽になりました。
もちろん最新バージョンの調査などはEKSを使っている以上は必要ですが、残っているリソースについては薄いAPIやETLジョブなどであり、バージョンアップにかかる時間は長く見積もっても1環境あたりトータルで2時間程度です。
ここからさらにAPIなどもKubernetesから脱却していくことでかなり運用コストは減るはずです。 具体的な移行先はまだ決まっていませんが、Google Cloudへの移行を考えるとCloud RunかGKE Autopilotあたりになると思います。
GKE Autopilotはクラスタ運用まではせずに既存のマニフェストファイルなどが利用できるため、今よりは運用が楽になると考えていますが、もう少し調査をしてみて決めたいと思っています。

検索システムへの理解度

また、純粋に1から検索エンジンについて学ぶ機会が得られたことも良かったこととして挙げられます。
これまであまり理解していないままにSolrを運用しており、検索機能の調査に時間をかけることができなかったため、Elasticsearchを1から調査することで既存の検索機能におけるバグを見つけることができました。 そして、検索という技術自体への知見が深まり、より検索のあるべき姿について考えることができるようになりました。

具体的には、以下のような知見が得られました。

  • SolrのDebug APIとElasticsearchのExplain APIを使って、Luceneに送るためのクエリ組み立てやスコア算出まで確認することで、検索エンジン内部でのドキュメントヒット工程やBM25によるスコアリング詳細を把握できた
    • Analyzer, Tokenizer, Token Filters, Char Filtersなどがどの順番で処理されるかや、辞書がどこで適用されるかなどを把握できた(ElasticsearchではChar Filtersでも辞書が効くなど)
  • SolrとElastic Cloudで差分があったときに、クエリからユーザの意図を汲み取ることでバグを認知して改修できた
  • Leader - Follower構成のSolrでは意識していなかったシャード構成についての知見が得られた

あくまでも一例ではありますが、上記のようにクエリ周りでは特にユーザの意図としてどのような結果になっているべきかという部分まで深堀って学ぶことができたのはとても良かったです。

Elastic社のサポート

あとはElastic Cloudならではのところで言うと、サポートとの素早いやり取りができることも挙げられます。
マネージドなサービスだからこそ、実際にElastic社の方と直接議論でき、何か問題があったときにはサポートケースによる調査も依頼できます。 検索エンジンレベルでこのようなサポートが受けられることは、開発時にも分からないことを気軽に聞くことができたり、運用開始した今もまだElasticsearchに対する理解が十分でないため、助けられることがあります。

移行後の課題

目下の課題は性能面です。
上で説明したとおり、全ての機能実装後に性能試験はしており、SLOとして定めていた95%ileの検索リクエストに対して500ms以内にレスポンスを返すというラインは満たしていることは確認しました。 むしろ、性能試験時点ではSolr利用時よりも性能が向上したという結果が得られていました。
しかし、実際に運用をしてみると95%ileの平均レスポンスタイムとしては確かに性能向上しているのですが、特定のスロークエリについてはSolrより悪化していることが分かりました。
それらのスロークエリがボトルネックとなり、一部のサービスではかえって性能悪化を引き起こし、検索キューを逼迫することで他のサービスに対しても瞬間的に「429 Too Many Requests」を返す状況が発生しています。

ここでスロークエリは「検索に1秒以上かかったクエリ」としています。 具体的には以下のような傾向のクエリにスロークエリの割合が高く、Solrと比べてレスポンスが悪化していることが分かりました。

  • 1文字のみで検索するクエリ
  • 特定サービスにおいて大量のファセットを利用するクエリ
  • 検索時に大量のスコアリング計算を必要とするクエリ

スロークエリへの対策として、この運用期間に以下の施策を実施しました。

  • 1文字検索の要件見直し
  • 特定サービスのリクエスト先Indexを変更
  • プライマリシャード数のチューニング

なお、スロークエリの発見が遅れたのは性能試験の監視観点として全体での性能ばかりを見ており、一部のサービスや一部のIndexに細分化した性能を見られていなかったことが原因であり、オブザーバビリティの観点についても現在チームで見直し中です。

1文字検索の要件見直し

もともとDMM TVなど一部のサービスではインクリメンタルサーチというリアルタイムにユーザの入力した文字列で検索する機能が実装されていました。 そのため、1文字入力したときにkuromojiによる形態素解析のみの結果を返すと、2文字入力したときのN-gramによる部分一致の結果より少ない検索結果を返してしまう問題があったため、1文字検索にはワイルドカードによる前方一致の仕組みを導入していました。

しかし、この前方一致のワイルドカード検索はデータヒット数が多く、今のDMMのドキュメント数だとElastic Cloudではレスポンス悪化を引き起こしていました。 また、純粋な形態素解析の結果に比べて意味のない結果を返すことも多いため、1文字検索については前方一致からkuromojiによる形態素解析の結果のみを返すように変更しました。

DMM TVに限らず、この影響で1文字の検索結果より2文字の検索結果でドキュメントヒット数が多い状態になってしまいます。 しかし、一般的にフロントで表示する範囲のドキュメント数としては問題ないと判断し、性能面での課題解決と、形態素解析による意味のあるドキュメントをランキングで上に表示できるメリットの方が高いと判断しました。

ブログを書いている現在すでにログが残っておらず、当時の1文字検索におけるレスポンスタイム500ms以上のリクエスト数のスクリーンショットになりますが、以下のような結果になりました。
上の画像が変更前で、下の画像が変更後になるのですが、1文字検索自体のレスポンスは改善されており、500ms以上のリクエスト数は減っているのが分かります。しかし、ぼかしていますが一部のUserAgentにおいてはむしろ増えているため、大きな改善には繋がりませんでした。実際全体のレスポンスタイムとしてはメトリクスを見ても分かるようにそこまで変わっていません。ここは継続してあるべき検索の形も模索しつつ改善していきたいと思います。

1文字検索要件変更前のSLOを満たさないリクエスト数 1文字検索要件変更後のSLOを満たさないリクエスト数 1文字検索要件変更によるp95レスポンスタイム

特定サービスのリクエスト先Indexを変更

事前に記載していますが、DMMではサービス横断の検索を提供しており、Solrではそれらのサービスを一つの大きなコアにまとめることで対応していました。
Elastic Cloudでは一部の影響の大きいサービスについてはIndexを分離し、複数Indexをまとめた大きなエイリアスを作ることで、横断検索の機能を提供するようにしました。
しかし、検索利用事業部の各クエリを細かく調査する時間までは取れず、クエリについては横断検索かどうかに関わらず、この大きなエイリアスに検索するように設計していました。
この結果、大量のファセットを利用するようなクエリで巨大なIndexへの不要な集計時間がかかり、レスポンスが悪化していることが分かりました。

これを受けて、各クエリを調査および事業部へ確認することで、特定サービスのみを検索するようなクエリについては大きなエイリアスに向けるのではなく、直接そのサービス専用のIndexに向けるように修正しました。

サービスによってはあまり効果が見られないサービスもありましたが、以下の結果のように動画サービスなどは95%ileのレスポンスタイムで大幅な改善が見られました。

p95レスポンスタイム(動画サービスリクエスト先Index変更)

プライマリシャード数のチューニング

移行検証時の性能試験でプライマリシャード数についてはチューニング観点として盛り込んでいました。 Elastic Cloudのベストプラクティスに基づいてプライマリシャード数を1から始めて、目安としてデータ数が20GBを超えるものはプライマリシャード数を2に変更して試験を実施しました。

この時点ではプライマリシャード数が1と2では大きな性能差は見られませんでした。 今後巨大なIndexについてはサービスごとにIndexを分離していきたいモチベーションもあったため、Index分離時にプライマリシャード数を下げるよりは性能差がないならばプライマリシャード数は1で決定しようという結論になりました。

しかし、実際に運用して性能面での課題が出たことで、あらためてプライマリシャード数を5まで増やして性能試験を実施したところ、かなりの性能改善につながったため、プライマリシャード数を増やすことにしました。
プライマリシャード数を増やし、性能面での向上が見られた一方これまで詰まっていた検索クエリが一気に流れ込むことでCPU負荷が爆発的に増える問題が発生しました。 これにより、捌き切れる検索スレッド数を超えたことで逆に検索スレッドのRejectが発生し、「429 Too Many Requests」を返す量が増えましたが、ここはクラスタのノード数を増やすことで対応しました。

プライマリシャード数を変更した結果は以下の通りです。
SLOに定めている95%ileのレスポンスタイムで20ms程度の改善が見られました。 どちらかと言うとこの変更で特に改善が見られたのはMaxのレスポンスタイムで、Maxでは1秒以上の改善に繋がりました。

p95レスポンスタイム(プライマリシャード数変更) Maxレスポンスタイム(プライマリシャード数変更)

運用面での課題

その他一部の運用における課題もあります。 具体的にはreindexがかなり運用コストの高い操作になっています。
運用コストという言葉を使ってしまうと曖昧な定義になってしまいますが、複雑な処理の流れや単純に作業時間の長さなどが問題となっています。
Elasticsearchで管理しているIndexについてはTerraformでIndex Templateを管理し、変更が発生したときには新規Indexを作ってreindexをする運用になっており、具体的には以下のような手順で実施しています。

  1. TerraformでIndex Templateを修正してリリースする
  2. 新規Indexを作成し、既存のIndexからreindexを実行する
  3. ETLジョブを新規Index用に新しく作り、reindex実行前の時間からキューを流し直す(reindex時の更新はreindexには反映されないため)
  4. キューの消化が既存のIndexへの更新に全て追いついたら検索のリクエストを新規Indexに向ける
  5. 問題が発生しないことを確認した後、古いIndexへの更新を停止する
  6. 古いIndexを削除する

新規ETLジョブの作成やキューの消化の監視などが挟まることで全ての作業を自動化することが難しく、ETLジョブの設計の都合上、1つのIndexに対して複数のパイプラインからの更新が走るため、ここの制御が複雑化していました。 また、Indexによっては常に膨大な更新が流れていることもあり、キューの消化にかなりの時間を要することもありました。
性能面での課題が顕著な現在、特にIndexの設定を変更する機会が多いため、reindexがかなり頻繁に発生しています。そのような作業に対して複雑な設計や長い待ち時間が必要というのは当初の運用コストの削減という要件に対してマイナスポイントとなります。 これについては更新システム自体の見直しも含めてどのように運用していくのが良いかを検討しているところです。

まとめと今後の展望

ここまでSolrからElastic Cloudへの移行について、移行の詳細なプロセスは省いて説明させていただきました。
これを受けて、正直なところ現状では課題が残っているため、ネガティブな印象を受けるかもしれません。
実際、性能面での課題が目立っており、元々予定していた検索改善に着手できていないため、我々としてもまだ移行したメリットを享受できていないと思っています。

しかし、Elastic Cloudに移行したからこそこれまで気付くことができなかった検索のバグを解消できたり、トータルの検索性能についても改善が見られています。
横断検索に対してもより柔軟な対応ができるようになったため、今後さらにIndexの分離を進めることで、各サービスごとに最適化したフィールド設計をして、それぞれのサービス特性に合わせた検索の提供もできるようになると思っています。

その他、ベクトル検索についても実装自体は進めており、検索改善チームでもElastic Cloudの機能を使った施策を複数検討しているところです。必要に応じてElastic Cloudの契約プランについても見直し、より便利な機能を取り入れることも検討しています。

これらの施策はこれまでのSolr運用では難しかった部分であり、今の性能課題が解決してしまえばエンドユーザ目線ではDMMの検索がより使いやすいものになると思っているため、将来性は高いと考えています。

その他、Elastic Cloud Serverlessについても具体的な導入事例などが見つからず、成熟しきっていないと判断し、導入は見送りましたが、今後の成熟度を見て導入していきたいと思っています。

まずは目下の課題である性能改善に注力し、当初の目的にあったElasticsearchの最新機能を利用した検索改善にも少しずつ着手していきたいと考えています。