Ruby on Rails アプリケーションをスケールするための開発者ガイド

アプリケーションの作り手にとって、これほど多くのユーザーを抱えることは成功であると同時に挑戦でもある。まずやるべきことは、製品やサービスに対する関心の高まりに対処することです。逆に、技術的な準備が不十分だと、アプリケーションの崩壊につながりかねない。幸いなことに、この問題を解決することは可能です。私たちの助けを借りて、Ruby on Railsアプリケーションをスケールさせる方法を学びましょう。

フレームワークの拡張性は？

フレームワークのスケーリングとは、1分あたり（RPM）より多くのリクエストを生成するために、アプリケーションのキャパシティを増やすことを意味する。サーバーシステム全体のインフラよりも、フレームワーク自体の面倒を見ることの方が重要ではありません。これが実際にどのように機能するかを見てみましょう。

数人が乗れるエレベーターが1基しかない高層ビルを考えてみよう。景観を楽しみたいという関心が高いため、エレベーター内は混雑し、まともに機能しなくなる。ビルが完成する前に、適切なインフラを確保するか、より多くの人を上まで運ぶ方法を開発することが不可欠である。ここで説明したエレベーターは、適切なスケーリングのないアプリケーションに相当する。結果として損失が発生し、それは非常に痛いものとなる。

アプリケーションを拡張しないとどうなるのか？

トラフィックの増加に応じてアプリケーションが拡張されないと、動作が遅くなり、クラッシュすることさえある。これは起こりうる問題の始まりに過ぎません。解決策が遅れれば顧客は離れていき、その不満はオンラインレビューに反映される。スケーリングは軽視されることなく、迅速に改善されるべきです。

アプリケーションの規模を拡大する際、どのような障害に直面する可能性がありますか？

スケーリングを始めるのは簡単だが、それを実行するのは難しい。アプリケーション・アーキテクチャが障害の一つかもしれない。例えば、現実的に関心の高いソリューションが実装されていない場合、リクエスト処理に問題があるかもしれない。きれいでモジュール化されたコードは RoRアプリケーション.

 このアプローチでは、より多くのデータベース管理システムとの統合が有利になる。さらに、より多くのリクエストを処理するためにロードバランサーを配置することも問題ない。

Ruby on Railsはスケーラブルですか？

その結果、Rubyアプリケーションは簡単に拡張できる。Rubyの水平スケーリング機能とスレッドセーフの性質により、これには2つの理由があります。基本的には、より多くのトラフィックを処理するために、より多くのRubyプロセスを起動し、より多くのサーバーをアプリケーションに接続すればよいのです。 

Ruby on Railsアプリケーションをスケールさせるヒント

そのうちのいくつかはRuby on Railsに特有のものだが、他のものはどんなシェアードナッシング・アプリケーション・サーバーにも適用できる。

• 最初のルールは、キャッシュし、キャッシュし、キャッシュし、さらにキャッシュすることだ。

データはクライアントでキャッシュし、JQueryのようなAjaxライブラリを使用してブラウザにストリーミングすることができます。有効期限やetagsの使用方法、ゲートウェイ/リバースプロキシキャッシュを使用したHTTPレスポンスのキャッシュ方法を学びましょう。アクション、ページ、フラグメントに対するRailsの組み込みキャッシュを活用しましょう。データベースの結果は、Memcacheから取得するのではなく、Memcacheを使用してキャッシュできます。

• データをデータサービングから切り離す

すべてのデータを "便宜上 "1つのデータベースに入れてはいけない。独立したデータセットには別のデータベースを使うべきである。静的アセットを別のティアで利用できるようにするか、Amazon S3やアカマイを使って配信する。コストは高くなるが、スケーリングは容易になる。すべてのデータストアにリレーショナル・データモデルが必要かどうか、DBAと話し合いましょう。データがより単純であれば、キー・バリュー・データ・ストアを使用できるかもしれません。大量の非構造化データを保存・分析する場合は、RubyクライアントがあるのでHadoopを使う。ファイルシステムを使う場合は、そのスケーラビリティの限界にも注意する必要がある。大量のデータ報告が必要な場合は、本番用データベースではなく、メイン・データベースのコピーを使用する。

• 外部依存の最小化と管理

サイトが広告ネットワークやRSSフィードのような外部サービスに依存していないことを確認する。サービスが応答しなかったり、増大するリクエスト量に対応できない場合に備えて、バックアップ・プランがあることを確認してください。

• ジョブハンドラーとデータベースを最新の状態に保つ

RailsのActiveRecordを含め、どのORMでも生成されるSQLクエリがデータベースパフォーマンスの問題を引き起こすことがあります。大規模な統合を行った場合は、低速なクエリログをチェックして、「見つからない」データベースインデックスがないか、Railsコードに不適切なfind-allが含まれていないかを確認してください。定期的にデータベースをチェックして、不要になったインデックスがないか確認する必要があります。スケジュールジョブやバックグラウンドジョブのリソース使用状況にも注意してください。

 ユーザーが増えるにつれてジョブが重なり、毎日のログ処理に24時間以上かかるようになることも珍しくない！このようなことで不意打ちを食らうのは簡単です。ジョブが別々の階層に分離されていることを確認してください。ビジネスが成長するにつれて、最終的にはメッセージベースのジョブハンドラーに移行したくなるかもしれません。

• 避けられないリレーショナル・データは、シャード化すべきである。

MySQLデータベースは、高いスケーリングレベルでシャーディングする必要があります。シャーディングのプロセスでは、キーに基づいてデータセットを独立した断片に分割します。ユーザーIDに基づくシャーディングは、ほとんどのコンシューマー向けRailsサイトで使用できますが、データ年齢やアクセス頻度に基づくシャーディングスキームもあります。

結論

プロジェクトのタイプによって、Ruby on Railsベースのアプリケーションのスケールは異なるはずです。他の多くの技術と同様、RoRはすべての問題に対する答えではありません。したがって、アプリケーションを開発する前に、あなたのビジネス プロファイルとRailsの機能を比較することが重要です。私たちは Ruby on Rails開発会社 レイルスカルマ 専門家が必要な場合 RoRサポート.すべての段階 アプリケーション開発 は、経験豊富なプロフェッショナルチームが対応いたします。