はじめに

Amazon Web サービスを利用した経験のある読者のなかには、クラウド・コンピューティングで SaaS が果たす役割について興味を持った方がいると思います。クラウド・コンピューティングを利用した SaaS を開発する利点は、Amazon Web サービスをベースに、Web 対応のクラウドに適した SaaS を開発できるということです。そのような SaaS を、コストの低い従量制の料金を設定してコンサルタントや製品技術者などの大規模な顧客基盤に販売すれば、顧客はソフトウェア購入の先行投資を削減することができます。別の利点として、SaaS では一元化された場所で更新が行われるため、頻繁に出てくるパッチとアップグレードをダウンロードする必要がありません。

この記事では、まず SaaS とクラウド・コンピューティングとの類似点と相違点について説明し、SaaS がクラウド・コンピューティングにおいて果たす役割、そして SaaS がユーティリティー・コンピューティングや PaaS (Platform as a Service) などの他の形態のクラウド・コンピューティングとどのように違うのかを探ります。続いて、SaaS サービスを分類し、それぞれのサービスのアプリケーション例を紹介し、マルチテナンシーと仮想化との組み合わせについて説明します。さらに、使われていないリソースと相互運用性の問題について説明し、それぞれの問題に対するソリューションを提示します。そして最後に、クラウド・コンピューティングでの SaaS のパフォーマンスをテストするために必要となる基準と、SaaS でのセキュリティー問題について検討します。

SaaS の成熟度

SaaS は十分に成熟しており、マッシュアップの一部、あるいは PaaS 製品やインターネット・ベースのサービスに対するプラグインと見なす必要があります。SaaS が提供するのは、初期設定の要らない完全なアプリケーションです。エンタープライズ・リソース管理やプラント・エンジニアリング管理などがその例で、これらのアプリケーションには、ユーザーがどこにいようと Web ブラウザーからアクセスすることができます。

SaaS のサービスがここまで成熟した背景には、サーバーおよびディスク両方での仮想プラットフォーム・ソフトウェアの存在があります。サービスの成熟度という点で SaaS に続くのは PaaS と IaaS (Infrastructure as a Service) で、最も成熟度が低いのはインターネット・ベースのサービスです。PaaS はディスク上で API と仮想プラットフォーム・ソフトウェアを実行します。一方、IaaS は、インターネットを介して完全なコンピューター・インフラストラクチャーを提供し、例えば Amazon EC2 や IBM Blue Cloud のユーザーに対してサーバーのみを仮想化します。インターネット・ベースのサービスの例には、Amazon S3、Amazon Simple DB、Google Base が挙げられます。

例 1: プラント・エンジニアリング管理

プラント・エンジニアリング会社が製造に要する期間を短縮し、物品購入、販売、および会計取引を安全で確実に行えるようにするために使用できる完成度の高い SaaS を構築することができます。SaaS は、外注製造の生産量を計画するためのビジネス・プロセスの決定に役立つはずです。顧客基盤は、プラント管理者から品質管理者、生産ライン管理者、COO、CFO にまで及びます。

SaaS は、経営幹部が従量課金対象の環境内でデータを利用するのに役立つだけではありません。経営幹部は財務、プラント設計、製造所要期間、供給管理、人材資金計画において重要な決定を行いますが、SaaS は製造中のプラントの意思決定者向けビジネス・インテリジェンス・ツールとして使用することもできます。例えば SaaS を介して提供されるツールが、意思決定者に運搬時間、各工程に要する時間、予備システムへの切り替え時間などで達成すべき数値目標に関する情報を提供する場合もあります。さらに、これらのツールが分析を行い、数値が目標に届かない場合に意思決定者が取るべき措置を診断することもあります。

例 2: 遠隔教育など

教育プログラムは、SaaS として構築することが可能です。DigitalChalk の SaaS モデルは大学および企業の顧客を対象に、教育内容 (遠隔教育を含め) を Web サイトによって提供しています。SaaS を構築するにあたって、DigitalChalk ではデータ・センターを使用する代わりに、独自の AMI (Amazon Machine Image) を作成して Amazon S3、EC2、SQS を利用しました。

その他の SaaS サービスを開発するには、EC2 が実行する IBM AMI を利用するという方法もあります。IBM AMI には、IBM DB2、IBM Informix、IBM Websphere Smash、および IBM Lotus Web Content が含まれます。AMI のリポジトリーを拡張するには、あらかじめ構成された AMI テンプレートを使用することも、アプリケーション、ライブラリー、データ、そして関連する設定が含まれる AMI を作成することもできます。

SaaS サービスの分類

Microsoft® では SaaS を 2 つのカテゴリーに分類しています。1 つは事業区分別サービス、そしてもう 1 つは利用者指向サービスです。いずれのカテゴリーにしても、利用登録ベースで販売されています。事業区分別サービスは、金融、サプライ・チェーン管理 (SCM)、顧客関係管理 (CRM) を対象とした、従量課金制登録環境での大掛かりなカスタム・ビジネス・ソリューションです (例えば、プラント・エンジニアリング管理など)。利用者指向サービスは、対象となる利用者に無料でサービスを提供するもので、広告による収益で賄われます。

この 2 つのカテゴリーでは限りがあると思うので、もう 2 つのカテゴリーを追加します。それは、共有リソース・サービスとアウトソーシング・サービスです。共有リソース・サービスではユーザー間でサービスを分配します。大企業は、SaaS が提供するサーバーを利用することで、最大負荷時に必要な容量を低コストで使用できるため、内部データ・センターの規模を大きくする必要性が少なくなります。一方、中小企業向けのアウトソーシング・サービスでは、中小企業はデータ・センター・インフラストラクチャーを完全に外部化することによって、利用登録ベースでサービスを提供できるようにします (例えば、遠隔教育など)。

利用者指向サービスは例外として、SaaS サービスによって収益性がもたらされるのは、ビジネスが大規模な顧客基盤にサービスを提供する場合だけです。使用回数制料金で請求するユーティリティー・コンピューティングとは異なり、SaaS サービスでは安価な従量課金制登録による低いマージンで大きなインフラストラクチャー・コストを十分にカバーしなければなりません。利用登録に加え、収益モデルには紹介料、取引手数料、使用量に基づく料金、パフォーマンスに基づく料金、再販マージン、そして収益分与も含まれます。

パフォーマンス最適化のための調整

それぞれの例が示している SaaS の特性は、構成可能性、スケーラビリティー、そしてマルチテナンシーによる効率性の 3 つです。SaaS にこの 3 つの特性が 1 つでも欠けていれば、SaaS としての成熟度は足りません。マルチテナンシーおよび仮想化の最高の組み合わせにより、最適なパフォーマンスに向けてシステムをより柔軟に調整することができます。

マルチテナンシー

マルチテナンシーとは、シングル･インスタンスのソフトウェアが SaaS として実行されて複数の顧客組織 (テナント) にサービスを提供するソフトウェア・アーキテクチャーのことです。マルチテナント型アーキテクチャーでは、データと構成は実質的に顧客組織ごとに区分され、それぞれの顧客組織が仮想アプリケーション・インスタンスを利用できるようになっています。マルチテナンシーでは、複数の IT リソースを 1 つの運用に統合することにより、通常のスケール･メリットを上回るコスト削減を可能にします。

マルチテナンシーの欠点は、顧客基盤の規模が小さいと、アプリケーション用に用意されたメモリーと処理能力に関わる多大な費用を負担する結果になり得ることです。顧客基盤が大きければ、マルチテナンシーの効果がこの欠点を上回ります。なぜならこのような固定費は、顧客の数によって償却されるからです。また、もう 1 つの欠点として、効率的なマルチテナント型アプリケーションを構築するためには追加プログラミングが必要になることがあります。その場合、固定費はさらに大きくなります。

仮想化

SaaS アーキテクチャーでのサーバー仮想化は、マルチテナンシーでのデータと構成を実質的に顧客組織ごとに区分するというだけではありません。仮想化の 1 つの利点は、ストレージとデータベース・リソースをはじめとする実際のサーバーの数とリソースの論理サイズを動的に調整することで、需要の増加 (例えば 12 月の購買増加など) に合わせてシステムの容量を増やせることです。一方、欠点としては、仮想化ソフトウェアの相互運用性の問題が原因で、ベンダー間で仮想サーバーを移植できないことがあります。

問題 1: 使われていないリソース

Web サービスをベースに動作する SaaS は、サービス指向アーキテクチャー (SOA) を利用してソフトウェア・アプリケーション相互の通信を可能にします。それぞれのソフトウェア・サービスは、サービス・プロバイダーまたはサービス・リクエスターとして機能します。SaaS サービス・プロバイダーはその機能を、公開ブローカーを介して他のアプリケーションに公開します。一方、SaaS サービス・リクエスターは他のサービスからデータと機能を取り込みます。プロバイダーとリクエスターはいずれも、SaaS サービスのデプロイメントと管理においてスケール･メリットを利用します。

Web サービスは通常、リソースが十分にあろうとなかろうと疎結合されています。需要に応じて容量が増減するなかで、サービスのプロバイダーとリクエスターのリソースを無駄にしないためには、疎結合と密結合を切り替えられる Web サービスを作成して SaaS アプリケーションを補完してください。この切り替えとは、使われていないリソースの範囲が一定のレベルにまで達したことを伝えるアラートを受け取ると、Web サービスが疎結合から密結合に切り替わるというものです。

問題 2: 相互運用性の問題

SaaS が Web に対応し、クラウドに適しているとしても、企業はその同じSaaS アプリケーションを別のベンダーで実行するのは難しいことに気付く場合があります。別のベンダーでは、例えば異なるフォーマットでデータをインポートおよびエクスポートしている場合があるからです。一例として、2 つの SaaS アプリケーションをマッシュアップする場合を考えてみてください。一方のアプリケーションでは、あるベンダーのクラウド・コンピューティング環境で業界標準の API を実行しています。もう一方のアプリケーションでは独自仕様の API を別のベンダーのクラウド・コンピューティング環境で実行しています。この場合、何らかの再設計を行わない限り、マッシュアップは上手くいかないでしょう。

まず対処しなければならないのは、この 2 つのクラウド・コンピューティング・ベンダー間での移植性です。ベンダーが環境間での通信をすでに可能にしているのか、それとも環境間でデータをマーシャリングしなければならないのかを検討してください。そして、この 2 種類の API の間でデータ・フォーマットとロジックが互換性を持つのか、それとも 2 つのアプリケーション間でデータのフォーマットを設定しなおす必要や、ロジックを変更する必要があるのかを検討します。現在、データのインポートおよびエクスポートに標準の API はありませんが、IBM と Amazon では連携して相互運用性の実現に取り組み、その結果マッシュアップを容易に設計および管理できるようにしようとしています。

1 にテスト、2 にも 3 にもテスト

あらゆるソフトウェア開発では、クラウド・コンピューティングと SaaS を確実に環境に配慮したものにするためにはテストが欠かせません。SaaS サービスおよびアプリケーションのテストを行って、サービス品質を向上させる必要があります。テストに取り掛かるにはまず、複数の Web ブラウザー、オペレーティング・システム、ネットワーク接続性などのエンド・ユーザー環境をシミュレートします。このシミュレーションを行わなければ、初めからすでに失敗は目に見えています。例えば、ある Web ブラウザーに備わっている機能が、別の Web ブラウザーにはない場合もあるからです。機能の不足は、ユーザーがクラウド・コンピューティングで SaaS サービスにアクセスする方法や、使われていないリソースを利用する方法に影響を与え兼ねません。

次に、マルチテナンシーの脆弱性をテストしてください。例えば、ソフトウェアの欠陥によってユーザー A がユーザー B になりすますことができるかどうかなどです。仮想化の脆弱性については、サーバー A がサーバー B のふりをすることができるかどうかなどをテストします。その他にテストしなければならない内容には、ユーザーがシステムに負荷を与え過ぎることなく、どこまで使用量のスケーリングが可能か、そして従量課金制環境で秘密鍵を管理するのに最適な方法、バックアップしてリストアしなければならないクラウド内のデータの量などがあります。SaaS モデルではバージョン管理と変更管理は顧客の作業ではありませんが、この 2 つについてもテストして、適切に検証できることを確認しておかなければなりません。さらに、SaaS は水平方向のアプリケーションであるため、SaaS が垂直方向のニーズにも対応するかどうかという点も重要です。

念頭に置いておかなければならないのは、クラウド内での SaaS 製品のデプロイメントと使用条件は、一般的なデータ・センター環境にデプロイされた製品とは異なるということです。したがって、クラウド・ベースのアプリケーションではテスト要件も異なってきます。例えば SaaS 製品を変更する際、顧客に通知する必要はありません。SaaS デプロイメント・モデルでのリリースは他のモデルよりも頻繁に行われる傾向があります。これは、一元管理ではマイナーな更新を簡単に行えるためですが、この頻繁なリリースにより、SaaS 製品の顧客サポート問題は短いサイクルで発生しがちです。さらに、十分なテストを行わずに当座の処置として変更が行われた場合、この短いリリース・サイクルが顧客に大きな面倒をもたらす可能性があります。

テスト・インフラストラクチャーを購入して、管理、運用するには費用がかかります。SaaS インフラストラクチャーが拡大するにつれ、機能テスト、リグレッション・テスト、パフォーマンス・テスト、負荷テストをセットアップするとなると、その費用は高くつきます。SaaS 製品のファイナル・リリース前には常に、潜在顧客からのフィードバックを受けるためのアルファ版およびベータ版のテスト環境をセットアップしなければなりません。したがって、安価な利用登録から収益を得る一方で、テストのための高額なコストを吸収するためには、大きなマーケット･シェアの獲得を目指した計画を立て、それを実現することが重要です。

考慮すべきセキュリティー上の問題

災害復旧、秘密鍵の管理、統制活動の開示は、いずれも従量課金制インフラストラクチャーの SaaS 環境において、考慮すべきセキュリティー上の問題です。適切な計画と実装が行われていなければ、セキュリティー保護のコストが SaaS とクラウド・コンピューティングによる利益を大きく上回ってしまう可能性があります。

災害復旧

2008年の初めに Amazon の S3 および EC2 で 3 時間のサービス停止が発生してからというもの、災害復旧計画は非常に重要な問題となっています。サービスが停止している間、利用者は販売機会を逃し、経営幹部は重要なビジネス情報にアクセスできませんでした。この事態が及ぼした影響は、SLA に規定されているデータ・リカバリーおよびサービス料金の控除では到底補えない規模でした。

SaaS サービスの利用者は機能停止が発生するまで何もしないのではなく、独自にセキュリティー・テストを行って、SaaS サービス・プロバイダーのデータ・リカバリー能力を確認するべきです。そのためのテストは単純で、プロバイダーに E メールを送信して保管されているデータを要求し、プロバイダーがそのデータをリカバリーするまでの時間を調べるだけです。リカバリーにあまりにも時間がかかるようであれば、プロバイダーにその理由と、さまざまな状況でどれだけサービス料金が控除されるかを尋ねる必要があります。大量のデータを要求したにもかかわらず、極めて短時間でリカバリーされるとしたら、チェックサムが元のデータと一致するかどうかを確認します。また、ピーク時とそうでない時の両方でリカバリー・テストを行う必要もあります。

データ保護

行うべきセキュリティー・テストの 1 つとして、表示されているローカル・コンピューター上のデータを暗号化し、そのデータをクラウド内にあって表示できないリモート・サーバーに配置した後、復号キーを使ってそのデータにアクセスすることで、暗号化アルゴリズムのテストを行います。データにアクセスできてもデータを読み取れないのであれば、復号キーが壊れているか、またはベンダーが独自の暗号化アルゴリズムを使っているためにサーバーが復号を拒否したということになります。この場合、ベンダーにどの暗号化アルゴリズムを使用しているかを尋ねてください。

もう 1 つの問題は、クラウド内でデータに問題が発生する可能性があることです。データを保護するためには、独自の秘密鍵を管理しなければならないこともあります。ベンダーに秘密鍵の管理について確認してください。Amazon の場合は、サインアップしたユーザーに証明書を与えるようになっています。

統制活動の開示

すべての SaaS プロバイダーが、SaaS 環境でいかに自分たちの統制活動が十分であるかを進んで開示するわけではありません。プロバイダーによっては、統制活動の監査ポリシーを設けている場合もあります。

利用しているプロバイダーに、統制活動の開示および利用者に対するプロセスが SAS 70 Type II 認定を受けているかどうかを尋ねる必要があります。この認定は、包括的な変更管理文書、バックアップおよびリカバリー要件、障害リカバリー要件、およびクラウド・コンピューティングのアクセス用およびミラーリング用データ・センターを含めたデータ・センターの物理レベルでのセキュリティー要件を保証するものです。認定を受けていない場合には、せめて統制活動の管理方法に関する情報を入手するにはどうしたらよいかを尋ねる必要があります。プロバイダーの統制活動の方法に満足できるのであれば、この認定は必須ではありません。Amazon では自社のセキュリティー・プロセスをサイト上に記事として掲載しています。この記事については、以下の「参考文献」セクションを参照してください。

まとめ

この記事を参考に、クラウド・コンピューティングでの SaaS の開発および管理を計画してください。従量課金制インフラストラクチャーで安価に加入できるサービスを求める潜在的ユーザーの要求は、開発者やプロジェクト・チームのその他のメンバーにとって課題となっています。チームが円滑に作業を進めるための鍵となるのは、考えられるセキュリティーの問題を含め、SaaS を開発および管理する上での問題を認識することです。その手段としては、IBM Rational Web Developer WebSphere Software および IBM Rational ClearQuest を使用して、IBM AIM で作成中の SaaS の欠陥とアプリケーションを追跡するという方法があります (詳しくは「参考文献」を参照)。

参考文献

学ぶために

• Amazon のセキュリティー・プロセスについて読んでください。
  
  
• Judith M. Myerson による連載「エンタープライズ規模の SOA における Web サービスの取り扱い」では、エンタープライズ規模の SOA での Web サービス対処方法に関する情報を提供しています。
  
  
• Judith M. Myerson の連載記事「Web サービスのコンテキストにて SLA を使用する」を読んで、サービス・レベル・アグリーメントの詳細を理解してください。
  
  
• Ajax のツールについて詳しく知りたいという方は、「Ajax のツールと手法の調査」 (Gal Shachor、Yoav Rubin、Shmulik London、Shmuel Kallner 共著、developerWorks、2007年7月) を読んでください。
  
  
• 「SOA における密結合の Web サービス」(developerWorks、2008年) を読んでください。
  
  
• Judith M. Myerson の著書『The Complete Book of Middleware』は、システム設計の基本原則と優先順位に焦点を当て、e-commerce と分散統合システムの興隆によって生じた新しい要件について強調しています。
  
  
• 『Enterprise Systems Integration, Second Edition』を読んで、システム統合を成功させるためのビジネス的洞察力と技術ノウハウを手に入れてください。
  
  
• ビジネス・プロセス、運用と実装の問題、リスク、脆弱性、そしてセキュリティーとプライバシーについて説明している「RFID in the Supply Chain」は、組織の将来に役立つはずです。
  
  
• developerWorks SOA and web services コンテンツ・エリアでは、SOA の概要と、SOA 実現に向けた IBM の支援について案内しています。
  
  
• developerWorks の Technical events and webcasts で最新情報を入手してください。
  
  

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

• アーキテクチャー管理用の IBM Rational Web Developer for WebSphere Software、変更およびリリース管理用の IBM Rational ClearQuest、品質管理用の IBM Rational Functional Tester Plus が、Ajax やその他のアプリケーション開発にどのように役立つのかを調べてください。企業でのテスト時間と研究所コストを削減するこれらの IBM ツールが、生産性の向上を促します。
  
  
• IBM製品の試用版のダウンロード: 次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版をご利用ください。
  
  

議論するために

• developerWorks blogs: developerWorks コミュニティーに参加してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• SaaS の成熟度
• 例 1: プラント・エンジニアリング管理
• 例 2: 遠隔教育など
• SaaS サービスの分類
• パフォーマンス最適化のための調整
• 問題 1: 使われていないリソース
• 問題 2: 相互運用性の問題
• 1 にテスト、2 にも 3 にもテスト
• 考慮すべきセキュリティー上の問題
• まとめ
• 参考文献
• 著者について
• コメント