もう並列実行は怖くない ~コネクション枯渇解消のための実践的アプローチ~

by katakyo

Slide 1

Slide 1 text

もう並列実行は怖くないコネクション枯渇解消のための実践的アプローチ @katakyo Kaigi on Rails 2025 1

Slide 2

Slide 2 text

01 自己紹介 2

Slide 3

Slide 3 text

片田恭平 (katakyo) プロダクト開発部バックエンドエンジニア 23卒でマイベストに新卒入社現在は社内システムのAIワークフローの開発、社内の AI活用改善などしています kashiwa.rbによく出没します ●自己紹介 @katakyo_51 自作PC/ラーメン/サウナ ●趣味自己紹介 3

Slide 4

Slide 4 text

月間利用者数 3,000 ユーザーの “選択”をサポートするサービス万人以上（2025年8月時点） 4

Slide 5

Slide 5 text

選択に資するデータベースを作るために、ユーザーニーズや利用シーンに合わせて各領域で専門性を持ったメンバーが徹底検証を行い、唯一無二のデータベースを制作しています。商品を自社で購入し、専門性を持ったメンバーが徹底検証雨傘の検証。送風機を使って「耐風性」を比較防水カメラの検証。プールを貸し切り、実際に潜って撮影縦型洗濯機の検証。主要メーカー 7社の中から人気 18商品を購入して検証ヘアアイロンの検証。全商品を実際に使用して違いを検証チェーンソーの検証。片道 2時間ほどかけて、山奥にこもって検証電子レンジの検証。実際の使い勝手などをリアルに検証 5

Slide 6

Slide 6 text

今日持ち帰っていただけるもの ● Active Recordのコネクションプールの仕組みと、それがなぜ枯渇するのかについて ● RDSのmax_connectionsの数, Active Recordのコネクションプールのサイズ , Sidekiqのスレッド数といった複数プロセスと複数スレッドの並列処理のパラメータを見積もるための考え方や手順 ● コネクションの枯渇を未然に防ぐための方法 6

Slide 7

Slide 7 text

想定する聞き手 ● バッチの並列処理の設計に困っている方 ● Active Recordのコネクションや並列実行の適切なパラメータ設定の考え方を知りたい方 ● これから並列実行を行おうとしている方 7

Slide 8

Slide 8 text

想定環境バックエンド　 Ruby on Rails(8.0) バッチ処理　 Rakeタスク非同期Job　Sidekiq インフラ　AWS ECS, RDS 使用したgem Parallel 8

Slide 9

Slide 9 text

アジェンダ 1 自己紹介今回並列実行を行った背景並列実行時に起きたエラー安全に並列処理を行うための方法 9 2 3 4 5 まとめ

Slide 10

Slide 10 text

02 今回並列実行を行った背景 10

Slide 11

Slide 11 text

11 マイベストでの事業課題マイベストは、オールジャンルで商品 DBを作成しています扱う商品数は約 1000万点で今後も増え続けていきます 1つの商品に複数のスペック情報を登録していきます

Slide 12

Slide 12 text

マイベストでの事業課題商品データやスペック情報の入力・チェック業務をほぼ全て手動で行っていたネットリサーチデータ入力ダブルチェック 12

Slide 13

Slide 13 text

時間と労力がとてもかかる ..... 13

Slide 14

Slide 14 text

そこでゲームチェンジャーとして現れたのが 14

Slide 15

Slide 15 text

AI 15

Slide 16

Slide 16 text

マイベストでの事業課題人間のチェック AIによるリサーチとデータ入力人によるリサーチとデータ入力 AsIs ToBe AIによって商品情報の入力ができないかというプロジェクトが始動 16

Slide 17

Slide 17 text

AIワークフロー 01 調査対象を選定 02 Web検索 03 情報抽出 04 データ整形 05 ファクトチェック OpenAIやGeminiなどのLLMを使って自動化 OpenAIやGeminiといったLLMのAPIを複数回実行し、仮説検証を進めていた 17

Slide 18

Slide 18 text

ある程度ワークフローの仮説検証もできたのでプロダクトに組み込もうとなりました 18

Slide 19

Slide 19 text

19 AIワークフローのシステム概要 1 日次バッチでAIワークフローの実行 2 管理画面からAIワークフローを実行未入力の商品データを埋めるために RakeタスクをECSタスクとして定期実行管理画面から特定のボタンを押したときに Sidekiqで非同期Jobを実行 Amazon ECS タスク実行コンテナ起動非同期Jobを実行

Slide 20

Slide 20 text

ただここで問題が .... 20

Slide 21

Slide 21 text

AIのワークフローは時間がかかる 21

Slide 22

Slide 22 text

AIワークフローの課題 01 調査対象を選定 02 Web検索 03 情報抽出 04 データ整形 05 ファクトチェック精度改善のため、 AIのステップを複数に増やしたため 1商品あたりのリサーチが約2分近くかかるようになってしまった 22

Slide 23

Slide 23 text

AIワークフローの課題 01 調査対象を選定 02 Web検索 03 情報抽出 04 データ整形 05 ファクトチェックリサーチ対象商品が月に 120万商品ほどあり、 1日3500商品ほど捌けていたが、 1ヶ月でも周り切らない 23

Slide 24

Slide 24 text

非同期JobでのAIワークフローの課題スレッド数が少ないため、 Jobが詰まってしまった当時の運用だと、 Sidekiqを1プロセスで行っていた 24

Slide 25

Slide 25 text

25 外部APIのI/Oがボトルネックだから、パフォーマンスチューニングしづらい ...

Slide 26

Slide 26 text

26 並列実行すれば、なんとかなるのでは？

Slide 27

Slide 27 text

27 本当に大丈夫？

Slide 28

Slide 28 text

03 並列実行時に起きたエラー 28

Slide 29

Slide 29 text

29 Parallel gemについて Parallel gem を使うことで、 Rubyで並列化を手軽に実装することができる 3種類の並列化 (マルチプロセス、マルチスレッド、 Ractor)を引数で切り替えることが可能

Slide 30

Slide 30 text

30 AIワークフローのマルチスレッドを実装今回のAIワークフローは I/Oバウンドがボトルネックなので、 1プロセスの ECSタスクを 8マルチスレッドで動かし高速化を目指した

Slide 31

Slide 31 text

31 バッチを実行してみる

Slide 32

Slide 32 text

32 コネクションプールが枯渇していることがあった

Slide 33

Slide 33 text

データベースのコネクションとは？アプリケーションサーバー DB アプリケーションサーバーは、データベースとやりとりする必要が生じるとアプリケーションサーバーとデータベースサーバー間の専用通信チャネルである「コネクション」を確立します 1 コネクションを確立 2 データベース操作を実行 3 コネクションをクローズ 33

Slide 34

Slide 34 text

データベースのコネクションプールとは？ DBとの接続・切断はコストが高い処理のため、 Active Recordはあらかじめ一定数の接続を確保しておき、必要に応じて使い回す「コネクションプール」という仕組みを持っています。 1 プールからコネクションを取得する 2 データベース操作を実行 3 コネクションをプールに戻すコネクション確立前すでにコネクションが確立済み 34 1 コネクションを確立 2 データベース操作を実行 3 コネクションをプールに保存

Slide 35

Slide 35 text

ActiveRecordにおけるコネクションプールについて Active Recordは、データベースコネクションプールを Webプロセスやバックグラウンドプロセスごとに管理します 35 https://www.bigbinary.com/blog/understanding-active-record-connection-pooling

Slide 36

Slide 36 text

36 コネクションプールが枯渇した理由 Parallelブロック内の関数で DBデータの操作があったが、スレッド数に対してコネクションプールの数が適切に設定されていないことが原因でした

Slide 37

Slide 37 text

失敗したケーススレッド数に対してコネクションプールのサイズが足りていないため、待機する秒数が checkout_timeoutを超えたため発生 37 ・・・ DB コネクションプールスレッド1 スレッド2 スレッド3 スレッド4 スレッド8 待機中のスレッド

Slide 38

Slide 38 text

適切なケース 1つのスレッドで複数のデータベースコネクションは発生しないので、 DBのやり取りが発生する場合は、コネクションプールのサイズをスレッドと同数に合わせる 38 ・・・ DB コネクションプールスレッド1 スレッド2 スレッド3 スレッド8 ・・・

Slide 39

Slide 39 text

データベースのプールサイズの設定方法 ActiveRecordでは、database.ymlでプールで保持するコネクションの最大数を設定できます Railsではプロセスごと (Puma)のプール数を連動するために RAILS_MAX_THREADSというデフォルト値が用意されているが、こちらを 8スレッドの場合は 8にする 39

Slide 40

Slide 40 text

40 設定が甘かった .... Sidekiqの時はちゃんと設定しよう

Slide 41

Slide 41 text

Sidekiqの並列処理と concurrency concurrency の設定値が、1プロセス内で同時に動くスレッドの数を決定します 41 各プロセスのスレッド数の合計個別のプロセスのスレッド数

Slide 42

Slide 42 text

42 AIワークフローを Sidekiqで動かすワークフローの共通化クラスにおいて Sidekiqのスレッドを使いたい先ほどRakeタスクでは 8スレッドで設定した値を SidekiqのJobではスレッドのネストを避けるため、この値を 1に設定して実装しました。

Slide 43

Slide 43 text

新しいプロセスで Sidekiqを立ち上げてみる sidekiq-ai-researchという名前の新しいプロセスを立ち上げて既存の Jobに影響が出ないように試みた試験的にプロセスを作成し、 Sidekiqのスレッド数を10でこのプロセスのコネクションプールのサイズを10と設定した 43

Slide 44

Slide 44 text

44 またコネクションプールが枯渇してしまうケースが発生

Slide 45

Slide 45 text

Sidekiqでのコネクションプールが枯渇した原因 Sidekiqは起動時にプロセス自身がコネクションを 1つ確保します。そのため、実際にスレッドが使えるコネクションは設定値より1つ少なくなります。結果として、 sidekiq.ymlのconcurrencyとdatabase.ymlの poolの数を同じにすると、コネクションが 1つ不足する事態に陥ります。 45

Slide 46

Slide 46 text

並列処理を行うためのコネクションプールのサイズ Batchの時コネクションプールのサイズ = Batch内でのスレッド数 Sidekiqの時コネクションプールのサイズ = Sidekiqのスレッド数 +1 46

Slide 47

Slide 47 text

05 安全に並列処理を行うための方法 47

Slide 48

Slide 48 text

安全に並列処理を行うための方法 1 パラメータ設定の考え方コネクションプールを枯渇させないようにする工夫パフォーマンス改善 48 2 3

Slide 49

Slide 49 text

パラメータ設定の考え方 49

Slide 50

Slide 50 text

DBと可能性のあるサービスを考えて悲観的に見積もる max_connections の数を超えると Too Many Connections エラーによりアプリケーションのダウンタイムが発生する DBの最大コネクション数は以下のように見積もる ● Webコネクション数 = ECSタスク数 ✕ Pumaのワーカー数 ✕ コネクションプールのサイズ ● バッチのコネクション数 = ECSタスク数 ✕ コネクションプールのサイズ ● バックグラウンドコネクション数 = ECSタスク数 ✕ Sidekiqプロセス数 ✕ プロセスあたりのスレッド数 ● DBの最大コネクション数 = Webコネクション数 +バッチのコネクション数 + バックグラウンドコネクション数 50

Slide 51

Slide 51 text

インフラ全体でのパラメータ見積もり Amazon ECS Amazon ECS Amazon ECS Batch Sidekiq アプリケーション ECSタスク数× pumaのworker数 × コネクションプールのサイズ Batchの実行数×コネクションプールのサイズプロセスごとの(スレッド数+1)の合計超えてはいけない値 max_connections 51

Slide 52

Slide 52 text

Slide 53

Slide 53 text

max_connectionsの値を確認する使用している RDSのスペックごとに DBコネクションが可能な max_connections数が異なる db.r5.4xlarge (Writer) を使っていたため 4000という値が max_connectiosになります 53 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html

Slide 54

Slide 54 text

全体のコネクション数は RDSのmax_connectionsの半分にする ● デプロイ時には、瞬間的に古いサービスと新しいサービスが一時的に共存するため、 ECSのタスク量が2倍になる可能性がある ● DBに接続している、全体のコネクション数の合計が、 RDSのmax_connectionsの半分を超えないように設定します。 54

Slide 55

Slide 55 text

データベースのコネクションを確認サービスによって ECSタスクのサーバー台数が変動するため、ピーク時のデータベースコネクションを計測追加可能なデータベースコネクション数 = (max_connections / 2) - ピーク時のデータベースコネクション数 55

Slide 56

Slide 56 text

ワークフローの I/Oの比率を測定アプリケーションの I/O待ちの割合を各ワークフローの測定により 90%以上あると算出しました。アムダールの法則などから、現状のスレッド数を増やしても性能向上が鈍化する点を見極め、 CPUリソース効率が最も良い 8スレッドを 1プロセスあたりの最大値として採用し、それ以上実行したい場合はサーバー台数を増やして並行処理を行った 56 p: 並列化できる処理の割合 N: 並列実行に利用するプロセッサ（スレッド）の数 (1 - p): 逐次実行（並列化できない）が必要な処理の割合

Slide 57

Slide 57 text

Sidekiqの公式推奨の concurrencyの上限 Sidekiqの1プロセスでのconcurrency は50以下で推奨されています 50を超える場合はプロセスを増やす 57 https://github.com/sidekiq/sidekiq/wiki/Advanced-Options

Slide 58

Slide 58 text

正しくコネクションプールが設定されているかログを仕込む ActiveRecord::Base.connection_pool.statなどでコネクションプールのサイズや、現在のコネクション数などを可視化してデプロイ時に設定が意図通りか確認 58

Slide 59

Slide 59 text

コネクションプールを枯渇させないようにする工夫 59

Slide 60

Slide 60 text

アプリケーションのコードでもコネクションを意識バッチの中で DBのコネクションが発生する箇所と外部APIとの通信を意識 DBの読み取り DBの書き込み外部APIの通信 60

Slide 61

Slide 61 text

ActiveRecord::Base.connection_pool.with_connection とは DBコネクションプールから接続を「一時的に借りて、ブロック終了時に必ず返却」するための安全なラッパーメリットスレッドや並列処理下でも接続リークを防ぎ、 ConnectionTimeoutの発生確率を下げる。デメリットコネクションプールのcheckout/checkinの頻発でスループットが下がることがある 61

Slide 62

Slide 62 text

ActiveRecord::Base.connection_pool.with_connection とは外部APIの通信時に with_connection ブロックを閉じてコネクションを開放することにより、コネクションを占有し続けないようにするコネクションが発生するブロックと、外部 API の通信などの I/Oを明確に分ける工夫をする 62

Slide 63

Slide 63 text

パフォーマンス改善 63

Slide 64

Slide 64 text

Webアプリケーションでは、データベースへのコネクションが多数発生するためこのような状況で、データの整合性を保つためにトランザクションは不可欠トランザクションを長時間張るとテーブルロックの可能性が発生し、 ActiveRecord::LockWaitTimeoutエラーやコネクションを占有し続けてパフォーマンスが悪化する原因となります。 64 長時間のトランザクションに気をつける

Slide 65

Slide 65 text

● 範囲を最小限に本当に一貫性が求められる、必要最低限の DB操作のみをトランザクションで囲みます。 ● 重い処理は外に出す外部APIの呼び出しや、時間のかかる計算などはトランザクションの外で実行させる ● ロックの粒度を意識する不必要にテーブル全体をロックしないよう、更新範囲を限定するなどの工夫をする。 65 トランザクションに気をつける

Slide 66

Slide 66 text

パフォーマンスを意識するためにワークフロー全体の処理を rack-lineprofのgemを使った調査を開発にテストとして行った例として、各ワークフローのトランザクションを貼っているメソッドやクラスを行単位でプロファイリングするようにした 66 https://nishinatoshiharu.com/usage-rack-lineprof/

Slide 67

Slide 67 text

プロファイリングによって検知できた例 ● N+1や非効率なクエリ処理の検知 ● トランザクション時に S3への画像のuploadの同期処理 67

Slide 68

Slide 68 text

プロファイリングによって検知できた例 ● N+1や非効率なクエリ処理の検知 →パフォーマンスチューニング ● トランザクション時に S3への画像のuploadの同期処理 →S3への画像のupload処理とレコードの保存処理を分離し、 S3への画像のuploadを非同期処理に修正 68

Slide 69

Slide 69 text

● 環境変数の設定の見直しと適切なパラメータ見積もり ● ワークフロー内での DBコネクションが発生するブロックと I/Oの完全分離によるコネクション管理 ● トランザクション内などで不要な I/OやN+1などが起きていないか、行単位でプロファイリングして確認 69 安全に並列処理を行うためやったこと

Slide 70

Slide 70 text

70 実際に追加したプロセス 1 日次バッチでAIワークフローの実行 2 管理画面からAIワークフローを実行 ECSタスクを15台で8スレッドの並列処理を組み合わせた並行処理別プロセスを立ち上げて非同期の 50並列処理を実行 Amazon ECS タスク実行コンテナ起動非同期Jobを実行

Slide 71

Slide 71 text

・120並列で問題なく、バッチを完了 !5台のサーバーで 8スレッドの処理でリサーチ件数が 3500商品/日→45万商品/日に！・Sidekiqも50並列で他の Jobに影響を与えることなく、高速化を実現 71 結果

Slide 72

Slide 72 text

06 まとめ 72

Slide 73

Slide 73 text

● 並列実行するときはコネクションプールを意識してパラメータを設定しましょう ● コネクション枯渇を防ぐために、 DBコネクションが発生する処理と I/Oの処理を分けてコネクションプールに余裕が出るようにしましょう ● LLMのAPIなどI/Oがボトルネックの時は並列化を検討してみましょう 73 まとめ

Slide 74

Slide 74 text

74 https://connpass.com/event/370180/ Afterイベントを3社合同でやります！

Slide 75

Slide 75 text

75 https://connpass.com/event/370180/ LT枠もぜひ募集していますのでよかったらご参加ください！

Slide 76

Slide 76 text

ご清聴ありがとうございました 76

Slide 77

Slide 77 text

● https://www.bigbinary.com/blog/tuning-puma-max-threads-configuration-with-gvl-instrumentation ● https://techracho.bpsinc.jp/hachi8833/2025_07_01/151299 ● https://www.bigbinary.com/blog/understanding-active-record-connection-pooling ● https://techracho.bpsinc.jp/hachi8833/2025_07_16/151486 ● https://qiita.com/HrsUed/items/6a103322bf4e67e9054c ● https://nishinatoshiharu.com/usage-rack-lineprof/ ● https://speakerdeck.com/andpad/yasasiiactiverecordnodbjie-sok-nosikumi 参考文献 77