ミドルウェア(Web、AP、DB)について知ろう

はじめに

みなさん、こんにちは。第5回の今回はミドルウェア(Web、AP、DB)について詳しく解説していきます。ミドルウェアは、普段パソコンを使用している時には全く意識しない部分ですが、インフラエンジニアにとっては絶対に避けて通れない存在です。

本連載では、これまでサーバ、ネットワーク、仮想化・クラウドと解説してきましたが、ミドルウェアを理解できればインフラエンジニアとしての下地は完成します。分類や製品も多種多様で、一見するととっつきにくい印象を持つ分野でもありますが、そのような漠然とした苦手意識を払拭していければと思います。

ミドルウェアとは

ミドルウェアとは、”middle”と名の付く通り、アプリケーションとOSの中間的な処理を行うソフトウェアのことです。「中間的な処理」と言われてもピンとこない方が多いと思いますが、あまり難しく考えず「ある機能に特化してOSとアプリケーションを補助するソフトウェア」と覚えておけば良いでしょう（図1）。

図1：ミドルウェアの立ち位置

OSはサーバを動かす上で必須のものですが、あくまで基本機能しか持っておらず、業務で求められる機能までは備えていません。しかし、ミドルウェアをインストールすることで特定の処理や複雑な動作が可能になります。また、矛盾するようですがアプリケーションと比べて汎用的な機能を提供しています。まさしく「ミドル」の名にふさわしいソフトウェアなのです。

ここまで読んで、「ミドルウェアはアプリケーション寄りだ」と感じた方もいるでしょう。それでは、なぜインフラエンジニアがミドルウェアを担当するのでしょうか。その理由として、「システムの安定性を実現する上でインフラエンジニアが考える必要がある」ということが挙げられます。

システムは「止まらないこと」を大前提に作られています。ミドルウェアは一見するとアプリケーション寄りの機能を持ってはいますが、その実OSと非常に密接な関係にあり、OSに負荷をかけすぎないことも考えて設計する必要があります。OS（インフラ）の知識がないとミドルウェアを使いこなせないのです。

Web、AP、DBの役割

冒頭でミドルウェア(Web、AP、DB)の解説と書きましたが、実はWeb、AP、DBには製品名として「○○Server」と付くものが数多くあります（図2）。

図2：主なミドルウェアの分類と製品

ミドルウェアは単体で動くのではなく、サーバにインストールしてはじめて使用できます。したがって、ここからは「Web機能に特化したミドルウェア『○○ Server』をインストールした『Webサーバ』」について解説していきます(AP、DBについても同様です)。

1. クライアント・サーバシステム

第1回でも触れましたが、現在の企業における一般的なシステム構成は「クライアント・サーバシステム」です（図3）。

図3：企業における一般的なシステム構成図

皆さんが今見ているこのページも「Webシステム」というWebブラウザを通して利用できるクライアント・サーバシステムの1つです。「クライアント」と「サーバ」のように役割が非対称になっており、クライアント端末に専用のアプリケーションをインストールしなくてもWebブラウザのみでシステムを利用できるという非常に便利なものです(対称の役割を持つ端末が相互に通信することを「Peer to Peer(P2P)」と呼びます)。

そして、図3の「Web3層構造」という網掛け部分が、今回説明するWeb、AP、DBに特化した機能を持つサーバ群です。インフラエンジニアが携わる大規模なシステムは基本的にこのWeb3層構造をベースにしていることが多いため、Web3層構造を理解できるようにWeb、AP、DBをセットで解説していきます。

2. Web(ウェブ)サーバ(図4)

図4：Webサーバの役割

皆さんが持っているPCやスマホのブラウザから見ているコンテンツは、Webサーバから送られてきた文字や画像の集合体です。Webサーバには、主にクライアントからのリクエストに対して「静的コンテンツを見せること」と「APサーバに動的コンテンツを要求し、返ってきた結果を見せること」という2つの役割があります。

Webのミドルウェアとして”Apache HTTP Server”がよく使用されていますが、上記の2つの役割を切り替える具体的な方法はURLで判断されることが一般的です。例えば、”http://www.bfts.co.jp/aaa.html”の場合にはWebサーバに保存されている静的コンテンツ”aaa.html”を返し、”http://www.bfts.co.jp/douteki/aaa.html”の場合にはAPサーバに処理を流して動的コンテンツ”aaa.html”を返すといったことをしています。

なお、第1回でも解説しましたが、DBサーバなどと比較するとクリティカル度（必要不可欠な度合い）が低いためにコストがかけられなかったり、Web、APサーバと1台にまとめられたりと軽視されがちなサーバだったりします。

3. AP(アプリケーション)サーバ(図5)

図5：APサーバの役割

APサーバは、Webサーバから受けたリクエストをもとにJavaやPHPなどで作成されたアプリケーションを実行して動的コンテンツを生成します。また、“必要であれば”DBサーバへリクエストを行い、返ってきたデータを加工して「動的コンテンツ」に埋め込みます。

“必要であれば”というのは、例えば、四則演算のアプリケーションが実装されているAPサーバでクライアントが「1＋1は？」というリクエストを送ると、Webサーバはこれを「動的コンテンツ」と判別してAPサーバにリクエストを投げます。受け取ったAPサーバは四則演算ができるのでDBサーバにリクエストを投げなくても「1＋1＝2」という答えをWebサーバに返すことができます。

しかし、「リンゴとバナナの合計金額は？」というリクエストが飛んでくると、APサーバにはリンゴとバナナの値段のデータが存在しないため、DBサーバにリクエストする必要があります。そして、DBサーバからリンゴとバナナの値段が返ってきたらAPサーバは計算して結果をWebサーバに返します。

それでは、四則演算のプログラムをインフラエンジニアが作るのかというと、そうではありません。プログラムを作るのはアプリケーションエンジニアの役割で、アプリケーションエンジニアがプログラムを実行できる環境を作ることがインフラエンジニアの役割です。

4. DB(データベース)サーバとは(図6)

図6：DBサーバの役割

DBサーバとはデータベース管理システム（一般にDBMS（DataBase Management System）と省略）が動作しているサーバのことを指します。「データベース」と聞くとデータが大量に保管された場所を想像するかもしれませんが、それは「ストレージ」の役割で、DBサーバはストレージに新たなデータを書き込んだり、必要な情報を引き出したり更新したりします。

データを操作する際は、APサーバのリクエストに従って「SQL」と呼ばれるデータベース言語を実行し、その結果をAPサーバに返します。先ほどのリンゴとバナナの例で言うと、DBサーバは値段だけでなく消費期限、生産地、重さなどの様々なデータを持っていますが、APサーバからリクエストされた値段のみのデータをSQLで抽出してAPサーバに返します。DBサーバには四則演算のアプリケーションは実装されていないため、「リンゴとバナナの合計金額」を求めることはできません。

インフラエンジニアが最も触れる機会が多いミドルウェアはDBサーバかもしれません。DBサーバは性能を求められることが多いため、物理サーバ自体も多くのCPUやメモリが搭載され、インフラエンジニアにもより効率良くデータを抽出するための「チューニング」という作業が求められます。

Web3層構造

ここまで3種のミドルウェアを実装したサーバについて解説してきましたが、なぜ大規模システムにおいてWeb3層構造が採用されるのか、その点を解説していきます。

Web3層構造が採用される理由にはいくつかありますが、その1つに「セキュリティの高さ」があります。DBサーバには多くの顧客情報が保存されており、万が一この情報が流出してしまうと大問題になります。Web、AP、DBがすべて1台にインストールされたシステムではクライアントから直接DBサーバにアクセスできてしまいますが、Web3層構造ではクライアントとDBサーバの間にWebサーバ、APサーバ、そしてセキュリティ製品を配置できるため、より堅牢になります。

また、「管理がしやすい」点も大きな理由です。本記事の前半で「システムは『止まらないこと』を大前提に作られる」と述べましたが、これは理想であり、もう少し現実的に表現すると「システムは『止まってもすぐに復旧できる』ことを前提に作られる」のです。サーバに不具合が発生した場合も、Web機能がおかしいのであればWebサーバ故障、アプリケーションエラーが出ているのならAPサーバ故障と、1台に機能が集約されている場合と比較して故障の影響が軽微になるというわけです。システム全体としても全停止ではなく一部機能の停止で済みます。また、例えばAPサーバの拡張が必要な場合にもAPサーバのみと柔軟に対応することが可能となります。

一方で、当然デメリットもあります。例えばミドルウェアを各サーバにインストールするには、それだけ物理サーバを購入するコストがかかります。また、最近”Struts2”のニュースが世間を騒がせましたが、アプリケーションやライブラリ自体に致命的なバグがあると階層を分けてもシステムを守ることはできません。

大規模システムは多くの人たちが利用するものです。多少お金がかかってもセキュリティの高さや管理のしやすさという点でWeb3層構造が採用されているのです。

おわりに

今回は、「ミドルウェア(Web、AP、DB)」について解説しました。ミドルウェアは分類も多く製品も各社から出ています。エンジニアに成り立ての頃はどこから手を付けたら良いのか分からないかもしれません。また、必ずしも自分が学んだ製品や過去に扱ったことがある製品を現場で使うとも限りません。しかし、どの製品も違いこそあれ役割は一緒です。「あぁ、前に使った○○と似た感じね」と気楽に考えると良いと思います。

また、Web3層構造は多くのシステムで用いられているため普段の生活でもよく目にします。例えばAmazonのようなECサイトがそうです。「今自分が見ているページは静的コンテンツなのか？ 動的コンテンツならAPサーバはどういった情報をDBサーバから受け取っているのか？」などを考えると面白いかもしれません。

次回は、「ミドルウェア(システム運用)」をテーマに解説します。こちらもみなさんが普段意識しないところかもしれませんが、システムを動かす上では欠かせません。次回も楽しみにしていてください！