SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

EnterpriseZine Day 2024 Summer

2024年6月25日(火)オンライン開催

予期せぬ事態に備えよ! クラウドで実現するIT-BCP対策 powered by EnterpriseZine

2024年7月10日(水)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

翔泳社の本

ITインフラのキホン:3階層型システムを見てみよう【中編】


3.3.2 Web サーバーから AP サーバーまで

 「動的コンテンツ」へのリクエストを処理するのがAPサーバーです。図3.12で、具体的な処理内容について見てみましょう。

 全体の流れとしては、以下となります。

 (1)Webサーバーからのリクエストが到着する

 (2)スレッドがリクエストを受け取り、自分で計算できるのか、DBへの接続が必要か判断する

 (3)DBへの接続が必要な場合、コネクションプールにアクセスする

 (4)(5)DBサーバーにリクエストを投げる

図3.12 WebサーバーからAPサーバーのデータの流れ
図3.12 WebサーバーからAPサーバーのデータの流れ

 動的コンテンツへのリクエストに対しては、まだ存在しないコンテンツを可及的速やかに作り出す必要があります。この役割を担うのが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.13 DBサーバー以外の選択肢
図3.13 DBサーバー以外の選択肢

3.3.3 AP サーバーから DB サーバーまで

 図3.14のDBサーバー上では、Oracle Databaseであればサーバープロセスがリクエストを受け取ります。リクエストはSQLという言語の形でやってきます。このSQLを解析し、データのアクセス方式を考え、ディスクやメモリ上から必要なデータだけを集めてくるのが、データベースの主な仕事です。

 全体の流れとしては、以下となります。

 (1)APサーバーからのリクエストが到着する

 (2)プロセスがリクエストを受け取り、キャッシュが存在するか確認する

 (3)キャッシュになければ、ディスクにアクセスする

 (4)ディスクからデータが返る

 (5)データをキャッシュとして格納する

 (6)結果をAPサーバーに返す

図3.14 APサーバーからDBサーバーに来て、戻るまでのデータの流れ
図3.14 APサーバーからDBサーバーに来て、戻るまでのデータの流れ

 DBサーバーにもさまざまなソフトウェアがあります。Web系のシステムでポピュラーなものとしてはMySQLやPostgreSQL、企業向けではOracle社の提供するOracleDatabase、Microsoft社の提供するSQL Serverなどがあります。ここでは、OracleDatabaseを用いて説明を進めます。

 DBサーバーはデータの格納庫です。管理対象データは膨大なので、いかに効率的にアクセスするかを重視します。多くのケースでは、まずサーバーのメモリ上にキャッシュがないか確認します。存在しない場合は、ディスクにアクセスして、必要なデータを持ってきます。このキャッシュの仕組みについては第5章をご覧ください。

 上記はOracle Databaseの例ですが、たとえばインメモリデータベースなどでは、そもそもディスクを多用せず、すべての処理をメモリ内で完結させるようなアーキテクチャを取り、高速化を実現しています。

 Webサーバーでは個々のプロセスが独立して動いている例を示しましたが、DBサーバー上では、複数のプロセスが役割を分担することがあります。

 たとえばOracleDatabaseでは図3.15のような作業分担が行なわれています。リクエストをSQLとして受け付けて解析やデータへのアクセスを行なうプロセスもあれば、メモリ上にキャッシュとして格納されたデータとディスク上のデータの「定期的な同期」を行なうプロセスもあります。これは、分業することで処理を並列化し、「スループット」を向上できるからです。この観点についても第8章でより詳しく説明します。

図3.15 Oracle Databaseのプロセス間での作業分担
図3.15 Oracle Databaseのプロセス間での作業分担

 さて、これまでに挙げてきた図では、DBサーバーにおけるディスクへのアクセス部分は簡略化されており、多くのエンタープライズ向けシステムの実情を表わしていません。実際にはDBサーバー内部のディスクは耐障害性という観点で劣るため、それを直接利用するケースは少ないです。

 多くのケースでは、図3.16のように別のストレージ装置へのアクセスが行なわれます。

図3.16 外部ストレージ装置へのアクセス
図3.16 外部ストレージ装置へのアクセス

 ストレージ装置には、多数のディスクが格納されています。しかし本質的なアーキテクチャは、これまで登場したWebサーバー、APサーバー、DBサーバーと大差なく、同じようにCPUやメモリがあり、OSが動いています。

 メモリ上にデータをキャッシュとして格納する仕組みもあります。大量データへの高速アクセスに特化している専用サーバーであるとイメージしてください。外部ストレージの利用例については、第8章で紹介します。

次のページ
3.3.4 AP サーバーから Web サーバーまで

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
関連リンク
翔泳社の本連載記事一覧

もっと読む

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/13392 2020/11/19 17:48

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング