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

© 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

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

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

View Slide

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

View Slide

EC2 Spot の導⼊ & よくある課題

View Slide

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

View Slide

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

View Slide

EC2 Spot とコンテナは
本当に相性が良いのか

View Slide

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

View Slide

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

View Slide

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

View Slide

❤
❔
EC2 Auto Scaling とコンテナの相性が良い︖
EC2 Auto Scaling
イズを維持
コンテナ
ü 実⾏環境の Docker エンジン
がアプリケーションの動作を
担保
ü コンテナイメージの送受信が
容易
ü コンテナ間アイソレーション

View Slide

AS とコンテナオーケストレータの相性が良い
EC2 Auto Scaling
イズを維持
Amazon ECS/EKS
ü あらかじめ指定されたコンテナ
実⾏定義をもとに、クラスタ内
のコンテナ実⾏状態を維持

View Slide

Amazon EC2 Auto Scaling における⾃動復旧

View Slide

Amazon ECS/EKS における⾃動再実⾏

View Slide

EC2 Auto Scaling + Amazon ECS/EKS

View Slide

コンテナと 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

代表的な課題と解決策の列挙 (再掲)
• コンテナオーケストレータによる再実⾏
• コンテナイメージと AMI でライフサイクルを分割
• ︖

View Slide

EC2 Spot の世界を⽣き抜ける
アプリケーションとは

View Slide

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

View Slide

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

View Slide

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

View Slide

【参考】
§ 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

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

View Slide

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

View Slide

代表的な課題と解決策の列挙 (再掲)
• アプリケーションごとに、停⽌・再実⾏・べき等を想定した設計と実装を⾏う

View Slide

構築パターンに学ぶコンテナ x EC2 Spot

View Slide

EC2 Auto Scaling + Amazon ECS/EKS (再掲)

View Slide

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

View Slide

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

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

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

View Slide

中断通知の受け取り⽅
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

中断通知の受け取りと ECS への伝達
- 1. Amazon EventBridge -
構築パターン

View Slide

© 2020, Amazon Web Services, Inc. or its Aﬃliates.
中断通知の受け取り⽅と ECS への伝達
- 1. Amazon EventBridge → AWS Lambda → Amazon ECS
• 中断通知を Amazon EventBridge 経由で AWS Lambda 関数へ

View Slide

• 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"
}
}

View Slide

• 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

中断通知の受け取りと EKS への伝達
- 1. Amazon EventBridge -
構築パターン

View Slide

中断通知の受け取り⽅と 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

中断通知の受け取りと ECS への伝達
- 2. インスタンスメタデータ -
構築パターン

View Slide

- 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

中断通知の受け取りと EKS への伝達
- 2. インスタンスメタデータ -
構築パターン

View Slide

中断通知の受け取り⽅と 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

Fargate Spot (ECS) での中断通知ハンドリング
- SIGTERM -
構築パターン

View Slide

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

本⽇のまとめ
• アプリケーションごとに、停⽌・再実⾏・べき等を想定した設計と実装を⾏う
+ インスタンス中断時にコンテナオーケストレータから登録解除する

View Slide

Thank you!
Tori Hara
toricls

View Slide

Appendix

View Slide

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

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

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

Tori Hara
PRO

More Decks by Tori Hara

Other Decks in Technology

Featured

Transcript

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

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

Tori Hara PRO

More Decks by Tori Hara

Other Decks in Technology

Featured

Transcript

Tori Hara
PRO