5

かなりのスケーリングが必要なアプリを初めて開発しましたが、これまで複数のインスタンスでアプリケーションを実行する必要はありませんでした。

これは通常どのように達成されますか？SQLサーバーをクラスター化してから、すべてのサーバー間でプログラミングをミラーリングし、負荷分散を使用しますか？

または、あるサーバーでいくつかを実行する機能を別のサーバーで実行する機能を分離しますか？

また、すべてのEC2 Windowsインスタンスにコードをプッシュするにはどうすればよいですか？

4

3 に答える 3

8

これはあなたが持っている要件に依存します。ただし、一般的なガイドラインとして（私はWebサイトを想定しています）、db、webserver、キャッシングサーバーなどを異なるインスタンスに分離し、静的アセットにs3（+ cloudfont ）を使用します。また、インフラストラクチャに正当な負荷のみがかかるように、適切なレート制限が設定されていることを確認します。

RDBMSサーバーの場合、マスタースレーブのdbセットアップをセットアップし（RDSを使用するとこれが簡単になります）、dbシャーディングなどを使用できます。セットアップがより複雑になるDBクラスターソリューションも存在しますが、アプリケーションプログラマーのデータベースアクセスが簡素化されます。また、すべてのdbクエリをチェックし、それに応じてdb/sqlクエリを調整します。場合によっては、純粋なNoSQLタイプのデータベースが、必要なデータに応じてアプリケーションがそれらを切り替えるRDBMSまたは両方の組み合わせよりも優れていることがあります。

Webサーバーの場合、ロードバランサーをセットアップしてから、ロードバランサーの背後にあるWebサーバーインスタンスで自動スケーリングを使用します。同様のことがアプリサーバーにも当てはまります。また、Webサーバーの設定も調整します。

キャッシングサーバーも、インスタンスのクラスターに分離されます。ElastiCacheは素晴らしいサービスのようです。Redisのパフォーマンスはmemcacheに匹敵しますが、スケーリング時に役立つ可能性のあるより多くの機能（リスト、セットなど）があります。

于 2012-11-23T04:46:11.450 に答える
7

免責事項-私は常にUnixマシンで作業してきたので、Windowsの詳細については触れません。これらのガイドラインはかなり一般的です。

これは主観的な質問であり、誰もが独自のスタイルで独自のシステムを調整します。これが私が従ういくつかのガイドラインです。

Webアプリケーションの場合は、プレゼンテーション（フロントエンド）、ミドルウェア（API）、およびデータベースの各レイヤーを分離します。スライスされたアーキテクチャは、モノリシックアプリケーションと比較して最適なスケーリングを実現します。

  1. データベース-Amazonは、SQLおよびNoSQLデータストアに優れた高可用性サービスを提供します（私たちにいる場合を除きます-東のアベイラビリティーゾーン）。リレーショナルデータベースの場合はRDSを、NoSQLの場合はDynamoDbを確認することをお勧めします。どちらも拡張性が高く、データストアを起動した後は、データストアの管理とロードのシャーディング/クラスタリングについて心配する必要はありません。
  2. ミドルウェアAPI-これは重要な部分です。バックエンド機能をサービスとして公開する一連のAPI（できれば、RESTですが、ここではほとんど何でも使用できます）を用意することが重要です。サービス指向アーキテクチャは、Web、モバイル、デスクトップ、サードパーティウィジェットなどの複数の前面クライアントに対応するために非常に簡単に拡張できます。MiddlewareAPIは通常、ビジネスロジックが処理される場所ではなく、そのほとんど（またはすべて）パフォーマンスを向上させるには、データベースのルックアップ/クエリに変換する必要があります。これらのサービスは、高可用性のために負荷分散することができます。AmazonのElasticLoadBalancer（ELB）は初心者に適しています。特定のIPアドレスのセットのトラフィックをブロックするなど、さらにカスタマイズしたい場合は、青/緑のデプロイの場合は、HAProxyロードバランサーを個別のインスタンスにデプロイすることを検討する必要があります。
  3. フロントエンド-これは、プレゼンテーション層が存在する場所です。フロントエンドのスコープに限定されているものを除いて、直接のデータベースクエリを回避する必要があります。たとえば、フロントエンドフラグメントの最新のキャッシュキーを取得するための単純なRedis呼び出しです。ここで、サービス呼び出しからフロントエンドフラグメントまで、ほとんど多くのキャッシュを実行できます。静的アセットの配信にはAWSCloudFrontを使用し、キャッシュストアにはAWSElastiCacheを使用できます。ElastiCacheは、マネージドmemcachedクラスターに他なりません。ELBの背後にあるフロントエンドノードの負荷分散も検討する必要があります。

これらはすべて、AWSElasticBeanstalkを使用したAutoScalingにバンドルしてデプロイできます。現在、ASP .NET、PHP、Python、Java、Rubyコンテナをサポートしています。AWS Elastic Beanstalkにはまだ独自の制限がありますが、監視、スケーリング、負荷分散の手間を最小限に抑えてインフラストラクチャを管理するための非常に優れた方法です。

ヒント：アプリケーションの読み取りと書き込みが集中する領域を特定すると、非常に役立ちます。次に、先に進んでそれに応じてインフラストラクチャをスライスし、一度に読み取りまたは書き込みフォーカスを使用して必要な最適化を実行できます。

要約すると、Amazon AWSには、サーバートポロジの作成に使用できる可能性のあるほとんどすべてのものがあります。コンポーネントを選択するのはあなた次第です。

お役に立てれば！

于 2012-11-26T12:03:07.743 に答える
2

私のやり方は、mysqlを実行しているDBサーバーとして1台のサーバーを使用することです。memcached上のすべてのデータは、複数のサーバーとクライアントにまたがることができ、「memcachedにない場合は、dbから読み取り、memcachedに置いて返す」だけです。

Memcachedは、DBと比較して非常に簡単にスケーリングできます。dbスケーリングには、多くの管理作業が必要です。それを正しく機能させるのは苦痛です。だから私はmemcachedを選びます。実際、ダウンタイム（memcachedサーバーがある場合）を管理するためだけに、追加のmemcachedサーバーを稼働させています。

私のデータはほとんどが読み取りで、書き込みはほとんどありません。また、書き込みが発生すると、データをmemcachedにもプッシュします。全体として、これは私にとって、コード、管理、フォールバック、フェイルオーバー、負荷分散の方法でうまく機能します。すべてが勝ちます。あなたはただ「少し」より良くコーディングする必要があります。

mysqlのクラスタリングは、コーディング、デプロイ、保守、および維持と実行がより簡単であるように思われるため、より魅力的です。mysqlはハードディスクベースであり、memcachedはメモリベースであるため、本質的にはるかに高速です（少なくとも10倍）。また、dbからのすべての読み取り負荷を引き継ぐため、dbの構成は非常に簡単になります。

私は誰かがここで反対の議論を指摘することを本当に望んでいます、私はそれを聞きたいです。

于 2012-11-23T05:01:45.250 に答える