次のトラフィックパターンでAmazonElasticBeanstalkで実行されているサイトがあります。
アマゾンウェブサービスは、このような課題に迅速に拡張できると主張していますが、クラウドウォッチの「xより大きい」セットアップは、このトラフィックパターンに対して十分に高速ではないようです。
通常、数秒以内にすべてのec2インスタンスがクラッシュし、すべてのcloudwatchメトリクスが強制終了され、サイト全体が4/6分間ダウンします。これまでのところ、このシナリオで機能する構成はまだ見つかりません。
これは、サイトを殺した小さなイベントのグラフです。
これらのリンクは予想通りに投稿されていますか？その場合は、スケジュールによるスケーリングを使用できます。または、代わりに、自動スケーリンググループのDESIRED-CAPACITY値を変更したりas-execute-policy、リンクが投稿される直前にスケールアウトするようにトリガーしたりすることもできます。
1つのグループに複数のスケーリングポリシーを含めることができることをご存知ですか？したがって、ケースに特別なAuto Scalingポリシーがある場合がSCALE_OUT_HIGHあります。たとえば、一度に10個のインスタンスが追加されます。コマンドを見てくださいas-put-scaling-policy。
また、コードをチェックしてボトルネックを見つける必要があります。
どのHTTPDを使用していますか？Nginxは、Apacheよりもはるかに高速でリソース消費の少ないソフトウェアであるため、Nginxへの切り替えを検討してください。Memcacheを使用してみてください...高位の読み取りと書き込みにRedisのようなNoSQLも適切なオプションです。
AWSからの提案は次のとおりです。
システムの応答性を高めるために常に取り組んでいますが、ユースケースで必要と思われる応答時間で仮想サーバーを自動的にプロビジョニングすることは困難です。おそらく、リクエストが増え始めたときに、より迅速に応答するか、より回復力のある回避策があります。
より大きなインスタンスタイプを使用した場合、または定常状態でより多くのインスタンスを使用した場合に、サイトのパフォーマンスが向上するかどうかを確認しましたか？これは、インバウンド要求の急激な増加に対応するための1つの方法かもしれません。私はそれが最も費用効果が高いとは限らないかもしれないことを認識していますが、これは迅速な解決策であることがわかるかもしれません。
別のアプローチは、需要の増加をより早く反映（または予測）するしきい値またはメトリックを使用するようにアラームを調整することです。たとえば、75または100ユーザーを超えた後にインスタンスを追加するようにアラームを設定すると、パフォーマンスが向上する場合があります。あなたはすでにこれをしているかもしれません。それとは別に、ユースケースには、需要の増加を予測する別の指標がある場合があります。たとえば、Facebookページへの投稿は、大幅な要求の増加に数秒または1分先行する場合があります。CloudWatchカスタムメトリクスを使用してその値を監視し、アラームを自動スケールに設定することも、解決策になる可能性があります。
したがって、最良の答えは、より少ないトラフィックでより多くのインスタンスを実行し、カスタムメトリックを使用して外部ソースからのトラフィックを予測することだと思います。たとえば、FacebookやTwitterでサイトへのリンクがある投稿を監視し、すぐにスケールアップしてみます。