連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第7回 補遺：AAG正式版について 日本ユニシス　猪股 健太郎 2010/02/16
Page1 Page2 Page3

■クラウド・サービス

　クラウド・コンピューティングとは、リモートで運用されるサービスやアプリケーションを構築したり利用したりするための新しいテクノロジやアプローチを指していわれる言葉である。その種のサービスやアプリケーションの多くがインターネットを介してアクセスするものであるため、インターネットのことを雲（＝クラウド）状の記号で表現するネットワーク図の表記法から、クラウド・コンピューティングという言葉が生まれた。

　多くの場合、クラウド・コンピューティングは、スケールする（＝ユーザーや処理の増加に適応できる）分散システムを構築・利用するためのインフラストラクチャとアプリケーション・モデルを表している。インフラストラクチャとアプリケーション・モデルはともに進化し、アプリケーションに依存しないインフラストラクチャの拡張性と、そのインフラストラクチャを十分に活用できるアプリケーション・モデルが生まれてきた。

　逆にいえば、クラウド・コンピューティングの利点を活用するためには、アプリケーションのアーキテクチャは特定のアプリケーション・モデルに従って構築される必要がある。異なるクラウド・コンピューティング・サービスの提供者には、それぞれ異なるアプリケーション・モデル要件がある。

　また、提供されているクラウド・コンピューティング・サービスの種類もそれぞれ異なっている。アプリケーション実行環境を提供する「PaaS（Platform as a Service）」、ソフトウェアやアプリケーションを提供する「SaaS（Software as a Service）」などのように分類されることが多い。

クラウド体験記（前編） - ＠IT より引用

　企業向けのアプリケーションやサービスをクラウド上で運用することには、アプリケーションやサービスを提供するベンダや、クラウド・コンピューティングを利用する企業にとってメリットがある。

ベンダのメリット

• アーキテクチャの自由度。さまざまな配置パターンを利用者に提示できる。
• 豊かなユーザー体験。既存の外部Webサービスをマッシュアップすることで高機能なUIを簡単に構築できる。
• オフライン対応。ユーザー情報やアプリケーション状態をクラウド上で保持することで、特にモバイル・デバイスで、オフライン操作や断続的接続をサポートできる。
• 初期コストの低さ。起業したてのベンチャー企業でも、ユーザー数に見合ったサービスを即座に提供できる。

企業のメリット

• アーキテクチャの自由度。開発者はクラウド上のサービスをローカルのアプリケーションやサービスと組み合わせられる。情報システム部はどの機能を新規開発し、どの機能を外部サービスでまかなうかを選択できる。
• 費用と時間の節約。開発者は要件に応じた外部サービスを組み合わせ、短い時間でアプリケーションやサービスを開発できる。加えて、社内で保持するITインフラを減らすことで、運用保守の費用を抑えられる。
• 規模の経済。一般的な業務のためのシステムはクラウド・サービスを利用する。利用者が多いため安価となる
• オフライン対応。クラウドがハブとなり、ユーザーがさまざまな場所から接続する。デスクトップPCとモバイル機器とのシームレスな連携も可能である。

　ホスティングされたサービスとクラウド・サービスの設計課題として、AAGでは下記のものを取り上げている。ここでは、その中から「データの分離と共有」「データの保存場所と拡張性」「自社運用と外部運用、構築と購入の選択」の3つを説明しよう。

クラウド・サービスの設計課題

データの分離と共有

データのセキュリティ

データの保存場所と拡張性

アイデンティティ管理

マルチテナント

自社運用と外部運用、構築と購入の選択

パフォーマンス

結合サービス

サービスの統合

サービス管理

●データの分離と共有

　これは、アプリケーションやサービスのデータベース、データベース・スキーマを、テナント（ユーザー企業）ごとに持つかどうかを指す。マルチテナント・データを管理するための手法は次の3種類に大別される。

個別のデータベース
　テナントごとに異なるデータベースを使用する。

共有データベース、個別のスキーマ
　データベースは共通だが、その中で各テナントが独自のテーブルを持つ。

共有データベース、共有スキーマ
　すべてのテナントが同じテーブルを共有し、テナントID列でデータを区別する。

　この3つの手法にはそれぞれメリットとデメリットがあるため、提供するサービスに応じて適切に選択する必要がある。メリットとデメリットをまとめて表に示す。

データの持ち方	メリット	デメリット
個別のデータベース	・実装が簡単 ・オンプレミス（自社運用）環境からクラウドへ移行しやすい ・既存の運用管理ツールを利用できる ・独立性が高く、ほかのテナントの処理の影響を受けにくい	・共通的に使われるようなテーブルやデータをテナントごとに持つことになるため、多重管理になる ・各サーバのテナント集約度が制限されるため、ハードウェア面のコストがかかる
共有データベース、 個別のスキーマ	・メモリ消費量が小さい ・各サーバのテナント集約度を高められる ・共通的に使われるようなテーブルやデータを共有できる ・テナントごとにデータのアクセス権を分離することが簡単 ・実装がやや簡単	・独立性がやや低くなる ・バックアップと復元が難しい
共有データベース、 共有スキーマ	・メモリ消費量が最小 ・各サーバのテナント集約度が最高	・独立性が最低。独立性を実現するには特別な考慮が必要 ・データをほかのテナントと共有する形になる ・バックアップと復元が難しい ・テナントごとのモニタリングが難しい
データベースとスキーマの持ち方に関するメリット／デメリット

　もしアプリケーションやサービスを短い期間で構築しなければならないのなら、個別のデータベースを選ぶとよい。また、セキュリティ要件が厳しい場合や、テナントごとにサービス内容を変え、付加価値を提供したい場合も、個別のデータベースが適している。

　一方で、もし多くのテナントに対してサービスを提供しなければならないが、テナントごとのデータ量はそれほど大きくならないのなら、共有データベース・共有スキーマを選ぶとよい。そして、共有データベース・個別スキーマは、両方のバランスを取った構成となる。

参考情報：

• ・マルチテナント・データ・アーキテクチャ

●データの保存場所と拡張性

　アプリケーションやサービスにおいてデータを保存する方法はさまざまだが、ホスティング／クラウド環境では2つの異なる技術が発展している。RDBMS（リレーショナル・データベース管理システム）を使うアプローチと、非リレーショナルなクラウド・ストレージを使うアプローチだ。

　RDBMSは構造が定まったデータのためのシステムであり、トランザクショナルなアプリケーションやI/O処理が集中するアプリケーションに適している。また、複雑なクエリを取り扱うことも可能である。

　一方で、クラウド・ストレージには多くの種類がある。例えば、DBMSとしての機能を持つものもあれば、デジタル・メディアのように構造のないデータを扱えるもの、データ同期サービスやネットワーク化されたストレージなどが存在する。

　クラウド・ストレージの長所には、大きなデータを扱えることや、安価なこと、高速なこと、そして、スケーラビリティがあることが挙げられる。一方、短所には、信頼性が問題になる場合があること、ネットワークを経由するオーバーヘッドが大きい場合があること、ACIDトランザクションがサポートされないか、あるいは非常に限定されたサポートしかないことが挙げられる。これは、CAP定理*1における「可用性」と「ネットワーク分断耐性」を重視しているためである。

*1　「データの整合性(Consistency)」「システムの可用性(Availability)」「ネットワーク分断の耐性(Partition Tolerance)」の3つを同時に満たすことはできないという定理。

　マイクロソフトのクラウド・サービスである「Windows Azure」では、クラウド・ストレージとして「テーブル」「BLOB」「キュー」などのストレージを提供している。詳細は、「特集：初めてのWindows Azureテーブル・ストレージ開発」や参考情報をご覧いただきたい。

　一方で、これまでも一般的に使われてきたRDBMSをホスティング／クラウド環境で使うことも多い。クラウド・ストレージほどのスケーラビリティは実現できないが、ACIDトランザクションをベースにした一貫性や信頼性は有用である。

　RDBMSにはスキーマを変更しにくいという欠点もあるが、RDBMSを使用しながらも、異なった構造を持つデータを取り扱うためのテクニックもいくつか存在する。以下に列挙する。

固定列を用いる方法

各テーブルに、拡張データを格納するための列をあらかじめ定義しておく方法。拡張データ用の列をいくつ用意するかは、テーブルや利用状況によって変わる。拡張データ列はデータ・アクセス層が抽象化し、スキーマ情報を隠ぺいしておく必要がある。この方式は高速で、比較的スケーラビリティもある。一方で、拡張データ列をVARCHAR型にせざるを得なくなることも多い。そのため、数値的な大小で検索するなどの場合は特別な考慮が必要である。また、多くのデータが空（NULL）であってもデータ領域を多く使用してしまう。

スキーマをカスタマイズする方法

この方法は「共有データベース、個別のスキーマ」と併せて使われる。テナントごとに別のスキーマを持つため、テナントごとに異なる列を追加することもできる。固定列の場合と同様、拡張データ列はデータ・アクセス層が抽象化し、スキーマ情報を隠ぺいしておく必要がある。追加された列に関する検索が効率よく実行できるが、スキーマおよび共有データの管理コストが増大する。

名前と値をペアにした拡張データ用テーブルを持つ方法

この方法は、拡張データを無制限に持つことができるため、非常に柔軟性が高い。半面、データを取得するためにテーブルを複数回結合しなければならなくなる。そのため、インデックス化や検索や更新が複雑になるうえ、処理速度も落ちる。

XMLデータ列に格納する方法

この方法も、拡張データに制限がないため、非常に柔軟性が高い。また、設計・実装は比較的シンプルになる。多少複雑になるがインデックスもサポートされる。半面、スケーラビリティがあまりなく、処理速度も遅い。また、開発者にはXMLを扱うスキルが必要になる。

参考情報：

• 初めてのWindows Azureテーブル・ストレージ開発
• Windows Azure Platformデベロッパー センター

●自社運用と外部運用、構築と購入の選択

　クラウド上でサービスを提供すれば、ベンダはより多くの顧客に対してサービスを提供できるようになる。また、サービスを利用する企業側も、市場競争により安価なものを利用できる。

　しかし、外部運用に移行することは、アプリケーションやデータやサービス・レベルを自由に制御できなくなることにもつながる。また、自社専用のアプリケーションやサービスを構築する場合と、標準的なソリューションやパッケージを利用する場合との間にもトレードオフがある。それぞれの場合の特徴を表にまとめる。

XMLデータ列に格納する方法

この方法も、拡張データに制限がないため、非常に柔軟性が高い。また、設計・実装は比較的シンプルになる。多少複雑になるがインデックスもサポートされる。半面、スケーラビリティがあまりなく、処理速度も遅い。また、開発者にはXMLを扱うスキルが必要になる。

参考情報：

• 初めてのWindows Azureテーブル・ストレージ開発
• Windows Azure Platformデベロッパー センター

●自社運用と外部運用、構築と購入の選択

　クラウド上でサービスを提供すれば、ベンダはより多くの顧客に対してサービスを提供できるようになる。また、サービスを利用する企業側も、市場競争により安価なものを利用できる。

　しかし、外部運用に移行することは、アプリケーションやデータやサービス・レベルを自由に制御できなくなることにもつながる。また、自社専用のアプリケーションやサービスを構築する場合と、標準的なソリューションやパッケージを利用する場合との間にもトレードオフがある。それぞれの場合の特徴を表にまとめる。

	自社運用 （アプリケーションやデータを自由にできる。また、特殊な運用が必要な場合や、セキュリティ要件や法律が厳しい場合にも適する）	ホスティング （運用を他社と共通化することでコストを抑えながら、アプリケーションについては制御できる）	クラウド （初期費用を抑えつつ、高いスケーラビリティを実現する場合に適する）
独自に構築したアプリケーションを利用する	アプリケーションを内製あるいは外注し、自社のデータセンターで運用する。 自社の要件をパッケージ製品では満たせない場合に適する	アプリケーションを内製あるいは外注し、他社のデータセンターに運用をアウトソースする。 費用や期間が妥当な範囲に収まるかをあらかじめ判断するべきである	クラウド用アプリケーションを内製あるいは外注し、クラウド・サービスに配置して利用する。 クラウド環境特有の開発スキルが必要となる。 費用や期間が妥当な範囲に収まるかをあらかじめ判断するべきである
一般的なソリューションやパッケージを利用する	ソリューションやパッケージを購入し、自社のデータセンターで運用する。 自社の要件が妥当な範囲で満たされる場合に適する	ホスティング業者がサポートしているパッケージを導入する。 運用開始までの期間が短い場合に適する。 自社の要件が妥当な範囲で満たされる場合、運用も含めて最適化される	クラウド・アプリケーションを提供しているベンダと契約してアプリケーションを利用する。 運用開始までの期間が非常に短い場合や、TCO（＝総所有コスト）を抑えたい場合に適する
自社運用と外部運用、構築と購入のマトリックス

参考情報：

• アーキテクチャ ジャーナル:“Head in the Cloud, Feet on the Ground” （英語）

■

　今回はAAG正式公開版の差分を駆け足で紹介した。当連載ではAAGのすべてを説明できたわけではない。この連載をきっかけに、AAGに興味を持っていただけたら幸いである。将来、AAGの日本語訳が公開されることがあるかもしれないが、.NETのアプリケーションやサービスを設計するすべての人は、それまで待つのではなく、いますぐにでもAAGに目を通してもらえればと思っている。

　長い間お付き合いいただき、ありがとうございました。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第7回 補遺：AAG正式版について
	1．ドメイン駆動設計
	2．横断的関心事
	3．クラウド・サービス

「アプリケーション・アーキテクチャ・ガイド2.0解説」

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