「プライベートクラウド」の旗印の下、全社のインフラの統合、標準化が進む。一方で、アプリチームは「自前サーバー」構築の隙をうかがう。インフラチームとアプリチームの役割の明確化が不可欠だ。プライベートクラウド構築の第一歩を、実際の取り組みから紹介する。

 仮想化技術の成熟に伴い、プライベートクラウドは企業にとって現実的な選択肢の一つとなりつつある。従来に比べると比較的容易にインフラを統合できるようになったわけだ。

 とはいえ、会社やグループ企業の標準インフラとして確立・活用するためには、数え切れないほどの障壁がある。プライベートクラウドの導入に踏み切れない、着手したものの運用合理化やコスト削減といった当初の狙いを実現できていないなど、まだ多くの企業で懸念や苦労があるだろう。

 本連載では、プライベートクラウドを構築する上で気をつけるべきポイント、長期にわたりうまく使いこなすための運用方法などを、当社(パナソニック インフォメーションシステムズ)の具体的な事例を踏まえて解説する。

 全6回にわたり、当社が行ってきたサーバー統合、データベース統合、ネットワークの再構築、プライベートクラウド稼働後の運用体制整備といった取り組みを紹介する(図1)。本連載が、効果的なインフラ統合のあり方を考える一助となれば幸いである。

図1 本連載の予定
図1 本連載の予定
[画像のクリックで拡大表示]

まずは役割分担を見直す

 第1回、第2回では、多くの企業にとってプライベートクラウド構築の起点となるであろうサーバー統合を中心に話を進める。今回は、まず「組織のあり方」に焦点を当てたい。ポイントは「組織が無統制なまま行ったインフラ統合は意味を成さない」ということだ。

 企業のIT組織はITインフラの構築・運用を担うインフラチームと、アプリケーションの開発・保守を担うアプリチームに二分されているケースが一般的である。システムの構築・運用に当たっては、サーバーやストレージといった機器やOSの調達、バージョン管理、パッチ管理などの業務が必ず生じる。こうした業務に対して、インフラチームとアプリチーム、どちらが担当するかを全社統一ルールで事前に役割分担しておく必要がある。これをおざなりにしたままでは、いくらインフラを仮想化し「統合基盤」を作り上げたとしても、いずれまたアプリチームが独自にサーバーを立ち上げてしまう恐れがあるからだ。

当社のインフラはこんな形

 自己紹介も兼ねて、当社のインフラ構築・運用体制について簡単に説明したい。

 当社はパナソニックの情報システム子会社として、主にエコソリューションズ社(以下、ES社)の生産管理・受発注・物流といった基幹業務を含む多くの業務システムの開発・運用を手掛けている。また、こうした経験を通じて得た技術とノウハウを生かし、パナソニックグループ外の企業に対してもサービスを提供している。

 当社の組織はアプリケーションを担当する部門とインフラを担当する部門とに分かれている。パナソニックグループをはじめとする顧客は、当社アプリチームの開発したシステムをサービスとして利用する。アプリチームが必要とするシステム基盤は、インフラチームがPaaS(プラットフォーム・アズ・ア・サービス)として提供するという構図である(図2)。このように、当社はアプリケーションの設計・開発から、その実行基盤の構築・運用までを担っている。

図2 アプリチームに対し、インフラチームがPaaSを提供
図2 アプリチームに対し、インフラチームがPaaSを提供
[画像のクリックで拡大表示]

アプリチームにPaaSを提供

 アプリとシステム基盤を分離し、PaaSを提供することで、全社最適な標準インフラにアプリ開発を合わせていくことが可能となる。また、この形態を取ることで、運用をシンプルにし、かつ集約したリソースを有効活用できる。その結果、TCO削減と運用品質の向上を実現しているのだ。

 PaaSを提供する大まかな流れはこうだ。

(1)インフラチームの窓口担当者が、アプリチームからインフラの利用申請を受け付ける。
(2)インフラチームの運用担当者とアプリチームのシステム担当者が集まり、どの程度のリソースが必要か、システム要件に合わせたサイジングを行う。
(3)インフラチームからアプリチームへ見積もりを提示し、正式に注文を受ける。
(4)インフラを提供する。

 システム構成はシステムの規模に応じて「松・竹・梅1・梅2」と4段階のサービスメニューを用意している。ただし、そこからアプリチームに自由に選ばせることはせず、必ず(2)のサイジングを実施することにしている。というのも、アプリチームは開発予算がかさむことを気にするあまり、安価で能力不足のインフラを選ぼうとしがちだからだ。サービスメニューをベースに話し合い、必要があればカスタマイズも行うことで、システム要件に応じた適正なインフラを提供できている。

 またメニューがあることで、アプリチームは「あのアプリが竹レベルだから今回も同等のインフラが必要だろう」とイメージしやすくなっているようだ。インフラの提供に際して、基本的には即時性よりも機能性を重視しているが、トラブル時などは即日に数十台のサーバーを立ち上げ、提供した経験もある。

 インフラにはミドルウエア層を含み、アプリ実行基盤まで整備してある。アプリチームはプラットフォーム構成に関して一切考える必要がなく、決められた方式にのっとって業務ロジックを実装する。全てのAPサーバーを「OS+Apache+Tomcat+アプリ実行基盤」という同一の構成で統一しているため、アプリケーション開発のための環境は、Javaの一つのプロセスとして立ち上がるイメージだ。

 実は今の形を目指してインフラ統合に着手したのは、クラウドという言葉もない2000年代の初めの頃である。当時を振り返ってみると、現在で言うところのプライベートクラウド構築を進めていたということになる。ファーストステップとして見直したのが、今回のポイントとして挙げた「組織のあり方」だった。統合前の悲惨な状況から順を追って紹介していく。

単なる「場所屋」を卒業する

 遡ること十数年前、筆者が所属するインフラチームはオープンシステムに関しては「場所屋」に甘んじていた。当時、オープンシステムの構築はアプリチームが主導しており、それぞれのプロジェクトで個別に機器を調達していた。当時のインフラチームの役割は、データセンターの提供と、システム監視程度のサービス提供に限られており、いわば場所屋である。アプリチームが、アプリを開発する傍ら、システム運用も行うという状況だった。

 そうした限定的な役割でありながら、インフラチームの苦悩は数知れなかった。サーバー障害が頻発し、休日や深夜お構いなく、会社に呼び出される。アプリでエラーが発生しアプリチームのサーバー管理者に連絡すると「もう担当じゃない」と返事が返ってくることもある。バックアップやシステム監視、スケジュール管理方法がバラバラで、有効に働いていないことも問題だった。

 アプリチーム主導による、個別の機器調達やシステム構成、運用方法がインフラチームの作業負荷を増大させていた。また、個別の環境ではシステムごとに余裕を持たせたリソースを確保しなければならず、過剰な構成で運用コストも上昇する一方だった。

 筆者たちはこうした状況から脱却すべく、インフラの全社的な統制管理に着手しようと考えたのである。乱暴な言い方かもしれないが、まず実施すべきは他でもない、アプリチームからインフラを取り戻すことだった。

どこまでインフラチームが持つか

 「アプリチームからインフラを取り戻す」。これは言い換えると、これまで個別に行われていたインフラの設計・構築・運用をインフラチームの下で統合し、全社最適化を図るということだった。

 メインフレームに関しては、私たちはミドルウエアのレベルまで完全統制を実現していた。これは、メインフレームは1台が数億円以上と非常に高価であり、アプリチームが個別に調達できる代物ではなかったからである。こうしたメインフレームの世界におけるインフラチームとアプリチームの役割関係を、オープンシステムにも展開しようと考えたのだ。

 では、システムを構成するレイヤーのどこまでを統合するか。私たちは検討の結果、メインフレームと同様に、ハードウエアからOS、ミドルウエアまでのレイヤーを統合することに決めた。インフラの手配、構築、保守を一元化し、PaaSとしてアプリチームへ提供しようと考えたのである(図3)。

図3 アプリチームとインフラチームの役割を再定義
図3 アプリチームとインフラチームの役割を再定義
[画像のクリックで拡大表示]

 その方針に基づいて、アプリチームとインフラチームの役割を次のように分担した。

【アプリチーム】

・アプリケーション開発標準の策定
・ユーザーニーズの分析
・要件定義に基づくシステムの企画設計
・アプリケーション開発・保守
・ユーザーサポート

【インフラチーム】

・インフラ全体方針の策定
・インフラ設計・機器選定・構築
・監視・障害対応・バックアップ
・リソース管理
・バージョン管理・パッチ管理

IT戦略部門とタッグ

 インフラチームは「インフラを標準化してPaaSとして提供」、アプリチームは「PaaSの上でアプリを開発する」。こう役割分担を決めたものの、アプリチームがそれを受け入れたかというと、当初は反発された。

 アプリチームは、インフラ運用をアプリ開発の片手間で行ってきた。そのため、運用に費用を割くという考えがなく、PaaSは「価格が高い」と猛反発を受けた。当時アプリチームは、あるメーカー1社に機器調達とアプリ開発をまとめて発注することで費用のディスカウントを図っていた。PaaSによりこうした慣習が崩れてしまうことも、アプリチームが首を縦に振らない理由の一つだった。

 これに対して筆者たちは、「インフラ品質の全社的な向上」や「セキュリティ監査対応の重要性」などを主張した。しかし、アプリチームにとって、それらは切羽詰った問題ではなく、「お金がない」の一点張りが続いた。

 そこで、システムオーナーである親会社のIT戦略部門の協力を仰いだ。その当時、IT戦略部門では基幹システムの刷新計画が持ち上がっており、これを絶好の機会と捉えたのだ。「インフラ品質の向上はシステムの信頼性向上に必要な過程」との理解を得られ、新しい基幹システムからインフラ統合の第一歩を踏み出すということで十分な予算を割いてもらった。また、IT戦略部門からもアプリチームへ統合インフラの利用を呼びかけてもらった。

 もちろんこれだけで利用が進んだわけではないが、ともかくIT戦略部門との協力によって、私たちはようやくインフラ統合のスタート地点に立てたのである。さらなる展開へ向けた取り組みについては第2回で詳しく述べる。

*   *   *

 インフラ統合を進める前段として、まず組織統制に目を向ける重要性を述べてきた。

 インフラチームとアプリチーム、それぞれの役割を明確化することがインフラ統合への第一歩となる。プロジェクトを円滑に進めるには、部門間の距離が近いか、部門を越えて話し合える職場風土があるかといったソフト面もチェックすべきポイントだ。当社においても最初から立派な組織体制があったわけではない。サーバー統合チームは当初筆者一人であった。重要なのは小さな一歩でも構わないので、ぶれない方針を持つことである。

 またIT部門とユーザー部門の関係を考えたとき、IT投資の決裁権限はある程度IT部門が掌握できていることが望ましい。IT部門が自ら投資リスクを負いつつユーザー部門へSaaSを提供する形にすれば、機器選定に関するユーザー部門との個別調整や決裁手続きが不要になる。その結果、インフラ統合のスピードを向上し、統合後もITトレンドに合わせた素早いシステム更改が可能になる。

八木 洋至(やぎ・ひろし)氏
パナソニック インフォメーションシステムズ
サービスビジネス本部 IDCサービス事業部
2001年入社。メインフレーム担当としてオープン系システムとの連携整備・一体運用化に従事する。2004年より全社標準基盤策定、プライベートクラウドの企画・構築・展開・運用およびオンプレミス・クラウドの外販を担当し現在に至る。愛車を眺めるのが休日の楽しみ。