かなりのスケーリングが必要なアプリを初めて開発しましたが、これまで複数のインスタンスでアプリケーションを実行する必要はありませんでした。
これは通常どのように達成されますか?SQLサーバーをクラスター化してから、すべてのサーバー間でプログラミングをミラーリングし、負荷分散を使用しますか?
または、あるサーバーでいくつかを実行する機能を別のサーバーで実行する機能を分離しますか?
また、すべてのEC2 Windowsインスタンスにコードをプッシュするにはどうすればよいですか?
かなりのスケーリングが必要なアプリを初めて開発しましたが、これまで複数のインスタンスでアプリケーションを実行する必要はありませんでした。
これは通常どのように達成されますか?SQLサーバーをクラスター化してから、すべてのサーバー間でプログラミングをミラーリングし、負荷分散を使用しますか?
または、あるサーバーでいくつかを実行する機能を別のサーバーで実行する機能を分離しますか?
また、すべてのEC2 Windowsインスタンスにコードをプッシュするにはどうすればよいですか?
これはあなたが持っている要件に依存します。ただし、一般的なガイドラインとして(私はWebサイトを想定しています)、db、webserver、キャッシングサーバーなどを異なるインスタンスに分離し、静的アセットにs3(+ cloudfont )を使用します。また、インフラストラクチャに正当な負荷のみがかかるように、適切なレート制限が設定されていることを確認します。
RDBMSサーバーの場合、マスタースレーブのdbセットアップをセットアップし(RDSを使用するとこれが簡単になります)、dbシャーディングなどを使用できます。セットアップがより複雑になるDBクラスターソリューションも存在しますが、アプリケーションプログラマーのデータベースアクセスが簡素化されます。また、すべてのdbクエリをチェックし、それに応じてdb/sqlクエリを調整します。場合によっては、純粋なNoSQLタイプのデータベースが、必要なデータに応じてアプリケーションがそれらを切り替えるRDBMSまたは両方の組み合わせよりも優れていることがあります。
Webサーバーの場合、ロードバランサーをセットアップしてから、ロードバランサーの背後にあるWebサーバーインスタンスで自動スケーリングを使用します。同様のことがアプリサーバーにも当てはまります。また、Webサーバーの設定も調整します。
キャッシングサーバーも、インスタンスのクラスターに分離されます。ElastiCacheは素晴らしいサービスのようです。Redisのパフォーマンスはmemcacheに匹敵しますが、スケーリング時に役立つ可能性のあるより多くの機能(リスト、セットなど)があります。
免責事項-私は常にUnixマシンで作業してきたので、Windowsの詳細については触れません。これらのガイドラインはかなり一般的です。
これは主観的な質問であり、誰もが独自のスタイルで独自のシステムを調整します。これが私が従ういくつかのガイドラインです。
Webアプリケーションの場合は、プレゼンテーション(フロントエンド)、ミドルウェア(API)、およびデータベースの各レイヤーを分離します。スライスされたアーキテクチャは、モノリシックアプリケーションと比較して最適なスケーリングを実現します。
これらはすべて、AWSElasticBeanstalkを使用したAutoScalingにバンドルしてデプロイできます。現在、ASP .NET、PHP、Python、Java、Rubyコンテナをサポートしています。AWS Elastic Beanstalkにはまだ独自の制限がありますが、監視、スケーリング、負荷分散の手間を最小限に抑えてインフラストラクチャを管理するための非常に優れた方法です。
ヒント:アプリケーションの読み取りと書き込みが集中する領域を特定すると、非常に役立ちます。次に、先に進んでそれに応じてインフラストラクチャをスライスし、一度に読み取りまたは書き込みフォーカスを使用して必要な最適化を実行できます。
要約すると、Amazon AWSには、サーバートポロジの作成に使用できる可能性のあるほとんどすべてのものがあります。コンポーネントを選択するのはあなた次第です。
お役に立てれば!
私のやり方は、mysqlを実行しているDBサーバーとして1台のサーバーを使用することです。memcached上のすべてのデータは、複数のサーバーとクライアントにまたがることができ、「memcachedにない場合は、dbから読み取り、memcachedに置いて返す」だけです。
Memcachedは、DBと比較して非常に簡単にスケーリングできます。dbスケーリングには、多くの管理作業が必要です。それを正しく機能させるのは苦痛です。だから私はmemcachedを選びます。実際、ダウンタイム(memcachedサーバーがある場合)を管理するためだけに、追加のmemcachedサーバーを稼働させています。
私のデータはほとんどが読み取りで、書き込みはほとんどありません。また、書き込みが発生すると、データをmemcachedにもプッシュします。全体として、これは私にとって、コード、管理、フォールバック、フェイルオーバー、負荷分散の方法でうまく機能します。すべてが勝ちます。あなたはただ「少し」より良くコーディングする必要があります。
mysqlのクラスタリングは、コーディング、デプロイ、保守、および維持と実行がより簡単であるように思われるため、より魅力的です。mysqlはハードディスクベースであり、memcachedはメモリベースであるため、本質的にはるかに高速です(少なくとも10倍)。また、dbからのすべての読み取り負荷を引き継ぐため、dbの構成は非常に簡単になります。
私は誰かがここで反対の議論を指摘することを本当に望んでいます、私はそれを聞きたいです。