業界動向――ユーティリティ・モデルの現状：ユーティリティ・モデル 第1部

[Open Enterprise Magazine]

コンピュータの低価格化とネットワーク化が進行した結果、業務の処理量に合わせて複数台のコンピュータを組み合わせて利用することがごく普通に行なわれるようになった。メインフレーム時代のシンプルなモデルは過去のものとなった。しかし、現在では増えすぎたサーバの台数が管理限界を超える、という問題が生じ、その複雑さが非効率と見なされ始めた。そこでユーティリティ・モデルが脚光を浴びることとなったが、基本的な概念は単純でも、実現手法は各社まちまちとなっている。

ITシステムの現状

　現在のIT環境では、ネットワークの利用が前提となっている。さらに、業務処理を複数のより小さい単位に分割し、要素ごとに異なるコンピュータで実行し、結果を繋ぎ合わせて1つの大きな業務処理とする、という手法が一般的

になってきている。こうした分散処理は、どのような形で処理を分割し、どう繋ぎ合わせるのか、という点でさまざまな考え方があり得るのだが、現在一般的になってきているのは、3階層モデル（3Tier Model）と呼ばれるアーキテクチャだ（図1参照）。

図1■図1：3階層システムの基本的な構造。クライアントから殺到する大量のリクエストを効率よくさばくため、各層でそれぞれ処理の一部を分担しながら処理を集約していく、というのが基本的な考え方だ

　3階層モデルでは、業務処理（アプリケーション）をプレゼンテーション、ロジック、データ・ストレージの3層に分割し、それぞれに対応するサーバを配置してネットワークで接続する。このモデルの背景には、インターネットの普及、そしてインターネット環境で成立した技術を社内の業務ネットワークで利用するというイントラネットの考え方がある。処理要求の受付窓口の役割を果たすため、大量のネットワーク・リクエストを効率よくさばくために通信帯域の確保が欠かせない。一方で、Webサーバ・ソフトウェアを実行してコンテンツの配信を行なうのが主な役割であることから、ネットワークとのデータの送受信が処理の中心であり、負荷の高い演算などはあまり行なわれない。また、HTTPの特性上、各リクエストは基本的にステートレスで行なわれる。つまり、あるユーザーの処理の途中経過をすべて把握している必要はなく、一回のリクエストに一回応答すればそれで終わり、というのが基本となる。1画面のWebページには多数の構成要素があり、HTMLファイルに加えて画像データなども多数含まれるが、基本的な処理はファイル単位で行なわれ、一回の処理はリクエストに応じて1つのファイルを送出すれば終わる。必要なファイルをすべてリクエストし、集まったファイル群から1画面のWebページを構成して表示するのはクライアント側のWebブラウザの仕事である。こうした特性から、Webサーバを実行するサーバマシンは、少数の高性能マシンよりも、比較的低性能な安価なマシンを多数並列に配置しておく方が全体の処理能力（この場合はネットワーク・スループット）を高めることが容易で、コスト面でも安価になる。

　対照的なのがデータ・ストレージ層のサーバで、データベースを運用し、データの一貫性を保つためにはデータベース・インスタンスは1つである方が好ましい。安全性／信頼性の面からクラスタ構成を採ることが多いが、それでも論理的には1台の巨大高性能サーバを配置することが一般的だ。

　この中間的な性格をもつのが、ロジック層のアプリケーション・サーバだ。アプリケーションでは処理の一貫性や順序正しい逐次実行などが求められるので、ステートレスなWebサーバの背後でアプリケーションの実行状態の保持

に責任を持つ。また、アプリケーション・ロジックが実行されることから、アプリケーションの処理内容によっては演算性能も相応に求められることになる。万一のサーバダウンでも実行中の処理が失われることがないよう、クラスタリングを行なうことも一般的だ。そこで、一般的にはミッドレンジサーバを数台〜数十台配置することになる。

　このように、3階層モデルは1つのアプリケーションを3階層に分割し、それぞれに異なる性格付けを行ない、異なるハードウェア上で実行するモデルである。3階層モデルはイントラネット・アーキテクチャとしては標準的なもので、現在稼働中のWebアプリケーションのほとんどがこのアーキテクチャに沿って作られているといってよいだろう。ここで問題は、3階層という把握しやすい数の階層に整理されたとはいえ、実際のサーバの構成はかなり複雑で、特にWebサーバ層ではサーバ台数が膨大になる点だ。

管理限界超過／利用効率低下

　サーバの台数が増えると、管理の手間は大幅に増えることになる。しかも、前述の通り、3階層モデルでは各層ご

とに性格の異なるサーバを配置している。コスト面での最適化を考えて、Web層では安価なエントリ・サーバを多数配置する。数が多いことから、1Uサーバや、最近ではブレード・サーバなどが活用される。ロジック層では、多数のWebサーバからのリクエストに応じてアプリケーションを実行するため、4CPU以上くらいの構成のミッドレンジ・サーバを使う例が多い。1Uのエントリ・サーバとは価格が桁違いなので、数的にはぐっと少なく、処理内容によっては2台ということも珍しくはない。一方、最終的にすべてのデータ・アクセスが集中することになるデータ・ストレージ層のサーバはハイエンド、もしくはミッドレンジのサーバで、処理の規模に応じて4〜8CPU、場合によっては16CPU以上の大規模なサーバを使用する。

　このとき、どのくらいの処理能力をもつサーバを用意するのが最良なのか、その判断は極めて困難なものになる。クライアントのリクエストを受け付けるWebサーバの処理能力は、クライアント数やそれぞれの処理の頻度、HTMLファイルのサイズや画面数に依存する。そして、Webサーバの数が決まったとして、その後段に位置するロジック層のアプリケーション・サーバはどのくらいの処理能力のサーバを何台用意すれば適切なのか。これを適切に予測することは実際にはかなり困難で、現場ではサンプル・アプリケーションまたは本番用アプリケーションをあらかじめ用意し、想定される業務負荷を実際に掛けてみてパフォーマンスを測定し、その結果に基づいて判断する、という手法が採られる。つまり、やってみなくてはわからない、というのが現実なのである。当然、データ・ストレージ層のRDBMSサーバも同様だ。

以降、記事の続きはPDFで読むことができます。

---

本特集は、ソキウス・ジャパン発刊の月刊誌「Open Enterprise Magazine」の掲載特集を一部抜粋で掲載したものです。次の画像リンク先のPDFで記事の続きを読むことができます。同特集は、2005年1月号に掲載されたものです。

サイズ　381Kバイト