2019ironman 10th – Cloud Native – Day02 – Elastic Beanstalk 架構說明(1)

分享

2019 ITHOME 鐵人賽-AWS Elastic Beanstalk & Devops 網站維運實戰

Day02 - Elastic Beanstalk 架構說明(1)

Elastic Beanstalk

這個服務最小的規模就是一台EC2作為Web Server

由於他是AWS代管的服務

所以內建幾項東西

  1. 程式版本控管
  2. auto scaling 的可行性
  3. 多種程式語言的支援
  4. 監控機制的整合
  5. devops的可行性

但是他不包含(需要使用.ebextensions以YAML或JSON來客製化)

  1. 多站點的設定(VirtualHost)
  2. 共享資料夾的設定(NFS或SMB)

如果是初期的Web開發

可以再加上一台RDS來組合成Web+db的架構

在這個架構當中如果未來需要直接轉換成正式環境

正式環境如果需要使用auto scaling與Load Balancing

要注意你要使用的是哪種Load Balancing

Load Balancing如果一開始沒有選定類型

在未來產生Load Balancing的時候只有Classic Load Balancer一種選擇

Classic Load Balancer 不具有 Application Load Balancer 的兩大特性

  1. Stickiness
  2. WAF附加的可行性

所以說如果需要用到這兩個特性

在第一次建置時不要直接Create application

而是進到Configure more options

直接將Capacity改成Load Balancer

並進到Load Balancer將類型改成Application Load Balancer

全篇好讀版

Read more

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

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

By Albert Yu