ECS Scheduled Task 上の定期実行バッチを ecschedule で GitOps 化した話 / A story about a scheduled execution batch on the ECS Scheduled Task converted to GitOps with ecschedule

KGDC Tech Conference #0 通信インフラだけじゃないKDDIグループの多彩な技術 ( https://kgdc.connpass.com/event/203487/ ) で登壇の際に使った資料です。

資料内のリンク:
* ECS Scheduled Taskの管理をecscheduleでGitOps化しました - コネヒト開発者ブログ - https://tech.connehito.com/entry/2021/03/01/155041
* タスクのスケジューリング (cron) - Amazon ECS: https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/scheduled_tasks.html
* AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化/ Container service of batch execution environment realized by AWS service - Speaker Deck: https://speakerdeck.com/shoichiron/container-service-of-batch-execution-environment-realized-by-aws-service
* Songmu/ecschedule: https://github.com/Songmu/ecschedule
* ansible-collections/community.aws: https://github.com/ansible-collections/community.aws

Transcript

1. ECS Scheduled Task 上の定期実行バッチを ecschedule で GitOps 化した話 2021.03.17 KGDC Tech Conference #0 通信インフラだけじゃないKDDIグループの多彩な技術 Kei IWASAKI (@laugh_k)
2. お前誰よ Kei IWASAKI Twitter: @laugh_k Github: @laughk コネヒトのインフラエンジニア 最近はTerraformとよく戯れています
3. https://connehito.com/
5. 本日のお話 ECS Scheduled Task を利用して動く定 期実行バッチの運用を ecschedule で GitOps 化することにより改善した話で す 先日のテックブログにも記事があるの であわせご覧ください
6. ECS Scheduled Task とは
7. ECS Scheduled Task とは Amazon ECS は、cron のようなスケジュール、または CloudWatch イベ ント に応答してタスクをスケジュールする機能をサポートしています。 この機能は、Fargate および EC2 の両方の起動タイプを使用する Amazon ECS タスクでサポートされています。 from: タスクのスケジューリング (cron) - Amazon ECS "
8. ECS Scheduled Task とは 簡単に言えば EventBridge を組み合わせてECSタスクをCronのように実行できるサービス Amazon ECS は、cron のようなスケジュール、または CloudWatch イベ ント に応答してタスクをスケジュールする機能をサポートしています。 この機能は、Fargate および EC2 の両方の起動タイプを使用する Amazon ECS タスクでサポートされています。 from: タスクのスケジューリング (cron) - Amazon ECS "
9. ECS Scheduled Task はとても便利 定期実行バッチ処理のコンテナ化ができる cron実行するような定期実行バッチをほぼサーバレスで動かすことができる 専用バッチサーバは不要 ECS 運用の資産(Dockerイメージ、Task定義など)を生かせる Dockerレイヤキャッシュを使うことでスケジュール通りのバッチ実行が可能 Fargateを使えば完全にサーバレス化することもできる など
10. ECS Scheduled Task のコネヒトの以前の利用状況 1つのバッチに対し、1つのECSタスク定義を用意 ECSタスク定義はTerraformで管理をし、バッチ追加の際は開発者がPRを出す運用 PRをインフラエンジニアがレビューし、OKなら terraform apply スケジューリングについては特にコード管理せず、手動適用
11. ECS Scheduled Task のコネヒトの以前の利用状況
12. 参考資料 AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化/ Container service of batch execution environment realized by AWS service - Speaker Deck
13. ECS Scheduled Task はとても便利 AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化/ Container service of batch execution environment realized by AWS service - Speaker Deck
14. ただし、運用し続けると問題は出てくる
15. コネヒトの運用で陥っていた状態 EventBridgeルールは手作業で追加・変更なので作業の属人化は結局発生 1つのバッチに対して1つのタスク定義を用意する運用は、数が少ないうちはよかっ たがバッチの数が増え運用がきつくなってきた
16. コネヒトの運用で陥っていた状態
17. Terraformのコードも無駄に肥大化 利用しているDockerイメージは同一なのにcommand と環境変数の微妙な違いによるコピペコードが量産さ れていた 気が付いたらtfファイルが1564行まで膨れてしまった クラスタも
18. バッチを動かすためにマネージドサービスを便利に 使えてはいるが、運用はしんどい
19. バッチ運用を楽にするための 改善プロジェクトを開始
20. バッチ運用を楽にするための改善プロジェクトを開始 コピペコードの量産に、変更の適用フローが属人的で開発者体験は良くはなかった @laugh_k が入社したばかりで着手しやすい状況だったこともおおきい
21. 目指したところ 開発者でもわかりやすく、直接扱いやすい仕組みにしたい バッチの追加・更新の際は属人的でなく、極力開発者の裁量でできるようにしたい
22. 改善方針 バッチ一つにつき一つのタスク定義を用意する方法をやめ、バッチ共通のタスク定 義を一つ用意して使う タスク定義ではなく、イベントルールを管理する 手作業はできるだけ排除したい
23. こうしたいイメージ
24. タスク定義は1つなので特別なツールは使わない
25. ここをどうするか？
26. EventBridgeルール管理の技術選定 次の二つが候補に上がる Songmu/ecschedule ansible-collections/community.aws (AnsibleのAWSモジュール)
27. Ansible (AWSモジュール) vs ecschedule
28. Ansible (AWSモジュール) 構成管理ツールとしての実績は間違いなし ContainerOverrideはJSON文字列で渡す必 要がある タスクの単発実行には対応してない など
29. ecschedule ワンバイナリで環境がそろう ECS Scheduled Task 特化なので余計な機能 がない タスクの単発実行に対応 ContainerOverrideも含めて一気通貫YAML で書ける など
30. 比較した結果 ecschedule を選択 EventBridgeルールをよりシンプルに管理できる タスクの単発実行ができるのも嬉しい 一気通貫でYAMLで管理できるのもよい Ansibleは社内で特に使われていなかったのも大きい
31. 対応方針を整理
32. 決まった方針 1. ecscheduleでEventBrideのルールを管理する 2. タスク定義の管理を簡略化するための構成変更 1. タスク定義はawscliで適用可能なJSONを用意する 2. バッチで利用しているタスク定義を切り替える
33. ecscheduleでEventBrideのルールを管理する
34. ecschedule の導入
35. ecschedule の導入 とりあえず導入するのはdump機能があるのでとても簡単 $ ecschedule dump \ > --cluster clusterName1 \ > --region ap-northeast-1 > event-rule.yaml
36. ecschedule の導入は
37. コネヒトではバッチ用クラスタが三つあり、 dev環境とprd環境があるので実際には次のようなファイル構成に . |-- cluster1/ | |-- dev-events-rules.yaml | |-- prd-events-rules.yaml |-- cluster2/ | |-- dev-events-rules.yaml | |-- prd-events-rules.yaml `-- cluster3/ |-- dev-events-rules.yaml `-- prd-events-rules.yaml
38. タスク定義の管理を簡略化するための構成変更
39. タスク定義の管理を簡略化するための構成変更
40. タスク定義の管理を簡略化するための構成変更
41. 共通のタスク定義は愚直にJSONを 用意 管理するタスク定義はバッチ用ECSクラスタあたり 1つ ※ Dockerイメージもreleaseタグを参照しているので、 更新する頻度は少ない ※ FargateとEC2を利用している環境の場合は2つ必要
42. バッチ管理のためのファイル構成は次のように `-- cluster1/ |-- dev-events-rules.yaml |-- dev-task-definition.json ← 追加 |-- prd-events-rules.yaml `-- prd-task-definition.json ← 追加 長くなるので一つのクラスタだけ抜粋
43. バッチ管理のためのファイル構成は次のように (Fargate併用版) `-- cluster3/ |-- dev-events-rules.yaml |-- dev-task-definition-ec2.json ← 追加 |-- dev-task-definition-fargate.json ← 追加 |-- prd-events-rules.yaml |-- prd-task-definition-ec2.json ← 追加 `-- prd-task-definition-fargate.json ← 追加 長くなるので一つのクラスタだけ抜粋
44. タスク定義の管理を簡略化するための構成変更
45. タスク定義の管理を簡略化するための構成変更
46. バッチで利用する タスク定義の切り替え ecschedule管理のYAMLを編集 適用は ecschedule apply で
47. $ ecschedule apply -conf cluster1/dev-event-rule.yaml -all
48. タスク定義の共通化ができ、Terraform管理から解放
50. ecschedule (YAML) のみでバッチの更新・追加がで きるように 基本的にEventBridgeルールだけを考えればよくなった タスク定義のTerraformに比べてコード量も大幅に削減 (1564行から335行) 手作業ではなく、コードの内容がそのまま適用されるようになった
51. ただし、まだ課題は残る
53. １コマンドで終わるとはいえ、手作業は残っている 適用する人が属人化してる状況はかわらない 今はコロナ渦のフルリモート業務、新たな手動オペレーションは結構リスキー せっかくPRベースで追加・更新ができるようになったものの、適用のタイミングは 調整する必要がある
55. ここでもう一押し対応
56. GitHub Actions による自動化
57. GitHub Actions による自動化のためにやったこと 必要なコマンドのmakeタスク化 GtiHub Actions用の設定YAMLを準備 mainブランチにレビューなしのコードが入らないように READMEを整え全体周知
58. 自動化にあたって必要な コマンドをmakeタスク化 設定YAMLに直接ベタ書きしてもいいが、手動で も簡単にCI上のオペレーションを再現できたほ うが便利 GitHub Actions上でも手動でも make apply-all すればOKな状態に
59. 用意したmakeタスクを活用す る形でGitHub Actionsで自動 Apply AWS向けのsecretsをリポジトリに設定 公式ドキュメントに従いYAMLを準備 mainブランチの内容は常にすべてapplyする
60. ブランチの設定も変更 mainブランチにレビューしていないコードが入らないように
61. GitHub上でバッチ追加・更新が完結するように！ 1. YAMLを編集し、PRを出す 2. インフラエンジニアがレビューし、Approveする 3. マージする 以上で
62. READMEを整備 バッチ追加に必要な流れをドキュメント化 いくら仕組みを用意しても 安心して使ってもらえないと意味がない
63. 最後は全体周知
64. こうしたいイメージが現実に！
66. 導入後の話
67. 通常のバッチ追加・更新は晴れてGitOps化が実現 開発者の裁量でバッチの適用までできるように
68. 安全な計画停止の実現(GitOps化以前) 以前は停止に伴う影響を調べスプレッドシートにまとめていた
69. 安全な計画停止の実現(GitOps化以前) 停止の際は秘伝のシェルスクリプトを実行していた (@shnagai のPCより発掘)
70. 安全な計画停止の実現(GitOps化後) 計画停止の内容もPRで共有できる
71. PRベースでバッチ停止に関する相談もできる
72. 停止も再開も安全に実施できる 停止時 $ git switch maintenance-20210128 $ make apply-all 再開時 $ git switch main $ make apply-all
73. もちろん問題がないわけではない ecscheduleはバッチの削除には対応していないので、削除は手動対応が必要 YAMLのタスク名に重複がある場合に意図しない適用のされ方をする など
74. 必要に応じてYAML内容のチェックを入れたり、 時には ecschedule 自体へのフィードバックを 行うことで対応していきます
75. ご清聴ありがとうございました https://connehito.com/recruit/ We are hiring!!