Frederick Chong and Gianpaolo Carraro
Microsoft Corporation

April 2006
日本語版最終更新日 2006 年 10 月 20 日

対象：
   アプリケーションアーキテクチャ
   サービスとしてのソフトウェア (SaaS)

要約　本稿では、ソフトウェアの配布モデルとしての「サービスとしてのソフトウェア (SaaS：Software As A Service) 」の概要と、SaaSアプリケーションのアーキテクチャの全体構成を説明します。さらに、SaaSの開発と提供に関する問題点と利点についても議論していきます。

目次

はじめに
サービスとしてのソフトウェアとは何か
サービスとしてのソフトウェアを考える
ビジネスモデルの変更
シングルインスタンス／マルチテナントアーキテクチャの3つの性質
ソフトウェアのサービス成熟モデル
成熟性レベルの選択
全体的なアーキテクチャ
メタデータサービス
セキュリティサービス
認証
承認
マルチテナントデータモデルの詳細
スケーラビリティ
運用組織
共有サービス
モニタリング
結論
謝辞
フィードバック

はじめに

「サービスとしてのソフトウェア」この言葉は、皆が口にします。 ソフトウェア業界誌の誌面は、「サービスとしてのソフトウェア (Saas：Software As A Service) 」の記事でいっぱいです。それらの記事では、SaaSによる「革命」や、SaaSで「広がる世界」といった語句が使われています。 ほとんどの人は、SaaSが何なのかということは漠然とは知っていて、その影響が大きいであろうことも知っているでしょう。 しかしSaasとは何かを実際に定義できる人はわずかで、その構築方法を知っている人は、ほとんどいません。

Saasがアプリケーションの配布モデルとして将来的有望なのに、実際、それを実現しようとする手がかりとするガイダンスが少ないのはなぜでしょうか。

私たちは、SaaSがソフトウェア業界において大きな影響を及ぼしていくだろうと信じています。なぜなら、SaaSはソフトウェアの構築、売買、そして使い方を大きく変えるからです。 しかしこのようなことが起きるためには、ソフトウェアベンダーにとって、SaaSアプリケーションをうまく開発するための資料や情報が必要です。

本稿は、Microsoftによる一連の記事において、SaaSとは何かを紐解き、そのガイダンスを提供するさわりとなる部分です。また、SaaSアプリケーションを設計する際の、実際的なガイダンスでもあります。 本稿では、SaaSの概要や、SaaSの提供者にとっての問題点と利点を説明します。将来の記事では、より詳細で幅広いトピックを言及していくことになるでしょう。

本稿では、まず単純に、「サービスとしてのソフトウェアとは何か」という問いかけから始まります。そして将来、SaaSベンダーとなるものが「従来のソフトウェアとは根本的に何が違うのか」を理解するために知っておきたい「概念の変化」について説明していきます。 次に、「サービスとしてのソフトウェア」が実世界において収益を産み出せるかどうかを確かめるため、SaaSビジネスモデルを見ていきます。

本稿は、アーキテクチャに関する記事なので、SaaSアプリケーションのアーキテクチャにもっとも多くの誌面を割いて扱います。 ここでは、SaaSにおける4つの成熟モデルを考えるときに、主要な性質に焦点を当てます。その性質とは、「構成可能」、「マルチテナント効率」、「スケーラビリティ」です。 まずは、Saasアーキテクチャのコンポーネントを全体的に調べていきます。そして次に、SaaSアーキテクトが直面する典型的な問題点を詳細に見ていきます。その問題点とは、マルチテナントアプリケーションのデータモデルを拡張するための機構の提供です。

最後に、配布したあとにSaaSアプリケーションをサポートする際の、運用上の問題点を簡単に扱います。

サービスとしてのソフトウェアとは何か

今日に至っても、SaaS (Software As A Service) の正確な定義は議論されており、5人に尋ねれば、恐らく、5つの異なる答えが返ってくることでしょう。 それでも、ほとんどのエキスパートは、従来のパッケージソフトやWebサイトとSaaSとの違いを区別する、わずかな基本原則には同意するでしょう。 もっとも単純に、「サービスとしてのソフトウェア」を表現すると、次のようになります。

「ソフトウェアはホストされたサービスとして配置され、インターネットを通じてアクセスするもの」

この定義の意味を、少し考えてください。 この定義では、特定のアプリケーションアーキテクチャを規定していません。 技術やプロトコルについても何も言っていません。 ビジネス指向と消費者指向というサービスの違いにも触れていませんし、特定のビジネスモデルを要求するわけでもありません。 この定義によると、サービスとしてのソフトウェアかどうかを区別する重要な特徴は、「アプリケーションのコードが存在する場所」と「どのように配置されてアクセスされるのか」という点です。

(この定義は、少し単純にしすぎたのではないかと思っていますか？　確かにそうですね。のちほど、きちんと設計された成熟したSaaSアプリケーションを定義し、SaaSとは何かを区別するいくつかの性質に焦点を当てていきます。)

この定義によると、あなたがSaaSという分類には入らないだろうと思っている多くのサービスやアプリケーションも、SaaSに含まれることになります。 たとえば、Microsoft Hotmailのような、Webベースの電子メールサービスを考えてみましょう。 あなたがSaaSについて考えるとき、Hotmailは、すぐに思い浮かんでくる例ではないかもしれません。しかしHotmailは、SaaSの基礎的な基準をすべて満たします。 ベンダーはすべてのプログラムロジックとデータをホストしていますし、Webベースのユーザーインターフェイスにより、エンドユーザーがインターネットを通じて、このデータへとアクセスできるようにする機能を提供しています。

一般的なものから特殊なものへという考え方をすれば、サービスとしてのソフトウェアは、次の2つの大きな分類に分けることができます。

• 基幹業務サービス　 規模を問わず、企業や組織に提供されるサービスです。 金融システムやサプライチェーン管理、顧客管理といったビジネスプロセスを効率化することを目指した場合、基幹業務サービスは、規模が大きくてカスタマイズしたビジネスソリューションになることが多々あります。 これらのサービスは一般に、サービス契約を結んだ顧客へと売られます。

• 消費者向けサービス　 一般消費者向けに提供されるサービスです。 消費者向けサービスは、ときにはサービス契約としても売られますが、多くは、広告運営によって、消費者によるコスト負担はなしで提供されます。

本稿では、基幹業務アプリケーションの開発に関わるアーキテクチャとビジネスの問題、そしてその概念を説明していきます。提示する例も、基幹業務アプリケーションに関するものです。 しかしマルチテナントのカスタマイズ性や拡張性、データのスケーリングや分離といった問題は、消費者向けのサービスでも同様に生じます (この場合、消費者向けサービスのほうが、解決が簡単な傾向があります) 。そのため、消費者向けSaaSを提供しようとしている開発者にとっても、本稿を読むことで得られるものはあるでしょう。

サービスとしてのソフトウェアを考える

所有する (on-premise) ソフトウェアからサービスとしてのソフトウェアへと移行する場合、ソフトウェアベンダーは、「ビジネスモデル」、「アプリケーションアーキテクチャ」、「運用組織」という3つの相互関係をもつ範囲についての考え方を変えなければなりません (図1を参照) 。

図1　ソフトウェアベンダーが考え方を変える必要がある範囲

次の3つのセクションでは、おもに、SaaSにおけるアプリケーションアーキテクチャに焦点を当てながら、それぞれの範囲の変化をより詳細に見ていきます。

ビジネスモデルの変更

ビジネスモデルは、次に示す1つ以上の変更を伴うことになります。

• ソフトウェアの「所有権」を、顧客から外部のプロバイダへと移すこと

• 技術的な設備や管理 (すなわちハードウェアと専門サービス) に対する責任を、顧客からプロバイダへと再配分すること

• 特殊化と規模の経済によって、ソフトウェアサービスを提供するコストを削減すること

• ソフトウェアを導入できる最低価格を引き下げることで、より小規模なビジネスの「ロングテール」をターゲットにすること

SaaSによる利益を現実のものにするためには、プロバイダと顧客の双方が考え方を変えなければなりません。顧客の考え方を変える手ほどきをするのも、プロバイダの責任です。

ソフトウェアは誰のものか

ほとんどのソフトウェアは、ここ数十年同じ方法で売られ続けています。 顧客はソフトウェアを使うためにライセンスを購入し、ハードウェアへとインストールします。そのハードウェアは顧客の所有物、もしくは顧客の管理下にあるものです。ベンダーはライセンス条項あるいは保守契約に則ってサポートを提供します。 誠実なソフトウェア売買では、「ライセンス」という概念は、少し専門的だと言えます。 法律上、顧客はソフトウェアの複製を利用する権利を購入しているだけです。しかし実際には、顧客がソフトウェアを「所有している」ようであり、しばしば、実際にそうであることを望んでいます。

ソフトウェア市場の環境を構成する「製品としてのソフトウェア」というモデルから考えれば、サービスとしてのソフトウェアという考え方は、異色のものに感じることがあります。 顧客には、ソフトウェアを完全に「所有する」という代わりに、他の誰かのサーバーで実行されているソフトウェアに対するサービス契約に対する支払いが必要で、契約を切れば、ソフトウェアは使えなくなってしまうということが告げられます。 そのため、契約を見込めそうな顧客に対して、SaaSが従来のモデルよりも、いかに経済的利益が大きいかということを直接定量化して納得してもらうということが極めて重要になってきます。

ITに対する責務の移転

一般に、組織では、情報化 (IT) の予算は、次に示す3つの大分類に配分されます。

• ソフトウェア　組織がコンピューティングや情報処理に利用する実際のプログラムやデータ

• ハードウェア　ソフトウェアにアクセスする手段を提供するデスクトップコンピュータ、サーバ、ネットワーク機器、モバイルデバイス

• 専門サービス　システムが停止することなく可用性を保証する、テクニカルサポートスタッフやコンサルタント、ベンダー窓口のような人材や機関

もちろん、これらの3つの要素のうち、IT構成の最終的なゴールである情報化にもっとも直接関係してくるのはソフトウェアです。 ハードウェアや専門サービスは、IT環境において重大かつ重要な要素ではありますが、ソフトウェアが効果ある情報管理に対して、望ましい最終結果を生み出すという点から考えれば、これらは正確に言えば、遂行への手段であると考えることができます。 (言い換えれば、特殊なハードウェアなしにソフトウェアに機能を追加できるなら、どんな組織も、喜んでそうするでしょう。しかし、ソフトウェアに機能が追加されないのに、ハードウェアを追加する組織はないでしょう。)

業務用ソフトウェアを中心とするIT環境では、一般に予算の大半は一般にハードウェアと専門サービスに費やされ、残ったわずかな予算がソフトウェアへとつぎ込まれます (図2を参照) 。

図2　業務用ソフトウェア環境における一般的な予算配分

このモデルでは、ソフトウェアの予算は、主に、”シュリンクラップ”のビジネスソフトのライセンスコピーとカスタマイズされた業務ソフトウェアに費やされます。 ハードウェアの予算は、エンドユーザーのデスクトップやモバイルコンピュータ、そして、データやアプリケーションをホストするサーバー、さらに、それらをつなぐネットワーク機器に配分されます。 専門サービスに関する予算は、ソフトウェアやハードウェアを配置したり保守したりするサポートスタッフの人件費となります。また、カスタム化されたシステムを設計したり構築したりするのを手助けするコンサルタントや開発リソースにも費やされます。

注　 図における配分は一例にすぎません。 すなわち特定のリソースの配分を意図するものではなく、実際の環境における配分は、著しく異なるかもしれません。

大部分をSaaSに依存する組織では、IT予算の割り当てが大きく違ってくる傾向があります (図3を参照) 。

図3　SaaS環境における一般的な予算

このモデルでは、基幹のアプリケーションならびにそれに付随するデータは、SaaSベンダーによって、ベンダー自身が管理するサーバーセンターへとホストされます。ハードウェアやソフトウェアは、専門のサポートスタッフによって保守されます。 これによって顧客は、ホストされたソフトウェアの保守、そして、サーバーとなるハードウェアの購入やメンテナンスから解放されます。 さらに、Webやスマートクライアントをアクセスできる場所に配置されたアプリケーションは、従来のローカルにインストールされたアプリケーションよりもデスクトップコンピュータへの要求がはるかに少なくなります。そのため、顧客はデスクトップコンピュータの技術的なライフサイクルを著しく伸ばすことができます。 結果としてソフトウェアに対して、はるかに多くの予算を割り当てられるようになり、その予算は一般に、SaaSプロバイダへの契約料という形で費やされることになります。

規模の経済の影響力

しかしこのような結果は、まやかしではないでしょうか。 実際には、SaaSベンダーに支払われる「ソフトウェア」に対する契約料金には、ベンダーに対するハードウェアや専門サービスの代価も含まれています。 その答えは、規模の経済にあります。 センターにホストされたソフトウェアサービスを提供するSaaSベンダーが顧客数xを抱える場合、そのベンダーは、抱える全顧客に対して、統合された環境を使ってサービスを提供することができます。 たとえば基幹業務SaaSアプリケーションを5台の負荷分散構成されたサーバーにインストールして50の中規模の顧客に提供するという場合、それぞれの顧客は、サーバーに対して10分の1のコストを支払うだけで済みます。 一方で、ローカルにインストールされた同様のアプリケーションの場合には、それぞれの顧客は、アプリケーションを実行するために、サーバーのコストを丸々負担することになるでしょう。いや、負荷分散や高可用性まで考えれば、恐らくサーバー1台のコストでは済みません。 スケールメリットの恩恵があるSaaSアプリケーションでは、それぞれの顧客が負担する運用コストは、顧客が増えるほど少なくなっていきます。これは従来モデルと比較して、本質的にコスト削減の可能性があるものであると言えます。 これを実現するために、プロバイダは、収益の柱としてマルチテナントを開発していくことになるでしょう。マルチテナントでは、低コストでより高品質のものを提供できます。 つまりSaaSベンダーにおけるハードウェアと専門サービスの経費を加味した場合でさえも、顧客は同じIT予算の大部分を、純粋にソフトウェアの機能に割り当てることができます (図4を参照) 。

図4　SaaS環境における一般的な予算配分 (ハードウェアと専門サービスを加味した場合)

「ロングテール」に売り込む

「ロングテール」という考え方は、Chris Andersonが執筆した「The Long Tail」 (Wired誌、2004年10月号(http://www.wired.com/wired/archive/12.10/tail.html) (英語) という記事において、なぜ従来の小売業者が効率よくコスト削減できないのに、Amazon.comのようなオンライン小売業者は独自の地位を築いているのかということを説明する際に用いられて、広まりました (図5を参照) 。

図5　ロングテール

本やCDといった商品分野の需要は、「指数法則分布 (power law distribution) 」と呼ばれているものに従う傾向があります。 この種のシナリオでは、何千もの本、CD、そしてDVDが毎年発行されます。しかしベストセラーの域に達するのは、数ダースのタイトルだけです。 残りは、いわゆるロングテールのなかに埋もれていきます。 ロングテールのなかには、恐らく数千部すら売れない専門分野のタイトルが膨大にあります。

従来型の店舗を構える小売業者は、もっとも人気がある品物を売ることに専念します。なぜなら、発行された何百万もの種類がある本やCD、DVDを、すべて在庫として持つことは不可能だからです。 その一方で、オンライン小売業者は、棚スペースの制限について考える必要はありません。 世界中の大きな倉庫から顧客に対して、直接、商品を送ることで、100万番目に人気あるタイトルであっても、一番人気のものと同じように容易に陳列して売ることができます。 少数販売という、このロングテールへの呼び込みは、巨大な収入へと姿を変えていきます。

大きな書店の場合、棚に約13万ものタイトルが置かれます。 しかしアンダーソンによると、Amazon.comにおける書籍売上の大半は、そのトップ13万の「圏外」です。言い換えれば、Amazon.comが売るほとんどの本は、従来の実店舗型の書店には置かれないタイトルです。

複雑な業務 (LOB：line-of-business) ソフトウェアのソリューションベンダーは、同様の市場曲線に直面します (図6を参照) 。

図6　LOBソフトウェアベンダーの市場曲線

シュリンクラップのパッケージソフトウェアと単純に比較した場合、基幹業務ソフトウェアでは、個々の顧客の要望を満たすためにテーラリングされる傾向があります。この要望には、ときにはオンサイトでのインストールやベンダーのサービスチームからの派遣も含まれます。またさらに、専用のサーバーとなるハードウェアやそれを管理するためのサポートスタッフが要求されることもあります。 この種のお膳立てを提供するコストは、ベンダーがソフトウェアを売るのに差し障りのない最低価格に積み上げられます。 そのためこの種のソフトウェアは、お膳立てに対する支払いに余力がある、より大きなビジネスの市場へと流れていく傾向があります。 大企業なら、基幹業務ソリューションを購入しますが、多数の中小規模のビジネスでは、ソリューションが役立つとしても、その費用を捻出する余裕はありません。

図7　低コストなSaaSによって開かれる新市場

顧客のハードウェアやサービスの集中化によって規模の経済が働き、多くの維持費から解放されるので、SaaSベンダーは、従来のベンダーより、ずっと低コストでソリューションを提供できます。そしてこれは顧客にとって、金銭的なメリットだけでなく、IT設備の複雑さも大きく削減します。 そのため、コスト効率が良くないがゆえに従来のベンダーでは近寄り難かった潜在的な顧客というまったく新たな層をSaaSが独占することになります (図7を参照) 。

実際に、こういった、より小規模な顧客を対象とするには、顧客とベンダーとの1対1のやりとり――すなわち顧客関係――に慣れているベンダーは、考え方を変えなければなりません。 価格面を考えると、ほとんどのベンダーは、小口の顧客に対して、大口の顧客と同じように、個別のサービスを提供することはできないでしょう。 SaaSを売ることは、携帯電話の着メロやダウンロードできる音楽を売ることに似ています。 顧客はWebサイトに訪れ、サービスを契約し、クレジットカードで支払い、サービスをカスタマイズして使い始める。これらはすべて、ベンダー側の人の手を介すことなく実現されるべきです。 これは大口顧客の幅広い要望に対して、個々の対応をなくすようにしなければならないという意味ではありません。 しかしセールス、マーケティング、納品、そしてカスタマイズといったプロセスを最初から最後まで自動化するように設計することは、多くの自動化対応への余地を与えます。これは同時に、顧客の代わりに同じ仕事をする、あなたのサポート人員の仕事を楽にするといううれしい効果もあります。

アプリケーションアーキテクチャ

私たちは、サービスとしてのソフトウェアを「ソフトウェアはホストされたサービスとして配置され、インターネットを通じてアクセスできるもの」であると定義してきました。 「ソフトウェア」や「アクセス」といった言葉をどのように捉えるのかによって、サービスとしてのソフトウェアという定義は、多くの (おそらく多すぎるほどの) 事柄を含むようになります。 アプリケーションアーキテクトにとって、実際この定義では、何がSaaSアプリケーションを動かせるようにするのか、そして、成功と失敗の違いの原因となるものは何かという点については、少しも触れられていません。 応急装備のHTMLによるフロントエンドを伴った十年来の古いコードを主体とした基幹業務アプリケーションは、広い意味で言えば、サービスとしてのソフトウェアに適合するかもしれません。しかしこのようなアプリケーションは、スケーラビリティやコスト効率が良くならないという問題で行き詰まります。 そのため、何が成熟したSaaSアプリケーションと呼ばれるものなのかということを定義するために、私たちは、いくつかの追加の基準を採り入れなければなりません

シングルインスタンス／マルチテナントアーキテクチャの3つの性質

アプリケーションアーキテクトという立場から見ると、下手に設計されたSaaSアプリケーションと、うまく設計されたSaaSアプリケーションとを見分ける、3つの重要な違いがあります。 うまく設計されたSaaSアプリケーションは、スケーラブルであり、マルチテナント効率が良く、構成可能です。

アプリケーションのスケーリングとは、同時実行性を最大限にし、より効率的にアプリケーションリソースを使うということを意味します。たとえば、ロックの持続時間の最適化、ステートレス性、スレッドやネットワーク接続といったプーリングされた共有リソース、参照データのキャッシング、巨大なデータベースのパーティショニングなどです。

マルチテナントは、分離されたアプリケーション (単一テナントのアプリケーション) の設計に慣れているアーキテクトにとって、最大のパラダイムシフトかもしれません。 たとえば、ある企業のユーザーがCRMアプリケーションサービスを使って顧客情報にアクセスする場合、ユーザーが接続するアプリケーションのインスタンスは、数十、いや場合によっては数百もの他の会社のユーザーに対して、サービスを提供しているかもしれません。しかし他の会社のユーザーが見えてしまうことはありません。 これを実現するには、テナントをまたいだリソースの共有を最大限にするけれども、異なる顧客が所有しているデータを区別できるアーキテクチャが必要となります。

もちろん、異なる会社のユーザーに対して、単一サーバー上の単一のアプリケーションインスタンスでサービスを提供する場合でも、エンドユーザーへのカスタマイズを施すためにカスタムコードを書いて済ませるということはできません。ある顧客に対するアプリケーションの変更はすべて、他の顧客のアプリケーションにも影響します。 そこで、従来の概念でアプリケーションをカスタマイズするのではなく、それぞれの顧客に対して、アプリケーションの見栄えや振る舞いを構成するための方法として、メタデータを付与します。 SaaSアーキテクトにとって課題となるのは、アプリケーションを構成する処理が、それぞれの構成に対して余計な開発や操作のコストを招くことなく、単純かつ簡単にできるようにすることです。

ソフトウェアのサービス成熟モデル

ここまで、成熟したSaaSアプリケーションにとって重要な性質を見極めることで、SaaSの定義を広げてきました。 しかし成熟とは、「ある」か「ない」かという二者択一の話ではありません。 アプリケーションアーキテクトは、コスト効率が良くないときには、すべての性質を備えないという選択をしてもかまいません。この場合、アプリケーションは、1つか2つの要件だけしか満たさないことになりますが、その場合でも、必要なビジネス要件をすべて満たすことができます。

おおまかに言えば、SaaSアプリケーションの成熟性は、4つの異なるレベルのモデルによって表現できます。 それぞれのレベルでは、先に述べた3つの性質が、1つずつ加わっていきます。

図8　SaaSの4つの成熟性レベル

レベル1：アドホック／カスタム

レベル1は、従来のアプリケーションサービスプロバイダ (ASP) モデルと似ています。これは1990年代にまでさかのぼるソフトウェア配布のモデルです。 レベル1では、それぞれの顧客に対してカスタムバージョンのアプリケーションがホストされており、ホストされているサーバー上で、自身のインスタンスが実行されます。 アーキテクチャ的には、このレベルのソフトウェアは、従来の販売形態をとっている基幹業務ソフトウェアにとてもよく似ています。組織内の異なるクライアントはサーバーで動作している単一のインスタンスへと接続します。しかしこのインスタンスは、他の顧客のためにホストされているインスタンスやプロセスにはまったく依存していません。

一般に、従来のクライアント／サーバアプリケーションは、全体を再設計することなく、比較的小さな開発努力で、システム全体を、レベル1のSaaSモデルに移行することができます。 レベル1は、成熟しているSaaSソリューションの恩恵をほとんど得ることができません。しかしサーバーとなるハードウェアや管理者の統合によって、ベンダーがコストを削減することはできます。

レベル2：構成可能

レベル2では、ベンダーはそれぞれの顧客 (すなわちテナント) ごとに分離したアプリケーションのインスタンスをホストします。 レベル1ではインスタンスは、それぞれのテナントのために個別にカスタマイズされます。しかしレベル2では、インスタンスにはすべて同じコードを実装します。またベンダーは、それぞれの顧客がアプリケーションの見栄えや振る舞いを変更することを可能とするために、詳細にわたる構成オプションを提供し、顧客の要望に応えます。 コードレベルではお互いに同じものですが、インスタンスレベルでは、それぞれのインスタンスが、他のインスタンスから完全に分離されています。

ベンダーが抱えるすべての顧客に対して、単一のコードベースへと移行することは、SaaSアプリケーションに対して必要となる保守を大幅に軽減します。なぜならコードベースに対するどんな変更も、同時にベンダーが抱える顧客へと簡単に提供でき、アップグレードやカスタマイズされたインスタンスに次々と適用していく必要性がなくなるからです。 しかし従来のアプリケーションが構成メタデータではなく、個々のカスタマイズをするように設計されている場合には、レベル2へと移行することは、レベル1に比べて、かなり多くの再設計が必要となります。

レベル1と同様にレベル2でも、ベンダーは、同時に実行される多くのアプリケーションインスタンスをサポートするために、十分なハードウェアとストレージを必要とします。

レベル3：構成可能なマルチテナント効率

レベル3では、ベンダーはすべての顧客に対して、サービスを提供する単一のインスタンスを実行します。このインスタンスは、すべての顧客に対して、固有の振る舞いや動作を規定する構成可能なメタデータをもっています。 認証とセキュリティポリシーにより、それぞれの顧客のデータは、他の顧客のものとは分離されることを保証します。 つまりエンドユーザーからは、アプリケーションのインスタンスが複数のテナント間で共有されているようには見えません。

この手法では、ベンダーが抱える顧客数と同数となる、たくさんのインスタンスをサーバーに作る必要がなくなります。すなわちレベル2に比べるとはるかにリソースを効率的に利用でき、直接、コスト削減へとつながります。 この手法での、特記すべき不利な点は、アプリケーションのスケーラビリティが制限されるということです。 もしデータベースの性能向上にパーティショニングを使っていないなら、もっと強力なサーバーへと移行するしか拡張の余地がありません (スケールアップ) 。収穫逓減により、その限界は、コストと性能との兼ね合いで決まってきます。

レベル4：スケーラブルで構成可能なマルチテナント効率

最後となるレベル4では、同一のインスタンスをロードバランス環境で複数の顧客へとホストします。このインスタンスは、分離性を保ったままそれぞれの顧客のデータと、ユーザーに固有の振る舞いや動作を提供する構成可能なメタデータをもっています。 SaaSシステムは、顧客の数に応じて、いくらでも拡張できます。というのは、バックエンドにおけるサーバーとインスタンスの数は、アプリケーションを再設計することなく、数千のテナントでも1つのテナントと同じぐらい簡単に増減できるからです。

成熟性レベルの選択

あなたのアプリケーションでは、どの成熟性レベルを目指すべきでしょうか。 どんなSaaSアプリケーションでも、レベル4が最終的なゴールであると思うかもしれません。しかし必ずしもそうだとは言えません。 SaaSの成熟性は、分離されたデータとコード、そして共有されたデータとコードの違いという連続性を示したものであると考えるとわかりやすいでしょう (図9を参照) 。

図9　連続したSaaSの成熟性

あなたのアプリケーションがこの連続性のどの位置に来るのかは、顧客を考慮したうえでの、ビジネスモデルやアーキテクチャモデル、そして運用モデルの必要性に準じます。 この簡単な説明からわかるように、これらを考察する場合には、すべてが、ある程度の相互関係があります。

• ビジネスモデル　 ―分離されたアプローチに金銭的な合理性がありますか？　 共有するという取り組みによる金銭的そして管理面での利益を放棄することは、アプリケーションを顧客に提供する際のコストが高くなることを意味します。 しかしながら、いくつかの状況下では、他の意味での価値をもたらすかもしれません。 さらに、たとえあなたが機密データを危険にさらさないということを実証できた場合でさえ、顧客は多数のテナントがアプリケーションへのアクセスを共有するアーキテクチャモデルに、法的なもしくは文化的な強い抵抗感をもっているかもしれません。 つまるところ、どの成熟レベルを目的とした場合でも、あなたのアプリケーションが、どのように金銭的な利益を生み出すのかを示すビジネスモデルが必要になってきます。

• アーキテクチャモデル　 ――単一の論理的なインスタンスとして動くようにアプリケーションを作れますか？　 デスクトップベースもしくは従来のクライアントサーバーベースのアプリケーションをインターネットベースの配送システムへと移行しようとする場合、単一インスタンスでメタデータ中心の取り組みとは基本的に互換性がないかもしれません。またSaaSアプリケーションの成熟性を満たすように変更するのに必要な開発投資をしたとしても、コストに見合わないだろうと判断するかもしれません。 最初から最後までインターネットにネイティブな設計や構築をしているなら、恐らく、単一インスタンスという取り組みは、非常に多くの柔軟性をもつでしょう。

• 運用モデル　 ―分離することなくサービス品質保証 (SLA) を満たせますか？　 顧客と結んでいる既存のSLAによって課せられた義務を注意深く検討してください。考慮すべきものとして、ダウンタイム、サポートオプション、災害からの復旧などが挙げられます。こういった義務は、無関係な顧客が単一のアプリケーションのインスタンスに共有してアクセスするというアーキテクチャの環境下において、果たせるのかどうかを判断してください。

全体的なアーキテクチャ

アーキテクチャとしては、SaaSアプリケーションは、サービス指向の設計原則を適用したアプリケーションにとてもよく似ています (図10を参照) 。

図10　SaaSアプリケーションアーキテクチャ

ほとんどのアプリケーションアーキテクトは、図10に示されたコンポーネントのほとんどをよく知っているはずです。 プロセスサービスはスマートクライアントやWebプレゼンテーション層から呼び出すことができるインターフェイスをエクスポーズし、同期的なワークフローや長時間トランザクションを呼び出します。これによってビジネスサービスが呼び出され、さらに、ビジネスデータを読み書きするために、それぞれのデータストアとのやりとりが生じます。 セキュリティサービスは、エンドユーザーとバックエンドソフトウェアサービスに対するアクセス権の制御を担当します。

もっとも大きな違いは、メタデータサービスが追加されているという点です。メタデータサービスは、個々のテナントのアプリケーションの構成を管理する役割をします。 サービスやスマートクライアントは、それぞれのテナント固有の構成や拡張機能の記述を見つけ出すために、メタデータサービスとやりとりします。

メタデータサービス

成熟したSaaSアプリケーションにおいて、メタデータサービスは、要望に応じてアプリケーションをカスタマイズしたり構成したりする基本機能を顧客へと提供します。 一般に顧客は、次の4分野の構成を変更できます。

• ユーザーインターフェイスとブランド　 ――顧客は、企業ブランドを反映できるユーザーインターフェイスへと修正できるかどうかを評価するものです。そこでSaaSアプリケーションでは一般に、顧客がグラフィック、色、フォントといったものを変更できる機能を提供します。

• ワークフローとビジネスルール　 ――業務に直結したSaaSアプリケーションでは、幅広い分野の見込み客にとって役立つようにするために、ワークフローの違いを調整できるようにしなければなりません。 たとえば、請求管理アプリケーションを使っている、ある顧客は、それぞれの請求書が1人のマネージャによって承認されることを求めるかもしれません。 そして別の顧客は、請求書が2人のマネージャによって順に承認されることを求めるかもしれません。 さらに第3のケースでは、それぞれの請求書を2人のマネージャが承認することを要求する一方で、それらは順にではなく並列的に承認できるようにすることを求めるかもしれません。 この場合、それぞれの顧客のビジネスプロセスに合うように、アプリケーションのワークフローを構成できるのが適切でしょう。

• データモデルの拡張　 ――データを扱う多くのSaaSアプリケーションにとって、あるデータ構造がすべての場合に適しているとは限りません。 比較的単純な、限定された処理をするアプリケーションでさえ、顧客は、変更することができないデータフィールドやテーブルセットによる制限に、いらだちを感じるかもしれません。 拡張可能なデータモデルは、顧客に対してあらかじめ決まったアプリケーション処理を強要するのではなく、処理に自由度を与えます。 本稿ではのちほど、顧客自身が拡張できるデータモデルをどのように設計するのかについて、もう少し説明します。

• アクセス制御　 ――一般に、それぞれの顧客は、個々のエンドユーザーのアカウントを作成し、それぞれのユーザーがどのようなリソースや機能にアクセスできるのかを決定することになります。 それぞれのユーザーに対するアクセスの可否は、セキュリティポリシーによって追跡されます。セキュリティポリシーは、それぞれのテナントごとに構成できるようにすべきです。

必要に応じた柔軟なソフトウェア構成を顧客に提供するため、これらのオプションは「スコープ」と呼ばれる階層的な構成単位として構成されます。個々のユニットは、前述したそれぞれの4分野を変更するオプションを含んでいます。 すべての顧客は、必要に応じて構成可能なトップレベルのスコープをもっています。顧客は、このトップレベルスコープの下に1つ以上の任意の階層化されたスコープを作ることもできます。 どのように、そして、どこから子ノードが継承されていて、さらに、親ノードからの構成設定を上書きするかどうかということは、リレーションシップ構造で決定します。

たとえば一般に、エンタープライズ全体に渡ってアクセスできるアプリケーションを購入する顧客は、いくつかの事業所単位で異なる要望をもっているでしょう。その要望は、すべて企業の標準に従うべきですが、個々のアプリケーションのいくつかの見栄えは構成可能であるべきです。 同様に、それぞれの事業所のなかには、構成について固有の要求をもっている組織グループがあるかもしれません。 このように区別されたそれぞれの組織単位のために、顧客は、設定を変更できる構成オプションへのグループアクセス権を与えるスコープを作成できます。

ベンダーによってカスタマイズされた従来の基幹業務アプリケーションとは違い、SaaSアプリケーションは、顧客自身によって構成される多くの余地があります。 そのため、構成に対するインターフェイスを設計することは、エンドユーザーのインターフェイスを設計するのと同程度に重要です。 理想を言えば、顧客は、ウィザードを使って構成できるべきです。もしくは、与えられたスコープのなかでどれが変更できてどれが変更できないオプションなのかを明確にし、情報過多とはならないけれども、すべての提供されているオプションを提示するシンプルで直感的な画面を使うのでもよいでしょう。

セキュリティサービス

どんな状況下のソフトウェアでもセキュリティは重要であり、SaaSも例外ではありません。SaaSの性質として、セキュリティは、顧客にとって最大の関心事であり、また、アプリケーションアーキテクトにとっても、最優先となるものです。 いくつかの基本的なガイドラインに従うと、テナントのプライベートデータを管理下に置くことを確実にしやすくなります。

認証

Saasプロバイダは一般に、各テナントに対して、それぞれのユーザーアカウントを作成して保守することを委任します。この手法は、「管理委譲」と呼ばれます。 管理委譲では、顧客が個々のユーザーアカウントの作成に責任を負うという状況を作り出します。しかしベンダーは、それらを認証しなければなりません。 この管理委譲モデルを提供するために、SaaSの設計者は、認証を扱うための2つの一般的な手法を採用します。 それは「集中型の認証システム」と「分散型の認証システム」です。 どちらを選ぶのかは、アーキテクチャの複雑さと、エンドユーザーがアプリケーションでどのようなことをするのかによります。決定する際には、あなたのビジネスモデルでは、アプリケーション、顧客、そしてエンドユーザーの要望が、どのような指針をとっているのかを考えるべきです。

集中型の認証システムでは、プロバイダはアプリケーションのテナントのすべてに対して機能を提供する集中的なユーザーアカウントデータベースを管理します。 テナントの管理者には、それぞれのテナントのユーザーアカウントディレクトリ内に、ユーザーアカウントを作成したり管理したり削除したりする権限が与えられます。 アプリケーションにサインオンするユーザーは、アプリケーションに対して認証情報を提示します。アプリケーションは、認証情報を中央のディレクトリと照合して、認証情報が有効であればアクセス権を与えます (図11を参照) 。

図11　集中型の認証システム

この手法は、設計や実装が比較的容易ですが、テナント自身がユーザー基盤を変更しなくてよいという、比較的単純な認証基盤に限られます。 この手法での、特記すべき不利な点は、企業ネットワークですでにアクセス権を得ている認証情報をアプリケーションが受け入れるというシングルサインオンを実現するには、集中型の認証システムは非常に困難であるということです。 シングルサインオンせずにアプリケーションにログインする場合、ユーザーにとって不便なログインプロンプトが頻繁に現れます。このときユーザーは認証情報を手入力しなければなりません。

分散型の認証システムでは、テナント自身のユーザーディレクトリサービスと接続する連携サービスをテナント上に配置します。 エンドユーザーがアプリケーションへのアクセスを試みるときには、連携サービスはユーザーをローカルで認証し、セキュリティトークンを発行します。SaaSプロバイダの認証システムは、そのセキュリティトークンを受け入れ、ユーザーがアプリケーションへとアクセスできるように許可します (図12を参照) 。

図12　分散型の認証システム

シングルサインオンが重要であるなら、これは理想的な手法です。認証はユーザーから隠されて処理されるため、ユーザーは固有の認証情報を覚えておいて入力する必要がないからです。 しかしながら、分散型の手法は集中型の手法よりも複雑です。そして、数千の顧客を抱えるSaaSアプリケーションでは、数千ものテナントの連携サービスのそれぞれに対して個々の信頼関係を結ばなければならなくなります。

多くの場合、SaaSプロバイダはハイブリッドな手法を考えたいと思うでしょう。すなわち、小規模なテナントのユーザー管理や認証には集中型の手法を使い、シングルサインオン環境を必要とし、またその対価も支払う大規模なエンタープライズに対しては分散型の手法を使うといった具合です。

承認

一般にSaaSアプリケーションにおけるリソースや業務処理へのアクセスは、組織内の特定の職務権限をマッピングするロール (役割) を使うことによって管理されます。 それぞれのロールには、1つ以上のパーミッションが与えられます。パーミッションは、ロールに割り当てられたユーザーが任意の適切なビジネスルールに則ってアクションを起こせるようにします (図13を参照) 。

図13　アクセス制御

ロールはSaaSアプリケーション自身で管理されます。 ロールには、それぞれのユーザーだけでなく、ユーザーのグループを含むこともできます。 個々のユーザーアカウントやグループには、必要に応じて異なるロールを割り当てることができます。

ロールに割り当てられたユーザーは、そのロールに従って、特別な操作やアクションを起こすための1つ以上のパーミッションが与えられます。 これらのアクションは一般に、重要な業務処理やアプリケーション自身の管理機能に直接マッピングします。 たとえば購入アプリケーションは、購入注文の作成、提出、承認、拒否をするためのパーミッションを含むでしょう。 また、住宅ローン仲介業アプリケーションは、借り手の与信をチェックし、貸し出しを与えるためのパーミッションを含むでしょう。 必要に応じて、単一のパーミッションは、1つもしくは複数のロールへと割り当てることができます。 それぞれのユーザーは、ユーザーが属するすべてのロールに割り当てられたパーミッションを統合したパーミッションが与えられます。

アプリケーションは、パーミッションによる許可よりも細かいレベルで、アクションとリソースへのアクセスを制御するビジネスルールを使うことができます。 ビジネスルールは、アクセス権が与えられる前に満たされなければならない条件を導入するものです。 たとえば、通常営業時間内だけ、または一定の金額を超えない場合だけに限って、口座間での振込を可能にするビジネスルールを使うことができます。

アクセス制御は、スコープレベルで管理されます。 それぞれのスコープは、アプリケーションのリレーションシップ構造に従って、親スコープから、ロール、パーミッション、ビジネスルールを継承します。リレーションシップは、望み通りに、変更したり追加したり削除したりすることができます。 たとえば、アメリカに本拠を置いていて、カナダのトロントに支店がある顧客を考えてみましょう。 ルートスコープは、給付金管理者という名前のロールをもっています。給付金管理者には、企業の401K退職金制度の管理を含む、従業員給付金を管理する多くのパーミッションが関連付けられています。 401K制度は、米国の税法によるものなので、カナダでは使われません。 したがって、カナダのオフィスのために作られる子スコープは、給付金管理者ロールを継承し、すべてのパーミッションを継承しますが、401Kに関する修正ができるパーミッションは省きます。 401Kのパーミッションの代わりに、米国の401Kに相当するカナダの「Registered Retirement Savings Plan (RRSP)」を修正することができるパーミッションを加えます。

図14　ルートスコープのパーミッションと子スコープのパーミッションの例

長年の経験から言えば、アプリケーションは、すべてのテナントで使うことができる、既定のロール、パーミッション、ビジネスルールの一式を備えているべきです。そして個々のテナントが、使いやすく直感的なユーザーインターフェイスを使ってこれらのルールをカスタマイズしたり、さらなるルールを作成したりできるようにすべきです。

マルチテナントデータモデルの詳細

ここまで、アプリケーションアーキテクチャの概要的な部分は、一通りカバーしてきました。そこで次に、特定の問題について、より詳細に検討していきましょう。 特定の問題とは、顧客がマルチテナント環境において拡張することを許すデータモデルです。 これは決してデータモデルの拡張方法に対する包括的な探求ではなく、SaaSアプリケーションを設計するときに、検討されるに違いないアーキテクチャ上の課題の手ほどきをするものにすぎません。

設計に際して、アプリケーションは、ソリューションに適した自然なかたちで、既定のテーブル、フィールド、クエリ、そしてリレーションシップといった標準的なデータベース構成を含むでしょう。 組織には、それぞれ固有の要望があります。しかし、厳密で拡張性がない既定のデータモデルでは、それを扱うことができません。 たとえば、SaaSで構成された業務トラッキングシステムを使っているある顧客は、その顧客がもつ他の外部プロセスとシステムを完全に統合するために、各レコードには、外部で作成された分類をstringとしてそれぞれのレコードに格納しなければならないかもしれません。 別の顧客は、分類を表すstringを必要としないかもしれませんが、追跡のためのカテゴリID番号をintegerとして必要とするかもしれません。 そのため、ごくわずかな特殊な場合を除き、すべての場合において、他の顧客によって使われるデータモデルに依存することなく要求を満たすために、顧客が既定のデータモデルを拡張できる方法を開発し、実装しなければなりません。 この問題を解決するため、3つの一般的な手法を見ていきましょう。それは、 「テナント専用のデータベース」、「あらかじめ決められた拡張を含む共有データベース」、そして「カスタム拡張を含む共有データベース」です。

テナント専用のデータベース

最初の手法は、それぞれのテナントに対して、単純に、自身のデータベースを与えるということです。テナントは必要に応じてこのデータベースを拡張できます。

最初の手法は、それぞれのテナントに対して、単純に、自身のデータベースを与えるということです。テナントは必要に応じてこのデータベースを拡張できます。 この手法では、新しいテナントを準備するときに、新しい既定のデータベースを作ります。そして、メタデータサービスが、どのデータベースがどのテナントに割り当てられたのかを追跡します。 ひとたび新しいデータベースが作られれば、テナントは、データベースを自由に変更できます。変更できるものは、アプリケーションのユーザーインターフェイスやプログラムロジックの許可と同様に多岐にわたり、新しいフィールドやクエリの作成、さらには新しいテーブルやリレーションシップさえ作れます。

提供するサービスのコストが気にならないなら、これは検討に値する唯一の手法となるでしょう。なぜなら、構築の際の配置がシンプルである一方で、顧客に対しては、既定のデータモデルを最大限に自由に拡張できる機能を提供するからです。 さらに、銀行取引やカルテ管理のような分野の顧客は、「データを分離したい」という要求を根強く持っており、それぞれの顧客自身が所有するデータベースを提供しないアプリケーションには、見向きもしないかもしれません。 この手法の不利な点は、サポートできる数が、それぞれのサーバーのデータベースの最大数によって制限されるという点です。したがってインフラストラクチャのコストは、想像以上に急速に高くなっていくことでしょう。

あらかじめ決められた拡張を含む共有データベース

2番目の方法は、いくつかのプリセットされたカスタムフィールドを含んだ、すべてのテナントによって共有されるデータベースを構築することです。テナントはそれらのフィールドを好きなように割り当てたり使ったりできます (図15を参照)。

図15　共有データベース中のカスタムフィールド

図15に示したように、異なる顧客のレコードは、単一のテーブル内に混在します。 TenantIDフィールドは、それぞれのレコードと個々のテナントとを結び付けます。 フィールドの標準セットに加え、多くのカスタムフィールドが提供されます。それぞれの顧客は、これらのフィールドから使うものを選ぶことができ、どのようにデータを取ってくるのかを決めることができます。

カスタムフィールドは型付きにすることができます。そうすれば、顧客はデータを検証するために、アプリケーションやデータベースが提供している内蔵の型チェック機構や妥当性の検証機能を用いることができます。 あるいはフィールドを型なしにすることもできます。そうすれば顧客は、どんな型のデータでも格納することができます。 (顧客は、意図しない無効なデータが入力されることを防ぐため、オプションで顧客自身の妥当性検証用ロジックを提供することもできます。)

共有データベースは、分散型の手法に比べて、サービスをはるかに低コストで提供できます。なぜなら、パーテショニングを必要とせずとも、多数の顧客をサポートできるからです。 この手法での、特記すべき不利な点は、データモデルの拡張性は、あなたが提供したカスタムフィールドの数に制限されるという点です。 この数を賢く選ぶためには、顧客の潜在的な要望に対する注意深い検討が必要になります。 カスタムフィールドが少なすぎれば、顧客はアプリケーションを効果的に使うことができないでしょう。 逆に多すぎれば、データベースはたくさんの使われないフィールドでいっぱいになり、無駄で不経済なものとなります。

カスタム拡張を含む共有データベース

3番目の手法は、単一の共有データベースを構築し、それぞれの顧客が分離されたテーブルへと「名前と値のペア」を格納できる任意の拡張を許すデータモデルです (図16を参照) 。

図16　分離された拡張テーブルに格納されたカスタムデータ

ここでは、カスタムデータを含んだそれぞれの顧客レコードに対して、唯一無二のレコードIDが割り当てられます。レコードIDは分離された拡張テーブルの1つ以上の行に対応します。 この拡張テーブルのそれぞれの行には、「名前と値のペア」が格納されます。 顧客はそれぞれ、ビジネス上の要求に合わせて、このたくさんの「名前と値のペア」を作成できます。 アプリケーションが顧客のレコードを検索する場合、カスタムデータテーブルをルックアップし、そのレコードIDに対応するすべての行を選択して、通常のフィールドデータとして扱うために、それらを返します。 カスタムデータテーブル内のデータは、顧客によってまちまちなデータ表現が含まれている可能性があるため、明らかに、型付きにすることはできません。 この制限を回避するために、データ型の識別子を保持する第3の列をオプションで追加するという手があります。そうすれば、データが取り出されたときに適切な型へとキャストできます。

この手法では、共有データベースを用いるというコスト的な優位性を保ちつつ、データモデルを好きなように拡張できるようにします。 主なデメリットは、検索やインデックス、クエリ、レコードの更新といったデータベース操作に複雑な要素が加わるという点です。 この手法は一般に、顧客が相当な柔軟性を要求する一方で、データの分離は要求しないだろうと思える場合には、最良の手法です。

データモデルを拡張する手法を開発する際には、顧客によって実装されたどんな拡張も、対応するビジネスロジック (これはアプリケーションがカスタムデータを使えるということです) と対応するプレゼンテーションロジック (これはユーザーがカスタムデータを入力する方法と取得したデータを出力する方法です) の双方に、拡張が必要であるということを忘れないでください。 したがって、顧客に提示する構成のインターフェイスは、できるだけ、これら3つをすべて更新する統合された機構として提供すべきです。 (顧客にビジネスロジックやユーザーインターフェイスを拡張することを許すために提供する機構については、今後の記事で取り上げます。)

スケーラビリティ

大規模な企業ソフトウェアは、何千もの人達に、同時に使われることを目指しています。 もしこの種のエンタープライズアプリケーションを構築した経験があるなら、直接の課題は、スケーラブルなアーキテクチャを作ることであるということを知っているでしょう。 SaaSアプリケーションにおいて、スケーラビリティはさらに重要です。 1顧客当たりの平均ユーザー数に、あなたが抱える顧客数を掛けたものの数だけサポートしなければならないからです。 業務用のエンタープライズソフトウェアの構築に慣れていたISVにとっては、これだけの単位となるユーザーをサポートすることは、マイナーリーグからメジャーリーグに移ることに似ています。 ルールはわかっているかもしれませんが、ゲームはまったく違った水準で行われます。 幅広く展開していく基幹業務ビジネスアプリケーションの代わりに、あなたは、もしかすると何百万という単位の有効なユーザーを必要とするインターネットスケールなシステムを実際に構築していることでしょう。

アプリケーションのスケーリング

もちろん、あなたがHotmailがサポートするほどの数のユーザーをサポートすることは、たぶんないでしょう (そうなったらおめでとう！) 。 しかしスケーラビリティの問題は、とてもよく似ています。

アプリケーションは、 (より大きく強力なサーバーへと移行させることによって) スケールアップできます。そしてまた、 (アプリケーションをたくさんのサーバーで動かすことによって) スケールアウトできます。 かつて行われた、老朽化したコンピュータを真新しいモデルに取り換えた、誰もが知っている解決法だったスケールアップは、非常に多くの同時利用ユーザーをサポートしなくてもよい、小さなアプリケーションにとっては、多くの場合は良い選択でした。 しかしながらSaaSという水準では、SaaS成熟モデルとして示されるように、スケールアウトが、キャパシティを向上するための、常に最良の方法です。 よく設計されたSaaSアプリケーションは、任意の数のサーバーへとスケールアウトできます。それぞれのサーバーは、アプリケーションの同一のインスタンスを1つ以上実行します。 次に示すのは、アプリケーションをスケールアウトできるものとして設計するためのいくつかのガイドラインです。

• 必要となるユーザーデータやセッションデータをクライアントサイドやアプリケーションインスタンスからアクセスできる分散ストレージに保存することで、アプリケーションをステートレスに実行できるように設計してください。 「ステートレス」とは、それぞれのトランザクションが他のどれとも同じように扱えるということを意味します。 ユーザーはそのようなことはまったく意識せずに、1つの一連の処理を異なる多数のインスタンスで処理できます。

• アプリケーションは非同期なI/O処理をするように設計してください。そうすることで、入出力が完了するのを待つ間に、有効な処理をできるようになります。

• スレッドやネットワーク接続、データベース接続といったリソースはプーリングしてください。 これはコンピュータのリソースを最大限に活かし、また、リソースの利用状況を予測しやすくなります。

• データベース処理は、同時実行性を最大限にし、排他ロックを最小限にする方法で記述してください。 たとえば、読み出し専用の処理をする場合には、レコードをロックしないでください。

もちろん、スケーラブルなアーキテクチャというテーマの考察において、これらは、非常に簡単なものに過ぎません。 スケーラブルなアーキテクチャの実装に関しては、書くべきことはもっとたくさんあります (そして実際に執筆は続けられています) 。 いくつかの付加的なガイダンスについては、Microsoft Patterns & Practicesの「Performance & Scalability」 ("http://msdn.microsoft.com/library/ms998530.aspx") (英語) を参照してください。

データのスケーリング

データベースがたくさんの同時ユーザーへのサービスを提供し、そのサイズが大きくなっていけば、それに比例して、問い合わせや検索にかかる時間が著しく増加していきます。 しばしば同じデータベースで数千の顧客へのサービスを提供するSaaSアプリケーションは、特に、この種の性能低下に影響されます。そのため、成長に対する十分な計画を立てることが重要です。

データベースをスケーリングする比較的簡単なひとつの方法は、問い合わせや更新の効率を改善するため、パーテショニングし、データを小さな「チャンク (かたまり) 」へと分割していくことです。 あなたのデータを分割する最良の方法となるパーティショニング戦略を考えてみてください。 たとえば、アプリケーションが世界中の顧客を抱えている場合、ヨーロッパの顧客が所有しているデータを1つのパーティションに、アジアの顧客が所有しているデータを1つのパーティションにというように、地理的に分割するという戦略は適切だと言えるでしょう。

ほとんどの状況下では、データベースサイズは、大きくなり続けます。 そのため、パフォーマンスとスケールのバランスを保つために、すでにパーテショニングされたデータがさらに再分割できるよう、動的な再パーテショニングできる戦略をもっていることもまた重要です。

運用組織

考え方の重要の変化の3つ目は、アプリケーションの運用組織と関係してきます。 それは、アプリケーションをコスト効率が良く、顧客へと提供し、実行して、利用可能な状況にしておくというものです。 多くのISVにとっては、ISV自身が顧客のためにデータセンターで実行する必要がなかったため、これはSaaSのもっとも馴染みの薄い部分かもしれません。 SaaSプロバイダはソフトウェアを構築して、それを市場へと出すエキスパートでなければならないだけでなく、そのソフトウェアを運用して管理するエキスパートにもならなければならないのです。

Microsoft Operations Framework (MOF) のような資料は、システムの信頼性、可用性、サポート性、管理性を維持するための、多くのよきガイダンスを提供します。 MOFが示す設計の共通の運用方法の課題に加え、SaaSには、ほかにも固有な課題があります。

共有サービス

エンタープライズレベルのWebの配置を経験していれば、Webホスティングやミドルウェアサービスの基本については既に理解しているでしょう。Webでは、サイトを内部もしくは外部プロバイダのコロケーション設備やフルサービスホスティングでホストします。設備には、ハードウェア、ストレージ、そしてネットワーク帯域が含まれます。 ホスティングサービスは、サイトの信頼性の一因となります。しかし一般には、サイトの運用や管理のほうに問題があります。

ソフトウェアをサービスとして提供する場合、ホスティングの配置には、新たな層を追加するかどうかを考慮する必要があります (図17を参照) 。ビジネスプランに応じて、次に示す目的のための計量システムや課金システムが必要になる場合があります。

• 正確にユーザーの行動を追跡し、使った時間やリソースに対して請求する。

• 1日単位もしくはそれ以外の基準でアクセスを制限したり絞り込んだりする。

• SLAを保証するため、サイトへのアクセスやパフォーマンスをモニタする。

• 顧客が期待するもしくは期待以上にシームレスに使えることを保証するためのその他の機構を実行する。

これらの機能を遂行するために使われる集合的なシステムは、「共有サービス」と呼ばれています。

図17　SaaSホスティングのための共有サービス層

共有サービスは、次の2つに細分化できます。

• 運用サポートサービス (OSS：Operational Support Services) 　――アカウントのアクティブ化、供給、サービス保証、利用調査、計量といった運用上の問題を扱います。

• ビジネスサポートサービス (BSS：Business Support Services) 　――請求処理 (請求書作成、割引率、課税、代金回収を含む) や顧客管理 (受注登録、顧客のセルフサービス、顧客サポート、トラブル管理、取引先管理を含む) をサポートします。

従来のWebホスティングのように、共有サービス層は、あなた自身が作ってアプリケーションに組み込むか、外部のホスティング企業 (「SaaSプロバイダ」と呼ばれます) に委託するかという選択をする必要があります。 SaaSプロバイダは、上に述べた運用やビジネスの課題を扱う共有サービスを提供します。

モニタリング

あなたが顧客と結んでいるSLAは、あなたに求められている運用基準を計るものとなるでしょう。 SLAは法的な契約であり、それを満たさないと、著しく収益を失い、評判も悪くなります。 そのため、アプリケーションアーキテクチャのモニタ機構は、重大な故障停止や性能低下に至る前に、問題を発見して解決するための重要なツールとなります。

可用性のモニタリング

高可用性の保証は、どんなSaaSベンダーにとっても、最重要課題です。 1台のサーバーあるいはデータセンターの停止は、かなりの割合の顧客――もしかすると全顧客――のデータや生産性の損失に影響を及ぼします。 従来のデスクトップソフトウェアやクライアントサーバーソフトウェアの開発からSaaSへと移行するISVにとって、ネット中心のアプリケーションモデルにおける高可用性の要求には、新しく未知の課題が含まれることでしょう。 動作のモニタリングやアラート装置のような、基本的な技術をサポートするように構成し、管理下ではないリモートサイトでのデータベースへの接続のような潜在的な弱いリンクには、特に注意を向けることを推奨します。

もちろん、アラートのような技術的な機構は、高い信頼性を保証するプロセスの一部に過ぎません。実際、アラートが出ても、誰も反応しなければ、それはプロセスの一部ということさえも言えません。 運用センターにおいては、システム障害が起きたときに備えて、具体的な行動方法を規定し、実行できるようになっていることを確認してください。

高可用性を取り巻く問題の概要については、Microsoft TechNetの「Service Management Functions：Availability Management」 (http://technet.microsoft.com/library/cc506049.aspx) (英語) を参照してください。

パフォーマンスのモニタリング

顧客は、アプリケーションにアクセスする場合、妥当なパフォーマンスを提供することを期待しています。 この期待は、ある程度までは、あなたと顧客が結んで同意しているSLAによって明示されることになるでしょう。 SLA契約の元では、顧客がアプリケーションが遅かったり反応がなかったりしたことに気づいたときには、契約の打ち切りもしくは契約の更新が断られる可能性があります。 不満なユーザーはWebサイトや業界誌で彼らの不満を表し、その結果、あなたのアプリケーションの不評が知れ渡るでしょう。 逆にユーザーの要求を満たす、高速で洗練されたアプリケーションは、顧客を喜ばせます。そして、レスポンスが悪い従来のソフトウェアパッケージから、あなたのソフトウェアへと移行するでしょう。つまりSaaSはカテゴリとして、より受け入れられるようになります。

高水準のパフォーマンスを保証するため、パフォーマンスカウンタは、できるだけアプリケーションに直接内蔵させてください。 CPUの使用率やアプリケーションのレスポンスタイムといったパフォーマンスの閾 (しきい) 値を設定し、管理イベントが発生したときに、適切な人員に通知するアラートを利用してください。

パフォーマンス基準の制定は、通常はもっとも重要なことです。 基準を制定しておけば、異常なことがどこでいつ起きたのかが、ずっと簡単に伝えられるようになります。

結論

本稿で述べた、それぞれの話題については、説明した以外にも書くべきことがまだあります。しかしおそらく、これらの要点によって、SaaSを理解したり、どうやってあなたやあなたの顧客がSaaSから利益を得るのかということを目指す、概念的なフレームワークを開発し始めるのに十分な情報を得たはずです。 SaaSは、ソフトウェアの配布において、新しいパラダイムを意味します。マルチテナント効率、包容力あるスケーラビリティ、メタデータ駆動の構成可能といった法則に基づくSaaSは、既存のもしくは将来見込みある顧客に対して、ソフトウェアを低価格で提供します。 いまこれらの法則を採用することは、ロングテールビジネスを捕まえる方法へと、姿を変えていくのに役立つことでしょう。

謝辞

Paul Henryのテクニカルライティングの手助けに多大な感謝の意を表します。

フィードバック

筆者は、本稿へのフィードバックを歓迎します。 フィードバックはメールにて、fredch@microsoft.com (英語) またはgianpc@microsoft.com (英語) までお願いします。