Ruby on Railsを使用して写真共有用のソーシャルアプリ（本当にシンプル）を作成しています。いくつかのRails依存関係とMySQLをデータベースとして使用しています。また、購入済みのカスタムドメインを使用する必要があります。
私はいくつかの疑問があります：
アプリを高速にスケーリングする必要がある場合、DigitalOceanで十分ですか？
Railsのアスペクトをインストールおよび変更できるシェルにアクセスできますか？
バックアップやその他のものを含め、MySQLに完全にアクセスできますか？
スターターアプリケーションのためのより良い解決策はありますか？
HerokuのようなPaaSプロバイダーとDigitalOceanのようなIaaSプロバイダーのどちらかに行くには2つの方法があります。
アプリを実行する実際のアーキテクチャの可視性が低くなり、スケーリングが少し簡単になりますが、コストが高くなります。また、可視性が低い場合は、コードの微調整や単純なアーキテクチャの選択を使用して、複雑さを増すことなくパフォーマンスを向上させることに集中できません。
あなたはすべてに責任があります。つまり、初期設定といくつかの新しいことを理解するためにより多くの時間を費やす必要があります。ただし、アプリケーションがハードウェアとどのように相互作用するか、およびスケーリングするためにどの要素を微調整する必要があるかについて、よりよく理解できます。
サイトのどの部分でスケーリングが最も困難になるかを事前に推測できます。しかし、結局のところ、計画の量に関係なく、最終的にはボトルネックになります。したがって、パフォーマンスの壁にぶつかったときに遅延し、実行したときにスケーリングしやすくするために実行できるいくつかの簡単な手順を次に示します。
専用DBインスタンス-最初からDBサーバーを独自の仮想マシンに移動します。DBサーバー、キャッシュサーバー、およびアプリサーバーのワークロードは異なり、単一の特定のタスクを処理する場合に最適化されます。また、VMのすべてのリソースをDBに使用することもできます。
Nginxロードバランサー-DBが別のサーバー上にあるので、従来のアプリ/ウェブサーバーを作成できます。2つのWebサーバーを作成し、これらのマシンに負荷を分散できるNginxロードバランサーを作成することをお勧めします。より多くの構成ですが、サーバー＃3、＃4、＃Nを追加すると、単純な構成変更になります。
キャッシング！-すべてをキャッシュします！DBの前にクエリされるmemcacheを使用するような単純なものでも、サイトで最も一般的にヒットするURLまたはパーシャルのキャッシュページを作成することもできますが、キャッシュによって読み込み時間が大幅に改善され、より多くのヒットを提供できるようになります。サーバーの数が減り、キャッシュを節約できます。
オブジェクトストア/コンテンツ-重いコンテンツコンポーネントがある場合は、最初からAmazonのS3のようなオブジェクトストアを使用する必要があります。これを最初からアプリに統合することで、後でこれを再設計する必要がなくなります。それはあなたにもう少しお金がかかりますが、あなたはまたあなたが複数のボリュームを管理する必要がないことからあなた自身を救っている頭痛を考慮しそして起こるスケーリング問題のいくつかに対処する必要があります。
構成管理：Puppet / Chef -DB、Web / App、ロードバランサー、キャッシュの2種類のサーバーが用意されたので、PuppetまたはChefを使用してセットアップすることをお勧めします。ここでも学習曲線がありますが、特定のインスタンスタイプにN + 1サーバーを追加する必要がある場合は、2時間ではなく2分かかります。
もちろん、他にも多くの考慮事項がありますが、最初から前向きに実行する手順が多いほど、スケーリングへの道が容易になります。実行するステップの数に関係なく、スケーリングの問題が発生するため、MVPリーンスタートアップアプローチでこれをバランスさせることが重要です。これにより、完璧なインフラストラクチャのセットアップに何ヶ月も費やさないようになります。多くのトラフィックに見舞われていないので、すべてのサーバーがあるかどうかは重要です。
この記事の背後にある基本的な考え方は、あなたの主な質問はPaaSとIaaSであり、IaaSルートに進む場合はDigitalOcean（私は共同創設者なので）は素晴らしい選択ですが、最終的にIaaSプロバイダーでの最大の勝利はアプリを設定する際の賢明な決定はほとんどありません。
アプリケーションはDigitaloceanVPSで実行できるようです。