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

Transcript

1. ECSを活用して Digdagに安らぎを与える 　東 優太
2. Digdagが抱える問題 課題 並列して実行しているタスクがお互いにリソースを取り合い、 リソースが枯渇し処理が遅延する ComputeResource Digdag Task Digdag Task Digdag Task Digdag Task
3. Digdagが抱える問題 解決策 タスクごとに独立したリソースを割り当て、 リソースを取り合うことがないように担保された環境で実行する ComputeResource Digdag Task ComputeResource Digdag Task ComputeResource Digdag Task
4. Digdagが抱える問題 この課題を解決する方法の一つ、 digdag-operator-ecs_task
5. DigdagServer digdag-operator-ecs_task digdag-operator-ecs_task 何ができるか AWS上のコンテナオーケストレーションサービスであるECS上で、 指定したコンテナを起動・実行待機するオペレータを提供 シェルやruby、embulkを実行するオペレータが存在する ECS Digdag Task embulk
6. AWS ECS 何ができるか DockerhubやAWSのDockerレジストリに登録したコンテナイメージを AWS上に構築したコンピューティングリソース(クラスタ)内で リソース指定でコンテナ化・実行できる クラスタ内のEC2もしくはFargateで実行できる digdag-operator-ecs_task DigdagServer ECS (case ec2) Digdag Task embulk EC2 Container Container
7. AWS Fargate 何ができるか クラスタ内のEC2ではなくOn-Demandで要求リソースを確保し、 コンテナを立ち上げる クラスタのコンピューティングリソースの事前確保が不要となり、 クラスタのスケールについて考える必要がほぼなくなる digdag-operator-ecs_task DigdagServer ECS (case Fargate) Digdag Task embulk Container Container
8. まとめると... digdag-operator-ecs_taskで、 必要なタスクをECSのFargateで起動すれば、 リソースを取り合うことなく実行できる digdag serverのコンピューティングリソースに悩まなくて済む サンプルを用意しておきました 利用方法を見ていきましょう digdag-operator-ecs_task
9. インフラ構築 ECSでFargateを利用するための構築を行います 1. ECSのクラスタとネットワークを作成 2. スクリプト共有のためのS3を作成 3. Fargate実行のためのIAMRoleを作成 利用準備
10. 1. ECSのクラスタとネットワークを作成 ECSはクラスタというリソースの単位があり、 クラスタ内でコンテナを立ち上げます コンテナを立ち上げるためにインターネット接続が必要になります - クラスタの作成 - vpcと(Fargateを立ち上げる)subnetの作成 - internet gatewayの作成とsubnetからのルーティング 利用準備
11. 2. スクリプト共有のためのS3作成 digdag-operator-ecs_taskは実行スクリプトをS3に保存し、 ECSで起動するコンテナがダウンロードする方法を取っている - S3バケットを作成 利用準備
12. 3. Fargate実行のためのIAMRole作成 関わるIAMRoleは3つ - ecsExecutionRole - ECSのDockerデーモンがECRやCloudwatchに起動ログを書き 込むRole - ecsTaskRole - 起動したコンテナがアクセスするAWSサービスを許可・制限する Role - スクリプトやり取りのため、S3へのReadWrite権限必要 - digdag serverのRole - digdagからECSのタスクを起動するため、ECSのタスクの権限が 必要 - スクリプトやり取りのため、S3へのReadWrite権限必要 利用準備
13. 利用準備 Digdag側の設定 digdag-operator-ecs_taskの設定を記述します 1. Fargate起動のための設定 2. プラグインの振る舞いのための設定
14. 利用準備 1. Fargate起動のための設定 大量にある.... が、基本的にはクラスタやRoleを指定してくだけ 注意が必要な設定として、network_modeをawsvpcにする必要がある
15. 利用準備 2. プラグインの振る舞いのための設定 - プラグイン実行時のスクリプトやり取りのS3のバケット指定 - 起動するコンテナのイメージ 必須な設定はこれくらい
16. プラグインでできること 一番使うであろうものだけ紹介 ecs_task.embulk>: 指定したymlもしくはymlの内容をパラメータとして渡すことで、 ECSのタスクとしてembulkを実行でき、終了待機できる td_load>: と同様にyml内の変数展開もできる embulk_pluginsパラメータを設定すれば、コンテナにないプラグインも追加 できる
17. プラグインでできること ecs_task.register>: ecs_task.run>: ecs_task.wait>: ecs_task.result>: それぞれタスクの登録・実行・実行待機・結果取得を行う ecs_task.embulk>:やecs_task.sh>:といった具体的なオペレータは 上記のオペレータをサブタスクとして実行し、 シェルを実行しているだけという作りになっている
18. プラグインでできること デメリットはない？ - 設定値がひたすらに多くて面倒 - 共通のconfig用yamlにまとめてloadしておけば多少マシ digdag server起動時に与えてもいい - DockerImage自体は用意する必要がある - むしろ予めプラグイン導入したimageを使える利点でもある - s3にアクセスする関係で、aws cliも入っている必要がある - 起動オーバーヘッドがある - ProvisionやS3アップロード部分にかかるが、 そもそも長くかかるembulk処理なら軽微な範疇 - 起動待機が1秒ごとに行われ、都度ログが出力される - 待機時間の可変化・exponential backoffの 機能追加のPRなげてるんでもうちょい待って
19. 終　 ありがとうございました