3.3.2 Web サーバーから AP サーバーまで
「動的コンテンツ」へのリクエストを処理するのがAPサーバーです。図3.12で、具体的な処理内容について見てみましょう。
全体の流れとしては、以下となります。
（1）Webサーバーからのリクエストが到着する
（2）スレッドがリクエストを受け取り、自分で計算できるのか、DBへの接続が必要か判断する
（3）DBへの接続が必要な場合、コネクションプールにアクセスする
（4）～（5）DBサーバーにリクエストを投げる
動的コンテンツへのリクエストに対しては、まだ存在しないコンテンツを可及的速やかに作り出す必要があります。この役割を担うのがAPサーバーです。
Javaを利用したAPサーバー上では、Java Virtual Machine（JVM）と呼ばれる仮想マシンが動いています。このJVMも、実は1つの巨大なプロセスです。仮想マシンという名前の通り、それ単体で1つのOSであるかのように、さまざまな機能を備えています。その中で動く1つのスレッドが、リクエストを受け取ります。
たとえば、このリクエストが「1＋1の計算結果」を求めるものだとします。こういった単純なリクエストはアプリケーション上で計算すれば良いので、APサーバーの担当スレッドが計算を行ない、結果を返します。
たとえば、このリクエストが「ユーザーの残高情報」だとします。こういった情報はAPサーバーでは持っていません。1つの銀行には口座数が数十万、数百万といった単位で存在します。APサーバー上でこれらすべてのデータを管理することは現実的ではなく、大量データを管理するにはDBサーバーが向いています。こういったケースでは、APサーバー上のスレッドはDBサーバーへの問い合わせを行ない、その結果をまとめてから返します。
APサーバーからDBサーバーへのアクセスには「ドライバー」が利用されます。前述のカーネルのデバイスドライバーと同じような位置づけであり、その裏側にあるデータベースへのインターフェースとなり、そのデータベース自体を隠蔽する役目があります。
DBサーバー以外の選択肢
さて、データが欲しければDBサーバーへアクセスするのが一般的ですが、必ずしもこれは効率的ではありません。
たとえば、「日本の都道府県情報」は頻繁に変更されるものではないので、これを毎回データベースに問い合わせる必要はありませんよね。こういった小規模かつ更新頻度が少ない情報は、図3.13のように、JVM内部にキャッシュとして格納しておいて、そのまま返すことが有効です。
また、JVM内部ではなく、他のキャッシュ専用サーバーを利用していることもあります。その場合は、ネットワーク経由で、さらに問い合わせが行なわれます。
3.3.3 AP サーバーから DB サーバーまで
図3.14のDBサーバー上では、Oracle Databaseであればサーバープロセスがリクエストを受け取ります。リクエストはSQLという言語の形でやってきます。このSQLを解析し、データのアクセス方式を考え、ディスクやメモリ上から必要なデータだけを集めてくるのが、データベースの主な仕事です。
全体の流れとしては、以下となります。
（1）APサーバーからのリクエストが到着する
（2）プロセスがリクエストを受け取り、キャッシュが存在するか確認する
（3）キャッシュになければ、ディスクにアクセスする
（4）ディスクからデータが返る
（5）データをキャッシュとして格納する
（6）結果をAPサーバーに返す
DBサーバーにもさまざまなソフトウェアがあります。Web系のシステムでポピュラーなものとしてはMySQLやPostgreSQL、企業向けではOracle社の提供するOracleDatabase、Microsoft社の提供するSQL Serverなどがあります。ここでは、OracleDatabaseを用いて説明を進めます。
DBサーバーはデータの格納庫です。管理対象データは膨大なので、いかに効率的にアクセスするかを重視します。多くのケースでは、まずサーバーのメモリ上にキャッシュがないか確認します。存在しない場合は、ディスクにアクセスして、必要なデータを持ってきます。このキャッシュの仕組みについては第5章をご覧ください。
上記はOracle Databaseの例ですが、たとえばインメモリデータベースなどでは、そもそもディスクを多用せず、すべての処理をメモリ内で完結させるようなアーキテクチャを取り、高速化を実現しています。
Webサーバーでは個々のプロセスが独立して動いている例を示しましたが、DBサーバー上では、複数のプロセスが役割を分担することがあります。
たとえばOracleDatabaseでは図3.15のような作業分担が行なわれています。リクエストをSQLとして受け付けて解析やデータへのアクセスを行なうプロセスもあれば、メモリ上にキャッシュとして格納されたデータとディスク上のデータの「定期的な同期」を行なうプロセスもあります。これは、分業することで処理を並列化し、「スループット」を向上できるからです。この観点についても第8章でより詳しく説明します。
さて、これまでに挙げてきた図では、DBサーバーにおけるディスクへのアクセス部分は簡略化されており、多くのエンタープライズ向けシステムの実情を表わしていません。実際にはDBサーバー内部のディスクは耐障害性という観点で劣るため、それを直接利用するケースは少ないです。
多くのケースでは、図3.16のように別のストレージ装置へのアクセスが行なわれます。
ストレージ装置には、多数のディスクが格納されています。しかし本質的なアーキテクチャは、これまで登場したWebサーバー、APサーバー、DBサーバーと大差なく、同じようにCPUやメモリがあり、OSが動いています。
メモリ上にデータをキャッシュとして格納する仕組みもあります。大量データへの高速アクセスに特化している専用サーバーであるとイメージしてください。外部ストレージの利用例については、第8章で紹介します。
