重複の可能性:
キャパシティプランニングを手伝ってくれませんか?
私のチームはNice Djangoアプリを作成し、EC2インスタンスにデプロイする予定です。答えを探しているいくつかの質問があります。
これらの質問への回答は非常に主観的であり、ほとんどのものはアプリケーションの設計とアーキテクチャに依存していることを私は知っています。したがって、私はそのような決定を下すプロセスを知ることにもっと興味があります。
質問の最後に、「状況によって異なります」以外に直接、客観的な答えを出すことはできないとご指摘いただいたので、私(広大ではない)に基づいて支援しようと思います。 AWSの使用経験。
アプリに適したインスタンス(マイクロ、スモール、ミディアム、ラージなど)を決定するにはどうすればよいですか。言い換えると、このアプリケーションに必要なメモリ/処理能力をどのように知ることができますか。
テスト、ベンチマーク、実験によって。他のプロバイダーの「同等の」ハードウェア仕様と比較した場合にEC2のパフォーマンスがどのように低下するかを指摘する記事がいくつかあります( this は良いものです)。私の提案は、最善の推測で環境をセットアップし、インスタンスを監視、負荷テスト、ベンチマークし、新しいインスタンスで遊んで、アプリケーションの要件に最適なインスタンスを決定することです。アーキテクチャの詳細がなければ、これが最善の答えです。
サーバー上の同時ユーザーの最大数を定量化するにはどうすればよいですか。これはこのアプリケーションにとって重要です。マイクロ/スモール/ミディアムまたはラージインスタンスでサポートされるユーザーの数を知る必要があります。
繰り返しますが、これはシステムアーキテクチャとトランザクションのプロファイルに大きく依存します。それらはI/O集約型、CPUバウンド、メモリバウンドですか?最良のヒントは、実験することです。
単一のインスタンスにインストールされているすべてのものを使用する必要がありますか、それともデータベース、バックアップ、およびアプリケーション用に個別のインスタンスを使用する必要があります。
アプリケーションの各層に個別のインスタンスを用意することをお勧めします。 AWSでの一般的なセットアップには、アプリケーション用のEC2インスタンス(Elastic Load Balancerの背後かどうか)(またはElastic Beanstalk)、データベース用のEC2インスタンスまたはRDSの別のセット、ファイルとバックアップを永続化するためのS3などが含まれます。 。大きな(または中程度の)負荷が予想されない場合は、単一のmedium
インスタンスがニーズに完全に適合する可能性があります。分離する主な理由は、将来、それらを個別にスケーリングできることです。これは、私見ですが、AWSの最大のメリットである柔軟性です。マウスをクリックするだけで(ほぼ文字通り)RDSシステムをスケーリングできます。また、手間をかけずにWeb層の前にElastic Load Balancerを追加してから、エコシステムに2つまたは3つのWebサーバーを追加することもできます。したがって、この柔軟性を最大化して活用するために、物事を別々に保ちます。
各ユーザーを追加して必要な追加リソースを見積もるにはどうすればよいですか(これは線形ではないと思います)
実験、ベンチマークなど。繰り返して申し訳ありませんが、リソースのデプロイを開始すると、物事が本当に線形ではなく、 AWSを使用する場合、期待が常に正しいとは限らないことに注意してください。いくつかの簡単なヒント(前の箇条書きで示した回答など)に従うことで、システムが負荷に応じて簡単にスケーリングできるとは限りませんが、スケーリングが必要なときはいつでも問題が軽減される可能性があります。
それが役に立てば幸い。