PR
Microsoft MVP for Windows Server System
カブドットコム証券
システム統括部 情報技術課 課長
谷口 有近氏

著者紹介
1977年生まれ。2000年東海大学教養学部卒業。同年某ソフトハウスに入社し,コミュニティの形成を目的としたWebアプリケーション・システムのリッチ・クライアント環境の開発に従事。2001年5月,カブドットコム証券に入社し現在に至る。Windows Server Systemの構築・設計・運用を中心に,ネットワークの設計・運用にも従事。いわゆる何でもやらされるタイプ。最近徹夜ができなくなったことに少なからずショックを受けている。
 

 私が所属するカブドットコム証券では,現在システムの増強ラッシュが続いています。11月8日には東京証券取引所第1部の売買出来高が,過去最高の45億5805万株を記録しました。その原動力はオンライン証券を利用する個人投資家であり,当社のユーザーや取引件数もうなぎ登りに増えています。

増強増強,また増強
 その結果,ある日突然,それまで190Mビット/秒程度だったインターネット接続回線の利用帯域が230Mビット/秒になったり,サーバーのCPU負荷率が2倍になったり——といったことが,いとも簡単に発生しています。負荷の推移が予想できれば楽なのですが,現実はそううまく行きません。突発的な事象,例えば大きな事故や同業他社の動向でもシステム負荷は大きく左右されます。利用者の操作傾向が変わるだけでもシステム負荷のバランスは影響を受けます。過剰投資はなるべく避けたいものですが,用意周到に準備したリソースの余裕を食い尽くすような事態が起きています。

 当社では12月末に実施する予定だったシステム増強計画を,1カ月半前倒しで実施しました。たった1カ月半と思われるかもしれませんが,増強する上では様々な困難がありました。

 まずはサーバー・ルームのスペースや電源,空調の確保です。当社のサーバーは電源やHDDを2重化しているだけでなく,最近の電力消費量の多いプロセッサを最低2個,アプリケーション・サーバーで8個は搭載しています。ピーク時の消費電力量はそれこそ業務用電子レンジ200台分にも及びます。電源や空調設備の増強が欠かせません。

 次にするのが,サーバー本体とネットワーク環境の準備です。サーバーは搭載プロセッサ数が増えるにつれて,納期が伸びる傾向にあります。小さいIAサーバーを連結させるグリッド・コンピューティング環境ならば,納期の短い安価な小型サーバーを大量に短期間に投入できるでしょう。しかし管理すべきOSのインスタンス(実体)が猛烈に増えるので,管理コストの増加につながりかねません。その一方,搭載CPU数の多いサーバーは管理の集約が容易ですが,納期が2カ月以上かかることがザラなので事前の計画が欠かせません。

 結局先月号のコラムで「200台超」と述べていた私たちが管理するサーバーの台数は,今月号では「220台超」に増えました。ここまでサーバー台数が増えてくると頭が痛いのが,サーバー・マシン上で稼働しているWindows OSのメンテナンスになります。

 少人数で多数のサーバーを管理するのは,普通に動作しているだけならそう難しくはありません。最近は管理ツールも充実していますし,WMI(Windows Management Instrumentation)による管理インターフェースもあるので,「パフォーマンス・カウンタで特定項目がいき値を超えた場合に,IIS(Internet Infomation Services)のプロセス・リサイクリングを強制的に実行する」といったメンテナンス・プログラムであれば1時間程度で作成できます。

 しかしながら,Windowsに修正パッチを適用する,アプリケーションの設定を変更する,といった作業は,安全性確保のためにサーバーごとに状態を確認しながら手作業で実施しているのが実情です。例えば「3件の修正パッチを適用し,アプリケーションの設定を変更してOSを再起動する。起動してからサーバーの状況を確認してオンライン(サービスを提供する状態にすること)にする」という手順を実施すると,1台当たり5~10分程度はかかります。複数台同時に作業するとしても,220台のサーバーを管理する上では,8~16時間程度の作業時間が必要になります。

 月に1回のペースでこの作業が発生するのであれば問題はありませんが,アプリケーションの設定変更が毎週発生する当社のような環境では,運用にかかる時間の短縮はとても重要です。人員計画にも影響を及ぼします。

 このような多サーバー環境における運用管理を簡略化するシナリオとして,「仮想マシン・ソフトを使って,大量のサーバーを巨大サーバーに集約する」という手法があります。しかし私は,このようなシナリオに魅力を感じません。

 まずサーバーを集約しても,メンテナンスすべきOSのインスタンス(実体)は残り続けます。サーバー・ハードウエアが仮想マシン・ソフトに変わっても,修正パッチを適用したり,アプリケーションの設定を変更したりといった作業は,サーバーOSのインスタンス(仮想ディスク・イメージ)分だけ必要です。

 また,ハードウエアは集約せず,運用上の最後の保険として,「いざとなったらサーバーのネットワークや電源を物理的に遮断する」という手段を残したいです。役に立つ場面がまだあるからです。

 もちろん,Windows Server 2003はWindows NTのころと比べると非常に安定しており,「トラブルが発生したらとにかくリブートする」「サーバーの安定稼働のためには定期的にリブートする」といった「リブート神話」は過去のものになったと思っています。それでも,「CPUの負荷率がずっと100%に張り付いたままで,タスク・マネージャすら表示できない」という経験をふまえると,最後の物理的手段を確保しておきたくなるのです。

管理は1つ,稼働サーバーは複数
 私にとっての「理想のインフラ」は,「メンテナンスすべきOSの実体は可能な限り少なく,それでいてたくさんのサーバーを運用できる」という環境です。OSは,アプリケーションを稼働させるための環境を提供する「サービス」に過ぎません。1つの「OSサービス」を複数のマシンで共用するという考え方です。

 理想に近い存在の1つに,アップルコンピュータがMac OS X環境で実現している「NetBoot」という機能があります。NetBootは,サーバー上にある1つのOSのイメージから,複数のマシンがブートするという仕組みです。メンテナンスすべきディスク・イメージはサーバーにある1つだけですが,クライアントは全く別のマシンとして動作可能です。

 実際には,NetBootのクライアントは,起動時にNetBootサーバーからFTP(ファイル転送プロトコル)でディスク・イメージを毎回ダウンロードし,ローカル・ディスクからマシンを起動しています。Windows Serverの「RIS(リモート・インストール・サービス)」を毎回実行しているようなものです。

 もしOSがブートする際に読み込むイメージが1つで,個別設定やアプリケーションも別個にロードできる構成であれば,管理すべき対象が減るとともに,システムの自由度も上げられます。サーバーはブート時に,自分の必要なサービス(OSも含む)やアプリケーション,設定だけを読み込むのです。

 OSをAPI(アプリケーション・プログラミング・インターフェース)のレベルで仮想化するのも,1つの実装方法だと考えます。OSがサービスに過ぎないと考えれば,アプリケーションが呼び出すAPIの先に存在するOSが実体を伴う必要もないからです。

 今後,コンピューティングの世界が高度化するにつれ,コンピュータの数は増え続けるでしょう。今回取り上げたような「仮想OSサービス」は,きっと必要になります。もし未来の世界でもシステム管理者が運用管理に苦しんでいたら——そう考えるとぞっとしますからね。


(日経Windowsプロ2005年12月号より)

 

Microsoft MVPとは…
 Microsoft MVP(Most Valuable Professional)とは,MS製品のユーザー会やメーリングリストなどでユーザーのサポートをしている人の中でも,特に貢献度が高いとMSが認定したプロフェッショナル。Windows ServerやSQL Serverなど部門ごとに認定されている。