この記事では、クローズドベータからオープンユースへの移行時に使用するサーバー構成について説明します。 負荷はあるが、利益はまだないため、価値の問題が最も深刻な期間。
平均的な負荷の期間に関する資料の不足とsynckの要求により、この記事の執筆が促されました。
結果：
- サービスは負荷を処理しました：HackerNews、Habr、およびProductHuntの「人気のある」セクション
- これらの期間中のピーク負荷は、400rpsを超える地域で、約5時間続きました。
- 1分あたり最大10件の登録。
- NewRelicの可用性：過去3か月で96.092％、2月で99.991％
開発の開始以来、Amazon AWS E2を使用しており、Herokuの場合のようにホスティングの制限を回避する方法を探すことなく独自のアーキテクチャを作成し、広範なクラウドソリューションを提供しています。
サービスを稼働状態に維持するために、負荷の急激な増加を避け、トラフィックを徐々に増やして、システムのボトルネックを特定し、作業モードで緊急事態なしにボトルネックを排除できるようにしました。
Amazonの推奨構成：
私たちの構成：
- Haproxyを使用したバランサー（現在ではなく、ルーター）としてのt1.microインスタンス
- nginxパッセンジャーおよびredisを使用したt1.smallおよびm3.mediumインスタンス
- S3ファイルストレージ
- MySqlを使用したRDS m1.smallインスタンス
毎日の請求書：〜8.21 $
注意！ 詳細な請求書を定期的に確認し、Amazonは多くの小さな支出項目の支払いを分配します。また、未使用の項目の請求書は不愉快なことになります。
サーバー構成
このサービスはRailsで書かれていますが、この事実は記事ではほとんど影響を受けません。
開発の開始時には、スワップを有効にした1つのt1.microインスタンスで十分です。 使用期間が無料のAWS無料利用枠では、コストをゼロまで削減できます。
サービスがオープンアクセスになった場合、スキッピングを行わずに、最初からアーキテクチャに容量を大幅に増やす機会を与えることをお勧めします。 分散型マルチサーバーアーキテクチャを使用すると、他の要素に影響を与えることなく、各要素を個別に操作できます（たとえば、インスタンスを再起動したり、電力を増やしたりする必要がある場合）。
必ずモニタリングを使用してください。無料のNewRelicプランで十分です。
プロジェクトのパブリックバージョンを開始するときに、2番目のサーバーm3.medium （1つのIntel Xeon CPU、3.7 GB RAM、磁気ストア、構成済みの交換可能性）を起動します。
サーバーの電力は、Railsアプリケーションの構成を考慮して計算されました。
- Ruby 2.1.0
- Nginx +乗客4
- 各スレッドは約200 MBのメモリを消費します。
開発サーバーと本番サーバー間でリクエストを簡単にルーティングするために、 SSLターミネーションがインストールおよび構成されたHaproxyを持つ1つのt1.microインスタンスを使用しました 。
Haproxy構成でパブリックの代わりにプライベートIPを使用すると、サーバー間の遅延を大幅に削減できます。
時期尚早の最適化を恐れてはいけません。今が彼女にふさわしい時です。 サービスコードで特定されたボトルネックごとに、応答時間を100分の1秒短縮することで、より多くの顧客をサポートし、節約することができます。 コードのサイクルに最大限の注意を払います。この場合、最適化の最大の可能性はそれらにありました。 サイクルの制限を超えるすべての過剰を取り除くことで、応答時間を数十倍に短縮しました。
Amazon SESは Eメールの送信に使用され、
Action Mailerを使用してRailsと完全に統合し、 1日あたり10,000メッセージの無料割り当てを提供します。
ファイル
ファイルはS3に保存されますが、静的（スクリプト、スタイル、画像）の保存には使用しないでください。インスタンス自体にファイルを保存する場合よりも遅延が大きくなります。
ファイルアクセス遅延：
- S3：〜280ms-1.80s
- CloudFront：〜60ms-200ms
ヘッダー{'Cache-Control' => 'max-age = 315576000'}を追加して、S3からのコンテンツのキャッシュを有効にします。
待ち時間を短縮するために、Amazonは、S3からリージョンにコンテンツを配信するサービスであるCloudFrontの使用を提案しています。
CloudFrontトラフィックはS3トラフィックよりも安価です。
データベース
データベースと同じインスタンスをサーバーと同じように使用できますが、これにより要素間の接続が増加し、アーキテクチャの柔軟性が低下します。 データベースには、磁気ストアでRDS db.m1.smallインスタンスを使用します 。これにより、バックアップや構成を心配する必要がなくなります。
最も初期のベータ版から始めて、クライアントはサービスを使用し、データベースにデータがありました。その安全性を確保する必要がありました
地域
潜在的な顧客の地理的条件と、私たちが働きたい市場を考慮する必要があります。全世界をすぐにカバーできますが、ネットワークの遅延は深刻です。
アーキテクチャのすべての要素は同じ地域に存在する必要があります。
リージョン間のダウンロード速度：
実際には、サンクトペテルブルクからUS-EASTリージョンのサーバーへの遅延は、EU-WESTサーバーへの要求時よりも6倍大きくなる可能性があります。
最初からシンプルでモジュール式のアーキテクチャを構築すると、スムーズな成長と高負荷への移行の可能性が高くなります。
お客様のアドバイスやコメントをお待ちしております。Habréからのフィードバックは、サービスの多くのポイントを真剣に改善するのに役立ちました。
使用されるリソース：