アーキテクチャ・ジャーナル クラウドへのアプリケーションのマッピング Darryl Chantry 2009/12/07
Page1 Page2 Page3 Page4 Page5

■クラウドは 1 つか ?

　クラウドは 1 つなのか、それとも複数あるのか。これは、これまで何度も耳にしてきた議論です。この議論には、パブリック クラウド VS プライベート クラウドという構図があります。そのため、クラウド テクノロジが私的に実装されているものを果たしてクラウドと呼べるのか、すべてのパブリック クラウドでは同じものが提供されているのか、ハイブリッド モデルとしてプライベートとパブリックの両方のクラウドにまたがっているアプリケーションやシステムはどのように位置付けられるのか、などの議論が交わされています。

　率直に言うなら、これらの議論そのものが的外れです。どのような見解を支持するにしても、目指すところは同じで、可能な限りコスト効果の高いシステムを構築して稼動させることです。前のセクションでは、決定を下すのに役立つアイデアを考察しました。ここからは、クラウドで、あるいはハイブリッド クラウド ソリューションの一部として実装できるアプリケーションの例を簡単に紹介します。

●クラウドでソリューションのアーキテクチャを設計する

　このセクションでは、クラウド サービスを利用して実装できるソリューションのアプリケーションのシナリオを 3 つ紹介します。以下のシナリオは、クラウド サービスに適したソリューションをすべて網羅するものではなく、実現可能なアプリケーションのサンプルにすぎないことに留意してください。

（1）チケット販売システム

　クラウド インフラストラクチャのメリットについて語るとき、クラウド シナリオの最適な例として必ず取り上げられるのがコンサート チケット販売システムです（図 5）。一見して、このタイプのアプリケーションは、クラウドに最適のように思えます。というのは、チケット販売システムは、短期間に多くの要求を処理しなければならないことがあるからです（コンサートやスポーツ競技のチケットが売り切れる前に購入しようとユーザーが殺到するため）。その後は、通常、利用度が低から中程度の状況が長期にわたって続きます。

図 5: クラウド インフラストラクチャを利用するチケット販売システム

　多くの要求が集中し、コンピューティング リソースの必要性が非常に高まる時期には、チケット販売アプリケーションに過剰な負荷がかかりがちです。このようなときには、システムを援護する仮想マシンのインスタンスを起動できれば助かります。とはいえ、ソリューションの設計を始める前に、考慮しなければならない点がいくつかあります。

• チケット販売システムでは、大量のデータが処理され、大量のトランザクションが実行されます。トランザクションの実行は、支払システムに加えて、座席の予約でも必要になります。

• 多くの顧客がチケット販売会社にアカウントを持っており、新たにアカウントの作成を希望する顧客もいるため、個人識別情報の収集は、ほぼ間違いなく必須となります。

• クレジット カード決済の照会には、時間がかかる場合があります。これは、チケット販売プロセスのボトルネックとなる可能性があります。

• 一部の仮想クラウド サーバー プラットフォームでは、ステートを保存することができません。その場合、サーバー イメージが途中でシャットダウンされると、イメージ内に保存されているデータの変更点や追加事項はすべて失われます。

• 既存のチケット販売企業は、インフラストラクチャやデータ管理に既にかなりの投資を行っていると考えられます。

• 選択するクラウド サービスによっては、ステートを保存できない仮想クラウド サーバー イメージをイベントごとに作成し直さなければならない場合があります。結果として、新しいインスタンスの環境を用意するたびに、大量の処理が発生します。

　これらの点をすべて考慮に入れたうえで、クラウド サービスを活用して、ピーク時の既存のシステムの負荷を軽減する次のような方法があります。

• 社内システムとまったく同じシステムをもう 1 つ構築する ― これは最も手間のかかる方法です。つまり、アプリケーションの使用を開始した後も、新しいインスタンスを作成するたびにメイン システムと同期をとる必要があります。このシステムを常に稼働状態にしておくと（処理能力を縮小していても）、サービス プラットフォームの使用によってコストが発生するため、多大な費用がかかります。

• 社内システムとクラウド サービスとの間でワークロードをリアルタイムに分割する ― この方法では、2 つの環境の間で座席の選択とチケット購入のプロセスが分割されます。たとえば、企業内のチケット販売システムでトランザクションを開始します。そこでは顧客がアカウントにログインし、参加するイベントを選び、座席を選択するようにします。その後クラウド サービスにトランザクションを渡して、最終的な支払のプロセスを実行します。この方法では、プロセスの最終段階のみを処理する仮想クラウド サーバーを作成して、事実上ステートレスな処理エンジンとして使用するため、このサーバーをメイン システムと同期する必要はありません。クラウド サービスには転送するデータは最小限で済みます。クレジット カードの情報は社外のクラウド サービスで収集し、1 度使用した後で削除できます。

• バッチ処理を使用して、社内システムとクラウド サービスとの間でワークロードを分割する ― 上記の処理方法と似ていますが、クレジット カードの詳細を含むすべての個人情報が社内システムで収集される点が異なっています。この情報はプロセス キューに入れ、一括でクラウド サービスに転送して処理できます。この方法では、支払でエラーが発生する場合、チケットを購入しようとしている顧客への連絡用に 2 次プロセスを実装する（まだ実装されていない場合）必要があります。

　これらのソリューションは、ピーク時にクラウド サービスと企業の社内システムとの間で処理を分割するチケット販売システムの例です。

（2）写真/ビデオの処理

　この例では、複数のサービス（インフラストラクチャ、ストレージ、キュー）を組み合わせて、データ処理のソリューションを提供する方法を紹介します（図 6）。このシナリオには、クラウド サービスを活用してデジタル メディア ファイルのレンダリングや再フォーマットを行う、フランチャイズ チェーンの写真店が登場します。

図 6: クラウド インフラストラクチャを使用した写真/ビデオの処理

　このフランチャイズ チェーンは米国各地に店舗を展開していますが、大きな画像やビデオの処理を中央で一元管理することによって、システムの抱える 2 つの問題、つまり各店舗に配備しなければならないハードウェアの量と、ハードウェアのメンテナンスやサポートの手間を軽減しようとしています。

　顧客が店舗を訪れ、ビデオのフォーマットの変換を依頼すると、そのビデオ ファイルはまずストレージ サービスにアップロードされます。その後、ストレージ プラットフォームにファイルがあり、他のフォーマットへの変換が必要であることを通知するメッセージがキュー サービスに追加されます。コンピューターのインスタンスを実行しているアプリケーション コントローラーがキューからメッセージを受け取り、仮想マシンの既存のインスタンスを使用するか、新しいインスタンスを作成して、ビデオの再フォーマットを実行します。このプロセスが完了すると、コントローラーはキューにメッセージを追加して、お店にプロジェクトが完了したことを通知します。

　このシナリオは、オンラインのプロセスにも簡単に応用できます。たとえば、顧客は実際に店舗に足を運ばなくても、ファイルをアップロードして、変換処理を依頼することができます。

（3）Web サイトのピーク時の負荷

　紹介する最後の例は、不規則な時間帯に大量のトラフィックが発生する Web サイトです。この場合、ピーク時の負荷をサポートするために、ホスティング インフラストラクチャを構築することは実際的ではありません（図 7）。このようなサイトには、たとえば速報を提供するニュース サイト、新しいゲームを発表するゲーム サイト、新しい話題作の予告編を視聴できる映画サイトなどがあります。

図 7: クラウド インフラストラクチャによる、ピーク時の負荷のサポート

　このシナリオのソリューションでは、過大なトラフィックが発生する企業の Web サイト全体またはその一部のコピーをクラウド サービス インフラストラクチャ サービス上に作成します。サイトのコピーは静的なインスタンスであり、負荷分散されたサーバーのセットまたはクラスターとして構成される、複数の Web サーバー上で実行されます。サイトに何らかの変更を加えたいときは、元の Web サイトに変更を加え、クラウド サーバーと同期をとることができます。これによって遅延が生じますが、Web サーバーや Web サイトの維持に費やす労力は大幅に軽減されます。また、社内と社外でホストされている Web サイト間でステートを維持するという問題も解決できます。

　上記のシナリオでソリューションを設計する方法は、1 つではありません。また、クラウド サービスを活用できるシナリオも、この他に数多くあります。この記事では、従来の方法に代わるいくつかの選択肢にスポットライトを当て、新しいサービスの活用方法を紹介するに留めています。

■まとめ

　クラウドやクラウド テクノロジに強い関心を抱いている多くの開発者、ISV、新興企業、大企業がクラウド サービスを吟味し、導入すべきかどうかを探っています。ストレージとインフラストラクチャ性能の両面における所有コストの低減とほぼ無限のスケーラビリティという、クラウドの掲げるメリットは無視できません。とはいえ、これらのメリットが実現可能かどうかは必ず検証が必要です。クラウド サービスの導入を慎重に検討し、すべてのアプリケーションがクラウドに適しているわけではないことを理解する必要があります。多くのアプリケーションはクラウドで動作しますが、ソリューションによってはクラウドでホストすることにより隠れたコストが発生します。そのため、従来の確立されたアーキテクチャやテクノロジを使用する場合と比べて、プロジェクトの開発コストと運用コストが増大する危険性があることも考慮しなければならないでしょう。　

著者について Darryl Chantry は、マイクロソフトのプラットフォーム アーキテクチャ チームでシニア アーキテクトを務めています。アーキテクトとして幅広いスキルを持ち、エンタープライズ アーキテクト、ソリューション アーキテクト、インフラストラクチャ アーキテクトとして活躍してきました。ニュージーランドのマイクロソフト開発者およびプラットフォームエバンジェリズム チームに加わったのは 2002 年のことです。Darryl はニュージーランドのオークランドで生まれ育ち、ラグビーに情熱を注いでいましたが、人類学、歴史、ユーザー エクスペリエンスに強い関心を抱くようになりました。現在は、妻、そして 1 匹のブーアブール犬と 2 匹のビルマ猫と共に、ワシントン州のレドモンドに住んでいます。

【このトピックに関する最新情報】

• Introducing the Azure Services Platform（Azure Services Platformの概要 日本語版）（David Chappell氏の記事）

• Azure for Business（ビジネスのためのAzure）

• Azure for Corporate Developers（社内開発者のためのAzure）

• Azure for Independent Software Vendors（ISVs）（ソフトウェア開発パートナー（ISV）のためのAzure）

INDEX
	［アーキテクチャ・ジャーナル］
	クラウドへのアプリケーションのマッピング
	1．クラウドとクラウド コンピューティング : どちらが先か ?
	2．アプリケーションはすべてクラウドに移行されるか ?
	3．クラウドは 1 つか ?
	付録 A : アプリケーション マッピング属性／クラウド マッピング属性のサンプル
	付録 B : クラウド インフラストラクチャのプラットフォームと仮想化のタイプ

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）