普段Java EEを使ってアプリケーションを書いています。
Javaで書かれたサーバープログラムの場合Tomcatなど、Java EEだとWebSphereやGlassfishなどのアプリケーション・サーバー上にデプロイして動かすことになると思います。
RubyにもUnicornやThinなどがあると思います。

不勉強で申し訳ないのですが、私はずっと「サーバープログラムを動かすためにはアプリケーションサーバーが必要」だとばかり思っていました。
先日Node.jsの勉強を初めたのですが、Node.jsやGo言語にはアプリケーションサーバーがなく、ポートのlistenなどの処理を自分で書いて実行するものだと知りとても驚きました。

これを知ったとき、「デプロイが簡単そうだ」「処理が追いやすくてわかりやすい」など良い印象ばかり感じたのですが、同時に、「アプリケーションサーバーがなくて大丈夫なんだろうか」と疑問に思っています。

なんとなく自分の中で「アプリケーションサーバーがいい感じに処理していてくれている」という安心感があるため、いままでアプリケーション・サーバーが担当していた部分を自分で書くということに（この認識があっているのか心配ですが・・・）不安を感じています。（リッスンの仕方やメソッドの呼び方など）

なぜNode.jsやGo言語にはアプリケーション・サーバーが必要ではないのか、あるいは、なぜJavaやRubyではアプリケーション・サーバーが必要なのか教えていただきたいです。

また、アプリケーション・サーバーが存在することのメリット・デメリットもわかる方がいたら教えてほしいです。

行動規範の内容に同意します

回答2件

ベストアンサー

時代が変わって来て変化への対応が求められる様になってきたからです。

Java のアプリケーションサーバが流行り始めた 1990 年代後半から 2000 年前半にかけては、リッチなマシンリソースを手に入れるのも難しく、それに加えて Java はリソース食いと悪評もありました(今でも変わりませんが)。アプリケーションサーバを導入するのは今でこそ簡単になりましたが昔は手間で、マシンリソースが足らなくなったら別のサーバを用意してアプリケーションサーバをインストールし、Java アプリケーションをデプロイして来ました。勿論サーバが起動した後もこまごまとしたチューニングも必要でした。しかし時代も変わりリッチなリソースのマシンを手に入れやすくなったと同時に、即時性も求められる事になりました。

環境構築のしやすさ

アプリケーションーサーバが持っていなかった物を Go や node は持っています。Go であればアプリケーションのバイナリ1つをコピーすれば良いですし、node であれば node のランタイムこそ必要ですが、アプリケーションが格納されたフォルダをそのまま別の環境に持っていけば動くのです(さすがに同じOSに限ります)。もちろん Java にも war という仕組みはありますが、その引っ越し先のサーバにもアプリケーションサーバが構築されている必要があります。

Java はマルチプラットフォームをウリにしていましたが、Go であれば Windows から Linux の実行バイナリを生成する事も出来ます。

標準ライブラリ

Java は Servlet API という仕様だけを策定し、サーバやミドルウェア自体はサードパーティが実装するという方法を取りました。それはそれで良いデザインなのですが、サードパーティの実装差異により開発者が苦しめられる事もしばしばありました(今でもありますし先日もありました)。またアプリケーションサーバのバージョンが上がると、そのアプリケーションサーバで動くアプリケーション全てに影響が出る事もありました。非推奨の API を使っていた事で対応を同調しないといけないといった事もしばしばありました。Go や node はオフィシャルから標準ライブラリとしてウェブサーバを提供する事で、こういった問題を回避しています。

スケールアウトのしやすさ

最近のウェブサービスではマイクロサービスという、システムを複数のサービスの集合として作る事が一般的になってきました。いざユーザ数が増えてきたり負荷が増大してきた時に、小さく分けられたサービスを新しく増やしてスケールアウトする事で、変化に対応しやすい様にする為です。始めは小さく、後に大きくといった事を行うのがマイクロサービスです。アプリケーションサーバの場合はスケールアップが一般的で、コストも掛かります。

投稿2017/12/12 04:59