【クラウド構築実践事例（前編）】導入のきっかけは「部品点を減らすこと」

エンタープライズハードウェア

注目記事

2011.8.22（月）21:51

　自社内にクラウド環境を構築し、それまで部署ごとに構築・運用されていた複数のシステムを仮想化によって集約することで、リソースおよび運用管理の効率化を図ろうとする「プライベートクラウド」の導入が加速している。

　RBB TODAY編集部の母体「株式会社イード」も、事業部ごとにそれぞれ独立したネットワークを構築していたために運用管理負荷が大きかったが、保守切れサーバが多数出たことを契機に、プライベートクラウドへの移行に着手。今年7月より「社内共通クラウド基盤」の運用を開始した。

　そこで今回は、弊社でクラウドを管理しているネットワーク事業部を紹介。クラウド導入事例として、前後編の2部構成で紹介する。前編は、移行の経緯や旧システムの課題、クラウド導入のポイントについてまとめる。

■クラウド化の経緯─イードの全ネットワークを3人で運用管理

　まず事業内容について紹介しておこう。イードは、マーケティングやコンサルティングを提供するリサーチ事業、「RBB TODAY」「Response」「INSIDE」「リセマム」などメディア事業、Webアプリケーションサービスやシステム開発・ネットワーク運用を行うシステム事業、ショップ運営ASPサービスを提供するWebサービス事業、携帯電話向けコンテンツを提供するfunboo事業、以上5つの事業を展開している。

　従来は、全社で約300台のサーバが稼動しており、事業部ごとに独立したネットワークを構築していた。そのため、ベンダーも統一しておらず、セキュリティや負荷分散、冗長化といった機能もネットワークごとに異なっていた。しかし全てのネットワークを運用管理するエンジニアは、たったの3人である。

　そんななか、昨年末の調査によって、リース切れ・保守切れが近い、またはすでに過ぎているサーバが約30台あり、リプレイス費用が膨大にかかることが判明。そこで、サーバ集約のためのクラウド化の検討に入った。

■クラウド化の目的─とにかく部品数を減らしたい！

　クラウド化の最大の目的ときっかけは、「部品数を減らすこと」であった。サーバの台数が多ければそれだけ部品数も多く、全体として故障する確率が上がる。サーバをデータセンターに収容しているため、サーバーを立ち上げたり、機器を持って行くなどハードウェア設置のたびにエンジニアがデータセンターに出向かなければならない。こうした負荷を減らすためにも、仮想化によって部品数を減らしたいと考えた。

　さらに今回の移行を機に、ネットワークを1つにまとめ、各サービスを安定的に提供するために冗長構成をとることにした。また、ネットワーク機器の選定にあたっては、IPv6対応製品を条件とした。各事業部の独立したネットワークの中には、IPv6に対応していない製品があり、IPv4アドレス枯渇により新規サービスの立ち上げ時等で影響が出る可能性が高いことが懸念されていたからだ。ネットワークを統合することでこうした二重三重の投資を回避することにもつながる。

■クラウド化のポイント─コスト削減とサービスの安定的な提供の実現へ

　クラウドへの移行は、リース切れ/保守切れとなる約30台の旧サーバを対象とし、残る約270台のサーバは、今後の保守切れや負荷状況等に応じて、順次クラウドへ移行していく。クラウドの構成については、かねてから取引のあった日商エレクトロニクス株式会社に提案を依頼。ポイントとなるのは、仮想システムと大型ストレージの導入、リンクアグリゲーションによるネットワークの冗長化だ。

（1）約30台を2＋1台の仮想システムに集約

　まず、約30台の旧サーバの集約だ。技術進歩により、旧サーバ（2004年製）と同価格帯の今のサーバをスペック比較すると、コア数はおよそ6倍、メモリとハードディスクのそれぞれ5倍と2倍にアップし、ベンチマークによるとおよそ18倍の性能差がある。しかし各サーバにそこまでの性能を要求しておらず、単純にリプレースすると17台分のサーバリソースが無駄になってしまう。そこで約30台を2台の仮想サーバに集約してこれらをマスター機とし、もう1台用意してスタンバイ機とした。

　これにより、面倒を見る部品数は一気に削減し、修理やファームウェアアップデート等にかかる現場の作業時間は、6分の1に削減される試算だ。残りの約270台も順次移行していくため、この削減効果は移行のたびに高くなっていく。

（2）3PARストレージで仮想システムを冗長化

　スタンバイ機を用意したのは、サーバ障害時は自動的にスタンバイ機でサービス継続できるよう、OSイメージをストレージに配置し、サーバを冗長化するためだ。この冗長化により、ハードウェア障害が発生してもサービスに影響を与えることがなくなり、また日中時間帯のメンテナンスも可能になる。

　ストレージには、HP社製「3PAR F400」を選定。3PARと言えば、昨年9月、DellとHPが白熱の買収合戦を繰り広げた末にHPが買収したことで話題となった米国のベンチャー企業だ。イードでは、「99.999％の稼働実績」「オンラインでの容量追加・障害パーツ交換・バージョンアップ」「専用チップによるシンプロビジョニング・高速I/O」といった特徴を高く評価した。

　特にシンプロビジョニング機能は、仮想化ボリュームにより、実際にディスク容量が必要になってからHDD拡張できるため、将来必要なディスク容量を導入初期に確保しなくてよくなり、先行投資を抑えることができる。また、イードでは仮想化システムにマイクロソフト社製「Hyper-V」の採用を決めていたが、同製品は、マイクロソフト社からHyper-Vによる仮想化パートナー製品として認証済みである点も考慮した。

（2）リンクアグリゲーションによりネットワークを冗長化

　事業部ごとに独立していたネットワークは1つに統合し、ファイアウォールとロードバランサをそれぞれたすき掛け構成にし、リンクアグリゲーションを使って冗長化した。

　ファイアウォールおよびコアスイッチには、ジュニパー社製「SRX240H」「EX4200」を選定。イードはこれまでもジュニパー製品を採用してきた経緯があり、使い慣れた「JUNOS」と呼ばれる同社の共通OSを使って簡単に操作できるメリットがある。しかし最大の決め手となったのは、バーチャルシャーシ技術による「リンクアグリゲーション」が可能であることだ。旧ネットワークの中には冗長化を「スパニングツリープロトコル（STP）」で構成していたものがあったが、ループによるネットワーク停止が発生していたため、クラウドではシンプルな構成で冗長化したいと考えていた。

　後編では、イードのネットワーク事業部の担当者にインタビューし、機器選定にあたって比較検討した他社製品の話や、導入後の効果など、現場の声を聞く。

《RBB TODAY》