[AWS note] Batch 使用心得｜開發筆記
以一個有很多子任務的 backup cronjob 使用情境為例
這篇文章主要介紹 AWS Batch 服務實際使用遇到的疑難雜症，如何開始使用 Batch 請參照官方教學。
情境
之前有一個 backup Elasticsearch 的定時任務 (cronjob)，因為商業上決策結果這個 based on Elasticsearch 的服務想要做架構改造，因此希望這個「暫時的」cronjob 不要跑在要自己做 management 的機器上。所以想在 aws 服務尋找 solution。簡單來說，想要一個有 Airflow 的機制，但不用自己 maintain 一台 Airflow 這樣。（提醒：不是每個任務都能直接從 Airflow 轉換，需考量所需的情境有沒有只有 Airflow 才做得到的特性）
需求與實作
這次的 backup 任務包含了幾個子任務如下：
- 使用 elasticdump 做備份，上傳檔案到 S3（這部分也有一些小眉角，會在後面段落補充）
- 用 aws cli 呼叫 Athena 服務將 S3 檔案註冊成 table、做資料預處理之後轉成需要的形式，同時輸出 parquet files
其實第 2 步驟在實作上必須拆成好幾個步驟，因為有 2 個 table 做預處理後要 insert 到最後的大表，所以總共變成十個上下的步驟，都是要等前一步做完在做。簡單流程圖如下 ：
圖中我們可以看到 Cloudwatch 會定時去叫 Lambda 發出 Batch job 到 queue 裡，Lambda 就可以功成身退繼續睡，因此不會碰到 Lambda 的時間限制。一開始是兩個 elasticdump 的 job，會把資料上傳至 S3。dump 完各自接著 drop and create external table，等兩邊的 table 都建立好之後，再 drop and create ETL 用的 view，解決一些格式問題。最後將整理好的資料 insert 到最終產出的大表（同時因為 Athena 的機制會產出 parquet file 到 S3）。
上面橘色很多點跟線的 icon 就是 Batch，下面我們來看 Batch 的組成及優缺點。
Batch 的組成
Batch 基本上由 job, job definition, job queue, compute environment 這幾種積木去組，將 job 丟到 job queue 中在指定的 compute environment 跑，而 job 可以從 job definition 產出，並且每個 job 可以指定要等待哪些 job 跑完才開始執行。而 Batch 的 job 是起 docker container instance 去做事情，例如像我們這邊要用到 aws cli 讓 Athena 執行 query，可以使用官方的 cli image。Job definition, job queue 和 compute environment 這些設定完之後，主要都在 job 那個分頁活動。
Batch 的優缺點
- 優點：不用實際 host 一台 master 機器而是每次任務需要再由服務幫忙起 worker。
- 缺點：懷疑人生的介面。像是在開發的時候 job definition 每開一個 revision，設定好的 parameter 跟 command 都會全清空。監測的時候 job 狀態的頁面有時候會看不到東西，沒有 success 也沒有 fail，但在 Cloudwatch log 是可以找到的。並且在一連串的 dependent 任務放下去之後還要在不同狀態中追著 job 們跑超級崩潰。
補充
- 上傳到 S3 的小眉角：S3 有檔案的 partition 限制，也就是不能有太大的檔案，系統會幫你切成太多份。可以用 elasticdump 的檔案大小限制功能，再配合壓縮指令。
- 設定 job definition 使用 memory 的上限必須留點位置給系統，不然會一直找不到合適的機器，並且沒有明顯的介面提示， job 只會一直停在 starting 狀態。
- 如果 job 一直停留在 starting 狀態，沒有進到 running，那可能要去看下 EC2 裡的 Auto Scaling Groups，找到 Compute Environments 名稱對應的 Activity History，看有沒有起 instance。
- Batch 送出 Athena task 成功，不代表 Athena 執行成功。可以透過最後產出的 table or S3 files 來確認。Log 的部分，可以從 job 裡的 log 連結，導去 Cloudwatch 看到 Athena 的任務 id，再去 Athena 查看結果。
心得
這是第一次從無到有去研究沒用過的 aws 服務並實作一整套的 backup 流程。到了 Gogolook 之後開始碰 aws 的各種服務，覺得每一次用一個新的工具就很像玩一套桌遊，先了解一下遊戲規則，然後實驗一下想法（順便適應一下 console UI），再順著工具給的積木組出結果，非常有趣。雖然這邊只給出了一些簡單的概念，好像很快速可以建立 Batch 實作，但實際上的參數調整（memory, vcpu, file size 等等）占了最多時間。尤其是要等 auto scaling group 起機器的時間不確定性，讓開發時間有點難掌握。
轉眼到 Gogolook 的 server team 滿一年了，覺得這邊真的是非常鼓勵各種想法討論的地方，也都可以實現，非常難能可貴的環境。在公司內遇到很多強者大神們，不管在後端專業技能上或是拆解工作這樣的軟技能上都有典範可以學習！目前公司正釋出多種職缺，歡迎至官網搜尋職缺 https://global.whoscall.com/zh-TW/careers/joblist/ 或是將履歷寄至人資 Jennifer 的信箱 jennifer.chuang@gogolook.com。（如果有內推，不要忘記寫推薦人喲！有推薦費的～）
這次文章（加工商）就到這邊，喜歡的話請幫拍拍（？）＋訂閱，有使用 Batch 的其他心得或是小技巧也歡迎留言喲！
參考資料
- AWS Batch 官方教學：https://aws.amazon.com/tw/blogs/compute/creating-a-simple-fetch-and-run-aws-batch-job/
- aws cli docker image: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html
- elasticdump: https://github.com/elasticsearch-dump/elasticsearch-dump
- 流程圖使用 diagram 套件繪製：https://diagrams.mingrammer.com/
- Gogolook 職缺：https://global.whoscall.com/zh-TW/careers/joblist/
