「ただAutoscalingグループの後ろに置けばいい」というアドバイスは、Webサーバーなどのステートレスアプリケーションのスケーリングに一般的に使用されます。これは、レプリカが相互に交換可能であり、最小限の影響で追加または削除できるため、うまく機能します。ただし、このアプローチはすべてのワークロードに適していない、特に交換可能性を侵害する特定のプロパティを持つワークロードには適していません。そのようなプロパティの1つは、セッションアフィニティです。ここで、セッションは特定のインスタンスに結び付けられており、簡単に転送することはできません。もう1つは、新しいインスタンスの起動時間が遅く、インスタンスが必要なときに準備できていない場合、反応型のスケーリングは効果的ではありません。これらの特性を持つワークロードの場合、標準的な反応型オートスケーリングは誤った解決策です。即時の反応ではなく、スケーリングアウトはより遅い、傾向に基づくトリガーを使用する必要があります。これにより、新しいインスタンスが重要な時期に必要になる前に、完全に動作するための十分な時間が与えられます。安全にスケーリングインすることも重要です。インスタンスを単純に終了すると、進行中の作業が中断される可能性があるためです。AWSライフサイクルフックなどの業界の解決策は、インスタンスが終了される前にセッションを優雅にドレインすることを可能にします。このパターンには、新しい作業を停止し、既存のセッションが完了するまで待ち、次にインスタンスを削除することが含まれます。ビデオ会議プラットフォームなどの大規模システムは、すでにこれらのより洗練されたスケーリング戦略を使用しています。重要なポイントは、インスタンスの交換可能性を評価することです。任意のインスタンスが任意のタスクを瞬時に処理できる場合、オートスケーリングは適切です。そうでない場合、より遅いスケーリングアウトメカニズムと適切なスケーリングインドレインロジックが、セッションアフィニティまたは起動が遅いワークロードを効果的に管理するために必要です。これらのワークロードを反応型の交換可能モデルに強制すると、重大な障害につながります。