ERPを含む基幹系を仮想環境で統合　440台のサーバーを4台のブレードに集約【富士フイルム】

IT Leaders編集部 - 2009年5月15日(金) 08:00

仮想化技術でサーバーを統合し、コスト削減に取り組む企業が増えている。だが、ほとんどがファイルサーバーやグループウェアサーバーの統合に留まり、基幹系の統合事例はゼロに等しい。そうした中、富士フイルムはSAP製のERPを含む約440台の基幹系サーバーを、2010度までに4台のブレードサーバーに統合する計画を進めている。
聞き手は本誌編集長・田口潤　Photo：陶山勉

柴田英樹氏: 富士フイルムコンピューターシステム
システム事業部 ITインフラ部部長; 1998年10月に入社。基幹系システムの再構築やERPパッケージのグループ展開を手掛けてきた。現在は、基幹系システムの戦略立案や開発指針の策定などを統括している。

渡辺和博氏: 富士フイルムコンピューターシステム
システム事業部 ITインフラ部主査; 1999年12月に入社。基幹系システムやサプライチェーンマネジメントシステムの構築を担当。現在は、基幹系サーバーの運用管理やサーバー統合を推進するリーダーを務める。

─ 約440台の基幹系サーバーを仮想化して、ブレードサーバー上に統合するそうですね。「基幹系を仮想化して統合するとは、随分思い切ったことを」という感じです。まず、きっかけを教えてください。

柴田：大きいのは、運用コストの増加です。当社では過去、汎用機で動いていた基幹系を刷新、オープン系に移行しました。SAPのERPパッケージや他の連結会計ソフトを稼働させていますが、グループ内外にサービスを提供してきた結果、年48台のペースでサーバーの台数が増え、現時点で298台になったんですよ。運用費で言えば、2004年度に7億円だったのが2007年度には28億円と、4年間で4倍になりました。

─ 4倍！会社から、「いい加減にしなさい」と怒られませんでしたか（笑）。

柴田：ま、あくまでもオープン系について4倍になったということです。ホストの運用コストなどを減らしていますから、トータルは別ですよ。

富士フイルムの主力商品であるデジタルカメラ「FinePix（ファインピックス）」と、スキンケア化粧品「ASTALIFT（アスタリフト）」

─ なるほど。ホストの減少分を考えると、横ばいか、微増ですか？

柴田：いや、トータルでもそれなりに増えました（笑）。それはともかく、第2にシステム資源の有効活用に関する問題意識があります。

普通、サーバーやストレージは数年後のユーザー数や必要ディスク量、期末期首のピーク性能を考慮して調達します。すると、どうしてもオーバースペック気味になって、平常時のプロセサやメモリーの使用率は2割くらいにしかなりません。

ハードの保守切れも問題でした。オープン系のサーバーは7年ほどで保守パーツが供給停止になる。このとき単にハードを更新するだけならまだしも、OSまで新しくしなければなりません。当然、データベースソフトやミドルウェア、パッケージソフトのバージョンアップも必要になります。

─ 時々、聞く話ですが、古いバージョンのOSを最新のハードで動かすことはできないと思ったほうが良い？

柴田： OSのコアは動くかもしれませんけど、デバイスドライバが問題ですね。古いOSでは最新のドライバがサポートされていないので、実質的に古いOSは新しいハードで使えません。

─ 少し嫌な質問ですが、柴田さんは富士フイルムコンピューターシステムの部長ですよね。富士フイルムからの委託費が売り上げになるので、運用コストが高くてもいいのでは。

柴田：当社は10年ほど前に富士フイルムから機能分社しました。富士フイルム本体やグループ各社のシステム構築と運用管理だけでなく、システム企画やIT戦略の立案、ガバナンスや情報セキュリティを効かせることも、当社のミッションに含まれます。

─ 会社は別だけど、役割は情報システム部門そのもの。

柴田：そうです。プロフィットセンターではなくコストセンターの位置づけですから、運用コストを増やして収益を上げても意味がありません。むしろ下がったほうが、グループ内で効果的に機能していることになります。

─ なるほど。よこしまな質問で、大変失礼しました（笑）。ところで統合プロジェクトの開始はいつ？

図1　サーバー統合プロジェクトのスケジュール（図をクリックで拡大）

SAPの動作保証を“自信”にプロジェクトを本格化

柴田： 2007年10月です。掲げたのは、次のようなテーマでした。まず運用コスト削減、省電力化、省スペース化、システム資源の有効活用は、当たり前。ハードは小規模構成から始めて段階的に拡張可能にする。それからハード更新に伴う、ソフトの無用なバージョンアップを減らす、といったことです。

─ ずいぶん欲張りな。次に何をしましたか。

柴田：最初の3カ月は構想固めです。仮想化技術の採用は決めていましたが、ベンダーにRFI（情報提供依頼）をお願いし、具体的にどんなテクノロジを使うか検討しました。

─ 今でこそ、仮想化はポピュラーですが、2007年だと特に「基幹系には時期尚早」と考えるベンダーが多かったと思いますが。

柴田：ええ、実際に仮想環境での動作保証に二の足を踏むベンダーはいました。でもよく聞いてみると、大抵は実績がないだけで、明確な根拠があるわけではない。何か問題が生じたとき、原因が業務システムにあるのか、ミドルウェアにあるのか、仮想化ソフトにあるのかといった切り分けができれば、保守サポートは引き受けるというのが各社の基本スタンスでした。

─ しかしその切り分けが難しいわけですよね。特にユーザー企業が切り分けに責任を持つとなると…。

柴田：その点、当社は、基幹系の構築と運用を自ら手掛けているので、技術的なポイントを抑えています。当社が切り分けをするということで、サポートも受けてもらいました。

─ なるほど。でも富士フイルムの基幹系は、SAPですよね？

柴田：ええ。財務／管理会計、販売、在庫・購買、品質管理、人事管理などを使っています。

─ 2007年当時、SAPジャパンは仮想化をサポートしていました？

柴田：正式にはなかったですね。問題はないはずでしたが、正直、悩みました。ところが2007年12月、ちょうど構想化フェーズの最終段階になって、SAPがVMwareの仮想化ソフト上で、ERPの動作保証をすると発表したんですよ。SFA（営業支援）や連結会計で他のアプリケーションも使っていますが、SAPが大丈夫なら他もVMware上で動くだろうと考え、プロジェクトを具体化しました。

リース切れや残存簿価から移行の優先度を決める

─ 具体化では、まず何を。

柴田：何月にどのサーバーを移行するか、それまでに何を実施するかを決める計画化フェーズです。既存サーバー約300台について、移行の優先順位を決めて、2008年後半から2010年度までに順次、新しい環境に移行する計画を立てました。その後、システム要件定義や移行検証などへと続きます。

─ 最初の本番系サーバーの移行まで1年、300台をすべてを3年弱で統合する。かなり速いペースでは？

柴田：月平均4台のサーバーを追加するペースで新規システム案件が並行して走っていますから、スピード感が求められました。そもそも統合作業は長々と計画しているより、検証を含めて一気に進めたほうが効果が出やすいんです。

─ 渡辺さん、もう少しゆっくりしたいと思ったでしょう。

渡辺：はい（笑）。移行だけなら、もう少しのんびりしても良いのでは、と考えたかもしれません。ただ、サーバー移行というシステム側の都合で新規案件を遅らせることはできないですから。

─ ところで一口に300台の既存サーバーを移行するといっても、順不同というわけにはいきませんよね。優先順位は、どう決めたのですか。

柴田：まず保守パーツの提供期間。第2にハードのリース切れ時期。そして保管費、つまり消費電力や設置スペースの大きさ。最後に許容できるサービスレベル。これら4点を考慮して、優先順位を考えました。例えば、すべてのサーバーについてリース切れ時期や残存簿価を調べて、いつ統合すると最も効果を出しやすいかをシミュレートしたんです。ハウジング費用が高い場合は、リース期間が残っていても、早めに仮想環境上に移行した方が、コスト削減効果が大きいケースもありますから。

図2　サーバー統合後のシステム構成の概要。VMwareの「VMware ESX」でサーバーを仮想化している（図をクリックで拡大）

仮想化の判定や資源配分の方針を独自に策定

─ 基幹系ならではの、難しい点もあったでしょう。

柴田：いくつもあります。仮想化すべきかどうかを判断するのが、その1つです。

─ 何かを参考にされたのですか。

柴田：最初は他社の事例を参考にするべく情報を集めました。ただ…。

─ ただ？

柴田：事例のほとんどはWebシステムの一部分だったり、データベースサーバーが含まれていなかったりと、限定的だったんです。結局、「可用性」と「性能」、「サポートの有無」、「VMwareの制約」という4つの基準を独自に設けて判断しました。

可用性について言えば、仮想化検証環境で性能や他システム連携の確認試験を実施しています。既存システムのレスポンスタイムやバッチ処理時間を基準にして。

─ 4つめのVMwareの制約というと？

柴田：プロセサの能力やメモリー容量によっては、VMwareでサポートされないケースがあるんです。例えば運用中のSAPのデータベースサーバーの1つは、32個のプロセサと128ギガバイトのメモリーを搭載している。この規模になるとサポートされません。

─ 結果として、仮想化できないと判断を下したシステムはあった？,

柴田：ダメではないのですが、不向きなのはありました。PDFの帳票などを数万件や数十万件の単位でディスク上に生成し、そこへのアクセスが頻繁に発生するようなシステムです。富士フイルムの基幹系でいうと、特許出願情報をPDFで残しておく知的財産関連のシステムがその1つです。オーバーヘッドが大きくなるので、仮想化は向いていません。

─ 色々ありますね。でも、そこまでやれば、後は粛々と移行作業をするだけ。

柴田：とんでもない。移行すべき既存サーバーの台数が多いので、12の移行パターンを決め、ベンダーとともに移行手順を検証しました。OSの違いや、業務アプリケーション／データ交換／障害監視／データベースといった処理内容の違い、稼働マシンの違いなどによってパターン分けしたんです。OSだけで、Windows2000 Serverが2種類、Windows Server2003が2種類と、4種ありましたからね。

─ 検証段階で問題は出ました？

柴田：はい（笑）。移行ツールに不具合があったり、バックアップ用のテープドライバが不要だったりとか、色々なことが起きましたよ。移行後、ちゃんと動作するかを検証するのは必須でしたね。

休日返上でサーバーを移行
リソース使用率は80％に

─ 統合後のハードウェア構成について教えてください。

柴田：サーバーブレードを16基搭載した4台のブレード・エンクロージャがあります。うち3台が本番用、1台が開発/検証用。それぞれVMwareの仮想化ソフトを使ってプロセサやメモリーを共通化しておき、サーバーが必要になったときにリソースを割り当てるという使い方です。ブレードの1つは、障害時の予備用です。

─ 1台当たり、どれだけの仮想OSを稼働させるのですか。

柴田：ブレード1基につき5から10個といったところですから、最も良いパターンでエンクロージャ1台当たり、100個の仮想OSを稼働できる計算です。現時点で既存サーバー70台と新規サーバー48台を移行済みですが、1台のエンクロージャで50個は問題なく動くことを確認しています。

─ 予備を除く15基のブレードをフルに使うと、単純計算で150個になりますが、そこまではいかない？

柴田：そうですね。ただ、100個でも集約率は十分に高いですし、事実、リソース使用率も格段に高まります。これまで20％程度だったプロセサとメモリーの使用率は、80％くらいに達しています。

─ そこまで使用率が高いと、かえって不安になりませんか。

渡辺：「おお、ちゃんと有効活用できているな」という気持ちになることはあっても、不安になることはないですよ。

─ 最後に、まだ300台近くのサーバーをブレードサーバーに載せていくわけですが、どのようなペースで統合作業を進めていくか教えてください。

柴田：だいたい月平均10台ペースです。平日にシステムを止めることができればペースアップできますが、基幹系の本番システムとなると、そうもいきません。週末に作業するしかないので、日曜日にオンラインサービスを停止して移行します。

─ ということは、まだしばらくの間、土日の出社が続きそうですね？

渡辺：そうなります。でも出社は順番ですし、慣れれば何でもないです（笑）。

─ 渡辺さんは我慢強い。

柴田：確かに、彼は打たれ強いタイプです（笑）。