Category: EC2 Spot Instances


EC2 スポットインスタンスでワークロードの停止と再開が可能に

EC2 スポットインスタンスは EC2 のコンピューティング容量をオンデマンドレートの 90% オフまで許可することができます。特定のサイズのインスタンス数をリクエストできるようにしてから、スポットフリート自動スケーリングスポットフリートをサポートすることでスポットインスタンスをより便利そして柔軟にし、ユーザーが希望するレベルのコンピューティング容量を維持できるようにしました。

EC2 ユーザーはこれまでも EBS ボリュームをアタッチした状態を維持しながら実行中のインスタンスを停止させることができ、インスタンスの実行が再開すると停止した所から自動的に始めるアプリケーションの使用を可能にしていました。

スポットワークロードの停止と再開
そして本日、こうした 2 つの重要な機能を組み合わせ、容量が利用不可能になった場合または入札価格以下になった場合にインスタンスを停止 (終了する代わりに) することで、スポット入札やスポットフリートをセットアップできるようにしました。停止状態のインスタンスにアタッチしている EBS ボリュームは EBS-backed ルートボリュームと同様にそのまま維持されます。キャパシティが利用可能になるとインスタンスが開始し、アプリケーションのプロビジョニングや EBS ボリュームのセットアップ、データのダウンロード、ネットワークドメインへの参加などに時間を費やす必要なく引き続き実行することができます。

AWS をご利用されている多くのお客様がアプリケーションを強化してチェックポイントの作成と活用を行い、EC2 プロセスでの開始/停止の機能を利用することで耐障害性を向上させています。そうしたお客様はこのようなアプリケーションをスポットインスタンスで実行できるようになり、平均 70%-90% の節約を実現できます。

インスタンスが停止している間、EBS 最適化、ユーザーデータ、Ramdisk ID、Delete on Termination の属性を変更することができます。停止状態にあるスポットインスタンスはコンピューティング時間に対して料金を請求することはありませんが、アタッチ済みの EBS ボリュームの容量には通常料金が適用されます。

スポット入札またはスポットフリートの作成や停止/開始の使用を特定する方法については次をご覧ください。

主要事項
この機能はスポットインスタンスが利用可能なすべての AWS リージョンで今すぐご利用いただけます。これは新しい EC2 インスタンスと EBS ボリュームの秒単位による請求で上手く機能するように設計されており、スポットインスタンスが提供する以上のコスト節約の方法としても可能性があります。

EBS ボリュームは常に特定のアベイラビリティーゾーン (AZ) 内にあります。そのため、スポットとスポットフリートは特定の AZ が常にその AZ で再起動するようにリクエストします。

幅広く様々なインスタンスタイプが含まれている可能性のあるスポットフリートとこの機能を組み合わせる場合はご注意ください。フリートの構成は時間が経過するに連れて変更することもあるので、アカウントの IP アドレスや EBS ボリュームの制限にご注意ください。

この機能を使用した新しくクリエイティブな利用法について皆さんからの声が届くのを楽しみにしています。利用しているアプリケーションがスポットインスタンスには適さないと思っていた方や、中断時に対応するためのオーバーヘッドが高すぎるとお考えの方は、詳しく調べてみることをぜひお勧めします。

Jeff;

Amazon EC2 スポットインスタンスを利用した Amazon ECSクラスターの起動

この記事は気前よく次の方から寄贈されました。

Chad Schmutzer, Solutions Architect Shawn O'Conner, Enterprise Solutions Architect
Chad Schmutzer
Solutions Architect
Shawn O’Connor
Solutions Architect

 

本日、Amazon EC2 Container Service(Amazon ECS)が、ECSコンソール上から直接 Amazon EC2 Spot Instances上に ECSクラスターを起動させる機能をサポートする事を発表しました。

スポットインスタンスを利用すると、Amazon EC2の余剰コンピュートキャパシティに入札することが出来ます。スポットインスタンスは通常、オンデマンドインスタンスよりも50-90%安い価格です。スポットインスタンス上でECSクラスターを起動することで、既存のコンテナ化されたワークロードの実行コストを削減したり、同じ予算を維持しながら、コンピュートキャパシティを2倍から10倍に増やすことが可能です。もしくは、その両方を実現することもできます!

スポットインスタンスを利用する場合、インスタンス時間あたりに支払う価格を指定します。現在のスポットプライスを上回る価格で入札している間、スポットインスタンスは起動します。スポットプライスの上昇によりインスタンスが回収された場合、インスタンスが実行された分の時間は請求されません。

ECSコンソールはスポットインスタンスをデプロイするために、 Spot Fleetを利用します。Spot Fleetは、利用者にとって最も良い価格となる様にスポットインスタンスを起動し、コンテナ化したアプリケーションの為にリクエストしたターゲットキャパシティ(インスタンスやvCPUの数で表現される)をデプロイしようします。スポットプライスや、空き容量の変化によってスポットインスタンスが回収された場合、Spot Fleetはターゲットキャパシティを維持しようとします。

コンテナはSpot Fleetが大きくなる多様なリソースプールに適してします。Spot Fleetを利用すると複数のスポットインスタンスプール(インスタンスタイプとアベイラビリティゾーンの組み合わせ)に渡ってキャパシティをプロビジョニング出来き、アプリケーションの可用性を向上させ、時間経過と共に運用コストを削減できます。ECSが提供する拡張性と柔軟性を備えたコンテナ配置システムとSpot Fleetとの組み合わせはコンテナ化されたワークロードを効率的にデプロイし、わずかなコストであらゆる規模のクラスタを容易に管理できます。

従来は、スポットインスタン上へのECSクラスタのデプロイは手動で行われてました。この記事では、ECSコンソール上からのSpot Fleetとの新しいインテグレーションによって、高い可用性とスケーラビリティをどの様に実現し、コンテナ化したワークロードをどの様にコストを削減するのかを紹介します。また、AWS CloudFormationを利用し、スポットインスタンス上にECSクラスターを構築する方法も紹介します。

 

スポットインスタンスで実行するECSクラスタの作成

AWS マネージメントコンソールを利用してECSクラスタを作成することが可能です。

  1. Amazon ECSコンソールを開きます。 https://console.aws.amazon.com/ecs/
  2. ナビゲーションパネル上でClustersを選択します。
  3. Clustersページでは、Create Clusterを選択します。
  4. Cluster nameに名前を入力します。
  5. インスタンス設定では、プロビジョニングモデルとしてSpotを選択します。

ECS Create Cluster - Spot Fleet

配置戦略の選択

2つの利用可能なSpet Fleet配置戦略はDiversified戦略かLower price戦略です。

ECS Spot Allocation Strategies

Spot Fleetで選択した配置戦略は、利用可能なスポットインスタンスプールからSpot Fleetをどの様に満たすかを決定します。diversified戦略を使用すると、スポットインスタンスは全てのプールにわたって分散されます。lowest price戦略を選択した場合、リクエストで指定された最低価格のプールから取得されます。

各インスタンスタイプ(各インスタンスファミリ内のインスタンスサイズ、例えばc4.4xlarge)、各アベイラビリティゾーン、各リージョンで、キャパシティで別れたプールであり、別々のスポットマーケットであることに注意してください。可能な限り異なったインスタンスタイプとアベイラビリティゾーンにまたがって多様にすることで、fleetの可用性を向上することができます。また、時間の経過とともにスポットプライスが上昇することに対しての反応を低くすることができます。

Spot Fleet Market

Spot Fleetに利用するインスタンスタイプを6種類まで選択可能です。この例では、m3,m4,c3,c4,r3,そしてr4のxlargeを選択しています。

Spot Instance Selection

インスタンスの為に入札価格を入力する必要があります。一般的には、オンデマンドインスタンス価格かそれに近い価格で入札するが良い出発点です。そのスポットプールのインスタンスタイプに支払うつもりがある最大価格が入札価格になります。スポット価格が入札価格と同じ、または下回っている間、スポット価格を支払います。低い価格での入札はコストを低減させ、高い価格での入札はインスタンスの中断の確率を下げます。

クラスターに所属するインスタンスの数を設定します。Spot Fleetはリクエストで特定されたターゲットキャパシティを満たす様にスポットインスタンスを起動しようとします。

最新のECS最適化AMIがSpot Fleetがインスタンス時に使用されます。

ストレージとネットワークの設定を行います。多様性と高可用性を実現する為に、複数のアベイラビリティゾーンとなる様にsubnetを選択する様にします。singleのSpot Fleetでは、同じアベイラビリティゾーンにある複数のサブネットを選択する事はできません。

ECSコンテナエージェントがECSのAPIをコールします。エージェントが実行されるコンテナインスタンスはに、エージェントの所有者を知るためにecsInstanceRole IAMポリシーとロールが必要です。

Spot Fleetを利用するマネージドコンピュート環境を作成した場合、入札、起動、インスタンスの終了するためのSpot Fleet権限を付与したロールを作成しなくてはなりません。このロールはECSコンソールから作成できます。

ECSコンソールでの作用はこれだけです!Spot Instance上で稼働するるECSクラスターを起動する為に作成を選択してください。

スポットインスタンス上で稼働するECSクラスターのデプロイにAWS CloudFormationを利用する

リファレンスアーキテクチャとなるAWS CloudFormationテンプレートを公開しています。このテンプレートはCloudFormationスタックの起動や、スポットインスタンス上でのECSクラスタのデプロイがどれくらい簡単をデモンストレーションします。

CloudFormationテンプレートには 以前投稿したSpotインスタンスの終了通知スクリプトだけではなく、いくつかの追加のロギングやその他のサンプル機能が含まれています。Amazon EC2 Spot Instance GitHub上のレポジトリからCloudFormationテンプレートを見つけることができます。

環境に応じてカスタマイズを実施して試してみてください!

Spot Fleet Architecture

終了のハンドリング

スポットインスタンスでは、指定した価格以上を支払う必要はありません。もしスポット価格があるインスタンスで入札を上回った場合、そのインスタンスは自動的に終了されます。

スポットインスタンスの終了を防ぐための最も良い方法は、コンテナ化されたアプリケーションをフォールトトレラントなアーキテクチャにすることです。加えて、スポットインスタンスの終了通知機能を利用することもできます。それはEC2がスポットインスタンスを終了する前に2分間の警告を提供します。

この警告は、インスタンスメタデータ内の項目を使用して、スポットインスタンス上のアプリケーションで使用可能になります。コンソールを利用してスポットインスタンス上にECSクラスターをデプロイした場合、AWSはインスタンス終了通知を5秒毎に確認するスクリプトをインストールします。通知を検知した場合、スクリプトはコンテナインスタンスの状態をDRAININGにただちにに更新します。

簡略したバージョンのスポットインスタンス終了通知は次の様になります。

#!/bin/bash

while sleep 5; do
  if [ -z $(curl -Isf http://169.254.169.254/latest/meta-data/spot/termination-time) ]; then
    /bin/false
  else
    ECS_CLUSTER=$(curl -s http://localhost:51678/v1/metadata | jq .Cluster | tr -d \")
    CONTAINER_INSTANCE=$(curl -s http://localhost:51678/v1/metadata \
      | jq .ContainerInstanceArn | tr -d \")
    aws ecs update-container-instances-state --cluster $ECS_CLUSTER \
      --container-instances $CONTAINER_INSTANCE --status DRAINING
  fi
done

コンテナインスタンスをDRAININGにセットすると、ECSによって、新しいタスクのコンテナインスタンスへの配置がスケジュールされなくなります。リソースが利用可能な場合、代替サービスタスクはクラスター内の別のコンテナインスタンスで開始されます。コンテナインスタンスのドレイニングにより、クラスタ内のタスクに影響を与えない様にクラスターからコンテナインスタンスを削除することができます。PENDING状態にあるコンテナインスタンス上のサービスタスクは直ちに停止します。

コンテナインスタンス上でRUNNING状態にあるサービスタスクは停止し、サービスデプロイ設定パラメータであるminimumHealthyPercentとmaximumPercentに従い、再配置されます。

実際のスポットインスタンス上のECS

どの様にお客様がスポットインスタンス上でECSクラスターをすでに起動しているか知りたいですか?Mapboxにいる友人はこの様にしています。

Mapboxはカスタムマップをデザインし、公開するためのプラットフォームです。同社はマップを作成する為に1日に1億マイルを超えるセンサーデータの収集と実行するバッチプロセッシングアーキテクチャー全体の実行にECSを利用しています。彼らはスポットインスタンスを使用したECSを利用することでバッチプロセッシングアーキテクチャを最適化しています。

Mapboxプラットフォームは5000を超えるアプリケーションを起動し、各月で2億ユーザ以上に達しようとしています。それらのバックエンドはECS上で動いていて、1日あたり13億リクエスト以上を処理しています。Mapbox社の最近のECSへのマイグレーションについてより学びたい場合は、同社のブログである、We Switched to Amazon ECS, and You Won’t Believe What Happened Next. を読んでください。そして、フォローアップ記事である、 Caches to Cashでは、EC2のコストを50-90%節約しながら、同社がスポットインスタンス上でどの様にプラットフォーム全体を動かしているのかを学んでください。

結論

スポットインスタンスを利用してスケールし、コスト効率よくコンテナ化したアプリケーションを動かす事について、私たちと同じ様に読者の方も興奮している事を願います。さらなる情報については、次のページを確認してください。

コメントや提案があるかたは下記よりコメントをください。

原文:Powering your Amazon ECS Cluster with Amazon EC2 Spot Instances(翻訳:SA浅野)
 

CloudWatch Metrics for Spot Fleets

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく(1台のインスタンスから何千台のインスタンスまで)費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応

私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが(可能な限り費用対効果を高めるよう変化)、フリート自体はその属性を保持します。

新しいスポットフリート メトリックス

スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます:スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。

下記メトリックスは各スポットフリート毎に取得されます。(これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります)

  • AvailableInstancePoolsCount
  • BidsSubmittedForCapacity
  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • DiskWriteOps
  • EligibleInstancePoolCount
  • FulfilledCapacity
  • MaxPercentCapacityAllocation
  • NetworkIn
  • NetworkOut
  • PendingCapacity
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System
  • TargetCapacity
  • TerminatingCapacity

 メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、

  • AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。
  • BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。
  • EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか(1)スポット価格がオンデマンド価格より高い場合、または(2)入札価格がスポット価格よりも低い場合にはプールが不適用となります。
  • FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。
  • PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。
  • PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。
  • TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。
  • TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。

これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。

  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • FulfilledCapacity
  • NetworkIn
  • NetworkOut
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System

これらのメトリックスを利用することでアベイラビリティゾーン、インスタンスタイプをまたいだの負荷の許容可能な分布確認をすることができます。

フリート全体の使用率を把握するためにMax、Min、またはAvgを使用しメトリックを集計することができます。一方で、2種類以上のインスタンスからなるフリートでは、Avgを使用すること自体意味がないことにもご注意ください!

利用可能

この機能はすでにご利用頂けます。

— Jeff (翻訳は酒徳が担当しました。本文はこちら:https://aws.amazon.com/jp/blogs/aws/new-cloudwatch-metrics-for-spot-fleets/)