朋友的 WordPress 網站是五年前幫他架設在 AWS EC2 上，這五年來沒有特別的維護與升級，終於（？）在今年的一月被駭客入侵，網站出現一大堆亂七八糟的帳號和色情文章。於是開始拯救與升級 legacy 架構的挑戰，此篇分享整個遷移和升級過程，大家一起來看看吧！

在設定 AWS Lambda Memory 上限時，是否只考慮實際應用所需呢？這裡有一個陷阱，AWS Lambda Memory 大小和執行實體的 Performance 有關！

AWS Lambda 的計價方式是以每 1 毫秒執行時間為基準，依照 Memory 大小進行階梯定價。因此，Memory 越大的實體，性能越高，執行時間越短，反而可能比 Memory 低的實體更有成本效益！

本篇文章分享實例數據，透過圖表分析思考過程，並提供一些策略給大家參考。

在 0元用 SBC 架設自己的 WordPress 網站 #3 速度優化 中提到使用 Cloudflare 做 cache，並安裝 WP Cloudflare Super Page Cache 外掛，讓他在發布新文章的時候自動做 preload。

但這個套件是透過 WordPress 主機所在位址對 Cloudflare 做 curl，因此 cache 並沒有發佈到全世界，於是我想到利用 AWS lambda 來實現。以下就來看看如何操作！

在開發上，很多時候我們必須為不同的環境給予不同的 configure。如果使用第三方 api，還需要設定對應的 credentials。

以往貪圖方便，通常會直接在 code base 裡面指定，或是另外給定一個 .env 檔來切換不同環境所需的變數。但這會有一個缺點，假如今天有一個設定值必須修改，因為我們把設定 hard code 的情況下，變成必須重新上一版才能解決，耗時又費工。同時如果把 credentials 也寫入檔案上 git 的話，也會有資安上的風險。

如果是使用 kubernetes 來做管理的話，可以使用它提供的 config map 和 secrets 來解決。但如果還沒導入 kubernets，有別的通用解決方案嗎？他就是今天要討論的 AWS Paremeter Store。

在 Microservices Patterns (可參考 https://microservices.io) 這本書中提到微服務間的通信可以簡單分為兩類:

1. 同步通信
2. 非同步通信

同步其實就是我們熟知的打 API，如 Restful 或 gRPC。使用起來簡單直覺，只要以前有設計過 api 的人都可以簡單上手。但主要缺點如下：

在 Kafka + Debezium 串流 DB – 原理介紹 說明整體的概念，這邊就來分享一下實戰步驟！

在「架構重整 – 使用 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 下這個命令