Web アプリケーションをマルチテナント型 SaaS ソリューションに変換する

Web アプリケーションをクラウド・アプリケーションに迅速に変換するための考慮事項と手順のチェックリスト

シングル・テナント型の Web 対応アプリケーションをすでに構築してあるとしても、そのアプリケーションをクラウド環境に対応させて、クラウドのなかで有効に機能させなければなりません。この場合、アプリケーションを本格的なマルチテナント型のクラウド対応 SaaS アプリケーションに変換するために必要な手順をご存知でしょうか?この記事では、サンプル Web アプリケーションを例に、クラウド対応のアプリケーションへの変換を成功させるために必要な考慮事項と変更内容を具体的に説明し、この目標を達成するための手順を概説します。最後におまけとして、著者の会社がマルチテナンシーへの「プラグイン的な」手法となるように設計したソフトウェアを紹介します。

Scott Chate, Vice President, Products, Corent Technology

Fortune 500 企業でのソフトウェア開発、アーキテクチャー、帯域処理、そして管理の実績を持つ、Corent Technology の Scott Chate は、現在、IT 業界でこれまで経験してきたのとは別の側面を、革新的な技術を持った企業家組織で経験しています。Oracle、TransCanada PipeLines、IBM、そして Mercer での管理コンサルティングおよび製品開発を通し、彼は新しい技術を使用して効率性の向上、リスクの管理、機会の有効化に対応する革新的ソリューションを支持し、実装してきました。



2010年 12月 14日

例えば、皆さんが市場に売り出している Web アプリケーションがあるとします。その後、クラウド・インフラストラクチャーでの SaaS (Software as a Service) に関する記事を目にして、業界が向かっている先はクラウド上で SaaS を提供することであると理解したとします。皆さんはクラウド上で SaaS として Web アプリケーションを提供する必要性は認識しており、おそらく顧客からもすでに、SaaS バージョンの製品を提供するように迫られているかもしれません。

ここでの課題は、SaaS への変換を迅速かつ効率的に行うと同時に、採算性を維持、あるいは向上させる必要があることです。

SaaS アプリケーションと通常の Web アプリケーションとの間には考慮しなければならない違いが数多くあります。その違いには、技術に関するものもあれば、SaaS を提供する際に企業が適応しなければならないビジネス・モデルの変更に関するものもあります。

通常の Web アプリケーションと SaaS アプリケーションとの違い

SaaS の最大の特徴は、顧客がソフトウェア・アプリケーションを従量課金制方式で使用できることです。顧客がソフトウェアのライセンスを取得する必要もなければ、ソフトウェアをインストール、ホスト、管理するための準備も必要ありません。このような運用上の側面には、SaaS アプリケーションを提供する組織が対処します。

SaaS 成功の鍵を握るのはマルチテナンシーです

SaaS 企業の CEO たちの言葉: SaaS にとってのマルチテナンシーの必要性

マルチテナンシーは、SaaS ベンダーが成功するための要件です (Salesforce の CEO、Marc Benioff の言葉)。

マルチテナンシーに対応していない SaaS が成功することはあり得ません (OpSource の CEO、Treb Ryan の言葉)。

弊社では、並外れて効果的な (低) コストのコンピューティングの場を実現しました。マルチテナンシーのおかげで、SaaS 業界では最も低い価格となっています (SuccessFactors の CEO、Lars Dalgaard の言葉)。

現在、ASP が盛り返そうとしていますが、クラウド・データ・センターの手法では未だにシングル・テナント・モデルを使用して顧客を隔離しています。シングル・テナント・モデルは、運用するのに多大な費用がかかり、したがって購入するにも極めて高くつくことを意味します (NetSuite の CEO、Zach Neson の言葉)。(マルチテナンシーのおかげで) 弊社の粗利益は 70 パーセントを上回りました。

私たちにとって、マルチテナンシーは実に重要です。マルチテナンシーによって、従来よりも遥かに効率的なモデルが作り出されます (iPipelineの CEO、Tim Wallace の言葉)。

マルチテナンシーは、SaaS というゲームにおける手持ちの掛け金です (Edge Dynamics の前 CEO、Henry Olson の言葉)。

マルチテナンシーによって、サブスクリプション・モデル全体が機能するようになります (THINKStrategies の CEO、Jeff Kaplan の言葉)。

SaaS の基本的な基準を満たすには、アプリケーションに登録できるというだけで十分ですが、実際的な観点からすると、それでは足りません。実際のところ、SaaS アプリケーションはマルチテナント型アプリケーションであることも必要です

この必要性を突き詰めると、単に経済的であるということが理由となっています。主要な SaaS 企業の CEO たちが口を揃えて言うように、マルチテナンシーなくして SaaS ビジネスが成長することはあり得ません (囲み記事を参照)。

SaaS の効率性を高める手段はマルチテナンシーです

効率性を向上させるための主要な手段は、マルチテナンシーです。マルチテナンシーにより、アプリケーションのさまざまなユーザーに対応しながらも、各ユーザーにはそのアプリケーションを独占しているかのように思わせることができます。この概念は、システム上の個々のユーザーに当てはまることからお馴染みのはずですが、SaaS 環境では少し意味が違ってきます。典型的なエンタープライズ SaaS アプリケーションでは、「ユーザー」とは特定の組織の従業員のグループのことで、組織は「テナント」と呼ばれます。これは、単純な Web アプリケーションを組織が購入する場合と似ています。その場合、組織には、そのアプリケーションのユーザーである従業員のグループがあり、組織はアプリケーションの「所有者」です。SaaS モデルでは、組織は所有者ではなくテナントですが、従業員のグループがユーザーであるという点は変わりません。各ユーザーは特定のテナント (組織) と関連付けられ、SaaS は各テナントにそのアプリケーションを独自に所有しているようなエクスペリエンスを提供し、そのテナントに所属するユーザーがそのアプリケーションを使用できるようにします。

クラウド内での仮想化には SaaS が使用されます

単純な Web アプリケーションとクラウド対応 SaaS アプリケーションとの違いには、現在の IT において、容量を最大限に利用するための以下の 2 つの機能が含まれます。

  • マルチテナンシー (前のセクションで紹介しました)
  • ハードウェアの仮想化

アプリケーションを効率化する主要な手段はアプリケーション・アーキテクチャーのマルチテナンシーですが、ハードウェアの仮想化も効率性の向上に効果があります。クラウドは価値の活用という任務を賢くこなすための方法として、仮想化技術を使用することでハードウェアの使用率を向上させ、通常のデータ・センターで実際のマシンを使用した場合に生じる、使われずに残されている容量を減らします。

さらに、クラウドでは、リソースの必要に応じて動的にハードウェアをアプリケーションに割り当て直すこともできます。この弾性 (分単位の短期間になる場合も、月単位の長期に及ぶ場合もあります) により、ハードウェアに関する決定を 1 つのアプリケーションを基に行うのではなく、多数のアプリケーションに基づいて行えるようになります。また、必要なハードウェア容量の予測および管理が容易なものになり、ハードウェアへの投資を無駄なく行えるようになります。

ここからは、従来型の Web アプリケーションを SaaS 対応のアプリケーションに変換するために通常必要となる手順について見て行きます。


Web アプリケーションを SaaS に変換する方法

Web アプリケーションを SaaS アプリケーションに変換するには、以下の 7 つの必要条件を満たさなければなりません。

  1. アプリケーションがマルチテナンシーをサポートすること
  2. アプリケーションがある程度の自動サインアップ機能を備えていること
  3. 登録/課金メカニズムが用意されていること
  4. アプリケーションを効率的にスケーリングできること
  5. アプリケーションとテナントを監視、構成、管理するための機能が用意されていること
  6. 一意のユーザー ID および認証をサポートするメカニズムが用意されていること
  7. テナントごとのカスタマイズをある程度可能にするためのメカニズムが用意されていること

以降のセクションで、上記のそれぞれについて、もう少し詳しく説明します。

マルチテナンシーのサポート

マルチテナンシーは SaaS の効率性を決定付ける鍵です。一般に、アプリケーションは複数のユーザーをサポートするものですが、そのサポートは、すべてのユーザーが同じ 1 つの組織に属することを前提とします。このモデルは SaaS に移行する前は問題ありません。組織がソフトウェア・アプリケーションを購入する場合、そのアプリケーションを使用するのは、その組織のメンバーに限られるからです。けれども SaaS やクラウドでは、同じアプリケーションを多数の組織が使用します。これらのすべての組織は、組織の全ユーザーにそのアプリケーションへのアクセスを許可することができなければならない一方、アプリケーションはそれぞれの組織のメンバーに対し、そのメンバーが属する組織のデータに限り、アクセスを許可しなければなりません。

各組織のデータ・セキュリティーを危険にさらすことなく、複数の組織 (SaaS の用語では、テナント) を同じアプリケーションで共存させることができれば、そのアプリケーションはマルチテナント型アプリケーションということになります。

マルチテナンシーには、いくつかのレベルがあります (下記の図を参照)。

  1. クラウド内での単純な仮想化により、ハードウェアのみを共有
  2. 1 つのアプリケーションで、テナントごとに異なるデータベースを使用
  3. 1 つのアプリケーションでデータベースを共有 (最も効率的な真のマルチテナンシー)
マルチテナンシーのモデル
マルチテナンシーのモデル

1 番目のモデルは真のマルチテナンシーではないという意見もありますが、仮想サーバーを使用したクラウドによくあるモデルであり、マルチテナンシーの形にプロモートされることがよくあります。実際には、このモデルはマルチテナンシーには不十分であり、専用ハードウェアを使用した古い ASP モデルよりもわずかにメリットがあるというだけのモデルです。

最も効率的なのは、アプリケーションがデータベースとアプリケーション・ビジネス・ロジックを完全に共有するモデルです。このモデルを実現するには、データベース・スキーマを変更してテナント ID をすべてのテーブルとビューに追加するだけでなく、あらゆる SQL アクセスを作成し直し、テナントの基準をフィルターに追加するという厄介なプロセスが必要になる可能性があります。コードでこれらの変更を加えなければならない箇所が 1 箇所でも見落とされると、アプリケーションのデータ・セキュリティーが危険にさらされる恐れがあります。

アプリケーション内でデータ・アクセスを行うアプリケーションのほかにも、個々のテナントのデータに対してその特定のテナントからしかアクセスできないようにするために、テナント・フィルタリングを含めるように変更しなければならないアプリケーション (例えば、レポート・ライターやユーティリティー・アプリケーションなど) があるかもしれません。問題となるのは、アプリケーションそのものから直接行われるのではないアクセスです。このようなアクセスは、制御しなければなりません。許可されたユーザーがレポートを作成できる場合には、これらのユーザーが、自分の属するテナント以外のデータにはアクセスできないようにする必要があります。

自動サインアップ

アプリケーションは、何らかの自動サインアップ機能を備えている必要があります。例えば、アプリケーションにテナントを追加するためのビジネス・プロセスとなる、単なるリクエスト・メカニズムであっても構いません。

登録と課金

登録および課金メカニズムを用意してください。SaaS アプリケーションにはその目的上、テナントごとのユーザー数やアプリケーションのオプション、そしておそらく使用時間といった要因に基づく一連の支払いが伴います。したがって、アプリケーションの使用状況を追跡して管理し、課金情報を生成してテナント管理者がアクセスできるようにするための手段が必要です。

アプリケーションのスケーリングと管理

登録数が増加するのに応じてアプリケーションをスケールアップできなければなりません。その当然の手段となるのは、効果的かつ効率的にスケーリングするために必要な多くの機能を具現化するクラウド・インフラストラチャーです。

また、アプリケーションとそのすべてのテナントを監視、構成、管理するための管理機能も提供する必要があります。

ユーザー ID と認証

ユーザーの識別と認証をサポートするために、ユーザーを一意に識別することが可能なメカニズムを用意する必要があります。マルチテナンシーで必要となるのは、システムにサインオンしたすべてのユーザーの身元を確認し、個々のユーザーが所属するテナントを判別することです。したがって、あるユーザーが特定のテナントに所属するユーザーであることを識別するための確定的な関係がなければなりません。このユーザーとテナントの関係は、ユーザーがアクセス可能なデータを制限するための重要な情報となります。

一意性を保証して、個々のユーザーを特定のテナントに属するユーザーとして認識および識別できるようにする手段としては、一般的に E メール・アドレスが使用されます。

認証メカニズムにはさまざまなものがあり、認証メカニズムを統合するにも多様な方法があります。したがって、ユーザーを柔軟に識別できるメカニズムが不可欠です。そうしたメカニズムとして、特定のテナントに対して、そのテナントの既存の LDAP を利用できるようにしたり、SaaS アプリケーションへのシングル・サインオンをサポートするその他のディレクトリー・サービスまたは認証メカニズムを利用できるようにしたりしなければならないことがよくあります。ユーザーを外部認証するこうした手法は重要なものの、識別されたユーザーが、そのユーザーが主張するテナントのメンバーであることを立証するのは SaaS アプリケーションの責任です。

テナントごとのカスタマイズ

テナントがそれぞれに、一意に決まる URL、待ち受けページ、ロゴ、配色、フォント、さらには言語を使用できるようにするには、テナントごとの基本的なカスタマイズをサポートするメカニズムを提供する必要があります。

テナントごとに構成できる内容としては、上記の基本的なものが考えられますが、複数のテナントのニーズを本当の意味で満たすためには、それ以上に詳細なテナントごとのカスタマイズがどうしても必要になってきます。

必要とされる典型的なカスタマイズは、テナントが社内アプリケーションで行うのと同じようなカスタマイズです。例としては、フィールドの追加やテーブルの追加、特殊なビジネス・ロジックの構築、他のアプリケーションとの統合などが挙げられます。このようなテナントごとのカスタマイズを行っても、個別のインスタンスを作成する必要がないため、マルチテナント設計の効率性を損なうことはないという事実が、SaaS アーキテクチャーの高い能力を示しています。


パフォーマンスに関して考慮すべき問題

一般に、マルチテナント型 SaaS アプリケーションのパフォーマンスの問題は、同等のアクティビティー・レベルを持つ同数のユーザーに対応する通常の Web アプリケーションに見られるパフォーマンスの問題と変わりません。Web アプリケーションでの必要な容量の増加に対処するためのベスト・プラクティスはさまざまにあります。通常は、これらの Web アプリケーションでのベスト・プラクティスはすべて、マルチテナント型 SaaS アプリケーションにも適用することができます。容量増加に対応するための手法で一般的に使用されるのは、水平スケーリングと垂直スケーリング、そして一連のサーバーでのロード・バランシングです。

水平/垂直スケーリング

クラウド・インフラストラクチャーには、このようなタイプのスケーリングを動的かつ自動的に行えるようにするための機能が多数用意されており、必要なときにはリソースが追加され、少ないリソースでパフォーマンスのサービス・レベル・アグリーメント (SLA) を満たせるようになるとリソースが削減されます。これらの機能によって実現される弾性は詳細な調整をすることが可能で、十分に活用されることがなさそうなリソースは使用せずにサービスを提供することができます。

  • 水平スケーリングは一般にアプリケーション・サーバー層に使用されます。
  • 垂直スケーリングは一般にデータベース層に使用されます。

データベースのクラスタリング

SaaS アプリケーションの場合、その製品がよく使われるようになると、ユーザーの総数はかなりの数になります。その場合、ある特定の数まで達すると、データベースの垂直スケーリングでは対応しきれなくなります。多くのデータベース技術では、同じデータベースでより多くの容量を使用することができるクラスター・データベース・モデルを提供しています。DB2® には、クラスター・データベース・モデルで有効に機能するオプションが複数あり、これらのオプションを使用してデータベース・クラスターを作成することができます。

地理、分割、同期

一方、SaaS アプリケーションとそれを使用するユーザー集団によっては、より適した手法が他にもあります。SaaS には、その性質上どこからでもアクセスすることができるため、ユーザーの集団が遥か彼方に存在する場合もあります。この長距離ネットワーク・トポロジーは、パフォーマンス劣化の原因となり得ます。

このような場合には、異なる地域に存在するクラウドを使用して、データを分割するか、同期化によって一貫性を維持するようにしたほうが望ましい結果を得られるかもしれません。どの方法が適しているかは、個々のアプリケーションの性質によって決まります。なかには、長距離の同期には適さないものもあります。

別個のデータベース

データベース容量が需要を満たせなくなったときに採る方法として (少なくとも SaaS アプリケーションにとって) 最も抜本的な方法は、別個のデータベースを構築することです。マルチテナント型 SaaS アプリケーションを必要とする誰もが考慮しなければならないことは、別個のデータベースを構築することによって、テナントごとに 1 つのデータベースをサポートするという受け入れ難い状況がもたらされ、それが、マルチテナンシーが回避しようとしている非効率性にそのまま結び付く可能性があるかどうかです。

アプリケーション・サーバーを複数に分けなければならない場合に、それぞれのサーバーからは 1 つのデータベースしか利用できなければ、マルチテナンシーの効率性はさらに失われていきます。競争の激しい市場では、マルチテナンシーの効率性はSaaS 企業が成功する上でなくてはならないものなのです。

負荷分散されたクラスターの効率性を設計によって維持します

何らかの理由で別個のデータベースを使用せざるを得ないとしても、効率性をできるだけ維持する 1 つの方法は、負荷分散されたクラスター内のアプリケーション・サーバーのどれもが、複数のデータベースのなかから適切なデータベースにアクセスできるようなマルチテナンシー設計にすることです。すべてのアプリケーション・サーバーが、それぞれがサポートするユーザー・セッションのために任意のデータベースに接続することができれば、負荷分散されたクラスターの効率性を保つことができます。これにより、複数のデータベースがあるという制約のなかでも優れた効率性を維持することができます。

容量だけが要件ではありません

複数のデータベースを使用する正当な理由は、容量以外にもあります。例えば、セキュリティーに対する要求が高い特定のテナントのために、データベースを暗号化する必要がある場合などです。この場合、容量は問題ではないので、本質的にあまり効率的でないモデルが要求されている場合でも、効率性を可能な限り最大にするような設計をすることが重要になります。


セキュリティーに関して考慮すべき問題

調査に次ぐ調査では、一般に、セキュリティーは SaaS アプリケーションに登録している人にとって最大の懸念事項であるか、それにかなり近い重大な懸念事項となっています。どの SaaS プロバイダーもセキュリティーを無視することはできませんが、データ・セキュリティーの概念は SaaS アプリケーション自体のコンテキスト内に限られると考えられがちです。

ほとんどの SaaS アプリケーションのアーキテクチャーは、基本的な要件として、あるテナントが別のテナントのデータを見られないようにするデータ・セキュリティー対策を取っていますが、そこには以下の問題があります。

  • SaaS アプリケーションに備わっていなければならない重要な機能の 1 つは、他のアプリケーションと統合および対話する機能です。
  • SaaS アプリケーションと統合および対話するアプリケーションのなかには、SaaS プロバイダーの制御が及ばない外部アプリケーションもあります。
  • SaaS アプリケーションのアーキテクチャーのすべてが外部アプリケーションとのアクセスしやすさを考慮して設計されているわけではありません。

SaaS アプリケーションと統合および対話するアプリケーションが、データにアクセスしたり、データを共有したりしなければならない社内アプリケーションである場合もあります。また、そのようなアプリケーションが、傾向分析のためにデータをマイニングする分析ツールやレポート作成ツールである場合もあります。データベース管理者が使用するユーティリティー・ツールでさえも、テナントがそのツールを使ってそのテナントに属していないデータにアクセスしたり、さらに最悪なことにデータを操作したりできるとしたら、セキュリティーが懸念されます。

SaaS のベスト・プラクティス・アーキテクチャーで考慮しなければならないことは、アプリケーションがデータへのアクセスすべてを制御できるとは限らないという点です。したがって、SaaS アプリケーションを介したアクセスであるか、あるいは外部アプリケーションを介したアクセスであるかに関わらず、各テナントのデータをセキュアにすることができるメカニズムを用意する必要があります。


技術スタックの選択

技術スタックを決定するときには常にトレードオフが付いて回るものですが、SaaS アプリケーションの場合には尚更のことです。なぜなら、すべてのテナントを考慮して決定しなければならないためです。このセクションでは、技術スタックを決定する際に考慮すべき事項を説明します。

オペレーティング・システムに関する考慮事項

Web アプリケーションの場合、オペレーティング・システムとの対話はブラウザーを介して行われるため、オペレーティング・システムはユーザーとの関連性が最も少ないでしょう。けれども、オペレーティング・システムの決定を左右する可能性のある財務上および技術上の考慮事項がいくつかあります。

  • OS に依存する特定のコードへの依存関係がある場合、選択肢は限られてきます。
  • また、外部アプリケーションとの統合が共通の要件であり、ある特定の OS で統合したほうが他の OS で統合するよりも望ましい場合にも、選択肢は限られます。

クラウドの厳しい経済的側面によって、ライセンス料金が低く、パフォーマンスに優れた OS を選択することが常に要求されます。Web アプリケーションのスケーリングを行う場合、その主要な手段となるのは水平スケーリングです。つまり、SaaS アプリケーションの利用者が増えるにつれ、Web アプリケーション・サーバーの総インスタンス数が増え、それが直接、運用費に結び付くということです。

データベースに関する考慮事項

Web アプリケーションのデータベースにしても、エンド・ユーザーにとってはそれほど重要な懸念事項ではありません。それは、データベースとの対話はブラウザーで行われ、アプリケーションがユーザーのデータを保管および取得できる限り、ほとんどユーザーには関係してこないからです。

この場合にも、アプリケーション開発者に関連してくる財務上、技術上の考慮事項があります。まず、アプリケーションがデータベースの特定の機能に依存する場合には、選択肢が限られてきます。

データベースの選択は、アプリケーション設計上のさまざまな理由で重要になる場合があります。また、SaaS 環境の特定の需要によっても左右されます。

SaaS アプリケーションでのデータベースに対する需要は、最終的に登録されるユーザーの数を考えただけでも Web アプリケーションよりも高いものがあるため、データベースのスケーラビリティーが極めて重要になります。通常、データベースのスケーリングが行われるのは単一のインスタンスに対してですが、次第に要件が厳しくなるアプリケーションに対しては、より強力なデータベース・サーバーを使用することで対処します。しかし、SaaS アプリケーションに要求されるスケーラビリティーには、垂直スケーリングでは対応しきれなくなる可能性があります。そこで、データベースのスケーラビリティーにおける次のステップとして必要になるのがクラスタリング機能です。

クラウド環境でデータベースをクラスタリングするための機能が、データベースの選択を左右することもあります。候補として有力なのは、多種多様な OS で実行できることで垂直スケーリングを可能にし、複数インスタンスによるクラスタリングと冗長化によってスケーリング方法を柔軟に選択できる DB2 です。クラウドには、例えば DB2 HADR (High Availability Disaster Recovery) クラスターをセットアップすることができます。

アプリケーション・サーバーに関する考慮事項

アプリケーション・サーバーとエンド・ユーザーとの対話はブラウザーを介してのみ行われるため、アプリケーション・サーバーの選択も、他の技術スタックの決定と同様、主に SaaS アプリケーション開発者の決定に委ねられます。けれども、アプリケーション設計上のさまざまな理由が、その選択に重要な違いをもたらすこともあります。さらに、SaaS 環境に対する特定の要求がアプリケーション・サーバーの選択に影響を及ぼす可能性もあります。

例えば WebSphere® のようなアプリケーション・サーバーが持つ特殊な機能やアドオン・コンポーネントを利用するアプリケーションは、そのアプリケーション・サーバーをクラウドでも使用しなければなりません。

ある特定のアプリケーション・サーバーを選択する理由付けは、通常、アプリケーション・ライフサイクルの初期段階で行われます。それらの理由としては、そのアプリケーションが特定の機能を利用できるからという理由や、そのアプリケーションにとって重要なサード・パーティーのアドオンや統合機能があるからという理由、そして場合によっては、単に組織の専門家および社内標準によって技術スタックの特定のコンポーネントを使用するように規定されているからという理由などがあります。

SaaS/クラウド環境で使用する技術スタックを選択および構成する際の決定が好結果をもたらすためには、技術による影響と経済による影響のバランスを取ることが必要です。


技術革新の鍵となる柔軟性

使用する技術スタックに関する決定および妥協を行えること、そして後でこれらの決定を再考できることは、SaaS アーキテクチャーが有する貴重な能力の 1 つです。技術の変化に伴い、主要なクラウド・プロバイダーは新しいミドルウェア・アプリケーションや機能を取り込んでいくため、これらのものを自らの SaaS アプリケーションに合わせて適応できることが、SaaS/クラウド環境を使用するメリットになります。

特定の技術スタックに縛られるような決定を強いる SaaS アプリケーション・アーキテクチャーは、SaaS アプリケーションの進化および適応能力を低下させることになります。SaaS アプリケーションに必要なアジリティーおよび柔軟性をもたらすには、サービス指向アーキテクチャーの主要な概念がぴったり適合します。サービス指向アーキテクチャーの疎結合の概念は柔軟性をもたらし、柔軟性によって戦略的で巧妙な進化が可能になるからです。

この記事の残りの部分では、Corent 社の Multi-Tenant Server™ を例に、オープソースの課金用 Java™ Web アプリケーションを最小限の作業でマルチテナント型 SaaS バージョンに変換する方法を説明します。


Corent の Multi-Tenant Server によるアプリケーションの自動 SaaS 化

クラウド・プロバイダーは豊富な機能を提供しており、ほとんどすべての Web アプリケーションに対処することができます。アプリケーションを完全なマルチテナント型 SaaS アプリケーションに変換するには、一般にアプリケーション・コードを隅々まで変更し、データベースを再設計して構成し直すという作業が必要になってきます。

Corent の Multi-Tenant Server では、ISV は別の方法を採ることができます。それは、ミドルウェア層を使用して必須のマルチテナンシーを提供するというものです (この方法により、既存のコードへの投資を活かすことができます)。ここからは、jBilling というアプリケーションをマルチテナント型 SaaS バージョンに変換するために必要な 4 つのステップを説明します。jBilling は、よく使用されているオープンソースの Java Web アプリケーションであり、典型的なシングル・テナント型アプリケーションを代表する例です。

ステップ 1. データベース・スキーマを抽象モデルに変換する

図 1 に、Web アプリケーションの典型的なスタックを示します。アプリケーションがデータベースと通信する手段としては、Hibernate などのデータ永続化層がよく使用されています。

図 1. クラウドでの典型的な Web アプリケーション・スタック
クラウドでの典型的な Web アプリケーション・スタック

アプリケーションをマルチテナント型アプリケーションに変換するためには、データベースを設計し直して、テナント ID データを管理するためのフィールドを追加しなければなりません。テナント ID データは、テナントを基準にデータをフィルタリングできるようにする上で必要となります。

既存のアプリケーション・データベースのスキーマを読み取るには、SaaS-Factory™ アプリケーションを使用します。SaaS-Factory はスキーマを読み取った後、そのデータベースのモデルを作成します。そして、このモデルに従って新しいデータベースを MySQL で生成し、そのデータベースのテーブルに TenantID フィールドを追加します。この時点で、テナント情報用のテーブルを含め、Multi-Tenant Server が使用する複数のテーブルが追加で作成されます。

図 2. MetaModel データベース・スキーマの作成
MetaModel データベース・スキーマの作成

MetaModel データベースは、オリジナルのアプリケーションとまったく同じテーブルとフィールドを持つように見えるため、オリジナルのアプリケーションは MySQL データベースを使って、引き続き、前とまったく同じように MetaModel データベースを操作することができます。モデルを基にした実際のデータベースは、マルチテナント型アプリケーションに必要な TenantID フィールドを追加して生成することができます。

MetaModel データベースは抽象化に過ぎないため、実際にはデータを格納しません。MetaModel データベースは単なるモデルなのです。したがって、実際のデータベースを生成する場合には、サポートされている RDBMS (Relational Database Management System) であれば、どの RDBMS を生成することもできます。このことは、ISV が特定の機能を使用するため、あるいはアプリケーションのパフォーマンスを向上させるために、他の RDBMS (例えば DB2) を選択して技術スタックを変更したいと思っている場合に役立ちます。

ステップ 2. ユーザー認証プロセスを拡張する

マルチテナント型 SaaS アプリケーションに例外なく必要となるのは、認証済みユーザーに必要なセッション情報を管理して、それらのユーザーが属するテナントを明らかにすることです。アプリケーションには多くの認証方式があるため、マルチテナント型に変換するアプリケーションを分析し、そのアプリケーションの認証方式を理解しなければなりません。

Corent の Multi-Tenant Server™

Corent の Multi-Tenant Server では、顧客がアプリケーションを再作成することなく、簡単に既存のシングル・テナント型 Web アプリケーションをクラウド対応の完全なマルチテナント型 SaaS ソリューションに変換できるようにしています。これは Corent が提供する、最も効率的でコスト効果の高いマルチテナンシー手法です。マルチテナンシーに対するこのプラグイン・ミドルウェア・ソリューションは、セキュアでスケーラブルなソリューションであり、サービス・デリバリーのコストを劇的に削減します。

技術スタックは、顧客の好みに応じて柔軟に選択できるようになっているため、OS、データベース、アプリケーション・サーバーを自由に選択して使用することができます。Multi-Tenant Server の柔軟なアーキテクチャーでは、社内あるいは任意のタイプのクラウドにどのような形態で SaaS アプリケーションをデプロイするかを選べます。したがって、SaaS アプリケーションを公開サービスとしてデプロイすることも、あるいは限られた使用者にサービスを提供する Private SaaS™ としてデプロイして、例えば大企業内の各部門をテナントにすることもできます。

Multi-Tenant Server には、テナントのプロビジョニングおよび管理、そして SaaS アプリケーションの監視などを行うための SaaS-Cockpit™、さらにはテナントごとのカスタマイズや SaaS アプリケーションの強化を行うための SaaS-Factory™ が付属しています。Corent のソリューション一式を利用することにより、アプリケーションの SaaS 変換を大幅に迅速化することができます。

Corent と IBM® では現在、ISV の Web アプリケーションを IBM SBDT Cloud で実行されるマルチテナント型 SaaS ソリューションに変換し、ISV が SaaS ソリューションの成果を体験できるように、限られた数の適任候補者に無料の概念検証変換を提供しています。

ステップ 1 では、テナントとユーザーの関係をアプリケーション・データで維持できるように、テナント・テーブルを作成してユーザー・テーブルを追加する方法を説明しました。その先にある最終目標は、ユーザーのログオン時に、そのユーザーを対応するテナントとも突き合わせ、一致するテナントの TenantID をセッション情報に組み込むようにアプリケーションのユーザー認証プロセスを拡張する方法を実装することです。

この目的を達成するには多数の方法があり、どれを選ぶかは、アプリケーションの実装次第です。Tomcat をアプリケーションのサーブレット・コンテナーとして使用している場合は、コンテナー管理認証を使用して Multi-Tenant Server で実行されるビジネス・ルールを開始し、ユーザーに関連付けられた TenantID の参照を行うことができます。あるいは、サーブレット・フィルターを使用して、スレッド・ローカルな変数である TenantID を検出して設定するという方法もあります。jBilling を使用するこの例では、アプリケーションがそのユーザー・テーブルに照らし合わせて検証することによって、直接認証を処理します。したがって、認証を拡張するための方法を実装するために必要だったのは、認証コードに単純な変更を加えることだけでした。追加した変更は、新しいテーブルに保管されたユーザーのテナント情報を参照するプロセスを組み込むためのものです。

認証済みユーザーとそのユーザーが属する TenantID を把握すれば、ユーザーがそのテナントに属するデータにしかアクセスできないようにフィルタリングする情報としては十分です。

ステップ 3. データベース接続を構成する

Corent の Multi-Tenant Server がベースとするサービス指向アーキテクチャーでは、MetaModel データベース (ステップ 1 で説明) を使用します。この MetaModel を抽象化層として使用して、アプリケーションが元々使用しているデータベースをモデル化し、アプリケーションのデータベース通信を実際のデータベース実装ではなく、MetaModel 抽象化層にリダイレクトします。そのための方法は、単に jBilling のJDBC 接続を再構成して、実際の MySQL データベースの代わりに MetaModel データベースにアクセスするようにするだけです。Hibernate を使用するアプリケーションの場合には、Hibernate の Corent 方言を構成します。

以上の変更を加えた結果、アプリケーションのデータベース呼び出しは MetaModel データベースに送られるようになりました。これらの SQL イベントは、Corent Agile Controller™ によってインターセプトされて、Corent の ADBC™ (Agile DataBase Connector) に渡されます。ADBC は、アプリケーションが MetaModel データベースに対して実行依頼した SQL 文を取得して構文解析してから、セッション内で SQL を実行依頼したユーザーの TenantID を検索するためのフィルター基準を追加します (例えば、TenantID = <myTenantID>)。これにより、共有データベース内のデータのセキュリティーが常に厳重に維持されるというわけです。ReportWriter などの外部アプリケーションが接続した場合でも、その外部アプリケーションから見ることのできるデータは、依然としてそのテナントに属するデータに限られます。ログインしているユーザーはわかっているので、どのアプリケーションからアクセスしたとしても、そのユーザーがどのテナントに属しているかは既知であり、適切なフィルターが適用されます。

SQL 文の操作は、その SQL 文が MetaModel データベースに対して実行依頼されて、ユーザーのテナントが既知になってから行われるため、Corent Agile Controller は SQL 文をインターセプトし、例えばテナント固有のプロセスおよび構成を参照するなどの、より高度な操作を実行することができます。したがって、テナントごとに特定のアクションを実行することも可能です。さらに、ある特定のテナントだけは DB2 データベースを使用するように別のデータベース接続に置き換えて、残りのテナントには引き続き MySQL データベースを使用させることもできます。あるいは、追加の SQL 操作によって、あるテナントが取得可能なデータを 90 日以内に入力されたレコードに制限することもできます。このようなテナントごとのカスタマイズは、いずれもオリジナルのアプリケーション・コードを変更することなく、Multi-Tenant Server に組み込まれた Agile Rules Engine™ を使用して行うことができます。

図 3. テナントごとのカスタマイズ構成
テナントごとのカスタマイズ構成

jBilling アプリケーションの全体的な変換は、アプリケーションにマイナーな変更をいくつか加えるだけで完了しました。これらの変更は主に、セッション情報にテナント情報を組み込み、データベース接続を Multi-Tenant Server に向けるように変更するためのものです。以下に、jBilling の変更内容を要約します。

  • オリジナルのアプリケーション
    • ソース・ファイルの数: 897 (Java および jsp)
    • コードの合計行数: 76,621
  • 変換後のアプリケーション
    • 追加したソース・ファイルの数: 2 (標準テンプレート)
    • 変更したコードの行数: 100 未満
    • アプリケーションのビジネス・ロジックの変更: なし

jBilling の変換には 1 週間かかりませんでした。これには、変更する必要があるコードの箇所を判断するための分析および準備の時間も含まれます。変更の多くは、Hibernate などのデータ永続化層を使用している場合には不要な、JDBC によるアクセスのための一連の Java コードでの単純な 1 行の変更の繰り返しでした。

ステップ 4. 新しいマルチテナント型 SaaS アプリケーションをクラウドにデプロイする

この段階まで来ると、SaaS-Factory を使用して、指定のサーバー (クラウド内のサーバーを含む) に SaaS アプリケーションをデプロイすることができます。

アプリケーションおよびデータベース用のサーバーを選択すると、ターゲット・データベースが (この jBilling アプリケーションの場合には、Windows® サーバー上の MySQL データベースとして) 生成されて、完全に構成された Multi-Tenant Server アプリケーションが .WAR ファイルのセットとして、選択したアプリケーション・サーバーにデプロイされます。Multi-Tenant Server は最近の J2EE Servlet コンテナーのどれとでも連動し、WebSphere Application Server でも使用が認定されています。

デプロイメントが完了すると、アプリケーションは複数のテナントを処理できるようになります。その一方、オリジナルのアプリケーションには、テナントを管理したり、マルチテナント型アプリケーションを監視したりするための管理インターフェースがありません。

SaaS-Factory は、これらの基本的なマルチテナント・サービスを提供する、SaaS-Cockpit™ というコンパニオン・アプリケーションも生成してインストールします。メイン・アプリケーションと同じ MetaModel データベースにアクセスする SaaS-Cockpit には、管理画面があります。この画面で、テナントのプロビジョニング、テナント管理者アカウントの割り当て、テナントごとに使用できる各種アプリケーション構成の基本パラメーターの構成を行うことができます。さらに、SaaS-Cockpit にはテナントとそのユーザーを監視し、レポートを作成する管理機能も備わっています。SaaS アプリケーションに共通する特性の 1 つに、登録されているテナントに対して課金を行わなければならないことがあるため、課金を行う機能や外部課金システムとの統合を行う機能も用意されています。

図 4. 新規 SaaS アプリケーションをクラウドにデプロイするための構造
新規 SaaS アプリケーションをクラウドにデプロイするための構造

このレベルのデプロイメントは、SaaS アプリケーションのデプロイメントに関する限り、かなり基本的なものです。アプリケーションの特性は、変換後もそのまま維持され、クラウド管理ツールを使用してテンプレートを作成したり、アプリケーションのインスタンスを伝播したりするなどの一般的なデプロイメント・シナリオを使用して、アプリケーションのスケーラビリティー、弾性、レジリエンシー、そして冗長性の要件を満たす運用アーキテクチャーをデプロイすることができます。

典型的な SaaS アプリケーションでは、ロード・バランサーを介して一連のアプリケーション・サーバーにアクセスし、接続するデータベース・サーバーは 1 台である可能性が考えられます。冗長性とスケーラビリティーをもたらすために、データベース・サーバー自体が複数のデータベース・サーバーからなるクラスターとしてデプロイされることもあります。

IBM DB2 が提供するいくつかの技術および構成は、レジリエンシーと保証された復旧時間を実現するためや、データベースの負荷を分散できるようにするために使用することができます。

  • DB2 HADR (High Availability Disaster Recovery) 構成は、スタンバイ・データベースを読み取り専用データベースとして使用することにより、可用性のレジリエンシーとある程度のロード・バランシングの両方を提供することができます。
  • IBM pureScale 技術と TSA (Tivoli System Automation) を使用すれば、データベース環境をクラスタリングして複数のノードで処理の負荷を共有することができますが、これらのノードにはハードウェアと OS の構成に関する制限が追加されます。

データベースの可用性およびフェイルオーバー機能は、SaaS アプリケーションではより高度なものとなってきています。それは、顧客の構内に配置される従来のソフトウェアと比べ、サービス停止の影響を受ける顧客/テナントの数が多いためです (図 5 を参照)。

図 5. スケーラブルでレジリエンシーのあるクラウド運用のための SaaS デプロイメント・アーキテクチャー
スケーラブルでレジリエンシーのあるクラウド運用のための SaaS デプロイメント・アーキテクチャー

傾向としては、オフラインでのデータ再編成、スキーマの進化、バージョン・アップデート、そして激しい負荷変動にも関わらず、アプリケーションの実行を継続可能にする機能が求められています。IBM の pureScale 技術は、z System の世界から AIX® および Linux® へと移行しつつあり、これまで専用メインフレーム環境にしか適用されなかったような容量処理およびアップタイムを実現可能にしています。


まとめ

IT 業界の SaaS への進化は現在進行中ですが、お察しのとおり、すでに IT の全体像に大きな変化をもたらしています。クラウド・コンピューティングは他の IT の動向とは比べ物にならないほどの速さで成長しています。そしてその成長の推進力となっているのが、SaaS です。この IT 業界での推移により、企業はそのビジネス組織を再考し、クラウド中心の IT 世界でのサービス・デリバリーについて新しい見方をするようになってきています。ソフトウェア・ベンダーにとっては、この推移を理解し、SaaS に移行できるように準備して実行に移すことが急務となっています。そうでなければ、デジタル化の歴史の塵の山に取り残されてしまいます。

クラウドでの SaaS モデルは、技術とビジネスに関する考慮事項という両方の点で、従来のソフトウェア・ベンダー・モデルとは一線を画しています。これらの違いがあることから、SaaS への移行は ISV にとってリクスの高い取り組みです。けれどもリスクを減らし、製品化までの時間を短縮するために、ISV は SaaS への移行を支援する実証済みの技術、製品、そしてパートナーを活用することができます。

謝辞

この記事の作成に大いに貢献し、たくさんのアイデアとアドバイスを提供するとともに、記事のレビューに時間を割いてくれた Mike Oliver 氏、Rob Brown 氏、Mark Joncich 氏、Kaiser Saeed 氏、Feyzi Fatehi 氏、そして編集を手伝ってくれた Aimee Dean 氏に多大なる感謝の意を表したいと思います。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Java technology, Open source, Information Management
ArticleID=619310
ArticleTitle=Web アプリケーションをマルチテナント型 SaaS ソリューションに変換する
publish-date=12142010