連載 JavaServer Pages— それでも、いままでの一生ぶんよりもたくさんの流れ星 と言しました。 を見物できました。、、涅雨 " とまではいきませんでした このように、、 C 。 ntext " タクて指定されているファイ が、今年はやはり当たり年だったようです。 ルの集合が 1 つのアプリケーションとして扱わ appli- さて、前回までに 9 つの暗黙オプジェクトのうちの 4 cati 。Ⅱオプジェクトに割り当てられます。このあともア つを紹介しました。今回は残りの 5 つのうち例外処理に関 プリケーションという用語がたびたひ登場しますが、 する exception 暗黙オプジェクトを除く次の 4 つについ での、、アプリケーション " とは一ヨ勺なプログラムを指す て紹介していきます。 のではなく、 JSP サーバーカ理するファイル ( ページ ) の集合という未です。 application application 暗黙オプジェクトは、しつは初登場ではあ sess 10n りません。前回の記事で、 "config オプジェクトの get- page ServletContext() メソッドでサープレット・コンテキ pageContext ストを取得できる " ということを書きました。このサープ レット・コンテキスト (javax. servlet. ServIetContext) application 暗黙オフジェクト オプジェクトが application 暗黙オプジェクトそのもの です。 JSP サーバーは、特定のディレクトリの下の JSP ファ application オプジェクトでは、前回の記事で簡単に触 イルや HTML ファイルの集合をアプリケーションとい う単位で管理しています。 application 暗黙オプジェクト れた、 は、このアプリケーションを表現したオプジェクトです。 ・サーバーの 1 帯長の恥等 たとえは、 Tomcat に付いてくる JSP やサープレット サープレットのノヾージョンの耳昇 のサンプルファイルは、 JSP サーノヾーの、、 /examples" ・ファイルを置いてあるディレクトリのパスの取得 という URL の下に集めら 1 つのアプリケーションを ・ログメッセージの出力 構成しています。また、この連載では、、 /unimaga" とい う URL の下に JSP ファイルを集め、 Tomcat をインス などのほか、 トールしたディレクトリの下の、 ・サープレット・エンジンの属性清報の操作 webapps/unimaga アフリケーションに成疋されたパラメータの取得 に嬲里ファイルを置いています。これも 1 つのアプリケー ・指定した URI (URL) に対応したサープレット・コン シ - ョン -- 0 づ % テキストの取得 1 つの JSP サーバーは複数のアプリケーションをも つことができます。個々のアプリケーションは Tomcat といったことができます。 の成疋ファイル、、 conf/server. xml" を見れば区別できま 以下では、デバッグに役立っログの出力と、サープレッ す。 ト・エンジンの属性情報を操作するガ去を、プログラム例 /examples' アプリケーションは、 たとえば、 を示しながら説明します。 く Context path="/examples " docBase="examp1es" ログの出力 debug="O" reloadable="true"> 図 1 は、 application オプジェクトを使って、入力し た name パラメータの値をログファイルに出力する JSP ファイル log. jsp です。図 2 は、以下の URL を指定し て log. jsp を呼び出したときのプラウサの表示です。 http : //tomcat : 8080/unimaga/10g ・ j sp?name=Nek0 く /Context> と記述されています。また、 ョンは、 く Context path="/unimaga" docBase="unimaga' debug="O" reloadable="true"/> /unimaga アプリケー ン 86 UNIX MAGAZINE 2002.1

ていた。しかしトンネルをイ描する機能や欟冓は提供さ れていない。 そこで RFC3193 では、 L2TP において各種のセキュ リティを石呆するために IPsec を用いる手法を提案してい る。 L2TP セキュリティに関する要求事項をまとめ、 IP- sec を用いた L2TP セキュリティの相互接続性に関する ガイドラインの提示と、 L2TP をイ描する際の IPsec フィ ルタの言田についての言缶義をおこなっている。なお、 RFC 3193 ではエンドッーエンドの安生は別のセキュリティ 機構によって提供されると仮定しており、この問題につい ては論していない。 BEEP 関連 RFC3117 On the Design of AppIication ProtocoIs アプリケーション・プロトコルの言十 旧 fo. 、 M. Rose BXXP (Blocks eXtensible eXchange Protocol) を 利用してアプリケーション・プロトコルを構築する際の設 言 1 上の原則について論じている。、、広報 " として 2001 年 11 月に公開された。 BXXP はコネクション指向、非同期接続を対象とし たアプリケーション・プロトコル用の汎用的なフレーム ワークである。 BXXP のフレームワークは 1998 年に提 案され、 2000 年には IETF で BEEP 分科会が発足し た。、、 BXXP" が、、 BEEP" に変更されたのはこのころで ある。 BEEP のフレームワークは RFC3080 で論しられ ている。 RFC3117 では、 BEEP を用いたアプリケーション・ プロトコル構築の基本的な原則を以下の本咎はみに沿って論 している。 ・アプリケーション・プロトコル構築に関する背景 ・アプリケーション・プロトコル構築に関するさまざまな 問題の鮹夬ガ去 ・ BEEP を利用したアプリケーション・プロトコルのオ冓 ・ BEEP を利用したアプリケーション・プロトコルの属性 ・ BEEP のフレームワーク 電子メール関連 RFC3191 Minimal GSTN Mail 178 address format ln lnternet インターネット・メールにおける最′艸艮の GSTN アドレ ス形式 DF. 、 C. Allocchio ( RFC2303 置換 ) ( RFC2846 更新 ) GSTN (Global Switched TeIephone Network) ア ドレスをメールアドレスの一部として表現する手法を提案 している。現在の状態は、、標準化への草稿 (Draft Stan- dard)" である。 RFC2303 を置き換え、 RFC2846 を更 新する RFC として 2001 年 10 月に公開された。 これまで、 GSTN アドレス ( ー殳電話回線の電話番号 ) をメールアドレスの一部として表現することを目的とした 複数の独自実装か混在してきた。 RFC3191 では、 GSTN アドレスをメールアドレスの一部として表現するための 、最低限の表現方法 " を提案している。この表現方法は拡 張可能で、将来出現するであろう新しいデバイスなどにも 対応できるようになっている。 具体的には、、、サービス指定部分 " 、、電話番号部分 " 、、オプション部分 " から構成される。以下に、 RFC3191 で 提案されている表現ガ去の使用例を示す。 VO 工 CE = + 39402263389 orldvoice . com FAX= + 1 . 202.7653000 / T33S = 6377@faxserv. org / SMS = + 33 ー 1 ー 88335215/@telecom . com RFC3192 Minimal FAX address format in lnternet Mail インターネット・メールにおける最′艸艮の FAX アドレス DF. 、 C. Allocchio ( RFC2304 置換 ) ( RFC2846 更新 ) FAX 機器の GSTN アドレスをメールアドレスの一部 として表現する手法を提案している。現在の状態は、、標準 化への草稿 " である。 RFC2304 を置き換え、 RFC2846 を更新する RFC として 2001 年 10 月に公開された。 RFC3191 では、メールアドレスの一部として GSTN アドレスを表現する手法を提案している。 RFC3192 で は、具イ勺なサービスとして FAX を指定するための形式 とそのオプションを定義している。ここで定義されている FAX サービス指定用のキーワードは、、 FAX" 、オプショ ンは、、 T33S " である。 URN 関連 RFC3187 Using lnternational Standard Book Num- bers as Uniform ReSOLffCe Names UNIX MAGAZINE 2002.1

tion は同社の Java 開発ツール Borland JBuilder との統合が可能。 価格 ( 開発ライセンス / 運用ライセンス ) は、 Web Edition が無償 / 68 , 000 円 ( メデ ィアキットを含む ) 、 VisiBroker Edition が 200 , 000 円 / 600 , 000 円、 AppServer Edition が 200 , 000 円 / 150 万円、メディ アキット ( 出荷は 2002 年 1 月 ) が 70 , 000 •Trend Micro Li nux ファイルサーバー用ウイルス対策製品 トレンドマイクロは、ウイルス対策ソ フトウェア「 ServerProtect for Linux 」 の販売を開始した。 Linux ファイルサーバー用のウイルス 対策ソフトウェア。ファイルへのアクセ スを常時監視するリアルタイム検索が可 能。 web プラウサからの遠隔管理、定義 ファイル / 検索エンジンの自動更新、電子 ・ CaIdera ltanium サーバ—/WS 用 Linux カルデラ (Tel 03 ー 5486 ー 3905 ) は、 Li- nux ディストリピューション「 OpenLi- nux 64 R3.1 」 ( 英語版 ) の販売を開始し 0 lntel の 64bit プロセッサ ltanium に 対応する Linuxo カーネル 2.4.5 、 glibc 2.2.3 、 gcc 3.0 。 Apache や Samba など のサーバー・ソフトウェアのほか、各種 GUI 開発ツール、 kdevelop 、 QT De- signer を含む。インストール・オプショ ンとして、、サーバー〃や、、ワークステー ショゾなどの構成を選択可能。 ーメティアラボ CD-ROM ドライププートの Linux メディアラボ (Tel 03 ー 5294 ー 7255 ) は、 Linux ディストリビューション「 Live Linux 2 」の販売を開始した。 CD-ROM ドライプから直接起動し、 HD を使用せすに動作する ()D はスワッ プ領域の確保、環境設定、アプリケーショ ンの追加 / 更新などに使用可能 ) 。カーネ ル 2.2.19 (alsa—driver 、 ReiserFS 、圧縮 ext2 、圧縮 isofs) 、 glibc 2.2.3 、 XFree 86 4.1.0 、 pcmcia—cs 3.1.24 。サーノヾー として Apache 、 ProFTPD 、 Postfix 、 Samba 、 netatalk などを、日本語環境 •HOLON Windows 用の UNIX 互換環境 HOLON は、 Windows 用の UNIX 互 換環境「 X on Windows 」の販売を開始 Cygwin をもとにした UNlXJi 換環境 で、 InstallShield でインストール / 削除 できる。環境内でのアプリケーションの 追加 / 削除には RPM を使用。 Windows 上の 1 ウインドウとして X ウインドウ・ ■沖電気 「 DressUP Performance for J2EE 」の 沖電気工業 (Tel 03 ー 5445 ー 6818 ) は、 Web アプリケーション性能管理ツール版売を開始した。 UNIX MAGAZINE 2002.1 Web アフリケーション性能管理ツール NEWS 円。 Web Edition の開発ライセンスは 「 BorIand JBuiIder 6 Pr0fessional 」に 付属。 http://www.borland.co.jp/から のダウンロードも可能。 メール /SNMP による通知などの機能を もつ。 ARJ 、 LZEXE 、 LHA 、 TAR など の各種工縮ファイル形式をサポート。 対応ディストリピューションは Red Hat Linux 6.2 / 7.1 。 価格は 298 , 000 円 ( 1 サーバー ) 。 http://www.trendmicro. CO. jp/o 富士通の ltanium サーバー PRIMER 19 均処理時間などのデータとして管理する。 ションのサーバー側処理時間を測定し、平 ServIet 2.3 を使用した Web アプリケー 、、 DressUP Framework" に属する製品。 統合システム管理フレームワーク http://www.holonlinux.com/o 価格は 7 , 800 円。 Windows NT 4.0 (SP5 以上 ) / 2000 / XP 。 対応 OS は、 Windows 98SE/Me 、 システムを起動可能。 価格は 9 , 800 円。 ライプを備える PCO の空き容量が 0 ~ 200MB 、 CD—ROM ド 記憶が 64MB ( 推奨 128MB ) 以上、 HD 動作環境は、 CPU が Pentium 以 . E 、主 含む。 として Canna 、 kinput2 、 kterm などを のまま販売する。 数無制限、サポートなし ) 。当面は英語版 価格は 69 , 800 円 ( 1 システム、ユーサー 予定。 の ltanium 製品での動イ料証もおこなう GY N4000 での動作を確認済み。各社

図 1 イ勺な仮想マシンの冓成 アプリケーション ペレテ アプリケーション 、 VMM ( 仮想マシンモタ ) 。 物理マシン VMM は、標準的な OS とアプリケーションが実行される 仮想マシンを抽象化して提供する。各仮想マシンは、 ほかの仮想マシンから完全に独立している。 シンを支配する通常のシステムとは対照的である。 性能を最大に引き出すため、 VMM はできるだけでしゃ ばらすに引っ込み、財モードの場合も、佖想マシンが ードウェアに対して直接命令を実行できるようにする。 VMM は、仮想マシンがはかの仮想マシンやハードウェ アの正しい重川徂こ景グをおよは、しうる操作を実行しようと したときに制御を取り戻す。 VMM は、安全な方法で操 作をエミュレートしたのちに仮想マシンに制御を戻す。 うした直接実行の仕組みによって、メインフレームのイ反想 マシンはネイテイプに近い生能を替軍し、エミュレートさ れたマシンとのあいだに解釈実行用の層を常時必要とする マシン・エミュレータを技術面で凌いでいる。 マシンを完全にイ瓦想化すると、複数の仮想コンピュータ を作成して実際のコンピュータ上で動かすことが可能にな る。イ課マシンごとに、異なる OS や、同し OS の別の 実装を実行できる。仮想マシンで実行される OS を、ゲ スト・オペレーティングシステム ( 以下、ゲスト (S) と 呼ぶ。イ反想マシンは互いにうしているため、ゲスト OS がクラッシュしても、はかの仮想マシンには景グ繹をなえな い。異なる佖想マシンのユーサー同士が、互いに致命的な 景グを与・えることもない。 PC プラットホームでも、メインフレームの仮想マシン とほは 1 司様の効果カ碍られ、さらにいくつか異なる利点も ある。メインフレームの仮想マシンは、時分割システム、 異なる OS やアプリケーション間でのマシン資源の分割、 -¯OS やソフトウェアの開発、システムのスムーズな移行な UNIX MAGAZINE 2002 ユ I/O デバイスの仮 どの用途に使われている。デスクトップ PC やワークス テーション PC では、 Microsoft のものや UNIX べー スのものを中心に、さまざまな OS を実行する需要があ る。仮想マシンを利用すれば、これらの OS を 1 台のコ ンピュータで同時に実行することができる。 ・ -- - 殳企業や、アプリケーション・サーピスを提供するフ ロバイダが lntel べースの PC をサーバーとして使う事例 も増えている。障害箇所を分離したり性能を保証するため に、サービスやアプリケーション、顧客といった単位で 1 つのマシン全体を割り当てることも多い。これらの用途で アプリケーションのホストにイマシンを使用すれば、資 源の利用効率が上がり、システムの管理もしやすくなる。 また、マシン間での移行や複製も容易になるので、サービ スをイ合する面でも助かるだろう。仮想マシンは、ホスト マシンのハードウェアが異なっても、まったく同凵反想 ハードウェアにすることができるため、さまざまな物理マ シンに自由に移行させられる。 PC プラットホームをイ瓦想化するためには、克服しなけ れはならない技勺、実際的な間題がいくつかある。従来 のメインフレーム方式では、仮想マシンを低し罸モード で実行して、 VMM かオ讚モードの命令を自由に奪えるよ うにし、 I / O テンヾイスの仮想化と直接のインターフェイス は VMM に缶迂ている。また、 VMM はマシン全体を完 全に制御する。以下の理由により、この手法を PC に対し て適用するのは容易ではない。 仮想化できないプロセッサ : lntel の IA-32 プロセッ サ・アーキテクチャ [ 10 ] は、本質的に仮想化できない。 popek と Goldberg によると、イ反想マシンをサポート できるアーキテクチャは、キ讚在モードのマシンの状態を 調べたり変更できるすべての命令が、もっとも高し寸讚 モードを除くいかなる場合に実行されてもトラップされ るものだけである [ 11 ] 。 IA-32 プロセッサはこの条件 を満たさないため、佖想マシンのすべての命令を低い特 権モードで実行するだけでは想化できない。 PC ハードウェアの多オ剃生 : PC には多種多様なデバイ スが使われている。これは、 pc が、、オープンな " ア ーキテクチャであることに起因する。従来の実装では VMM がこれらのデバイスを管理しなけれはならない 1 .1 PC プラットホームの仮想化 159

図 2 ホスト協仮想マシン・アーキテクチャ が、サポートされるすべての PC デバイス用のデバイ スドライバを VMM に提供するには、膨大な量のプロ VMM 領域 グラミングが必要になる。 既存の PC ソフトウェア : 経験豊富なシステム管理者が アプリケーション 構成、管理するメインフレームとは異なり、デスクトッ プ PC やワークステーションの多くには標準の OS が プレインストールされており、セットアッフや管理はェ 仮想マシン アプリケーション VMApp ンドユーザーがおこなう。このような工竟では、既存の OS やアプリケーションの使用に章をきたさすに、仮 MDrive„ : MM ( 仮想ヌぐンモ ; ター 、スト OS 想マシン技術を導入できることがきわめて重要である。 物理マシン 既存の OS を VMM と完全に置き換えようとしても受 け入れられないだろう。 VMw 眠のホスト協調型仮想マシンモデルでは、仮想化ソフ トウェアは、 CPU を仮想化する仮想マシンモニター、ホス ト OS を用いてデバイスをサポートするアプリケーション、 VMware Workstation は、既存のホスト・オペレー 両者のあいだをとりもつ OS ドライバに分けられる。 ティングシステム ( 以下、ホスト (S) との共存を可能に し、デバイスのサホートを OS に委ねることができるホス ト協調型アーキテクチャを備えている。図 2 に、ホスト 協調型アーキテクチャの橢友要素を示す。このアーキテク VMware Workstation は、ホスト協え起仮想マシン・ チャでは、 VMware はさまざまな pc ハードウェアに対 アーキテクチャというまったく新しい言を使って 1/0 応し、既存の PC ソフトウェアとの互換性をもつ。論文 デバイスを佖想化する。この言手法のおもな特徴は、既 執点では、ホスト OS となれるのは Windows NT 、 存の OS を用いて I/O デバイスをサポートし、 CPU を Windows 2000 、 Linux である。以下では、ホスト OS 大量に消費する処理ではネイテイプに近い生能か得られる を通して I/O デバイスにアクセスする場合の性能に焦点 点にある。図 2 はホスト協調型アーキテクチャにおける仮 を絞って説明する。 想マシンの構造である。 次節以降の構成は次のとおりである。 2 節では、 VNI- VMware Workstation は、 OS ( ホスト (S) の通常 ware Workstation のホスト協調型アーキテクチャとそ のアプリケーションと同様にインストールされる。起動 の利点およびコストについて説明し、仮想 Ethernet NIC すると、 VMware Workstation のアプリケーション部 (Network lnterface Card) の例を紹介する。 3 節では 分 (VMApp) は、ホスト OS にロードされたドライ VMware Workstation 2.0 による NIC の仮想イヒの匪育 バ (VMDriver) を使って、ハードウェア上で直接実 を匐ヾ、いくつかのワークロードに分けてオーバーヘット 行される特権的な仮想マシンモニター・コンポーネント を分析し、そのデータが夋する直イ法によって達成 (VMM) を確立する。それ以降は、特定の物理プロセッ された性能の改善状況を測定する。 4 節では、 3 節て解説 サがホスト領域または VMM 領域のいずれかを実行し、 した最適イユ外に、 I/O 性能を怖 1 上させるための手法をい VMDriver が 2 つの領域のあいだで制御の受渡しをおこ くつか紹介する。一の手法は、ホスト協調型アーキテク なう。 VMM 領域とホスト領域の切替えは、 CPU 上の チャの範疇を超えるものである。 5 節では、 1 台のマシン ユーサーとシステムのすべての状態を保存 / 復元する必要 でマルチプラットホーム・コンヒューティングをサポー があるため、通常のプロセスの切替えよりも負荷か高い。 トする分野での研究列を紹介する。 6 節では、ホスト協 このアーキテクチャでは、 VMM が CPU のイ反想化を 調型アーキテクチャの特徴をまとめ、その I/O の佖想化 処理する。純粋に言算処理だけをおこなうゲスト・アプリ に対する耳絲はみに関して、いくつかの結論を述べる。 ケーションやゲスト OS は、従来のメインフレーム型の イ反想マシンシステムと同じように重乍する。ゲスト・アフ ホスト領域 160 UNIX MAGAZINE 2002.1

特集ネットワークの基礎知識 0 log tm P log tmp 図 1 ローカルなファイルシステムの輊成例 / ( ルート ) home hayao 」 oe usr bin lib local bin lib db 図 2 NFS マウント列 三 hayao joe.: home NFS マウント home ファイルサ / ( ルート ) usr bin lib var var クライアント / ( ルート ) usr : bin lib 三 lib local var db 一方、 NFS を利用すると、あらかじめ指定した NFS サーバー上のディレクトリを、あたかもローカルなパーテ ィションであるかのようにマウント (NFS マウント ) する ことができます。たとえば、ファイルサーバーの /home と /usr/local を NFS クライアントにマウントすると、 図 2 のようになります。 アプリケーション側からみると、 NFS マウントしたデ ィレクトリやファイルに対する読み書きなどは、ローカル なハードディスク上のディレクトリやファイルに封する 操作と同様に扱うことができます。 NFS クライアントで は、ファイルがローカルなファイルシステム上にあるの か、それとも NFS マウントされたディレクトリにあるの かがカーネルによって識別さ後者の場合は操作のリク 工ストが NFS サーバーに送られます。 このとき、異なるアプリケーションや NFS クライア ントが、 NFS サーバー上の同じファイルに対して同時に 38 書込みをおこなわないように、 NFS とは別のプロトコル でファイルのロック冓を提供しています。これにより、 ある NFS クライアントのアプリケーションがファイルを UNIX MAGAZINE 2002.1 いてそれはど彳釜質にならなくてもいいでしよう。 したがって、一イ殳的な利用では、ファイルのロックにつ に 1 つのファイルに書き込むことはめったにありません。 込んだり、ユーサーか複数の NFS クライアントから同時 のユーサ、一のホーム・ディレクトリにあるファイルに書き ルの書込みが頻繁におこなわれますが、あるユーサーが別 どないはすです。また、ホーム・ディレクトリではファイ が NFS サーバー上のファイルを書き換える必要はほとん などに置かれたプログラムについて、 NFS クライアント ただし、ファイル共有の目的を考えると、 /usr/local という奇妙な状態になっています。 するのに、 FreeBSD の NFS クライアントでは動かない の NFS クライアントとのあいだではロックが正しく機能 す。このため、 FreeBSD の NFS サー ーとはかの OS 構カ躾装されていますが、 NFS クライアントは未対応で とえば、 FreeBSD では NFS サーバー側にはこれらの機 と組み合わせるとうまく働かない場合もあるようです。た 対応がまちまちで、実装されていなかったり、異なる OS もっとも、ファイルのロックや監視オ冓は OS ごとに るといえます。 に動くだけでなく、さまざまな OS への実装も容易になってい NFS はステートレスでシンプルに言 t されたため、上は交的高速 シュしたときの再刑処理も複雑になります。 ための情報を処理する手間がかかるだけでなく、一方がクラッ グ欟冓を含む、より高機能なサービスを提供できますが、その ステートレスの反対は、ステートフル (stateful)" です。ロッ たかのように処理を再開します。 サーバーか復帰すると、 NFS クライアントはなにごともなかっ シュすると NFS クライアントの処理も停止しますが、 NFS まったくもっていません。たとえば、 NFS サーバーがクラッ あり、 NFS クライアントとの接続状態をイ寺するための情報は NFS 自体は、ステートレス (stateless)" なプロトコルで クライアントの状態を監視する機溝も提供されています。 情報がそのまま残るのを防ぐため、 NFS サーバーや NFS NFS クライアントがクラッシュした場合、一方のロック できなくなります。さらに、ロック中に NFS サーバーや ントは、ロックが解除されるまでそのファイルにアクセス ロックすると、はかのアプリケーションや NFS クライア

NEWS Delphi で使用されている、、 Snap" アー キテクチャを採用し、 DB/Web アプリ ケーションの開発 (Open Edition を除 く ) 、 Web サービスや多層分散アプリケー ションの構築 (Enterprise のみ ) が可能。 富士通 (Tel 03 ー 3548 ー 3795 ) は、システ ム運用管理ソフトウェア製品群、、 System Walker V10 クの販売を開始した。 PSM (Policy—based Systems Man- agement) にもとづく統合運用管理ソフ トウェア。おもな機能は、 SLA (Ser- vice Level Agreement) の監視、各種 SystemWaIker V 1 0 Enterprise は COR BA や EJ B との相互 運用に対応。 動作環境は、 Linux カーネル 2.2 以 - ヒ、 glibc 2.1.2 ( 推奨 2.1.3 ) 以上、 libjpeg 6.2 DB (SymfoWARE Server 、 Oracle 、 SQL Server など ) の SAN (Storage Area Network) 環境での高速バックアッ プ、 XML などで記述された電子帳票の統 合管理、シングル・サインオンや GPKI (Government Public Key lnfrastruc- ture) などの各種セキュリティ。 ■富士通 ■ Sy ba se Adaptive Server Enterprise 12.5 サイベース (Tel 03 ー 5210 ー 6255 ) は、 RDBMS 「 Sybase Adaptive Server En- terprise 12.5 」日本語版の販売を開始 、 -0 おもな新機能は以下のとおり。 1 ) XML/XQL をサポート 2 ) DB 工ンジン内への EJB (Enterprise JavaBeans) コンポーネントの格納と実 行によりアクセスを高速化 3 ) 非リレーショナルな外部コンテンツの 管理が可能 4 ) 動的なパフォーマンス・チューニング •BEA 業務アプリケーション統合環境 日本 BEA システムズ (TeI 03 ー 5545 ー 8440 ) は、システム統合環境「 BEA Web Logic lntegration 2.1 」を販売する。 ERP や CRM などの個別のアプリケー ションやメインフレーム・システムを連携 し、ワークフローにもとづく統合的な運用 が可能。企業間取引の統合にも対応する。 Java アプリケーション・サーバ—BEA WebLogic Server がべースで、 J2EE や JCA (J2EE Connector Architecture) に準拠。統合化設計環境とアプリケーシ ョン・アダブタ開発キットを備え、 GUI 対応のビジネスプロセス管理、 B2B ( 企業 間取引 ) 統合、システム間で利用するデー ・ BorIand Java アプリケーション・サーバー ポーランド (Tel 03 ー 5350 ー 9358 ) は、ア プリケーション・サーバー、、 BorlandEn- terprise Server" の販売を開始した。 既存の Borland AppServer 、同 Visi 18 Broker の後継製品。 Web アプリケーシ ョン運用環境「 Web Edition 」、 CORBA による分散アプリケーション開発・運用環 境「 Visi Broker Edition 」、 J 2EE (Java 価格は、 Kylix 2 Professional が 68 , 000 円、同 Enterprise が 240 , 000 円。同 Open Edition は http://www.borland. co. jp/kylix/openedition/ から無償でダ ウンロードできる。 価格は、「 SystemWalker / Centric MGR 」 ( 統合運用管理 ) が 840 , 000 円か ら、「同 OperationMGR 」 ( 自動運用 ) が 400 , 000 円から、「同 WebMGR 」 (Web 管 理 ) が 700 , 000 円から、「同 ListWORKS 」 ( 電子帳票システム ) が 580 , 000 円から、 「同 StorageMGR 」 ( 高速バックアップ ) が 180 万円から。 が可能 5 ) Unicode 3.0 をサポート 6 ) 行レベルのアクセス制御と SSL による 暗号イし凾信に対応 価格は、 UNIX 版が 217 万 4 , 000 円 ( 同 時ューサー数 5 ) から、 Linux 版と Win- dows NT 版がいすれも 149 , 000 円 ( 同時 ューサー数 1 ) から。 タの XML 化、 Web サーヒ、スへの対応な どの機能をもつ。 対応 OS は、 Solaris 7 / 8 、 HP—UX 11.0 、 AIX 4.3.3 、 Windows NT 4.0 (SP 6 ) / 2000 Professiona10 対応 DB は、 Or- acle 、 SQL Server 、 Sybase など ( 動作 OS により異なる ) 。 価格は 1 , 100 万円 ( ICPU あたり ) から。 出荷は 2002 年 1 月。 2 Enterprise Edition) 1.3 と EJB 2.0 UNIX MAGAZINE 2002.1 ニングク技術を使用。 AppServer Edi- サーバーの稼動が可能な、、パーティショ 複数パーティションの作成と複数の仮想 Borland Web Server 、 1 サーバー内での 1.3 と Tomcat4.0 べースの Web サーバー 「 AppServer Edition 」がある。 Apache に対応したアプリケーション・サー

連載 /JavaServer Pages— 図 1 ログメッセージを出力する log ・ jsp ファイル く % page contentType="text/htm1 ; charset=EUC-JP" % > く ! DOCTYPE HTML PUBLIC "—//W3C//DTD HTML 4.0 Transitiona1//EN"> く html> く head> く meta http—equiv="Content—Type" content="text/html ; charset=EUC—JP"> く title>log output く /title> く / 五 e ad> く body> namezs0 ラメータの値はく % = request . getParameter("name") % > です。く br> ログファイルにも書き込みます。 く % application. log("name/€ラメータの値 : 年を、 ログファイルにも書き込みます。 na パラメータの値は Neköです。 、カイの編第表示強索ジャンプゆフめマゆ⑧タスクヘルプ 図 2 10g. jsp の実行醯 く /html > く /body> 十 request. getParameter("name")) ; 成されるログファイルは、実彳の日付を prefix と suffix prefix と suffx でログファイル名を指定します。作 書いてください。 Name はログの出力を担当するクラス名で、図のように http://tomcat:8080/unimaga/log ・ jsp?name=Neko 書き出されたログの内容も確かめておきましよう。 10g ( ) メソッドで指定したメッセージは、デフォルトで は、、 logs/localhost 」 og. 日付 . txt" ファイルに出力されま す。たとえば、 2001 年 11 月 11 日に上記の 10g ・ jsp を 実行した場合、、 localhost 」 og. 2001 ー 11 ー 11. txt" に次の ような 1 行か書き込まれているはずです。 2001 ー 11 ー 11 23 : 22 : 27 name パラメータの値 : Neko なお、デフォルトでは行の地頁にログを出力した日付と 日該リか書き込まれます。 logs/localhost 」 og. 日付 . txt" には、同し JSP サーノヾ ーー E で動作しているほかのアプリケーションのログ出力が 書き込まれることもあります。開発中のアプリケーション にこでは unimaga) のログをほかのログと混在させたく conf/server. xml" に図 3 のように言当 ない場合には、 してください。 アプリケーションを定義している Context タグのなか ー一一一一にい図 3 のように Logger タグを挿入します。 class- UNIX MAGAZINE 2002.1 て指定した文字列で挟んだ、 2 ル日付か田 という名前になります。図 3 の例では、 11 日に作成したログファイルの名前は SSlocalhost-uni- maga -2001-11-11.10g " です。 2001 年 11 月 timestamp="false" と書き込まれます。また、図 3 の例のように、 2001 ー 11 ー 11 23 : 22 : 27 name パラメータの値 : Neko と記主すれば、さきほどのように日日判寸きで、 timestamp="true" 時を挿入するかどうかの指示です。 timestamp は、ログファイルの各行のう巨頁に出力日 と言すれば、 Ⅱ ame / くラメータの値 と書き込まれます。 属性の操作 Neko application オプジェクトのメソッドを使えば、 87

e WS ・ 1 / 2002 EHP PA—8700 使用の superdome 日本ヒューレット・パッカード (Tel モジュールの交換により PA ー 8700 にア 0120 ー 081565 ) は、 CPU に PA ー 8700 を使 ップグレードできる。異なるパーティシ 用したハイエンド・サーバー 「 hp super- ョンでの PA ー 8600 と PA ー 8700 の混在が dome 」の販売を開始した。 可能。 CPU は最大で PA ー 8700 (750MHz) x 価格は 6 , 985 万 8 , 000 円 ( PA ー 8700 ( 750 「 HITACHI 9000V superdome 」として、 64 。 64CPU 時のトランザクション処理 MHz) x 4 、主記憶 2GB 、 PCI スロット x 日本電気 (Tel 03 ー 3798 ー 5143 ) は「 NX 性能は、 Oracle9i との組合せで 389 , 434 12 、 hp—ux 11i ライセンス ) から。 7000/superdome 」として同等製品を販 tpmC0 既存の PA ー 8600 使用マシンは、 日立製作所 (TeI 03 ー 5471 ー 2553 ) は 売する。 'BorIand 4.0 、 iPlanet 6.0 など。 価格は、「 JBuilder 6 Professional 」 が 68 , 000 円、「同 Enterprise 」が 360 , 000 円。「同 Personal 」は http://www. ポーランド (Tel 03 ー 5350 ー 938 のは、 スコードの修正が可能なリファクタリン borland. co. jp/jbuilder/ から無償でダウ Java 開発ツール、 \Borland JBuilder 6 ク グ機構、プログラムのテストを自動化す ンロードできる。チームによる開発用に 日本語版の販売を開始した。 るユニットテスト機構など。 Enterprise 十コーポレート追加ライセン EJB 2.0 準拠の J2EE/CORBA アプ 対応 OS は、 SoIaris 7 / 8 (SPARC 版 ) 、 ス ><2 の「同 Enterprise 製品ノヾック 3 」 リケーションや Servlet 2.3 、 JSP 1.2 準 Red Hat Linux 6.2 / 7.1 、 Windows NT ( 2001 年 12 月 21 日までのキャンペーン価 拠の Web アプリケーションなどの構築が 4.0 ( SP6 ) / 2000 (SP2)/XP0 対応アプリ 格は 736 , 000 円 ) 、 Enterprise 製品パック 可能なビジュアル開発ツール。 J2EE 1.3 ケーション・サーバーは、 Borland Enter- 3 に年間バージョンアップ・サーピスを付 に対応。おもな新機能は、 UML による prise Server 、同 AppServer 4.5 、 BEA 加した「同サプスクリプションパック 3 」 Java コードの視覚的表示、効率的なソー WebLogic 5.1 / 6. x 、 WebSphere 3.5 / ( 同 117 万円 ) も用意。 インターフェイス UDII. 0.1 のサポート、 カーネルダンプ解析ツール kcrash のサ ポート、ファイルシステム・タイプの自動 カルデラ (Tel 03 ー 5486 ー 3906 ) は、 lntel モリ、 ITB のファイルシステム、 76 , 800 認識、通常ファイルを特殊デバイスとして アーキテクチャ用の UNIX OS 「 Caldera TB のストレージをサポートする。 Unix 扱える Marry コマンド、 FAT32/VFAT Open UNIX 8 R8. OJ 」の販売を開始し Ware 7 以降に新たに追加された機能は、 のサポートなど。 LKP (Linux Kernel Personality) 1.0 価格は、メディアキットが 9 , 500 円 ( 60 ーー 0 旧 SCO の SCO UnixWare をもとに ( Linux 用アプリケーションが動作する ) 、 日間の評価ライセンス付き ) 、ライセンス した製品。最大で、 32CPU 、 64GB のメ Java 1.3 、 UNIX/Linux 汎用ドライノヾ・ が 90 , 000 円から。 GNU GPL (General PubIic License) に準拠したアプリケーション開発用の 「 BorIand Kylix 2 Open Edition 」、商 用・業務アプリケーションの開発も可能な land Kylix 2 〃日本語版の販売を開始 「同 Pro fessi ona 1 」「同 Enterprise 」があ る。新たに同社のピジュアル開発ツール JBuiIder6 日本語版 naldera 日本語 Open UNIX8 •BorIand K ⅵ ix2 日本語版 ボラーン卞イ Tel 03 ー 5350 ー 9380 ) は、 ー = 一一一亡ー - ・、一用のど - ジュアル開発環境、、 Bor- 17 UNIX MAGAZINE 2002.1

連載 /UNIX Communication Notes—O って、トランスポート層とアプリケーション層でのプロト コルに起因する遅延は、プロトコルそのものを変えないか ぎり去宿できない。ただし、・カーネル内に実装されたプロ トコル処理自体は、サーバーやクライアントの匪能に左右 される。 プロトコルの構造に起因する遅延の典型は、 TCP のウ インドウフロー制御によって発生するものだろう。 TCP のパラメータ設定によって去噌できる可能性はあるが、根 本的に解決するには、 TCP においてウインドウフロー 制御の代わりにより性能の高い制御方式を導入するしかな い。たとえは、 TCP Vegas[I] と呼はれる制御方式は、レ ート制御 (rate control) の概念を採り入れ、広帯域ネッ トワークにおける TCP の能を改善しようという試みで ある。この分野の研究は現在も活発に進められており、と くに、山も匠のネットワークの広或化に対応するさまざま な方式が考案されている。 アプリケーション層での遅延を矢可宿するには、アプリ ケーションごとに対応するしかない。 HTTP であれは、 HTTP 1.1 てラ尊入された persistent connection や、デ ータ転却芋の gzip 日引彡式の選択などが代表的な手法で ある。これらの改善手法は、アプリケーション・プロトコ ルごとに検言寸されている。 一方、プロトコル処理そのものの遅延は、カーネルにお けるプロトコルの実装やシステムの性能に左右される。た とえは、 80486 DX2 66MHz を用いた PC UNIX サー ーは、現在のシステムと上交して明らかにプロトコル処 理か遅くなる。このような場合は、高速な CPU を使っ て処理速度を高めれは、カーネル内でのプロトコル処理に ともなう遅延をまできる。しかし、山も匠のシステムでは CPU がポトルネックになっていることは少ないので、シ ステムの単純なアップグレードによって性能か劇的に改善 されるわけではない。これは、サーバーでの処理によって ける遅延にも当てはまる。 サーパーて、の里による過匡 サーバーでの処理による遅延をいかに矢聾宿するかは、サ ーバーの友を考えるうえでもっとも重要な譏題である。 サーバーにおける処理の性能改善を考えるうえで重要な のは、何がポトルネックとなっているかを把握すること を一一 ~ これさえ分かれば、その要素を高性能なものに交 UNIX MAGAZINE 2002.1 換することでシステム性能の改善か図れる。 1 つのポトル ネックを改善しても、今度は別の要素がポトルネックにな ることもある。このようなときは、ポトルネックを毆亦し ながら性能を改善する作業が必要になる。単一のサーバー では、次のような要素がポトルネックになりうる。 最初に考えなけれはならないのは、ハードディスクと ファイルシステムである。とくにハードディスクは要注意 である。ハードディスクの性能は、ハードディスク自体 とその上に実装されるファイルシステムの 2 つに分けて 考える必要がある。前者については、たとえはディスク回 転数の遅いドライプはディスクアクセスか遅く、性能力咄 ない。とくに、ディスク I/O カ噸発する処理ではその傾 向か顕著になる。実際、ラップトップ PC の内蔵ディス クは、デスクトップ PC のそれと上交して回転数が遅い のか通である。これを回転数の高いものに交換するだけ で、性能か劇的に改善される場合がある。サーバーのよう な大規模なシステムであれば、前回説明した RAID 技術 の導入により、アクセス性能の改善を図る場合が多い。 一方、ファイルシステムについては、その構造によって 処理のオーバーヘッドが変わるので、それぞれに性能が大 きく異なる。たとえは、同し BSD FFS (Fast File Sys- tem) であっても、カーネル内の実装は OS ごとにかなり 違う。そのため、 FreeBSD と NetBSD を上交した場合、 前者の他のほうか圧倒的に性能がよい。また、異なるファ イルシステムである FreeBSD の ffs と Linux の ext2fs では、一殳に後者のほうか高速である。このように、ファ イルシステムの実装の違いによって性能が大きく変わるこ ともある。このため、高性能サーバーを設計する場合は、 とくにアプリケーションの特生や、使用する OS 上て利 用可能なファイルシステムの機能を勘案し、どれを使うか を寸分に考える必喫がある。さらに、ファイルシステムに は性能を左右するパラメータがあり、たいていはカーネル のコンパイル時のオプションでチューニングできる。この 点についても、十分に検討すべきであろう。 処珊生能を決める大きな要因の 1 つに CPU がある。最 近の CPU はかなり高性能なうえに、続々と高速な CPU が発表されている。このため、数 - I ・年前のシステムならと もかく、山も丘は CPU がポトルネックになることはあまり ない。事実、クロックの高い CPU に交換しても、まっ たく性能が改善されない場合も少なくない。ただし、スト 57