Day01 我眼中的EB(Elastic Beanstalk)
Beanstalk 看到這個字通常都會很納悶
魔豆? 這是啥鬼東西
但是這名字的由來是由童話傑克與魔豆(Jack and the Beanstalk)
取這個名字的人因該是個童話迷
但同樣的也反映了這個產品的特性
只需要簡單的種植就可以長成巨大且巨量的服務
如果對他有很多疑惑
從各個面向都有不同的理解方式
系統工程師：
減低網站與API底層環境建置時間的工具
程式設計師：
只要會上傳程式碼就可以部署出高可用性的環境
自動化佈署的高手：
AWS版的Ansible
雲端初學者：
他就是 EC2、RDS、Code*、X-Ray 等等等的組合
當然各種面向都有些片面
但是這個工具對於許多的建置專案來說
他的確是可以減少大量的部屬時間
不需設計複雜的擴展機制
不需反覆進行擴展測試與監控調教
只需要注意一點
EB的主體是 Stateless Service (無狀態伺服器)
程式的任何儲存行為絕不可以存放在本機
這其實也是自動擴展的網站所需的基礎
掌握了這個原則基本上我們就可以開始進行Elastic Beanstalk的建置
Day02 - Elastic Beanstalk 架構說明(1)
Elastic Beanstalk
這個服務最小的規模就是一台EC2作為Web Server
由於他是AWS代管的服務
所以內建幾項東西
- 程式版本控管
- auto scaling 的可行性
- 多種程式語言的支援
- 監控機制的整合
- devops的可行性
但是他不包含(需要使用.ebextensions以YAML或JSON來客製化)
- 多站點的設定(VirtualHost)
- 共享資料夾的設定(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 的兩大特性
- Stickiness
- WAF附加的可行性
所以說如果需要用到這兩個特性
在第一次建置時不要直接Create application
而是進到Configure more options
直接將Capacity改成Load Balancer
並進到Load Balancer將類型改成Application Load Balancer
Day03 - Elastic Beanstalk 架構說明(2)
以單Elastic Beanstalk來進行建置
通常就這個架構是偏向單純
但是如果是在系統運作上面附載高低差很大的時候
為了資源利用率最大化通常會使用
Load Balancing 與 auto scaling 的架構運行就會是必要的
在這種狀況之下除了 Load Balancing 類型的選擇之外
您還需要考慮到
- login機制
- Cache的共用是否有存在的必要
- 共用資料夾的必要性
- data存放的位置選擇
但對於開發者來說這些都是可以用程式修改來進行排除的問題
對於營運者來說還可以再更一步地考慮到既然系統的擴展之外的問題
出自於 AWS DevOps Blog 中的圖片就可以顯示出Elastic Beanstalk所具有的可行性
通常對於系統工程師來說維護附載平衡與知間的一致性就是一個很大的工程
但在於Elastic Beanstalk當中
你發現到的是著重不止於擴展這件事情上
而是服務的整合與增進服務品質之上
PS
或許有點誇大
但是在雲端與傳統IDC的建置方式中
"建置1000個同時1000人上線的服務"對比"建置1個可容納100,000的網站"
在雲端的建置方式後者的難度遠高於前者
這點對於傳統的IDC維運人員來說是比較不可思議的
因為在這些年的硬體發展中
硬體效能的成長幅度其實一直沒減慢過
而且硬體相關的解決方案一直沒有少過
但是如果再考慮成本效益的情況之下
雲端服務的效益絕對會比較好