レベル: 初級 樽澤 広亨, ベータ・プログラム推進, テクニカル・セールス, SW事業, IBM
須江 信洋, WebSphereテクニカル・セールス, IBM
2009年 11月 06日 クラウド・コンピューティングの方向性と技術トレンドをご紹介し、IBM WebSphereソフトウェア製品群がこれらの技術トレンドにどのように対応しているかを解説します。プライベート・クラウドを構築するための基盤としてIBM WebSphereソフトウェアを採用する際の参考情報としてご活用下さい。
注）本記事は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アプリケーションのスケール・アウト
データ層のスケール・アウト戦略として図2に挙げた3つの方法が考えられます。表や列単位で分割し、各サーバーに配置するのは、言い換えればそれぞれ分散RDB、正規化されたRDBにあたります。これらの方法では、特定の表や列にアクセスが集中し、即ち特定のサーバーにのみ負荷がかかる可能性があります。ACIDトランザクションによるロックも含め、十分なパフォーマンスを得られない危険性があるのです。その一方で最近注目があつまっているのは、キー：バリュー形式の分散キャッシュです。1サーバーは、ある一定範囲のキー値を持つレコードをキャッシュします。つまり行単位に分割するわけです。またキーとして、アプリケーション・データの代わりにハッシュ値を使用します。これによって、確率論的に特定のサーバーに処理が集中することを防ぐことができます。
図 2. データ層のスケール・アウト戦略
パフォーマンスやアクセス平準化が得られるとしても、分散キャッシュではいかにしてデータの整合性を保つのでしょうか。分散キャッシュ上でACIDトランザクションを実現するのでしょうか。このような問いにヒントを与えてくれるのが、CAP定理(図3)とBASE(図4)に基づいたEventual Consistency(結果整合性)の考え方です。
図 3. CAP定理
CAP定理とは、図に挙げた3つの要件のうち同時に満足できるのは2つである、という考え方でUC BerkeleyのBrewer博士が発表したものです。「Tolerance to network Partition (P)」は意訳すると分散処理可能性とでもなるでしょうか。分散処理前提のスケール・アウトではPは必須です。クラウドという文脈でAvailability(可用性)も重要なので、これも重視しましょう。となると、やはりデータの一貫性(Consistency)を如何に担保するかが課題として残ります。従来ですと、ACIDトランザクションを使用するところですが、排他ロックによって可用性が損なわれるため、なるべく避けたいところです。
図 4. CAP定理
BASEとは、図4に挙げた属性の頭文字を取ったもので、データ整合性にかかる一つの方針を示したものです。要するに、処理の途中の一時点ではデータの不整合はあるかもしれないが、最終的には一貫性を取れればよいとする、緩いトランザクションのスタイルを特徴づけるものです。ACIDトランザクションに見られるような、時間と場所を超越した厳密な一貫性はありませんが、ショッピング・カートに商品を入れるような、それほど厳密な一貫性を求められない要件には、BASEに基づいた緩い処理で良いだろう、という主張です。振り返ってみれば、私たちがWebを使ってショッピングをする際、多くの時間は商品を検索したり説明をみたり、あるいはショッピング・カート内の商品を入れたり出したりという、それほど厳密さを要さない処理に費やされています。一方で、ACIDトランザクションを要するのは、ショッピング・カート内の商品を購入するタイミングだけなのです。つまり、リクエスト数が膨大な読み込み処理は、BASEに基づいた緩いスタイルで分散キャッシュを用いつつ、リクエスト数が相対的に少ない更新系の処理は、従来のACIDトランザクションでDBにアクセスする、というBASEとACIDの適材適所の使い分けによって、スケール・アウトによるデータ整合性とスケーラビリティが両立できそうです。
クラウド・コンピューティングとWebSphereソフトウェア
ここまで、クラウド・コンピューティングの方向性として集中と分散がある、そして技術トレンドとして、仮想化、プロビジョニング、アプリケーション・サーバー層とデータ層のスケール・アウトがあることをご紹介してきました。
IBM WebSphereソフトウェアはこれらの技術トレンドに沿ってミドルウェア製品を展開しています(図5)。ここでは、各製品の概要をご紹介したいと思います。
図 5. クラウド・コンピューティング技術トレンドとWebSphere Software
仮想化環境に対応したWAS: WebSphere HyperVisor Edition(WAS HV)
仮想化技術を利用することで様々なメリットが享受できることを説明してきましたが、実際にWebSphere Application Server(WAS)を仮想化環境で利用することを考えると、初期セットアップとして以下の事前準備が必要になります。
- 仮想マシン上へのOSの導入、OSへのFix適用、OSのコンフィグレーション(カーネルパラメータなど)
- 仮想マシン上へのWASの導入、WASへのFix適用
これらの作業が完了した時点での仮想マシンイメージをファイルとして保存しておくことで、これ以降はイメージファイルを仮想化環境に配布するだけでWASの環境を構築することができるようになるのです。
WAS HyperVisor Edition(HV)は、このような作業をスキップして直ちに使い始めることのできる、仮想化環境に対応した「ソフトウェア・アプライアンス」です。WAS HVの概要を以下に示します。
- OS、WAS、IHS導入済みの仮想マシンイメージ
- WAS ND(Network Deployment)相当の機能を提供
- WASの稼働を前提としてOS等コンフィグレーション済み
- VMwareおよびOpen Virtual Format(OVF)1.0 形式のイメージを提供
図 6. WAS HV(HyperVisor Edition) 概要
プロビジョニングを効率化: WebSphere CloudBurst Appliance(WCA)
仮想化環境に対応したWAS HVを利用することで、仮想マシンイメージの作成は不要になります。しかし、実際の環境構築を行う際には、仮想マシンイメージに対して個別のコンフィグレーションが必要になるため、これだけでは十分とは言えません。例えば、仮想化環境でWASのクラスタを構築する場合を考えてみましょう。WAS HVのイメージを配布した後に、以下のような作業が必要になります。
- WASの設定ファイル内に定義されている自ホスト名などを修正
- WASのセルにメンバーとしてノードを追加
- クラスタを作成
- Webサーバー・プラグインの定義ファイル生成
このようなWASに特有の「プロビジョニング」作業は、WebSphere CloudBurst Appliance(WCA)を利用することで大幅な省力化と自動化が可能になります。
WCAとは、一言で言うと「家電製品のような操作で、仮想化環境にワンタッチでWASの環境を構築してくれる魔法の箱」です。WCAは「ハードウェア・アプライアンス」ですので、セットアップは非常にシンプルであり、ハイパーバイザー導入済みのハードウェア(ブレード・サーバーなど)を登録すればすぐに使い始めることができます。また、WCAにはWAS HVが内蔵されており、ユーザーがWebブラウザーから指示を出すだけで仮想化環境にWASのサーバーを構築することができます。
WCAが特に威力を発揮するのは、仮想化環境にWASのクラスタなど大規模な環境を構築する場合や、繰り返し何度も環境を構築する場合です。このような状況はテスト環境やメンテナンスのための環境が必要になった際によく発生するのではないでしょうか。WCAはサーバーのトポロジー情報を「パターン」として格納しており、ユーザーはパターンを選択するだけでクラスタなどの様々な構成をとるWAS環境を構築することができます。また、パターンはカスタマイズが可能ですので、よく使うトポロジーを登録しておいて再利用することも可能です。
図 7. WCAによる企業内クラウドへのWebSphere環境構築
APサーバー層の動的なスケール・アウト: WebSphere Virtual Enterprise(WVE)
既にご説明したとおり、ロードバランサー(IP splayer)などを利用してアプリケーション・サーバー層のスケール・アウト行うことは、一般的な手法として確立しています。しかし、ワークロード管理、特に変動性の高い負荷への対応とリソースの全体最適化の実現という観点ではまだまだ課題が多いのが現状ではないでしょうか。
従来は、アプリケーション単位でインフラを構築し、最大負荷を想定してアプリケーション・サーバーを用意する手法が一般的であり、例えばネットオークションなどのピーク性の高いアプリケーションの場合には通常時のリソース利用が非効率的であるという課題がありました。また、キャパシティを拡張する際には、人手でサーバーの増設やロードバランサー、アプリケーション・サーバーの設定変更などを行わなければならない場合が多く、運用面の負荷や、メンテナンス作業のためにサービス停止を伴うことも課題となっているのではないでしょうか。
WebSphere Virtual Enterprise(WVE)は、このような課題を根本から解決し、APサーバー層のキャパシティ管理を一段階上のレベルに引き上げる製品です。WVEを利用することで、Webインフラを以下のように再構築することが可能です。
- 負荷特性の異なる複数アプリケーションを統合し、クラウド型の共有インフラに移行することでリソースの全体最適化を実現
- 動的クラスタ機能により、キャパシティを動的かつ自動的に増減
- リクエスト・コンテキスト適応型の負荷分散の実現: アプリケーション、ユーザー、URL、セッション、HTTPヘッダーなどを解釈してトランザクションを分類
- ポリシー・ベースのサービスレベル管理の実現: レスポンスタイム目標を満たすように、自動的にリクエスト優先度やキャパシティを調整
- 運用管理作業を軽減し、メンテナンス停止をゼロに
図 8. WebSphere Virtual Enterprise (WVE) 概要
拡大図
WVEはWAS以外のアプリケーション・サーバーにも適用可能ですので、Webインフラ全体を再構築することでより高い導入効果を得ることができます。
データ層の動的なスケール・アウト: WebSphere eXtreme Scale(WXS)
データ層のスケール・アウト戦略を実現するための手法としてキー：バリュー形式の分散キャッシュというアプローチをご紹介しました。
昨今、日本でもキー：バリュー形式の分散キャッシュに対する注目度が高まっており、mixiやGREEをはじめとした適用事例が増えつつあります。ある予測では、2013年までに主要な企業の20%で分散キャッシュ基盤を採用することになるとも言われています。
もちろん、企業システムにおいて分散キャッシュを利用する場合、メモリー上にあるデータの保全性やセキュリティーなど考慮しなければならない点がいくつかあります。WebSphere eXtreme Scale(WXS)はそのような要件を満たす、企業システムで利用可能な分散キャッシュ製品です。
WXSの特長を簡単にまとめると以下のようになります。
- 極めて高いスケーラビリティ
スケーラビリティの阻害要因を徹底的に排除するアーキテクチャを採用しており、千ノードのオーダーまでリニアにスケール・アウトが可能です。
- セキュリティー
SSLによるデータアクセスの暗号化や、JAASベースのセキュリティー機能を提供します。
- 参照系だけでなく更新系にも適用可能
ポリシー・ベースのデータの冗長化機能とノード障害からの自己回復機能により、メモリー上のデータの信頼性を確保しています。また、ライト・ビハインド方式を利用することで、データの更新をメモリー上で完結させることにより、パフォーマンスの向上が実現できます。この場合、メモリー上の更新データは、非同期でデータベースなどの永続ストアに書き出すことができます。(前回のコラムでご紹介したBASEに相当)
- Map/Reduceエージェントによる処理のスケール・アウト
データだけでなく、ロジック処理もスケール・アウトによる分散実行が可能です。
- 多様なAPI
Map形式のAPIだけでなく、構造をもった複雑なJavaオブジェクトを扱うためのEntityManager APIが提供されています。また、Java以外のクライアントからアクセスするためにREST形式のAPIも追加されました。
- システム全体の可用性向上
サービスを停止することなく動的にノードを追加することが可能になり、うまく活用することで可用性を向上させることができます。
図 9. WebSphere eXtreme Scale(WXS) 概要
WXSは非常にコンパクトな製品であり、JavaSEのみで動作可能です。製品版と同機能の評価版がダウンロードできます。インストールも簡単ですので、ぜひお試しください。
参考文献
著者について | | | 樽澤 広亨
1997 年より Java の技術普及活動を始め、1998年より WebSphere Application Server の技術リーダーとして様々なシステム開発プロジェクトをリードする。2006年より2007年にかけて米国 IBM Raleigh 研究所にて先進的 Web 技術を研究する一方、ソフトウェア技術者として Project Zero の開発に携わる。
|
| | | 須江 信洋, WebSphereテクニカル・セールス, IBM |
記事の評価
| 
