システム運用における、5つの大間違いとは（2）

クラウド化後も発生するシステム管理コスト

ここで1つの例として、冒頭に挙げた、とあるネット通販のシステムの例について、そのシステム構成（図1）を簡略化して見てみよう。

図1 とあるネット通販のシステム構成例

このシステム構成では、ファイアウォールを介して負荷分散装置とメールサーバーがあり、負荷分散装置の先に複数のWebサーバーとDBサーバーなどが接続されているという、ごく基本的な構成である。また、各サーバーの役割は、表2の通りである。

物理サーバーで構成していたこのシステムは、アクセスが集中するとレスポンスが悪化する問題があった。そこで、このネット通販会社は既存システムに追加投資するのではなく、動的にサーバーを追加できるクラウド環境への移行を考えたのだ。

具体的には、もともとのシステムでは、物理的なWebサーバー環境はweb1からweb4までの4台に限られていた。このケースでネット通販会社が重視したのは、クラウドであればアクセスが増大するのに応じて5台目、6台目と、ほとんど手間をかけずに必要に応じてサーバーを増強できるという点だった。

しかし、そうした柔軟にシステム規模を増減させることができる環境を手にいれたとき、ある種の副作用が発生する。物理サーバーで運用してきたときの環境と比べると、クラウド環境での運用は変わることが多いのだ。その典型的なものとしては、「サーバー台数」「アプリケーション実装」「運用・監視」の3つがある。それぞれについて見ていこう。

サーバー台数

まずサーバー台数。動的に増減するようになるが、仮想環境のオーバーヘッドがあるため、クラウド環境では、物理サーバー環境よりも最低限必要な台数は多めになる。特に、物理サーバーでの運用時にサーバーのリソースに余裕がなかった場合には、クラウド移行時の最低台数は多めに用意することになる。

アプリケーション実装

アプリケーション実装では、サーバーの台数変化に追随させることが必要になる。例えば前出の図1のバッチ処理サーバーは、物理サーバー環境ではWebサーバーは4台という「決めうち」でよかった。しかし、クラウド環境では、Webサーバー台数が動的に変化するため、バッチの実行結果を反映させる処理などを、Webサーバーの台数に合わせられるような実装が求められる。

運用・監視

運用・監視も、アプリケーション実装と同様だ。サーバー台数の変化に追随した実装が必要になる。特に監視障害対応においては、その時点でサービス提供しているサーバーを確実に監視しなければならないことから、必然的に、監視の仕組みや障害対応のフローの見直しが必要となるのだ。したがって障害対応時には、現状のサービスを提供しているサーバーを特定するなどの、確認の手間が必要になる。

以上のようなことだけを見ても、クラウドへの移行で得られる利点がある反面、新たに発生するコストについてよく見極める必要があることがわかるだろう。従来型の設計システムをそのまま移行した場合、下手すると、運用におけるコスト増になることは十分にありうるのである。

仮想化やクラウドの利用が、システムに柔軟性を持たせ、新世代のシステム設計を助けてくれる仕組みであることには間違いない。しかし、その利点にのみ着目し、単純に従来の物理サーバーで構築してきたシステムをそのままクラウド環境に移すことは、大きな間違いだ。運用を含めたシステム全体の設計の見直しとセットになって初めて、仮想化やクラウドを生かすことができるのである。