Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Containers + EC2 Spot: 特性と実装パターンに学ぶ低コスト & 高可用アーキテクチャ / Practical Guide for Amazon EC2 Spot with Containers

Containers + EC2 Spot: 特性と実装パターンに学ぶ低コスト & 高可用アーキテクチャ / Practical Guide for Amazon EC2 Spot with Containers

Talked at AWS Spot x Containers Seminar #SpotLovesContainers

Tori Hara
PRO

June 10, 2020
Tweet

More Decks by Tori Hara

Other Decks in Technology

Transcript

  1. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Tori Hara / toricls
    Sr. Product Developer Advocate
    Containers Product, Amazon Web Services
    Jun. 10, 2020
    Practical Guide for Amazon EC2 Spot x Containers
    特性と構築パターンに学ぶ低コスト & ⾼可⽤アーキテクチャ
    \2020!/

    View Slide

  2. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Tori Hara / toricls
    Sr. Product Developer Advocate
    Containers Product, Amazon Web Services
    ---
    ERP パッケージベンダー R&D チーム SDE
    ➡ UI ⾃動テスト SaaS
    ➡ クラウド利⽤の SI + MSP にて、コンテナやサーバーレスによる設計・開発・運⽤
    Web 技術利⽤のゲームやビジネスアプリケーション開発、ML/DL 環境構築運⽤など
    ➡ Sr. Containers Specialist SA, AWS Japan
    ➡ 現ロール
    AWS Fargate / AWS Lambda が好きです

    View Slide

  3. © 2020, Amazon Web Services, Inc. or its Affiliates.
    本セッションは…
    想定される聴講者
    • コンテナワークロード構築を検討中
    • コンテナワークロードを運⽤中で、EC2 Spot 活⽤を検討中
    • コンテナが好き、EC2 Spot が好き
    ゴール
    • EC2 Spot とコンテナがなぜ相性が良いのか説明できるようになる
    • EC2 Spot とコンテナの組み合わせ時に推奨されるベストプラクティスを理解する
    • ベストプラクティスを⾃⾝のワークロードに適⽤できる
    • もしくは適⽤するためにやるべきことを洗い出せる

    View Slide

  4. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Agenda
    1. EC2 Spot の導⼊ & よくある課題
    2. コンテナと EC2 Spot は本当に相性が良いのか
    3. EC2 Spot の世界を⽣き抜けるアプリケーションとは
    4. 具体的構築パターンに学ぶコンテナ x EC2 Spot ワークロード

    View Slide

  5. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot の導⼊ & よくある課題

    View Slide

  6. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot 導⼊ & よくある課題
    • EC2 Spot Instances の特徴
    • 最⼤90%OFF
    • インスタンスの中断が起こりうる
    • 導⼊にあたってのよくある課題は「中断される」特性によるもの
    1. 中断によるキャパシティ減少
    2. いつでも AMI から最新のアプリケーションが⼊ったインスタンスを実⾏できる
    よう、アプリケーション更新毎に AMI 作成とインスタンス⼊替を⾏う⼿間と時
    間 (⼿動・⾃動はここでは問題ではない)
    3. アプリケーションが処理中に⽌まることによる不具合発⽣の可能性
    4. 「アプリケーション再実⾏」の考慮

    View Slide

  7. © 2020, Amazon Web Services, Inc. or its Affiliates.
    代表的な課題と解決策の列挙
    1. 停⽌によるキャパシティ減少
    • EC2 Auto Scaling / Spot Fleet でキャパシティの維持が可能 (前セッション)
    2. キャパシティ復旧後のアプリケーション再実⾏の担保
    • ︖
    3. アプリケーション、ホストのライフサイクル混在によるオペレーション負荷
    • ︖
    4. アプリケーション処理中の停⽌・再開による不具合発⽣の可能性
    • ︖

    View Slide

  8. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot とコンテナは
    本当に相性が良いのか

    View Slide

  9. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot とコンテナは本当に相性が良いのか
    • 本セッションにおける「相性」
    • システム間の組み合わせの良さ・悪さ
    • 相性が良い
    • ⼆つないし複数のコンポーネントがそれぞれの特性を補完、もしくは互いの
    特性が順応し、相対的に全体がより良いシステムとして稼働できる状態
    • 相性が悪い
    • それぞれの特性の衝突により個々の良さが発揮されない、あるいは相対的に
    システム全体における機能性や価値が損なわれている状態

    View Slide

  10. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot、コンテナの特性
    EC2 Spot
    ü 安価に利⽤可能でありながら
    オンデマンドインスタンスと
    同じ仮想マシンを利⽤可能
    AWS 側のインスタンス需要
    などに基づきインスタンスを
    中断されることがある
    コンテナ
    ü 実⾏環境の Docker エンジン
    がアプリケーションの動作を
    担保
    ü コンテナイメージの送受信が
    容易
    ü コンテナ間アイソレーション


    View Slide

  11. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot と相性が良いのは EC2 Auto Scaling
    EC2 Spot
    ü 安価に利⽤可能でありながら
    オンデマンドインスタンスと
    同じ仮想マシンを利⽤可能
    AWS 側のインスタンス需要
    などに基づきインスタンスを
    中断されることがある
    EC2 Auto Scaling
    ü あらかじめ指定されたインス
    タンスタイプや購⼊モデルな
    どをもとに、キャパシティサ
    イズを維持

    View Slide

  12. © 2020, Amazon Web Services, Inc. or its Affiliates.


    EC2 Auto Scaling とコンテナの相性が良い︖
    EC2 Auto Scaling
    ü あらかじめ指定されたインス
    タンスタイプや購⼊モデルな
    どをもとに、キャパシティサ
    イズを維持
    コンテナ
    ü 実⾏環境の Docker エンジン
    がアプリケーションの動作を
    担保
    ü コンテナイメージの送受信が
    容易
    ü コンテナ間アイソレーション

    View Slide

  13. © 2020, Amazon Web Services, Inc. or its Affiliates.
    AS とコンテナオーケストレータの相性が良い
    EC2 Auto Scaling
    ü あらかじめ指定されたインス
    タンスタイプや購⼊モデルな
    どをもとに、キャパシティサ
    イズを維持
    Amazon ECS/EKS
    ü あらかじめ指定されたコンテナ
    実⾏定義をもとに、クラスタ内
    のコンテナ実⾏状態を維持

    View Slide

  14. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Amazon EC2 Auto Scaling における⾃動復旧

    View Slide

  15. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Amazon ECS/EKS における⾃動再実⾏

    View Slide

  16. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Auto Scaling + Amazon ECS/EKS

    View Slide

  17. © 2020, Amazon Web Services, Inc. or its Affiliates.
    コンテナと EC2 Spot は本当に相性が良いのか
    • 実は相性が良いのはコンテナと EC2 Spot そのものではない
    ⇨ コンテナや EC2 Spot Instances を実⾏するそれぞれの仕組みの相性が良い
    • コンテナオーケストレータと EC2 Auto Scaling の相性が良い
    ⇨ ともに「宣⾔的」な挙動であるため⾃動化される
    EC2 Auto Scaling によるホストの⾃動復旧 + ECS/EKS によるコンテナの再実⾏
    が⾒込める (AWS Batch については後述)
    コンテナイメージがアプリケーションとインスタンスのライフサイクルの分界
    点になるため、AMI 再作成の⼿間も減らせる
    EC2 Auto Scaling は Spot Instances の起動もサポートしている

    View Slide

  18. © 2020, Amazon Web Services, Inc. or its Affiliates.
    代表的な課題と解決策の列挙 (再掲)
    1. 停⽌によるキャパシティ減少
    • EC2 Auto Scaling / Spot Fleet でキャパシティの維持が可能 (前セッション)
    2. キャパシティ復旧後のアプリケーション再実⾏の担保
    • コンテナオーケストレータによる再実⾏
    3. アプリケーション、ホストのライフサイクル混在によるオペレーション負荷
    • コンテナイメージと AMI でライフサイクルを分割
    4. アプリケーション処理中の停⽌・再開による不具合発⽣の可能性
    • ︖

    View Slide

  19. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot の世界を⽣き抜ける
    アプリケーションとは

    View Slide

  20. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot の世界を⽣き抜くアプリケーション
    • 課題『アプリケーション処理中の停⽌・再開で不具合が発⽣するかも』
    • 外部要因でアプリケーションが停⽌する
    • アプリケーション観点で考慮すべき点は⼤きく分けて3つ
    1. 処理中のユーザーリクエストやデータなどを壊すことなく停⽌できるか
    2. 停⽌後、そのアプリケーションの再実⾏が担保されるか
    3. 再実⾏によって意図しない副作⽤が発⽣しないか

    View Slide

  21. © 2020, Amazon Web Services, Inc. or its Affiliates.
    1. 安全に停⽌しやすいアプリケーション
    • SIGTERM を受け取り Graceful に終了する
    • ユーザーからのリクエストを返しきる
    • ログをバッファリングしている場合、出⼒しきる
    • 計算処理を(適切な待ち時間で)中断する
    • ステートレスに設計されている
    • 状態はマネージドサービス(e.g. RDS, S3)に逃し、アプリケーションをステートレスに
    保つ
    • コンテナを利⽤している場合、ベストプラクティスに沿ったコンテナイメージを作
    る/使う
    • 1コンテナ1プロセス etc.
    https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

    View Slide

  22. © 2020, Amazon Web Services, Inc. or its Affiliates.
    1. 安全に停⽌しやすいアプリケーション
    • 常駐型アプリケーションの場合 (e.g. Web サーバ)
    • 多くの場合ロードバランサで Connection Draining を⾏う
    • ステートレス、ステートレス、ステートレス
    • ログのホストストレージへの出⼒も極⼒避ける (use stdout/stderr)
    • スタンドアロン型アプリケーション (e.g. バッチジョブ)
    • 再実⾏される可能性を常に考慮して設計する
    • 1つの⻑⼤なジョブではなく、細かい並列実⾏のジョブとして設計できると停⽌
    しやすい
    • 実装的にも⼼理的にも
    • アプリケーションのステートレス化も容易に

    View Slide

  23. © 2020, Amazon Web Services, Inc. or its Affiliates.
    【参考】
    § Amazon ECS
    • Service - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html
    • Task - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html
    § AWS Batch
    • Job - https://docs.aws.amazon.com/batch/latest/userguide/jobs.html
    • Managed Computing Environment - https://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html
    § Amazon EKS (Kubernetes)
    • Deployment - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
    • Jobs - https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
    2. 停⽌後のアプリケーション再実⾏を担保する
    常駐型 (e.g. Web サーバ) スタンドアロン型 (e.g. バッチ処理)
    Amazon ECS Amazon EKS
    (Kubernetes)
    Amazon ECS AWS Batch Amazon EKS
    (Kubernetes)
    Service Deployment
    (ReplicaSet)
    e.g. Step Functions
    + Task (*)
    Job
    (Managed Compute
    Environment backed)
    Job
    ※ Amazon ECS は単体ではスタンドアロン型タスクの終了保証を⾏わない. Appendix 参照.
    Appendix は時間の都合で作れなかったので別の機会でご覧ください...

    View Slide

  24. © 2020, Amazon Web Services, Inc. or its Affiliates.
    3. 再実⾏による意図しない副作⽤を回避する
    • 常駐型アプリケーションの場合 (e.g. Web サーバ)
    • Stateless, Stateless, Stateless
    • このタイプのアプリケーションはそもそも複数個が同時に⾛ることが⼀般的な
    ため、再実⾏⾃体の難易度は低い
    • スタンドアロン型アプリケーション (e.g. バッチジョブ)
    • 再実⾏される可能性を常に考慮して設計する (再)
    • 1つの⻑⼤なジョブではなく、並列実⾏の短いジョブとして設計できると再実⾏
    しやすい (再)
    • いわゆる「べき等」な設計が望ましい
    • 同⼀ジョブの複数回実⾏が外部に与える副作⽤を同じ状態に収束するよう設計する

    View Slide

  25. © 2020, Amazon Web Services, Inc. or its Affiliates.
    3. 再実⾏による意図しない副作⽤を回避する
    • 常駐型アプリケーションの場合 (e.g. Web サーバ)
    • Stateless, Stateless, Stateless
    • このタイプのアプリケーションはそもそも複数個が同時に⾛ることが⼀般的な
    ため、再実⾏⾃体の難易度は低い
    • スタンドアロン型アプリケーション (e.g. バッチジョブ)
    • 再実⾏される可能性を常に考慮して設計する (再)
    • 1つの⻑⼤なジョブではなく、並列実⾏の短いジョブとして設計できると再実⾏
    しやすい (再)
    • いわゆる「べき等」な設計が望ましい
    • 同⼀ジョブの複数回実⾏が外部に与える副作⽤を同じ状態に収束するよう設計する

    View Slide

  26. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Spot の世界を⽣き抜くアプリケーション
    • 安全に終了・再開できるアプリケーションは EC2 Spot にフィットする
    • できる限りステートレスであり、いつでも停⽌できること
    • 再実⾏される可能性を考慮した設計と実装になっていること
    • これらの実現によるメリットは Spot やコンテナの世界だけに限らない
    • 継続的デプロイメントの実践が容易
    • スケールアウト/インがやりやすいダイナミックなアーキテクチャの実現

    View Slide

  27. © 2020, Amazon Web Services, Inc. or its Affiliates.
    代表的な課題と解決策の列挙 (再掲)
    1. 停⽌によるキャパシティ減少
    • EC2 Auto Scaling / Spot Fleet でキャパシティの維持が可能 (前セッション)
    2. キャパシティ復旧後のアプリケーション再実⾏の担保
    • コンテナオーケストレータによる再実⾏
    3. アプリケーション、ホストのライフサイクル混在によるオペレーション負荷
    • コンテナイメージと AMI でライフサイクルを分割
    4. アプリケーション処理中の停⽌・再開による不具合発⽣の可能性
    • アプリケーションごとに、停⽌・再実⾏・べき等を想定した設計と実装を⾏う

    View Slide

  28. © 2020, Amazon Web Services, Inc. or its Affiliates.
    構築パターンに学ぶコンテナ x EC2 Spot

    View Slide

  29. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Auto Scaling + Amazon ECS/EKS (再掲)

    View Slide

  30. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Auto Scaling + Amazon ECS/EKS (再掲)

    View Slide

  31. © 2020, Amazon Web Services, Inc. or its Affiliates.
    EC2 Auto Scaling + Amazon ECS/EKS (再掲)
    - Q -
    ECS/EKS に対して配下のインスタンス
    の登録解除を伝える必要がある
    ⇨ いつ、どうやって伝える︖

    View Slide

  32. © 2020, Amazon Web Services, Inc. or its Affiliates.
    ECS/EKS へのノード登録解除の伝え⽅
    • Amazon ECS
    • DeregisterContainerInstance API
    • 対象のインスタンスに新しい Task がスケジュールされなくなる
    • 対象のインスタンス上で⾛る ECS Tasks が ELB のターゲットグループに登録されてい
    る場合は⾃動的に登録を解除
    • インスタンス上のタスクは停⽌されないが、ECS の認知しないタスクとなる。ECS
    Service 配下のタスクは別インスタンス上で再実⾏される
    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html

    View Slide

  33. © 2020, Amazon Web Services, Inc. or its Affiliates.
    ECS/EKS へのノード登録解除の伝え⽅
    • Amazon EKS (Kubernetes)
    • `kubectl drain` コマンド
    • 対象のインスタンス上に新しい Pod がスケジュールされなくなる
    • 対象のインスタンス上の Pod を別インスタンス上に移動(新規作成と停⽌)
    • see “Pod Disruption Budget”
    https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#drain
    https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

    View Slide

  34. © 2020, Amazon Web Services, Inc. or its Affiliates.
    いつ伝える︖ - EC2 Spot Interruption Warning -
    • スポットインスタンスの価格は⻑期供給と需要に基づいて徐々に調整される
    • スポットインスタンスは AWS によって中断されることがある
    (2018 年のある 3 ヶ⽉間に AWS によって中断された Spot Instances は全体の 5%)
    • AWS によって中断される際は 2 分前までに通知される
    ⇨ 中断通知を受け取ったら ECS/EKS からインスタンスを登録解除する

    View Slide

  35. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅
    1. Amazon EventBridge (旧 CloudWatch Events)
    • AWS リソースの変更をイベントストリームとして対応するサービスやリソース
    などに対して送信
    • e.g. Interruption Warning → Amazon EventBridge → AWS Lambda
    2. インスタンスメタデータ
    • 通常時は 404 Not Found
    • EC2 Spot によって中断が予約されると中断予定時刻が返ってくる
    $ curl -sf http://169.254.169.254/latest/meta-data/spot/termination-time
    2019-04-09T06:30:00Z
    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html

    View Slide

  36. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取りと ECS への伝達
    - 1. Amazon EventBridge -
    構築パターン

    View Slide

  37. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と ECS への伝達
    - 1. Amazon EventBridge → AWS Lambda → Amazon ECS
    • 中断通知を Amazon EventBridge 経由で AWS Lambda 関数へ
    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html

    View Slide

  38. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と ECS への伝達
    - 1. Amazon EventBridge → AWS Lambda → Amazon ECS
    • AWS Lambda 関数が受け取る JSON 例
    {
    "version": "0",
    "id": "12345678-1234-1234-1234-123456789012",
    "detail-type": "EC2 Spot Instance Interruption Warning",
    "source": "aws.ec2",
    "account": "123456789012",
    "time": "yyyy-mm-ddThh:mm:ssZ",
    "region": "us-east-2",
    "resources": ["arn:aws:ec2:us-east-2:123456789012:instance/i-1234567890abcdef0"],
    "detail": {
    "instance-id": "i-1234567890abcdef0",
    "instance-action": "action"
    }
    }
    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html

    View Slide

  39. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と ECS への伝達
    - 1. Amazon EventBridge → AWS Lambda → Amazon ECS
    • AWS Lambda 関数例 (Python)
    import boto3
    # - 省略 -
    def handler(event, context):
    instance_id = event['detail']['instance-id’]
    logger.info('{0} will be terminated in 2 minutes'.format(instance_id))
    ecs = ECS(region)
    ecs.deregister(instance_id)
    https://github.com/awslabs/ec2-spot-labs/tree/master/ecs-ec2-spot-auto-deregister

    View Slide

  40. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取りと EKS への伝達
    - 1. Amazon EventBridge -
    構築パターン

    View Slide

  41. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と EKS への伝達
    - 1. Amazon EventBridge → AWS Lambda → Amazon EKS (Kubernetes)
    • ECS 同様 Amazon EventBridge 経由で AWS Lambda に通知
    • `kubectl drain ${NODE_NAME} --force --ignore-daemonsets` を実⾏
    https://github.com/aws-samples/amazon-k8s-node-drainer
    ※ このリポジトリでは drain ではなく cordon + Eviction API が使われている
    実装例 (このサンプルは Auto Scaling Group のライフサイクルフックとのインテグレーション例)

    View Slide

  42. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取りと ECS への伝達
    - 2. インスタンスメタデータ -
    構築パターン

    View Slide

  43. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と ECS への伝達
    - 2. インスタンスメタデータ → Amazon ECS
    • ECS Agent がインスタンスメタデータのチェックと ECS へのドレイン指⽰を
    ⾏う機能を有効化
    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-spot.html
    #!/bin/bash
    cat <> /etc/ecs/ecs.config
    ECS_CLUSTER=MyCluster
    ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
    EOF
    ※ 上記のような User data スクリプトなどを利⽤して、ECS_ENABLE_SPOT_INSTANCE_DRAINING=true を ECS
    Agent に設定する

    View Slide

  44. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取りと EKS への伝達
    - 2. インスタンスメタデータ -
    構築パターン

    View Slide

  45. © 2020, Amazon Web Services, Inc. or its Affiliates.
    中断通知の受け取り⽅と EKS への伝達
    - 2. インスタンスメタデータ → Amazon EKS (Kubernetes)
    • インスタンスメタデータのチェックと Kubernetes へのドレイン指⽰を⾏う
    “AWS Node Termination Handler” をデプロイする
    ※ これにより Termination Handler コンテナが Kubernetes DaemonSet として全ノードに配置される
    ※ Windows ノード⾮対応 see https://github.com/aws/aws-node-termination-handler/issues/8
    ※ Helm チャートあり〼 https://github.com/aws/eks-charts
    # マニフェストをダウンロード
    $ curl -o node-termination-handler.yaml \
    https://github.com/aws/aws-node-termination-handler/releases/download/v1.4.0/all-
    resources.yaml
    # DaemonSet の環境変数 ENABLE_SPOT_INTERRUPTION_DRAINING を “true” に書き換えてデプロイ
    $ vi node-termination-handler.yaml
    $ kubectl apply -f node-termination-handler.yaml
    https://github.com/aws/aws-node-termination-handler
    (AWS Node Termination Handler のリリースまでは以下を案内することもありました)
    https://github.com/awslabs/ec2-spot-labs/tree/master/ec2-spot-eks-solution/spot-termination-handler and/or https://github.com/kube-aws/kube-spot-termination-notice-handler

    View Slide

  46. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Fargate Spot (ECS) での中断通知ハンドリング
    - SIGTERM -
    構築パターン

    View Slide

  47. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Fargate Spot (ECS) での中断通知ハンドリング
    - SIGTERM
    • EC2 Spot 同様、2分前の警告がある
    • 警告は以下の2種類の形式
    • 1. Amazon EventBridge へのタスク状態変更イベント
    • 2. ECS タスクで実⾏されているアプリケーションへの SIGTERM シグナル
    • Graceful な終了が実装できているアプリケーションであれば、特段の⼼配な
    く安全に停⽌可能
    • ECS はデフォルトでは SIGTERM シグナルの30秒後に SIGKILL シグナルを
    発⾏
    • タスク定義内コンテナ定義の stopTimeout 値を 120 などに設定しておけば
    中断通知後のアプリケーション内の終了処理に時間的余裕を与えられる
    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html#fargate-capacity-providers-termination
    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_timeout

    View Slide

  48. © 2020, Amazon Web Services, Inc. or its Affiliates.
    本⽇のまとめ
    1. 停⽌によるキャパシティ減少
    • EC2 Auto Scaling / Spot Fleet でキャパシティの維持が可能 (前セッション)
    2. キャパシティ復旧後のアプリケーション再実⾏の担保
    • コンテナオーケストレータによる再実⾏
    3. アプリケーション、ホストのライフサイクル混在によるオペレーション負荷
    • コンテナイメージと AMI でライフサイクルを分割
    4. アプリケーション処理中の停⽌・再開による不具合発⽣の可能性
    • アプリケーションごとに、停⽌・再実⾏・べき等を想定した設計と実装を⾏う
    + インスタンス中断時にコンテナオーケストレータから登録解除する

    View Slide

  49. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Thank you!
    Tori Hara
    toricls

    View Slide

  50. © 2020, Amazon Web Services, Inc. or its Affiliates.
    Appendix

    View Slide

  51. © 2020, Amazon Web Services, Inc. or its Affiliates.
    ECS スタンドアロンタスクの成功終了保証 w/ Step Functions
    {
    "StartAt": "Run an ECS Task and wait for it to complete successfully",
    "States":{
    "Run an ECS Task and wait for it to complete successfully":{
    "Type":"Task",
    "Resource":"arn:aws:states:::ecs:runTask.sync",
    "Parameters":{
    "LaunchType":"FARGATE",
    "Cluster":"arn:aws:ecs:us-west-2:123456789012:cluster/my-cluster",
    "TaskDefinition":"arn:aws:ecs:us-west-2:123456789012:task-definition/my-task:1",
    "Overrides":{
    "ContainerOverrides":[{
    "Name":"my-container",
    "Environment":[{
    "Name":"SOME_VALUE",
    "Value.$":"$.some_value"
    }]
    }]}},
    "Retry":[{
    "ErrorEquals":["States.TaskFailed"],
    "IntervalSeconds":3,
    "MaxAttempts":3,
    "BackoffRate":1.5 }],
    "End":true }}}
    1. Manage Amazon ECS or Fargate Tasks with Step Functions: https://docs.aws.amazon.com/step-functions/latest/dg/connect-ecs.html
    2. Error Handling in Step Functions: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html
    例: ECS タスクの処理が失敗した際に最⼤3回までリトライする Step Functions のステートマシンの定義

    View Slide