翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
重要
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、 AWS re:Post
受信ユーザーリクエストが単一の t2.micro インスタンスで処理可能な制限に近づいている場合、サーバー容量を増やす必要があります。大きいインスタンスに移行できますが、制限があります。インスタンスをスタックに追加し、ロードバランサーの背後に配置すると、柔軟性が向上します。基本的なアーキテクチャは次のようになります。
とりわけ、このアプローチには、単一の大きいインスタンスより堅牢性がかなり高いというメリットがあります。
-
いずれかのインスタンスが失敗した場合、ロードバランサーは受信リクエストを残りのインスタンスに分散し、アプリケーションは動作し続けます。
-
インスタンスを異なるアベイラビリティーゾーンに置いた場合 (推奨される方法)、アベイラビリティーゾーンで問題が発生してもアプリケーションが動作し続けます。
AWS OpsWorks スタックを使用すると、スタックを簡単にスケールアウトできます。このセクションでは、2 番目の 24/7 PHP App Server インスタンスを IISExample に追加し、両方のインスタンスを Elastic Load Balancing ロードバランサーの後ろに配置することにより、スタックをスケールアウトする方法の基本について説明します。この手順を簡単に拡張して任意の数の 24/7 インスタンスを追加したり、時間ベースのインスタンスを使用して AWS OpsWorks スタックでスタックを自動的にスケーリングしたりできます。詳細については、「時間ベースおよび負荷ベースのインスタンスによる負荷の管理」を参照してください。
