WebSphereソフトウェアで構築するプライベート・クラウド

クラウド・コンピューティングの方向性と技術トレンドをご紹介し、IBM WebSphereソフトウェア製品群がこれらの技術トレンドにどのように対応しているかを解説します。プライベート・クラウドを構築するための基盤としてIBM WebSphereソフトウェアを採用する際の参考情報としてご活用下さい。

樽澤 広亨, 金融サービス, グローバル・テクノロジー・サービス, IBM  

樽澤 広亨の肖像樽澤 広亨
1997 年より Java の技術普及活動を始め、1998年より WebSphere Application Server の技術リーダーとして様々なシステム開発プロジェクトをリードする。2006年より2007年にかけて米国 IBM Raleigh 研究所にて先進的 Web 技術を研究する一方、ソフトウェア技術者として Project Zero の開発に携わる。



須江 信洋, WebSphereクライアント・テクニカル・プロフェッショナル, IBM

須江 信洋の肖像須江 信洋
外資系ソフトウェアベンダー等を経て2007年より日本アイ・ビー・エム勤務。ソフトウェア事業にてWebSphere関連製品のプリセールスを担当しつつ、これから「来そうな」技術をウォッチ している。最近はGroovyがお気に入り。



2011年 7月 28日 (初版 2009年 11月 06日)

注)本記事はIBMユーザー研究会掲載のコラム「威風堂々Engineer 」第2回および第3回の内容に加筆修正したものです。

クラウド・コンピューティングとは

クラウド・コンピューティングについては、多くのメディアで取り上げられ、様々な観点より議論されています。わかりにくいと言う人もいますが、それはクラウド・コンピューティングの持つ間口の広さと深さにあるのではないかと思います。
筆者の意見を言わせていただければ、クラウド・コンピューティングとは、ネットワークを介してサービスを利用する、ユースケース(使い方)だと思っています。今やインターネット上では、業務アプリケーションやオフィス・アプリケーション等のソフトウェア(SaaS)、アプリケーション開発・稼働環境等のプラットフォーム(PaaS)、そして仮想サーバー環境等IT基盤(IaaS)が公開されています。自前でハードウェアやソフトウェアを用意しなくても、手軽にメーラーやスケジューラーを使って仕事をし、Webアプリケーションをホスティングすることができます。「低コスト」、「スピード」、そして「簡単さ」が受けてユーザー数を増やし、「クラウド」と呼ばれる一大ブームに至ったと思います。
ここで、専らインターネットを介してサービスを利用するというエンド・ユーザーの視点に代えて、データ・センターの運用管理担当者の立場からクラウド・コンピューティング・ブームを考えてみましょう。クラウドの先には、クラウド・コンピューティング環境をホスティングするプロバイダーのデータ・センターがあります。従来型の1企業のデータ・センターとの違いは、「低コスト」、「スピード」、「簡単さ」を担保しつつ、膨大なインターネット・ユーザーからのリクエストに応えるという「スケーラビリティ」を実現している点です。彼らのノウハウを上手に適用すれば、各企業のデータ・センターにおいても、よりスマートに「低コスト」、「スピード」、「簡単さ」そして「スケーラビリティ」を実現できるかもしれません。このような、クラウド・コンピューティングの考え方を適用した企業内システムのあり様をプライベート・クラウド、あるいはエンタープライズ・プライベート・クラウドと呼びます。


プライベート・クラウドを実現するテクノロジー

プライベート・クラウドを実現するには何をすれば良いのでしょうか?その一つのヒントとして、クラウド・コンピューティングを支えるテクノロジーの方向性を、概観してみましょう。様々な事例や書籍を参照すると、クラウド・コンピューティングは、「集中」と「分散」という2つの相反する方向性を上手く融合し実装しながら、実現されてきたことがわかります。
「集中」とは、サーバーやストレージ等ITリソースを1つないしは数か所のデータ・センターに集中することです。工業製品を大量生産することで一個あたりの単価を抑えることはよく知られていますが、「集中」とはこのコンセプトをデータ・センター運営に適用し、ITの運用管理コストを下げることを目指しています。でも一体どうやってITの運用管理コストを下げるのでしょうか。それには、データ・センターを集中することに加えて、ITリソースの「仮想化」や「サーバー・プロビジョニング」が重要な役割を担います。
仮想化とは、ハードウェアやOS等ITリソースを抽象化することです。仮想化によって、1つしかないリソースを論理的に複数のリソースに見せたり、逆に複数の物理リソースを一つの論理リソースに見せたりすることが出来ます。一般にサーバーの平均稼働率は、10~20%と言われています。これは投資に見合う使い方とは言えません。しかし、ここで仮想化技術を導入してあげれば、一つのサーバー上で複数OSやアプリケーションを稼働させることで稼働率を上げることが可能になります。
サーバー・プロビジョニングとは、物理的なサーバー・ハードウェアにOS、ミドルウェア、そしてアプリケーション等を導入し、運用可能なサーバー環境を構築することです。手作業による環境構築は、高いスキルは必要ないが長時間要するという、いわば単純な労働集約型作業です。そこで、サーバー・プロビジョニングを自動化するソリューションに注目が集まっています。集中化された大量のサーバー群のセットアップに、自動化されたサーバー・プロビジョニング・ソリューションを適用すれば、劇的な作業工数低減に繋がることでしょう。
つまり、データ・センターを局所化してサーバー等ITリソースを集中し、仮想化によってサーバー群の稼働率を上げ、サーバー・プロビジョニングで環境構築工数を低減することで、スペース代・電気消費・人件費・ITリソース購入費用を抑え、IT運用管理コストを削減するのが「集中」という方向性です。
一方「分散」とは、多数の安価なサーバーに処理を分散することで、コストを抑えつつスケーラビリティを保つことです。スケーラビリティを実装するには2つの手法があります。1つは複数の物理的サーバーによる分散処理の形態を取るスケール・アウト(水平スケーラビリティ)、もう一つの手法が機能増強されたサーバー1台で増大する処理量を賄うスケール・アップ(垂直スケーラビリティ)になります。昨今の動向としては、スケール・アウトによるスケーラビリティが注目されています。サーバー1台当たりの単価が安い上に、増設台数に応じてパフォーマンスがリニアに向上するため、投資対効果に優れいるといというのが、スケール・アウト人気の理由です。
スケール・アウトの適用領域として一般的なのは、WebSphere Application Server(WAS)等アプリケーション・サーバー層です。セッション情報等、複数のサーバー間での共有情報の連携方法が整備されており、多くの実績があります。


データ層のスケール・アウト

一方、スケール・アウトが難しい領域として考えられてきたのが、DBに代表されるデータ層です。分散配置されたサーバーにデータを格納する場合、データの整合性を担保することが難しい、というのがその理由です。ということで従来DBサーバーはスケール・アップの手法を取ってきました。とは言え、スケール・アップはより大きな投資が必要となりますし、スケール・アウトされたアプリケーション・サーバー群からの大量のリクエストを受け止めるデータ層がスケール出来ず、ボトルネックとなる可能性もあります (図1)。そこでデータ層のスケール・アウトに注目が集まっています。

図1. n層システムにおけるWebアプリケーションのスケール・アウト
図1. n層システムにおけるWebアプリケーションのスケール・アウト

データ層のスケール・アウト戦略として図2に挙げた3つの方法が考えられます。表や列単位で分割し、各サーバーに配置するのは、言い換えればそれぞれ分散RDB、正規化されたRDBにあたります。これらの方法では、特定の表や列にアクセスが集中し、即ち特定のサーバーにのみ負荷がかかる可能性があります。ACIDトランザクションによるロックも含め、十分なパフォーマンスを得られない危険性があるのです。その一方で最近注目が集まっているのは、キー:バリュー形式の分散キャッシュです。1サーバーは、ある一定範囲のキー値を持つレコードをキャッシュします。つまり行単位に分割するわけです。またキーとして、アプリケーション・データの代わりにハッシュ値を使用します。これによって、確率論的に特定のサーバーに処理が集中することを防ぐことができます。

図2. データ層のスケール・アウト戦略
図2. データ層のスケール・アウト戦略

パフォーマンスやアクセス平準化が得られるとしても、分散キャッシュではいかにしてデータの整合性を保つのでしょうか。分散キャッシュ上でACIDトランザクションを実現するのでしょうか。このような問いにヒントを与えてくれるのが、CAP定理(図3)とBASE(図4)に基づいたEventual Consistency(結果整合性)の考え方です。

図3. CAP定理
図3. CAP定理

CAP定理とは、図に挙げた3つの要件のうち同時に満足できるのは2つである、という考え方でUC BerkeleyのBrewer博士が発表したものです。「Tolerance to network Partition (P)」は意訳すると分散処理可能性とでもなるでしょうか。分散処理前提のスケール・アウトではPは必須です。クラウドという文脈でAvailability(可用性)も重要なので、これも重視しましょう。となると、やはりデータの一貫性(Consistency)を如何に担保するかが課題として残ります。従来ですと、ACIDトランザクションを使用するところですが、排他ロックによって可用性が損なわれるため、なるべく避けたいところです。

図4. CAP定理
図4. CAP定理

BASEとは、図4に挙げた属性の頭文字を取ったもので、データ整合性にかかる一つの方針を示したものです。要するに、処理の途中の一時点ではデータの不整合はあるかもしれないが、最終的には一貫性を取れればよいとする、緩いトランザクションのスタイルを特徴づけるものです。ACIDトランザクションに見られるような、時間と場所を超越した厳密な一貫性はありませんが、ショッピング・カートに商品を入れるような、それほど厳密な一貫性を求められない要件には、BASEに基づいた緩い処理で良いだろう、という主張です。振り返ってみれば、私たちがWebを使ってショッピングをする際、多くの時間は商品を検索したり説明をみたり、あるいはショッピング・カート内の商品を入れたり出したりという、それほど厳密さを要さない処理に費やされています。一方で、ACIDトランザクションを要するのは、ショッピング・カート内の商品を購入するタイミングだけなのです。つまり、リクエスト数が膨大な読み込み処理は、BASEに基づいた緩いスタイルで分散キャッシュを用いつつ、リクエスト数が相対的に少ない更新系の処理は、従来のACIDトランザクションでDBにアクセスする、というBASEとACIDの適材適所の使い分けによって、スケール・アウトによるデータ整合性とスケーラビリティが両立できそうです。


クラウド・コンピューティングとWebSphereソフトウェア

ここまで、クラウド・コンピューティングの方向性として集中と分散がある、そして技術トレンドとして、仮想化、プロビジョニング、アプリケーション・サーバー層とデータ層のスケール・アウトがあることをご紹介してきました。
IBM WebSphereソフトウェアはこれらの技術トレンドに沿ってミドルウェア製品を展開しています(図5)。ここでは、各製品の概要をご紹介したいと思います。

図5. クラウド・コンピューティング技術トレンドとWebSphere Software
図5. クラウド・コンピューティング技術トレンドとWebSphere Software

仮想化環境に対応したWAS: WebSphere HyperVisor Edition(WAS HV)

仮想化技術を利用することで様々なメリットが享受できることを説明してきましたが、実際にWebSphere Application Server(WAS)を仮想化環境で利用することを考えると、初期セットアップとして以下の事前準備が必要になります。

  • 仮想マシン上へのOSの導入、OSへのFix適用、OSのコンフィグレーション(カーネルパラメータなど)
  • 仮想マシン上へのWASの導入、WASへのFix適用、WASの構成 (パラメーターやクラスター構成など)

これらの作業が完了した時点での仮想マシンイメージをファイルとして保存しておくことで、これ以降はイメージファイルを仮想化環境に配布するだけでWASの環境を構築することができるようになるのです。
WebSphere Application Server Hypervisor Edition (WAS HV)は、このような作業をスキップして直ちに使い始めることのできる、仮想化環境に対応した「ソフトウェア・アプライアンス」です。WAS HVの概要を以下に示します。

  • OS、WAS、IHS導入済みの仮想マシンイメージ
  • WAS ND(Network Deployment)相当の機能を提供
  • 後述のWebSphere Virtual Enterpriseと同等の自律的運用管理機能 (WAS HVのIntelligent Management Packの提供機能)
  • WASの稼働を前提としてOS等コンフィグレーション済み
  • VMwareおよびOpen Virtual Format(OVF)1.0 形式のイメージを提供

2011年7月現在、WAS HVに加えて、WebSphere MQ、WebSphere Message Broker、WebSphere Process Server、WebSphere Business Monitor、WebSphere Portal ServerおよびIBM Lotus Web Content Management、DB2のHypervisor Editionが提供されています。

図6. WAS HV 概要
図6. WAS HV 概要

プライベート・クラウドでPaaSを実現: IBM Workload Deployer Pattern

クラウド・コンピューティングのサービス・モデルの一つであるPlatform-as-a-Service (PaaS)は、アプリケーション稼働環境をサービスとして提供します。アプリケーション稼働環境の(おおまかな)設計・構築・運用はPaaSが行いますので、エンド・ユーザーは、必要に応じてクイックにアプリケーション稼働環境を準備して、本来の役割であるアプリケーションの開発やテスト、配置に集中することができます。
このようなPaaSを企業のデータ・センター内に構築するソフトウェア製品が、IBM Workload Deployer Patternです。
IBM Workload Deployer PatternはPaaSを構成するOSやミドルウェアの機能、そしてPaaS環境の自動運用機能を備えています。後述のIBM Workload Deployer (IWD)にプリロードされて出荷され、IWDのコンソールやコマンドの操作に応じて、プライベート・クラウドを構成するサーバーのハイパーバイザー(2011年7月時点でVMware ESXをサポート)上にPaaS環境を実現します。
IBM Workload Deployer Patternは、ワークロードと呼ばれるアプリケーションのタイプごとに提供されており、2011年7月現在、Webアプリケーション向けのIBM Workload Deployer Pattern for Web Applicationsと、DBアプリケーション向けのIBM Workload Deployer Pattern for DB2 Workgroup Server Editionが製品としてリリースされています。
IBM Workload Deployer Pattern for Web Applicationsを例に取れば、Webサーバー、JavaEE アプリケーション・サーバー、キャッシュ、プロキシー、LDAPディレクトリーといったWebアプリケーションの稼働に必要とされる、(従来個々のミドルウェアが提供してきた)機能を包含しています。IBM Workload Deployer Pattern環境におけるエンド・ユーザーの役割は、アプリケーション(warファイルや、DDL等を記述したSQLファイル等)を、後述のIBM Workload Deployer (IWD)にアップロードすること、そして幾つかのポリシーの設定を行うことです。ポリシーとは、PaaS環境の運用を制御するパラメーターで、例えばCPUの使用率や応答時間をトリガーとしてJavaEE アプリケーション・サーバー環境を自動的にスケーリング(クラスターの拡張あるいは縮退)させることが可能です。IWDとIBM Workload Deployer Patternは、ワークロード・パターン(アプリケーションのタイプ)、アップロードされたアプリケーション、そしてポリシーに応じて、最適なミドルウェア構成を作成して、外部サーバー上に配布し、その上でアプリケーションをサービスします。先述のスケーリング・ポリシーの設定に従って、アプリケーション稼働環境のスケーラビリティを調整するなど、ある程度の運用の自動化も実現します。
IBM Workload Deployer Pattern for Web ApplicationsとIBM Workload Deployer Pattern for DB2 Workgroup Server Editionは、組み合わせて使用することができます。つまり、IBM Workload Deployer PatternとIWDを使えば、エンド・ユーザーは、必要な時に最適なアプリケーション稼働環境を準備して、開発やテスト、あるいは本番運用に備え、その後の運用負荷をも大幅に軽減することができるのです。

図7. Workload Deployer Pattern for Web Applications
図7. Workload Deployer Pattern for Web Applications

フル・ライフサイクルに渡ってプライベート・クラウド運用を効率化: IBM Workload Deployer (IWD)

仮想化環境に対応したWAS HVを利用することで、仮想マシンイメージの作成は不要になります。しかし、実際の環境構築を行う際には、仮想マシンイメージに対して個別のコンフィグレーションが必要になるため、これだけでは十分とは言えません。例えば、仮想化環境でWASのクラスタを構築する場合を考えてみましょう。WAS HVのイメージを配布した後に、以下のような作業が必要になります。

  • WASの設定ファイル内に定義されている自ホスト名などを修正
  • WASのセルにメンバーとしてノードを追加
  • クラスタを作成
  • Webサーバー・プラグインの定義ファイル生成

また、IBM Workload Deployer Patternを用いてPaaS環境を構築することを考えてみましょう。IBM Workload Deployer Pattern自身が、PaaSを実現するソフトウェア・スタックを提供するといっても、それに加えて以下の作業が必要になります。

  • PaaSソフトウェア・スタックのサーバーへの導入
  • 運用監視のためのハードウェアとソフトウェアの調達と配置、構成

このようなソフトウェアの導入、構成、そして運用に至るフル・ライフサイクルに渡る作業は、IBM Workload Deployer (IWD)を利用することで大幅な省力化と自動化が可能になります。

IWDとは、一言で言うと「家電製品のような操作で、仮想化環境にワンタッチでアプリケーション稼働環境を構築し、運用してくれる魔法の箱」です。IWDは「ハードウェア・アプライアンス」ですので、セットアップは非常にシンプルであり、ハイパーバイザー導入済みのハードウェア(ブレード・サーバーなど)を登録すればすぐに使い始めることができます。また、IWDにはWAS HV等Hypervisor Edition製品やIBM Workload Deployer Patternがプリロードされており、ユーザーがWebブラウザーから指示を出すだけで仮想化環境にWASのサーバーやIBM Workload Deployer PatternによるPaaS環境等を構築することができます。
IWDが特に威力を発揮するのは、仮想化環境にWASのクラスタなど大規模な環境を構築する場合や、繰り返し何度も環境を構築する場合です。このような状況はテスト環境やメンテナンスのための環境が必要になった際によく発生するのではないでしょうか。IWDはサーバーのトポロジー情報(WAS HV等Hypervisor Edition製品の場合)やアプリケーションのタイプとポリシー設定(IBM Workload Deployer Patternの場合)を「パターン」として格納しており、ユーザーはパターンを選択するだけでクラスタなどの様々な構成をとるミドルウェア環境を構築することができます。また、パターンはカスタマイズが可能ですので、よく使う構成を登録しておいて再利用することも可能です。

図8. IBM Workload Deployer全体像
図8. IBM Workload Deployer全体像

APサーバー層の動的なスケール・アウト: WebSphere Virtual Enterprise(WVE)

既にご説明したとおり、ロードバランサー(IP splayer)などを利用してアプリケーション・サーバー層のスケール・アウト行うことは、一般的な手法として確立しています。しかし、ワークロード管理、特に変動性の高い負荷への対応とリソースの全体最適化の実現という観点ではまだまだ課題が多いのが現状ではないでしょうか。
従来は、アプリケーション単位でインフラを構築し、最大負荷を想定してアプリケーション・サーバーを用意する手法が一般的であり、例えばネットオークションなどのピーク性の高いアプリケーションの場合には通常時のリソース利用が非効率的であるという課題がありました。また、キャパシティを拡張する際には、人手でサーバーの増設やロードバランサー、アプリケーション・サーバーの設定変更などを行わなければならない場合が多く、運用面の負荷や、メンテナンス作業のためにサービス停止を伴うことも課題となっているのではないでしょうか。
WebSphere Virtual Enterprise(WVE)は、このような課題を根本から解決し、APサーバー層のキャパシティ管理を一段階上のレベルに引き上げる製品です。WVEを利用することで、Webインフラを以下のように再構築することが可能です。

  • 負荷特性の異なる複数アプリケーションを統合し、クラウド型の共有インフラに移行することでリソースの全体最適化を実現
  • 動的クラスタ機能により、キャパシティを動的かつ自動的に増減
  • リクエスト・コンテキスト適応型の負荷分散の実現: アプリケーション、ユーザー、URL、セッション、HTTPヘッダーなどを解釈してトランザクションを分類
  • ポリシー・ベースのサービスレベル管理の実現: レスポンスタイム目標を満たすように、自動的にリクエスト優先度やキャパシティを調整
  • 運用管理作業を軽減し、メンテナンス停止をゼロに
図9. WebSphere Virtual Enterprise (WVE) 概要

WVEはWAS以外のアプリケーション・サーバーにも適用可能ですので、Webインフラ全体を再構築することでより高い導入効果を得ることができます。


データ層の動的なスケール・アウト: WebSphere eXtreme Scale(WXS)

データ層のスケール・アウト戦略を実現するための手法としてキー:バリュー形式の分散キャッシュというアプローチをご紹介しました。
昨今、日本でもキー:バリュー形式の分散キャッシュに対する注目度が高まっており、mixiやGREEをはじめとした適用事例が増えつつあります。ある予測では、2013年までに主要な企業の20%で分散キャッシュ基盤を採用することになるとも言われています。
もちろん、企業システムにおいて分散キャッシュを利用する場合、メモリー上にあるデータの保全性やセキュリティーなど考慮しなければならない点がいくつかあります。WebSphere eXtreme Scale(WXS)はそのような要件を満たす、企業システムで利用可能な分散キャッシュ製品です。
WXSの特長を簡単にまとめると以下のようになります。

  1. 極めて高いスケーラビリティ
    スケーラビリティの阻害要因を徹底的に排除するアーキテクチャを採用しており、千ノードのオーダーまでリニアにスケール・アウトが可能です。
  2. セキュリティー
    SSLによるデータアクセスの暗号化や、JAASベースのセキュリティー機能を提供します。
  3. 参照系だけでなく更新系にも適用可能
    ポリシー・ベースのデータの冗長化機能とノード障害からの自己回復機能により、メモリー上のデータの信頼性を確保しています。また、ライト・ビハインド方式を利用することで、データの更新をメモリー上で完結させることにより、パフォーマンスの向上が実現できます。この場合、メモリー上の更新データは、非同期でデータベースなどの永続ストアに書き出すことができます。(前回のコラムでご紹介したBASEに相当)
  4. Map/Reduceエージェントによる処理のスケール・アウト
    データだけでなく、ロジック処理もスケール・アウトによる分散実行が可能です。
  5. 多様なAPI
    Map形式のAPIだけでなく、構造をもった複雑なJavaオブジェクトを扱うためのEntityManager APIが提供されています。また、Java以外のクライアントからアクセスするためにREST形式のAPIも追加されました。
  6. システム全体の可用性向上
    サービスを停止することなく動的にノードを追加することが可能になり、うまく活用することで可用性を向上させることができます。
図10. WebSphere eXtreme Scale(WXS) 概要
図10. WebSphere eXtreme Scale(WXS) 概要

WXSは非常にコンパクトな製品であり、JavaSEのみで動作可能です。製品版と同機能の評価版がダウンロードできます。インストールも簡単ですので、ぜひお試しください。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=442489
ArticleTitle=WebSphereソフトウェアで構築するプライベート・クラウド
publish-date=07282011