https://clarence.tw/tags/hosting/ Recent content in Hosting on Clarence｜Backend、AI、DevOps 與 Infrastructure Hugo -- gohugo.io zh-tw Sat, 21 Jan 2023 02:00:00 +0800 https://clarence.tw/posts/hosting-high-bandwidth-web-server/ Sat, 21 Jan 2023 02:00:00 +0800 https://clarence.tw/posts/hosting-high-bandwidth-web-server/ <p>我曾長期維運高流量 hosting environment，同一組環境上承載 4000 個以上網站。這類工作不是單純把 Web server 架起來，而是要同時處理 capacity、monitoring、updates、security、DNS / CDN、incident response 與日常維護成本。</p> <p>對大量站台來說，最重要的是讓日常維運可以被標準化。每一次更新、憑證、設定調整或異常告警，都不能只靠人工記憶處理，否則規模一大就會變成風險。</p> <h3 id="cloudflare-30-天的數據">CloudFlare 30 天的數據</h3> <p>可以由下圖看到月流量統計</p> <ul> <li>Requests 約 1900 萬</li> <li>Bandwidth 約 2 TB</li> <li>Visits 超過 70 萬</li> <li>Page views 超過 100 萬</li> </ul> <img src="https://clarence.tw/posts/hosting-high-bandwidth-web-server/images/cf-30day-bandwidth.png" alt="CloudFlare 30 Day Bandwidth" class="center" > <h2 id="維運重點">維運重點</h2> <h3 id="monitoring-先於人工巡檢">Monitoring 先於人工巡檢</h3> <p>大量網站環境不能只靠人工打開頁面檢查。比較有效的做法是把系統資源、Web server 狀態、憑證、DNS、HTTP response、error rate 與流量趨勢納入 monitoring，讓異常先變成可見訊號。</p> <p>Monitoring 的價值不只是告警，而是讓維運人員可以判斷問題是 application、network、CDN、DNS、storage，還是 upstream service 造成。</p> <h3 id="更新要可控">更新要可控</h3> <p>Hosting environment 通常會面臨兩種相反壓力：一方面要定期更新以降低 security risk，另一方面又不能讓更新破壞大量既有網站。因此更新流程必須能分批、能 rollback，並且在更新前後觀察關鍵指標。</p> <p>這類環境的維護重點，不是追求一次改很多，而是讓每次變更都能被確認影響範圍。</p> <h3 id="capacity-planning-不能只看平均值">Capacity planning 不能只看平均值</h3> <p>網站流量會有尖峰，平均值通常不夠用。除了 CPU、memory、disk I/O、network throughput，也要觀察 CDN cache hit ratio、static assets、database pressure 與 log growth。</p>