2007年11月20日発行
The Mainstream - 2007年11月 - 第27号
John Shedletsky, Vice President, Competitive Technology, IBM Software Group
メインフレーム上で稼働するLinuxへ分散アプリケーションを統合すると、その結果ハードウェア・コスト、人件費その他のコストを削減できることは十分実証されています。しかし、コア・ビジネスを拡張する場合は、「大きな鉄の塊」（つまり「大型コンピューター」）に固執すべきなのでしょうか。それとも、それらのワークロードを分散プラットフォームに移行すべきなのでしょうか。これは大きな問題であり、複数のプラットフォームを運用管理するIT部門が正確なコスト比較の計算を行う時に、大きな課題となってきます。
IBMはメインフレームの価格政策の調整や戦略の見直しを常に進めており、プラットフォームの正確な費用対効果を理解することは、新しいワークロードを徐々に追加する上で役に立ちます。
いくつかの例とそれに関連する数字を示しながら、総所有コスト（TCO）を計算する際に必ずしも考慮されていない観点を明らかにします。
System z上での拡張
既存のメインフレーム環境では、System z上で新しいワークロードを追加する方が分散ボックス上で展開するよりも経済的にはるかに理にかなっています。それは、System z上でスケールアップするに従ってトランザクション（つまり作業単位）当たりのコストが下がるからです。
前述のとおり、IBMではSystem zハードウェアおよびソフトウェアが大幅に料金が下がる体系を実施しているため、トランザクション当たりのコストはさらに下がっています。たとえば、MIPS当たりのMLC（月額ライセンス料金）は、システムのリソース使用量の増加に応じて下がります。さらに、メインフレーム上で新しいアプリケーションを稼働させた場合、既存のワークロードに加算され、MLCの「傾斜料金」の対象となるため、単位コストはさらに下がります。
そのほかにも、メインフレーム上でLinux処理機構（IFL）を使用してLinuxアプリケーションを処理すれば、一時払いの料金は発生しますが、継続的な削減効果が得られます。また、zIIPやzAAPなどの専用エンジンによって新しいワークロードの処理を中央処理機構からオフロードすればMIPSコストはさらに下がり、ソフトウェアのサブキャパシティー料金体系の強化もメインフレームのさらなるTCO削減に貢献します。
逆に、サーバー・ファームのように分散サーバー上でスケールアウトすると、作業単位当たりのコストはほとんど変わりませんが（実際には複雑さの増大によって増加しますが）、ハードウェア・コストと人件費が大幅に増加します。また、多くのIT部門では、多額のハードウェア・コストを必要とする障害復旧を分散コンピューティングの予算に含めることも忘れています。メインフレームの障害復旧は、一般に分散コンピューティングの約半分のコストで済みます。
前提に問題あり
ところが、メインフレームが本来持つ利点や最近のコストやテクノロジーの変化にもかかわらず、相変わらず既存のメインフレームのワークロードを初期コストの低いサーバーにオフロードすることによってコスト削減を図ろうとしているユーザーがいます。
しかし、それで思い描いたとおりの好結果が得られることはめったにありません。意思決定に当たっては、以下の考慮事項について考える必要があります。
- エネルギー・コスト
メインフレームのコスト計算の際、電力、冷却、スペース、およびストレージのコストを考慮に入れるのを忘れがちですが、これらも作業単位の正確な実行コストを算定する上で重要な要因となります。
概して、分散サーバーの方がはるかに運転コストがかかります。たとえば、HP Itanium 2 Superdomeの消費電力は最大2万4,392ワットですので、年間の電力コストは約1万9,230ドルに上ります。それに対して、処理能力が同等のメインフレーム（System z9 S08の消費電力は6.3kW）の電力コストは5,000ドル足らずです。
それに伴う冷却コストは、一般に電力コストの約60%に相当しますので、Superdomeの場合は1台当たり年間3万ドルの電力コストが追加発生することになります。一方、処理能力が同等のSystem z 9の場合は8,000ドル足らずで済みます。
その他の考慮事項：この比較では、障害復旧用およびテスト用サーバーの電力コストは計算に入っていません。また、データ・センター内の既存の冷却用通気口を利用できるようにサーバーを再配置するためのコストも含まれていません。あるお客様の場合、冷却に都合のよい位置にハードウェアを移動するだけで25万ドルかかっています。 - スペース
メインフレームはプロセッサーを容易に追加できるため、System zはサーバー・ファームと比べてもはるかに小さな設置面積で済みます。たとえば、IBM System z9の設置面積は、1プロセッサーであろうと最大の28プロセッサー（S028）であろうと26.7平方フィート（約2.48平方メートル）です。それに対して、8プロセッサーのSystem zと同等の処理能力を持つ22台構成のSun Fireサーバー・ファームの設置面積は、5.8平方フィート（約0.54平方メートル）です。ところが、システムを拡張するに従って逆転し、28プロセッサーのメインフレームに相当する構成のSun Fireサーバーには2倍の設置面積、つまり52.2平方フィート（約4.85平方メートル）が必要になります。
もちろん、新しいデータ・センター・ビルを建設することもできますが、そのコストは1平方フィート当たり400ドルにもなるでしょう。 - ストレージ
そのほかにも、メインフレームのTCOを考える際に忘れてはならない問題として、ストレージとデータ圧縮効率があります。その差は数百万ドル単位のコスト減、あるいはコスト増につながる可能性があります。たとえば、IBM DB2の圧縮率は59%ですが、Oracleデータベースの場合は29%です。したがって、100TBのデータをDB2に格納する場合、42TBのIBMストレージが必要で、約145万ドルのコストがかかります。同じデータをたとえばHPストレージを使用してOracleに格納した場合、75TBのHPストレージが必要になり、そのコストは約334万ドルに上ります。 - 人件費
言うまでもなく、人件費は依然として最大のITコストです。業界アナリストによると、多くの企業のIT予算に占める人件費の割合は一般に70%です。しかも管理対象の分散サーバーの台数が増えるに従って増加します。メインフレーム要員の数は通常、同等の分散稼働に割り当てられる要員数の2分の1から3分の1で、メインフレームのワークロードが増加するにつれてワークロード当たりの要員数は減っていきます。言い換えると、メインフレーマーは分散サーバーの管理を担当する各要員の4倍のワークロードを管理できるということになります。 - その他の諸経費
メインフレームから他のプラットフォームにワークロードをオフロードする場合、さらにコストがかかる可能性があることを忘れてはなりません。人件費やその他の経費を含めて、移行期間中に2つのプラットフォームを稼働するためのコストも加味する必要があります。分散環境では約2倍にも及ぶ障害復旧コストも忘れずに計算に入れなければなりません。加えて、開発用サーバーとテスト用サーバーも必要になります。そして忘れてはならないのはプロジェクトの資金調達コストです。これは、軽く数百万ドルに達することもあります。
成長は続く
メインフレームに関する長年にわたる慣行や根強い先入観をなくすことは容易ではありません。真のTCO比較は、たとえばデータ・センター・コストは通常メインフレーム・コストとして全額計上するといった時代遅れの会計慣行によってさらに歪められています。
しかし、メインフレームの運用に関連するすべての要因を計算に入れることで、真実の姿が明らかになり、作業単位当たりのコストが実は分散サーバーの半分だとわかります。
IBM, IBM(logo),System zはInternational Business Machines Corporationの米国およびその他の国における商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標。