2019ironman 10th – Cloud Native – Day08 – Elastic Beanstalk 操作說明(5)

分享

Day08 - Elastic Beanstalk 操作說明(5)

11

談到了程式碼的上傳就不得不先優先提到 Rolling updates and deployments (滾動環境資訊更新) ,這個功能關係到了您網站在更新時是否會影響USER的使用!

一般來說更新程式的狀況是需要停機的

但是這個狀況在雲端的狀況已經變了

既然我隨時可以要到更多的主機

那何不直接將主機整個更新好之後將舊主機直接替換下來

這樣我的使用者幾乎不會感受到影響

點選 Rolling updates and deployments 下方的 Modify進入編輯畫面

Rolling updates and deployments 說明連結

重點在於 Rolling Updates(滾動更新) 與 Rolling Deployments(滾動部署)兩個的差異

滾動更新指的是在N台以上的主機時每次抽取1~N台來更新

滾動部署則是新安裝好之後將救的主機替換掉

如何更新就取決於對效能的附載多少

如果是7*24的高附載建議是以滾動部署為主

Rolling updates and deployments (滾動環境資訊更新) 這功能是因該最優先啟動的

Read more

雲端架構延遲問題:為什麼AP與DB不能放太遠?

雲端與地端的架構差異認知不足導致的性能陷阱 前言 許多企業在上雲初期,經常基於成本考量或錯誤認知,將應用程式伺服器(AP)與資料庫(DB)部署在不同區域。這種做法在地端環境中影響較小,但在雲端環境中卻會造成嚴重的性能問題。本文透過台北-東京的實際案例,說明距離對雲端架構的致命影響。 核心問題: * 地端思維:同個機房內不同區域延遲可忽略 * 雲端現實:跨區域延遲可達數十毫秒 * 結果:連線建立時間從毫秒級暴增到秒級 1. 地端 vs 雲端的延遲差異 1.1 地端環境的延遲特性 傳統地端機房: 同機房不同機櫃:RTT < 1ms 同城市不同機房:RTT < 5ms 同國家不同城市:RTT < 20ms 地端架構師的經驗: * AP和DB分別放在不同機櫃:幾乎無延遲影響 * 災備機房放在不同城市:RTT約10-15ms,可接受 * 習慣性認為「網路延遲不是問題」

By Albert Yu