Azure Functionsの同時実行数を減らして処理速度を改善した話

Transcript

1. Azure Functionsの同時実行数を減らして処理速度を改善した話 NCDC株式会社 佐伯 久 2026 / 06 / 24
2. 自己紹介 ⚫ 佐伯 久（サエキ ヒサシ） ⚫ バックエンドエンジニア（2年と少し） ⚫ API開発（TypeScript / Python） ⚫ インフラリソース構築(AWS / Azure) 2
3. アーキテクチャ 3
4. 非機能要件 ⚫ 各現場からのリクエストの１件目が、120〜180秒以内に処理されること ⚫ 各現場 → 18箇所 ⚫ 現場ごとにQueueを分けている ⚫ 例）複数現場が同時にリクエスト ⚫ OK: A現場が10件登録 → 1件目の処理時間 10秒 ⚫ OK: B現場が10件登録 → 1件目の処理時間 20秒 ⚫ NG: C現場が10件登録 → 1件目の処理時間 200秒 4
5. 性能試験の内容 5 ⚫ 単位は秒 ⚫ 処理時間の昇順 ⚫ 上位13件は合格 ⚫ 下位5件は不合格 ⚫ ツール ⚫ 「k6」を活用 ⚫ オープンソースの負荷テストツールで、JavaScriptにテストシナリオを記述して負 荷テストを実施することができる。 ⚫ シナリオ ⚫ 5秒おきに各現場から10件単位で写真を登録する
6. 性能試験の結果（１件目が120〜180秒以内に完了） 6 ⚫ 処理時間(秒)の昇順 ⚫ 上位13件は合格 ⚫ 下位5件は不合格 ⚫ 不合格から極端に遅くなっている
7. 原因分析 ⚫ 写真登録した現場順に処理が進んでいた ⚫ Queueに格納された10件のメッセージを同時に処理していた ⚫ Queueから一度に取得するメッセージ数 > 10 ⚫ 複数現場のOCR処理が数多く並行していた ⚫ → 複数現場のOCR処理が同時に大量に走ることで負荷が高まり、後か らリクエストされる現場にリソースを割けなかったのでは？ 7
8. パラメータ調整 ⚫ 調整したパラメータ ⚫ batchSize: 32 → 3 ⚫ Queueから一度に取得するメッセージの数 ⚫ newBatchThreshold: 16→0 ⚫ Queueからメッセージを再取得する基準になる処理中のメッセージ数 ⚫ 調整前後の最大同時実行数 ⚫ 調整前: 864件 ⚫ (32 + 16) * 18 = 864 ⚫ 調整後: 54件 ⚫ (3 + 0) * 18 = 54 8
9. 再試験の結果（１件目が120〜180秒以内に完了） ⚫ 全件合格 ⚫ Queueから3件ずつ取得して処理 できていた ⚫ 極端に遅い処理がなくなった 9
10. 補足：トータルスループットも改善されていた ⚫ 1現場から300件の写真登録 ⚫ 1件目、10件目、全てのデータの完了時間を計測 ⚫ 同時実行数32件の場合 ⚫ 1件目: 7秒 ⚫ 10件目: 51秒 ⚫ 全てのデータ: 18分31秒 ⚫ 同時実行数3件の場合 ⚫ 1件目: 8秒 ⚫ 10件目: 26秒 ⚫ 全てのデータ: 8分35秒 10
11. 補足：トータルスループットも改善されていた ⚫ なぜ速くなかったのか（Geminiの見解） ⚫ 詰め込みすぎによるオーバーヘッドの解消 ⚫ コンテキストスイッチの削減 ⚫ タスク切り替えが減って1つ1つの処理に集中しやすくなった ⚫ メモリ/GCの安定化 ⚫ 同時処理数が減ることでメモリ使用量が安定し、GCによる処理停止が減る ⚫ 外部リソースの競合解消 ⚫ DBへの接続数やロック競合が減り、待ち時間・リトライが発生しなくなる 11
12. まとめ ⚫ Azure Functionsの batchSize / newBatchThreshold を調整し、最大同 時実行数を864件 → 54件に削減 ⚫ 全18現場の非機能要件（120〜180秒以内）をクリア ⚫ 同時実行数を絞ることで、トータルスループットも改善 ⚫ 「並列度を上げれば速い」は必ずしも正しくない可能性がある ⚫ コンテキストスイッチの切り替えやリソース競合などによるオーバーヘッドに 注意が必要な場合がありそうです 12