[Day 24] RAG 從單機服務走向可水平擴展的 Production 架構

前幾天，我們開始把 RAG 從「可以運作」往 Production 推進

但 很快會遇到一個問題：

如果單台 Server 已經到極限，接下來該怎麼辦

這就是今天要處理的問題

今天不再只是優化單台機器，而是開始思考：

如何讓 RAG 從「單機服務」變成「可以水平擴展的 Production 架構」

什麼是 Scaling

Scaling 的核心概念很簡單：

當流量增加時，系統能不能透過增加資源來維持服務品質

最常見有兩種方式：

Vertical Scaling：垂直擴展

直接把單台 Server 升級

優點是架構簡單

但問題也很明顯：

• 有硬體上限
• 單機故障會造成服務中斷
• 資源成本可能快速增加
• 無法有效利用多台機器

Horizontal Scaling：水平擴展

不是把一台機器變得更強，而是增加更多 Server

建立 Load Balancer

當流量增加，這就是今天的重點：

Horizontal Scaling

為什麼 RAG 特別需要 Scaling

一個簡化版的 RAG Pipeline：

如果所有東西都放在同一台 Server

流量一增加，就可能發生效能消耗

最後變成：

流量越大、系統越慢、Timeout 越多

形成惡性循環

Scaling 之前不能直接說：

「多開幾台 Server 就好了」

因為真正的瓶頸可能根本不在 API Server

因此：

Scaling 的第一步不是加機器，而是找到瓶頸

Single Instance 到 Multi Instance

假設原本只有一個 RAG Application

當流量增加

這時候最大的問題是：

可以直接複製 RAG App 嗎

答案是：

可以，但 Application 必須盡可能 Stateless

什麼是 Stateless Application

Stateless 的意思是：

每一次 Request 都不應該依賴某一台特定 Server 上的本地狀態

把 State 移到共享服務

Production 架構通常會把 State 放到外部服務

因此任何一台 App 都可以處理 Request

Shared Services

不應該跟著每個 App 各自建立

應該是共享資源

Load Balancer 是做什麼的

當有三台 Application

User 不應該自己決定

而是透過 Load Balancer 負責將 Request 分配出去

這就是最基本的：

Load Distribution

Docker 讓 Scaling 更容易

前面幾天我們已經開始把服務 Production 化

現在可以使用 Docker 封裝 RAG Application

Docker Compose 進一步管理服務

實際開發時，可以使用 Docker Compose 管理

如果使用 Docker Compose 的 Scale

就可以建立多個 Application Container

Vector DB 也要考慮 Scaling

RAG 的核心資料之一就是 Vector Database

因此 Production 架構通常會把 Vector DB 視為：

Shared Data Service

Scaling 不代表所有東西都能無限增加

這是今天非常重要的一個觀念

可以避免：

• 惡意大量請求
• API 成本暴增
• LLM Limit
• Server 被單一 User 佔滿

這樣才能知道：

到底是哪一個 Component 成為瓶頸

核心概念是：

不要依賴單一 Application Instance 的 Local File System

所以：

Scaling 的目的不是無限增加 Server，而是找到合理的 Capacity

今天完成水平擴展之後，下一個問題自然會出現：

如果 Application、Vector DB、Load Balancer 都已經變成多個服務，要怎麼讓整套系統更容易部署與管理

下一步會開始進入：

[Day 25] RAG Deployment 從 Docker Container 到 Production 部署

不只是「架構圖可以畫出來」，而是真正可以被部署、更新與維運的 Production RAG