到了預計 cutover 當天晚上，我和 C 已經在線上等待預計維護的時間來臨。

「59分了，直接開始吧！」我在 slack 上和 C 說。
「go！」

於是我執行已經預寫好的Python script，他會使用 boto3 直接對我們的兩台 EC2，web server 和 database server 換上我特別設定好的 security group，擋住外部 80 和 443 連入 web server，以及內部 5432 連入 database server，只讓 dms 和我下指令用的 EC2 能連入。

維運時，如果能將四散的 log 集中到一個地方存放，要抓錯的時候就會非常方便，甚至可以透過分析內容來發出警報或是研究趨勢！

市面上有很多集中 log 的服務平台，或是也可以自己架設 ELK (elasticsearch logstash kibana) 來實現。由於目前工作上使用 AWS，以省時為由，就先選用了 AWS 提供的 CloudWatch logs 服務，這邊分享其中的設定方法！

把 RI 的 task 暫停後，果然客戶端就可以正常使用了，看來的確是 DMS 的關係。但是看 db 的 cpu，其實也只比平常多個 10% 左右，怎麼會有這麼大的影響呢？（後來才理解，瓶頸應該是出現在與 ebs 溝通的 throughput，但當時不清楚是這個原因）百思不得其解的我，只好把 task 的一些效能參數調小試試。

調小後果然就沒有收到抱怨了，但 task 狀態卻剛好轉 error，原來有幾張表沒有 primary key，所以無法搬移。

「竟然會有表沒有 pk？這不是基本的嗎？」我表示大傻眼，只好修改 task，略過這些奇怪的表。

但一啟動，立馬就跳紅字，似乎是找不到之前的中斷點了，奇怪，記得文件說暫停後可以繼續，怎麼會這樣？

基本的 Armbian 系統和 WordPress 架設完畢後，下一步要架設 nginx 處理對外的 https 連線。

因為我們的目標是零元架設，所以採用免費的 ssl 簽證，效期只有三個月，需要額外使用 cronjob trigger script 來自動更換簽證。

此外，防火牆也是很重要的設定，我們使用 ufw 來設定連入規則，避免 ssh 被不肖人士暴力嘗試。那就讓我們開始吧！

一般人架設 WordPress 會買虛擬主機來架設，一方面簡單，一方面不需要自己管理機器，只要專注在內容上。我之前幫朋友或案主架設，會傾向使用 AWS EC2 來建立，因為效能較好，若有需要還能搭配 RDS 和 S3 、 CloudFront 來做優化，可靠性也比虛擬主機高。但這次架設自己的 WordPress ，我打算挑戰使用 SBC ，看看能不能在最低的成本下，建立起可用的網站。

需注意的是，使用這個方法建立需要相當熟悉 linux 與 WordPress 、Docker，初學者還是建議使用虛擬主機比較不會有問題哦！

架構重整系列分享在工作上遇到的棘手架構案例。希望讓同樣面對這些問題的人也能從中得到一些靈感來處理！

先簡單列一下這個案例的狀況：

1. 原始碼部分：

code base 已經發展五、六年，使用 twistd 框架架設出來的單塊系統，所有的應用 backend 都塞在同一份 code base 裡面，而且還在使用 python2！開發上沒有分層設計，底層 db 的 orm instance 直接暴露到表現層上，不同應用會使用到相同的表，甚至前後端沒有分離，互相沾黏非常嚴重。

這邊整理我在使用 AWS Data Migration Service （簡稱DMS）一路採坑後整理出來的筆記，希望對也是在水深火熱的人有幫助！

以下結構主要拆成兩部分，一部分是對原先的 database 做設定（這邊使用的是 PostgreSql），另一部分是對 DMS。先後順序沒有一定，只要最終 DMS 能連線進去 database 並啟動 task 即可！