昨天跟之前的同事聊了一下
目前他有幫忙做一個案子
跟我目前做的系統架構類似，但是尚未分拆及優化系統
簡單的拿了現有的架構設計幫他改了一下
WEB端一樣做負載平衡 由AWS ELB 處理，SSL加密如有需求一樣由ELB做
後端兩台WEB SERVER 做 HA 備援使用，資料庫與他目前使用的相同一樣用MYSQL
資料端一樣做負載平衡 由 AWS ELB處理，差別在於只接收資料，在看程式邏輯是否做資料驗證動作與SSL加密
資料流接收後塞進SQS做序列待取，保證資料在系統端更新或異動時不會流失
由JOB機器確認資料是取出進S3做為RAWDATA，或是直接計算進MYSQL做資料顯示
HADOOP做資料的計算與分析動作，或是進行資料再利用動作，計算完成一樣進MYSQL給前端網頁做呈現
由目前得知的消息，大概做了這樣子的規劃，畢竟算是新創，沒有多大的資源做多大的架構設計，目前這樣子應該是堪用，在看系統的結構做調整
今天看到AWS AMI更新的消息
就特別去研究一下
目前整理出兩個比較常見的需求
一、同帳號轉移AMI到不同地區
如果今天服務要做到全球化的話，勢必要有不同地區有不同的伺服器
另一方面來說，也可以當作異地的備援機制
首先 EC2->AMIs
勾選AMI後點Actions
選擇Copy AMI
之後選擇要複製的地區
AMI名稱
說明
Encrypt target EBS snapshots 的選項則是加密EBS 預設通常不勾選
之後按下Copy AMI 等待完成即可
二、多帳號使用同一AMI
目前我的狀況是，我有DEV、STAGE、PROD三個帳號
但是我系統環境是同一套，原本我需要在三個帳號當中建立三個分別的AMI
這時候如果有一個AMI可以讓我共同使用就可以省下許多資源與時間
一樣先選 EC2->AMIs
勾選要共用的AMI
選擇下方的 Permissions
選EDIT
之後填入需要授權使用這個AMI的AWS帳號號碼即可
至於下方建立Volume的選項，如果只是需要共用AMI的話就不需要勾選
然後換到另一個帳號
一樣到EC2->AMIs
可以看到只有本身的帳號的AMI
選擇Private Images
可以看到剛剛共用的AMI出現了
這樣子就達成AMI共用的目的了
今天同事丟了關於PHP5的效能優化文章給我
主要講的就是 OPcache ，我大概研究了一下
嗯，這是我摸過的東西
前身就是 Zend 的 Optimizer+
大概早期有架過LAMP，或是LNMP都會摸過，用tar.gz安裝的話都要另外編譯這個
只是5.3~5.4那段時間不支援，要另外裝
5.5之後就變成OPcache內建了
主要的說明可以點這裡
至於安裝的話 不管是APACHE或NGINX都支援 在PHP5.5是內建的
詳細的安裝說明請點我
然後我無意見發現了一個小工具可以驗證OPcache的狀態
只是一個網頁，安裝後開啟這個PHP網頁會看到下圖
可以簡單確認OPcache的狀況，還滿不錯的
最近看到了一篇新消息
關於EC2的新規格
t2.nano
意思就是比t2.micro還要再小
規格則是 1 vcpu 0.5g ram
大概類似以前的 t1.micro時期的配置
費用的話如下表~
| Region | Price / Hour (On-Demand) |
Price / Month (On-Demand) |
1 Year Reserved Instance / Month |
3 Year Reserved Instance / Month |
| US East (Northern Virginia) | $0.0065 | $4.75 | $3.125 | $2.10 |
| US West (Oregon) | $0.0065 | $4.75 | $3.125 | $2.10 |
| Europe (Ireland) | $0.0070 | $5.11 | $3.42 | $2.31 |
| Asia Pacific (Tokyo) | $0.0100 | $7.30 | $5.25 | $3.44 |
| South America (Brazil) | $0.0135 | $9.85 | $5.67 | $4.17 |
當然我想不到有甚麼應用可以跑在這麼小的規格上
資料來源點我
某前公司做類似大數據的系統架構概圖
LB由LVS進行(預計，但實際上沒做)
WEB分為抓取數據資料一台
WEB網頁呈現一台
資料收集完後不採用資料庫的方式進行儲存
改由分散式儲存系統(DFS)進行儲存，使用的為MooseFS(簡稱MFS)
網路架構為同一層網段，用分散式設計進行
其中還有進行Indexs索引建立的Server，後台管理的Server，編輯用Server等
就不一一列出，需要功能配合時再增加Server
算是比較特殊的用法，不採用資料庫的大數據
中間當然遇過許多問題，從LVS模式、MFS的CHUNK格式等等
還有儲存空間的格式化問題，inode爆掉等等
就不一一說明了
系統原本採用apache+tomcat7
在進行優化時測試使用 nginx+resin
效果也不錯，但之後的更新我就不清楚了
當然這套系統還是在運作當中~
https://aws.amazon.com/tw/solutions/case-studies/unalis/
這是現職的工作當中
因採用AWS架構而申請上去的案例
其中 Unicloud 的部分，是由我規劃調整的
當然這是一套不完善的系統
正常的資料數據分析應該是由EMR之類的服務去設計
當然希望有時間的時候可以改善這部分
AWS的ELB
與正常的硬體設備不同
假使有 A 與 B 兩台Server
通常負載平衡會擇一導流
例如 User1 => A User2 => B
但AWS ELB 則是
User1 => A+B (各50%)
在公司測試SSO登入的時候就卡到這個問題
登入的資料存在A 但是LOGIN導到B，導致無限迴圈
所以要修改一下設定
修改LBCookies 設定多一個60秒
可以選擇程式的Cookie，或是ELB自己的Cookie
如果是程式的，就不用指定時間
ELB本身的話就需要設定時間
這樣子流量就可以固定導給一台server
參考資料
http://docs.aws.amazon.com/zh_cn/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html
© 2024 Kila's IT Home
Theme by Anders Norén — Up ↑
近期留言