スケーリンググループはAuto scalingの基本的な要素であり、同じタイプのサービスインスタンスを管理し、同様のビジネス目的に適しています。 スケーリンググループを使用して、クラスター内のインスタンスの水平方向の拡張を高速化できます。 スケーリンググループを使用して、ビジネス要件に基づいてインスタンスの数を動的にスケーリングすることもできます。これにより、大幅なコスト削減が可能になります。
メリット
迅速なスケールアウト機能と高いサービス可用性
スケーリンググループを使用すると、サービスクラスターを効率的に拡張し、サービスの可用性を向上できます。
コスト管理
サービスクラスタを水平方向にスケーリングすると、リソース管理の増加により運用コストが高くなる可能性があります。 ただし、ビジネスは常にフル稼働するとは限りません。 この場合、クラウドコンピューティングの柔軟な機能を使用して、コンピューティングリソース要件が減少したときにリソース投資を削減でき、コストの管理に役立ちます。
サポートされるスケーリングソリューション
解決策1: 固定数の利用可能なインスタンスのメンテナンス
シナリオ: クラスタースケーリングなしの高可用性メンテナンス
実装方法: インスタンスヘルスチェックおよび期待インスタンス数機能を有効にします。
スケーリンググループの [インスタンスのヘルスチェック] 機能を有効にすると、Auto scalingは異常なインスタンスをスケーリンググループから自動的に削除します。 スケーリンググループ内の現在のインスタンス数が予想されるインスタンス数より少ない場合、Auto scalingは自動的にスケールアウトイベントをトリガーして、スケーリンググループ内の使用可能なインスタンスの固定数を維持します。
例
たとえば、スケーリンググループの [期待されるインスタンス数] 機能を有効にし、期待される数として10を指定します。 スケーリンググループ内の実際のインスタンス数が10未満の場合、Auto scalingは自動的にスケールアウトイベントをトリガーして実際の数を10に増やします。
解決策2: 定期的にスケジュールされた自動スケーリング
シナリオ: 安定したリソース使用率
実装方法:: 定期的な自動スケーリングを有効にするスケジュール済みタスクを作成します。
クラスターのリソース使用率が増加すると、スケジュールされたタスクを実行してスケールアウトイベントをトリガーできます。 クラスターのリソース使用率が低下した場合、スケジュールされたタスクを実行してスケールインイベントをトリガーできます。 詳細については、「スケジュールされたタスクのトリガーによるECSインスタンスのスケーリング」をご参照ください。
例
たとえば、クラスターでは、毎晩19:00にトラフィックが増加し、01:00にモニタリングごとに減少します。 ビジネス需要の変動に対処するために、次のスケジュールタスクを作成できます。
トラフィックの増加: スケジュールされたタスクを有効にして、毎晩19:00にサービスレプリカの数を増やすことができます。 これにより、増加したトラフィックを処理するクラスタの能力が向上します。
トラフィックの減少: スケジュールされたタスクを有効にして、毎朝01:00にサービスレプリカの数を減らすことができます。 これにより、リソース利用率が向上し、コスト効率が最大になります。
解決策3: リソース使用率のしきい値に基づく自動スケーリング
シナリオ: ワークロードの突然の変動
実装方法:
リソース使用率が指定したしきい値を超えたとき、または下回ったときにスケーリングイベントをトリガーする
イベントトリガータスクを作成して、スケーリングイベントをトリガーできます。 リソース使用率が指定したしきい値を超えるか下回ると、イベントトリガータスクが自動的に実行され、スケーリングイベントがトリガーされます。
希望するリソース使用率を維持する
スケーリンググループにターゲット追跡スケーリングルールを作成して、目的のリソース使用率を維持できます。
例
Elastic Compute Service (ECS) タイプのスケーリンググループにターゲットトラッキングスケーリングルールを作成し、80% を目的の平均CPU使用率として指定します。 この場合、Auto Scalingはインスタンスを動的に追加または削除して、平均CPU使用率を80% に維持します。
実装方法の違い
単純なスケーリングルールまたはステップスケーリングルールベースの実装方法は、柔軟性とカスタマイズを向上させます。 イベントトリガータスクがトリガーされた後に追加または削除するインスタンスの数を制御できます。 この実装方法は、リソース利用層の変化に基づくインスタンスのスケーリングも可能にします。
ターゲット追跡スケーリングルールベースの実装方法は、より単純化される。 必要なリソース使用率にのみ集中する必要があります。
解決策4: カスタムスケーリング
上記のソリューションのいずれもビジネス要件を満たしていない場合は、カスタムスケーリングソリューションを設定できます。
手動でスケーリングルールを実行するか、インスタンス番号を変更してスケーリングイベントをトリガーできます。 詳細については、「数回クリックするとECSインスタンスを手動でスケールする」をご参照ください。
カスタムスケーリングはAPI呼び出しをサポートします。 API操作を呼び出して、ビジネス要件に基づいてカスタムスケーリングソリューションを構成できます。
ソリューション5: 予測スケーリング
Auto Scalingは、予測されるリソース需要に合わせて自動的に調整することもできます。
このソリューションでは、予測のみを有効にして精度と関連性を評価することで、予測スケーリングルールの初期テストを実行できます。 結果が満足のいくものであれば、予測とスケーリングの両方を有効にして、予測タスクを自動的に生成し、スケジュールされた計画に基づいてインスタンスをスケーリングできます。 詳細については、「予測スケーリングルールの予測の表示」をご参照ください。
使用上の注意
スケーリンググループを使用する前に、ビジネスをデプロイするインスタンスが水平スケーリングをサポートしていることを確認してください。
Auto Scalingは、インスタンスを水平方向にスケーリングします。 ビジネスに対する水平スケーリングの潜在的な影響を考慮することを推奨します。
データの整合性
データベースがインスタンスにデプロイされている場合、Auto Scalingを使用してインスタンスを水平方向にスケールアウトすると、データの不整合が発生する可能性があります。 この問題を解決するには、データベースを個別にデプロイし、すべてのインスタンスが同じデータベースにアクセスできるようにすることで、アーキテクチャ設計を変更することをお勧めします。 これは、サービスステートレスを達成するのに役立ちます。
データセキュリティ
スケーリンググループのインスタンスは自動的に作成およびリリースされます。 インスタンスにデータを保存する場合は、必ずデータバックアップ操作を実行してデータを保護してください。