AWS Elastic Beanstalk & Devops 網站維運實戰

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代管的服務

所以內建幾項東西

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

Day03 – Elastic Beanstalk 架構說明(2)

以單Elastic Beanstalk來進行建置

通常就這個架構是偏向單純

但是如果是在系統運作上面附載高低差很大的時候

為了資源利用率最大化通常會使用

Load Balancing 與 auto scaling 的架構運行就會是必要的

在這種狀況之下除了 Load Balancing 類型的選擇之外

您還需要考慮到

1. login機制
2. Cache的共用是否有存在的必要
3. 共用資料夾的必要性
4. data存放的位置選擇

但對於開發者來說這些都是可以用程式修改來進行排除的問題

對於營運者來說還可以再更一步地考慮到既然系統的擴展之外的問題

出自於 AWS DevOps Blog 中的圖片就可以顯示出Elastic Beanstalk所具有的可行性

通常對於系統工程師來說維護附載平衡與知間的一致性就是一個很大的工程

但在於Elastic Beanstalk當中

你發現到的是著重不止於擴展這件事情上

而是服務的整合與增進服務品質之上

PS

或許有點誇大

但是在雲端與傳統IDC的建置方式中

“建置1000個同時1000人上線的服務”對比”建置1個可容納100,000的網站”

在雲端的建置方式後者的難度遠高於前者

這點對於傳統的IDC維運人員來說是比較不可思議的

因為在這些年的硬體發展中

硬體效能的成長幅度其實一直沒減慢過

而且硬體相關的解決方案一直沒有少過

但是如果再考慮成本效益的情況之下

雲端服務的效益絕對會比較好