ECSを活用して Digdagに安らぎを与える 　東 優太

Digdagが抱える問題 課題 並列して実行しているタスクがお互いにリソースを取り合い、 リソースが枯渇し処理が遅延する ComputeResource Digdag Task Digdag Task Digdag Task Digdag Task

Digdagが抱える問題 解決策 タスクごとに独立したリソースを割り当て、 リソースを取り合うことがないように担保された環境で実行する ComputeResource Digdag Task ComputeResource Digdag Task ComputeResource Digdag Task

Digdagが抱える問題 この課題を解決する方法の一つ、 digdag-operator-ecs_task

DigdagServer digdag-operator-ecs_task digdag-operator-ecs_task 何ができるか AWS上のコンテナオーケストレーションサービスであるECS上で、 指定したコンテナを起動・実行待機するオペレータを提供 シェルやruby、embulkを実行するオペレータが存在する ECS Digdag Task embulk

AWS ECS 何ができるか DockerhubやAWSのDockerレジストリに登録したコンテナイメージを AWS上に構築したコンピューティングリソース(クラスタ)内で リソース指定でコンテナ化・実行できる クラスタ内のEC2もしくはFargateで実行できる digdag-operator-ecs_task DigdagServer ECS (case ec2) Digdag Task embulk EC2 Container Container

AWS Fargate 何ができるか クラスタ内のEC2ではなくOn-Demandで要求リソースを確保し、 コンテナを立ち上げる クラスタのコンピューティングリソースの事前確保が不要となり、 クラスタのスケールについて考える必要がほぼなくなる digdag-operator-ecs_task DigdagServer ECS (case Fargate) Digdag Task embulk Container Container

まとめると... digdag-operator-ecs_taskで、 必要なタスクをECSのFargateで起動すれば、 リソースを取り合うことなく実行できる digdag serverのコンピューティングリソースに悩まなくて済む サンプルを用意しておきました 利用方法を見ていきましょう digdag-operator-ecs_task

インフラ構築 ECSでFargateを利用するための構築を行います 1. ECSのクラスタとネットワークを作成 2. スクリプト共有のためのS3を作成 3. Fargate実行のためのIAMRoleを作成 利用準備

1. ECSのクラスタとネットワークを作成 ECSはクラスタというリソースの単位があり、 クラスタ内でコンテナを立ち上げます コンテナを立ち上げるためにインターネット接続が必要になります - クラスタの作成 - vpcと(Fargateを立ち上げる)subnetの作成 - internet gatewayの作成とsubnetからのルーティング 利用準備

2. スクリプト共有のためのS3作成 digdag-operator-ecs_taskは実行スクリプトをS3に保存し、 ECSで起動するコンテナがダウンロードする方法を取っている - S3バケットを作成 利用準備

3. Fargate実行のためのIAMRole作成 関わるIAMRoleは3つ - ecsExecutionRole - ECSのDockerデーモンがECRやCloudwatchに起動ログを書き 込むRole - ecsTaskRole - 起動したコンテナがアクセスするAWSサービスを許可・制限する Role - スクリプトやり取りのため、S3へのReadWrite権限必要 - digdag serverのRole - digdagからECSのタスクを起動するため、ECSのタスクの権限が 必要 - スクリプトやり取りのため、S3へのReadWrite権限必要 利用準備

利用準備 Digdag側の設定 digdag-operator-ecs_taskの設定を記述します 1. Fargate起動のための設定 2. プラグインの振る舞いのための設定

利用準備 1. Fargate起動のための設定 大量にある.... が、基本的にはクラスタやRoleを指定してくだけ 注意が必要な設定として、network_modeをawsvpcにする必要がある

利用準備 2. プラグインの振る舞いのための設定 - プラグイン実行時のスクリプトやり取りのS3のバケット指定 - 起動するコンテナのイメージ 必須な設定はこれくらい

プラグインでできること 一番使うであろうものだけ紹介 ecs_task.embulk>: 指定したymlもしくはymlの内容をパラメータとして渡すことで、 ECSのタスクとしてembulkを実行でき、終了待機できる td_load>: と同様にyml内の変数展開もできる embulk_pluginsパラメータを設定すれば、コンテナにないプラグインも追加 できる

プラグインでできること ecs_task.register>: ecs_task.run>: ecs_task.wait>: ecs_task.result>: それぞれタスクの登録・実行・実行待機・結果取得を行う ecs_task.embulk>:やecs_task.sh>:といった具体的なオペレータは 上記のオペレータをサブタスクとして実行し、 シェルを実行しているだけという作りになっている

プラグインでできること デメリットはない？ - 設定値がひたすらに多くて面倒 - 共通のconfig用yamlにまとめてloadしておけば多少マシ digdag server起動時に与えてもいい - DockerImage自体は用意する必要がある - むしろ予めプラグイン導入したimageを使える利点でもある - s3にアクセスする関係で、aws cliも入っている必要がある - 起動オーバーヘッドがある - ProvisionやS3アップロード部分にかかるが、 そもそも長くかかるembulk処理なら軽微な範疇 - 起動待機が1秒ごとに行われ、都度ログが出力される - 待機時間の可変化・exponential backoffの 機能追加のPRなげてるんでもうちょい待って

終　 ありがとうございました