私はREST APIをまとめていますが、それがどのようにスケーリングされるか、またはそれに対する需要がどのようになるかがわからないため、使用をレート制限し、リクエストを一時的に拒否できるようにしたいと考えています.ボックスが容量を超えているか、何らかのスラッシュドット シナリオがある場合。
また、容量を追加してサービスをスケーリングする必要がある場合は、(メイン サービスが少しオフラインであることを示す結果をクライアントに提供しながら) サービスを一時的に正常に停止できるようにしたいと考えています。
この種のベストプラクティスはありますか? 実装はRails with mysqlです。
これはすべて、世界をリッスンする外部Webサーバーで行われます（nginxまたはlighttpdをお勧めします）。
レート制限に関しては、nginxは制限することができます。つまり、IPごとに50 req /分で、カスタマイズ可能な503ページ全体を取得できます。
予想される一時的なダウンに関しては、railsの世界では、これは特別なmaintenance.htmlページを介して行われます。Railsアプリサーバーがダウンしたときにそのファイルを作成またはシンボリックリンクするある種の自動化があります。ファイルの存在ではなく、アプリサーバーの実際の可用性に依存することをお勧めします。
しかし、実際には、接続をまったく失うことなくサービスを開始/停止することができます。つまり、異なるUNIXソケット/ IPポートでアプリサーバーの個別のインスタンスを実行し、バランサー（nginx / lighty / haproxy）にその新しいインスタンスも使用させることができます。次に、古いインスタンスをシャットダウンすると、すべてのクライアントに新しいインスタンスのみが提供されます。接続が失われることはありません。もちろん、このシナリオは常に可能であるとは限りません。新しいバージョンで導入した変更の種類によって異なります。
haproxyはバランサーのみのソリューションです。ファーム内のアプリサーバーへのリクエストのバランスを非常に効率的にとることができます。
非常に大きなサービスの場合、次のような結果になります。
非常に小規模なサービス（2K rps未満）の場合、すべてのバランシングは1〜2台のWebサーバー内で行われます。
すでに良い答えです。リミッターを自分で実装したくない場合は、API のレート制限や分析などを行う3scale ( http://www.3scale.net ) などのソリューションもあります。これは、3scale アーキテクチャにフックするプラグイン ( ruby api プラグインについてはこちらを参照) を使用して動作します。また、ニスを介して使用し、ニスをレート制限プロキシとして機能させることもできます。
アプリケーションの外部でレート制限を実装することをお勧めします。そうしないと、トラフィックが多いとアプリが強制終了される可能性があります。良い解決策の1つは、 mod_evasiveのようなものを使用して、Apacheプロキシの一部として実装することです。