-1

これまで、私たちのサイトには適度な量のトラフィックがありました。私たちの開発者は誰も大規模な運用担当者ではありませんが、私たちはそれを先取りし、サイトを非常に迅速に稼働させ続けています. とはいえ、私たちの開発チームは限界に達しており、技術的負債が蓄積されており、最適化する機会はたくさんあります。

詳細には触れませんが、近い将来、非常に短期間で大量のトラフィックが予想されることがわかりました。数時間で数百万ヒットのオーダー。スケーリングは 1 つのことですが、これは現在見ているものよりも数桁大きいものです。

ELB と Postgresql を使用して S3 でホストされる Rails アプリです。

この状況を考慮して、スケーリングと負荷テストの幅広い出発点についていくつかの推奨事項を提出したいと思いました。

  • 更新：申し訳ありません、EC2、深夜:)
4

2 に答える 2

2

@LastZactionHero 非常に興味深い質問です。詳細にお答えさせてください。いくつかの e コマース アプリケーション、エンタープライズまたは B2B アプリについて話していることを願っています。スパイク自体は見られません。Railsアプリをs3でホストしているとすでに述べたので。いくつかのことを明確にさせてください。1) s3 で Rails アプリをホストすることはできません。S3は簡易ストレージサービスです。ファイルのみを保存できる場所。2) EC2 インスタンスの上にエラスティック ロード バランサーを接続して、AWS ec2 で Rails アプリをホストしていると思いますが、これは非常に優れています。

3) EC2 インスタンスにデプロイされた自己管理型の Postgresql があります。

AWS で実行している場合、中途半端に安全であり、簡単にスケールアップおよびスケールダウンできます。

あなたの現在のモデルには、db. AWS には db as a service があります。これは、関係データベース サービスと呼ばれます。これは、Mysql Oracle および MS SQL サーバーをサポートします。

RDS には、データベースの自動バックアップ、高い IOPS などの多くの機能が付属しています。

しかし、それは Postgresql をサポートしていません。自己管理型の ec2 インスタンスを所有または管理し、postgresql データベースを実行する必要がありますが、フェイル セーフであることを確認し、システムを適切にバックアップして復元する必要があります。

AWS は自動スケーリング API とコマンド ライン ツールを非常に簡単に提供します。

帯域幅の問題などについて心配する必要はありませんが、Angelo の回答も認めます。

Elastic Mem キャッシュを使用してアプリをキャッシュできます。アプリを高速化する必要がある場合は、CDN を使用してください。RDS は最大 30000 IOPS を管理できます。その怪物は、あなたのために多くの仕事をしてくれます。

ご不明な点がございましたら、お気軽にお問い合わせください。

(免責事項: 私は e コマース企業で働いているシニア devOps エンジニアで、Ruby on Rails を使用しています)

于 2013-04-04T06:17:45.547 に答える
1

おめでとうございます。あなたの期待がうまくいくことを願っています!!

入手可能な情報を考えると、これは包括的に答えるのが非常に難しい質問です。たとえば、サイトはデータベースの読み取り、書き込み、またはその両方に重点を置いていますか (そして、シャーディング/レプリケーション戦略はデータベースの負担に沿っていますか)? 帯域幅は問題ですか？明らかな点は、適切なハードウェアにアクセスできること、およびハードウェアのプロビジョニング/展開に使用するレシピが最新であり、準備が整っていることを確認することに焦点を当てます. 発見したボトルネックの根本にたどり着くまで、突然のトラフィックのスパイクにハードウェアを放り込むことがよくあります (もちろん、ボトルネックは都合の悪いときに発見することになります!)

アプリのスケーリングに関しては、少なくとも次のことを行う必要があります。

1) 可能な限りキャッシュします。キャッシュの有効期限などに注意してください。2) DB に適切なインデックスが設定されていることを確認してください (基本的に、検索対象のフィールドにはインデックスが必要です)。3) ログを注意深く見て、潜在的な長いクエリを特定します。N +1 クエリ、ロング ビュー レンダリングなど。ユーザーヒットリフレッシュ#axzz2O0gJDotV 5) スタックの各レイヤーに適切な監視システム (Monit、God など) をセットアップします。トラフィックの突然のスパイクは、予期しない場所でアプリケーションのボトルネックとなり、より多くの問題を引き起こす可能性があります。カスケードはすぐに発生する可能性があります。6) cron をセットアップして、現在手動​​で行っているすべての小さなタスクを自動化します...トラフィックの急増に対処すると忘れてしまう可能性があります。7) Google スケーリング レールを使用すると、多くの優れた情報が表示されます。8) 等等等…

いくつかのプロファイリング ツール (rubyperf、または NewRelic など) を使用できます。それらから得られる応答は、せいぜい大まかなベースラインと見なすのが最適です。単純な理由は、プロファイリングが実際のトラフィック パターンに応じて確実に変化するハードウェア スタックに依存しているからです。静的コンテンツのページが 1 つしかないサイトの場合は非常に簡単ですが、データベースが成長しトラフィックが増加している CMS サイトの場合は非常に困難です。

幸運を！！！

于 2013-04-04T05:35:59.963 に答える