ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソフトウェア
  3. WebOTX
  4. コラム/特集
  5. 開発者が語る
  6. クラウド構築の課題に対するサービス実行基盤の機能 ―運用効率―
ここから本文です。

WebOTX開発者が語る「クラウド構築の課題に対するサービス実行基盤の機能 ―運用効率―」

初期投資の不要なクラウドコンピューティングが大きな注目を集めています。クラウド環境においても、業務システムを稼働させるインフラに求められる要件は本質的に変わりません。WebOTXは、業務システムを稼働させる実行基盤として10年以上の実績があり、その特長である高信頼性、高い運用効率や柔軟性が高く評価されています。こうした実績を背景に、WebOTX開発者はクラウド構築において求められている、より高い信頼性、リソースならびに運用管理コストの最小化などを目指して新たな機能開発を行っています。

第2回は、WebOTX最新バージョンの機能を含め、運用効率にかかわるクラウドへの取り組みを紹介します。

【第2回】クラウド構築の課題に対するサービス実行基盤の機能 ―運用効率―

NEC 第三ITソフトウェア事業部主任
高橋 真志

NEC 第三ITソフトウェア事業部主任
岡田 好大

クラウド環境を支えるサービス実行基盤として、運用効率の観点ではどのような機能が求められるのでしょうか。

クラウド環境における業務システムでは、複数台からなるサーバを用いて負荷分散環境を構築することが多く、そこには同じ構成を持つ複数のアプリケーションサーバが存在します。

システム構築フェーズでは、各々のアプリケーションサーバに対して、アプリケーションの配備や実行環境に対するパラメータ設定作業を行わなければなりません。並列配置されるアプリケーションサーバが数台程度であればシステム構築者が直接作業することで済みますが、クラウドでは、数十~数百台も同じアプリケーションサーバを並列配置するため、システム構築者がこれら一つ一つに対して作業を行っていくのでは膨大なコストがかかります。この場合、仮想化ソフトを用いて、構築した実行環境のイメージを複製したものを使用したり、独自に作業バッチやスクリプトを作成したりと、さまざまな対応が検討されていますが、そのコストは決して安価ではありません。

同様に、システムの運用・保守フェーズにおいても、アプリケーションサーバに配備したアプリケーションの更新や、パラメータの変更作業がともないます。この時も、各々のアプリケーションサーバに同じ運用操作を行います。また、特定のサービスやアプリケーションの死活監視などの作業を追加で行うこともあり、この場合もアプリケーションサーバの台数分操作を繰り返すことになります。

このようにクラウド環境における業務システムでは、構築者や運用・保守担当者にとって負担が大きく、限られた要員では無理が生じます。そこで、このような大規模なシステムを効率よく構築、運用できる機能や仕組みが求められていると考えています。事実、社内外からのお客様やSEからも問い合わせや相談を受けることが多くなっています。

では大規模システムを効率よく構築、運用するために、WebOTXではどのような機能を備えているのでしょうか。

前述した課題を根本的に解決するため、8.3ではクラウド環境での利用を想定したさまざまな機能を有する運用管理基盤を「分散管理サーバ」と称し「WebOTX Cluster」の新機能として提供しました。

この運用基盤を簡単に説明すると、グルーピングされた多数のアプリケーションサーバに対し、単一の窓口である「分散管理サーバ」を通して、一括して業務の配備・設定を行える機能です。どのような業務の配備・設定ができるかは、次に示した6つの機能となります。構築フェーズから運用・保守フェーズまでを網羅しています。

  1. 分散配置された実行環境(ドメイン)の仮想的管理
    複数のサーバに分散配置されたドメインからなるアプリケーションサーバ群をグルーピングする仕組み。運用者は、運用操作1回を行うことで、各ドメインのアプリケーションサーバに同じ処理が行えます。
  2. アプリケーションの分散配備
    グループに対して配備要求を行うだけで、各ドメインのアプリケーションサーバにアプリケーションを配備できます。
  3. 運用パラメータの一括設定
    対象グループに運用パラメータの設定を要求するだけで、同じ設定がグループに属する全てのアプリケーションサーバに反映できます。
  4. サーバ固有情報の再設定
    グループに新たなドメインを登録する際、サーバ固有のパラメータ情報を新たなサーバに適する情報で置換(再設定)ができます。
  5. サーバ間での設定差異検出
    各ドメインのアプリケーションサーバが持つパラメータ情報を管理し、万が一予期せぬ変更があった場合でも、それを検出し、運用者にイベントとして知らせます。
  6. 各サーバで発生したイベントの一元管理
    設定差異検出のほか、特定のサービスやアプリケーションなどの死活状態の変化に対するイベントなども全て受け取ります。運用者は、運用管理ツールから分散管理サーバに接続する接続するだけで、全てのドメインのアプリケーションサーバで発生したイベントを把握できます。

画像

分散管理サーバ

クラウド事業者やSEにとってどのようなメリットがあると考えていますか?また、製品を開発者としてオススメする点を教えてください。

クラウド環境の運用保守担当者にとっても、SEにとっても構築や運用・保守フェーズにおける作業量の削減が大きなメリットだと考えています。通常はアプリケーションサーバの数だけ必要だった作業と比べると一目瞭然です。分散管理サーバを活用することで台数を意識することなく、全てのサーバ設定を一括で実施できるので作業者の負担を大幅に削減できます。

開発者としてオススメしたいのは「サーバ固有情報を再設定」できる点です。仮想化ソフトウェアを用いて実行環境のイメージを複製することで簡単にサーバ追加を行うことができますが、それでもサーバ固有の情報をアプリケーションサーバに設定しなおすという作業は残ってしまいます。こうした場合においても分散管理サーバはサーバ固有の情報を新たなアプリケーションサーバに簡単に再設定できるため作業者の負担を軽減できます。

開発に際し苦労した点、機能に込めた想いなど、エピソードがあればお聞かせください。

「分散管理サーバ」の機能は、全て新機能であり、Javaの仕様に則って開発するのと異なり、全くのオリジナルです。クラウドコンピューティングにおける運用を意識し、システム構築担当者や運用・保守担当者にメリットがあるようにと考え、1年半前から調査・検討し、必要な機能を吟味して製品に反映したのですが、参考資料もなく、1から設計・実装を行いました。これまでの開発の延長でないため、試行錯誤の連続でしたが、多くの開発メンバと数々の作業シナリオを想定しながら智恵を絞り、どうすれば利用者に最大のメリットを与えられるか、会議やレビューに時間を費やし、全体構成をどうするかで3~4ヵ月をかけて機能設計を行いました。

とりわけグルーピングの概念は、できるだけ今までと同じ操作感を実現し、しかもシンプルに見せたいということで取り入れたのですが、どういう粒度でグルーピングを実現するのか、グループ内に異なる製品Editionやバージョンの混在を許容するのか、あるいはグルーピングを分散配備や一括設定の機能とどのように連携させるかなど、活発な議論が交わされました。その結果、構築者から運用保守担当者まで、運用負担軽減に貢献できる機能として仕上がったと考えています。

新機能に対するお客様やSEの反応はいかがでしょうか?

実際にクラウド環境を想定したシステム構築における問い合わせや意見はこれまでも多く頂いています。中でも、200台以上構成のアプリケーションサーバに対し、設定や配備、監視を繰り返し作業するのは非常に手間がかかるという意見や、アプリケーションサーバ間で設定の差異を容易に確認する方法はないかといった構築・運用上の意見が多数寄せられました。そういった課題を感じているSEにはぜひご活用いただけると考えています。また、プレスリリースや外部サイトで取り上げられた際には、製品紹介ページへのアクセス数や資料ダウンロード数の増加や、問い合わせを受けるなど反響があり、やはりこのような機能に対する関心の高さを実感しています。

インタビューの様子

今後の機能強化について、クラウドのサービス実行基盤としてどのような機能を開発し、評価を高めたいと考えていますか?

現状では仮想化ソフトウェアの仮想イメージなどを用いなければ、一度作成したアプリケーションサーバ環境を他のサーバに複製して使用するのは困難です。システムによっては、仮想化ソフトウェアを使用できないケースもあります。そこで、作成したマスタとなる環境から、容易に新たなアプリケーションサーバを複製する機能開発などを検討しています。

また、何百、何千ものアプリケーションサーバを1人の運用担当者が管理することもあると聞いています。修正パッチモジュールを適用する場面を想定すると、どれほど人力を要するかは容易に想像できます。こうした課題を解決する機能も検討しています。

このように、今後も常にお客さま視点で必要となりそうな機能を調査し、ヒアリングさせていただきながら、さまざまなシナリオを想定し、より多くのお客さまに満足できる機能を持つ製品づくりを目指していきます。

(2010年9月24日)

WebOTX Application Serverをさらに詳しく知りたい場合はこちら

ページの先頭へ戻る