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

マルチテナンシーでアプリケーションを強化する方法に関する 7 つのヒント

この記事では、著者たちがシングルテナント型 SOA アプリケーションをマルチテナント型クラウド・ソリューションに変換する作業のなかで得た経験を紹介し、ベスト・プラクティスを詰め込んだ 7 つの重要なヒントを紹介します。

Christina Lau, Distinguished Engineer, IBM

Christina LauChristina Lau は、クラウドやモバイル・コンピューティングなどの新しい技術に豊富な経験を持つ、WebSphere の Distinguished Engineer です。彼女は現在、BPM、接続性、および ILOG ポートフォリオでのオンライン・クラウド・サービスの提供をサポートする高度な技術の開発に取り組んでいます。


developerWorks 貢献著者レベル

Valentina Birsan, Senior Developer, IBM

Valentina Birsan's photoValentina Birsan は WebSphere のシニア開発者で、現在はクラウド・プロジェクトに取り組んでいます。以前は、Rational Application Developer で技術リーダーを務めていました。Eclipse TPTP オープンソース・プロジェクトには初期メンバーとして加わった他、 TPTP Architecture Group の議長、Cosmos Service Modeling Eclipse オープンソース・プロジェクトの主任アーキテクトを務めた経験もあります。また、彼女は SML オープン標準のメンバーです。



Bhadri Madapusi, Advisory Software Developer, IBM

Bhadri MadapusiBhadri Madapusi は、WebSphere の顧問ソフトウェア開発者で、現在は主にクラウド・プロジェクトに取り組んでいます。彼のソフトウェア開発での経験は 10 年以上に及びます。以前は、ビジネス・プロセス・マネジメントおよび WebSphere Commerce に携わっていました。



2012年 3月 29日

技術の専門家としての私たちの目標の 1 つは、自分たちの経験とそこから学んだ教訓を共有することです。この記事の場合、それは、IBM SmartCloud Enterprise 上で稼働するマルチテナント型アプリケーションを構築するなかで得た知識を指します。この記事では特に、私たちが既存のシングルテナント型 SOA アプリケーションをマルチテナント型 SaaS (Software as a Service) アプリケーションに変換するために使用した技術を説明します。

ただし私たちは、将来的にはシングルテナント型アプリケーションからマルチテナント型アプリケーションへの複雑な変換を自動化するツールが開発され、開発者の作業が支援されることを期待しています。

まず始めに IBM の従来のソリューション (私たちにとって最も馴染み深いソリューション) を検討しましょう。

IBM の業界ソリューション

IBM では、広範な分野のさまざまな種類に及ぶソフトウェア製品群を通じて、豊富な機能を提供しています。さらに IBM は、数多くのお客様と関与させていただいた経験に基づき、お客様が特定のビジネス問題を解決できるようにソフトウェア製品群の豊富な機能をさまざまに組み合わせ、そのまま使用できる業界ソリューションを作り出すことができる唯一の立場にあると言えます。こうしたアプローチによって、お客様はそれぞれに特有のビジネス・ニーズに対応するために IBM のソフトウェア製品の統合に費やす時間と労力を少なく抑えることができます。

IBM SOA リファレンス・アーキテクチャーは、サービス指向アーキテクチャーの価値提案を実現する鍵となります。その価値提案とは、柔軟で再利用可能なアセットの作成を促進し、エンド・ツー・エンドのビジネス・ソリューションを実現することです。

The Open Group が公開した SOA リファレンス・アーキテクチャー標準は、クラウド・ソリューションのアーキテクチャーを含め、サービス指向ソリューションのアーキテクチャーの設計および実装を決定する上でのガイドラインとオプションを規定しています。SOA リファレンス・アーキテクチャー標準の目的は、アーキテクチャーを作成して評価するための青写真を提供することです。さらにこの標準では、SOA の基本要素をソリューションやエンタープライズ・アーキテクチャーに統合するための洞察を行い、そのためのパターンやビルディング・ブロックを明らかにしています。

IBM SOA リファレンス・アーキテクチャーは、ビジネス・プロセス、ビジネス・ツール、メッセージ交換、サービス統合、データ・アクセスを用い、レガシー・ソフトウェアおよびコンポーネントをカプセル化したソリューションを作成する際に役立ちます。

詳細については、「SOA リファレンス・アーキテクチャー標準に対する IBM のアドバンテージ」を参照してください。

IBM が提供する業界ソリューションの多くは、IBM SOA リファレンス・アーキテクチャーに従って開発されます。そのため、これらのソリューションには以下のような特徴があります。

  • ポータルを使用して、アプリケーションのコンポーネントを 1 つのビューに集約し、ユーザーがそれぞれのロールに基づいてビジネス・サービスや IT サービスを利用 (操作) できるようにします。
  • エンタープライズ・サービス・バスを使用して、サービスを柔軟に統合および接続できるようにします。
  • サービス指向のライフサイクル全体に、アイデンティティー、認証、許可、監査、およびコンプライアンスなどのセキュリティー原則を適用します。
  • ソリューションを利用して、問題の発生防止、切り分け、診断、および修正に必要な情報を収集できるように、重要業績評価指標 (KPI) をリアルタイムで監視します。
  • ビジネス・アナリティクスを適用して微妙な関連性を見つけ出し、ソリューションを利用して適切な判断を行えるようにします。
  • 統合ポータルを介してレポートを設計、カスタマイズ、そして使用します。

ご想像どおり、WebSphere Portal、Lotus Sametime、Cognos Business Intelligence、WebSphere MQ、WebSphere Message Broker、Business Process Management、Tivoli Access Manager、DB2、Rational Asset Manager などからなるソフトウェア製品群の機能を組み合わせて、すぐに使用できるソリューションを新たに作り出すことができます。

したがって、問題となるのは・・・
「・・・元々テナントという概念のない既存のエンタープライズ製品を利用して、どのようにマルチテナント型 SaaS アプリケーションを作成するかです。しかも、ますます増えていくテナントをそのソリューションでサポートするために、スケールアップできる必要もあります。」

最近、私たちは Industry Solutions チームと共に、シングルテナント型 SOA ソリューションを、IBM SmartCloud Enterprise に SaaS ソリューションとしてデプロイできるマルチテナント型 SOA ソリューションに変換するための開発作業に取り組みました。SOA ソリューションでは多くの IBM ミドルウェア製品を利用することができます。それをマルチテナンシーに変換するのは恐ろしく大変な作業のように思えるかもしれませんが、実際には IBM ミドルウェア製品の拡張性によって、この変換はかなり簡単に行うことができます。

この記事では、皆さんが既存のシングルテナント型ソリューションをマルチテナント型 SaaS ソリューションに変換する際に役立つ技術について説明し、変換についての有用な洞察を行います。

まずは、マルチテナンシーの概念を検討します。


マルチテナンシーの概念

最近では次第に、ISV だけでなく大小の企業も新しい配信モデルとしてクラウド・ベースのソリューションと SaaS を調査するようになっています。IBM ソフトウェア製品群に含まれる製品を使用すれば、何通りかの手法で新たな SaaS オファリングを作成することができます。

手法の 1 つは、SaaS ソリューションとして提供するまったく新しいオファリングを一から作成することです (例えば、IBM Blueworks Live を使用するなど)。もう 1 つの手法では、元々はオンプレミスのエンタープライズ・オファリングとして生まれた製品を SaaS ソリューションに進化させます (例えば、Commerce-as-a-Service、Cognos、および IBM SmartCloud for Social Business (以前の LotusLive) を使用)。

前者の手法では、土台からマルチテナンシーが構築される傾向にあります。一方の後者の手法の場合、オンプレミス・オファリングにはおそらくテナントの概念がありませんが、カスタム構成を採用することによってマルチテナンシーを実現することができます。

次は、一般的なマルチテナンシーのシナリオを検討し、テナンシーの基本定義がよく理解できるようにします。


一般的なマルチテナンシーのシナリオ

マルチテナンシーの基本概念については、以前の記事で説明しました (「参考文献」を参照)。理解しておかなければならない重要な概念は、リソースの共有にはさまざまな可能性があることです。

図 1 に、クラウド環境でのマルチテナンシーが関連する技術スタックを明らかにします。

図 1. リソースの共有レベルによって決まる、さまざまなマルチテナンシー
リソースの共有レベルによって決まる、さまざまなマルチテナンシー

ご覧のように、マルチテナンシーのシナリオには以下の 5 つがあります。

  1. リソースを共有しない
  2. ハードウェア・リソースを共有する
  3. オペレーティング・システムを共有する
  4. ミドルウェアを共有する
  5. アプリケーションを共有する

これらのシナリオのそれぞれについて、以下に詳しく説明します。

シナリオ 1: 共有しない (No sharing): テナントのそれぞれが、アプリケーション、ミドルウェア、オペレーティング・システム、インフラストラクチャー (ハードウェア) からなる完全なスタックを持ちます。同じ物理データ・センターで実行できるという点を除き、テナントは互いに完全に分離されます。

シナリオ 2: ハードウェアを共有する (Shared hardware): 共有の第一段階として、テナントはデータ・センター内のインフラストラクチャーを共有します。テナントは、例えばデータ・センター内のサーバー (例えば、Intel、Power)、ストレージ (SONAS、NetApp)、ネットワーク (Juniper、Cisco) を共有することができます。

シナリオ 3: オペレーティング・システムを共有する (Shared operating system): テナントはインフラストラクチャーに加え、オペレーティング・システムを共有します。通常は、ハードウェア上で複数のオペレーティング・システムを実行できるように KVM や VMware などのハイパーバイザーを使用してハードウェアを仮想化します。この場合も、テナントは他のテナントから厳格に分離されます。アプリケーション・サーバー、データベース・サーバー、およびアプリケーションについては、テナントごとに独自のバージョンを使用できるためです。このレベルの共有は、IaaS (Infrastructure as a Service) とも呼ばれます。

シナリオ 4: ミドルウェアを共有する (Shared middleware): テナントは共有オペレーティング・システムおよびインフラストラクチャーをベースに実行される一連のミドルウェア・サービス (セキュリティー・サービス、ポータル、データベース・サービス、監視サービスなど) を共有します。これらの共有ミドルウェア・コンポーネントをベースに、さまざまに異なるアプリケーションを作成することができます。このレベルの共有は、PaaS (Platform as a Service) とも呼ばれます。

シナリオ 5: アプリケーションを共有する (Shared application): テナントは他のテナントと同じアプリケーションを共有します。このアプリケーションを共有するという性質のため、テナントはミドルウェアも同じものを共有します。これには、アプリケーションを実装するために使用したミドルウェアも含まれます。テナントはアプリケーションの下層にあるリソースを共有するものの、それでもテナント同士は論理的に分離されます。テナントが他のテナントのアセット (データベース・サーバーやファイルシステムに保管されたデータなど) を見ることはできません。このレベルの共有は、SaaS (Software as a Service) とも呼ばれます。

一般に、マルチテナンシーが適用されるポイント (シナリオ 5 では、共有アプリケーションを意味します) が高いほど、その下層にあるスタックで共有される部分が多くなるため、新しいテナントをセットアップするために必要な作業は少なくなります。次第にテナントの数を増やしていくことを予定しているビジネスにとって、技術リソースとビジネス・リソースをいずれも大幅に増やすことなく、スケーリングができる点は、事前に考慮すべき重要な点です。1 つの共有コード・ベースがあれば、プロバイダーとカスタマーの両方がプロジェクトの成果をビジネスの価値に変えるまでの時間を短縮することができ、新しいアイデアを何ヶ月や何年もかけずに数週間でデプロイできるようになります。

前述のように、シングルテナント型ソフトウェア・ソリューションの一部には、その設計に元々テナントの概念が含まれていません。次のセクションでは、まずこの問題を解決する方法について検討します。その後で、シングルテナント型ソフトウェア・ソリューションをマルチテナント型ソフトウェア・ソリューションに変換するのに役立つ 7 つの技術を明らかにします。


分離によって生み出される隠れたテナント

これまでに名前を挙げたソフトウェア製品は、いずれも明示的なテナントの概念を伴うものではありません (そのため、テナントに含まれるユーザーという概念もありません)。しかしその一方、それぞれの製品には、分離の概念が組み込まれています。マルチテナント型ソリューションを実装するには、この分離の概念を利用することができます。

例えば、Rational Asset Manager を使用してコラボレーティブ・マルチテナンシーを実現するためのベスト・プラクティスに関する記事「アセットを中心としたクラウド・ベースのコラボレーションのためのベスト・プラクティス」(「参考文献」を参照) では、Rational Asset Manager に用意された「アセット・コミュニティー」の概念を利用して、テナント間でのアセットの分離と共有を実現する方法を説明しています。アセット・コミュニティーはテナントに対して作成することができます。そのテナントに属するユーザーはアセットをコミュニティーに公開できる一方、デフォルトでは、別のテナントに属するユーザーはこのアセット・コミュニティーを見たり、このコミュニティーにアクセスしたりすることができません。

前に触れた IBM オファリングの Rational Asset Manager 以外の製品には、これと同様の方法を適用することができます。IBM ソフトウェアは拡張可能なので、大抵の場合は、これらの製品の API を使用してカスタマイズするだけの話です。

ここからは、この概念を使用したマルチテナンシーへの変換に役立つ 7 つの技術を検討します。


マルチテナンシーに変換するための 7 つの技術

業界 SOA ソリューションの変換に取り組むなかで、私たちは皆さんのシングルテナント型アプリケーションを IBM ミドルウェア製品をベースとした完全なマルチテナント型アプリケーションに変換する際に役立つ可能性のある 7 つの技術を突き止めました。具体的には、以下の技術です。

  • 共有 LDAP
  • シングル・サインオン
  • 共有データベース・サーバー
  • 共有エンタープライズ・サービス・バス
  • テナント別のレポート
  • テナント別のログ・ファイル
  • WebSphere Portal による統一ユーザー・インターフェース

それぞれの技術について、詳しく検討しましょう。

共有 LDAP

マルチテナント環境を作成するために、まず始めに導入すべきものの 1 つは共有 LDAP です。これによって、ユーザーと組織の情報を一元管理する場所が提供されます。私たちが使用しているのは、LDAP 実装としてよく使用されている IBM Tivoli Directory Server です。すべての IBM ソフトウェア製品では、あらかじめ Tivoli Directory Server を簡単に統合できるようになっているので、既存のインストール・アセットの多くを利用することができます。

共有 LDAP には注意しなければならないことがいくつかあります。そのなかの 1 つが、各製品には、その製品に固有の検索フィルターを作成できるように最適化された独自のデフォルト LDAP ディレクトリー構造と属性が用意されていることです。したがって、多数の製品で LDAP を共有する場合には、これらのデフォルト設定の正規化および調整が必要になってきます。

例えば、大/小文字の区別には注意が必要です。製品によって大/小文字を区別するものもあれば、区別しないものもあります。例えば、大/小文字を区別しない製品で以下のように解釈される記述があるとします。

cn=users, o=ibm, c=us

この記述は、大/小文字を区別する製品では以下のように解釈されている可能性があります。

cn=Users, o=IBM, c=US

シングル・サインオン

シングル・サインオン (SSO) では、ユーザーが一度ログインすれば、システムごとにログイン・プロンプトが出されることなく、すべてのシステムへのアクセス権が取得されます。ミドルウェア製品の多くは WebSphere Application Server (WAS) 上で動作するため、ブラウザー・ベースの環境で効果的に機能する IBM Lightweight Third-Party Authentication (LTPA) 技術を使用することができます。

図 2 に一例として、シングル・サインオンの全体的な流れを示します。

図 2. LTPA トークンを使用することによる、複数のサーバー間でのシングル・サインオン
LTPA トークンを使用することによる、複数のサーバー間でのシングル・サインオン

HTTP リクエストが到着すると、Tivoli Access Manager WebSEAL は Tivoli Access Manager Policy Server と連動して、要求されたリソースが保護されているどうかを判別します。リソースが保護されている場合、Tivoli Access Manager WebSEAL はユーザーが認証されてからでなければ、アプリケーション (例えば、WebSphere Portal で実行されているポートレット) へのアクセス要求が許可されないようにします。

ポートレットが別のサーバー (Lotus Sametime Community Server) にアクセスする必要があるときには、共有 LTPA トークンが、Tivoli Access Manager WebSEAL によって認証済みのユーザーを識別します。したがって、ユーザーは再度認証をするように求められることはありません。

LTPA トークンは WebSphere Application Server 間の SSO を実装する場合の標準的な技術ですが、クラウドにこのようなシステムをデプロイするときには、やはり注意が必要です。私たちがソリューションをデプロイするときには、以下の課題に直面しました。

  • 通常、LTPA 鍵ファイルは、あるシステム (例えば、Tivoli Access Manager WebSEAL) からエクスポートされたものが、別のシステム (例えば、WebSphere Portal、Domino サーバー) にインポートされます。重要な点は、この鍵ファイルは、共有 LDAP を一貫した方法で記述することです。例えば、以下のように完全修飾ドメイン名を使用します。
    com.ibm.websphere.ltpa.Realm=vhost1111.site1.compute.ihost.com\:389

    エイリアスを使用しているサーバーが、エイリアス名を使用して LTPA 鍵ファイルをエクスポートし、エイリアスの使用をサポートしていない別のサーバーがこの鍵ファイルをインポートする場合には、SSO は正しく機能しません。

  • ログ・ファイルに LTAP トークンが失効していることを示すエラーが記録される場合もあります。これは、各仮想マシンの OS に設定されている時刻が一致していないことに起因するエラーです。例えば、Tivoli Access Manager WebSEAL の VM に設定されている時刻が 10:00 で、WebSphere Portal の VM に設定されている時刻が 1:00 の場合、WebSphere Portal サーバーがトークンを開いて、それをローカル時刻と照らし合わせると、トークンがすでに失効していると判断することになります。

    IBM SmartCloud 環境では、プロビジョニングされる複数の VM 上で、時計が同じ時刻に設定される保証はありません。このことから、上記のエラーはかなり目立った問題となっています。SSO を正しく機能させるためには、各 VM の時刻が同じタイムゾーンの同じ時刻になるように再設定するか、再同期するためのステップを追加で行う必要があります。

また、フロー全体をテストする前に、ペアごとに SSO テストを行うこともお勧めします。例えば、以下のペアで SSO が機能することを確認します。

  • Tivoli Access Manager WebSEAL と WebSphere Portal
  • Tivoli Access Manager WebSEAL と Lotus Sametime Community Server
  • WebSphere Portal と Lotus Sametime Community Server

以上のペアで機能することが確認できたら、Tivoli Access Manager WebSEAL から WebSphere Portal、そして Lotus Sametime Community Server までのパス全体をテストします。SOA ソリューションには多数のサーバーが関与するため、クラウド環境で考えられるさまざまな種類の障害を管理するには、体系的なテスト方法を用意した上でそのテストを繰り返すことが成功に不可欠な要素となります。

共有データベース・サーバー

マルチテナント環境で考慮しなければならない 3 つ目の事項は、テナントごとのデータを分離する方法です。シングルテナント型アプリケーションで DB2 などのリレーショナル・データベースを使用しているとしたら、このタスクは比較的容易になります。

マルチテナント型データベースには、図 3 に示す共通パターンがあります。

図 3. マルチテナント型データベースのパターン
マルチテナント型データベースのパターン
  1. 各テナントがそれぞれ独自のデータベースを使用します。
  2. 1 つのデータベースの中で、各テナントがそれぞれに固有のスキーマを使用します。
  3. すべてのテナントが同じデータベース、同じスキーマを共有します。

1 番目のシナリオでは、最も少ない変更でアプリケーションにテナントの概念を認識させることができます。通常は、アプリケーションがテナント ID に基づくテナント固有の正しいデータベースに接続するだけで十分です。

この 1 番目のシナリオは、テナント間の分離性が最も高いシナリオでもあります。例えば、テナント 1 とテナント 2 では、それぞれに異なるスケジュールでデータベースをアーカイブすることができます。

2 番目のシナリオが適用される一般的なケースは、既存のアプリケーションに固有のメタデータの概念があり、既存のデータベース接続の設計方法が理由で、ユーザーのデータを同じデータベースに格納しなければならない場合などです。この場合、同じデータベース内でスキーマによってテナントのデータを分離するという方法にすれば、再設計が必要最小限になります。

3 番目のシナリオでは、アプリケーションでの変更およびテーブル設計の変更が最も多くなります。テーブル設計にはテナント ID の概念を取り入れ、アプリケーションが更新または取得する特定のテナントのデータの範囲を、テナント ID を基準に設定できるようにしなければなりません。始めから SaaS として提供するように設計されたアプリケーションでは、このシナリオが一般的に使用されます。

共有エンタープライズ・サービス・バス

エンタープライズ・サービス・バス (ESB) は、サービスの実装と、コンシューマーに対して表示されるサービスのビューとを切り離すことによって、SOA 実装の概念をサポートします。

コンシューマーに対して表示されるサービスのビューを、実際のサービス実装から切り離すことで、アーキテクチャーの柔軟性は向上します。これにより、サービス・プロバイダーを別のサービス・プロバイダーに変えても、アーキテクチャーが変更されたことや、別のアーキテクチャーに置き換わったことが、コンシューマーに気付かれなくなります。

ESB には多種多様なパターンがあり、それぞれのパターンに対応する製品マッピングもさまざまです (「参考文献」の Redbooks を参照)。私たちが現在取り組んでいるプロジェクトでは、WebSphere MQ と WebSphere Message Broker を使用した典型的なトポロジーに焦点を合わせています。

WebSphere MQ は、アプリケーション間の通信を容易にします。WebSphere MQ でのキューは、アプリケーションの間で交換されるメッセージのコンテナーとして機能します。そしてこれらのキューを管理するキュー・マネージャーは、キューのコンテナーとして機能します。キューに入れられたメッセージをブローカー・ルールを使用して操作するには、WebSphere MQ を拡張する WebSphere Message Broker を使用することができます。

マルチテナント型システムでは、WebSphere MQ と WebSphere Message Broker の 1 つのインスタンスをすべてのテナントが共有します。このようなセットアップでは、あるテナントが送信した情報を別のテナントから分離しなければなりません。このような情報の分離を実現する 1 つの方法は、テナントごとに固有のキュー・マネージャーをプロビジョニングすることです。テナント固有のキュー・マネージャー内のキューが他のキューから分離されれば、これらのキューに渡されるメッセージも分離されます。キュー・マネージャーは個別に管理できるため、テナントのキュー・インフラストラクチャーに影響を及ぼす問題が、他のテナントに影響することはありません。

マルチテナント型システムのテナントが、それぞれに異なるブローカー・ルールのセットを使用するという方法もあります。テナントごとに固有のブローカー・ルールを使用できるようにする場合には、テナント固有のキュー・マネージャーをテナント固有のブローカー・ルールに関連付けます。これにより、テナント間でブローカー・ルールを分離することができます。

図 4 に、2 つの異なるテナントが同じ ESB インスタンス内で実行される場合の全体的な構成を簡単に示します。

図 4. マルチテナント型エンタープライズ・サービス・バスのパターン
マルチテナント型エンタープライズ・サービス・バスのパターン

テナント別のレポート

レポート作成は、あらゆるソリューションに共通の要件です。IBM Cognos Business Intelligence (BI) には、ユーザーがレポートを作成してデータを分析し、より適切なビジネス判断を行えるように、包括的なクエリーおよびレポート作成機能が用意されています。その上、Cognos BI は、複数のカスタマーがリソースを共有可能なマルチテナント環境で動作可能なプラットフォームとして実績があります。

Cognos BI は、レポートおよびレポート・メタデータをフォルダー構造にグループ化します。レポートから、必要なデータにアクセスするには、レポートに表示されるデータのロケーションおよびアクセス・パラメーターを定義するデータソース接続オブジェクトを使用します。

すべてのテナントが Cognos BI の単一インスタンスを共有するマルチテナント環境では、テナントに固有のフォルダーとデータソース接続を作成することによって、テナントを互いに分離します。テナントに属するユーザーは、そのテナント用に作成されたフォルダーとデータソース接続にのみアクセスが許可されます。このようにしてテナント間の分離が強化されるため、テナントが互いのデータやレポートを見ることはできません。

開発者は IBM Cognos Software Development Kit を使用することで、シームレスにマルチテナンシーを実現し、Cognos の機能をその独自のマルチテナント型アプリケーションに統合することができます。例えば、新規テナントが登録する際に、アクティベーション・ハンドラーは Web サービス呼び出しを行い、新規フォルダーとそのテナントにのみ可視になるデータソース接続を作成することで、透過的に Cognos BI にアクセスすることができます。

テナント別のログ・ファイル

これで、テナントは同じミドルウェアを共有するようになったので、今度はテナントが自ら実行した処理によって生成されたロギング・メッセージだけを確認できるように、テナントごとにログ・ファイルを分ける方法を検討することが重要になります。トレース・ファイルおよびログ・ファイルをテナントごとに分ければ、SaaS 管理者が特定のアカウントに固有の問題をトラブルシューティングすることができます。

テナント別にログ・ファイルを作成するために必要なのは、各 WebSphere 製品が提供しているロギング・フレームワークを拡張することのみです。各製品のディレクトリー構造はそれぞれに異なるので、ログ・ファイルが配置される場所は製品ごとに異なります。

各ソフトウェア製品のログ・ファイルは、ログ集約ユーティリティーを使って特定のテナント用の 1 つのアーカイブに集約することができます。

WebSphere Portal による統一ユーザー・インターフェース

SOA ソリューションで統合しなければならない各種のコンポーネント、アプリケーション、プロセス、そしてコンテンツに対し、WebSphere Portal は統一されたユーザー・インターフェースを提供することができます。例えば、図 2 に示されているシームレスなシングル・サインオン・エクスペリエンスは、WebSphere Portal によって実現できるため、ユーザーがこのポータルにログインした後は、ユーザー ID とパスワードを再入力することなく、その背後にあるすべてのアプリケーションにアクセスすることができます。

さらに、マルチテナント型 SaaS アプリケーションを作成する上で、WebSphere Portal の以下の機能が特に役立つこともわかりました。

  • ポータル・コンポーネント・モデル・ポートレット。複数の SaaS アプリケーションで使用できる、再利用可能なコンポーネントを作成することができます。このポートレットによって標準プログラミング・モデルが提供されるので、テナントは独自のカスタム・ポートレットを提供することで、容易に SaaS ソリューションを拡張することができます。
  • ポータルのカスタマイズ機能。テナントはスタイルシートを変更して、独自の専用スキンを使って UI をカスタマイズすることができます。
  • ポートレットへのロール・ベースのアクセス。ユーザーをテナントに追加するときに、共有 LDAP にユーザーの該当するロール (その企業における管理者、販売担当など) を設定することによって、適切なポートレットにアクセスする権限を自動的にユーザーに付与することができます。
  • モバイルおよび複数の機器のサポート。ほとんどの SaaS アプリケーションには、モバイル機器からアクセスすることができます。IBM Mobile Portal Accelerator により、機器に依存したオーサリングを行うことなく、複数の機器をすぐにサポートできるようになります。
  • WebSphere Portal 7.0 でのポータル・ファームのサポート。これは、クラウド環境で実行するには最適です。ポータル・ファームは、ポータル・サーバーの独立した一連のインスタンスで、従来のクラスターのように動作しますが、管理およびスケーリングを行うのは遥かに簡単です。ファームのサイズは、容量のニーズに応じて自動的に拡大/縮小することができます。

まとめ

この記事では、最新の経験と教訓を共有するという私たちの目標の一環として、IBM SmartCloud Enterprise 上で稼働するマルチテナント型アプリケーションを構築するなかで学んだ経験および教訓を紹介しました。

具体的には、既存のシングルテナント型 SOA アプリケーションをマルチテナント型 SaaS アプリケーションに変換するために私たちが使用した技術を説明しました。今後、SaaS 市場が成熟するにつれ、より複雑な変換を支援するための新しいツールが登場することを期待します。

謝辞

この記事の作成を支援してくれた IBM の Tony Carrato 氏に感謝いたします。

参考文献

学ぶために

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

議論するために

コメント

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, Rational, Information Management, WebSphere
ArticleID=806645
ArticleTitle=シングルテナント型アプリケーションをマルチテナント型アプリケーションに変換する
publish-date=03292012