王子グループにおけるプライベートクラウドの構築と運用
先進的なユーザー事例を紹介する「プロフェッショナルトーク」では、王子ビジネスセンター株式会社 取締役 業務本部長の島田政明氏が登壇した。同社は、創業から140年続く製紙業を事業の柱とする王子グループにおいて、グループ全体のシステムを請け負っている。グループ全体のシステムを収容するプライベートクラウドの構築に2008年から着手。サーバの仮想集約による大幅なコスト削減と、各システムの信頼性向上に取り組んだ。
王子ビジネスセンター株式会社
取締役 業務本部長
島田政明 氏
成功のポイントは構築前の「標準化」
王子ビジネスセンターがプライベートクラウドの導入を決めた背景には、ネットの普及による紙の消費量が減っている中、年間10~15%ペースでICTコストが増加していたことがあった。そこへ、リーマンショックの影響。仮想技術を使ってICTコストを圧縮し、全体としての信頼性も向上させるという目標が掲げられた。しかし当時の仮想技術は、ようやく脚光を浴びつつあるという段階で、仮想化はもちろん標準化も、同社にとってもまったく雲を掴むような話だった。そこで、富士通とともにプロジェクトを立ち上げ、プライベートクラウドの構築に着手することとなった。
プロジェクトをスタートするにあたり、最初に行ったのがスコープの設定だ。メインフレームからUNIX、IAに至るまで、すべてのサーバを調査。その結果、IAのほとんどにあたる200台を仮想化の検討対象に定めた。しかし現状把握、サーバのランク付けの作業に入ると、「メンバー全員のICTに対する目標値がそれぞれ違う」ことが明らかに。このまま進むと解決策を導くのに相当な時間を要することが予想され、また将来の様々な取り組みにも影響を及ぼすと判断し、多少まわり道であるが、富士通の「TRIOLE(トリオーレ)利用シーンレベル全集」をたたき台に、各システムのあるべき姿を議論していった。これによって全員の意識の統一がある程度図られ、また現在も様々な取り組みに生きてきていると、島田氏は言う。
サーバのランクとして、「サービスレベルパターン(SLP)」という s/A/B/C の4ランクを設定。それまでは「なんとなく重要」という位置付けでしかなかったサーバを、可用性の観点から明確に分類した。SとAはサービス停止許容時間が1時間、Bが4時間(半日)、Cが8時間とし、SとBはさらにリカバリーポイントの違いでS1/S2、B1/B2に分類した。
サーバのランク付けは当然ICT部門だけでは決定できないため、グループ会社のユーザー部門と連携しながら進めた。自分達のシステムが止まって欲しいユーザーはいないため、最初に「重要度は?」と質問した際、誰もが「S」と答えた。しかしSランクは高可用性を求めるため当然コストもかかり、仮想集約に向かない分野だ。そこで、ICT部門から見直しを依頼。その際の質問を「経営に与えるインパクトは?」と変え、代替手段の有無についても確認し、これが奏功し、「B」や「C」と答えるユーザーが現れるようになった。このSLPの決定には、3カ月という時間をかけてじっくり進めていった。
SLPの決定後、次に行ったのはプラットフォーム選定標準の制定だ。どういったOS、ハードウェア、ソフトウェアを選定するかについて、SLPごとの可用性に基づいて作成した。また、当時は仮想環境自体が今ほど信頼できなかったことから、B/Cのみを仮想統合の対象とする基本方針を決定。これにより、データセンター全体の統合物理モデルが完成した。
環境設計・機器選定では自社要件に合っているかの見極めを
ここから実際の機器選定や設計といった稼働環境の概要設計に入る。プライベートクラウドは自社で運用していく必要があるため、運用をシンプル化でき、かつそのための設計も簡単になるハードウェアの選択を基本に据えた。サーバは当時主流であったブレード、ストレージは2本のSANストレージをカスケード接続にし、当時は仮想統合環境としてベストと言われる構成をとった。また、サーバ単体では低コストを基本としつつも、仮想環境としての可用性は十分に重視して設計し、サーバはシャーシ間のVMware HA(High Availability)構成で冗長化し、ストレージは心配であったので同期ミラー構成。加えてスナップ領域やSAN Boot領域、システムバックアップ領域をとり、非常にリッチな構成にした。
稼働環境の設計においてカギとなったのは、ベンダーによって特徴が異なるストレージだった。当時、すでにRAID構成のFCおよびSASドライブで、シンプロビジョニング機能を持ったストレージが主流であったが、FCドライブを増設すると構成によってはコストが非常に高くなることや、ストレージの中にエリアが複数できて運用が複雑になることが懸念された。一方で、当時出始めた単一階層のティアレス型ストレージは、分散ミラーを採用しているためディスクの使用にムラが出ず、複雑に運用しようとしてもできない。またSATAのためドライブも低コストですみ、意外とパフォーマンスが高いことも魅力だった。不安材料としては、国内における実例が少なかった点があったが、時間をかけて従来型とティアレス型を比較検討した結果、後者にかけてみることにした。
監視ツールも、当時はそれほど選択の余地がなかったが、仮想領域と物理領域、ストレージ、これらすべてを、ベンダーに依存せず一括で監視できることを選定条件とし、サードベンダーのツールを導入した。
運用においては、グループ各社からの仮想サーバ構築要求に対して、自動で対応するか手動で対応するかの選択があるが、同社は、自動化ソフトのコストや、毎日のように要求が来ることはないという自社要件、そしてユーザーの意識の問題から手動を選択。ユーザーには物理環境の考え方が依然としてあり、5年後を見越して余裕を持ったサーバ領域を要求してくる。それを許容すると、仮想環境で無駄な領域が大量にできてしまうため、最初の段階でかなり厳しく、もっと言えば、既存の領域よりもさらにユーザーの要件を絞っていった。その際、システムの増強は同社が計画を持って少しずつ足していくこと、そしてユーザーにはとにかく今必要な領域だけ要求して欲しいことを伝え、折り合いをつけていった。
現在の仮想サーバは約300台で、運用体制としてはリーダー1名、サーバ担当2名、サーバ/ストレージ担当1名の計4名。ストレージに関しては、ツールの使い方さえ分かっていれば運用できる構成にしたため、ストレージの専門家が必要なかったのは運用コスト面で大きかったと島田氏は言う。
大幅なコスト削減・可用性の向上を達成
同社は現在、プライベートクラウド導入時のサーバが満杯状態となり、加えてリースアップも迎えることから高集約型サーバへの移行を進めており、ストレージに関しては、運用の容易さから同じティアレス型を追加して運用している。
プライベートクラウドの構築によって、同社は目標であったコスト削減を達成。その効果は、試算では2年で億単位になる島田氏は言う。また、サーバ構築の即応性についても、ユーザーからの評価は高く、今まで2カ月、場合によっては3カ月かかっていた構築は5日程度で可能になった。しかも、日数のほとんどはすり合わせに要するものであり、実際の構築自作業体は半日ですむようになった。
また、トラブルの減少、可用性の向上といった効果も出ている。それまでは、それぞれのサーバがそれぞれの場所で勝手に動いていたというイメージで、トラブル対策もばらばらであった。しかし一カ所に集約し、かつ可用性を加味したハードウェアに移行したことで、全体のトラブルはかなり減った。実際、インフラ自体のトラブルでシステムを停止したことは一度もない。
さらに、最初の段階で標準化にしっかり取り組んでことで、今もなお運用そのものの標準化が維持されており、以前と比べると非常にシンプルな運用になった。
仮想環境のニーズ増により、システム拡張へ
こうした効果がある一方で、予想外のことも起こった。当初の180台から、今は300台にサーバが増えた。Bランクに分類したサーバの中には、以前は1台であったが可用性を考慮して2台にしたケースもあり、また安価でかつスピーディーに構築できるようになったことから、遠隔のグループ会社からの利用も増えてきた。加えて、仮想化統合の対象としなかったSランクのサーバも、仮想環境の信頼度が上がってきたことから、万一のトラブルは許容してもらうという約束のもと、SAPなどの基幹系も仮想環境へ入ってきつつある。
予想外のことで最大の悩みは、バックアップである。実際のデータ領域よりもバックアップ領域のほうが大きいリッチな構成になっているため、パフォーマンスの高いストレージがバックアップでいっぱいになると言う事態に陥っている。これに関しては、今後とも富士通に相談しながら解決策を見つけたい意向である。
>> 富士通の取り組み
豊富なクラウド事例やストレージ活用ノウハウを持つ富士通の担当が登壇するセッションの前半は、「クラウドの上手な使い方」と題し、オンプレミスとクラウドそれぞれの特徴を活かして自社にとって最適なシステムを実現するためのポイントを紹介。続くセッションの後半では、「クラウド基盤を支えるストレージ活用」と題し、クラウドインフラ(仮想統合基盤)における様々なストレージの機能とそれによってもたらされるメリットが紹介された。
富士通の取り組み
クラウドの上手な使い方
クラウドに対する期待として大きいのは、1つはコスト削減、もう1つはクラウド導入によって新ビジネスを迅速に立ち上げ、機会損失をなくすといった、イノベーションの加速である。こうした背景から、ICT部門自身の立ち位置に変化が起こっており、単純にコストセンターとして構築してきた従来とは異なり、システムを活かしたビジネス貢献への期待が高まっている。
一方でICT部門は、「すべてクラウドにしてしまって大丈夫だろうか?」という悩みを抱えている。クラウドか、それともオンプレミスか、その選択のための判断ポイントは、大きく分けて5つある。しかしどれを重視するかは、お客様の要件によって異なり、それぞれバランスをとって考える必要があると久保田浩司氏は説明する。
富士通株式会社
プラットフォーム技術本部
クラウドインフラセンター
プロダクトプランナー
久保田浩司
クラウドか、オンプレミスか
1つ目の判断ポイントは、データを社外に置いても問題ないかといった「データ消失リスク」に関するもので、2つ目は、今まで社内で運用していたシステムと同等のセキュリティを確保するかといった「セキュリティ」。3つ目の「運用」は、クラウドサービスの場合に事業者のポリシーや運用レベルを許容できるかどうか。4つ目の「費用対効果」の視点では、サービスを利用してスモールスタートする場合に、導入時点ではオンプレミスのほうが高いが、システム規模が拡大するにつれてオンプレミスのほうが安くなるといったケースがある。5つ目は「可用性・信頼性」の視点で、クラウドサービスの場合に、事業者メインの障害復旧で大丈夫かどうか。クラウドの一般的な稼働率と、既存の基幹システムの稼働率には多少の差異があり、それを許容できるかどうかが判断ポイントとなる。
いずれにしても、構築前の分析のフェーズでAs-Is(現状把握)とTo-Be(あるべき姿)をしっかりと認識した上で判断することが重要である。
プライベートクラウドの4つのステップ
プライベートクラウドは、技術的な側面から見ると、「仮想化」「標準化」「自動化」「サービス化」の4つのステップで考えることができる。
例えば、「サーバを統合したい」「コストを削減したい」ということであれば、仮想化が最も効く。システム設計や構築工数の削減を目標にするなら、標準化が有効である。しかし標準化は仮想集約の範囲であって、プライベートクラウドとしての価値は、その先の自動化、サービス化へ至った時に初めて出てくる。自動化により運用の省力化や属人化の解消を実現できる。さらにサービスポータルを導入し、ユーザーの利用申請から30分でサーバ構築しシステムを提供できるところまでいけば、コストセンターとしての位置付けから一段進んだサービス事業化への道が拓ける。
自社のTo-Beがどのステップに当てはまり、その実現に向けてどのような施策が必要かは、富士通の「TRIOLE(トリオーレ)利用シーンレベル全集」を使うなどして、明確にしていくことが必要である。例えば、仮想化によるサーバ集約を目標にするのであれば、対象システムを選定しなければならない。すべてクラウドへ移行するのか、あるいはどのシステムをクラウド化し、どのシステムはクラウド化しないのか。その際、ICT部門は技術視点が強くなってしまいがちだが、業務プロセスやビジネスの視点を持って取り組むことが必要である。
今後のハイブリッド環境に向けて
今後の企業内システムは、オンプレミスとクラウドが混在したハイブリッド環境がますます増えてくると考えられる。しかし環境ごとに別々の運用体制を作っていては、管理負荷が増えたり、バックアップやジョブ管理などでオンプレミスとクラウド間の連携が複雑になったりする。久保田氏は、混在環境を一元監視することを視野に、統合監視ツールを導入することをアドバイスする。
ハイブリッド環境は、新たなメリットも生む。例えばオンプレミスのデータをクラウドサービスに待避することでデータ保護を強化したり、クラウド上のバッチ処理をオンプレミスから管理してスケジュールを連動させるといった運用も徐々に環境が整いつつある。こうした連携メリットも視野に入れた導入検討が今後は必要になってくるだろう。
クラウド基盤を支えるストレージ活用
富士通株式会社
プラットフォーム技術本部
プロダクトソリューション技術統括部
シニアディレクター
荒木純隆
最近では、部門サーバのみならず、基幹系などの大規模システムも動かすなど、プライベートクラウド上に集約されるシステムに変化が起こっている。要件の異なるシステムが混在する環境下では、効率的なデータ保管および運用においてはリソースのチューニングが重要になってくるが、仮想化されていると、従来の物理サーバで行っていた手動のチューニングや設計で待避することが難しいと荒木氏は指摘する。
効率的なデータ保管/運用
そこでポイントになるのが、処理をハードウェアに任せる自動チューニングである。「ストレージ自動階層制御」を活用した製造業A社の事例を見ていくと、A社では、I/Oボトルネックによるバッチ処理が長時間化するという問題を抱えていた。そこでストレージ自動階層制御を応用し、バッチ処理が実行される前に当該データを自動的にSSDへ移動し、終了と共にハードディスクへ戻すといった自動チューニングを実装。少ないSSDでパフォーマンスを最大化できたことで、バッチ処理時間を50~80%短縮することに成功したと言う。
自動チューニング技術としては、他にもいくつか挙げられる。
「QoSの自動化」では、ストレージ自動階層制御と連携させることも可能。「高/中/低」の3段階で帯域利用の優先度を設定しておけば、あとはストレージが自動的に処理し、目標性能に達しない業務を最適なドライブへ再配置する。
事業継続の観点で重要な、可用性の担保に貢献する「Storage Cluster」も登場している。停止時間が許容されないミッションクリティカルなシステムの場合、例えば「VMware HA(High Availability)」構成でもストレージ筐体障害が発生しても瞬時にストレージを切り替えることができる。また、計画停電や定期点検の際にVMware vSphere vMotion等を使って、VMをあらかじめ別のサーバに移動させることでシステム停止することなく運用することも可能になる。
仮想化統合基盤の運用管理負荷の軽減
仮想化統合基盤におけるストレージは、運用管理負荷の軽減にも貢献できる。例えばVMwareとETERNUSの組み合わせでは、API「VASA」を使ってVM(仮想サーバ)とETERNUSが会話することで、ストレージの様々な情報をクライアント上から参照したり操作したりできる。また同じくAPIの「VAAI」は、VMが行うゼロ埋めの処理や仮想マシンのクローン処理をETERNUSに代替させる機能がある。さらに来年には「VVOL(Virtual Volume)」という新機能が提供され、バックアップやリストアの運用性の改善が見込まれている。
同様の機能はHyper-Vにもあり、「ODX(Offloaded Data Transfer)」で仮想マシンのクローンをETERNUSが処理したり、「Space Reclamation」によって未使用領域を自動的に開放して再利用を効率化するといったことも可能になる。また、OpenStackのようなOSSクラウド基盤にも、ドライバーによる対応が進んでおり、選択肢が増えてきている。
バックアップ/リストア要件への対応
仮想化基盤の規模が拡大してくると、バックアップ運用へも影響が出てくる。インフラ管理者はシステム保全の観点からデータストア単位で、業務管理者は業務視点からファイル単位で、それぞれバックアップおよびリストアを行うが、別々のバックアップ方式を用意していては効率が悪い。加えて、データ量の増大に伴い、バックアップ時間やVMあたりのディスクサイズなどに制限が生じるという問題も出てくる。バックアップ運用においては、1つの仕組みに統合ながら、各管理者のロール(役割)ごとに制御できることが、運用効率化の大きなポイントとなる。
また、バックアップにおけるデータ量の削減に貢献する技術としては、仮想化環境で効果の高い重複排除技術が広く利用されている。
最後に荒木氏は、クラウドインフラの計画的導入についても触れ、サイロ化したシステムを単純に仮想化しただけでは、なかなかコスト削減には結びつかない点を強調。ITガバナンスを強化して全社共有で基盤化し、その上に業務をのせていくことが大きなポイントになると言う。富士通では、最適な仮想化環境をご提案するべく、セミナーやワークショップなどの「ICTインフラ最適化支援サービス」を提供。また、現状環境を評価した上で、目指すべきシステムの実現に向けた提案を行う「ICTインフラ運用アセスメントサービス」などのサービスメニューもご活用いただきたいと締めくくった。
<< プロフェッショナルトーク / パネルディスカッション >>
パネルディスカッション
セミナーの最後は、「プロフェッショナルトーク」でご登壇いただいた王子ビジネスセンター株式会社 取締役 業務本部長 島田政明 氏を迎え、プライベートクラウドのメリットやインフラのあり方についてのパネルディスカッションが行われた。
|
|
<進行>
ITジャーナリスト 新野淳一 |
<パネラー>
- 王子ビジネスセンター株式会社
取締役 業務本部長 島田政明 氏
- 富士通株式会社 プラットフォーム技術本部
プロダクトソリューション技術統括部 シニアディレクター 荒木純隆
- 富士通株式会社 プラットフォーム技術本部
クラウドインフラセンター プロダクトプランナー 久保田浩司
|
1. プライベートクラウドでコスト削減できるか?実現のための条件とは?
島田様の会社は、王子グループのサーバを仮想集約してICTコストの削減を達成されましたが、やはり成功のポイントは、構築前にきっちり標準化したり、過大な要求をしがちなユーザーに情報部門の考えを理解してもらったりしたことでしょうか。
そうですね。結局、仮想化で安く済ませるには、1台のハードウェアに仮想サーバを何台のせるかに尽きます。ユーザーから要求されるままに構築していたら、2台あるいは1台しかのせられないケースもありましたから、4台あるいは5台のせる工夫をしていきました。
グループ内のガバナンスのあり方も踏まえた説得が必要になってきますね。
説得は難しいですね。ユーザーは少ない資源では動かないかもしれないと考えますから、「とりあえずこれだけの領域で動かして、足りなければその時点で追加しましょう」と、半ば無理矢理スタートさせ、実際に動かしてから「問題なさそうだ。少ない領域で安く済んでよかった」と納得してもらう。走りながら削減していったという面もありました。
一方で、設計側の情報部門も「こんなに集約して大丈夫かな」という不安はありませんでしたか。
ありました。我々が仮想集約のプロジェクトを立ち上げた2008年当時は、まだテスト機で採用された事例が出始めた頃でした。そこでまずは、担当の業務部門には申し訳なかったのですが、1日程度ならデータ入力できなくもいいシステムで試しました。しかし今なら、試すことなくいきなり導入してもいいと思います。
富士通にお聞きします。初期投資を抑える方法として手っ取り早いのは集約率を上げることですが、集約率の適切な値については、どう考えればいいでしょうか。
まずはコスト削減以前の値を把握することが重要で、これをしていないお客様がけっこういらっしゃいます。我々の「アセスメントサービス」では、過去の膨大な事例から得た統計値をもとに、現在どれだけ使っているかを調査したうえで、理想的に集約した場合の構成をご提供できます。As-Is(現状)とTo-Be(あるべき姿)の差分をどこまで圧縮するかは、お客様側での調整となりますが、その検討材料となるデータのご提供は我々もお手伝いさせていただいています。
システムの観点からはどうでしょうか。ファイルサーバ、基幹業務、人事管理、グループウェア、メッセージングなど、効果が出やすいシステムはあるでしょうか。
お客様によって違いますので一概には言い切れないですが、例えばバッチが主体のシステムや、日中のオンラインのシステムに対して、動的なリソース変更まで踏み込んで考えるか、それともある程度固定的にリソースを割り当てるかによっても集約率は変わってきます。時間でリソースを分け合う、という考え方もできます。
実際に仮想集約に取り組まれた島田様はいかがですか。
難しい話だと思います。我々が紙パルプ産業ということもあるかもしれませんが、それほど仮想に向かないアプリケーションはないと思っています。コンシューマ相手ではなく、B-to-Bで商売をしている会社のため、トランザクションはある程度限定されていますから。ただ、メモリを占有してしまうアプリケーションは、メモリを解放するようカスタマイズしてもらう工数をかけながら、集約率を高める工夫をしていった記憶があります。集約率については、けっこうぎりぎりまで詰め込みました。当時は適正値がまったくありませんでしたから、ちょっと不安に思いながらもとりあえず回して、自分達でトライアンドエラーしながら構成していきました。
2. プライベートクラウドで解決できる課題とは?
島田様はコスト削減以外にどのような課題を解決されましたか。
もう1つの目標であったシステムの信頼性向上ですね。ユーザーに自分のシステムのランクを聞くと「止められません」と言うのに、実際には1台しかないシステムもけっこうありました。そういったシステムが会社に対してリスクを与えていたことは間違いありませんから、SランクならSランク用のサーバ、といったように、それぞれの可用性に見合った構成にしつつ仮想化できるものは仮想化していったことで、コストを上げず信頼性向上が実現できました。
隠れていたリスクが顕在化し、技術的にも対処できるようになったわけですが、逆に、今まで安く済んでいたのにコスト高になった面もあるわけですか。
グループ会社によっては、サーバ台数が3倍になり、1台あたりは安く済んでもトータルコストは上がったというケースがあります。しかしそれまでのサーバ構成自体に問題があったわけですから、1台しかないサーバで故障が発生した場合のリスクについて経営層も含め理解してもらいました。
富士通は、コスト以外でどのようなメリットをお客様に提案していますか。
それまでシステムごとに運用マニュアルを作成しテストしていた場合、標準化によって個別対応の手間が省け、またひな型を使うことでマニュアル作成も簡単になります。他にも、システムごとに操作を覚える必要がなくなれば運用効率が改善され、属人化の排除にもつながりますし、新しいビジネスの立ち上げ時も迅速なサーバ構築が実現します。
オペレーションミスや要員教育のコスト削減を実現するための前提条件として、どのようなことが必要ですか。
稼働環境をある程度絞られた製品で構成することが前提になります。そしてツールですね。よりよいツールを使うことで、性能トラブル発生時の調査がより簡単になります。また、ITガバナンスを効かせられるかどうかもかかわってきます。例えば人事給与のシステムは人事部門が予算を持っていて、会計システムは経理部門が持っている、という状況では、統合インフラが構築しづらくなります。予算も含めて全社的に統合し、計画的なICT投資を行っていくことも前提になってきます。
副次的な話になりますが、例えば、古いOSの場合、ドライバーが最新のハードに対応していないケースではアプリケーションの延命をすることが可能です。仮想化によって、ハードウェアとアプリケーションそれぞれのリプレースのサイクルを切り離せるようになりました。また、事業継続の観点では、仮想化によって1つのストレージの中にデータを収容できれば、全社的な災害対策を一括で考えることができます。会社にはたくさんのシステムがあり、それぞれ連携して動いています。あるシステムは最新データになっているのに別のシステムは古いデータのままでは、実際の災害発生時にシステムを切り替える際に不都合が生じます。ストレージでは書き込み順序を保証して遠隔地にデータを再現できますし、「VMware vCenter Site Recovery Manager(SRM)」と連携することで仮想環境という1つの仕組みの中で、災害対策が可能になります。
こうしたメリットは、パブリッククラウドでも享受できる気がします。クラウドを検討する際、プライベートとパブリック、どちらをどう選べばいいのでしょうか。
私のセッションでも、クラウド選択のポイントとして5つ挙げましたが、どうしても譲れない判断材料はデータを出すか出さざるべきか。そこだけはまずきちんと押さえていただきたいですね。また、出していいとなれば、パブリッククラウドの最大の特長はとにかくお金を払えば比較的に早くサーバを立ち上げられる点にあるため、例えば、クリスマスなど特定の期間だけシステムを増強する必要があるが普段は抱えておきたくない場合などパブリッククラウドを選択する方が良いとの判断も出てくるでしょう。
自社でシステムを持つか、SaaSも含めサービスを利用するかという観点でいくと、どこの会社でも使っているようなシステム、例えばグループウェアなどは、最近ではサービスもかなりこなれてきて、サービスレベルについて事業者とある程度話ができる面もありますので、社外に出しやすいでしょう。一方、ICT部門として自社の本業のシステムにおいて競合他社との差異化にかかわっていくのであれば、手元に置くことは、よりよいビジネスを進めるうえでポイントになるでしょう。
当時は比較にならないほどサービスの利用料が高くて"縛り"も多く、話になりませんでした。しかし今は5年のスパンで考えてもサービスのほうが安いケースも出てきています。我々は自社のプライベートクラウドを拡張していく予定ですが、同時に外のサービスの利用も検討し始めていますし、SAPなどの業務系も外のサービスでいいのではと言う考えも出てきています。先ほどデータが外か中か、という話が出ましたが、物理的に今はすべて外で、データセンター内は論理的に中というだけですから、きっちりとケアされているサービスであれば、むしろこだわらないで出ていくべきじゃないか、と我々は考えています。
3. プライベートクラウドに求められるインフラの条件とは?
構築にあたって、どのようなサーバやストレージ、ネットワーク、監視ソフトを選んでいけばいいのでしょうか。
プライベートクラウドでは、どう組むかがネックです。仮想基盤上で動くソフトウェアやミドルウェアの相性や検証工数を考えると、プライベートクラウドは意外と構築にコストがかかります。手組みで構築するか、垂直統合システムを利用するか。「垂直統合システムは高い」と言われますが、ソフトウェアの相性を確認したり1つ1つ動作検証していったりすることを考慮すると、検証済の垂直統合システムの選択も1つの方法です。
実際にどこまでやるかによって、求められる機能も当然変わってきますし、機能によって使うツールも変わってきます。弊社の運用管理ツール「ServerView Resource Orchestrator」でも、テンプレートを作成して標準化したり、サービスポータルを作成したりといったところは比較的簡単に行えます。物理層においては、サーバは足りなくなれば追加できますが、ネットワークやストレージは最初から、増設を考慮したシステム構成をしていただきたいと考えています。
またソフトウェアに関しては、我々は様々な仮想化ソフトウェアを扱っていますので、お客様の要件に合わせて最適なものをお勧めしています。ただ、OSSについて言えば、安く上がると考えるお客様が多くいらっしゃいますが、垂直統合システムの裏返しで、どのバージョン同士なら動くかといった組み合わせの確認が必要になります。当社のOSS部隊に来る商談も、トラブルシューティングやテクニカルな点も理解してサポートできる、技術者なりチームをお持ちのお客様が中心です。OSSは、新しいバージョンをどんどん取り入れることでメリットを享受できますから、バージョンアップに追随する検証を見込んで、かつそのための要員を確保する必要があります。
島田様は実際にどういった条件でインフラを選ばれたのでしょうか。
ベンダーが異なる製品間同士の整合性をチェックするような苦労は、本来ならやりたくありませんが、当社には3社コンペ必須というルールがあり、そういった苦労には昔から慣れていて、当時はあまり気にしませんでした。導入当時、我々の構成ではサーバとストレージのベンダーが異なり、米国での確認が必要になるなど、双方の検証が終わるまでに3カ月くらいかかりました。ストレージも今なら「サーバと同じベンダー製がいいかもしれない」といった選択は出てくると思います。ベンダーをそろえられるなら、あえてベンダーの策略にのっかるのも手だと思います。ソフトウェアについては、当時はVMwareの選択しかありませんでしたので、現在も引き続きVMwareを使っています。VMwareは、例えばデスクトップ仮想化等々も含め、我々が興味を持っている新しい分野に対する投資に積極的です。コストもしっかりとり、高いことは高いですが、それなりの価値はあるかなと今のところ思っています。
自社の要件に合うものを選んでいったらベンダーが違ったわけですが、島田様にとって一番大事な点は何でしたか。
ストレージに関しては、できるだけ簡便なもの。サーバが複雑になるのは目に見えていましたから、ストレージまで複雑になったらかないません。我々はストレージ専任の技術者を持っていませんから、それをハードウェアでカバーしようという考え方のもとでストレージを選びました。
今だったらそうでしょう。自動化もかなり進んでいますし、苦労せず環境が手に入るほうがうれしいですから。サーバもストレージも、集約度がどんどん上がりスピードも速くなっていますので、筐体内で合成されたほうが保証の点からもいいと思います。
自社の要件として何を重視すればいいかについて、富士通から補足はありますか?
サーバの場合、管理性の面では各ベンダーによって多少の差異があるものの、プロセッサーやメモリではほとんどありません。一方ストレージに関しては、各ベンダーの特徴が色濃く出ますし、運用にも直結してきます。ネットワークに関しては、プライベートクラウドの環境だけではなくデータセンター全体でとらえ、プライベートクラウドの拡張性を担保しながら構築するにはどうしたらいいか、といった観点で選んでいただくといいと思います。
<< 富士通の取り組み