いち早く取り組む企業に学ぶ次世代のIT基盤の考え方 東京編[09/12/11]

【TIS主催】 次世代IT基盤のロードマップを考える研究会
~クラウド新時代に向けて今IT部門がなすべきこと~ 第3回
いち早く取り組む企業に学ぶ次世代のIT基盤の考え方

日 時 2009年12月11日
参加者 ITインフラの再整備について考える企業の情報システム部門リーダー 7名
主 催 TIS株式会社
ファシリテーター
株式会社ナレッジサイン 吉岡英幸
 TISでは、情報システム部門のリーダーが、自社のITインフラにおける課題を共有し、いずれ本格化する「クラウド・コンピューティング」の時代にむけて、あるべきITインフラの姿や、IT部門が今なすべきことについてディスカッションする『次世代IT基盤のロードマップを考える研究会』を発足いたしました。第3回となる今回の研究会では、「いち早く取り組む企業に学ぶ次世代のIT基盤の考え方」をテーマに、IT基盤の再整備に積極的に取り組まれている企業から、その先進的な取り組みをご紹介いただきました。その後、その事例を踏まえ、参加者全員でIT基盤のあり方についてディスカッションをいたしました。本レポートではその議論の一部をご紹介いたします。
◆A社でのサーバー統合/シェアードサービス化の事例
 研究会では冒頭、機械系製造業A社のIT基盤整理に関する自社での先進的な取組みについて紹介がなされた。当時、A社はサーバーの急増と、事業部ごとによるIT資産の個別調達に頭を悩ませていた。そこで、A社のIAサーバーを統合し、それまでA社のデータセンターを運用していたシステム子会社が、事業部間で共有する「シェアードサービス」を提供するという体制に移行することになる。その結果、A社が使用するサーバー全500台のうち、400台のシェアード化に成功し、現在では、A社だけではなく、外部に向けてもIT資産の貸し出しを行っているという。さらに来年度中には、提供しているサーバーのほぼ9割を仮想化し、より効率的なサービスを提供していくことが予定されている。
◆サーバー統合をどのようにして進めるか
では、A社でのIAサーバーの統合はどのようにして進められたのだろうか。
「大きな方針として、IAサーバーを6種類に分け、また、統合の方法についても4種類に分けた後、どの種類のサーバーをどの統合方法とするかを決定した」(A社)まず、IAサーバーを

(a)ファイル共有サーバー
(b)データベースサーバー
(c)コンテンツ公開のみのWebサーバー
(d)アプリケーションを伴うWebサーバー
(e)アプリケーションサーバー
(f)開発・テストサーバー

の6つに分類。次に統合の方法についても、

(Ⅰ)集約化・・・拠点に散在する複数のサーバーを1箇所のデータセンターに集める
(Ⅱ)物理統合・・・同一アプリケーションを1台のサーバーに物理的に集約
(Ⅲ)データ統合・・・サーバーではなく、ストレージを統合
(Ⅳ)アプリケーション統合・・・仮想化を用いて複数アプリケーションを1つのサーバーに統合

の4つのパターンに分類した。そして、(a)~(f)のサーバーの種類に応じて、4パターンの対応のうち、いずれを取るのかを決定していったという。たとえば、(f)開発・テストサーバーは、仮想化を使った(Ⅳ)アプリケーション統合により集約を進めた。また、グループウェアや、Web系のコンテンツサーバーについては(Ⅱ)物理統合で集約をし、「最終的にサーバーの数を半数まで集約することができた」(A社)とのことであった。

もちろん、統合を進める上で、現実には課題に直面することも少なくない。
たとえば、当初、工場に直結しているアプリケーションサーバーを、データセンターに(Ⅰ)集約化しようとしたが、ネットワークの問題から、アプリケーションの速度が遅くなってしまうため、上手くいかなったという。また、稼働日の問題もあった。製造業の場合、電気料金が安くなるため工場を土日に稼働させることが多い。これに対し、データセンターのある本社は平日稼動であるため、本社の情報システム部門が工場のシステムに対応することが難しい。

そこで、ネットワークの問題については、バーストトラフィックを許容するネットワークサービスに切り替えることで、アプリケーションの速度を高めたという。また、現在では、システム子会社のアウトソーシング部隊が24時間365日の対応をすることにより、稼働日の問題も解決し、これによって、ようやくサーバーの移管に成功したとのことであった。

また、仮想化を用いた(Ⅳ)アプリケーション統合についても問題がある。仮想化については、たとえば「バッチ系のアプリケーションと、昼間に稼動するオフィス系のアプリケーションを上手く組み合わせることで、ピークを分散し、集約率を高める」といったセオリーがある。しかし、A社では、統合の対象となるサーバーの8割がオフィス系のアプリケーションであったため、このセオリーの通りに、ピークをずらして集約率を高めることが難しく、ある程度のピーク量を想定した容量が必要になってくる。この点については現在も課題として取り組んでいるとのことであった。

◆サーバー統合推進のステップ
 上記のようなサーバー統合はいくつかのステップを踏んで、段階的に行われたという。では、サーバー統合は具体的にはどのような手順で進めていけばよいのだろうか。「最初に取り組みやすいのは、グループウェアや、ファイルサーバーなどのシステムだ。各工場ではなく、本社情報システム部門が掌握している仕組みである上に、サーバーの台数も多いため、効果が出しやすいというメリットもある」(A社)

サーバー統合を進めていく上では、事前に技術の標準化を行うことが有効である。研究会に参加していた別のある企業は、グループ内システム会社として、A社の取り組みと同様にグループ全体でのサーバー統合に取り組んでいた。

「グループ会社で同じ技術標準とすることで、グループ全体のIT投資を極小化する活動を行い、それがある程度上手くいった段階で、次のステップとして、同じアーキテクチャーであれば1つのサーバーに集約した方が、メリットがあることを訴え、統合へと誘導した」(研究会参加企業)。

標準化を推進するためには、強力なガバナンスが必要になる。この企業は、あくまでグループ内のシステム会社であるため、トップダウンでグループ各社に対してガバナンスを利かせることは難しかった。そのため、グループ全体の統合の絵をしっかりと描き、客観店なメリットを明確にしていくことで、統合を推進していったという。

サーバー統合を推進する上では、現在のIT資産の棚卸しが重要である。全社のサーバーがどこに何台あり、どのように使われているのか。A社では2004年から全社のサーバー台数が急激に増加した。その理由の一つは、事業の急成長であるが、もう一つの理由は、隠れていたサーバーを把握できたことによる「増加」分であった。

現場が独自の判断でサーバーを調達する体制から、本社システム部門主体の体制に切り替えるに伴い、それまで把握されていなかったものが次々と可視化していったと言う。

「データセンターに持ってこなければ面倒は見ないし、予算もおりない」とトップダウンで指令を出した結果、それまで各拠点、工場に隠れていたサーバーが可視化されることになり、サーバー台数が一挙に増加したのである。

◆シェアードサービスの課金制度は?
 クラウド技術を念頭に置いたITのサービス利用について、第1回、第2回の研究会でも議論になったのが、従量課金制という課金スタイルへの期待である。しかし、リソースの共同利用を行った場合、期末期初などには、全システムの利用量のピーク時が重なる。これに対応するためには、サービス提供者はピーク時に合わせたリソースを持たざるを得ないが、これを従量課金制で賄うことは難しいのではないか。研究会では、参加者からこのような意見が挙げられた。

これについては、A社も、また、同じくグループ会社に対し、HaaSやPaaSをシェアードサービスとして提供していた企業も、現時点では、月ごとの厳密なリソース使用量に応じた従量課金制ではなく、ピーク時に合わせたシステム容量を元に算出した定額課金制を採用していた。

ただ、ハードやプラットフォームには、システム更改の度に投資が必要だ。ITのサービス利用がビジネスとして成立するためには、これらの維持・運用コストを賄って利益の出る料金設定が必要になる。逆に、利用者にとっては、今後数年分の維持・運用コストがあらかじめ定額料金に上乗せされてしまうのではないかという不安につながる。

A社におけるシェアードサービス価格の考え方は次のようなものだ。

「4年間の契約期間中に、システムのスペックは上がり、コストが下がることを見越した定額での料金設定をしている。現状で採算が取れる状態であれば、原価は少しずつ下がっていくため、それによって得られた余剰を、リソース切り替えのための金額としてプールしている。『あらかじめ更改のコストを含んでいる』と言えば含んでいるのだが、より正確に言えば、『含んではいないが減価低減で得られた分で更改時のコストをやりくりできる』のだと言える」(A社)

シェアードサービスをグループに提供していた別の企業もA社と同様のビジネスモデルを採用していた。

「ムーアの法則に従うと、ハードの性能は18ヶ月~24ヶ月で2倍になる。そこで減価償却の落ち込み分のおよそ半分で同じサービスが維持できると計算している。基本的に一度決めた金額から値段は下げないが、サービス利用者の増加や、新技術の活用など、我々が改善努力をすることによって、値下げを行うこともある」(研究会参加企業)とのことであった。

◆仮想化でシステム全体のライフサイクルの長期化を実現する
  システムを共同利用する際、サーバーを仮想化することができれば、ハードウェアのレイヤーと、それ以上のプラットフォーム、アプリケーションのレイヤーを切り離すことができる。これにより、ITのライフサイクル全体を長くしていくことが可能だ。研究会に参加していたある企業は、「仮想化を使う前までは、ハードウェアのサポート切れに対するプレッシャーが非常に大きかった」と述べている。「ハードウェアの変更に合わせてOSも、アプリケーションも変えなければならず、上位レイヤーのシステムのライフサイクルを短いものにしていた」(研究会参加企業)。しかし、仮想化導入後は、「ハードウェアだけは最新にし、古いOSは塩漬けにして使い続ける」ことができる。

このように、研究会に参加していた多くの企業が、コスト削減やリソースの有効活用だけではなく、システムライフサイクルの長期化を仮想化によるシステム統合の非常に大きなメリットであると考えていた。

◆今後のクラウド技術の動向
 今回の研究会では、TIS 田淵氏から、2009年11月に開催されたアメリカのCloud Computing Conference&Expoの報告を通して、アメリカでのクラウド技術の最新動向について、情報の提供がなされた。「アメリカのCloud Computing Conference&Expoでは、パブリッククラウドの話はほとんどなく、8割は企業内クラウドの今後の発展の仕方についての議論でした。今後はIaaSではなく、PaaSの話が中心になると考えられますが、OSやハードウェアからいかに切り離したアプリケーションをこれから整備いくのか。アプリケーション・エンジニアは企業内クラウドをいかに意識してアプリケーションをつくっていくか。ここの議論が一番盛り上がっていました。」(TIS 田淵氏)

「PaaSについても、ミドルウェアや開発フレームワークのテンプレートを、インターネットを通じて自由に使えることがその目的ではなく、たとえば、テンプレートをエンジニアがダウンロードして開発し、そこで作ったフレームワークや、OSイメージをシェアリングする機能の提供など、アプリケーション開発エンジニアが、効率的にアプリケーションを開発できるための環境としてのクラウド、という考え方が議論されていました。」(TIS 田淵氏)

田淵氏によれば、ソフトウェアベンダーにも、「これまでのスクラッチのサービスではなく、クラウド、仮想化に対応できる製品にすべて切り替えていくという動きが見られる」とのことであった。「複数のクラウド環境を組み合わせて使うようなプライベートクラウドや、パブリッククラウドを使おうとすれば、企業のシングルサインオンや認証等について、技術的にまだまだ未成熟である部分がある。このため、特にソフトウェアベンダーはこの点について、製品開発にかなり投資をしている様子であった」(TIS 田淵氏)。

本研究会では、”次世代の”という時間軸でIT基盤の整備を考えるうえで、「クラウド」というのが重要なキーワードになっていた。「クラウド」という言葉は技術を表す言葉だが、一般的には、「ITのサービス利用」という、サービスの視点でとらえられることが多く、しかも「パブリッククラウド」をイメージすることが多いようだ。

本研究会でも、これまで「クラウド」の技術論が「パブリックプラウド」をベースに論じられてきたが、今回の研究会では、「ITのシェアードサービス化を実現するための技術」としての「クラウド」という側面が見えてきた。

今後も本研究会では、サービス、技術、両方の視点から、特に「クラウド」という言葉には捉われずに、IT基盤の再整備に必要な技術や仕組みについて最新の動向や事例の共有を行っていきたい。

(文責:株式会社ナレッジサイン 森 天都平)
 
TISが提供する各種ソリューション
●クラウド対応に向けてのITインフラ最適化サービス「IT@VSOP」

お気軽にお問い合わせください。TEL 03-3555-6901受付時間 9:30~18:30(土・日・祝日除く)

メールでお問い合わせはこちら

このエントリーを含むはてなブックマーク Buzzurlにブックマーク livedoorクリップ Yahoo!ブックマークに登録

このページの先頭へ