0

プロジェクトの現在のアーキテクチャは次のとおりです。2つのAmazonインスタンスがあります。どちらにもUbuntu10.10がインストールされています。

インスタンス1：（m1.large）- このインスタンスには、Php、Apache、およびMySqlがインストールされています。メインのウェブサイト+API（Phpで開発）+データベース（MySql）が含まれています

インスタンス2：（t1.micro）- このインスタンスには、Php、Apache、およびMySqlがインストールされています。Javascriptが含まれています。

クライアントとサーバーの相互作用：クライアント側には、インスタンス2 のJSファイルをクライアントにロードするJSコードのブロックがあります。このJSファイルはリクエストを作成し、インスタンス1のAPIに送信します。インスタンス1のAPIは応答を生成し、それをクライアントに送信します。

インスタンス1には、毎週日曜日に約5〜6時間実行されるcronプロセスがあります。

インスタンス1の最大CPU使用率は約80％であり、cronが実行するように設定されている日曜日には95％を超えます。メインインスタンスでの1日あたりの平均リクエスト数は約225kです。

**There is no issue on instance 2 of CPU utilization.Size of database is 7.5 GB**

新しいアーキテクチャの必要性： ご覧のとおり、現在のアーキテクチャではCPU使用率が高くなっています。より多くのリクエストを処理したい場合、このアーキテクチャは効率的ではありません。クライアントの数が増えるにつれて、サーバー上のリクエストの数とデータベースのサイズも増えます。

新しい建築デザインを提案してもらえますか？また、データベースをMySqlからMongoDBに変更することも計画しています。また、データベースをインスタンス1から分離します。これは正しい決定ですか？

Memcached、nginxなどの新しいアーキテクチャに実装できる新しいテクノロジーを誰かが提案できますか？

ありがとうございました。

4

5 に答える 5

5

これは、役立つ可能性のあるAmazonのリファレンスアーキテクチャの1つへのリンクです。

ここに画像の説明を入力してください

一言で言えば：

  • インフラストラクチャを層（Web、アプリ、データ）に分割します
  • 自動スケーリンググループを使用して、トラフィックの増減に応じてスピンアップ/スピンダウンします
  • 高可用性のためにアベイラビリティーゾーン間で階層を分割する
  • CloudFrontを使用して静的画像/javascriptなどをホストします。速度に敏感なアイテムの場合
于 2012-09-11T19:00:04.463 に答える
0

これは非常に一般的な質問ですが、考慮すべき点がいくつかあります。

  • データベースをアプリサーバーから削除します。AmazonがホストするMySQLインスタンスにAmazonRDSを使用できます。
  • 静的リソース用に別のWebサーバーを使用してみてください。nginxはそのための良い選択でしょう。
  • nginxは、動的PHPリクエストをバックエンドサーバーに転送するためのフロントエンドプロキシとしても機能します。
  • このオプションを使用すると、スケーラビリティも容易になります。追加の計算能力が必要な場合は、バックエンドPHPサーバーを追加し、それらをnginx構成に追加するだけで、完了です。
  • アプリで、memcacheに接続された透過キャッシュレイヤーを使用してみてください（おそらく別のインスタンスにインストールする必要があります）。結果がキャッシュに見つからない場合は、結果をビルドし（たとえば、データベースにクエリを実行して）、キャッシュに保存します。その後のリクエストでは、キャッシュからの結果を使用できます。
于 2012-09-08T09:39:14.573 に答える
0

さて、ここであなたが考慮したいと思うかもしれないいくつかの事柄があります：

  1. 1日の平均リクエストではなく、最大連続リクエスト数を知る必要があります。apache.confで設定し（ある程度の制限まで）、ec2インスタンスの設定を増やす/自動スケーリングを使用することで、apacheに処理される連続リクエストの数を改善およびテストできます。また、日曜日のcronジョブが原因でCPU使用率が上昇しているため、CPU使用率の自動スケーリングが最適です。

  2. Cloudfrontの使用を検討すると、パフォーマンスが向上し（取得時間など）、アプリケーションの高可用性も実現します。

  3. MongoDbへの移行を計画している場合、RDSを使用することはできません。Mysqlに固執する場合は、RDSを使用する必要があります。

  4. memcachingを検討している間、memcacheはいくつかの不一致を与える可能性があるため、データベースレベルだけでなくアプリケーションレベルでもキャッシュを実装するようにしてください。

  5. Nginxは静的コンテンツを提供するための優れたオプションであり、優れたプロキシサーバーとして機能する可能性があります。

于 2012-09-09T07:35:56.390 に答える
0

ここにいる他の人たちによる本当に良い考え。他の回答の共通のテーマはこれにNginxのようなものを使用することだったので、静的コンテンツに関してチャイムを鳴らすと思いました。私にとっては、画像、JavaScript、CSSなどをS3バケットに配置し、Cloudfrontディストリビューションを配置する方が、このコンテンツにWebサーバーを提供しようとするよりもはるかに簡単であることがわかりました。エッジノードの静的コンテンツをエンドユーザーにはるかに近づけることができ、スケーリングの側面についてまったく心配する必要はありません。

また、Ubuntuの新しいバージョン（おそらくCanonicalの12.04）に移行することをお勧めします。

実際の本番Webサーバーでは、大規模なcronプロセス（つまり、大量のCPUまたはディスクサイクルを消費するプロセス）を実行しないようにします。おそらく、これらのタスクを実行するために必要に応じて、ロードバランサーではなく、同じインスタンスを起動します。これにより、Webサーバーのサイズを適切に調整/スケーリングすることもできます（cronが実行されている最悪の場合ではありません）

MongoとMySQLのどちらを使用するかは、実際にはデータ構造によって異なります（つまり、リレーショナル構造とスキーマレス構造のどちらに適しているか）。

于 2012-09-14T16:40:02.143 に答える
0

ええと、@MikeBrantに同意します。ここにいるすべての人からの素晴らしい入力と結論は、「MongoとMySQLのどちらを使用するかは、実際にはデータ構造に依存します（つまり、リレーショナル構造またはスキーマレス構造のどちらに適しているか）」です。静的コンテンツの問題に関しては、Nginxはかなり良いオプションだと思いますが、Cloudfrontを除外するつもりはありません（ほとんどの場合、十分な経験がないためです）。ただし、データベースの選択に関しては、NoSQLを使用する場合、mongoDBは良い選択です。MySQLを使用する場合は、RDSに加えてXeroundも確認することをお勧めします。乾杯 ：）

于 2012-09-29T20:03:29.887 に答える