ECSの辛いところ

ECSを使ってJob Observerパターンを実践した時の苦労話

Transcript

1. ECSの辛いところ
2. 自己紹介 @yamasaki0 github.com/masahide 職: インフラ屋 趣味: golang 好きなAWSサービス: SQS, S3, KMS
3. ECSとは Amazon Elastic Container Service (Amazon ECS) は、クラスターで Docker コンテ ナを簡単に実行、停止、管理できる非常にス ケーラブルで高速なコンテナ管理サービスで す。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html
4. ECSに期待するもの（理想） https://www.youtube.com/watch?v=vPjCL3BXTSw
5. ECSに期待するもの（理想） https://www.youtube.com/watch?v=vPjCL3BXTSw Amazon ECS: コンテナの自動スケーリング（日本語字幕） ECSのデベロッパーアドボケイトの方曰く 「ECSでは全てが自動で処理されるため まったく手間がかかりません」
6. 実現したい処理 Job Observerパターン http://aws.clouddesignpattern.org/index.php/CDP:Job_Observerパターン キューに積み上る メッセージ数に応じて スケーリング SQS ECS Claster Instance/Task
7. • スケーリング周り • ECS側の問題 ECSのつらみ（現実）
8. スケーリング周りが辛い • タスク数とインスタンス数の制御 • ドレイニング
9. 本日伝えたいこと！ • デーモンサービススケジューラは良い • Fargateは良い • 自分でAutoScaling APIを叩く方がマシ
10. タスク数と インスタンス数の制御
11. タスクとは • 複数のコンテナを1つにまとめたもの
12. タスクとインスタンスの関係 Task Task Task Task ECS Cluster
13. ECSのスケールの制御はタスク数 Task Task Task Task ECS Cluster
14. 料金はEC2インスタンス数で決まる ECS Cluster
15. タスク数とインスタンス数の制御担当 タスク数 ECS インスタンス数 Auto Scaling
16. AWSが言うお手軽ECS AutoScaling https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/ Amazon ECS で Auto Scaling
17. AWSが言うお手軽ECS AutoScaling https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/ Amazon ECS で Auto Scaling タスク数をアラームで制御
18. AWSが言うお手軽ECS AutoScaling https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/ Amazon ECS で Auto Scaling インスタンス数をアラームで制御
19. ２種類のスケールイン/アウトの閾値 合計4つの閾値調整が必要 • タスク数スケールアウト/イン • インスタンス数スケールアウト/イン
20. インスタンスの起動は遅い タスクの起動は速い • インスタンス数は常に余裕が必要 • インスタンスの起動が遅れると ◦ タスク渋滞が発生
21. タスク渋滞対応の難しさ • スケールアウトポリシーを強める • インスタンス過多 • スケールインポリシーに引っかかりインスタンス が少なくなる • →　再びタスク渋滞へ
22. そこで現れた救世主
24. Fargate • インスタンスの管理から解放される • 課金の単位がタスク
25. え！？ https://aws.amazon.com/jp/fargate/ > Fargate を使用すると、数秒で数万個のコンテナ を起動して、最もミッションクリティカルなアプリケー ションを実行するために簡単にスケールできます。
26. 欠点 ちょっと高い https://dev.classmethod.jp/cloud/aws/aws-fargate-pricing/ クラスメソッドさんが試算してくれてます。 （1年前だけど） ＞$0.0033816 * 60 = $0.202896/hourとなります。 m4.large EC2の料金($0.1/hour)
27. 現実的なworkaround
28. デーモンスケジューリング https://aws.amazon.com/jp/about-aws/whats-new/2018/06/amazon-ecs-adds-da emon-scheduling/ https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_service s.html#service_scheduler １インスタンスに１タスクだけ起動する設定 • タスクを増やしたい場合はインスタンスを増やすだけ • タスクを減らしたい時はインスタすを減らすだけ
29. デーモンスケジューリング インスタンス数の調整でだけで よくなる！
30. デーモンスケジューリングで実現！ Job Observerパターン http://aws.clouddesignpattern.org/index.php/CDP:Job_Observer パターン キューに積み上る メッセージ数に応じて スケーリング SQS ECS Claster Instance/Task
31. オレオレベストプラクティス • デーモンスケジューリングを使う • 1つのECSクラスタに１種類のタスク • 1タスクがインスタンスリソースを使い切るように
32. ドレイニング
33. ECS スケールインの問題 • AutoScalingによるインスタンス停止はECSのタ スクの状態を考慮しない ◦ https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-termination.html# default-termination-policy ◦ 処理中でもお構い無し無慈悲なTerminate
34. ECSのドレイニングとは AutoScalingでスケールインする際に、安 全にタスクを停止させる (graceful- stopのようなもの)
35. ドレイニングを実現するための構成 https://aws.amazon.com/jp/blogs/news/how-to-automate-container-instance-draining-in-amazon-ecs/ Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法
36. ECS ドレイニング用 Lambda https://github.com/aws-samples/ecs-cid-sample/blob/master/cform/ecs.yaml#L421-L490 Pythonのサンプルコードがある
37. ECS ドレイニング用 Lambda https://github.com/aws-samples/ecs-cid-sample/blob/master/cform/ecs.yaml#L421-L490 サンプルコードがある ただ、落とし穴があって・・
38. サンプルLambdaの落とし穴 Lambda内でAPIスロットリング によりエラーが発生
39. サンプルLambdaの落とし穴 Lambda内でAPIスロットリング によりエラーが発生 エクスポネンシャルバックオフ https://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html
40. エクスポネンシャルバックオフ https://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html • API呼び出しのリトライ処理 • 指数関数的にリトライ間隔を調整 • 実はほとんどのAWS SDKで実装されてるが・・・ ◦ 呼び出し側のリソース不足などのエラーに対応してない ので自前実装がおすすめ ◦ ググればライブラリは色々出てくる
41. しかし、このピタゴラ装置感 https://aws.amazon.com/jp/blogs/news/how-to-automate-container-instance-draining-in-amazon-ecs/ Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法
42. しかし、このピタゴラ装置感 https://aws.amazon.com/jp/blogs/news/how-to-automate-container-instance-draining-in-amazon-ecs/ Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法 マネージドなのにlambda を自前実装させるサービ ス・・・
43. Workaround タスク内から自分でAPIを叩く！
44. Workaround タスク内から自分でAPIを叩く！ • APIを叩いてインスタンスの状態を確認 ◦ 終了待ち状態だったら処理を終了
45. Workaround タスク内から自分でAPIを叩く！ • APIを叩いてインスタンスの状態を確認 ◦ 終了待ち状態だったら処理を終了 • メリット ◦ タスクの都合が良いタイミングで終了処理を行える ◦ 全体の構成がシンプル ▪ Lambda, SNSが不要
46. 実装方法詳細 • AutoScaling groupにライフサイクルフックを設定 https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/lifecycle-hooks.html • DescribeAutoScalingInstances で自インスタンスの LifecycleState が "Terminating:Wait" か確認する https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DescribeAutoScalingInstances.html • "Terminating:Wait"の場合は終了処理に入る • CompleteLifecycleAction でパラメータとしてライフサイク ルフック名と "ABANDON" 送る https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html
47. Auto scaling group のライフサイクルフックの設定はこんな感じ Ec2InstanceAutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: AutoScalingGroupName: !Sub ${AWS::StackName} VPCZoneIdentifier: !Ref SubNets LaunchTemplate: LaunchTemplateId: !Ref Ec2InstanceLaunchTemplate Version: !GetAtt Ec2InstanceLaunchTemplate.LatestVersionNumber MinSize: !Ref Ec2AutoscaleMinSize MaxSize: !Ref Ec2AutoscaleMaxSize DesiredCapacity: !Ref Ec2AutoscaleDesiredCapacity LifecycleHookSpecificationList: - LifecycleTransition: autoscaling:EC2_INSTANCE_TERMINATING LifecycleHookName: !Sub ${AWS::StackName}-lc-hook HeartbeatTimeout: 3600 DefaultResult: ABANDON 実装方法詳細
48. やっと理想のシンプルな構成に・・・ Job Observerパターン http://aws.clouddesignpattern.org/index.php/CDP:Job_Observer パターン キューに積み上る メッセージ数に応じて スケーリング SQS ECS Claster Instance/Task
49. オレオレベストプラクティスまとめ • デーモンスケジューリング • 1ECSクラスタ＝1種類タスク • 1タスクでインスタンスリソースを使い切る • タスクからAutoScaling APIを叩く • エクスポネンシャルバックオフ • CloudFormaiton
50. ありがとうとざいました。