雲端運算

為什麼期末報告的那台「伺服器」，不在你的桌子底下

學期末，一群修課同學要把作業展示成一個能讓全班即時投票的網站。半夜尖峰湧入三百人，平常空蕩蕩的時段卻沒人上線。如果他們真的去買一台主機放在宿舍，要嘛平常多數時間機器閒置、電費白繳，要嘛尖峰時刻當機、被同學罵翻。最後他們做的事很簡單：打開瀏覽器，點幾下，租了一台「線上的電腦」，跑完那一晚就關掉，只付了幾十塊台幣。

這就是雲端運算(cloud computing)最樸素的樣貌——把「運算資源」變成像水電一樣，需要時打開水龍頭、用多少算多少、不用時關掉。背後那台機器到底長什麼樣、放在哪個國家、是不是一台實體電腦，使用者其實不需要知道。這種「資源即服務」的思維，正是過去二十年資訊基礎建設最深刻的轉變。

雲端到底「雲」了什麼：三種服務模型

理解雲端，最好的起點是區分它替你「接管」了多少工作。傳統上，要讓一個應用程式上線，你得自己準備機房、伺服器、作業系統、執行環境、再到應用程式本身。雲端的三種經典服務模型，差別就在於這條「責任堆疊」從哪裡開始由雲端業者負責。

• IaaS（基礎設施即服務，Infrastructure as a Service）：業者提供虛擬機器、儲存空間、網路。你拿到的是一台「空的電腦」，要自己裝作業系統、設定環境、部署程式。彈性最高，但管理負擔也最重。例：AWS EC2、Google Compute Engine。
• PaaS（平台即服務，Platform as a Service）：業者連作業系統、執行環境、資料庫都幫你管好，你只要把程式碼丟上去，平台自動跑起來。你不必煩惱作業系統更新或伺服器修補。例：Heroku、Google App Engine。
• SaaS（軟體即服務，Software as a Service）：你連程式都不用寫，直接用現成的軟體。Gmail、Google Docs、Notion 都是。使用者只負責「使用」，其餘全部交給業者。

有個常見的比喻能幫助記憶：披薩的三種吃法。IaaS 像買冷凍披薩回家，烤箱、盤子、用餐空間自己準備；PaaS 像叫外送，披薩做好送到家，你只管吃，但要自己擺桌；SaaS 像直接去餐廳，連洗碗都不用。

由上往下，你扛的責任越來越少，自由度也越來越低。選哪一層，本質上是在「掌控權」與「省事」之間做取捨。

一台機器變很多台：虛擬化(virtualization)

雲端能成立的技術基石，是虛擬化。一台實體伺服器往往配備了幾十核心、上百 GB 記憶體，若整台只租給一個使用者，多數時候資源都閒著。虛擬化讓一台實體機器在邏輯上「切」成許多台互相隔離的虛擬機器(virtual machine, VM)，每台 VM 都以為自己獨占一台完整的電腦，擁有自己的作業系統。

實現這件事的關鍵角色叫超管理器(hypervisor)，它坐在硬體與多個 VM 之間，負責把實體 CPU、記憶體、磁碟分配給各個 VM，並確保它們彼此隔離——A 客戶的 VM 當機，不會拖垮 B 客戶的 VM。正因為一台機器能服務多位互不相識的使用者（這稱為「多租戶(multi-tenancy)」），雲端業者才能把硬體成本攤薄，再以低廉價格租給你。

比 VM 更輕巧：容器(container)

虛擬機很好用，但它有個代價：每台 VM 都要扛一整套作業系統，開機慢、佔空間。如果我只是想跑一個小小的網站程式，何必為它配一整套 Linux？

容器就是為了解決這個浪費而生。容器不虛擬化整台硬體，而是共用宿主機(host)的作業系統核心(kernel)，只把應用程式與它依賴的函式庫、設定檔打包在一起。結果是：容器啟動只要幾秒甚至更快，體積小、密度高，一台機器能塞下的容器數遠多於 VM。Docker 是最知名的容器工具，而當容器一多、需要自動調度時，就交給 Kubernetes 這類「容器編排(orchestration)」系統管理。

容器最迷人的承諾是「在我電腦上跑得起來，在伺服器上也一定跑得起來」——因為環境被一起打包了，不再有「明明同一份程式碼卻在不同機器上行為不一致」的惡夢。

動手看一個例子

假設你寫了一支 Python 小程式，想讓它「無論搬到哪台機器都能一樣執行」。用容器，你只要寫一份 Dockerfile 描述「環境長什麼樣」：

# 從一個已備好 Python 的基礎映像開始
FROM python:3.12-slim

# 設定工作目錄
WORKDIR /app

# 把依賴清單複製進去並安裝
COPY requirements.txt .
RUN pip install -r requirements.txt

# 把程式碼複製進去
COPY app.py .

# 容器啟動時要執行的指令
CMD ["python", "app.py"]

接著兩行指令就能把它「封裝成一個可攜帶的執行包」並跑起來：

docker build -t my-app .    # 依 Dockerfile 建出映像(image)
docker run my-app           # 由映像啟動一個容器來執行

這份映像可以推到任何雲端、任何同事的電腦，跑出來的環境一模一樣。對比之下，若用傳統 VM，你得開機一整台作業系統、手動裝 Python、裝套件、複製檔案——容器把這一切壓縮成一份可重現的「食譜」。

為什麼雲端不會被尖峰壓垮：彈性擴展(elasticity)

回到開頭那個半夜湧入三百人的網站。雲端的殺手級能力，是彈性擴展：系統能依負載自動增減資源。當流量上升，自動多開幾台機器分攤；流量退去，自動關掉、停止計費。

擴展有兩種方向：

• 垂直擴展(scale up)：把單台機器升級得更強（更多 CPU、更多記憶體）。簡單，但有物理上限，且升級時往往要重啟。
• 水平擴展(scale out)：多開幾台同樣的機器，用負載平衡器(load balancer)把請求分散過去。理論上可以一直加下去，是雲端時代的主流做法。

水平擴展之所以強大，正是因為它把問題從「一台超級電腦」轉成「許多台普通電腦合作」——這就把我們帶進了分散式系統的領域。

分散式系統初探：合作的代價

當你的服務跑在許多台機器上，新的麻煩就來了：這些機器之間要透過網路溝通，而網路會延遲、會塞車、甚至會斷線。一台機器以為的「現在」，跟另一台機器以為的「現在」，資料可能對不上。分散式系統(distributed system)研究的，正是「如何讓一群可能各自故障的機器，協同表現得像一個可靠的整體」。

舉個直覺的例子：你在台灣的伺服器更新了庫存數量，美國的伺服器要過一小段時間才會收到這個更新。在這個空窗期，如果有人去問美國伺服器，它看到的會是「舊的」庫存。要嘛你讓它先等一等、把資料同步好再回答（但使用者就得等）；要嘛你讓它直接回答舊資料（但可能不一致）。這個兩難，被精煉成了分散式系統最著名的一條定理。

重點回顧

• 三種服務模型：IaaS 給你空機器、PaaS 給你執行平台、SaaS 給你現成軟體；越往上，業者接手越多、你越省事但掌控越少。
• 虛擬化讓一台實體機切成多台隔離的虛擬機，是多租戶與成本攤薄的基礎；容器則更輕巧，共用作業系統核心、啟動快、可攜帶。
• 彈性擴展讓資源隨負載自動增減，水平擴展（多開機器）是雲端主流，按用量計費。
• 多機器合作就進入分散式系統，網路的不可靠帶來資料一致性的根本難題。
• 雲端的優點是省去前期建置、彈性、全球觸及；缺點是長期成本可能更高、受制於供應商(vendor lock-in)、隱私與資料主權需謹慎評估。

深入探討（研究所視角）

虛擬機 vs 容器：隔離的層次差異

VM 與容器的根本分野，在於它們「在哪一層做隔離」。VM 由 hypervisor 在硬體層之上虛擬出完整的虛擬硬體，每台 VM 跑自己的客體作業系統核心(guest kernel)，彼此之間幾乎沒有共用面，隔離邊界堅實。代價是每台 VM 都背負一整套作業系統的開機時間與記憶體足跡。

容器則建立在單一宿主核心之上，靠 Linux 核心的 namespaces（隔離視角：行程、網路、檔案系統掛載點等，讓容器「看不見」彼此）與 cgroups（限制與計量資源：CPU、記憶體、I/O）這兩組機制達成隔離。因為共用核心，容器省去了重複的作業系統開銷，啟動以秒甚至毫秒計，密度遠高於 VM。但代價是隔離邊界較薄——容器逃逸(container escape)漏洞一旦得手，攻擊面直達宿主核心，而 VM 之間的攻擊則還需穿透 hypervisor。因此安全敏感的多租戶環境，常採折衷方案如 Kata Containers、gVisor、Firecracker，把「容器的輕量」與「VM 級的隔離」結合起來。從研究角度，這體現了系統設計永恆的權衡：隔離強度 ⟷ 資源效率 ⟷ 啟動延遲，三者難以同時最大化。

CAP 定理的直覺

CAP 定理是分散式系統的基石之一。它斷言：一個分散式資料系統，在以下三個性質中，當網路發生分區(partition)時，最多只能同時保證其中兩個——

• 一致性(Consistency, C)：所有節點在同一時刻看到的資料一致；任何讀取都拿到最新一次寫入的結果。
• 可用性(Availability, A)：每個請求都能在有限時間內得到（非錯誤的）回應。
• 分區容忍(Partition tolerance, P)：即使節點間的訊息遺失或延遲（網路被切成幾塊），系統仍能繼續運作。

關鍵在於：在真實世界裡，網路分區遲早會發生，不是「要不要容忍」的選擇題，而是必然。所以 P 幾乎是必選項。真正的抉擇發生在分區當下，系統只能在 C 與 A 之間二選一：

• 選 CP：寧可拒絕服務，也不回傳可能過時的資料。回到前面台灣／美國庫存的例子，美國伺服器在收不到同步時，乾脆回「暫時無法服務」，保證你看到的永遠正確。
• 選 AP：寧可回傳可能過時的資料，也要保持回應。美國伺服器照樣回答，只是可能是舊庫存，待網路恢復後再「最終一致(eventual consistency)」地對齊。

值得澄清一個常見迷思：CAP 並非要你在「正常情況」下永久放棄某一性質，它描述的是分區發生時的瞬間抉擇。在網路健康時，系統其實可以兼顧 C 與 A。這個更細緻的觀點被 PACELC 定理補完：若有分區(P)，在 A 與 C 之間取捨；否則(E, else)，在延遲(Latency, L)與一致性(C)之間取捨——也就是說，即使沒有分區，想要更強的一致性往往得付出更高的延遲。

形式上，若以 $N$ 為複本總數、$W$ 為一次寫入需確認的複本數、$R$ 為一次讀取需查詢的複本數，當 $W + R > N$ 時可保證讀到最新寫入（強一致的法定數讀寫，quorum）。提高一致性（加大 $W$ 或 $R$）必然增加被慢節點拖累的機率，這正是延遲與一致性張力的數學寫照。

與其他主題的連結

雲端把計算機概論裡許多看似分立的主題串成一條線：作業系統的行程隔離與資源排程，在虛擬化與容器中以新形態重現；計算機網路的延遲、頻寬、可靠性問題，在分散式系統中被放大成一致性難題；演算法裡的負載平衡與快取策略，決定了水平擴展的效率上限。理解雲端，某種意義上是把這些基礎拼回一張完整的系統圖像——並學會在「沒有完美解、只有取捨」的真實工程世界裡做出明智的選擇。