私はHerokuでホストされているRailsアプリを持っています。mySQLデータベースに対して長いバックエンド計算とクエリを実行する必要があります。
私の理解では、DelayedJobまたはWhenever gemを使用してバックエンドプロセスを呼び出すと、Rails（フロントエンド）サーバーのパフォーマンスに影響があります。したがって、2つの異なるRailsサーバーをセットアップしたいと思います。
最初のサーバーは、通常のRailsアプリと同様に、フロントエンド（ユーザーの要求に応答する）用です。2番目のサーバー（これもRailsサーバー）は、バックエンドのクエリと計算専用です。mySQLからのみ読み取り、計算を行い、結果を別のRedisサーバーに書き込みます。
私の感覚では、Rails開発者の多くはこれを行っていません。彼らは、Railsサーバーでバックグラウンドジョブを実行し、必要に応じてワーカーを追加することを好みます。私のサーバー構造は良いデザインですか、それともやり過ぎですか？知っておくべき落とし穴はありますか？
ありがとうございました。
DelayedJobのようなバックグラウンドジョブがメインアプリケーションに別のサーバーよりも多くのオーバーヘッドを引き起こす理由はわかりません。DelayedJobは独自のプロセスで実行されるため、メインアプリのdynoは影響を受けません。唯一の影響はデータベースクエリにある可能性がありますが、それはバックグラウンドジョブからでも、同じデータベースにアクセスしている別のアプリからでも同じです。
プライマリアプリでDelayedJobとワーカーを使用することをお勧めします。それは物事をシンプルに保ち、パフォーマンスの面で悪化することはありません。
パフォーマンスが本当に心配な場合に考慮すべきもう1つのことは、データベースを「フォロワー」にすることです。これは、事実上、プライマリデータベースを最新の状態に保つが、読み取りにのみ使用できる（書き込みには使用できない）2番目のデータベースです。それについてのより良いドキュメントがあるかもしれませんが、ここでアイデアを得ることができますhttps://devcenter.heroku.com/articles/fast-database-changeovers#create_a_follower。次に、これらの長いバックグラウンドジョブにここからデータを読み取らせ、メインデータベースにまったく影響を与えないようにすることができます。