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)
   

   View Slide

2. お前誰よ
   Kei IWASAKI
   Twitter: @laugh_k
   Github: @laughk
   コネヒトのインフラエンジニア
   最近はTerraformとよく戯れています
   

   View Slide

3. https://connehito.com/
   

   View Slide

4. View Slide

5. 本日のお話
   ECS Scheduled Task を利用して動く定
   期実行バッチの運用を ecschedule で
   GitOps 化することにより改善した話で
   す
   先日のテックブログにも記事があるの
   であわせご覧ください
   

   View Slide

6. ECS Scheduled Task とは
   

   View Slide

7. ECS Scheduled Task とは
   Amazon ECS は、cron のようなスケジュール、または CloudWatch イベ
   ント に応答してタスクをスケジュールする機能をサポートしています。
   この機能は、Fargate および EC2 の両方の起動タイプを使用する
   Amazon ECS タスクでサポートされています。
   from: タスクのスケジューリング (cron) - Amazon ECS
   "
   

   View Slide

8. ECS Scheduled Task とは
   簡単に言えば
   EventBridge を組み合わせてECSタスクをCronのように実行できるサービス
   Amazon ECS は、cron のようなスケジュール、または CloudWatch イベ
   ント に応答してタスクをスケジュールする機能をサポートしています。
   この機能は、Fargate および EC2 の両方の起動タイプを使用する
   Amazon ECS タスクでサポートされています。
   from: タスクのスケジューリング (cron) - Amazon ECS
   "
   

   View Slide

9. ECS Scheduled Task はとても便利
   定期実行バッチ処理のコンテナ化ができる
   cron実行するような定期実行バッチをほぼサーバレスで動かすことができる
   専用バッチサーバは不要
   ECS 運用の資産(Dockerイメージ、Task定義など)を生かせる
   Dockerレイヤキャッシュを使うことでスケジュール通りのバッチ実行が可能
   Fargateを使えば完全にサーバレス化することもできる
   など
   

   View Slide

10. ECS Scheduled Task のコネヒトの以前の利用状況
    1つのバッチに対し、1つのECSタスク定義を用意
    ECSタスク定義はTerraformで管理をし、バッチ追加の際は開発者がPRを出す運用
    PRをインフラエンジニアがレビューし、OKなら terraform apply
    スケジューリングについては特にコード管理せず、手動適用
    

    View Slide

11. ECS Scheduled Task のコネヒトの以前の利用状況
    

    View Slide

12. 参考資料
    AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化/ Container service
    of batch execution environment realized by AWS service - Speaker Deck
    

    View Slide

13. ECS Scheduled Task はとても便利
    AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化/ Container service
    of batch execution environment realized by AWS service - Speaker Deck
    

    View Slide

14. ただし、運用し続けると問題は出てくる
    

    View Slide

15. コネヒトの運用で陥っていた状態
    EventBridgeルールは手作業で追加・変更なので作業の属人化は結局発生
    1つのバッチに対して1つのタスク定義を用意する運用は、数が少ないうちはよかっ
    たがバッチの数が増え運用がきつくなってきた
    

    View Slide

16. コネヒトの運用で陥っていた状態
    

    View Slide

17. Terraformのコードも無駄に肥大化
    利用しているDockerイメージは同一なのにcommand
    と環境変数の微妙な違いによるコピペコードが量産さ
    れていた
    気が付いたらtfファイルが1564行まで膨れてしまった
    クラスタも
    

    View Slide

18. バッチを動かすためにマネージドサービスを便利に
    使えてはいるが、運用はしんどい
    

    View Slide

19. バッチ運用を楽にするための
    改善プロジェクトを開始
    

    View Slide

20. バッチ運用を楽にするための改善プロジェクトを開始
    コピペコードの量産に、変更の適用フローが属人的で開発者体験は良くはなかった
    @laugh_k が入社したばかりで着手しやすい状況だったこともおおきい
    

    View Slide

21. 目指したところ
    開発者でもわかりやすく、直接扱いやすい仕組みにしたい
    バッチの追加・更新の際は属人的でなく、極力開発者の裁量でできるようにしたい
    

    View Slide

22. 改善方針
    バッチ一つにつき一つのタスク定義を用意する方法をやめ、バッチ共通のタスク定
    義を一つ用意して使う
    タスク定義ではなく、イベントルールを管理する
    手作業はできるだけ排除したい
    

    View Slide

23. こうしたいイメージ
    

    View Slide

24. タスク定義は1つなので特別なツールは使わない
    

    View Slide

25. ここをどうするか？
    

    View Slide

26. EventBridgeルール管理の技術選定
    次の二つが候補に上がる
    Songmu/ecschedule
    ansible-collections/community.aws (AnsibleのAWSモジュール)
    

    View Slide

27. Ansible (AWSモジュール) vs ecschedule
    

    View Slide

28. Ansible (AWSモジュール)
    構成管理ツールとしての実績は間違いなし
    ContainerOverrideはJSON文字列で渡す必
    要がある
    タスクの単発実行には対応してない
    など
    

    View Slide

29. ecschedule
    ワンバイナリで環境がそろう
    ECS Scheduled Task 特化なので余計な機能
    がない
    タスクの単発実行に対応
    ContainerOverrideも含めて一気通貫YAML
    で書ける
    など
    

    View Slide

30. 比較した結果 ecschedule を選択
    EventBridgeルールをよりシンプルに管理できる
    タスクの単発実行ができるのも嬉しい
    一気通貫でYAMLで管理できるのもよい
    Ansibleは社内で特に使われていなかったのも大きい
    

    View Slide

31. 対応方針を整理
    

    View Slide

32. 決まった方針
    1. ecscheduleでEventBrideのルールを管理する
    2. タスク定義の管理を簡略化するための構成変更
    1. タスク定義はawscliで適用可能なJSONを用意する
    2. バッチで利用しているタスク定義を切り替える
    

    View Slide

33. ecscheduleでEventBrideのルールを管理する
    

    View Slide

34. ecschedule の導入
    

    View Slide

35. ecschedule の導入
    とりあえず導入するのはdump機能があるのでとても簡単
    $ ecschedule dump \
    > --cluster clusterName1 \
    > --region ap-northeast-1 > event-rule.yaml
    

    View Slide

36. ecschedule の導入は
    

    View Slide

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
    

    View Slide

38. タスク定義の管理を簡略化するための構成変更
    

    View Slide

39. タスク定義の管理を簡略化するための構成変更
    

    View Slide

40. タスク定義の管理を簡略化するための構成変更
    

    View Slide

41. 共通のタスク定義は愚直にJSONを
    用意
    管理するタスク定義はバッチ用ECSクラスタあたり
    1つ ※
    Dockerイメージもreleaseタグを参照しているので、
    更新する頻度は少ない
    ※ FargateとEC2を利用している環境の場合は2つ必要
    

    View Slide

42. バッチ管理のためのファイル構成は次のように
    `-- cluster1/
    |-- dev-events-rules.yaml
    |-- dev-task-definition.json ← 追加
    |-- prd-events-rules.yaml
    `-- prd-task-definition.json ← 追加
    長くなるので一つのクラスタだけ抜粋
    

    View Slide

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 ← 追加
    長くなるので一つのクラスタだけ抜粋
    

    View Slide

44. タスク定義の管理を簡略化するための構成変更
    

    View Slide

45. タスク定義の管理を簡略化するための構成変更
    

    View Slide

46. バッチで利用する
    タスク定義の切り替え
    ecschedule管理のYAMLを編集
    適用は ecschedule apply で
    

    View Slide

47. $ ecschedule apply -conf cluster1/dev-event-rule.yaml -all
    

    View Slide

48. タスク定義の共通化ができ、Terraform管理から解放
    

    View Slide

49. View Slide

50. ecschedule (YAML) のみでバッチの更新・追加がで
    きるように
    基本的にEventBridgeルールだけを考えればよくなった
    タスク定義のTerraformに比べてコード量も大幅に削減 (1564行から335行)
    手作業ではなく、コードの内容がそのまま適用されるようになった
    

    View Slide

51. ただし、まだ課題は残る
    

    View Slide

52. View Slide

53. １コマンドで終わるとはいえ、手作業は残っている
    適用する人が属人化してる状況はかわらない
    今はコロナ渦のフルリモート業務、新たな手動オペレーションは結構リスキー
    せっかくPRベースで追加・更新ができるようになったものの、適用のタイミングは
    調整する必要がある
    

    View Slide

54. View Slide

55. ここでもう一押し対応
    

    View Slide

56. GitHub Actions による自動化
    

    View Slide

57. GitHub Actions による自動化のためにやったこと
    必要なコマンドのmakeタスク化
    GtiHub Actions用の設定YAMLを準備
    mainブランチにレビューなしのコードが入らないように
    READMEを整え全体周知
    

    View Slide

58. 自動化にあたって必要な
    コマンドをmakeタスク化
    設定YAMLに直接ベタ書きしてもいいが、手動で
    も簡単にCI上のオペレーションを再現できたほ
    うが便利
    GitHub Actions上でも手動でも
    make apply-all すればOKな状態に
    

    View Slide

59. 用意したmakeタスクを活用す
    る形でGitHub Actionsで自動
    Apply
    AWS向けのsecretsをリポジトリに設定
    公式ドキュメントに従いYAMLを準備
    mainブランチの内容は常にすべてapplyする
    

    View Slide

60. ブランチの設定も変更
    mainブランチにレビューしていないコードが入らないように
    

    View Slide

61. GitHub上でバッチ追加・更新が完結するように！
    1. YAMLを編集し、PRを出す
    2. インフラエンジニアがレビューし、Approveする
    3. マージする
    以上で
    

    View Slide

62. READMEを整備
    バッチ追加に必要な流れをドキュメント化
    いくら仕組みを用意しても
    安心して使ってもらえないと意味がない
    

    View Slide

63. 最後は全体周知
    

    View Slide

64. こうしたいイメージが現実に！
    

    View Slide

65. View Slide

66. 導入後の話
    

    View Slide

67. 通常のバッチ追加・更新は晴れてGitOps化が実現
    開発者の裁量でバッチの適用までできるように
    

    View Slide

68. 安全な計画停止の実現(GitOps化以前)
    以前は停止に伴う影響を調べスプレッドシートにまとめていた
    

    View Slide

69. 安全な計画停止の実現(GitOps化以前)
    停止の際は秘伝のシェルスクリプトを実行していた
    (@shnagai のPCより発掘)
    

    View Slide

70. 安全な計画停止の実現(GitOps化後)
    計画停止の内容もPRで共有できる
    

    View Slide

71. PRベースでバッチ停止に関する相談もできる
    

    View Slide

72. 停止も再開も安全に実施できる
    停止時
    $ git switch maintenance-20210128
    $ make apply-all
    再開時
    $ git switch main
    $ make apply-all
    

    View Slide

73. もちろん問題がないわけではない
    ecscheduleはバッチの削除には対応していないので、削除は手動対応が必要
    YAMLのタスク名に重複がある場合に意図しない適用のされ方をする
    など
    

    View Slide

74. 必要に応じてYAML内容のチェックを入れたり、
    時には ecschedule 自体へのフィードバックを
    行うことで対応していきます
    

    View Slide

75. ご清聴ありがとうございました
    https://connehito.com/recruit/
    We are hiring!!
    

    View Slide