大量の書類を複雑な条件で検索する基盤としてOpenSearch Serverlessを利用

ツール導入前の課題

バクラク請求書発行では、帳票の一覧検索を完全にSQLのSELECT queryのみで実装しており、以下の課題を抱えていました。

• お客様の書類ごとの独自の項目（カスタム項目）による検索ができない
• 検索パフォーマンスの著しい低下: 25個以上に渡る様々な検索項目と、テナントごとに異なる複雑な検索条件により、インデックスなどによるチューニングを行った上のRDBのオプティマイザでも対処できない複雑なクエリが発行され、最大数十秒かかるケースが発生
• 将来的なスケーラビリティの懸念: 書類件数は日々増加するため、今後年数が経過するにつれてさらなる性能悪化が確実に起こる

お客様が独自に定義した項目であるカスタム項目は、DBのカラムでは一般にシリアライズドLOBと呼ばれるJSON形式で保存されていたため、検索が実質的に不可能でした。特に、案件番号やプロジェクト名等の項目で書類を検索したいという要望は非常に多く、導入における必須条件となっていることもありました。

どのような状態を目指していたか

• カスタム項目を含む柔軟な検索条件でも、常に高速な検索を実現
• 書類件数が増加しても安定したパフォーマンスを維持できる
• 運用負荷を最小限に抑えた自動スケーリングが行われる
• MySQLはあくまでSingle Source of Truthとして保ち続ける

• Aurora Serverless v2(MySQL)のみで全ての検索を実装
• Amazon OpenSearch Serverless
• Amazon OpenSearch Managed Cluster

• 導入・運用の容易性: アプリケーションチームでメンテナンスするため、スケーリングやシャード管理など、出来る限り細かい管理を委譲したかった
• 既存の検索条件を互換性を崩さず維持できる
• 複雑な検索条件でも高速応答できる検索性能
• カスタム項目も柔軟に検索できる対応

• filterクエリによる高速検索: スコア計算不要で、SQL WHEREに近い純粋なフィルタリングが可能。これにより、既存条件もほとんどは問題なく移行できた
• Serverlessの運用メリット: シャード管理・スケーリングが自動化され、運用負荷が最小限
• 全体方針との一致: 全文検索エンジンはOpenSearch Serverlessを活用するという方針が既にあった
• nestedデータ型のサポート: カスタム項目の複雑な検索条件に対応可能

改善したかった課題はどれくらい解決されたか

• カスタム項目による検索: 完全に実現
• 検索パフォーマンス: p99が数十秒 → 1秒未満に劇的改善。中央値・p90・p99といった指標全てのパフォーマンスが向上。
• スケーラビリティ: 書類件数増加にも対応可能な基盤を確立

どのような成果が得られたか

• 検索速度が劇的に改善し、中央値・平均値を含む全体的なパフォーマンスが向上
• カスタム項目検索対応によって喜びの声が届いた
• 今後検索項目が増えたり、書類件数が増えても耐えうる検索環境となった

• データ構造の見直し: 基本的にデータ同期に当たってはOpenSearchにスナップショットを登録する必要がある。一つのデータが編集されると理論上無限の書類の情報に影響する項目があり、既存の検索条件を同等に維持できないものがあったため、書類に紐付く送付先のラベルのスナップショット化などをあらかじめ行う必要があった
• refresh_intervalの最小値が10秒: 書類作成・更新後の検索結果への反映が多少気になるレベルで遅延する。UI/UXでのフォローと、実際に表示するデータはMySQLから取得し直すことで、あくまで表示データは正しいという状況を作った。
• インデックス更新の競合問題: 同じ書類に対するMySQLからOpenSearchへのデータ登録リクエストが競合することで、片方で更新したかった項目が更新されないことが希に発生した。DynamoDBによるインデックス処理系へのロック取得によって解決した。
• 429エラーの散発的発生: OpenSearch Serverlessのスケーリング完了までの一時的なキャパシティ不足により、全件インデックス時や、急に負荷が上がったときなどにエラーが出た。リトライ機構により解決した。
• max_result_windowの10,000件固定: ページネーション制限が発生する。逆順検索のサポートで代替しつつ、全ページに対する一括処理ではPoint In Time APIによって対応した。

• 複雑な条件による検索を提供しているサービスがスケールしてきて、検索時間がボトルネックになっているような環境でまずおすすめ。
  • refresh_interval 10秒、max_result_window 10,000件といった制約を事前に把握し問題が無いかを確認する必要がある。絶対に10秒の遅延が許容されないような環境では使用できない。ただし、検索結果に一致する総件数はtrack_total_hitsによって取得できる。
• より細かい制御が必要な場合は、Managed Clusterも選択肢に入れる

この記事では触れていませんが、OpenSearchはこれだけでなくベクトル検索など様々な検索方法がサポートされており、近年流行のRAG(Retrieval-Augmented Generation)などとも相性は良いはずです。ただし、OpenSearch Serverlessを使う場合、Serverlessという特性上、ローカルでホストするOpenSearchでは使用できても実際には一部機能が塞がれていたり、特有の制約が存在することもあるので、事前に確認しておくことをお勧めします。

お客様の体験向上のため、以下の対応が出来れば良いなと思っています。

• 書類の楽観的表示による即時反映感の向上
• 最新書類表示箇所でのSQL混在によるハイブリッド検索の強化
• ServerlessからManaged Clusterへの移行検討（今後あまりにも遅延やスケーリング遅延が問題になった場合）
• さらなるUI/UX改善による10秒遅延の影響最小化