Windowsベースの基幹システム構築が加速化
Itanium® Solutions Allianceが
Windows開発者向けセミナー開催で後押し

3月7日、目黒雅叙園で開催された

　インテルのItanium®プロセッサ搭載プラットフォームに基づくソリューションを推進する世界的な団体であるItanium® Solutions Allianceは2006年3月7日、目黒雅叙園でDeveloper Days Japanを開催した。Developer Daysは、Itanium®の能力を最大限に活用したアプリケーションを開発してもらうためのソフトウェア開発者を対象としたセミナー。世界中で開催されているが、日本ではLinux開発者を対象とした2005年12月のセミナーに続き、第2回目の開催となった。

　今回はWindows開発者に加えて、システム・インテグレータ、エンドユーザーも対象の内容となっている。インテル日本法人の代表取締役共同社長、吉田和正氏の挨拶に続いて6つのセッションが展開された。以下では、この第2回Developer Daysを緊急リポートする。

　インテルの吉田和正氏は「Itanium®プロセッサファミリは今後10年、20年という長期的な視点に基づいて、メインフレームを超える演算能力と信頼性を実現する新しいアーキテクチャとして開発された。ハードウェア・メーカーの努力や技術の蓄積に、ここにいる開発者の皆さんのソリューションを組み合わせてこそ意味を持つと考えている。今後とも支援をお願いしたい」と話した。

インテルの吉田共同社長

　また、Itanium®プロセッサファミリのロードマップについて、「このプロセッサはムーアの法則からはずれたものではない。現在4世代先まで開発が進行中である。今年中頃にリリースを予定しているMontecitoは、Itanium®プロセッサファミリの中で初めてデュアルコアとなる。パフォーマンスの向上に加え、仮想化を支援し、信頼性を高める機能を搭載することで、さらなる革新を実現していく。今後もインテルのみならず、このアライアンスに参加している皆さんと、Itanium®ソリューションの展開に全力を尽くしていきたい」と続けた。

　以下では当日行われた6つのセッションの概要をリポートする。

　 このアライアンスは、国内外の主なサーバ・メーカーが集まり、Itanium®をお客様に活用してもらうことを目的に活動している。Itanium® Solutions Allianceのメンバーは発足当時23社だったが、現在40社に拡大した。ウイングアークをはじめ、日本の独立系ソフトウェアベンダの参加も広がってきている。ハードウェアは各社から出揃っているが、一番大事なのはサービスとソリューションだという認識を持っている。

NECの泓（ふち）宏優氏

　 Itanium®上で動作するソフトウェアは6000本に達した。しかし、このプロセッサが企業の基幹を担っていくには、さらに多くのツールが必要になる。現在、世界のItanium®の約30％が日本で販売されており、日本は世界のItanium®市場を牽引しているといえる。日本のソフトウェア開発者の皆さんには、ソフトウェア開発でも日本が世界をリードできるよう、協力をお願いしたい。

　 Itanium® Solutions Allianceでは、Itanium®に対応したソフトウェアの開発について学べるセミナーの「Developer Days」、開発したソフトウェアの検証が行える「Solutions Center Network」、開発を終えたプロダクトを紹介するWeb情報データベースの「Solutions Catalog」と、3段階のソフトウェア開発者向け支援プログラムを展開している。

　 Solutions Center Networkは世界で20カ所設置されている。インターネット経由での利用であり、サポートは英語ということもあり、日本人には使いにくいので、実機を使えるセンターを日本では立ち上げる。インテル、NEC、富士通、日立の施設を用いて検証できるよう準備中だ。

　Solutions Catalogは2006年1月末現在で約2000件のItanium®対応ソフトウェアが登録されていて、そのうち約700件が日本の製品となっている。ぜひ活用して自分の作った製品を世界に宣伝していただきたい。

　日本地域委員会では、国内ISVに向けたサポートを積極的に展開し、2007年までに金額ベースで日本のRISCサーバ売り上げ比、5割獲得を目指し、活動を展開していく。

　現在業務システムにおいて、過去になかった大きなうねりが発生している。それは基幹系システムをどうするかという問題だ。企業はこれまで情報システムのコスト削減に努めてきた。その努力は、主にオフショアリングなどを通じた人間系のコスト減らしに向けられてきたが、それも限界に達した。もう1度テクノロジーに回帰し、システムコストの「最適化」を考えるべきである。

ガートナーの亦賀氏

　x86と異なり、基幹系に焦点を当てたプロセッサであるItanium®の登場で、新たな可能性が生まれている。特に日本では、2005年上半期における10万ドル以上のサーバ市場で、IA64のシェアがRISCにあと4％程度まで迫ってきた。国産ベンダは、メインフレーム事業の次の施策の軸としてItanium®サーバを位置づけ、戦略の立て直しを図りつつある。

　メインフレーム上のシステムは、これまでのレガシーかオープンかという議論で埒外とされてきたケースが多い。しかし、国産ベンダによるメインフレーム事業戦略のシフト、運用や保守のコスト高、2007年問題などによってユーザーは耐え切れなくなってきている。一方、オープン・サーバでもテクノロジーの複雑化や多様化、バッチ処理の問題などが依然として残されている。特に日本は信頼性に対する要求度が高い側面もある。

　こうしたことから、従来のメインフレームでもオープン・サーバでもない、双方の利点を兼ね備えた基幹系システムの新たな受け皿が必要だ。新基幹系システムの信頼性の目標は99.9999％。サーバシステムからOS、アプリケーション、インダストリ・ナレッジまで、垂直統合が求められる。

　ベンダ各社からは、新基幹系システムに向けた製品がすでに登場している。富士通のPRIMEQUEST、日立のBladeSymphony、NECのシグマグリッドなどだ。これらはItanium®を活用し、ハードウェアの信頼性に重点を置いている。

　サーバ仮想化技術を用いたサーバ統合が進められつつあるが、今後はブレードサーバによるスケールアウトの仮想化から、SMPサーバによるスケールアップの仮想化にシフトすることで、ばらばらなシステムでなく、単一のシステムとして管理できることが求められてくる。Itanium®はこうしたサーバ統合の受け皿になれる可能性がある。

　従来の基幹系システムは、メインフレームを中核とし、オープンを周辺に配置してきた。しかし今後は中核もオープンになっていく必要がある。それは、全体のアーキテクチャを考えていかなければならないことを意味する。

　こうした進化はそれぞれのベンダのレベルの話ではなく、業界全体として取り組まなければならないテーマだ。Itanium® Solutions Allianceのような取り組みは、こうした進化を加速するきっかけとなる。

　Windows Server 2003で、Windows OSの信頼性は飛躍的に向上した。しかし、万が一止まったときに、障害の原因をすばやく究明して復旧させるための仕組みがメインフレームと比較すると弱い。そこでパートナーと協業し、サポートツールプロジェクトとして、各種のデバッギングツールや解析ツールを開発してきた。このプロジェクトの成果物は、ツールのEnterprise Editionとして、参加社が自由にカスタマイズしたり再配布したりできるライセンスを提供している。

マイクロソフトの柿本氏

　 このプロジェクトは1998年のWindows NT 4.0リリース直後に開始され、毎年新規のテーマで共同開発を行っている。今年の共同開発の成果物の一部は「Support Professionals Toolkit for Windows V8 Public Edition」として、2006年1月11日に一般向けの無償ダウンロード提供を開始した。今後もより多くのツールを64ビット対応で提供していく予定だ。

　今回は、公開中の「User Mode Process Dumper」（Userdump）と、未公開の「Kernel Memory Space Analyzer」（Kanalyze）の2つのツールを紹介する。

　特にUserdumpは広く使ってもらいたいツール。実行中の任意のWin32プロセスのスナップショットダンプを、このツールを実行するだけで生成できる。「コンソールモード」と「Full-featuredモード」があり、いずれも32ビットに加え、Itanium®プロセッサファミリをサポートしている。またいずれのモードでもダンプ生成時にはまず対象アプリケーションの全スレッドをフリーズし、それぞれのスレッドのダンプを取り、次に全スレッドをフリーズから解放する。生成されたダンプは、Windowsの標準デバッガ「WinDbg」で解析できる。

　コンソールモードはuserdump.exeを実行するだけでいい。これは、任意の複数プロセスのダンプを生成する、二次例外時にワトソン博士の代わりとしてJIT Debuggerとして利用する、あるいは作成したアプリケーションが例外ハンドラの中で自分自身のダンプを生成する（セルフダンプ）、の3通りに使える。特にセルフダンプはミッションクリティカルなアプリケーション構築で有用である。

　このツールのより本来的な使い方がFull-featuredモード。プロセスモニタリング（例外モニタリングおよび終了モニタリング）とホットキーダンプができる。

　例外モニタリングはワトソン博士でダンプが取れないとか、稼働中のシステムにデバッガをアタッチすることが許されないような場合に使える。OSの例外ディスパッチャを横取りして動作し、アプリケーションの例外ハンドラの前に一次例外を捕捉（そく）する。

　終了モニタリングはプロセス消滅時に、誰がTerminateProcess()あるいは類似関数をコールしたかをイベントログに記録する。

　ホットキーダンプは、アプリケーションがハングアップしたり、異常動作した場合に、あらかじめ設定したキーコンビネーションでスナップショットを生成することができる。

　Kanalyzeはクラッシュダンプ解析を支援するツール。メモリ空間をモデル化し、スタックやプール、同期オブジェクトなどに分類して表示すると同時に、オブジェクト間の関係や、各オブジェクトの異常を自動的に評価することができる。現在はEnterprise Edition のみの提供となっているが、Public Editionでの提供を検討中である。

　このプロジェクトは今後も継続し、ハングやスローダウンの解析を強化していきたい。また、Event Tracing for Windowsという既存のトレース・フレームワークを応用したトレースツールを開発していきたい。成果物はEnterprise Edition, Public Editionという形で今後もリリースしていく。

　昨年SQL Serverのパフォーマンスチューニングを数多く手がけたが、Itanium®を使うケースが増えてきた。ここでは、SQL Server用のプラットフォーム選択上の留意点や64ビットへの移行における留意点、事例を紹介したい。

エイ・エヌ・ティの熊澤氏

　プラットフォーム選択上の留意点としては、SQL ServerのEditionの問題（例えばStandard Editionではメモリを2Gバイトまでしか使えない）必要な搭載メモリ量、冗長性（更新系と参照系を分離している顧客も多い）、RAID上のパーティション構成などがある。

　BtoCのWebサービスでは、当初予想できなかった利用者の増加やサービスの広がりがあり得る。将来のビジネスボリュームを予測することは難しく、ハードウェアのスケールアップで当面必要なパフォーマンスを確保している事例は多い。

　アプリケーション・アーキテクチャについては、例えばIsolationのレベルや排他制御の時間と粒度の問題がある。ある企業では、排他制御がボトルネックになってデッドロックが発生した。このケースではインデックスの設定が原因だった。

　これらを前提とした上で、スケーラビリティ確保にはスケールアップとスケールアウトの選択肢がある。いずれの場合にも、Itanium®は重要な選択肢の1つである。

　パフォーマンスの阻害要因のワースト5は、キューによる実行待ち行列、不適切なサーバの構成管理、不適切なクエリとデータベース設計、不適切なインデックス定義、そして不適切なオプティマイザ・プランだ。

　例えば昨年Itanium®上のSQL Server 2000 SP3でプロシージャ・キャッシュのメモリリークが発生した。これはSP4で解決されているが、パッチを適切に当てているかは重要だ。SQL Serverの特性を理解しないで設計をしている例も多い。非常に多いのがインデックスの問題。1つのテーブルに3つ4つとインデックスをつけている例が多いが、検索と更新処理はトレードオフ。クラスタ化インデックスにどのキーを使うかが、パフォーマンスのボトルネックにつながる場合もある。さらにアドホッククエリを多用すると、毎回コンパイルが発生するため、CPUを消費する。

　 これらの問題のなかで、本稼働後に解決できる比率は、ハードウェアの変更と、パフォーマンス監視によるワークロードの変更を合わせて約30％程度。

　解決策としてはメモリの増設と最適な設定、ディスクI/O負荷分散の実施、アプリケーションサーバとデータベースサーバ間ネットワークの帯域幅拡大、データベース領域のデフラグ処理などを行う、インデックス・チューニング・ウィザードを盲信せず、不要なインデックスは追加しない。

　そして64ビット環境への移行という選択肢がある。

　SQL Server 2005 64ビット移行上の留意点についてだが、SQL Serverは7.0からSQL OS（User Mode Scheduler）を採用し、自分自身でスレッドのスケジューリングを行っている。SQL Serverのチューニングではこれを理解することが重要。

　SQL Server 2005では抜本的な内部構造の書き換えが加えられた。一番重要な改造点は.NET Frameworkの上でSQL Serverが動くこと。アプリケーションサーバとしての機能も備え、Notification ServiceやSOAPへの出口も持っている。内部的なWait Events事象は、75種類から221種類に増えた。同様に拡張パフォーマンスカウンターは382から662に増えた。これに伴い、新たなロックマネージャとロック粒度が導入されている。

　64ビット化の一番の恩恵はメモリプールである。SQL Server 2000の32ビットでは仮想アドレス空間の上限が4Gバイトで、ユーザーモードの空間は2Gあるいは3Gバイトしか使えなかった。その上で、AWEと呼ばれる拡張メモリ機能を使い、3Gバイトの上の部分にバッファキャッシュを置くことができた。Itanium® 2のネイティブ空間では、プロシージャ・キャッシュをはじめとするすべてのオブジェクトが64ビットの恩恵を受け、4Gバイトの制限を超えることができる。

　Windowsファミリでは、64ビットプラットフォームのサポートが進んでいる。Windows XP Professional Editionにはx64対応版があり、Windows Server 2003には、x64対応版に加えてItanium®プロセッサファミリ対応版が登場している。64ビットWindows上では、当然ながら64ビットアプリケーションを動かすことができるほか、32ビットエミュレーション層であるWOW64上で、32ビットアプリケーションを動作させることも可能となっている。

マイクロソフトの佐藤氏

　では、.NET Frameworkにおける64ビットのサポートはどうなっているだろうか。これまでの.NET Framework 1.1では、32ビットアプリケーションを開発し、WOW64上で動かすしかない。一方、.NET Framework 2.0では、Itanium®プロセッサファミリとx64の2種類の64ビット環境に対応したネイティブコードを作成することができる。32ビットとWOW64ももちろんサポートしている。

.NET Framework 2.0に基づくVisual Studio 2005では、多様なプラットフォームに対応するコードを、シングルバイナリで開発が可能だ。コンパイルオプションで特定のプラットフォーム向けに作成することができ、JITコンパイルによって各プラットフォームに対しネイティブなコードにコンパイルして実行するようになっている。

　これを開発言語別に見ると、Visual C++は32/64ビットのマネージコード、そして32/64ビットのネイティブコードが開発できる。Visual C#とVisual Basicでは32/64ビットのマネージコードが開発できる。Visual J#は32ビットのマネージコード開発のみをサポートしている。

　Itanium®プロセッサファミリのような64ビットプラットフォームを採用する場合、アプリケーションについては、これまでの32ビットアプリケーションをWOW64上で起動するという選択肢がある。しかし、そのままでは64ビットのパワーを生かすことができない。このため、.NET Framework 1.1で開発された従来のアプリケーションは、.NET Framework 2.0で64ビットにリコンパイルすることを奨める。そして最終的には、業務の見直しや新業務への対応といった機会をつかんで、64ビットでの構築を進めてほしい。

　32ビットと64ビットの混在環境における留意点としては、OSの持つ32/64ビット相互運用の制約を受けることになる。例えば同一プロセス内に32ビットコードと64ビットコードは共存できないため、64ビットアプリケーションで32ビットDLLを使うことなどができない。だが、64ビットプロセスと32ビットプロセスとの間のCOM/RPC通信で共有メモリやイベントなどのオブジェクトを共有することは可能だ。

　インテルは、アプリケーションのItanium® 2に対する最適化を支援するソフトウェア開発製品として「インテル コンパイラー」「インテル パフォーマンス・ライブラリー」「インテル スレッド化ツール」「インテル VTuneパフォーマンス・アナライザー」を提供している。

インテルの清水氏

　最適化の基本は、コンパイラーを最大限に活用することだ。Itanium® 2では、コンパイラーの性能が実行時性能に直接反映される。インテル・コンパイラーの性能は以前より大幅に向上している。

　最も重要なのは、O3オプションでコンパイルすること。これにプロファイルによる最適化を組み合わせる。/QparallelによりOpenMPディレクトリを自動挿入して、ループの自動分割とスレッド化もできる。

　インテルパフォーマンスライブラリーには、科学や金融などの大規模な数値処理用関数、そしてマルチメディア処理関数がある。科学技術分野では、この関数を使うことで処理が50倍アップした例もある。

　インテル スレッド・チェッカーはWin32およびOpenMPスレッド化バグの大部分を検出することができる。データレースやデッドロック、スレッドストールなどを解析し、該当ソースコード箇所を示すことができる。

　インテル VTuneパフォーマンス・アナライザーは、システム上で動作するアプリケーションのパフォーマンスデータを収集し、ソースコードやモジュール単位で問題箇所を表示できる。例えばソースコードの行単位で消費したCPUサイクルを全体に対する割合として表示できる。このツールの結果にしたがってソースコードを修正することで。パフォーマンスをチューニングできる。

　パフォーマンス低下の一因はキャッシュミス。必要に応じてプリフェッチ組み込み関数を挿入する。その際、例えばL3キャッシュのミスはL1キャッシュでもミスになっているが、L1に比べて処理に20倍以上かかることを認識するべきだ。構造体配列でなく配列構造体を使用し、キャッシュラインに必要なデータだけをロードするようにする。

　また、Itanium® 2における8ステージのパイプラインのうち、6ステージのバックエンドでは、マイクロパイプラインのストール、例外、分岐ミスを検出して、パイプラインをフラッシュするステージがある。パフォーマンス上、これが大きな問題になる場合がある。

　Itanium® 2への最適化の基本は、なるべくソースコードに手を加えず、コンパイラーによる自動的な最適化にまかせることにある。手を加えていくと、Montecitoなどの新プロセッサに対応するために、改めて変更が必要になることも考えられる。ライブラリーのリンクとスレッド化ツールによる並列アルゴリズムの並列化でこれを補完するのがお勧めだ。