パフォーマンスが低い？それは多分アプリのせい、ストレージじゃない

アプリケーションがどうにもうまく動かないとき、まっ先に目を向けられるのがストレージだ。しかし、多分我々はアプリケーションそのものを、違った観点から見なければならないのだ。

先日開かれたIBMカンファレンスで、私はパネルディスカッションに参加したが、私に投げかけられた質問のひとつは、私がずーっと聞かれている質問のように思えた。

「私の会社のアプリケーションのパフォーマンスを上げるためには、ストレージ基盤に対して何をすればよいのでしょうか？」

アプリケーションのパフォーマンスが悪いと、みんなすぐストレージ基盤を犯人にしたがるようだ。ＥＭＣが長年しこたまお金をかけて、ストレージこそ情報が棲む場所、というイメージを刷り込んできたのだから、そう考えるのも無理はない。

しかし、私はストレージそのものが問題を起こしていることはめったにないと思っている。そう、ストレージのIOPSを速くするためにはいくつかの方法がある。先月のコラムで話したように、ストレージの応答性を速くする一つの方法は、フラッシュ半導体ストレージや、一般にメモリーと言われるものを利用して、サブLUNティアリングの改良版を使って、データのリクエストに応えるやり方だ。データがハード・ディスクに書かれると、頻繁かつ/または競合する読み出しのリクエストにさらされるが、一時的にこのデータを半導体に入れておき、ソース側からのリクエストに応える、という方法をとることにより、全体の動きを速くするのだ。XIOは自社のシステムにこの仕組みを「ホット・シーツ」と名付けて使っている。以前、この仕組みの説明図を持って登場したエンジニアを紹介されたことがあったが、私はてっきり彼の名前が「ホット・シーツ」なのかと思った。

書き込みを早くするための方法としては２つのストレージ・ソリューションが用意されている。ひとつ目は、一般的に「ショート・ストローキング」と呼ばれ、たくさんのディスクスピンドルに書き込み処理を行わせる、並列化の手法である。より多くの読み/書きヘッドが書き込み処理を行えば、全体の書き込みパフォーマンスは増加するが、電力（より多くのディスク、発熱、ワット）とスペース（大きなストレージはアクセスフロアーの面積をたくさんとる）の代償の上でこのパフォーマンス向上は実現されている。

もうひとつの方法が、なりすましだ。いくつかのNASベンダーはバックエンドのRAIDの低パフォーマンスを補うためにこれを使っている。

基本的に、NASヘッド（thinサーバー）に直付けされたストレージ・アレイの前に大きなメモリーを置き、アプリケーションの書き込み命令を受信し記録したと応答するが、実際はデータがディスクに書き込まれる前にそれを行うのだ（「なりすまし」という言葉はそこからきている）。

メインフレームのチャネル拡張の古い時代には、我々はこの戦略によってチャネルが「大きな顔をする」のを防ぐ、と言ったものだ。言葉を換えて言えば、我々はアプリがデータを受信し、書き込みも終わったものと思わせ、アプリが自分の仕事を先に進めるようにしたのだ。

なりすましは何ら間違っていない。唯一の問題はNASベンダーがなりすましに使用するメモリーモジュールにつける馬鹿高い値段だ。私がより安価だと思った、これとは違う実装方法は、DataCore Software の SANsymphony-Vストレージハイパーバイザを使う方法だ。この製品は、他のベンダーが独自で高価なキャッシュ・コントローラーやフラッシュSSDを使ってやっていることを、サーバーの安いDRAMにやらせている。基本的にキャッシュの書き込みはアプリケーションが知らないうちにキューに置かれ、そこでディスクに書き込まれる順番を待つのだ。

そうとも、ヴァージニアさん^*訳注、ストレージのパフォーマンスを改善する方法は確かにいくつかある。しかし、それは必ずしもアプリケーションのパフォーマンスを高速化することを意味しない。好むと好まざるとにかかわらず、アプリケーションのパフォーマンスはストレージとは全くと言っていいほど関係がないものなのだ。

時としてアプリケーションに対するホストの割当が間違っている事がある。この間も、私は本番環境を準備するのに90分以上かかるデータベースのトラブルシューティングの役目を仰せつかった。元々はメインフレームをホストコンピュータとして作られたこのデータベースには、100年以上にわたる商品市場の取引が入っており、元々の設計から、いつのまにか複数の頭をつっかえ棒や梱包用のワイヤーでつないだバケモノに成長していた。どうやらOracleがその会社のCIOにうまく取り入って、メインフレームからRACへの移行を承諾させたようだ。決め手となったのは、移行してくれればOracle Magazineの表紙にそのCIOの写真を載せる、という約束だった。女性はCIOに好意を抱き、男性は自分も彼のようになりたいと思うことになる、筈だった。この作戦の結末はといえば、導入したデータベースのパフォーマンスは著しく低く、そのCIOは表紙に自分の馬鹿を晒す羽目になった。

ホストプラットフォームは、アプリのパフォーマンスが低い時、原因の根本のところで、必ず何らかの悪さをしている。これはまた別の話だが、私が昨年VMwareの前ヨーロッパ事業部長と話をしたときの内容からだ。彼はVMwareを辞めてスタートアップ（新興企業）に入った。何故なら、ハイパーバイザ・ベンダーのこれからの売上に可能性を見いだせなかったからだ、と言う。「ESXやvSphereによるアプリ統合後、みんなが一旦現役を退いたサーバーを、これまで以上の数のゲストマシン用ホストとして再利用しています。」と彼はこぼす。結果として、本来のゲストマシン用のホストとしては、コアもソケットも数が少なく、メモリーの量も足りないサーバーマシンがサービスを提供する役目を負わされることになるために、特にアプリケーション・パフォーマンスの遅さとユーザーの不平不満はすごいことになっている。

VMwareのようなサーバー・ハイパーバイザは、パフォーマンスの障害を創り出すことも多々ある。VMwareのストレージ用マイクロカーネルで使われているLSI Logicコントローラー・エミュレーションは、I/Oの大きなボトルネックになっている。VMwareは、ホストマシンにソケット数とメモリーを増やすこと（パフォーマンス改善のために大きな設備投資を要求する、ハードウェア中心の強引なやり方だ）と、ターゲット側の「インテリジェントな」（高価な、とも言う）ストレージに「最大20％」のオフロードを行うために、非標準のSCSIコマンドを持ってくるという必死の努力をして、この問題を解決しようとしてきた。最近になって彼らは、ストレージ全体をコントロールするために、また別のマイクロカーネルを書こうとしている。彼らの取り組みが上手く行くことを祈る。

最後に、アプリケーションの低パフォーマンスは、ちょっと言いにくいが、実はアプリケーション自身が原因になっている事が珍しくない、ということは話しておくべきだろう。私が知っているあるシステムは、Exchange環境を保護するために面白い仕掛けを使っている。このシステムでは、CA TechnologiesのARCserve Replication（以前、CA XOsoft Replicationとして知られていたもの）を利用して、ファイバーチャネル・ファブリックのバックエンド上にメールボックスを置くクラスタ型メールシステムを、2,3百マイル（320km～480km）離れたISP（インターネット・サービス・プロバイダー）でVMwareを稼働している1Uのサーバーにフェールオーバーしている。いつ来るかもしれないハリケーンや他の災害から4万のメールボックスを守るべく作られたこのソリューションは、結構上手く動いている。オペレーター達が言うには、システムが仮想ホストにフェールオーバーしても、ユーザーはその差に気がつかない、何故なら、どうやったって所詮Exchangeはパフォーマンスの良いアプリケーションじゃないからね！だそうだ。

これが、Global 2000の企業から200人ほどのCIOが参加したIBMカンファレンスでの私の解答だった。それにたいする彼らの反応は、拍手喝采。

分かる人には分かるようだ。

訳注：IBMのカンファレンスでToigoに質問した女性の名前と思われる。

著者略歴：Jon William ToigoはIT歴30年のベテラン。Toigo Partners InternationalのCEO兼主要執行役員、Data Management Instituteの会長でもある。

Copyright 2000 - 2011, TechTarget. All Rights Reserved,

*この翻訳記事の翻訳著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。