shiba-hiro’s 備忘録

技術ブログの皮を被ったただの備忘録

Tomcat(常駐のアプリケーションサーバープロセス)について 〜 昔はみんなサーバーレスだった

前回の記事では、Javaを利用してAPIを公開するために、いきなりTomcatを持ち出しましたが、今回はTomcatについて少し解説&考察してみます。

shiba-hiro.hatenablog.com

Tomcatの役割

Tomcatは、Javaプログラムを動作させることで、所謂アプリケーションサーバーという役割を果たすことを期待されています。
アプリケーションサーバーは、アプリケーションとして必要なロジックを保持し、リクエストに対して動的にレスポンスを生成して返却します。

対してWebサーバーは、静的なコンテンツを返却するサーバーです。
リクエストの一次受けとルーティングを行うケースもあります。

アプリケーションサーバーやWebサーバーは役割に基づく名前であって、必ずしもツールに張り付く名前ではありません。
なのでTomcatをWebサーバー的に活用することも可能です。
実際、前回の記事では静的なHTMLを返却させることも行ってみました。

Tomcat以前の課題を振り返ると、その役割の意義をより理解しやすいように思います。
登場の背景はこの記事がわかりやすいです。

Tomcatって何ですか? | Think IT(シンクイット)

すなわち、当初はサーバーサイドへのリクエストがあるたびに、サーバー外部のプロセスの起動を行っていました。
が、大量アクセスによるレスポンスの鈍化が見過ごせなくなり、解決策が必要になってきました。
そこで、「逐一プロセスの起動を行わない方法」が出てきます。

Tomcatの動作

「逐一プロセスの起動を行わない方法」として、サーブレットという技術が開発されます。
サーブレットでは、単一のプロセスが常に起動しており、リクエストに応じてプロセス内部のスレッドを起動します。
スレッドの起動負荷はプロセスのそれと比較して小さく、見事問題を解決することができました。

サーブレットを動作させるためには、サーブレットコンテナというサーバーが必要です。
Tomcatは、このサーブレットコンテナのひとつです。

先ほど紹介した記事内では、サーブレットのライフサイクルについても言及されています。
前回、拡張して利用したHttpServletが持っているservice()doGet()といったメソッドがどのように活用されているかをよく理解できると思います。

HttpServlet (Java(TM) EE 7 Specification APIs)

昔はみんなサーバーレスだった?

「常駐するプロセスを用意するのは、リクエストのたびにプロセスを逐一起動するのを避けるためだった」
私はこれを知ったとき、「リクエストごとに起動する方向へ、サーバーレスって名前で回帰してるやん!」と思ってしまいました。

Tomcatはセッション管理機能も有しています。
これも、リクエストごとにプロセスが起動して破棄されるようでは状態を管理できないからと、当時の課題を解決する形でTomcatに備えられたもののようです。
しかしながら、現代的には、アプリケーションサーバーにセッション管理をさせるのは筋が悪いと言えるでしょう。
いまは、大量リクエストを捌くためには、アプリケーションサーバーを水平にスケールさせます。 その際、プログラムのコードと関係ない各サーバーの状態を、物理的に新しく立てるサーバーへコピーするというのは現実的ではありません。
当該セッション情報を利用したいのが、最初にリクエストを受け取ったアプリケーションだけとも限りません。
ログイン情報などはインメモリのキャッシュサーバーを別途立てて管理するのが通例でしょう。

そして水平にサーバーを稼働させるのであれば、要請に応じてすぐ起動できるようにアプリケーションを構成する必要があります。
より粒度の高いモジュール編成やデプロイが追求されます。
(起動にかかる時間を見越して、特定の閾値を超えれば前のめりでサーバーを起動させるのが普通でしょうけれども)
結果、すぐに起動できるプロセスになるのであれば、なおのこと常駐のプロセスなんて要らないよね、という話になります。

常駐プロセスの登場もスケーラビリティの要請に沿ったものなのにも関わらず、さらにスケーラビリティの要請に応えようとするとそういった技術に頼らない構成になる。
これは、とても興味深い事象だなと感じます。
(もちろん、巨大なサーバーが常駐することで発生する無駄なリソースの消費を抑えたいという別面の要請もありますが)

この変遷は、個人的には、プロセスを動作させるハード面の性能向上とネットワーク環境の向上、クラウド環境の充実によるものなのかなと考えています。
(言わずもがな、その根底には、デバイスの普及やコンテンツへの要求水準向上もあったでしょう)
前提が変わると、選択可能な手段はドラスティックに変わるということですね。
基盤に近いインフラの進化がもたらす変化の大きさを理解できる事例だなとも思います。