AWS ECS 透過 CloudFormation 部署時的 Stack 更新行為

在 CloudFormation 的 Stack 被更新的時候，CloudFormation 有可能會針對要更新的資源做三種不同的處理 [1]：

1. Update with No Interruption
2. Updates with Some Interruption
3. Replacement

其中第一種是直接完成更新，不會導致資源的服務中斷；第二種會導致一段時間的資源服務中斷，但 Resource ID 不會改變；第三種是會建立新的資源然後替換舊的資源，所以有可能資源的服務不會中斷，但必然導致 Resource ID 改變。

當 CloudFormation 在更新資源的時候，會依據被更新的資源的類型，套用上述三種更新方法的其中一種。因此具體而言到底會採用哪個方法更新，必須看被更新的東西是什麼而定。除此之外，更新的行為是以 Stack Property 為單位的。舉例來說：

AWS::ECS::Cluster
    ClusterName:
        Update requires: Replacement
    Tags:
        Update requires: No interruption

在 CloudFormation 的文件 [2] 中，可以看到 ECS Cluster 如果是 ClusterName 這個屬性變更了的話，會採取的更方式是 Replacement；但如果是 Tags 的變更的話，則會採取 Update with No Interruption。

參考資料

1. AWS Documentation » AWS CloudFormation » User Guide » Working with Stacks » AWS CloudFormation Stacks Updates » Update Behaviors of Stack Resources
2. AWS Documentation » AWS CloudFormation » User Guide » Template Reference » AWS Resource and Property Types Reference
3. 1Strategy/fargate-cloudformation-example

在多節點環境將 logback 導出至 CloudWatch

在很久以前有寫了一篇文章 [1] 紀錄要如何用 logback 把 log 導出到 AWS CloudWatch，那時是用 logback.xml 直接設定，不過有個缺點是設定中指定在 logback.xml 裡的 Log Stream 的名字是個寫死的固定值，這在多節點的狀況可能會有問題。因為 CloudWatch 對於任一 Log Stream 同時只能允許一個執行緒存取，這會導致當應用程式會擴展成兩個以上的節點的時候，輸出 log 可能會有問題。

AWS VPC

AWS 的 VPC 最大只能開 /16，最小能開 /28。其中每個 Subnet 會有 5 個保留 IP 不能被使用：

• .0 是本地路由
• .1 是路由器位址
• .2 是DNS保留位址
• .3 目前沒用到的保留位址
• .255 廣播，禁止客戶使用廣播

VPC 生成時會建好一個主路由表，建議不要刪除主路由表，因為就算自己手動重建，可能其他資源的識別還是會有問題。

當 Resource 放在 Security Group 裡的時候，Resource 送出的所有封包都會先出 Security Group、尋找目標 Resource、再進目標的 Security Group。所以即使兩個 Resource 放在相同的 Security Group 內，預設也是無法互相存取的，必須要在 Security Group 內設定允許自己存取自己。

在 AWS Lambda 執行 web3.py

這篇要紀錄想要在 AWS Lambda 上執行 web3.py 之前需要先做的準備。因為 web3.py 用了一些 C/C++ 編譯的函式庫，因此必須要事先準備好能夠在 AWS Lambda 上執行的編譯後結果。主要步驟也可以參考 [2-3]。

(書籤) Serverless & AWS Fargate

參考資料

1. fargate-java-sample

(書籤) API Gateway + Lambda 處理 multipart/form-data

參考資料

1. myshenin/aws-lambda-multipart-parser
2. API Gateway support multipart?
3. 如何用 AWS API Gateway 和 Lambda 上傳和下載檔案 -- Part 1

(書籤) 在 AWS Lambda 上使用 Spring Boot

參考資料

1. Quick start Spring Boot
2. rob-baily/aws-lambda-spring

透過 Spring Data JPA 存取 DynamoDB

因為 Spring Data JPA 用來存取資料庫時很方便，然後 DynamoDB 又是屬於特別囉唆的東西，所以之前在研究 Spring Boot 時，就在想不知道 Spring 是否有支援 DynamoDB 的實作。很幸運地，社群真的有人做了 Spring Data JPA + DynamoDB [1-2] 造福大家！XD

AWS DynamoDB SDK v2 基礎使用（四）：讀取資料

在 DynamoDB 中，讀取被分成 Query 和 Scan 兩種行為
兩種行為的差異，主要來自於存取的範圍是否侷限於同一個 Partition。
這其實在之前（好久以前了呀….XD）的文章中有提到過，概念上可以當成一個 Partition 就是一台主機
在寫入資料時，作為 Partition Key 的值會決定資料會被存放在哪一台主機。
而讀取資料時，使用 Query 是在特定一台主機上讀取資料，而使用 Scan 則會在所有主機上讀取資料。

Logback 輸出 Log 到 CloudWatch

本來沒有特別使用 CloudWatch 的習慣
不過應用程式放在 VM 裡，如果不控管的話，Log 總有一天會把 VM 硬碟塞爆
而如果去設定控制大小，則又會有關鍵 Log 可能被洗掉的問題。
剛好最近寫不少 AWS Lambda 的程式，覺得 Log 丟去 CloudWatch 其實也還蠻方便的 XD
就找了一下該怎麼做這件事。

(暫存) 在 AWS Lambda 上使用 LXML

參考資料

1. AWS Lambda not importing LXML

AWS DynamoDB SDK v2 基礎使用（三）：寫入資料

DynamoDB 不得不說，其實表達的格式相當囉唆～
所以想要存取 DynamoDB，無論如何程式碼都會寫得有點冗長。
而其中因為 Java 又是格式嚴謹的語言，於是又比別的語言再更囉唆一些……。

在 AWS Lambda 的 Python 程式匯入額外的套件

AWS Lambda 的執行環境有預設匯入的套件
如果使用了其他的套件，Python 程式就會拋出找不到套件的錯誤。

從 AWS 的官方文件 [1] 中，可以看出關於這個問題的解決方法
就是事先把套件裝進程式裡，當成是程式自身的一部分，一起打包送進 AWS Lambda。

具體來說，也就是假設我的 Python 程式的資料夾是放在 D:\python\my_project
則可以使用以下的指令，把套件指定安裝到專案資料夾中。

pip install requests -t D:\python\my_project

而做完後，就會看到專案資料夾跑出一大堆資料夾和檔案
之後要上傳到 AWS Lambda 時，把整個資料夾（也就是 D:\python\mu_project\* ）壓縮成 zip
一起上傳到 AWS Lambda 即可。

參考資料

1. Creating a Deployment Package (Python)

AWS SDK v2 疑似是 BUG 的 exclusiveStartKey？

這只是快速先紀錄一下目前遇到的狀況，但還沒有嚴謹地確認是不是其他邏輯造成的…..。

AWS DynamoDB SDK v2 基礎使用（二）：基礎開發環境建置

因為今年 AWS 推出了第二版的 AWS SDK [1]，所以就來紀錄 AWS SDK v2 吧。

在用過第一版的 SDK 以後，其實覺得第二版的 SDK 寫得比較易用，而且還支援 Java Stream API。
不過實務上 AWS SDK v2 的文件 [2-3] 目前相當地不完整，而且網路上也沒太多資料
所以有很多情況是必須依靠第一版的經驗、Javadoc 跟 IDE 的提示來猜測使用方法…。

AWS CloudWatch Filter

CloudWatch 的 Filter 功能，主要的目的好像是用來觀察指定的事件在某個時間區段中的發生狀況
所以總歸來說，適用在想要把結果劃成折線圖那種的狀況。

例如 AWS 官網給的範例 [2]，都是屬於建立 Filter 去偵測某個特定樣式的 log 是否出現
出現的話，在 Metric 上會反應出「事件出現次數 +1」
然後最後在 CloudWatch 的 Metrics 那邊，就能夠以折線圖的形式，看到例如每分鐘這個事件的發生狀況。

參考資料

1. 淺談系統監控與 AWS CloudWatch 的應用
2. Creating Metric Filters

在 Java 中把 AWS DynamoDB 的紀錄轉成 JSON

DynamoDB 上的紀錄，都會有像是 {“S”: “XXX”} 之類的格式，用以表示它在 DynamoDB 裡的型態
不過程式在處理時，這樣很麻煩～。

實務上，AWS SDK 裡提供了一些方法，可以幫我們去掉那些多餘的東西。
具體來說，例如以下的程式碼：

ScanRequest scan = new ScanRequest();
ScanResult result = dynamodbClient.scan(scan);

Gson gson = new GsonBuilder().build();

for (Map item : result.getItems()) {
    JsonElement json = gson.toJsonTree(InternalUtils.toSimpleMapValue(item));
}

上述的程式碼，是假設對一個 DynamoDB 的表格做 scan 操作
操作完以後，要把 scan 出來的結果，用 GSON 轉成 JsonElement 的型態。
這裡透過 com.amazonaws.services.dynamodbv2.document.internal.InternalUtils 這個套件
就能夠去掉欄位型態這個東西，讓結果成為單純的 JSON。

參考資料

1. DynamoDB - Object to AttributeValue

AWS Lambda 呼叫另一個 AWS Lambda

一般來說，Lambda 都是透過中介服務去觸發的
例如透過 DynamoDB Stream、SNS、Kinesis、S3 等等的
當這些服務發生變更時，發送訊息觸發 Lambda。

不過實務上，Lambda 本身只要具備 Invoke 權限，就能夠直接透過 AWS 的 Lambda API 去觸發另一個 Lambda。

AWS SNS 的 Delivery Policy

在使用 SNS 時，需要考慮如果接收端處理 message 失敗了該怎麼辦？
如果沒有做特殊的設定，預設 SNS 是會直接走 Backoff Phase，重試三次、每次延遲 20 秒。

不過如果想要更多一點的重試，或者想設定比較複雜的行為，就需要稍微了解一下 SNS 的 Delivery Policy。

透過 AWS Lambda 開發 Serverless Framework（三）：使 Lambda 函式擁有 Internet 存取權

Lambda 函式在部署的時候，預設是不會帶有任何網路設定的
因此我們沒辦法知道 Lambda 實際的 IP 位址等等的資訊。
在一些單純的程式中，這可能沒什麼
但如果是在系統的 pipeline 裡，Lambda 需要去存取其他非公開服務時，可能就會有問題了。