AWS スポットインスタンスでのスケーラブルな API の構築

こんにちは、みんな！ 私の名前はキリルです。Adapty の CTO です。 私たちのアーキテクチャの大部分は AWS 上にあります。今日は、本番環境でスポット インスタンスを使用することでサーバー コストを 3 倍削減した方法と、その自動スケーリングを設定する方法について説明します。 最初にその仕組みの概要が説明され、次に開始するための詳細な手順が説明されます。

スポットインスタンスとは何ですか?

スポット インスタンスは、現在アイドル状態にある他の A​​WS ユーザーのサーバーであり、大幅な割引価格で販売されます (Amazon は最大 90%、私たちの経験では最大 3 倍書き込みますが、リージョン、アリゾナ州、インスタンス タイプによって異なります)。 通常のものとの主な違いは、いつでもオフにできることです。 したがって、私たちは長い間、これらを未使用の環境や、中間結果を S3 またはデータベースに保存して何かを計算するタスクに使用するのが普通であり、販売には使用しないのが普通だと考えていました。 本番環境でスポットを使用できるようにするサードパーティのソリューションもありますが、私たちの場合には多くの困難があるため、それらは実装しませんでした。 この記事で説明されているアプローチは、追加のスクリプトやクラウンなどを必要とせず、完全に AWS の標準機能内で機能します。

以下は、スポット インスタンスの価格履歴を示すいくつかのスクリーンショットです。

eu-west-5 (アイルランド) リージョンの m1.large。 価格は 3 か月間ほぼ安定しており、現在 2.9 倍の割引になっています。

us-east-5 地域 (バージニア北部) の m1.large。 価格は 3 か月にわたって常に変化しており、現在、アベイラビリティーゾーンに応じて 2.3 倍から 2.8 倍まで割引されています。

us-east-3 リージョン (バージニア北部) の t1.small。 価格は 3 か月間安定しており、現在 3.4 倍の割引になっています。

サービスアーキテクチャ

この記事で説明するサービスの基本的なアーキテクチャを次の図に示します。

アプリケーション ロード バランサー → EC2 ターゲット グループ → Elastic Container Service

Application Load Balancer (ALB) は、EC2 ターゲット グループ (TG) にリクエストを送信するバランサーとして使用されます。 TG は、ALB のインスタンスでポートを開き、それらを Elastic Container Service (ECS) コンテナのポートに接続する責任があります。 ECS は、AWS の Kubernetes に相当し、Docker コンテナを管理します。

XNUMX つのインスタンスには同じポートを持つ複数のコンテナが実行される可能性があるため、それらを固定的に設定することはできません。 ECS は、新しいタスク (Kubernetes の用語ではこれをポッドと呼びます) を起動していることを TG に伝え、インスタンス上の空きポートを確認し、そのうちの XNUMX つを起動されたタスクに割り当てます。 また、TG はヘルスチェックを使用してインスタンスと API が動作しているかどうかを定期的にチェックし、問題が見つかった場合はリクエストの送信を停止します。

EC2 Auto Scaling グループ + ECS キャパシティ プロバイダー

上の図には、EC2 Auto Scaling Groups (ASG) サービスは示されていません。 名前から、インスタンスのスケーリングを担当することがわかります。 ただし、AWS には最近まで、ECS から実行中のマシンの数を管理する機能が組み込まれていませんでした。 ECS により、CPU 使用率、RAM、リクエスト数などによってタスクの数をスケールできるようになりました。 ただし、タスクがすべての空きインスタンスを占有している場合、新しいマシンは自動的に作成されません。

これは、ECS キャパシティ プロバイダー (ECS CP) の出現により変わりました。 ECS の各サービスを ASG に関連付けることができるようになり、タスクが実行中のインスタンスに適合しない場合は、新しいタスクが発生します (ただし、確立された ASG 制限内で)。 これは逆方向にも機能し、ECS CP がタスクのないアイドル状態のインスタンスを検出した場合、それらをシャットダウンする ASG コマンドを与えます。 ECS CP には、インスタンス負荷の目標パーセンテージを指定する機能があり、特定の数のマシンがタスクを迅速にスケーリングできるように常に空きます。これについては後ほど説明します。

EC2 起動テンプレート

このインフラストラクチャの作成について詳しく説明する前に、最後に説明するサービスは EC2 Launch Templates です。 これにより、すべてのマシンが起動するテンプレートを作成できるため、毎回最初からこれを繰り返す必要がなくなります。 ここでは、起動するマシンのタイプ、セキュリティ グループ、ディスク イメージ、その他多くのパラメータを選択できます。 起動されたすべてのインスタンスにアップロードされるユーザー データを指定することもできます。 ユーザーデータ内でスクリプトを実行できます。たとえば、ファイルの内容を編集できます。 ECS エージェントの構成.

この記事の最も重要な構成パラメータの XNUMX つは次のとおりです。 ECS_ENABLE_SPOT_INSTANCE_DRAINING=本当です。 このパラメータが有効な場合、ECS はスポット インスタンスが削除されるという信号を受信するとすぐに、そのインスタンスで作業するすべてのタスクをドレイン ステータスに転送します。 このインスタンスには新しいタスクは割り当てられません。すぐにロールアウトしたいタスクがある場合、それらはキャンセルされます。 バランサーからのリクエストも来なくなります。 インスタンスの削除の通知は、実際のイベントの 2 分前に行われます。 したがって、サービスが 2 分を超えてタスクを実行せず、ディスクに何も保存しない場合は、データを失うことなくスポット インスタンスを使用できます。

最近のディスク - AWS について した ECS と Elastic File System (EFS) を併用することも可能で、この方式ではディスクがあっても障害になりませんが、原理的には状態を保存するためにディスクが必要ないため、これは試しませんでした。 デフォルトでは、SIGINT (タスクが Draining ステータスに転送されたときに送信される) を受信した後、実行中のすべてのタスクは、まだ完了していない場合でも 30 秒後に停止されます。この時間はパラメータを使用して変更できます。 ECS_CONTAINER_STOP_TIMEOUT。 主なことは、スポットマシンの場合は2分以上に設定しないことです。

サービスの作成

説明したサービスの作成に進みましょう。 その過程で、上では触れなかったいくつかの役立つポイントについても説明します。 一般に、これは段階的な説明ですが、非常に基本的な場合や、逆に非常に特殊な場合については考慮しません。 すべてのアクションは AWS ビジュアル コンソールで実行されますが、CloudFormation または Terraform を使用してプログラムで再現できます。 Adapty では Terraform を使用しています。

EC2 起動テンプレート

このサービスは、使用されるマシンの構成を作成します。 テンプレートは、[EC2] -> [インスタンス] -> [テンプレートの起動] セクションで管理されます。

Amazon マシンイメージ (AMI) — すべてのインスタンスを起動するディスク イメージを指定します。 ECS の場合、ほとんどの場合、Amazon から最適化されたイメージを使用する価値があります。 定期的に更新され、ECS が動作するために必要なものがすべて含まれています。 現在のイメージ ID を確認するには、次のページにアクセスしてください。 Amazon ECS に最適化された AMI、使用しているリージョンを選択し、その AMI ID をコピーします。 たとえば、us-east-1 リージョンの場合、執筆時点の現在の ID は次のとおりです。 ami-00c7c1cf5bdc913ed。 この ID は、「カスタム値の指定」項目に挿入する必要があります。

インスタンスタイプ — インスタンスのタイプを示します。 あなたのタスクに最適なものを選択してください。

キーペア (ログイン) — 必要に応じて、SSH 経由でインスタンスに接続できる証明書を指定します。

ネットワーク設定 — ネットワークパラメータを指定します。 ネットワーキングプラットフォーム ほとんどの場合、Virtual Private Cloud (VPC) が必要です。 セキュリティグループ — インスタンスのセキュリティ グループ。 インスタンスの前にバランサーを使用するため、ここでバランサーからの受信接続のみを許可するグループを指定することをお勧めします。 つまり、2 つのセキュリティ グループが存在します。80 つはバランサー用で、ポート 443 (http) と XNUMX (https) 上の任意の場所からの受信接続を許可します。XNUMX つ目はマシン用で、バランサー グループからの任意のポートでの受信接続を許可します。 。 両方のグループのアウトバウンド接続は、TCP プロトコルを使用して、すべてのポートのすべてのアドレスに対して開かれる必要があります。 発信接続のポートとアドレスを制限することはできますが、その場合は、閉じられたポート上で何かにアクセスしようとしていないことを常に監視する必要があります。

ストレージ (ボリューム) — マシンのディスクパラメータを指定します。 ディスク サイズは、AMI で指定されたサイズより小さくすることはできません。ECS 最適化の場合、ディスク サイズは 30 GiB です。

高度な詳細 — 追加パラメータを指定します。

購入オプション — スポットインスタンスを購入するかどうか。 希望しますが、ここではこのボックスをチェックしません。Auto Scaling グループで設定します。そこにはさらにオプションがあります。

IAMインスタンスプロファイル — インスタンスが起動されるロールを示します。 インスタンスを ECS で実行するには、権限が必要です。権限は通常、ロールにあります。 ecsインスタンスロール。 場合によっては作成できる場合もありますが、作成できない場合はここで 命令 これを行う方法について。 作成後はテンプレートに記載させていただきます。
次に多くのパラメータがあります。基本的にどこでもデフォルト値のままで大丈夫ですが、それぞれに明確な説明があります。 EBS に最適化されたインスタンスと T2/T3 Unlimited オプションを使用する場合は常に有効にします 破裂しやすい インスタンス。

操作実働時間 — ユーザーデータを示します。 ファイルを編集していきます /etc/ecs/ecs.config、これには ECS エージェント設定が含まれます。
ユーザーデータの例は次のようになります。

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — このパラメーターは、インスタンスが指定された名前のクラスターに属していること、つまり、このクラスターがそのタスクをこのサーバーに配置できることを示します。 まだクラスターを作成していませんが、作成時にこの名前を使用します。

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — このパラメーターは、スポット インスタンスをオフにする信号を受信したときに、そのインスタンス上のすべてのタスクをドレイン ステータスに転送する必要があることを指定します。

ECS_CONTAINER_STOP_TIMEOUT=1m - このパラメーターは、SIGINT シグナルを受信した後、すべてのタスクが強制終了されるまで 1 分間の猶予があることを指定します。

ECS_ENGINE_AUTH_TYPE=docker — このパラメーターは、Docker スキームが承認メカニズムとして使用されることを示します

ECS_ENGINE_AUTH_DATA=... — Docker イメージが保存されているプラ​​イベート コンテナー レジストリへの接続パラメーター。 パブリックの場合は、何も指定する必要はありません。

この記事では、Docker Hub のパブリック イメージを使用するので、パラメーターを指定します。 ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA それは必要ありません。

知っておくとよいです: 新しいバージョンでは Docker、Linux、ECS エージェントなどのバージョンが更新されるため、AMI を定期的に更新することをお勧めします。これを忘れないようにするには、次のようにします。 通知を設定する 新しいバージョンのリリースについて。 通知をメールで受信して手動で更新することも、更新された AMI を使用して新しいバージョンの起動テンプレートを自動的に作成する Lambda 関数を作成することもできます。

EC2オートスケーリンググループ

Auto Scaling グループは、インスタンスの起動とスケーリングを担当します。 グループは、[EC2] -> [Auto Scaling] -> [Auto Scaling Groups] セクションで管理されます。

起動テンプレート — 前のステップで作成したテンプレートを選択します。 デフォルトバージョンのままにしておきます。

購入オプションとインスタンス タイプ — クラスターのインスタンスのタイプを指定します。 起動テンプレートに準拠すると、起動テンプレートのインスタンス タイプが使用されます。 購入オプションとインスタンス タイプを組み合わせることで、インスタンス タイプを柔軟に構成できます。 使わせていただきます。

オプションのオンデマンドベース — 常に動作する通常の非スポット インスタンスの数。

基準を上回るオンデマンドの割合 — 通常インスタンスとスポット インスタンスの割合。50 ～ 50 が均等に配分され、通常インスタンスごとに 20 ～ 80 の 4 つのスポット インスタンスが発生します。 この例では 50 ～ 50 としますが、実際には 20 ～ 80 が最も多く、場合によっては 0 ～ 100 になります。

インスタンスタイプ — ここで、クラスターで使用される追加のインスタンスのタイプを指定できます。 話の意味がよく分からないので一度も使いませんでした。 おそらくこれは、特定の種類のインスタンスに対する制限が原因ですが、サポートを通じて簡単に増やすことができます。 アプリケーションをご存知の場合は、コメントを読んでいただけると幸いです）

ネットワーク — ネットワーク設定、マシンの VPC とサブネットを選択します。ほとんどの場合、利用可能なすべてのサブネットを選択する必要があります。

ロードバランシング - バランサーの設定ですが、これは個別に行います。ここでは何も触れません。 ヘルスチェック これも後で設定します。

グループサイズ — クラスター内のマシン数の制限と、開始時に必要なマシン数を示します。 メトリックに従ってスケーリングが発生する必要がある場合でも、クラスター内のマシンの数が指定された最小値を下回ったり、最大値を超えたりすることはありません。

スケーリングポリシー — スケーリングパラメータですが、実行中の ECS タスクに基づいてスケーリングするため、後でスケーリングを設定します。

インスタンスのスケールイン保護 — スケールダウン時にインスタンスが削除されないように保護します。 ASG がタスクを実行しているマシンを削除しないように、これを有効にします。 ECS Capacity Provider は、タスクを持たないインスタンスの保護を無効にします。

タグを追加する — インスタンスのタグを指定できます (このためには、[新しいインスタンスにタグを付ける] チェックボックスをオンにする必要があります)。 Name タグを指定することをお勧めします。そうすれば、グループ内で起動されるすべてのインスタンスが同じ名前になり、コンソールで表示するのに便利です。

グループを作成した後、それを開いて [詳細設定] セクションに移動します。作成段階ですべてのオプションがコンソールに表示されないのはなぜですか。

終了ポリシー — インスタンスを削除するときに考慮されるルール。 これらは順番に適用されます。 普段は下の写真のものを使っています。 まず、最も古い起動テンプレートを持つインスタンスが削除されます (たとえば、AMI を更新した場合、新しいバージョンが作成されましたが、すべてのインスタンスはそのバージョンに切り替えることができました)。 次に、次の請求時間に最も近いインスタンスが選択されます。 そして、発売日に基づいて最も古いものが選択されます。

知っておくとよいです: クラスター内のすべてのマシンを更新するため、便利に使用できます。 インスタンスの更新。 これを前のステップの Lambda 関数と組み合わせると、完全に自動化されたインスタンス更新システムが完成します。 すべてのマシンを更新する前に、グループ内のすべてのインスタンスのインスタンスのスケールイン保護を無効にする必要があります。 グループ内の構成ではなく、マシン自体からの保護。これは [インスタンス管理] タブで行われます。

Application Load Balancer と EC2 ターゲット グループ

バランサーは、「EC2」→「ロード・バランシング」→「ロード・バランサー」セクションで作成されます。 Application Load Balancer を使用します。さまざまなタイプのバランサーの比較については、次の URL を参照してください。 サービスページ.

リスナー - ポート 80 と 443 を作成し、後でバランサー ルールを使用して 80 から 443 にリダイレクトするのが合理的です。

アベイラビリティーゾーン — ほとんどの場合、私たちは全員を対象としたアクセシビリティ ゾーンを選択します。

セキュリティ設定を構成する — バランサーの SSL 証明書がここに示されています。最も便利なオプションは次のとおりです。 証明書を作る ACMで。 違いについて セキュリティーポリシー で読むことができます ドキュメンテーション、デフォルトで選択されたままにすることができます ELBSecurityPolicy-2016-08。 バランサーを作成すると、それが表示されます DNS名、ドメインの CNAME を構成するために必要です。 たとえば、Cloudflare では次のようになります。

セキュリティグループ — バランサーのセキュリティ グループを作成または選択します。これについては、上記の「EC2 起動テンプレート」→「ネットワーク設定」セクションで詳しく書きました。

ターゲットグループ — バランサーからマシンにリクエストをルーティングし、問題が発生した場合にそれらを置き換えるためにそれらの可用性をチェックする責任を負うグループを作成します。 対象タイプ インスタンスである必要があります。 プロトコール и ポート 任意。バランサーとインスタンス間の通信に HTTPS を使用する場合は、バランサーとインスタンスに証明書をアップロードする必要があります。 この例では、これは行わず、単にポート 80 のままにします。

ヘルスチェック — サービスの機能をチェックするためのパラメータ。 実際のサービスでは、これはビジネス ロジックの重要な部分を実装する別のリクエストである必要がありますが、この例ではデフォルト設定のままにします。 次に、リクエスト間隔、タイムアウト、成功コードなどを選択できます。この例では、使用される Docker イメージが 200 コードを返すため、成功コード 399 ～ 304 を示します。

ターゲットを登録する — ここではグループの車が選択されていますが、この場合、これは ECS によって行われるため、このステップをスキップします。

知っておくとよいです: バランサー レベルで、特定の S3 に保存されるログを有効にすることができます。 書式。 そこから、分析のためにサードパーティのサービスにエクスポートしたり、S3 内のデータに対して直接 SQL クエリを実行したりできます。 アテナを使用する。 便利で、追加のコードなしで機能します。 また、指定した期間後に S3 バケットからログを削除するように設定することをお勧めします。

ECS タスクの定義

前の手順では、サービス インフラストラクチャに関連するすべてを作成しました。次に、起動するコンテナーの説明に進みます。 これは、「ECS」→「タスク定義」セクションで行われます。

起動タイプの互換性 - EC2を選択します。

タスク実行 IAM ロール - 選ぶ ecsTaskExecutionRole。 これを使用すると、ログが書き込まれ、秘密変数へのアクセスが許可されます。

「コンテナ定義」セクションで、「コンテナの追加」をクリックします。

画像 — プロジェクト コードを含むイメージへのリンク。この例では、Docker Hub のパブリック イメージを使用します。 bitnami/ノード例:0.0.1.

メモリ制限 — コンテナのメモリ制限。 ハードリミット — ハードリミット。コンテナーが指定された値を超えると、docker kill コマンドが実行され、コンテナーはすぐに停止します。 ソフトリミット — ソフト制限。コンテナーは指定された値を超えることができますが、このパラメーターはタスクをマシンに配置するときに考慮されます。 たとえば、マシンに 4 GiB の RAM が搭載されており、コンテナのソフト制限が 2048 MiB である場合、このマシンはこのコンテナで最大 2 つのタスクを実行できます。 実際には、4 GiB の RAM は 4096 MiB よりわずかに少なく、これはクラスターの [ECS インスタンス] タブで確認できます。 ソフト制限はハード制限を超えることはできません。 XNUMX つのタスクに複数のコンテナがある場合、それらの制限は合計されることを理解することが重要です。

ポートマッピング - で ホストポート 0 を示します。これは、ポートが動的に割り当てられ、ターゲット グループによって監視されることを意味します。 コンテナ港 — アプリケーションが実行されるポートは、多くの場合、実行コマンドで指定されるか、アプリケーション コード、Dockerfile などで割り当てられます。 この例では、次のリストにある 3000 を使用します。 ドッカーファイル 使用されている画像。

健康診断 — コンテナーのヘルスチェックパラメーター。ターゲットグループで構成されたパラメーターと混同しないでください。

環境 - 環境設定。 CPUユニット - メモリ制限と同様、プロセッサに関するもののみ。 各プロセッサ コアは 1024 ユニットであるため、サーバーにデュアルコア プロセッサが搭載されており、コンテナーが 512 に設定されている場合、このコンテナーを使用して 4 つのタスクを XNUMX 台のサーバーで起動できます。 CPU ユニットは常にコアの数に対応しており、メモリの場合と同様に、CPU ユニットが少しでも少なくなるということはありません。

Command — コンテナ内でサービスを開始するコマンド。すべてのパラメータはカンマで区切って指定します。 これは、gunicorn、npm などです。 指定しない場合は、Dockerfile の CMD ディレクティブの値が使用されます。 表示します npm,start.

環境変数 — コンテナ環境変数。 これは、単純なテキスト データまたは秘密変数のいずれかです。 シークレットマネージャー または パラメータストア.

ストレージとロギング — ここでは、CloudWatch Logs (AWS のログ用サービス) でのログ記録を設定します。 これを行うには、[CloudWatch Logs の自動構成] チェックボックスを有効にするだけです。 タスク定義を作成すると、CloudWatch にログのグループが自動的に作成されます。 デフォルトでは、ログは無期限に保存されるため、保持期間を無期限から必要な期間に変更することをお勧めします。 これは CloudWatch Log グループで行われ、現在の期間をクリックして新しい期間を選択する必要があります。

ECS クラスターと ECS キャパシティ プロバイダー

ECS → Clusters セクションに移動してクラスターを作成します。 テンプレートとして EC2 Linux + Networking を選択します。

クラスター名 - 非常に重要です。ここでは、Launch Template パラメーターで指定したものと同じ名前を作成します。 ECS_CLUSTER、 私たちの場合には - DemoApiClusterProd。 「空のクラスターを作成する」チェックボックスをオンにします。 オプションで、Container Insights を有効にして、CloudWatch のサービスのメトリクスを表示できます。 すべてを正しく行った場合は、[ECS インスタンス] セクションに Auto Scaling グループで作成されたマシンが表示されます。

タブに移動 キャパシティプロバイダー 新しいものを作成します。 実行中の ECS タスクの数に応じてマシンの作成とシャットダウンを制御する必要があることを思い出させてください。 プロバイダーは XNUMX つのグループにのみ割り当てられることに注意することが重要です。

オートスケーリンググループ — 以前に作成したグループを選択します。

管理されたスケーリング — プロバイダーがサービスを拡張できるように有効にします。

目標容量% — タスクがロードされたマシンの何パーセントが必要か。 100% を指定すると、すべてのマシンが常にタスクの実行でビジー状態になります。 50% を指定すると、車の半分は常に無料になります。 この場合、負荷が急激に増加した場合、新しいタクシーはインスタンスの配備を待つことなく、ただちに無料の車両に乗車します。

管理された終了保護 — 有効にすると、このパラメーターを使用すると、プロバイダーはインスタンスの削除からの保護を解除できます。 これは、マシン上にアクティブなタスクがなく、ターゲット容量% が許可されている場合に発生します。

ECS サービスとスケーリングのセットアップ

最後のステップ:) サービスを作成するには、[サービス] タブで以前に作成したクラスターに移動する必要があります。

発射タイプ — [容量プロバイダー戦略に切り替える] をクリックし、以前に作成したプロバイダーを選択する必要があります。

タスク定義 — 以前に作成したタスク定義とそのリビジョンを選択します。

サービス名 — 混乱を避けるため、常にタスク定義と同じものを示します。

サービスの種類 - 常にレプリカ。

タスクの数 — サービス内のアクティブなタスクの必要な数。 このパラメータはスケーリングによって制御されますが、それでも指定する必要があります。

最低限の健康率 и 最大パーセント — 導入時のタスクの動作を決定します。 デフォルト値は 100 と 200 で、デプロイメント時にタスクの数が数倍に増加し、その後望ましい値に戻ることを示します。 最小 = 1、最大 = 0 の 100 つのタスクが実行されている場合、デプロイメント中にタスクが強制終了され、その後新しいタスクが発生します。つまり、ダウンタイムになります。 1 つのタスクが実行中 (最小 = 50、最大 = 150) の場合、1 つのタスクを半分に分割したり XNUMX 倍に増やすことはできないため、デプロイメントはまったく行われません。

展開タイプ — ローリングアップデートを終了します。

配置テンプレート — タスクをマシンに配置するためのルール。 デフォルトは AZ Balanced Spread です。これは、すべてのアベイラビリティーゾーンのマシンが稼働するまで、新しいタスクがそれぞれ新しいインスタンスに配置されることを意味します。 通常、BinPack - CPU および Spread - AZ を使用します。このポリシーでは、タスクは CPU ごとに XNUMX つのマシンにできるだけ高密度に配置されます。 新しいマシンを作成する必要がある場合は、新しいアベイラビリティ ゾーンに作成されます。

ロードバランサの種類 — [アプリケーション ロード バランサー] を選択します。

サービス IAM ロール - 選ぶ ecsServiceRole.

ロードバランサ名 — 以前に作成したバランサーを選択します。

ヘルスチェックの猶予期間 — 新しいタスクのロールアウト後にヘルスチェックを実行する前に一時停止します。通常は 60 秒に設定します。

コンテナから負荷分散へ — [ターゲット グループ名] 項目で、以前に作成したグループを選択すると、すべてが自動的に入力されます。

サービス自動スケーリング — サービスのスケーリングパラメータ。 [サービスの自動スケーリングの構成] を選択して、サービスの必要な数を調整します。 スケーリング時にタスクの最小数と最大数を設定します。

Service Auto Scaling の IAM ロール - 選ぶ AWSServiceRoleForApplicationAutoScaling_ECSService.

自動タスクスケーリングポリシー — スケーリングのルール。 2 つのタイプがあります:

1. ターゲット追跡 — ターゲットメトリクス (CPU/RAM 使用率または各タスクのリクエスト数) を追跡します。 たとえば、プロセッサの平均負荷を 85% にしたいとします。これが高くなると、目標値に達するまで新しいタスクが追加されます。 逆に、負荷が低い場合は、スケールダウンに対する保護が有効になっていない限り、タスクは削除されます(スケールインを無効にする).
2. ステップスケーリング - 任意のイベントに対する反応。 ここでは、任意のイベント (CloudWatch アラーム) に対する反応を構成でき、イベントが発生したときに、指定した数のタスクを追加または削除したり、タスクの正確な数を指定したりできます。

サービスには複数のスケーリング ルールがある場合があります。これは便利です。重要なのは、それらが互いに競合しないようにすることです。

まとめ

指示に従って同じ Docker イメージを使用した場合、サービスは次のようなページを返すはずです。

1. サービス内のすべてのマシンが起動されるテンプレートを作成しました。 また、テンプレートが変更されたときにマシンを更新する方法も学びました。
2. スポット インスタンス停止信号の処理を構成したため、受信後 XNUMX 分以内に実行中のすべてのタスクがマシンから削除されるため、何も失われたり中断されたりすることはありません。
3. 負荷をマシン全体に均等に分散するためにバランサーを上げました。
4. スポット インスタンス上で実行されるサービスを作成したため、マシンのコストが約 3 分の XNUMX に削減されます。
5. ダウンタイムコストを発生させることなく増加したワークロードを処理できるように、両方向の自動スケーリングを構成しました。
6. アプリケーションがインフラストラクチャ (マシン) を管理するのではなく、その逆ではないように、Capacity Provider を使用します。
7. 私たちは素晴らしいです。

大規模な電子メール キャンペーンで広告を掲載している場合など、負荷の急増が予測できる場合は、次の方法でスケーリングを設定できます。 時刻表.

システムのさまざまな部分からのデータに基づいて拡張することもできます。 たとえば、次のような機能があります 個別のプロモーションオファーの送信 モバイルアプリケーションのユーザー。 キャンペーンが 1 万人以上に送信されることもあります。 このような配布の後は、多くのユーザーが同時にアプリケーションにログインするため、API へのリクエストが常に大幅に増加します。 そのため、プロモーション プッシュ通知を送信するためのキューに、はるかに多くの標準インジケーターがあることがわかった場合は、すぐにいくつかの追加のマシンとタスクを起動して、負荷に備えることができます。

スポット インスタンスと ECS を使用した興味深い事例やスケーリングについてコメントで教えていただければ幸いです。

まもなく、主にサーバーレス スタックで XNUMX 秒あたり数千の分析イベントを (資金を使って) 処理する方法や、GitLab CI と Terraform Cloud を使用してサービスのデプロイメントがどのように機能するかについての記事が掲載される予定です。

ぜひ購読してください。きっと面白いでしょう！

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

実稼働環境でスポット インスタンスを使用しますか?

• 視聴者の３８%がはい6

• 視聴者の３８%がNo18

• 視聴者の３８%が記事で知り、使用する予定です3

27 人のユーザーが投票しました。 5名のユーザーが棄権した。

出所： habr.com