マルチテナント・サービスの実現に向けて

手持ちアプリの現実的なデータストア移行戦略

　すでにあるアプリケーションをクラウドに配置することでスケーラビリティや可用性、管理の自動化などのメリットを得つつ、社内外向けにSaaSとして提供しようとする場合、何らかのコード変更が必要になる場合がほとんどです。

　単純なホスティング相当のサービスをクラウドと称している場合を除き、一般的には、オンプレミスとクラウドではアーキテクチャーやプログラミング・モデルが異なっているからです。

　スケーラビリティやコストの観点でクラウド化を検討している場合は、TableやBlobを活用することで、そのメリットを最大限享受することができますが、データ・アクセス部分のコード変更が必須です。ビジネス・ロジックやUI（ユーザー・インタフェース）にSQLを埋め込んでいるケースなど、アプリケーションによってはかなりの工数がかかってしまう可能性があります。

　これでは、立ち上げのコストを低く抑えながら開発期間を短くするといったクラウドならではのメリットが失われてしまいます。そこで、クラウド側で稼働するリレーショナル・データベースであるSQL Azureをクラウド化へのステップとして利用することを検討してみましょう。

　SQL Serverに対応したアプリケーションであれば、SQL Azureでサポートされていない機能を使っていない限り、多くの場合で工数をそれほどかけることなくクラウドに移行することができるでしょう。

　移行にあたっては、いくつか注意が必要です。まず、データベース容量の上限の問題もあるので、法人向けに業務アプリケーションを提供する場合、企業ごとにデータベースを分割するなどの割り切りが必要になります。また、オンプレミスでSQL Serverを利用していた際にデータ量の増大を意識することなく大容量のデータを格納していた場合には、コスト面でのメリットを十分に享受できない可能性があります。

マルチテナント対応の段階的なステップアップ

　アプリケーションをクラウド上に配置してSaaS化する場合、マルチテナントにどう対応するかは悩ましい問題の1つです。

　業務アプリケーションを複数の顧客向けにサービスとして提供する場合、管理効率の面ではできるだけ一元化したいところですが、パフォーマンスやセキュリティの面では分散構成を採った方がよい場面があります。

　マルチテナントにおけるデータ管理の程度を大きく分けると、以下の3段階のバリエーションがあります。アプリケーション側での実装難易度も、この順番で高くなっていきます。

1.データベースをテナントごとに分ける
2.スキーマをテナントごとに分ける
3.共有スキーマでマルチテナントを制御する

　最初から共有スキーマで動くことを前提としたアーキテクチャーで設計されていれば問題ないのですが、多くの場合は、共有スキーマを使うようには設計されていません。ここで、全体のアーキテクチャーを再検討した場合、影響範囲が広いため、コード変更や動作確認に多くの工数を要してしまいます。

　現実的には、データベースをテナントやスキーマごとに積極的に分割するアプローチを採ります。これにより、マルチテナント対応のハードルが下がり、移行期間が短くなり、かつ、顧客数が増えた場合にも対応できます。

　データベース分割では、小さなデータベースをいくつも立ち上げるのに適したライセンスやサービス構成になっていることが望まれます。この点、SQL Azureはデータベースを追加した分だけの課金で済み、データベースの立ち上げに要する構築作業も不要であるため、ビジネス面からもSaaS向けデータストアとして利用する価値が高いと言えます。

　一方、共有スキーマを前提とした本格的なマルチテナント対応を行う場合には、整合性の問題をアプリケーション側で対応する必要はあるものの、Azure Storage ServicesのTableデータストアの利用が適しているでしょう。

　一声にマルチテナント化といっても、一足飛びに対応するのは難しいでしょう。まずはSQL Azureの特徴であるクラウドサービスとリレーショナル・データベースの2面性をうまく活用して、段階的に移行していくことをお勧めします（図2）。