モジュラーWebアプリネットワークアーキテクチャ
私が専用の物理サーバーまたはVPSを扱っていると想定すると、Webアプリケーションをホストするために、次の役割を持つ個別のサーバーをセットアップすることは理にかなっていますか？
- リバースプロキシ
- ウェブサーバー
- アプリケーション・サーバー
- データベースサーバー
興味のある特定のポイント：
Webサーバーとアプリケーションサーバーを分離する方法すら混乱しています。私の理解は、そのような 層アーキテクチャ は実現可能であるということでした。
アプリサーバーがWebサーバーとデータベースサーバーの間に直接存在するのか、またはWebサーバーがデータベースと直接やり取りできるのかは、はっきりしません。アプリサーバーは、アプリサーバーに代わって大量の計算を行うか、すべてのビジネスロジックを制御する強力なおよび制御（上の図に示されているように、Webサーバーからの直接データベースアクセスを拒否します）。
また、上記の設定を前提として、リバースプロキシ（例 nginx ）がどのような役割を果たし、Webサーバーとして実行する必要があるのかわかりません。 nginxにはWebサーバー機能があることを知っています。しかし、理論的にはWebサーバーがアプリサーバーから分離されることを考えると、リバースプロキシを独自のVPSにすることが理にかなっているかどうかはわかりません。
重要なルールを1つ覚えておいてください。
アーキテクチャをスケーラブルにすることや、すべてを最初の段階で行うことについてあまり心配しないでください。ユーザー/トラフィック/機能/その他の結果としてアプリケーションが進化するにつれて、数回変更する必要がある場合があります。
REALユーザーが試して、フィードバックに基づいて行動できるように、何かを出荷することに取り掛かってください。何を計画するにせよ、それは変わる可能性があるので、あまり多くを先に計画しないでください。
質問に関しては、リバースプロキシとWebサーバーは、一般的に同じアプリケーション（通常、最初はnginx）にすることができます。次に、スケールアウトすると、ワニスはより強力なリバースプロキシになります。
NginxのようなWebサーバーは、データベースと直接通信することはありません。アプリケーションサーバーは、2つの間にあります。
-更新-
上記は、建築について考える必要がないという意味ではありません。それは最初からすべての建築の細部を正しく取得することについて心配しないことを意味します。
ただし、高レベルのシステム形状について考える必要があります。コンポーネント間の相互作用は、具体的な実装を開始する前に十分に検討する必要があります。
3層アーキテクチャの場合、（部分的に）拡張しようとしています。つまり、一部の処理を単一のデータベースから少数のアプリケーションサーバーにオフロードし、それらの処理を多数のWebサーバーにオフロードします。これにより、専用の層ごとにコードを記述できるため、DBサーバーはDBのみを実行し、アプリサーバーはデータの読み取り（およびキャッシュ）のみを行い、ビジネスロジックを適用します。また、Webサーバーは、クライアントに結果。
このような3層アーキテクチャを作成する理由は他にもあります。セキュリティが大きな理由の1つです。このような安全なアーキテクチャでは、Webサーバーが危険にさらされる可能性が最も高いと考えられているため、低特権環境で実行されます（たとえば、 DB-誰かがあなたのウェブサーバーにアクセスし、それが任意のDBテーブルを読み取ることができる場合、またはあなたのすべてのパスワードは彼らのものです。もしそれができるすべてのことがアプリケーションサーバーへのAPI呼び出しを行うことであるなら、彼らもまたアプリケーションサーバーをハックする必要があります）。
多くの物理サーバーなしでこのようなアーキテクチャを作成できます。VMで実行するか、各層を個別のサービスとして作成するだけです。ウェブサーバーは1つで、そのコードは、アプリサーバーにあるサービスを呼び出しますが、それ以外の場合は、同じ通信チャネルを使用して通信するローカルサービスにすぎません。
多くの点で、このアーキテクチャを簡単に概念化できます。サードパーティのサービスを使用している場合、すでにn層である場合、「アプリケーションサーバー」は、使用するサードパーティのサービスです。そのため、サイトの一部にGoogleマッピングサービスを使用している場合、明らかに別のサーバーで実行されており、ネットワークコールを行って自分のデータと組み合わせてページを作成しています。 Googleサービスを独自のDBと通信する独自のサービスに置き換え、3層サービスを利用します。
リバースプロキシは、攻撃者からWebサーバーを保護するという点で、一般にセキュリティ上の問題です。非常に小さな攻撃対象であるため、プロキシをバイパスする必要があります。 3層アーキテクチャでは、アプリケーションサービスから提供されたデータからHTMLを生成する以外に、ウェブサーバーにこの役割を実行させることがよくあります。
アプリケーションサーバーは、JDBCやActiveRecordなどのスーパーバージョン、または使用しているものと考えることができます。一部のアプリケーションはその分離を必要としません。これが最初のパスである場合、前述のように、それについて心配する必要はありません。ただし、データベースとのやり取りを担当するロジックが非常に複雑になっている場合は、それを独自のサービスに分割すると便利です。データベースのプログラミングに関するロジックは非常に複雑で複雑なので、これはほとんど常にビッグデータ環境で行われます。
MySQLやPostgresよりも複雑なものを必要としない単純なWebアプリさえあれば、私はまだApp Serverについて心配していません。 Webサーバーに適切なWebフレームワーク（Play、Django、Railsなど）を使用している場合、コードは十分にモジュール化されており、DAOレイヤーをREST/HTTPレイヤーと交換して新しいアプリサーバーと通信できます。難しいことではありません。
Webサーバーがリバースプロキシとしても機能できることはすでに述べました。繰り返しになりますが、これが将来的に複雑になり、そのロジックに独自のボックスを与えることを正当化することができる場合は、どうしてもそうです。これは、専用のプロキシサーバーを破壊するためにモジュール化されていないコードを解く必要がないように、プログラミングの際にアプリが将来的に方向性を変える可能性があるという事実に注意してください。