64 ビット PC サーバの威力 (性能/価格)

 − 1,000 端末を “楽々” こなす 64 ビット PC サーバ −


 時代は変わった。 私どもの性能測定によっても明らかなように、今や 64 ビット対応の安価な PC サーバを用いることで、 スマートクライアント形態の基幹系業務アプリケーション1,000 セッションほど開設して、多重に動作させることが “楽々” と可能になった。 メインフレームやハイエンドの高価な UNIX サーバで行っていた基幹系業務に関しても、 十分なスケーラビリティをもつ安価な PC サーバで処理できるようになったのである。

 なお、64 ビット PC サーバのアーキテクチャには、x64IA の 2 種類がある。 ここではプライスパフォーマンスが高いといわれている x64 アーキの方を取上げて、これに関する報告をする。


◎ 性能測定で用いたサーバの仕様

 性能測定には、DELL 製のサーバ PowerEdge SC1425 を用いた。 このサーバは、メモリ 6 GB (ギガバイト), ハードディスク 160 GB, クロック 2.8 GHz (ギガヘルツ) の CPU Xeon (ジオン) 2 つ (Xeon はデュアルコアなので合計 4 つの CPU) を搭載している。 そして、この購入価格は、27 万円ほどであった。 なお、信頼性などに配慮した構成にすると、この価格では済まないが、メインフレームやハイエンドの高価な UNIX サーバに比べるとありがたい価格である。



 今回の性能測定だけに限ったことではないが、性能測定の際にはクライアント側の方が厄介なものである。 1,000 台の PC クライアントを設置し、1,000 人のオペレータを当てるのは、いかにも大ごとだからだ。 下記の画面へのデータインプットを行うオペレータが 1,000 人必要になってしまう。


性能測定に用いたサンプルアプリケーション「売上伝票入力」




◎ 性能測定A (166 セッション)

 人手による大ごとの測定の代わりに、クライアント側アプリに自動操作機能を付加して、 あたかもオペレータが画面へのインプットを行っているかのような状況を作り出した。 こうすれば、1,000 人のオペレータに操作をしてもらわなくても、そういう状況を擬似的につくり出せる。 しかし、単純に考えると 1,000 台のパソコンを用意しなければならないことになる。 これも大ごとなので、1 台のクライアント PC に複数のクライアント側アプリと複数の自動操作機能をのせて動作させることにした。 メモリが 1 GB で 1.6 GHz の Pentium を搭載したクライアント PC を用いることで 40 程度の多重度を実現できた。

 このようにして、4 台のクライアント PC と上記サーバを繋げて、多重度を上げていったところ 166 セッションまでの動作を確認することができた。

 この最初の性能測定Aにおけるサーバ側の状態は CPU 使用率 8 〜 14 %メモリ使用量 1.1 GBネットワーク負荷 2 % (1 Gbps のイーサネットを 100 Mbps のモードで使用したので 100 Mbps の 2 % ということ) であった。 4 台のクライアント PC は、フル稼働の状態であったが、サーバ側の負荷は軽く、まだまだ余裕のあることが分かった。


◎ 性能測定B (1,000 セッション)

 性能測定Aの延長線上で、目指す 1,000 セッションを達成するには、計算上、クライアント PC を 25 台ほど必要とする。 これも大ごとなので、クライアント側にはアプリエミュレータを用いることにした。 すなわち、あらかじめサンプリングしておいた電文 (開設から閉鎖まで) を一定の時間ごとにサーバに送り、 その応答を確認するだけの簡単なアプリケーションプログラム (アプリエミュレータ) で代用した。 こうしたところ、クライアント PC の負荷は軽くなり 1 台の PC で 600 程度のアプリケーションをエミュレートできることがわかった。 なお、maxconnection の指定を大きくしないと、アプリエミュレータは多数のクライントの役割を果たせないので、注意が必要である。  試行錯誤の末にこうしたノウハウを得ることができたので、2 台のクライアント PC と上記サーバを繋げて、 1,000 セッションまでの動作を確認することができた。


500 人になり代わってデータインプットを行っているアプリエミュレータ


 この性能測定Bにおけるサーバ側の状態は CPU 使用率 35 〜 45 %メモリ使用量 2.4 GBネットワーク負荷 2 % (この測定では 1 Gbps のイーサネットを使用したので 1 Gbps の 2 % ということ) であった。


◎ 考察その1

 セッション数と CPU の使用率は、ほぼ比例する。 この延長線上での推測であるが、私どもが用いた負荷について言うと 2,000 セッション程度で CPU の使用率は 90 % となり、ほぼ限界に達することになりそうである。

 メモリは、私どもが用いたアプリケーションでは、1 セッションあたり 3 MB を必要とした。 これから推測すると、1,000 セッションに必要なメモリ量は、固定的に必要な 0.6 GB を含めて合計 3.6 GB 程度のはずである。 しかるに 2.4 GB しか使用していない。 この理由は、負荷として用いたアプリケーションが性能測定Aと性能測定Bで次のようの異なるためである。

 性能測定Aと性能測定Bで用いたアプリケーションプログラムの内容は全く同じものであるが、 性能測定Aでは、次のような違いをつけた。すなわち、性能測定Aでは、 アプリケーションプログラムをコピーして名前を変えたものを 200 本ほど用意して、166 の各セッションではそれぞれ異なるプログラム名のものを用いた。 この結果、性能測定Aではプログラムが共用されることはなく、166 本の別々のプログラムとみなされて、ロードされることになった。 これに対して、性能測定Bでは、すべて同じプログラム名を用いた。 この結果、プログラムは1本だけがロードされて、1,000 のセッションすべてがそれを共用した。 こうした違いがあるので、メモリ使用量に差が生じていると推定できる。


◎ 性能測定で用いた OS など

 64 ビット PC サーバをサポートした OS としては、Linux もあるが、まずは、Windows Server 2003 R2 Standard x64 Edition を用いて性能測定をした。 この OS は、32 GB までの実装メモリと 4 台までの CPU をサポートしている。 これは 64 ビット版の Windows Server の中では、最も下位に位置づけられるものであり、もっと上位の Enterprise 版なども存在する。

 この 64 ビット Standard 版の Windows Server の上に、64 ビット版の .NET Framework 2.0 (x64) と弊社の製品である MANDALA.net 実動フレームワーク V8 (V8.60.25) をのせてベースを作り、 その上に開発支援ツール MANDALA.net を用いて開発したピュア .NET サンプルアプリケーションを動作させて、主にサーバ側の資源の利用状況に関する性能測定を行った。

 ここで、ご紹介をさせていただくと、MANDALA.net 実動フレームワークとは、スマートクライアントのためのアプリケーションフレームワークであり、 これを用いることによって、スマートクライアント形態のアプリケーションシステムの開発・構築が簡単にできるようになる。 そして、MANDALA.net は、こうした開発を支援するツールである。

 サーバ側の構成は、アプリケーションサーバとデータベースサーバを分離することが一般的であるが、 今回の性能測定では、これらの二つの役割を 4 CPU からなる 1 台のサーバでまかなった。


◎ 性能測定対象のアプリケーションについて詳しく述べると

 性能測定対象のアプリケーションは、スマートクライアントシステムにした。 昔の言い方では、オンラインアプリケーションといえるが、今流には Web アプリケーションの一種だということになる。 私どもでは、ハイエンドマシーンで処理されているような基幹系業務アプリケーションを意識しており、そうした処理を PC で行うには、 スマートクライアントシステムが最もふさわしいと考えている。 そこで、ここに焦点を絞って、性能測定を行っているのである。

 性能測定で用いたアプリケーションプログラムは、私どもの Web サイト (http://www.applitech.co.jp/clickonce/) から ClickOnce 機能を用いてダウンロードして実行させることのできる 「売上伝票入力」 プログラムのようなものである。 クライアントとサーバの通信は HTTP プロトコルを用いており、.NET Remoting 機構を用いて通信を行っている。

 このアプリケーションプログラムへの操作としては、サーバ側への確認を必要とするインプットを 12 回行い、このインプットが完了した時点でサーバにデータを登録することにした。 そして、これを何回も繰り返す形態にした。

 ここで、この操作によって何がどう動作するのかを考えてみる。 サーバ側への確認を必要とするインプット操作がなされると、それはサーバに伝えられて、 サーバ側のデータベースを参照して正しいデータかどうかの確認がなされる。 一つのアプリケーションでは、これが 5 秒に 1 回ほどなされる。 したがって、1,000 セッションでは、1 秒に 200 回ほどインプットデータの確認処理がなされることになる。 なお、この際にデータベース (今回の性能測定では SQLServer を用いた) へのアクセスがなされるわけだが、 今回の性能測定においてはある限られたレコードへの参照しかしないので、 それらのレコードはほとんどメモリに常駐している (あるいはキャッシュされている) ものと考えられる。 したがって、実質的にはディスクへのアクセスはほとんどないと推定できる。  ちなみに、64 ビットのマシーンを用いたデータベースサーバではメモリを大量に積めるので、 キーやデータの常駐化またはキャッシュによる効果によって、 レコードを参照した際にディスクをアクセスしなければならない頻度は大幅に下げることができる。

 レコードの参照を必要とする 12 回のインプットが終わると、データ登録の指示がなされる。 そして、画面にインプットされたデータがデータベースに登録されることになる。 これはトランザクション処理として、一つのアプリケーションで 1 分間に 1 回ほどなされる。 したがって、1,000 セッションでは、1 分に 1,000 回ほど、つまり 1 秒に 16.7 回ほどなされることになる。 これは、データベースにとっては結構な負荷になっている。 なぜなら、データベースへの登録処理の中では、11 個の明細レコードと 1 個の概要レコードの合計 12 レコードがディスクに書かれることになるからだ。 この他にデータベースのログも書かれる。したがって、少なくとも 1 秒間に 200 (12 × 1,000 ÷ 60) 回の割合で書き出し処理がなされるといえる。


◎ CPU 負荷

 こうした処理をすることは、CPU に対する負荷として高いものか低いものか、 それは皆様がどんなアプリケーションを想定するのかによって感じ方は異なるに違いない。 ここで言えることは、皆様が想定するアプリケーションを何多重で動作させられるのかを見積もる際に、今回の測定は大いに参考にしていただけそうだということである。

 アプリケーションによっては、そのロジック上 CPU を大量に食うものもあるだろう。こういうものは、個々に CPU の負荷を見積もることが必要である。

 今回の想定で用いたアプリケーションは、特別に CPU を食うものではない。 ごく普通のビジネスアプリケーションである。 そういうアプリケーションであり、サーバへのアクセス頻度がこの程度であれば、1,000 セッションは楽々こなせるということである。

 ただし、同じようなアプリケーションでもサーバへのアクセス頻度が2倍であれば、 すなわち 2.5 秒に 1 回ほどサーバでの確認が必要なインプット操作があり、30 秒に 1 回ほどデータ登録がなされるようなヘビーな使い方であれば、 1,000 セッションで CPU 使用率が 90 % となり限界だといえそうである。

 ただし、私どもが用いた Xeon は、2.8 GHz だったので、3.8 GHz の CPU を用いれば、さらに処理能力を増加できるだろう。 また、今回の性能測定では、アプリケーションサーバとデータベースサーバを分離せずに1台のサーバでまかなったが、 これらを分離することで CPU 使用率は若干低くなると思われるので、これによっても処理能力の増加は期待できるだろう。


◎ 各種資源の必要量とネックとなる資源

 今回の測定は、アプリケーションサーバの能力をターゲットにしたものであり、ここまでは主に CPU の使用率やネットワークの使用率などに注目してきた。

 この他にメモリの使用量についても、注意を払うことが必要だが、それは実装メモリをどの程度必要とするかということに帰着できる。 そして、64 ビットマシーンでは、大抵は必要とするメモリを実装可能だと考えてよいだろう。 つまり、必要とするメモリを積めばよいのである。 32 ビットの世界では、4 GB を超えることが難しかったが、その制限は大幅に緩和されたのである。

 この他に、もちろんデータベースの負荷に関しても注目することが必要である。

 これらの資源、すなわち CPU、メモリ、ネットワーク、データベースは、どれも重要である。 なぜなら、これらのどこかにネックがあると、それによって処理能力は頭打ちとなってしまうからだ。 そこで、どこにネックがあるのかを見つけて、それを解消していくことが重要なのである。


◎ データベースの負荷

 データベースの負荷は、どんなアプリケーションかによって、大いに異なるところである。 そして、必要なデータアクセスは必要なので、それを見積もることから始めなければならない。 データベースの負荷が高ければ、データベースサーバを分離した構成にするのがよいだろう。 そのデータベースサーバであるが、64 ビット化のおかげで 4 GB を超えるメモリを積むことによって、 アクセス頻度の高い大量のレコードをメモリに展開することも可能になる。 まずは、キー情報はメモリへの展開の第一候補になるだろう。 場合によっては、データまでもメモリに展開しておけるだろう。こうすることができれば、 最終的なディスクへのアクセスは、トランザクション制御のためのログや更新データをディスクに書き戻すことだけに限定できそうである。

 また、データベースシステムのキャッシュの効果も大いに期待できる。

 要するに、データベースからデータを読み出すことに関しては、メモリへの展開 (常駐化) やキャッシュの効果によって、 高速化できる余地が大きい。 他方、データを書き出す処理に関しては、そう高速化できる余地は少ないといえる。

 なお、今回の性能測定に用いた DBMS は SQLServer であったので、メモリの活用に関しては、max server memory の指定を大きくすることぐらいで、 細かなチューニングの指定はできなかった。 SQLServer は、オートマティック車のようなものであり、ORACLE のようないわばマニュアルシフトの車と違って細かなチューニングの指定はできないようである。 これは、その分だけチューニングの手間が省けてよいということもできる。


◎ 発生したスローダウンの原因究明と問題解決

 実は、性能測定Bを実施しているときに、しばらく動作させているとスローダウンが発生した。 通常は、各アプリケーションで 1 分間 (60 秒) に 1 回ほどなされるデータベースへの登録処理が 90 秒ほどかかるようになってしまうのである。

 CPU、メモリ、ネットワーク、データベースなどの資源にネックが生じていないか調べたが、これなに問題はない。 いろいろ調べて最終的に分かったことは、クライアントとサーバの通信に用いている .NET Remoting というソフトウェアがこうした高負荷にたえられないようだ。 あるいは、.NET Remoting の使い方に問題があるのかもしれない。 そこで、.NET Remoting ではなく、サーバ側を IIS としてプレーン HTTP による通信手段に切り換えてみたところ、スローダウンは生じなくなった。 ちなみに、MANDALA.net 実動フレームワーク を用いているので、通信手段を簡単に切り換えることができる。

 マイクロソフト ビジネスフォーラム 2007 で行うデモには、もちろんこうした問題を解決したものである。 そして、アプリエミュレータのチューニングを行った結果、1 台の PC で 500 程度のアプリケーションをエミュレートできるようになった。 したがって、1,000 端末はクライアント側は 2 台の PC でまかなえる。ただし、アプリエミュレータによる負荷だけでは面白くないので、 人手で操作できる PC も用意するので、是非ともご覧いただきたい。



1, 000 端末のエミュレートに加え、人手で操作できる PC も繋げたサーバのコンソール (1,001 セッション)


◎ まとめ

 世の中には .NET Framework のスケーラビリティに疑念をもたれている方々もいらっしゃるようだが、私どもでは 64 ビット PC サーバによって十分なスケーラビリティが得られる時代になったと考えている。 確かに 64 ビット版には問題があるかもしれないが、それは部分的な問題である。 たとえば、高負荷時の .NET Remoting の動作は不安定であるし、64 ビット版の.NET Framework には解決すべき設計上の問題が残っているとのことである。 こうした問題が皆無だというわけではない。 しかし、今回の性能測定のように、問題のありそうなところを避けて通れば、十分に実用的に使えるレベルになっている。 そして、64 ビット版の.NET Framework の問題は .NET Framework 3.5 または 4.0 で解決されるなどと、環境は整いつつある。 したがって、64 ビット PC サーバは、今から活用しても決して早すぎるわけではない。

 この性能測定で感じたことだが、ハードウェアのプライスパフォーマンスは、こんなに高くなっている。 したがって、皆様方が私どもが実施した程度の簡単な性能測定であっても、それを実施なされば、64 ビット PC サーバの威力をきっと実感なさることだろう。

 しかし、業務アプリケーションの構築に、昔と同様に手間がかかるのでは、性能測定ですら躊躇したくなるかもしれない。 そんなときには、スマートクライアントのためのアプリケーションフレームワーク MANDALA.net 実動フレームワークを用いていただきたい。 それに、開発を支援するツール MANDALA.net を併用するのである。 こうすれば、この程度の性能測定であれば簡単に行うことができる。 いや、性能測定の結果に満足できるのであれば、64 ビットの本番のシステムに是非とも MANDALA ファミリを採用していただきたいものである。 必ずや、開発の成果に関して生産性・品質・再利用性が向上することを実感なさるに違いない。


◎ デモの性能測定環境 (サーバ側)

アプリケーション:  売上伝票入力 (開発にはMANDALA.net を使用)
アプリケーションフレームワーク:  MANDALA.net 実動フレームワーク V8 (サーバ)
プラットフォームフレームワーク:  .NET Framework 2.0 (x64)
データベース管理システム:  SQLServer 2005
Web ホスティングシステム:  IIS 6.0 + ASP.NET
オペレーティングシステム (OS):  Windows Server 2003 R2 Standard x64 Edition
ハードウェア:  PowerEdge SC1425 (27 万円で購入したもの)
    メモリ 6 GB (ギガバイト), ハードディスク 160 GB,
    クロック 2.8 GHz (ギガヘルツ) の CPU Xeon (ジオン) 2 つ
    (Xeon はデュアルコアなので合計 4 台の CPU)


◎ デモの性能測定環境 (クライアント側)

高速アプリエミュレータ 2 台で 1,000 端末のアプリケーションをエミュレートしていることに加え、
人手で操作できる以下の PC
アプリケーション:  売上伝票入力 (開発にはMANDALA.net を使用)
アプリケーションフレームワーク:  MANDALA.net 実動フレームワーク V8 (クライアント)
プラットフォームフレームワーク:  .NET Framework 3.0
オペレーティングシステム (OS):  Windows Vista (Business)


◎ デモでの性能測定の結果 (サーバ側)

CPU の使用率:  50 ± 15 % ほど (負荷の変動に依存)
メモリ使用量:  2.4 〜 3.0 GB
ネットワーク負荷:  0.5 % (1 Gbps の 0.5 % なので 5 Mbps)
伝票処理レート:  平均 1,000 枚/分



CPU および メモリ使用量をタスクマネージャで表示



ネットワークの負荷をタスクマネージャで表示



MANDALA.net の実動フレームワークの威力

 − スマートクライアント形態の業務システムの開発をご支援 −


 MANDALA.net は、スマートクライアント形態の業務システムを開発する際に用いるフレームワークとツールであり、基幹系業務アプリケーションの開発をご支援いたします。

 以下の七つの特徴により、お客様の開発作業、およびカスタマイズ作業の生産性品質再利用性を向上させます。


@ 単にクライアント側の支援だけではなく、Web で繋がるサーバ側までも総合的にサポートする本格的なアプリケーションフレームワークを装備 (スマートクライアント専用)。


A キーボードからの高速インプットにも対応するレスポンシブな画面表示と操作性を実現。 ブラウザベースのシステムでは実現困難であった Web システムを構築できる。


B アプリ開発者の方々の主な仕事は画面レイアウトのデザインとビジネスロジックのプログラミングだけで済み、後は MANDALA.net に任せられる。 開発なさった資産は、MANDALA.net コード合成ツールによって解析され MANDALA.net 実動フレームワークとの結合のためのソースコードが生成・付加され、実稼動するプログラムになる。


C ビジネスロジックをデータ項目対応のクラスとする手法を採用。大勢のアプリ開発者たちによる再利用がしやすい資産に仕上がる。 実際に、ERP パッケージのカスタマイズをその開発元以外の企業 (カスタマイズ業者) が実施する例が数多くある。


D 独自仕様は極力排除し標準ソフトウェアをとことん活用
 言語は: VB, C#,
 プラットフォームは: .NET Framework、
 通信は: プレーン HTTP で IIS と繋ぐか、または .NET Remoting、
 デザイナ (スクリーンペインタ) は: Visual Studio 2005統合開発環境のもの、など。


E MANDALA.net 自体をご注文に合わせるカスタマイズサービス (お抱えツール屋サービス) も受託 (ただし有償)。


F お客様が開発したソフトウェアの資産価値を維持し高める手段を提供。 ビジネスロジック部品は、マルチ言語対応の資産に昇華させることもできる。



    


Copyright (c) 2007 By AppliTech, Inc. All Rights Reserved.
AppliTech および MANDALA および workFrame=Browser は、アプリテック株式会社の登録商標です。
ここに掲載の社名、製品名には、各社の商標または登録商標があります。