はじめに

ソーシャル経済メディア「NewsPicks」SREチーム・エンジニアの樋渡です。このブログは、NewsPicksの NewsPicks Advent Calendar 2025の15日目の記事となります。

今回はAWSリソースの「AWS OpenSearch Service」(以降、OpenSearch)・「Elastic Container Service」(以降、ECS)の機能を活用し、弊社の検索基盤を大幅にアップデートを実施し、AI時代における高い当たり前品質を実現できる検索基盤へ更新しているお話です。

「ベクトル検索」ができなかったレガシーな検索基盤を、多くの機能・高い当たり前品質を実現できる最新バージョンへと更新しようとしています。メジャーバージョンを3つも飛び越えるバージョン更新をどう実現しようとしているのか。
検索について何も知らなかったエンジニア歴2年目の新米エンジニアが、これまで誰も更新に手をつけてこなかったレガシーな基盤を半年という期間でどのように更新しているのか。

このブログでは、上記の２点について主に基盤整備の観点から話していきます。検索Queryそのものの改善については話さないのでお気をつけください。ネタバレをすると、新・検索基盤の整備は完了しており、現在は検索結果の妥当性について検証・改善を行っている段階で、まだユーザーには開放されていません。

最後まで読んでいただけると嬉しいです！

更新前の検索基盤

更新前の検索基盤は図１のような状態でした。OpenSearch + ECS(search-api) + DB(RDS・DynamoDB・ElastiCache) + ECS(digdag)で構成され、ECS(search-api)が検索queryなどをOpenSearchへ投げて結果を返すサーバーの役割、OpenSearchが検索データの保存や計算を行う検索エンジンの役割、OpenSearch以外のDBとECS(digdag)は、OpenSearchへ作成する検索Documentの元データ取得先とIndex作成・更新処理を行うワークフロー実行環境の役割を担っています。

それぞれのリソースで利用しているパッケージのバージョンは以下の通りです。DB関連とdigdagについては、省略しています。

OpenSearch
- Elasticsearch 6.8
search-api
- Java 11

めちゃくちゃレガシーでした。全体的にパッケージや検索エンジンのバージョンが古く、検索という機能の優先度・検索機能の開発を触れるエンジニアがごく一部というような事情もあり、これまでメンテナンスもされてきませんでした。このままでは、開発体験・ユーザー体験ともに良くないことは明白です。このような状況に加えて、昨今のAI活用の流れがElasticsearch 6.8が抱えている問題を解決したいという思いを強くしました。(Elasticsearch 6.8が抱えている問題については、次の章で解説します)

様々な事情でElasticsearch 6.8が抱える課題を解決したいという要望が出たことから、「どうせやるなら一気にOpenSearchの最新バージョンまで上げて、現代の当たり前品質を兼ね備えた検索基盤にしてやるぜ！」をどのようにして実現していっているのかというお話となります。

なぜやるのか・抱えていた課題

今回の刷新を行った目的についてです。今年、弊社UZABASEでは「Big AI Shift」というスローガンを掲げています。これは「Speeda AI Agent」を代表として、AI活用していくぞという意思を込めたものです。

note.com

前提として「Big AI Shift」は社外向けのプロダクトに限った話ではなく、社内向けの業務改善や効率化にも力を入れており、社内でAI開発コンペを行うなど積極的な活動が行われています。例としてLLMを使ったRAGシステムなどが開発されていますが、そのためにはベクトル計算やベクトル検索を行う仕組みが必要です。 NewsPicksでは開発の際、AWS Bedrockを活用しています。 AWS Bedrockを利用する理由は、「共通化されたベクトル検索基盤が整備されていない」・「マネージドサービスで新規開発において扱いやすい」の2点でしょうか。

ここでSREとして気になるのは、「開発が活発化したことによるコストの増加」・「共通化されたベクトル検索基盤が整備されていないことによるリソースの乱立」の2点です。実際、積極的なAI活用が始まった初期段階では一時的なコスト増加は発生してしまいましたし、一つの成功例ができるまではリソースや仕組みの乱立・車輪の再開発が起こっていました。 AI活用をしていく流れは、社外向け・社内向けどちらにおいても今年だけの流行りではなく、来年・再来年と継続的に行われていくものであることが予想されます。これから続いていくであろうAI時代に向けて、開発組織として開発しやすいベクトル検索共通基盤の提供が必要でした。

そこでOpenSearchをベクトル検索共通基盤に使えないか？という話があがります。確かに、ElasticSearch7系からはベクトル検索もサポートされていますし、ElasticSearch 7系からフォークされたOSSであるOpenSearchでは、現在でも活発な開発がされています。そもそも検索基盤としてAWS OpenSearch Serviceのリソースは存在しているので、そこに相乗りする形であればコスト効率も良いでしょうし、何より新しくベクトル検索基盤を開発して運用していく手間が省けます。とても良さそうです。

「よし！早速今ある検索基盤でベクトル検索して検証や！」

お気づきでしょうか？ベクトル検索がサポートされるのはElasticSearch7系からです。弊社の基盤は、ElasticSearch 6.8 。このままではベクトル検索ができないのですから、ベクトル検索基盤として利用できません、当たり前ですね。共通基盤として利用をするためには、最低でもElasticSearch 7系へと更新する必要があります。しかし、ElasticSearch 6.8 -> ElasticSearch 7系へ更新する際に数々の破壊的な変更が存在しており、実質search-apiや検索Indexは作り直しになります。この課題解決にかかるコストが大きかったため、これまで誰もバージョン更新に手がついていませんでした。解決できればベクトル検索共通基盤として活用できるだけでなくユーザーに提供する検索機能改善も行われて一石二鳥のため、この長年の課題をなんとか解決したいです。

このように様々な要因が重なり、今回重い腰をあげて、効率的(?)かつパワフルな方法でこの課題を解決していきます。長くなってしまいました。まとめます。

抱えていた課題
- 共通化されたベクトル検索基盤が整備されていないことによるリソースの乱立
- 開発が活発化したことによるコストの増加
- 車輪の再開発の発生
- ElasticSearch 6.8なので検索基盤でベクトル検索ができず、共通基盤として使えない
目的
- 来年・再来年のAI活用を見据えて、ベクトル検索共通基盤を用意・提供してあげたい

どうやって解決するか

それでは目的と解決したい課題が明確になったところで、どうやって解決するかについてです。

やりたいことはElasticSearch 6.8をできるだけ新しいものに更新したいです。更新先バージョンは、現時点でAWS OpenSearch Serviceでサポートされているバージョンで最も新しいバージョンであるOpenSearch 3.3にするとします。

では、ここで皆さん考えてみましょう。 ElasticSearch 6.8 -> OpenSearch 3.3へ更新するといった場合、どのような作業が必要になるでしょうか？ AWS公式が提供してくれるアップデートパスのDocumentに従い、正攻法で行くなら次の手順を辿ることになります。

docs.aws.amazon.com

(1)ElasticSearch 6.8 -> ElasticSearch 7系 or OpenSearch 1系へ更新する
- 多数のBreaking Changeが存在し自身の環境に応じて、それぞれに対応する必要があり。
(2)ElasticSearch 7系 or OpenSearch 1系 -> OpenSearch 1.3へ更新する
(3)OpenSearch 1.3 -> OpenSearch 2系
- OpenSearch 2.0からIndexのtypeパラメーターが完全に削除されるなど、Breaking Changeがある。
(4)OpenSearch 2.19 -> OpenSearch 3.1 or OpenSearch 3.3
- 一部IndexのパラメーターでBreaking Changeがある。

半端じゃないですね(笑)。途方もない道を辿ることになり、その間にぶつかる課題を一つ一つクリアしていく必要があります。この作業はかなり大変かつストレスですし、作業が終わり最新化した時には結局全てを作り直していたという結果になりそうです。僕自身、対応当初は正攻法で行くという覚悟がありましたが、半年で終わる未来は全く見えませんでした。では、どうやって対応したかです。発想の転換です、どうせ作り直すのなら既存のElasticSearch 6.8をOpenSearch 3.3へ更新するのではなく、OpenSearch 3.3のDomainを新しく作り、ElasticSearch 6.8と同じ結果を返すようにsearch-api(検索query)、Indexデータを作り直した方が早いぞ！！と気づきました。

以上の経緯から、作り直すことになりました。作り直すといっても簡単ではありません、考慮するべきポイントは沢山あります。この半年間、泥水を啜るように様々なDocument・コードと戦いを繰り広げました。が、その全てを紹介はできないため、今回の移行にあたって特に気をつけた以下の2点に絞ってご紹介します。

ElasticSearch 6.8(以降、V1) -> OpenSearch 3.3(以降、V2)への安全なリクエスト移行方法
V1とV2の並行稼働期間にデータ損失が起きないような仕組み整備

V1 -> V2への安全なリクエスト移行方法

それでは、V1 -> V2への安全な移行方法についてです。対応方針としては、前章で説明した通りOpenSearch Domainを新しく立て、同じ結果を返すsearch-api-v2を作成し、V2の基盤へユーザーのリクエスト先を変更するです。では、V2の環境が整備されて本番で移行するぞとなったとき、どのようにユーザーからのリクエストを移行していけば良いでしょうか？

簡単にやるなら、一気にスイッチを切り替えるようにリクエスト先をV1 -> V2に切り替えていく方法もあるでしょう。実現方法も沢山ありますが、安全とは言えないです。手元では完璧に動作確認したはずが、本番にリリースし大量のリクエストを受け取るようになるとエラーが顕在化した事象は往々にしてあります。そうなった場合、エラーに気づくまで壊れた検索基盤へリクエストが飛び続けることになり影響も大きなものになってしまいます。これは避けたいです。ではどうするのか。今回はECSのWeightedTargetGroupの機能を使って解決しました。これは、去年検索基盤をEC2 -> ECSへ移行したときにも利用した手法で、詳細な説明は、下記のブログに記載されていますのでここでは割愛します。この機能を使って、段階的な移行を行っていきます。

tech.uzabase.com

今回の移行では、10%・30%・50%・80%・100%と５段階に分けて慎重に行っていきます。その移行期間でNewRelicを使ったsearch-apiのメトリクス監視やOpenSearch Domainのリソース利用傾向などを注視します。何か問題があればWeightedTargetGroupでV1へ100%流すように変更すれば、復旧するのでエラー時の被害も最小限にできるのも利点です。

V1とV2の並行稼働期間にデータ損失が起きないような仕組み整備

V1とV2の並行稼働期間にデータ損失が起きないような仕組み整備についてです。今回の移行で最も大事にしたいことは、V1とV2で同じ結果が返ってくるように移行することです。もちろん最終的なゴールは検索機能の改善やベクトル共通基盤の整備ですが、今回の対応は初期段階・ゴールまでの前準備で、この段階で検索エンジンのバージョンをあげたことを起因としてユーザーに返す検索結果の妥当性を崩したくありません。ユーザーがV1とV2のどちらへリクエストすることになっても、ユーザー目線で検索結果は同じになることを担保するような基盤を作りユーザー体験を損なわない移行作業が求められます。

検索基盤において、同じ結果を返すようにするために最も重要な要素は検索Indexのデータです。同じ結果を返す検索Queryが2つあったとしても参照するデータが異なっていれば、結果は変わってしまいます。弊社の検索基盤のデータ更新の仕組みは以下のような構成です。

この構成を見るとIndexを更新・作成する仕組みとしては、大きく分けて↓↓に示す2つがあります。

(1) digdagによる、Index作成・更新系のワークフロー
(2) SQSからWorkerが処理して行う、Index作成・更新系のワークフロー

(1)・(2)のどちらについても、V1とV2の対応が必要でした。 (1)については、同じようにV2に向けてIndex作成・更新処理を行うワークフローを作成するだけです。ユーザーが行なった行動によって、Indexを更新するのか・作成するのか・削除するのかを記したデータがsearch-apiを通してSQSへ入っていき、SQSに入ったデータをWorkerが順次処理していきます。ここで問題となったのは、search-api自身がSQSへデータを詰めるAPIを持っていることでした。前章で示した通り、移行時にリクエストはV1とV2のいずれかに飛ぶようになっていて、V1とV2のどちらかにしか同じリクエストは飛びません。このままでは、一方のSQSにはデータが入り更新されるがもう一方のSQSにはデータが入らないといったような状態が発生、V1とV2でデータの整合性が崩れ、ユーザーに表示される検索結果が異なってしまうという事態に陥ります。

では、どうやって解決したのかについてです。これは考えてみると簡単でした、データを詰めるsearch-apiの処理をV1・V2どちらのSQSにも詰めるように変更してあげましょう。移行時のデータの流れとしては、図２のような流れになります。この変更をしてあげれば、送られてくるリクエストがV1とV2のどちらで処理されても必ずV1とV2のSQSにデータが詰められるようになります。これで2つのDomainが並行稼働している移行期間中のデータ不整合の発生が防げるようになります。

AIを活用して基盤移行を進めた話

前編で話したかった安全な基盤移行のための取り組みについては以上です。他にもembulkで行なっていたOpenSearchへのIndex登録やめた話やサーバー側のパッケージ更新・Java21への更新がすごく辛かった話など話したいことはあるのですが、それは後編 or 中編で喋れればなと思います。最後に、今回一人で基盤刷新を行なっていくにあたってAIを思いっきり活用したので、その話をして終わりたいなと思います。

「基盤を新しくする」や「メジャーバージョンを更新する」といったタスクをこなす際、最も大事かつ大変な作業は何でしょうか。それは現状を把握し、更新したいパッケージのDocumentやコードをひたすら読み、差分を理解することです。自分が今更新したいインフラの構造は現在どういう状態なのか、あのバージョンに更新するにはどういう変更や課題があってどう乗り越えられるのか。この答えはOSSの場合、公式のDocumentやGitHubにほとんど答えがあります。ただし、これらを自分の力だけで全部網羅的に把握し理解するにはかなりの技術力や経験・圧倒的な根性が必要です。今回の更新タスクにあたって自分自身もこの壁にぶち当たりました。エラーの解決一つをとっても、多くの経験を持つシニアと経験が浅いジュニアの解決にかかる時間は多くの場合大きく違います。更新対象の基盤に詳しくないなら尚更です。ちょっとしたエラーに引っかかり調査・解決に多くの時間を費やし、時間が溶けていき後続のタスクが遅れていく。ストレスです。

この問題をAIを活用して解決しました。そうです、「AI時代のビックウェーブに乗れ」のタイトルはこの章のことです(笑)。では、どのように活用すれば良いでしょうか。新卒１ヶ月目の僕であれば、「AI君に聞いたらなんか出てきたので使いました！」というでしょう。ナンセンスです、へっぽこエンジニアです。ただAIに聞いて言われた通りにPRを出すだけのエンジニアに未来はありません、身に染みてます。

今回僕は、AIを「壁打ちをしてくれる先輩エンジニア」として利用しました。分かんないことがあったらまず聞く、回答に対して必ず疑問を持ち情報源の提供を求める、情報源まで実際に目を通し理解を深める。この流れを自分が説明責任が果たせると思うまでひたすらと繰り返します。このように疑問点とエラーを一つ一つ解決していきました。自分でDocument調べるのと変わらないじゃないかって？全然違います。全く知識0の状態でGitHubや公式Documentに存在する大量の情報から、自分が欲しいと思っている情報を見つけるのはめちゃくちゃ大変です。結局目次を読み、それっぽいところを全部読んで本当に欲しい情報は一番最後の方だったと言う経験一度はあるんじゃないでしょうか。 AIを使えばこれをある程度は回避できました。結果として、自分の中で理解が浅いなと思っている部分は一つずつ潰していき自信を持って基盤刷新を行えました。

これが必ずしも正解だとは思いませんが、知識探究の一手段としての活用がすごく大きく、AI時代じゃなかったら半年で一人での対応はできなかったなと思います。

まとめ

今回のまとめです。今回のブログでは、半年間かけて行ったElasticSearch 6.8 -> OpenSearch 3.3へ大幅な基盤更新を安全に行う方法についてご紹介しました。今回紹介した話の他にも、まだまだ書きたいことはあるのですが今回はここまでにします!!大幅な基盤更新を行いたいと思っている読者に届けば嬉しく思いますし、2年目のエンジニアでも半年あれば基盤作り直せるぞというメッセージを同世代に届けられれば幸いです。

現在進行形で、検索基盤の移行は進行中です。ユーザーの皆様にいち早く届けられるよう引き続き対応していきたいと思います。これからも事業の継続的な価値提供のために、開発者体験や普段の運用負担軽減等の改善に励んでいきたいと思います。ここまで読んでいただきありがとうございました！！