【朗報】Amazon ECSが予測不可能な負荷のスパイクに対するアプリケーションの回復性を向上！
PRONIアイミツ開発チームで、
エンジニアリングをしている deliku といいます。
先日AWSからECSの新機能の発表がありました。個人的にものすごく有難いアップデートだったので、テックブログを通してまだ知らない人の手助けになればと思って書いています。
本日、Amazon Elastic Container Service (Amazon ECS) はタスクスケジューリングを強化し、予測不可能な負荷のスパイクに対するアプリケーションの回復性をさらに向上させました。Amazon ECS は、コンテナまたはロードバランサーのヘルスチェックに合格しなかった異常なタスクを終了する前に、正常な代替タスクを開始するようになりました。この機能の強化により、追加の作業や構成なしで、お客様のアプリケーションの回復性が向上します。
なぜサービス中断が引き起こるのか。
Amazon ECS はスパイクアクセスなどの予測不可能な負荷急増によりサービスの中断を引き起こす可能性がありました。
具体的には下記のようなケースがあります。
Application Load Balancer は登録されたターゲットのステータスをテストするため、定期的にリクエスト（以降ヘルスチェックと呼びます）を送信しています。
スパイクアクセスなどサーバのリソース消費が高くなることを条件にオートスケールが発動し、タスクが一定数増加するように設計していても、オートスケールによるタスク増加完了前にリクエストを受け付ける許容量を超えている場合、ヘルスチェックを受け付けることができなくなります。
なお、ヘルスチェックには正常 / 異常を判断するためのリトライ回数やインターバルを設定することができますが、異常と判断したタスクは終了します。
そのため、オートスケールによるタスク増加よりも前に稼働中のタスクが終了した場合サービスが中断することになります。
アップデートでどのような挙動になるのか
Amazon ECS は、各異常タスクに対して置換を開始して、代替タスクが正常になるまで待ってから、古いタスクの終了を試みるようになりました。お客様は、サービスの maximumPercent (デフォルトは 200%) パラメータを設定することで、Amazon ECS が同時に開始できるタスク置換の最大数を制御できます。
「代替タスクが正常になるまで待ってから、古いタスクの終了を試みる」ため、スパイクアクセスで一時的にリクエストが詰まってしまうようなケースでも新しいタスクが増加されるまで既存タスクが処理を継続してくれます。
サービスの自動スケーリング
今回の主題とそれますが、スケーリングポリシーが2種類あるのをご存知でしょうか。スケーリングポリシーには、ターゲットの追跡 と ステップスケーリング があります。AWS推奨はターゲットの追跡となっていますが、ユースケースに応じて設定するのが良さそうと考えています。
Amazon ECS サービス Auto Scaling は、以下のタイプのスケーリングポリシーをサポートします。
・ターゲット追跡スケーリングポリシー (推奨)—特定のメトリクスのターゲット値に基づいて 、サービスが実行するタスク数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
・ステップスケーリングポリシー - アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値) に基づいて、サービスが実行するタスク数を増減させます。
ターゲットの追跡
特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減させます。
ステップスケーリング
アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値) に基づいて、サービスが実行するタスク数を増減させます。
最後に
ちょうどスパイクアクセスに悩まされていたタイミングでこのアップデートがきたので渡りに船でした。また CodePipelineで gitタグのサポートが開始されるというアップデートもきたので近々設定していきたいと思います！
▶ 【PR】PRONI に興味がある方へ
今回の記事を読んでPRONIに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
興味でたかも？と思った方はまずはカジュアルにお話ししましょう！
エンジニア採用資料はこちら！
この記事が気に入ったらサポートをしてみませんか？