Amazon Web Services ブログ
【開催報告】「 クラウド最適化コンテナ編 ～コンテナ x Graviton2 x スポットインスタンスによるコスト最適化～」セミナー
EC2スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2021年8月26日にオンラインで開催された「クラウド最適化コンテナ編 ～コンテナ x Graviton2 x スポットインスタンスによるコスト最適化～」セミナーでは、150名近くの聴衆の方々にご参加いただき、AWSからの技術解説、またAmazon ECSとAmazon EKSそれぞれをお使いの2社のお客様による、Amazon EC2スポットインスタンスを使いこなすための具体的な活用方法をご紹介いただきました。
本記事では、お客様のご登壇資料を含む当日資料をご紹介し、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。
当日アジェンダと資料
14:05-14:40 理想のアプリケーション基盤の実現 〜 普及期にはいったコンテナとスポットインスタンス
講師：アマゾン ウェブ サービス ジャパン株式会社 プリンシパルソリューションアーキテクト 荒木 靖宏、ソリューションアーキテクト 滝口 開資
概要：2021年のアプリケーション開発ではスピードが求められ、無駄なことを省く必要性がさらに重要になっています。そこで、マネージドサービスを活用してビジネスのコア部分の開発に注力することが極めて重要です。そして、コア部分の実装にコンテナ技術を採用するのは、現在の主流となって久しいです。コンテナ基盤としてなお残っていくEC2インフラストラクチャの管理を省力化し、さらにビジネス要求に応えるためのコスト最適化を同時に推進することが求められます。本セッションでは、2021年現在のコンテナコンピューティングのためにAWSがご提供できる技術を全てお話しました。また、EC2スポットインスタンス、そしてARMアーキテクチャによるGraviton2インスタンスタイプを紹介し、それぞれを組み合わせたときの意義と価値を紹介しました。
資料：https://pages.awscloud.com/rs/112-TZM-766/images/20210826-Cloud-Container-Optimization-Keynote.pdf
14:40-15:00 Amazon ECS – EC2スポットインスタンス / Fargate Spot ことはじめ
講師：アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 石本 遼
概要：ミックスインスタンスグループ機能・Amazon ECS キャパシティープロバイダーによる EC2スポットインスタンス・Fargate Spot の活用方法をイチからお伝えしました。また、スポットリソースを利用する上で避けることのできない中断処理や、需要の高まりによってスポットリソースが確保できない状況をうまく乗り越える方法について、ご紹介しました。
資料：https://pages.awscloud.com/rs/112-TZM-766/images/20210826-Cloud-Container-Optimization-ECS.pdf
15:00-15:20 お客様事例 – ECS on EC2 環境におけるキャパシティープロバイダーとスポットインスタンスの活用事例
講師：シルバーエッグ・テクノロジー 株式会社 エンジニアリング部インフラストラクチャーチーム 白井 慎太郎 様
概要：負荷の増減が激しいウェブサービスに対して、突発的なトラフィックの増加に対応できるように自動スケーリングの仕組みを実装し、さらにスポットインスタンスを積極的に活用することでコスト最適化に成功されました。本セッションでは、オンデマンドとスポットインスタンスを混在させることで可用性を保ちつつも、ECS on EC2 の本番環境にてキャパシティープロバイダーで自動スケーリングの仕組みを実装し、スポットインスタンスで運用した経験をもとに知見をご共有いただきました。
資料：https://pages.awscloud.com/rs/112-TZM-766/images/20210826-Cloud-Container-Optimization-Silveregg.pdf
15:40-16:00 Amazon EKS における EC2 スポットインスタンスをもっと身近に
講師：アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 落水 恭介
概要：AWS での Kubernetes の実行を容易にするマネージド型サービスである Amazon EKS では、コスト最適化のためにコンテナ実行環境である EC2 においてスポットインスタンスを活用できます。本セッションでは、セルフマネージド型ノード、マネージド型ノードグループにおける EC2 スポットインスタンスの活用方法についてご紹介しました。
資料：https://pages.awscloud.com/rs/112-TZM-766/images/20210826-Cloud-Container-Optimization-EKS.pdf
16:00-16:20 お客様事例 2 – 「家族アルバム みてね」におけるスポットインスタンスを安定運用するための工夫
講師：株式会社ミクシィ みてね事業部 SREチーム 生島 光 様
概要：「家族アルバム みてね」では、EKSのノードにスポットインスタンスを活用されています。スポットインスタンスの比率は90%を超え、コスト削減に大きく貢献しています。スポットインスタンスをメインに使っている中で、インスタンスの中断に耐えるための工夫や、オンデマンドインスタンスとの使い分けなどをご紹介いただきました。
16:40-17:00 AWS Batch x Spot: AWS Fargate 対応記念 EC2との使い分けは？
講師：アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 宮本 大輔
概要：AWS Batch は、コンテナを基にした大規模バッチ処理環境をフルマネージドで提供するサービスであり、スポットインスタンスも活用することで、大量の処理をコストパフォーマンスよく実施することが可能です。また、2020年12月より計算環境として Fargate/Fargate Spot にも対応し、0.25 vCPU のような細かいリソース割り当てが行えるようになり、これまで以上に幅広い領域で活用できるようになりました。本セッションでは、この Fargate/Fargate Spot の使いどころや注意点、EC2との使い分けについてご紹介しました。
資料：https://pages.awscloud.com/rs/112-TZM-766/images/20210826-Cloud-Container-Optimization-AWS_Batch.pdf
17:00-17:20 マルチアーキテクチャ・コンテナのデリバリー : AWSのコンテナサービスと AWS Graviton2 の活用
講師：アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 林 政利
概要：現在のコンテナ実行環境はCPUアーキテクチャを抽象化しており、Graviton2 など Arm アーキテクチャの環境も ECS や EKSなどの AWS コンテナサービスで身近に利用できるようになっています。このセッションでは、マルチアーキテクチャ・コンテナについて技術的なポイントを整理してお伝えしました。また、実際に ECS や EKS など AWS のコンテナサービスで Graviton2 の環境を組み込み、CI/CD でマルチアーキテクチャをサポートしたコンテナイメージをデリバリーしてコストパフォーマンスを最適化する方法についてご紹介しました。
Q&Aのご紹介
当日いただいたQ&Aをいくつかご紹介します。
「Amazon ECS – EC2スポットインスタンス / Fargate Spot ことはじめ」へのQ&A
- Q. スポットインスタンスがシャットダウンされる場合、シャットダウン終了後に代替のインスタンスが起動され始めるのでしょうか。それともシャットダウンを開始した時点で代替のインスタンスが起動を始めるのでしょうか。
- ECSサービスの場合、シャットダウンが終了し、スポットインスタンスが削除された後に、Auto Scalingグループの台数維持機能により代替インスタンスが起動される動作になります。具体的には、スポットインスタンスが削除されるタイミングでAuto Scalingグループの稼働中台数が減り、これを検知したAuto Scalingサービスが追加のスポットインスタンスを補充する、という動作になります。
- Q. アプリケーション側で例えばSIGTERMを直接受け取らないとき、バックエンドインスタンスをエラーなく中断させることはできるでしょうか。
- ECSタスク(コンテナアプリケーション)内でSIGTERMをハンドリングしない場合でも、EventBridge経由で中断通知イベントを受信することができます。ですので、これをトリガーにしてEC2のレイヤーで中断に備えた準備処理を実装することは可能です。ただしこの方法には限度があります。例えばログファイルの退避、ロードバランサーからの登録解除といった、アプリケーションの外から操作可能な処理は実装できる場合が多いと考えます。一方、アプリケーションのメモリ上にあるデータを書き出すといった、アプリケーション内部にかかわる処理は実現できないことにご留意ください。
「Amazon EKS における EC2 スポットインスタンスをもっと身近に」へのQ&A
- Q. 中断通知を受け取った後、SIGKILLが発行されるまで猶予期間があると思います。コンテナアプリケーションにSIGKILLが発行されるまでエンドユーザーが利用し続けていた場合、そのセッションは切断されることになりますか。
- はい。処理中のリクエストが SIGKILL までの猶予期間が経過するまで完了しない、もしくはスポットインスタンスの中断が行われるまで完了しない場合、処理中のリクエストは失敗します。ただし、ご質問のような状況になるケースは限定的なことも多いかもしれません。 リクエストからレスポンスまでの所要時間が数秒程度となるような処理に対しては、SIGKILL までの猶予期間、およびスポットインスタンスの中断 (2分前) に対して十分に小さいレスポンスタイムとなるようにアプリケーションや API を設計するため、このような場合にはご質問の状況は極めて発生しにくいです。
「『家族アルバム みてね』におけるスポットインスタンスを安定運用するための工夫 」へのQ&A
- Q. スポットインスタンスが起動できない状況に対する機能テストはどのように実施されたのですか。
- スポットインスタンスを利用する Auto Scaling グループの最大容量値を小さい値に設定しました。希望する容量が増えない状況を敢えて作ることで「スポットインスタンスのキャパシティが不足して希望する容量を増やせない状況」を再現しています。
- Q. Priority Expanderの機能テストで、kubernetessのノードグループをすべてシャットダウンさせるというのはkubernetessの機能によって実現できるでしょうか。
- こちらも同じく、スポットインスタンスを利用する Auto Scaling グループの最大容量値を小さい値に設定しました。希望する容量が増えない状況を敢えて作ることで「スポットインスタンスのキャパシティが不足して希望する容量を増やせない状況」を再現しています。なおこちらはKubernetesのレベルではなく、EC2 Auto Scalingレベルの操作です。
「AWS Batch x Spot: AWS Fargate 対応記念 EC2との使い分けは？」へのQ&A
- Q. AWS BatchはコンテナジョブのワークロードのDockerイメージ化が必須ですか。
- はい。AWS Batchでは、コンテナ化が必須となります。コンテナ化が困難で、大量のEC2インスタンスが必要となる大規模なワークロードに対しては、AWS ParallelClusterをご検討ください。AWS ParallelClusterはSlurmのようなオープンソースのジョブスケジューラに対応し、EC2インスタンスを管理することができます。
- Q. AWS BatchはEC2インスタンス上で動くような定期実行cronジョブを動かすようなサービスではない認識であっていますか。
- 例えばEventBridgeを用いて、定期的にAWS Batchにジョブを投入することは可能です。一方で、AWS Batchサービスの方向性は大規模処理向けのものです。厳密な時刻に処理を開始しないといけなかったり、必ず一定期間内に終わらせる必要がある場合は適切ではない場合があります。Fargateの活用を含めたAWS BatchとEventBridgeの組み合わせは、こういった要件が緩いワークロードに対してご検討ください。
「マルチアーキテクチャ・コンテナのデリバリー : AWSのコンテナサービスと AWS Graviton2 の活用」へのQ&A
- Q. あえてCPUアーキテクチャを複数にする利点はどこにあるのでしょうか。
-
複数CPUアーキテクチャ・コンテナが必要になるケースとして、次のようなシナリオが考えられます。このような場面ではマルチアーキテクチャ環境が有力な選択肢です。
- コストパフォーマンス向上のためにarmのインスタンスを使いたいが、段階的な移行のために一時的に複数のアーキテクチャで稼働させるる
- ARM環境に向けてデプロイする想定だが、開発マシン・デバイスがx86のため、複数アーキテクチャで稼働できるコンテナイメージを準備する
- ミドルウェアやツールの開発で、複数CPUアーキテクチャに対応した製品を作成する
- Q. buildx等でクロスコンパイルしたコンテナイメージに比べて、本セッションの方式の方がコンテナイメージのサイズが小さくなる、という認識で正しいでしょうか。となると、クロスコンパイル自体にどのような利点があるのか、疑問が生じています。
- クラウド環境では、ARMなどマルチアーキテクチャのマシンを容易に調達できることもあり、クロスコンパイルの必要性が薄くなることは確かです。またbuildxは仮想環境を利用するため、実行に時間が掛かる、というデメリットもあります。一方で、ローカルの開発環境でビルドやユニットテストを実行したいケースや、クラウド上で用意が無いアーキテクチャに向けてビルドする必要があるケースでは、buildxのようなツールに加えて、 Go言語や Rustなどのプログラミング言語が提供しているクロスコンパイル機能を活用できます。また、バイナリが入っていないベースイメージ(scratch)はマルチアーキテクチャで利用できるため、GoやRustをクロスコンパイルして scratch をベースにイメージをビルドすることで、一つの環境で迅速にマルチアーキテクチャイメージを作成するようなアイデアも考えられます。
おわりに
今回はコンテナサービスとスポットインスタンス、そしてGraviton2の組み合わせについて、最新の技術情報と、先駆者のお客様による最新の運用事例と工夫のポイントをご紹介いたしました。Amazon EC2サービスに関連する今後のセミナー予定は https://awsj-compute.connpass.com/ に掲載していきます。今後も引き続き、様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。