目次


クラウドに接続する

第 1 回 アプリケーションにクラウドを活用する

ハイブリッド・モデルを利用する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: クラウドに接続する

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:クラウドに接続する

このシリーズの続きに乞うご期待。

はじめに

長年、ネットワーク図でインターネットを表す場合、雲 (細かく言うと、積雲) を使うのが慣例となっていました。雲 (クラウド) のイメージによって、形が定まらず、つかみどころがなく、それでもやはり図の中に含める必要がある何かを示していたのです。ネットワークを表す線はクラウドの中を通り抜けるだけであり、それはデータがインターネットを経由することを意味します。セキュリティーを表現した図の場合には、接続がセキュアであることを示すために、脇に南京錠が付いた雲 (クラウド) を線が貫通していたりもしました。

しかし今やクラウド (雲) は、ネットワーク図の中で第一級の役割を果たすものとなっています。アプリケーションは、クラウドを利用することで付加価値を付けることができます (例えばストレージ、キューイング、ホスト・アプリケーションなど)。アプリケーション自体をクラウドでホストすることもできます。ネットワーク図の線は、今や単純にクラウド (雲) を貫通するのではなく、クラウドに接続されており、アプリケーションの一部としてクラウドを利用しているのです。これにより、クラウドは実体を持つものになったのです。

この 3 回シリーズでは、クラウド・コンピューティングがどのようなものかを検証します。クラウド・コンピューティングのプロバイダーの数は比較的少ないですが、それぞれのプロバイダーが異なる分野から参入し、異なるサービスを提供しています。プログラミング言語の選択肢も、Python から C#、Java、あるいは他の独自言語に至るまで、さまざまに異なります。クラウドに対するインターフェースも多様です。軽量の REST インターフェースが望ましいのですが、今のところすべてのクラウド・コンピューティング・プロバイダーで REST が提供されているわけではありません。

ハイブリッド・モデル

このシリーズ第 1 回目の今回は、ハイブリッド型の例、つまりクラウド・コンピューティングのサービスとインフラを利用するプライベート・アプリケーションの例を取り上げます。このハイブリッド・アプリケーションを検証しながら、クラウド・コンピューティングによって何が提供されるのかを学びます。そのために、クラウド・コンピューティング以前はどうであったか、また主なクラウド・コンピューティング・プロバイダーが現在どんなサービスを提供しているかについて調べます。このシリーズの第 2 回では、第 1 回で設計したハイブリッド・アプリケーションを実際に作成します。第 3 回では、クラウドによるソリューションのセキュリティーとガバナンスの問題に焦点を当てます。

クラウド・コンピューティングとは一体何か

IBM が定義するクラウド・コンピューティングは、データとサービスが極めてスケーラブルなデータ・センターに置かれた新たなコンピューティング・パラダイムであり、インターネットに接続された機器であれば、どこからでも利用することができます。クラウド・コンピューティングによってアプリケーションは非常にスケーラブルになり、また (Amazon EC2 と呼ばれる Amazon Elastic Computing Cloud の場合には) アプリケーション自体をホストすることもできます。

クラウド・コンピューティングはすべての人に適しているというわけではありませんが、時間によってコンピューティング・ニーズが変動する組織にとっては特に魅力的です。ある組織のビジネスに必要な処理容量とストレージ容量が常に一定というわけではない場合 (例えば毎週土曜日の真夜中にバッチ処理が必要、など) には、ほとんどの時間、データ・センターを遊ばせておくよりも、クラウド・プロバイダーを使用した方が得策です。

またクラウド・コンピューティングは新興企業にも魅力的です。新興企業の設立者の多くは、ベンチャー・キャピタルの投資家から、「その技術はどのくらい柔軟にスケールアップやスケールダウンできるのか」というおなじみの質問をされたことがあるはずです。この質問に対して、クラウド・コンピューティングは説得力のある答えを提供します。しかしこのシリーズの今後の記事で説明するように、クラウド・コンピューティングは、所有権、セキュリティー、コストに関する問題も提起します。

クラウドの誕生

クラウド・コンピューティングが広く知られるようになる前には、グリッド・コンピューティングとユーティリティー・コンピューティングがありました。グリッド・コンピューティングとクラウド・コンピューティングとの間の大きな違いは、グリッド・コンピューティング環境が多様なマシンで構成されることが多いのに対し、クラウド・コンピューティング環境はグリッド・コンピューティング環境よりも細かく管理されている場合が多く、バックエンド・マシンは通常すべて同じです。ユーティリティー・コンピューティングはデータ・トラフィックまたはアプリケーションの使用量に応じて料金を支払うビジネス・モデルを指します。しかし弾力性を持ったサービスという概念はあまり一般的ではありませんでした。一方クラウド・コンピューティングでは、使用量の変化に応じて容量を追加 (あるいは削除) できるという機能が重要な部分となっています。

2000年から 2005年前後ぐらいにかけて、Google と Amazon がそれぞれ独立に、彼らのビジネスを実行する基礎となる独自のクラウド・コンピューティング・アーキテクチャーを開発しました。このインフラを開発すると、彼らは自分達自身のインフラがサービスそのものになることに気付きました。つまりそのインフラを、使用量に応じて開発者に販売することができるのです。特に Amazon は彼らのプラットフォームが持つ重要な価値を認識し、彼らがオンライン販売の Web サイトとして知られているのと同様に、彼らのコンピューティング・プラットフォームでも知られるようになることが十分に考えられると気付きました。Amazon はプラットフォームをサービスとして販売できることに気付いたのです (「プラットフォームをサービスとして」は Platform as a Service、略して PaaS と呼ばれます。これは Software as a Service を SaaS と略すのと同様です)。このように、クラウド・コンピューティングの商用化、特に課金モデルや使用モデルを考え出したという点で、Amazon はクラウド・コンピューティングの先頭を走っていると見なされています。

クラウド・ベースのコンピューティング環境の設計に関する専門技術は、Amazon や Google など、クラウド・コンピューティングで大成功を収めている少数のベンダーにばかり集約している傾向がありました。それを認識し、2007年に Google と IBM、そしていくつかの大学が研究用クラウドを構成しました。この研究用クラウドによって、研究室の学生にも、クラウド・コンピューティングに関する新たな手法やアプリケーションを開発するためのクラウド・コンピューティング環境が提供されました。この研究用クラウドは Amazon や Google のインフラと比較できるような規模ではありませんが、学生はこの環境を利用してクラウド・サービスを研究することができます。この研究用クラウドを利用した研究によって、クラウドを構成する手段を持つさまざまな組織によるプライベート・クラウドの開発など、クラウド・コンピューティングが一層発展することが期待されます。

ハイブリッド・モデルを利用する

ローカル・アプリケーションを捨て去ってクラウドのみを使用したり、あるいは逆にローカル・アプリケーションのみを使用してクラウドを無視したりするよりも、ローカル・アプリケーションとクラウドを組み合わせて使うことが賢明であることがわかってきています。これはハイブリッド・モデルと呼ばれます。ハイブリッド・モデルによって、企業は自社の重要なアプリケーションを制御できる一方、クラウド・コンピューティングを利用するのが適切な部分ではクラウド・コンピューティングを活用することができます。例えば多くの企業は、Amazon の S3 (Simple Storage Service) を使って画像や動画、文書などを保管することが経済的であることに気付いています。またハイブリッド・モデルはインクリメンタルな手法にも適しています。

大部分のアプリケーション、あるいはすべてのアプリケーションをクラウドに移行することが適切と思える場合であっても、すべてを一度に移行することは危険性が高いと思える場合があります。ハイブリッド・モデルを使用することによって、まず手軽なもの (例えばファイル・ストレージなど) をクラウドに移行するという選択が可能です。そしてこのデプロイメント・モデルに不安を感じなくなったら、アプリケーションの重要な部分をクラウドに移行することができます。このシリーズでも、この方法をとる予定です。では、このシリーズでとりあげるアプリケーションについて調べてみましょう。このアプリケーションのインフラの一部を後ほどクラウドに移行し、ハイブリッド・アプリケーションにします。

ハイブリッド・アプリケーションを設計する

ここで例として取り上げるハイブリッド・アプリケーションは非同期の E メール通知システムです。あるいは、ワークフロー・システムのサブシステムであってもかまいません。このシステムでは、新しいアクティビティーがサブミットされて承認が要求されると、適切な承認者に E メールが送信され、その承認者は、そのアクティビティーを承認または却下します。この種のシステムはフルフィルメント・システムにも使用することができます。つまり、ある注文品が出荷されると E メールが送信され、その注文品が配送中であることが通知されるといった具合です。このように、非同期の E メール通知システムはさまざまなタイプのアプリケーションで使用することができます。E メールは本質的に非同期であるため、E メールを生成する非同期メカニズムはここで挙げたようなシステムを実現する効率的な方法となります。

既にそうしたシステムを採用した既存のアプリケーションがどこかにあることは十分に考えられます。そうしたシステムの実装方法にはさまざまな方法がありますが、非常にスマートなメカニズムの 1 つとして JMS を使う方法があります。JMS 仕様は J2EE™ 技術スタックの重要な部分です。JMS 標準の実装には、独自のものやオープンソースのものなどが数多くあります。容易に想像できるシステムとして、JMS キューに通知を送信するシステムと、そのキューから定期的に読み取り、JMS キューの中にある各メッセージに対して E メール通知を生成する別のシステムを考えることができます。

ハイブリッド・モデルの場合には、まず JMS キューをクラウドに移すことから始めます。つまりクラウドの中で実行されるサービスで JMS キューを置き換えるのです。では、そのサービスとはどんなサービスなのでしょうか?そして、そのサービスとインターフェースを取るためにはアプリケーションをどのように変更する必要があるのでしょうか?こうした質問に対する答えはどのようなクラウド・プラットフォームを使用するかによって異なってきます。そこで次に、さまざまなプラットフォームについて見ていきましょう。そして JMS キューの機能を実装する (この場合には再実装する) ために、それらのプラットフォームをどのように使うのかを調べてみましょう。

Amazon Web サービス

クラウド・コンピューティングに課金することに成功したパイオニアとして、Amazon は開発者にとって関心のある成熟したサービスをいくつか提供しています。Amazon の提供するクラウド・サービスとして最も知られているのは EC2 (Elastic Computing Cloud) サービスでしょう。EC2 サービスを利用すると、Amazon 自身のインフラ上で実行される (AMI: Amazon Machine Image と呼ばれる) 仮想マシン・インスタンスを作成することができます。これはむしろホスティング・プロバイダーのサービスに非常に近いと言えるかもしれませんが、使用されるマシンが本物のマシンではない点、またマシンそのものをレンタルするのではなく、使用したトラフィックに応じて支払いが行われる点が異なります。

Amazon の S3 サービスはオンラインのストレージ・サービスであり、これはストレージ容量のスケーラリビリティーが必要な新興企業にとって特に魅力的です。S3 サービスは Amazon による他のクラウド・サービス (EC2 など) の付帯サービスとして利用することもできます。これはつまり、AMI (例えば PHP を実行する Linux™ マシン) が Amazon の S3 をデータ・ストアとして使用できるということです。データ・トラフィックが増大すると、S3 サービスは弾力的に拡張されます。Amazon の SimpleDB は高速で単純なクラウド・ベースのデータベースであり、インデックス作成機能、データ保存機能、そして保存したデータにアクセスする機能を持っています。SimpleDB はスキーマを必要とせず、データに自動的にインデックスを付け、またデータを保存するための API と保存したデータにアクセスするための API を提供しているため、フル機能のリレーショナル・データベースよりもはるかに単純です。

Amazon の SQS (Simple Queue Service) のキュー・サービスは JMS に似ていますが、RESTful インターフェースがあるところが異なります。SQS は Amazon による他のクラウド・サービスと組み合わせて使用することも、あるいは単純な HTTP GET または HTTP POST を使って SQS に接続される他の任意のアプリケーションの一部として使うこともできます。ハイブリッド・アプリケーションの場合、SQS は JMS キューを置き換えるには適切です。SQS の RESTful な XML インターフェースを利用することで SQS にアクセスできるため、既存のアプリケーションと SQS を容易に統合することができます。このシリーズで取り上げるハイブリッド・アプリケーションの場合、SQS はおそらく最も明白な選択肢です。

多くのソフトウェア・プロバイダーが Amazon と提携しているため、そうしたプロバイダーの顧客は EC2 を活用することができます。例えば IBM は Amazon と提携しているため、IBM の最も一般的なエンタープライズ・ソフトウェア (DB2®、Informix®、WebSphere® など) の多くを EC2 で利用することができます。

Google

Google は高速かつ正確な検索で有名であり、これは多くのユーザーにとって Arthur C Clarke の言葉である「非常に高度な技術は魔術と区別できない」を具現化しています。この魔術を可能にする技術を持っているため、Google はクラウド・コンピューティング・プラットフォームを提供する候補として理想的です。Google のプラットフォームの上でアプリケーションを実行できるということに開発者が興奮するのも当然です。

Google は App Engine というクラウド・コンピューティング・プラットフォームを提供しています。App Engine は、Google が長年にわたって築き上げた、ベースとなるプラットフォームに基づいています。App Engine には、GFS (Google's File System) と、GFS の上に構築された Bigtable というデータベース・システムが含まれています。Google App Engine でのプログラミングは Python を使って行います。プログラマーが Python を使ってアプリケーションを作成すると、それらのアプリケーションを App Engine フレームワーク上で実行することができます。将来は Python 以外の言語もサポートされる予定です。また、開発用に App Engine 環境のローカル・エミュレーターをダウンロードすることができます。App Engine は無料であり、500 MB までのストレージと 1 日当たり 500 万ページの閲覧を実現することができる十分な CPU 帯域幅を持っています。

Google App Engine には GFS によるデータ・ストアや memcache の実装など、いつくかの便利なインフラが用意されています。そのまま使用できるキュー・メカニズムは用意されていませんが、Python 用の完全なプログラミング環境が提供されるため、JMS に代わる独自のものを簡単に App Engine 上に作成することができます。App Engine のデータ・ストアはこのハイブリッド・アプリケーションに非常に適しており、キュー用の RESTful インターフェースを手早く作成する上で Python によるプログラミングはほとんど必要ありません。

Microsoft Azure

皆さんが想像するとおり、Windows® Azure™ では Windows と .NET が非常に大きな特徴です。Microsoft は、Visual Studio® を使って作成されたアプリケーションを Windows Azure 環境でホストし、実行できる環境を提供しています。Azure プラットフォームは、ファイル・ストレージやデータ・アクセスといったインフラ・サービスから検索や連絡先管理といった専用サービスに至るまで、さまざまなサービスを提供しています。また Azure には .NET Service Bus も含まれています。.NET Service Bus は昔ながらの ESB (Enterprise Service Bus) デザイン・パターンを Microsoft が実装したものです。ESB の最も単純な使い方の 1 つがメッセージ・キューとしての使い方です。そのため、ESB は確実に JMS キューの置き換えとなることができます。.NET Service Bus も開発者にとって使いやすいものです。.NET Service Bus は、XML を使用する軽量な RESTful インターフェースと、WS-* 標準の完全実装を含む強力な SOAP ベースのインターフェースの両方をサポートしています。これらのインターフェースのどちらを使用した場合も、既存のアプリケーションと .NET Service Bus との間での相互運用性を容易に実現することができます。

SalesForce.com

SalesForce.com が提供するモデルでは、SalesForce.com の Apex 開発言語を使って SalesForce.com のサービスにアクセスすることができます。SalesForce は Apex を「世界初のオンデマンド・プログラミング言語」と呼んでいます。オンデマンドというのは、Apex コードが SalesForce の Force.com クラウド・サービスでホストされ、そのコンテキストで実行されるという点を指しています。Apex は構文的に Java 言語や C# 言語と似ています。

Apex コードは Web ページの作成に使われ、これらの Web ページが実際のユーザー・インターフェースである VisualForce レイヤーとなります。これは MVC (Model-View-Controller) モデルを利用しています。このモデルは、コンパイル済みの C# を .NET の ASPX ページの背後で使用するモデルと似ています。これらの VisualForce ページには、HTML とAjax (XMLHttpRequest オブジェクト)、そして Adobe Flex を含めることができます。

VisualForce を利用すると、SalesForce.com の Web インターフェースのバリエーションを作成することができます。これは、SalesForce.com を気に入った企業が SalesForce.com に機能を追加しようとする場合に便利です。SalesForce.com のユーザーは、そうした機能の作成を SalesForce.com に依頼する代わりに自分でバリエーションを作成することができます。そのためには Apex コードを使って VisualForce ページを作成し、作成したページを SalesForce.com のバックエンドに接続します。

Salesforce は、Edit や Save といった標準的なルーチンを含む Controller も提供しています。Controller は、ページの表示をそのベースとなる SalesForce のデータベースのデータと結びつけるために使用されます。Force.com クラウドは大きな成功を収めています。Force.com クラウドを利用することでクラウド上にアプリケーションを作成できるだけではなく、直接的な分散モデルによってユーザーに課金できるアプリケーションを作成することもできるのです。しかし、これは非常に特別なクラウドであり、インクリメンタルな手法にはあまり適していません。通常は Force.com クラウド専用に作成します。

まとめ

この記事では、さまざまなクラウド・サービス・プロバイダーが提供する多様な機能と、それらを使ってJMS キューを置き換え、既存のアプリケーションをハイブリッド型のクラウド・アプリケーションに変換する方法を見てきました。今後の 2 回の記事では、ローカル・アプリケーションをクラウド・サービスと結合するハイブリッド・モデルの実現方法を説明します。また、クラウド・コンピューティングに影響する、セキュリティーやガバナンスに関する重要な問題についても検証します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, SOA and web services
ArticleID=393995
ArticleTitle=クラウドに接続する: 第 1 回 アプリケーションにクラウドを活用する
publish-date=04272009