APサーバ(静的コンテンツを返す)、APサーバ(アプリケーションを実行する)、DBサーバのようにすることもできると思います。この構成のデメリットは何でしょうか
絶対的にこうだ、というものではないと思います。
そもそも、WEBサーバ、APサーバの区分けは相対的なものです。たとえば、Railsのアプリで、以下の構成だとApacheはWEBサーバです。
Apache(REeverse Proxy=WEBサーバ) - Puma(APサーバ) - MySQL(DBサーバ)
以下の構成だとApacheはAPサーバです。
Nginx(WEBサーバ) - Apache+mod_passenger(APサーバ) - MySQL(DBサーバ)
後者だと、Nginxはなくても問題ないわけですが、Nginxがキャッシュサーバとしての性能が優れているので、ウェブサイトとしての性能が向上することを期待してNginxを配置するわけです。
しかし、であれば、下記の構成でよいのではないかという話も出てきて、こちらが最近の主流かと思います。
Nginx(REeverse Proxy=WEBサーバ) - Puma(APサーバ) - MySQL(DBサーバ)
さて、上記の構成でNginxを取り除くことは可能でしょうか。PumaはHTTPSに対応しているので、一応以下の構成でも動きます。
Puma(WEBサーバ 兼 APサーバ) - MySQL(DBサーバ)
ところが、この構成だと、2つの問題があります。まず、WEBサーバの性能がNginxほどではないということ。次にセキュリティの問題があります。
上記の構成で80/TCPなり443/TCPなりで待ち受けするには、Pumaをroot権限で動かさなければなりません。
参考: [rails5 + puma]一般ユーザで443ポートのpumaを起動できない
そうすると、万一Railsのアプリケーションに脆弱性があった場合に、サーバのroot権限が奪取されることになります。この問題はApache Tomcat等でも現実に存在します。なので、仮にPumaやTomcatでHTTPSで待ち受ける場合には、Pumaを一般権限で動かして3000ポート等で待ち受けておき、ルータやiptablesなどで443等に振り向けてやります。ApacheやNginxの場合はいったんはroot権限で起動した後一般ユーザの権限で動作するのでこの問題は緩和されてます。
また、一部のPumaの脆弱性は前段にNginxをたてることで緩和されます。
JVNDB-2020-002385 - JVN iPedia - 脆弱性対策情報データベース
まとめると、3層構造のアプリケーションには性能やセキュリティ面でのメリットがある 場合があります が、構成にもよるため、個別の検討が重要ということです。