すべてのプロダクト
Search
ドキュメントセンター

Auto Scaling:伸缩组概述

最終更新日:Jul 11, 2026

スケーリンググループは、同じアプリケーション要件とインスタンスタイプを共有するインスタンスを管理します。これにより、クラスターを迅速にスケールアウトし、ビジネスの需要に基づいてインスタンス数を動的に調整することで、コスト削減に役立ちます。

スケーリンググループを使用する理由

  • 高可用性のための迅速なスケールアウト

    インスタンスを追加して容量を増やし、トラフィックを処理することで、サービスクラスターを迅速に スケールアウト します。

  • コスト管理

    トラフィックは常にピークにあるわけではないため、Auto Scaling はリソースを実際の需要に合わせ、不要なインスタンスを削除することでコストを削減します。

スケーリングソリューション

ソリューション 1:固定数のインスタンスの維持

  • ユースケース:スケーリングを必要としないクラスターの高可用性を維持します。

  • 仕組み:スケーリンググループに対して [インスタンスのヘルスチェック] を有効にし、[希望インスタンス数] を設定します。

    [インスタンスのヘルスチェック] が有効な場合、スケーリンググループは異常なインスタンスを自動的に削除します。インスタンス数が希望する数を下回ると、Auto Scaling はスケールアウトをトリガーして、固定数の正常なインスタンスを維持します。

  • 正常なサービスインスタンス 10 台で構成されるクラスターを維持したい場合は、希望するインスタンス数を 10 に設定します。スケーリンググループは、正常なインスタンス 10 台を維持するために、スケーリングアクティビティを自動的にトリガーします。

ソリューション 2:スケジュールされたスケーリング

  • ユースケース:予測可能で周期的なビジネスワークロードの変動に対応します。

  • 仕組み:スケーリンググループに [スケジュール済みタスク] を作成し、スケールアウトおよびスケールインイベントを自動化します。

    スケジュールされたタスクは、リソース需要が高いときにスケールアウトをトリガーし、需要が低いときにスケールインをトリガーします。完全なガイドについては、「ECS インスタンスのスケジュールに基づくスケーリング」をご参照ください。

  • たとえば、毎日午後 7:00 にトラフィックが増加し、午前 1:00 に減少する場合、2 つのスケジュールされたタスクを作成できます。

    • トラフィックの急増への対応:午後 7:00 に スケジュールされたスケールアウトタスク を設定します。毎日午後 7:00 に、このタスクはインスタンスを追加してクラスターの容量を増やします。

    • トラフィックの閑散期への対応:午前 1:00 に スケジュールされたスケールインタスク を設定します。毎日午前 1:00 に、このタスクはインスタンスを削除してリソースの利用率を向上させ、コストを削減します。

ソリューション 3:しきい値に基づくスケーリング (CPU、メモリ使用率など)

  • ユースケース:リソースメトリクスが定義されたしきい値を超えたときにスケーリングをトリガーすることで、予測不可能な突然のワークロード変動に対応します。

  • 仕組み

    イベントトリガータスク

    スケーリンググループに [イベントでトリガーされるタスク] を設定できます。リソースメトリクスが指定されたしきい値を超えると、アラームがスケーリングアクティビティをトリガーします。

    固定数のインスタンスの追加または削除

    [イベントでトリガーされるタスク] を設定し、アラームがトリガーされたときに実行する [シンプルスケーリングルール] を指定できます。このルールは、イベントに応じてグループをスケールアウトまたはスケールインします。

    効果

    簡易スケーリングルールは、特定の数のインスタンスを追加または削除するか、総インスタンス数を特定の値に設定します。

    • クラスターの平均 CPU 使用率が 80% を超えた場合、N 個のインスタンスを追加します。

    • クラスターの平均 CPU 使用率が 70% を下回った場合、N 個のインスタンスを削除します。

    完全なガイドについては、「ワークロードに基づく ECS インスタンスのスケーリング」をご参照ください。

    使用率に基づいて段階的にインスタンスを追加または削除

    [ステップスケーリングルール] と関連する [イベントでトリガーされるタスク] を作成できます。アラームがトリガーされると、システムは事前に定義された使用率の段階に基づいてスケールアウトまたはスケールインします。

    重要

    ECI のスケーリンググループは、[ステップスケーリングルール] をサポートしていません。

    効果

    イベントトリガータスクがトリガーされると、スケーリンググループはクラスターの平均 CPU 使用率の段階に基づいてスケールインまたはスケールアウトします。

    • 平均 CPU 使用率が 60% から 70% の間の場合、1 個のインスタンスを削除します。

    • 平均 CPU 使用率が 30% から 60% の間の場合、3 個のインスタンスを削除します。

    • 平均 CPU 使用率が 30% 未満の場合、5 個のインスタンスを削除します。

    ターゲット追跡スケーリングルール

    [目標追従スケーリングルール] を作成して、スケーリンググループのリソースメトリクスをターゲット値またはその近くに維持できます。

    ECS スケーリンググループでは、平均 CPU 使用率のターゲットを 80% に設定するターゲット追跡スケーリングルールを作成できます。Auto Scaling は、グループの平均 CPU 使用率を 80% またはその近くに維持するために、インスタンスを自動的に追加または削除します。

  • 2 つの方法の比較

    • イベントトリガータスクは、より高い柔軟性とカスタマイズ性を提供します。アラームがトリガーされたときに追加または削除するインスタンスの数を正確に制御でき、さまざまなリソース使用率の段階に対して異なるスケーリング応答を定義できます。

    • ターゲット追跡スケーリングルールは、設定がより簡単です。メトリクスのターゲット値を定義するだけで、残りは Auto Scaling が処理します。

ソリューション 4:カスタムスケーリング (手動スケーリング)

これらのソリューションがニーズを満たさない場合は、カスタムスケーリングソリューションを作成できます。

スケーリングルールを手動で実行するか、スケーリンググループ内のインスタンス数を変更することで、スケーリングアクティビティをトリガーできます。完全なガイドについては、「ワンクリックで ECS インスタンスを手動スケーリング」をご参照ください。

説明

手動スケーリングは API コールをサポートしています。独自のプログラムを記述して API を呼び出し、ビジネスに合わせたカスタムスケーリングソリューションを構築できます。

ソリューション 5:予測スケーリング

スケーリンググループは、将来のリソース需要を予測し、自動的にスケーリングできます。

予測ルールを設定し、予測のみのモードで実行して精度を評価します。予測がニーズを満たす場合は、[予測とスケーリング] を有効にします。その後、予測ルールは予測に基づいてスケジュールされたタスクを自動的に作成し、グループをスケーリングします。詳細については、「予測スケーリングルールの効果の表示」をご参照ください。

注意事項

スケーリンググループを使用する前に、アプリケーションがスケールアウトをサポートしていることを確認してください。

インスタンスの追加がクラスターのビジネスオペレーションに影響を与えるかどうかを検討してください。

  • データの一貫性

    スケーリング対象のインスタンス上でデータベースが実行されている場合、スケールアウトによってデータに不整合が生じる可能性があります。これを避けるには、データベースを独立してデプロイし、すべてのインスタンスが単一のデータベースを共有するようにして、サービスをステートレスにします。

  • データセキュリティ

    スケーリンググループ内のインスタンスは自動的に作成および解放されます。これらのインスタンスに保存されているデータは、その安全性を確保するためにバックアップしてください。

スケーリンググループの使用

利用開始

高度なユースケース

アプリケーションのデプロイ

  • パッケージ済みソフトウェアイメージによる自動デプロイ

    • ECS スケーリンググループ。

      アプリケーションパッケージを含むカスタムイメージを構築し、インスタンス設定でこのイメージをソースとして設定します。

    • ECI のスケーリンググループ。

      アプリケーション用の Docker イメージを構築し、インスタンス設定でこのイメージをソースとして設定します。

  • インスタンス起動時のデプロイスクリプトの自動実行

    • ユーザーデータソリューション

      ECS スケーリンググループでは、インスタンスにユーザーデータを設定できます。ユーザーデータ内でスクリプトを実行して、アプリケーションパッケージをデプロイできます。詳細については、「ユーザーデータを使用した ECS インスタンスの自動設定」をご参照ください。

    • ライフサイクルフックソリューション

      ECS スケーリンググループでは、ライフサイクルフックを設定できます。スケールアウトがトリガーされた後、新しいインスタンスがグループに追加される前に、インスタンス上でデプロイスクリプトを実行できます。詳細については、「ECS インスタンスでのスクリプトの自動実行」をご参照ください。

ローリングアップデート

ローリングアップデート機能を使用して、スケーリンググループ内のインスタンスイメージを更新したり、複数のインスタンスにわたってバッチでスクリプトを実行したりできます。詳細については、「ローリングアップデート」をご参照ください。

クラウドデータベースの関連付け

スケーリンググループに同じセキュリティグループを割り当てるか、新しいインスタンスをクラウドデータベースの IP アドレスホワイトリストに自動的に追加できます。これにより、新しいインスタンスがデータベースにアクセスできるようになります。

関連ドキュメント

ロードバランサーの関連付け

スケーリンググループ内のインスタンスクラスターがアクセスポイントとしてロードバランサーを使用している場合、そのロードバランサーをスケーリンググループに関連付けることができます。関連付けが完了すると、新しいインスタンスはロードバランサーのバックエンドサーバーグループに自動的に追加されます。

関連ドキュメント

カスタム操作

ライフサイクルフックを使用して、インスタンスがスケーリンググループに追加または削除される前に、NAS ファイルシステムのマウント、EIP のバインド、カスタムスクリプトの実行などのカスタム操作を実行できます。

関連ドキュメント

スケールインポリシーの設計

ビジネスワークロードが減少すると、スケーリンググループはポリシーに基づいてスケールインアクティビティをトリガーし、リソースを削減して無駄を防ぎます。頻度を制御したり、グレースフルなスケールインを実行したり、削除するインスタンスを選択したりする必要がある場合があります。

関連ドキュメント

リソースコストの最適化

スケーリンググループを設定した後、スポットインスタンスを組み込み、コスト最適化ポリシーを使用することで、コストをさらに削減できます。

関連ドキュメント

障害復旧と可用性

アベイラビリティーゾーンのインスタンス在庫が不足しているため、スケールアウトアクティビティが失敗する可能性があります。複数のアベイラビリティーゾーンとインスタンスタイプを設定することで、この問題を軽減できます。また、マルチゾーンの障害復旧のために均等分散ポリシーを実装することもできます。

関連ドキュメント

Kubernetes ノードのスケーリング

Kubernetes を使用して、ノードの弾力的なスケーリングを実装します。

関連ドキュメント