Amazon Web Services ブログ
【開催報告】「コンテナ × スポットインスタンス」 活用セミナー
スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。
本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。
当日アジェンダと資料
12:00～13:00 Amazon EC2 Auto Scaling によるスポットインスタンス活用講座
講師：滝口 開資（アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト）
Amazon EC2 Auto Scaling によるスポットインスタンス活用講座
13:00～14:00 具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ
講師：Hara Tori（アマゾン ウェブ サービス ジャパン株式会社 シニアデベロッパー アドボケイト）
14:00～14:30 AWS Batchによる大規模バッチ処理でのスポットインスタンス活用
講師：宮本 大輔（アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト）
Containers + EC2 Spot: AWS Batch による大規模バッチ処理でのスポットインスタンス活用
14:30～15:00 ECS×スポットインスタンス活用の秘訣
講師：田中 一樹 様（株式会社ナビタイムジャパン）
15:00～15:30 SaaS 企業における EKS のシングルテナントクラスタ戦略とスポット活用術 / 機械学習基盤におけるスポットインスタンスの有効活用
講師：坂井 学 様、田中 浩之 様（freee株式会社）
SaaS における EKS のシングルテナントクラスタ戦略とスポットインスタンス活用術 / EKS single-tenant cluster strategy and Spot Instances
[freee] 機械学習基盤におけるスポットインスタンスの有効活用
15:30～16:00 Fargate Spot, in Production? Challenge Accepted!
講師：Michael Wangsa 様（HENNGE株式会社）
Fargate spot, in production? Challenge Accepted
Q&Aのご紹介
当日いただいたQ&Aをいくつかご紹介します。
- Q. スポットインスタンスの中断通知を契機に、Lambda関数からスポットインスタンスの計算結果をS3に書き出す場合、どう実現するのでしょうか。Lambdaからシェルスクリプトを叩くのでしょうか。
- まず、ELBからの登録解除、コンテナステータスのdrainingへの変更といった操作は、いわばインスタンスの外側に対するものであり、Lambda関数内でお使いの言語のAWS SDK経由で記述します。これに対し、ご質問いただいたようにインスタンスの内部に対して操作する必要がある場合、AWS Systems Manager (SSM)のRun Command機能を使い、シェルスクリプトやAWS CLIコマンドをリモート実行するのが主な実現方法です。実装例のご参考に、ご質問のユースケースとは異なるものですが、スポットインスタンスワークショップで Run Commandを用いて負荷試験を実施する方法について記述した箇所をご紹介します。
- Q. スポットインスタンスの中断通知をインスタンスメタデータで受け取る場合、EventBridgeで受け取る場合、それぞれの使いどころが知りたいです。
- 中断通知の送付という観点からは違いはなく、現行のアーキテクチャに対して中断通知のjsonを受け取る経路をどのように組み込むかがポイントになります。もしすでにAmazon EventBridge (Amazon CloudWatch Events)を使った監視システムがある場合には、中断通知対応をそちらに組み込んでいただくのが良いと思います。一方で、インスタンス内部の処理でなるべく完結させたい、もしくはセキュリティ要件等でマネージドサービスを選択できないような場面では、引き続きメタデータサービスをお選びいただくと良いと考えます。
- Q. スポットプールの分散を考えたとき、「近いインスタンスタイプを選択する」というお話でしたが、 EKS Cluster のための nodegroup を構成する場合、 vCPUとRAM については同一のインスタンスタイプを候補とすることが Cluster Autoscaler のベストプラクティスになっています。厳密にベストプラクティスに従うと、ワークロードによっては十分な数のスポットプールを選べない状況になってしまいますが、スペックの異なるインスタンスタイプを指定することの是非、その場合のリスク、代わりとなるソリューションについて教えてください。
-
「vCPU と RAM が同一のインスタンスタイプを利用する」は、実際には「vCPU/RAM が最小なインスタンスタイプと同一、もしくはその倍数となるvCPU/RAM を持つインスタンスタイプを利用する」が本来
Cluster Autoscaler のプラクティスとして説明されている内容ではないかと推察します。
では、そもそもなぜこのようなプラクティスが提言されているのかという観点で補足します。Cluster Autoscaler はノードレベルのスケールアウト時に AWS の EC2 Auto Scaling を内部的に利用します。そのため、例えば複数インスタンスタイプが利用されているノードグループでスケールアウトを行う際、Clulster Autoscaler 側から新たに起動するインスタンスタイプを明示的に指定することはできません。ここから分かることは、ノードグループ内の各インスタンスタイプのリソース量が倍数ではない組み合わせとなっており、かつノードグループ内の最小インスタンスタイプが Pod の求めるリソース量を持たないサイズだった場合、不必要にノードレベルのスケールアウト処理が繰り返されることに繋がり得ます。このような事象を避ける目的で先の Cluster Autoscaler のプラクティスが導き出されていると考えられ、同プラクティスはノードグループ内でリソースサイズの異なるインスタンスタイプを利用することを妨げるものではないと考えます。 - Q. コンテナ(コンテナ内のアプリ)を安全に停止させる為には、サイドカーパターンで設計しない方が良いということでしょうか？
- タスク(Kubernetes の場合は Pod) 内に複数のコンテナが並ぶことは特に問題のない一般的な構成と言えます(e.g. サイドカー、アンバサダーなどのパターン). このご質問はおそらくセッション中の「コンテナ内に複数のプロセスを持つことを避ける」という内容についてのものだと思いますが、これはタスク(Pod)の構成要素であるコンテナそれぞれの中に複数のプロセスを持つことを避けましょう、という意味合いであり、タスク(Pod)の中に複数のコンテナが存在することを説明したものではありません。その点だけご留意いただければ幸いです。
- Q. コンテナ内からEC2メタデータエンドポイントにアクセスできますが、使わない方がよいのでしょうか？コンテナ内でEC2のプライベートIPが知りたい時に利用しているのですが、正しい使い方なのか知りたいです。
- ご質問に書かれている利用方法に特に問題はないと考えます。ただし、コンテナワークロードにおいて EC2 のプライベート IP が必要となるユースケースそのものについてはもしかしたら避けるべきものかもしれません。ユースケースを伺わないことには詳細に言及できないため、必要であればご担当するAWSのソリューションアーキテクト、もしくはTwitter: @toricls までご連絡いただければ幸いです。ディスカッションしましょう。
- Q. AWS Batchの活用において、大規模バッチでのデータベースやキャッシュサーバーへの同時接続数エラー回避のためのベストプラクティスはありますでしょうか？
- 万能な回避策というのはありませんが、データベースへの接続元ジョブ側でのリトライ回数の調整、AWS Batchでの最大vCPU数の制限、データベース側でのリードレプリカ設置などを一つづつ確認・調整していくことをお勧めしています。
- Q. AWS Batchについて、Step FunctionsでもFargate, Lambdaと組み合わせるとバッチ処理は可能かと思います。使い分けはどのように考えたら良いでしょうか？スポットインスタンス（コスト）、GPU以外で何かありましたらお教えください。
- いずれの場合も同じような仕組みを組むことは可能と思いますが、AWS Batchをご利用いただくことで、ジョブを管理するためのコード（リトライやキャンセル処理なども含む）を書く必要がなくなります。また、ご認識の通り、FargateやLambdaよりも一般にEC2インスタンスのほうが時間あたりの料金は安価になっておりますので、特に処理量・時間が大きくなる場合はAWS Batchをご検討いただければと思います。
おわりに
2020年は、様々な切り口からのスポットインスタンスの活用に関するセミナーを企画しようとしています。スポットインスタンスを含め、EC2サービスに関連する今後のセミナー予定は https://awsj-compute.connpass.com/ に掲載していきます。みなさまのご登録をお待ちしております。