詳細內容

1. 概要
   • StartHub 是一個 AI 創業支援平台，為解決創業者所面臨的問題，從零打造 RAG 系統，透過客製化補助公告推薦、以使用者行為為基礎的 AI 聊天機器人、商業模式圖生成、競爭對手分析等功能，支援創業的整個前期歷程。
   • 韓國新創企業的存活率為 33.8%，低於 OECD 平均的 45.4%，約有 90% 因資金不足（38%）、缺乏市場性（35%）、錯誤的商業模式（20%）等因素而失敗。此專案正是從這個問題出發。
   • 競爭對手分析等需要即時網路搜尋的功能，則透過串接 Perplexity API 來處理。
   
2. 問題 — 流量增加時，LLM 服務的請求延遲與失敗率上升
   • LLM 相關功能當時是以阻塞式（blocking）的執行緒池架構在處理。
   • 在 Perplexity API 冗長的回應延遲期間，執行緒會處於 I/O 等待狀態。
   • 流量增加時，執行緒池隨之擴張，記憶體使用量呈線性成長。
   • 無法發揮 WebFlux 以非阻塞為基礎、高並行處理的優勢。
3. 解決方法 1 — 將以執行緒為基礎的非同步改為 Kotlin Coroutine
   • 以 CoroutineScope 與 Deferred 取代 Spring @Async 與 CompletableFuture。
   • 透過 kotlinx-coroutines-reactor 與 WebFlux 整合，建立了非同步處理架構。
4. 解決方法 2 — 將阻塞式 I/O 改善為非阻塞式
   • 將 Perplexity API 呼叫中的 .block() 轉換為 .awaitSingle()。
   • 將重複請求處理中的 CompletableFuture.get() 轉換為 Deferred.await()，改善為在 I/O 等待期間讓出執行緒。
5. 成果 — 並行處理量提升逾 10 倍，記憶體使用量降低約 90%
   • 建置 Grafana 監控伺服器後，執行並分析以 K6 為基礎的負載測試。
   • 達成全流程非阻塞，在相同資源下將並行處理量提升逾 10 倍，並將記憶體使用量降低約 90%。
   • 大幅改善了虛擬使用者（VU）達到臨界值時因過載而導致請求失敗的現象。
6. 導入非阻塞之前
   • 當 VU 達到臨界值時，Failure Rate 會急遽飆升，進而造成服務故障。
   
7. 導入非阻塞之後
   • 並行處理量大幅提升，並達成 HTTP Failures 為 0。