在「架構重整 – 使用 Route 53」中有提到，為了將案例中的主要網域 xxxx.com 轉址到 www.xxxx.com，我採用了 CloudFront 的方式來實現。主要是不想另外再用一個 nginx 負責轉址（需要額外的設定與維護），傾向使用 AWS 原生服務來完成，減少管理的資源。實現的方式也很簡單，只需要一個 S3 bucket，前面掛上 CloudFront，並到 Route 53 做對應設置即可。同時也使用 AWS 提供的 SSL 簽證，再也不用花冤望錢繳保護費了！

在「架構重整 – 使用 ELB 與 Docker」中，已經完整描述我如何從 legacy sysytem 轉移至使用 Docker 和 ELB 來建立可用性高的系統架構，但其中沒有提到 Route 53 的設定，因此這邊詳細補充說明一下如何設定 Route 53，以及為何要使用 Route 53。

Route 53 也是 AWS 服務之一，他其實就是 DNS (Doman Name System），可能有人會好奇說，如果是在 Godaddy 等網域公司購買網域，都會附上免費的 DNS 服務，為何需要轉移到 AWS 上面？

完成 DB migrate to RDS 後，現在的挑戰是要逐步拆解掉舊的 api server。這邊我們將會使用 docker 包裝原來的單塊系統 code base，並搭配 aws 的 ELB (Elastic Load Balancer) 中的 ALB (Application Load Balancer)。先讓我們來了解一下修改前的架構。

於是我回到座位，開始實驗用 PostgreSQL 原生工具讓兩台 db 做對拷。首先需要設定防火牆，讓 slave db 可以直接連到 target RDS 的 5432，使用者帳號也需要先在 RDS 中設定好，接下來連入 slave db EC2，在 console 下這個命令

到了預計 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 能連入。

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

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

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

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

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

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

1. 原始碼部分：

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