はじめに：なぜ高速化が必要だったのか？

私が担当しているプロジェクトでは、大量の物件データを扱っています。

Solrコアに保存されている「元となる物件データ」を、ユーザーや店舗に見せるための形に整形し、別のSolrコアへ保存し直す──
そんな一連の処理を日々回しています。

このときに問題になるのが、物件データのインポート速度です。
インポート処理が遅くなると、どうしてもデータの反映が後ろ倒しになり、結果として物件データの鮮度が落ちてしまいます。

物件の鮮度が落ちると、実際のサービスにも影響が出てきます。

• ユーザーから物件の問い合わせがあっても、すでに成約済みだった
• 表示される物件が減り、ユーザーの選択肢が狭まってしまう

どちらもユーザー体験を大きく損なう要因です。

そのためこのプロジェクトでは、
「いかに速く・安定して物件データをインポートできるか」　がとても重要なテーマになっており、
Solrへの大量データインポートの高速化に取り組むことになりました。

現状の課題:

元となるSolrコアからのデータ取得、整形、そして別コアへの保存までの一連の処理が徐々に遅くなってきているという問題を抱えていました。

平時であれば約20分で完了していた処理が、
状況によっては2時間以上かかることもあります。
さらに厄介なのは、一度処理に時間がかかり始めると、
次回以降の実行でも同様に時間がかかってしまうという悪循環に陥る点です。

また、処理全体がブラックボックス化しており、
「取得・加工・保存」のどこがボトルネックになっているのか分からない状態でした。
このままでは、効果的な改善策を打つことができません。

当然ながら、この処理が遅くなるほど、最新の物件データがユーザーの目に届くまでの時間も長くなります。
結果として、データの鮮度低下につながり、サービス品質にも影響を与えてしまいます。

前提

• Solrバージョン：6.6.6（旧系統）
• 使用ライブラリ：rsolr（Ruby）
• 対象データ件数：数十万〜数百万件処理内容：
• • Solrからの取得 → 加工 → Solrコアへ投入
  • 取得するSolrと投入するSolrは同一サーバーで動いており、コアが分かれている。
• 処理方式：バッチ単位で複数プロセス並列実行
• 実行環境：Cloud Run Job

🔍ステップ1：ボトルネックの特定と計測

最も時間がかかっている部分を特定することから始めます。

🔍インポート処理フローの再確認

データソース（Solr）からの取得 → 変換・加工 → Solrへの送信 → Solrでのインデックス作成・コミット

この一連の処理を都道府県や地方ごとに並列で実行している

🔍ボトルネックの調査準備

まず最初に取り組んだのは、
「どこで時間がかかっているのかを可視化すること」でした。

これまでは、「全体として遅い」ことは分かっていても、
処理のどこが原因なのかを正確に把握できていませんでした。

そこで、処理の実態を把握するために、
計測専用のレポート用DBを新たに用意し、
以下の情報をバッチ処理ごとに記録するようにしました。

• 処理の開始時間・終了時間
• データソース（Solr）から取得した件数
• 変換・加工後の件数

これにより、
「どのバッチが」「どの工程で」「どれくらい時間を使っているのか」
を数値として追えるようになりました。

あわせて、既存のアプリケーションログも改めて確認しました。
処理時間が長くなっていそうな箇所を洗い出し、その前後のログを詳しく追っていくことで、
実際に最も時間を消費している処理を特定していきました。

この2つのアプローチを組み合わせることで、
感覚ではなく、事実ベースでボトルネックを判断できる状態を作ることができました。

🔍ボトルネックの特定

まず問題になっていたのが、
Solrの select クエリの実行時間が、時間帯によって極端にばらつく点です。
同じ検索処理を繰り返し実行しているにもかかわらず、

• 0時台：1秒もかからずに終了
• 9時台：15秒以上かかって終了

というように、明らかな差が発生していました。

調査を進めたところ、
この「遅い時間帯」は、データソース側のSolrに大量データを投入している時間帯と
ちょうど重なっていることが分かりました。

つまりこの時間帯は、

• 変換・加工対象となる物件数が増加し
• 同時に Solr への 読み取り（select）と書き込み（add / commit） が発生し
• Solr に対する負荷が一気に高まっている

という状態になっていたのです。

もうひとつの大きなボトルネックが、
Solrへの commit 処理に異常な時間がかかっている点でした。

具体的には、

• 5,000件の commit に 120秒以上かかるケースが頻発
• 現状の実装では commit を最大3回までリトライするため
  最悪で 360秒以上 を要することもありました

さらに、データソース側のデータ量が多い場合には、
ネットワーク負荷が高まりやすいという問題も見えてきました。

その結果、

• Cloud Run Job のメモリ使用量が増大し
• メモリ不足による Out of Memory エラー が発生
• ジョブが異常終了する

といった事象も確認されました。

これらの結果から、単純に「アプリ側の処理が遅い」のではなく、
Solrへの読み書きが集中するタイミングそのものがボトルネックになっている
ということが、はっきりと分かってきました。

🛠️ ステップ2：各ボトルネックに対する具体的な改善策

ここでは、特定されたボトルネックに対して、どのような対策を講じたかを具体的に記述します。

…

記事の続きは下のURLをクリック！

https://rightcode.co.jp/blogs/54363

もっとワクワクしたいあなたへ

現在、ライトコードでは「WEBエンジニア」「モバイルエンジニア」「ゲームエンジニア」、「デザイナー」「WEBディレクター」「営業」などを積極採用中です！

ライトコードは技術力に定評のある受託開発をメインにしているIT企業です。

有名WEBサービスやアプリの受託開発などの企画、開発案件が目白押しの状況です。

• もっと大きなことに挑戦したい！
• エンジニアとしてもっと成長したい！
• モダンな技術に触れたい！

現状に満足していない方は、まずは、エンジニアとしても第一線を走り続ける弊社代表と気軽にお話してみませんか？

ネット上では、ちょっとユルそうな会社に感じると思いますが（笑）、
実は技術力に定評があり、沢山の実績を残している会社ということをお伝えしたいと思っております。

• ライトコードの魅力を知っていただきたい！
• 社風や文化なども知っていただきたい！
• 技術に対して熱意のある方に入社していただきたい！

一度、【Wantedly内の弊社ページ】をのぞいてみてください。

Wantedly：https://www.wantedly.com/companies/rightcode