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

■アプリケーションはすべてクラウドに移行されるか ?

　アプリケーションはすべて、クラウドで実行されるようになるのでしょうか。既存のすべてのアプリケーションをクラウドに移植する必要がありますか。新しいアプリケーションはすべてクラウドで開発すべきでしょうか。そもそも、クラウドとは何なのでしょう。クラウド サービスの使用を検討すると、このような疑問が生じます。

　アプリケーションには、クラウド プラットフォームへの移植、クラウド プラットフォームでの開発、またはクラウド インフラストラクチャでのホスティングに適しているものと、クラウドに適さないものがあります。ですから、上記の一連の問いに対しては、“場合による”という、アーキテクチャ業界の常套句で答えるほかありません。実際には、ほぼすべてのアプリケーションを部分的あるいは完全にクラウドに移植することが可能です。ただし、注意が必要なのは、クラウドに移植することによって、アプリケーションの属性が（場合によっては、アプリケーションの機能も）損なわれるおそれがあるということです。

　以降のページでは、特定のアプリケーションをクラウドで実行するのが実際的かどうかを判断する材料として、アプリケーションとクラウドをそれぞれ基本的な属性に分解するいくつかのアイデアについて説明します。

●アプリケーションをクラウドにマッピングする

　受注管理システムであれ、飛行機の予約システムであれ、CRM アプリケーションであれ、すべてのアプリケーションは何らかの目的を果たすために設計されています。アプリケーションの特定の機能を実装するには、特定の属性を有していることが必須となります。たとえば、受注管理システムでは、トランザクションとロックのサポートを欠かすことはできないでしょう。しかしその場合、受注管理という目的のためにクラウド ストレージをデータ ストアとして使用するのは適切でないということになります。このように、アプリケーションまたは大きなアプリケーションを構成するサブシステムの主要な属性を特定することが、アプリケーションがクラウドに適しているかどうかを判断するための重要なステップとなります。

　図 1 は、あらゆるアプリケーションに該当する主要な属性の大まかな分類（青い列）を示しています。アプリケーションに関係すると思われる属性をすべて挙げる必要はありません。大切なのは、どの属性がアプリケーションにとって絶対不可欠なのかを見極めることです。この作業によって、対応可能な数の属性のリストができあがります。クラウドへのマッピングは、このリストに基づいて行うことができます。たとえば、“データ管理”属性を例にとると、“データ管理”には、さらに 2 次的な属性のリストが含まれます。2 次的な属性とは、上位の属性の詳細情報を提供する属性です。ここで“アクセス”を選択すると、データ ソースへのアクセスをオンライン、オフライン、あるいはオンライン/オフライン両方のいずれかを指定できます。

図 1: アプリケーションの属性マップ

　“データ アクセス”の例では、クラウド プロバイダーの提供するデータ ストレージを使用するかどうか、という選択にこの属性がどのような影響を及ぼすかが分かります。このアプリケーションで必要となるのがオンライン データだけであれば、クラウド ストレージはすばらしい選択となります。逆にオフライン データしか必要としない場合は、このアプリケーションがクラウドに適していないことが強く示唆されていることがわかります。また、オンラインとオフラインの両方のデータが必要な場合は、アプリケーションとクラウド間でデータの同期を行うアプリケーションの開発費用について考慮する必要があるでしょう。

　エンド ユーザーにオンラインとオフラインの両方のモードを提供するには、追加のコストがかかります。とはいえ、アプリケーションの主要な属性がデータ管理ではなく、たとえば高可用性であるなら、クラウドの提供する優れた可用性というメリットによって、オフライン モードの開発費用は簡単に相殺できるでしょう（4 ページの「付録 A アプリケーション マッピング属性のサンプル」を参照）。

●クラウドは何でできているか ?

　アプリケーションを分解して主要な属性を特定したら、同様の作業をクラウド（厳密には、クラウド サービス プロバイダー）に対して実行します。クラウドの属性を大きなカテゴリに分類することによって、マッピング プロセスを簡略化できます。この例で使用するカテゴリは、クラウド インフラストラクチャ、クラウド ストレージ、クラウド プラットフォーム、クラウド アプリケーション、およびコア クラウド サービスです。

　図 2に示されているように、アプリケーションの属性は、1 つ以上のカテゴリのクラウド属性にマッピングすることができます。

図 2: アプリケーション属性のクラウド属性へのマッピング

クラウド インフラストラクチャ

　“クラウド インフラストラクチャ”とは、クラウドのインフラストラクチャです。一般的な表現を使えば、仮想サーバーを指します。インフラストラクチャは、大規模なプロセスやアプリケーションを裏で支える処理能力を提供します。大規模なアプリケーションを支えるインフラストラクチャは、Facebook や MySpace を思い浮かべると理解しやすいかもしれません。大規模なプロセスは、たとえば航空機や自動車の製造業でストレス テストのシミュレーションを実行する高性能のインフラストラクチャ クラスターを想像してください。

　クラウド インフラストラクチャを実現する主要テクノロジが仮想化です。つまり、大規模なデータ センターで仮想サーバーを実行することによって高価なハードウェアを購入および維持する必要がなくなり、インフラストラクチャ リソースを共有することで規模の経済効果を享受できるというわけです。仮想化のプラットフォームは、通常、完全仮想化あるいは準仮想化の環境のいずれかです（仮想化の詳細については、5 ページの「付録 B」を参照）。

クラウド ストレージ

　“クラウド ストレージ”とは、クラウドに置かれるあらゆるタイプのデータ ストレージを指します。これには、データベースのような機能を提供するサービス、非構造化データ サービス（デジタル メディアのファイル ストレージなど）、データ同期サービス、ネットワーク接続ストレージ（NAS）サービスが含まれます。データ サービスは通常、従量課金モデルで提供されます。この例の場合は、ギガ バイト（保存データと転送データの両方を含む）単位で課金されます。

　クラウド ストレージには多くのメリットがあります。たとえば、膨大な量のデータをいつでも、どこからでも保存し、取得することができます。データ ストレージ サービスは、高速で廉価なサービスであり、ほぼ無限のスケーラビリティを備えています。ただし、信頼性の面では問題が生じる可能性があります。最高のサービスであっても、障害が発生することは避けられないからです。また、トランザクション サポートも、クラウド ベースのストレージ システムが持つ短所の 1 つです。これは、ストレージ サービスとして企業で広く活用されるためには、必ず解決しなければならない重要な問題です。

クラウド プラットフォーム

　“クラウド プラットフォーム”とは、実際にはクラウドでアプリケーションを構築、テスト、展開、実行、および管理できる能力を指します。クラウド プラットフォームでは、これらの操作を新たな方法で実行できます。たとえば、アプリケーションの構築はオンライン、オフライン、あるいはその両方で行われる場合があるのに対し、アプリケーションのテスト ツールについては、あるプラットフォームには存在せず、他のプラットフォームには優れたツールが存在するということがあります。

　クラウド プラットフォームは一般に低コストで高いスケーラビリティを備えており、Web ベースのアプリケーションおよびサービスに適したホスティング/開発環境です。きわめて単純に表現するなら、クラウド プラットフォームは、平均的な Web ホストよりも高いスケーラビリティと可用性を備えた Web ホスティングの高度な形態といえます。しかし、どのようなテクノロジにもプラス面とマイナス面があります。クラウド プラットフォームのマイナス面は、その移植性にあります。いったん特定のプラットフォーム向けにアプリケーションを開発した後で、そのアプリケーションを他のクラウド プラットフォームに移動したり、従来のホスティング環境に戻したりすることは、ほとんど不可能だからです。

クラウド アプリケーション

　“クラウド アプリケーション”は、部分的に、あるいは完全にクラウド内に存在し、クラウド サービスを使用してアプリケーション内でコア機能を実装します。クラウド アプリケーションのアーキテクチャは従来のアプリケーション モデルとは大きく異なる場合があるため、クラウド アプリケーションを実装するには、アプリケーション設計の思考プロセスを根本的に変化させる必要があります。

　クラウド アプリケーションの多くはローカルにインストールして実行する必要がなく、ソフトウェアの維持、展開、管理、サポートに要する費用を削減することができます。このタイプのアプリケーションは、SaaS（サービスとしてのソフトウェア）アプリケーションと見なされます。

　この SaaS に取って代わることができるのは、ソフトウェア プラス サービス（S+S）モデルでしょう。S+S は、従来のアプリケーション開発と完全な SaaS 実装のハイブリッドです。S+S アプリケーションは、通常、クライアント PC にインストールされているリッチ クライアント アプリケーションを外部のホスト サービスに対するインターフェイスとして使用します。また多くの場合、オフライン モードでアプリケーションとやり取りしたり、必要に応じて中央のサービスと同期したりする機能も備えています。

コア クラウド サービス

　“コア クラウド サービス”とは、クラウド ベースのソリューションをサポートするサービスです。ID管理、サービス間統合、マッピング、課金/支払システム、検索、メッセージング、ビジネス プロセス管理、ワークフローなどが含まれます。コア クラウド サービスは、個人が直接使用したり、システム間統合を通じて間接的に使用する場合があります。

　コア クラウド サービスは、テレコミュニケーション業界と同じような進化の軌跡をたどると考えられます。この点は、多くのサービスがビジネス サポート システム（BSS）かオペレーション サポート システム（OSS）のカテゴリに分類されるところに表れています。

　BSS サービスは、主として次のようなタスクを処理する顧客のやり取りを管理します。

• 受注
• 請求書の処理
• 支払の徴収

　OSS サービスは、サービスそのものを管理し、次のような項目を担当します。

• サービスのモニタリング
• サービスプロビジョニング
• サービスの構成

●クラウド サービスの属性マップ

　これらの 5 つのクラウド カテゴリを使用して、各カテゴリの属性セットを作成します。これらの属性は、2 つの方法で使用できます。

• アプリケーションの属性をクラウド属性にマッピングして、クラウド サービスがアプリケーションに適しているかどうかを検証し、使用するサービスのタイプを決定できます。
• アプリケーションのホストとして適切かどうかクラウド サービス プロバイダーを評価し、そのプロバイダーで利用できるサービスのタイプを調べて、提供されているサービスの特定の実装属性を見極めることができます。

　図 3 は、5 つのクラウド カテゴリと、クラウド ストレージというカテゴリの属性のリストを示しています。クラウド プロバイダーがクラウド サービスを実装する方法は、プロバイダーごとに多少異なります。マイクロソフトのように多くの異なるストレージ サービスを提供している企業の場合、開発者はアプリケーションで必要とされる機能に応じて使用するサービスを選択できます。

図 3: 5 つのクラウド カテゴリとクラウド ストレージの属性

　クラウド プロバイダーのサービスが企業のニーズに合致するものかどうかを判断する際には、アプリケーション属性と同様、クラウド属性も注意深く検討しなければなりません。この決定によって生じる実装コストも、計算に入れる必要があるからです（4 ページの「付録 A クラウド マッピング属性のサンプル」を参照）。

●クラウドとアプリケーションを重ね合わせる

　アプリケーションについて、またソリューションの実装に利用できるクラウド サービスについて十分に把握できたら、最終的なアーキテクチャをどのようなものにするか決定を下さなければなりません。従来のアプリケーション アーキテクチャに代わる選択肢としてクラウドが有望であり、コスト効率にも優れていると結論できる場合は、次のステップとして、アプリケーションに最適なクラウド プロバイダーを選択します。

　すべての要件を 1 社で満たせるベンダーが見つからない可能性があります。そのような場合は、複数のベンダーからアプリケーションが必要とするサービスをすべて調達できるでしょう。

　図 4 は、複数のクラウド プロバイダーが提供する複数のクラウド サービスを利用するアプリケーションを示しています。たとえば、前述の例であれば、ASP.NET で構築され、Azure プラットフォーム（クラウド プラットフォーム）で実行されるアプリケーションを想定できます。このアプリケーションはコンポーネントを完全に信頼する必要があるため、それらのコンポーネントは必ず完全仮想環境（クラウド インフラストラクチャ）で実行されなければなりません。データはマイクロソフトのクラウド（クラウド ストレージ）に保存し、Azure を介して提供されるワークフローや ID などのサービス（コア クラウド サービス）を利用します。このアプリケーションの最後の要件は、課金/支払サービス（コア クラウド サービス）です。これには、別のクラウド プロバイダーのサービスを利用できます。

図 4: 複数のクラウド サービスとベンダーを利用する単一のアプリケーション

　ただし、このシナリオは実現可能であるとはいえ、複数のプロバイダーと取り引きし、複数の API を使用し、すべてのサービスを 1 つのアプリケーションに統合することによって生じるコストを考えると、実用的とはいえません。考えられる解決策は、アプリケーションが必要とするサービスの大半を 1 社で提供できるベンダーを見つけ、このベンダーをハイブリッド ソリューションの基本のプラットフォームとするという方法です。

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

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

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