Windows Azureエンタープライズアプリケーション開発技法 マルチテナント・アーキテクチャ ―― 第3章　クラウドとオンプレミスの考え方の違い　3.6 ―― 日本マイクロソフト株式会社コンサルティングサービス統括本部　 赤間 信幸 2012/01/10

本コーナーは、日経BP社発行の書籍『Windows Azureエンタープライズアプリケーション開発技法』の中から、特にInsider.NET読者に有用だと考えられる章や個所をInsider.NET編集部が選び、同社の許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『Windows Azureエンタープライズアプリケーション開発技法』の詳細は「目次情報ページ」や日経BP社のサイトをご覧ください。

ご注意：本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

■3.6　マルチテナントアーキテクチャ

　マルチテナント方式*1とは、1つのシステムの中に複数の企業（ユーザー）のサービスを同居させ、リソースや運用コストを大幅に低減する方式のことである。マルチテナント方式は、クラウド特有の考え方というわけではないが、SaaS型サービスの多くで利用されている方式である。もしWindows Azure PlatformのようなPaaS型サービスの上に、SaaS型の業務パッケージアプリケーションを構築してサービスを提供しようと考えるのであれば、避けては通れない検討項目となる。これについて解説する。

*1　日本語に直訳すると「雑居」。例えばマルチテナントビル＝「雑居ビル」。「雑居」という言葉は日本語としてあまり響きがよくないようにも思うが、他意はなく、単純に、複数のユーザーが共存・共用する、という意味で使われている。

●3.6.1　パッケージ製品のクラウド化における課題

　マルチテナント方式の重要性を考えるために、具体例として、既存のパッケージ製品を改良してAzure上に載せるケースを考えてみることにする（図 3-29）。

　本来、パッケージ製品とは「購入してきたものをそのままインストールして使うことができる」ものである。しかし、「業務パッケージ」と呼ばれる領域の製品は、実態としては数多くのカスタマイズを必要とすることが多い。すなわち、受注した顧客ごとに各種のカスタマイズや追加開発を行い、個別システムとして構築・納品していくわけである*2。これは、残念ながらコストも時間もかかる。

*2　「パッケージ」という名前はついているが、実際のビジネスのやり方からすると、どちらかというとSIビジネスを行う際、汎用部品を使うことで生産性を高めコストを下げているものである、と考えた方が適切なものが多い。

　このような業務パッケージ製品を、単純にそのままPaaS型クラウドサービスに載せてSaaS型サービス化した場合、確かにインフラコストは下がるかもしれないが、やはり従来と同様に数多くのカスタマイズをしないと顧客にサービスを提供できない。このため、かなりのコストと時間がかかってしまう。

　しかし、顧客がSaaS型サービスに求めるものは、「早い・安い・上手い」である。旧態依然とした時間とコストのかかるソリューションは、クラウドの世界では敬遠されてしまう。以前はそれでも「顧客向けのカスタマイズを行う」という大義名分があったため許容されていた面もあったが、昨今のクラウドサービス（特に全世界的に展開されているSaaS型サービス）は「早い・安い」だけでなく、「上手い」、すなわち高度なカスタマイズ機能を備えていることが多くなっている。しかもこうしたサービスは、国際化対応して全世界的に展開されているものも多く、このようなサービスは圧倒的に安価である。従来製品を単にAzureなどの上に載せただけでは、クラウドの世界では十分な競争力を発揮できない危険性がある。

図 3-29　従来のパッケージ製品と、SaaS化した場合に求められるサービスレベル

●3.6.2　マルチテナントアーキテクチャを採用する際の課題

　さて、前述したように、1つのシステムの中に複数の企業（ユーザー）のサービスを同居させ、リソースや運用コストを大幅に低減する方式を、マルチテナント方式と呼ぶ。こうしたマルチテナント型システムは、例えばメールやグループウェアのような、完全に画一化されたサービス、あるいはカスタマイズが発生するとしてもごく簡単なもので済むようなサービスを提供する場合、比較的簡単に作ることができる。しかし、CRMや財務会計、小売業務のように、顧客ごとの高度なカスタマイズが求められるような業務システムでは、マルチテナント型システムの実現は非常に面倒である。

　一般に、こうした業務システムのマルチテナント化が厄介なのは、顧客ごとに、必要となるデータ項目（すなわちデータベーススキーマ）が大きく変化するためである。図 3-30は、マルチテナント型システムを実現するための代表的なアーキテクチャである。図中Aの方式のように、顧客ごとにスキーマをカスタマイズし、それに合わせたデータベースを作成・展開し、さらにそれに併せてアプリケーションを開発していくのは、どう考えても、コストも時間もかかる。少なくとも、図中Bの方式のように、すべての顧客で使うテーブルについては共通化するような工夫が必要であるし、出来れば図中Cの方式のように、すべての顧客を共通のスキーマでカバーするような工夫ができればベストである。

図 3-30　マルチテナント型システムを実現するための代表的なアーキテクチャ

●3.6.3　単一データベース共通スキーマ方式

　実は、普通にデータベースを設計するとどうしても図中Aのような形になってしまうが、データベース設計の際に列データの持ち方を少し工夫することで、図中Cのようなことも実現できる。これについて以下に説明する。

　まず一般的なテーブル設計では、図 3-31のように、属性情報を列データとして保持する。しかし、実際のシステムでは、同じ「顧客情報」であっても、企業ごとに、必要となる属性情報が異なる。このため、このような設計では、利用企業（テナント）が増えるごとにテーブル数が増えていくことになり、運用コストやカスタマイズコストがどうしてもかさんでしまうことになる。

図 3-31　データ値を列データとして保持する方式

　この問題を避けるためには、テーブル設計を図 3-32のようにする必要がある。この設計では、顧客情報を、（すべてのテナントで共通となる）必須属性と（テナントごとに変化する）オプション属性に分け、オプション属性を保存するテーブルを別に用意する。さらに、どのテナントでどんな属性情報が必要になるかは、属性マスターという形で保持するようにする。このようにデータを保持するように設計すると、固定のスキーマ構造で、任意の属性を定義して使うことができるようになる。

図 3-32　マルチテナント型データベース設計

　中長期的に見た場合には、このような単一データベース共通スキーマ方式には大きなメリットがある。なぜなら、データベースのセットアップコスト、カスタマイズコスト、メンテナンスコストを安く抑えることができ、場合によっては顧客のセルフサービスでのカスタマイズも可能となるからである。こうしたスキーマを使って、カスタマイズ性の高いサービスを提供することで、安価でありながら利益率の高いSaaS型サービスを提供していこう、というわけである。

　ところが、このような単一データベース共通スキーマ方式の厄介なところは、従来型のデータベース設計とはSQL文が全く異なってしまう、という点である。特に既存システムのデータベースをこの構造に書き換えようとすると、SQL文のほとんどについて抜本的な書き換えが必要になってしまい、事実上、再構築に近いコストが必要となってしまう。このような「作り直し」を行うことは、実際のところは難しいケースがほとんどだろう。

　ただ、ここで一点併せて検討していただきたいのは、巨大データベースの件である。既存システムをクラウド上に載せていく際に、巨大なデータベースは水平分割するように再設計する必要がある、ということを述べたが、この水平分割もまたアプリケーションのSQL文の大幅な書き換えを必要とすることが多い。よって、もし既存システムをクラウド上に載せる際に、このような水平分割が必要になるのであれば、いっそマルチテナント化までやってしまう、というのも有効な選択肢となり得るわけである。

　どのような方式でマルチテナント対応を行うのかは、中長期的なビジネス戦略や、対応に必要となるコスト試算に基づいて検討する必要がある。しかし、いったん作ったアプリケーションを後付けでマルチテナント対応にすることは非常に難しい。PaaS上でアプリケーションを開発する際には、マルチテナント対応についても最初から併せて検討しておくことをお勧めする。

■

　以上がマルチテナントアーキテクチャに関する解説である。次回は、PaaSサービスモデルについて解説する。

「Windows Azureエンタープライズアプリケーション開発技法」

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