クラウドポータルというものについて(2)
さて、先日述べました、クラウドポータルの話について、もう少し具体的な説明したいと思います。
ユーザに対するクラウドサービスを、人を介せず提供するシステムであるクラウドポータルとして、クラウドサービスに付随して提供する必要がある機能がいくつかあります。
（１）ID管理
クラウドポータルのユーザを管理する機能です。クラウドサービス自体は、複数のアプリケーションの集まりなので、構造上そのインフラ上には、IaaS環境のユーザディレクトリの他に、クラウド上の各SaaSのユーザディレクトリ、下記の機能がそれぞれ管理するユーザディレクトリ、等複数のユーザ管理DBが存在するシステムになります。これらのユーザディレクトリをLDAP統合し、統一したユーザプロビジョニング／デプロビジョニングが出来る機能がどうしても必要になります。ユーザの個人情報を扱う機能でもあるため、クラウドサービスのセキュリティにも直接的に関係してくる機能である上、J-SOX準拠の条件にもなってくる重要な機能である、と言える。クラウドアプリ上のLDAPの統合が出来、尚かつ場合によってはクラウド上でその統合ディレクトリを管理できるID管理システムが必要になってくるわけです。
クラウドサービスを開始すると、無償ユーザも含めて、管理対象となりIDの数が極端に多くなる可能性があり、そういう意味でも効率よく管理する必要性も出てくる。
（２）課金管理
e-Commerceサイトと同様に、クラウドサービスもユーザから収益を上げる事がビジネスモデルですので、IaaSサービスにとっても、ユーザのクラウドサービスの利用度に則して課金をするシステムが必要になってきます。クラウドサービスの大きな特長は、課金の対象となるのは、様々な”単位”に基づいて課金を行わなければいけない、という事である。確たる定義が業界である、という訳ではないが、次の様な単位での課金が要求されます。
ストレージデータ量（MB単位）
使用時間（分／時間単位）
ユーザ数（ユーザ単位／グループ単位）
CPU単位（実CPU数／サイズ）
VM単位（実VM数／サイズ）
メモリ単位（GB単位）
IPアドレス単位
また、課金方式もAWSが展開している方式を事例に多様化している。次の様なモデルがあります。
オンデマンド（必要時に利用する時の課金方式）
予約方式（事前に一定期間利用する事をコミットする際に予約できる方式：少し安くなる）
データセンタ指定価格（特定のデータセンタを指定して利用する方式：少し高くなる）
オフピーク価格（余剰のクラウドリソースを安く売る方式：安くなる）
無償トライアル（初期使用を無償で提供する、俗にFreemiumと呼ばれる方式）
バンドル価格（上記の複数の価格体系を纏めてわかりやすくパッケージ）
プロモーション（特定のプロモコードを設定して無償で提供）
こういった機能の提供に加えて、PCI-DSS準拠等の要件に応えるためのセキュリティ要件、しかるべきペイメントゲートウェイとの連携、等かなり広い範囲の機能サポートが必要になってきます。
ビジネスとしてのクラウド事業の収益を決める重要な機能であるため、十分時間とリソースをかけて設計していく必要のあるコンポーネントです。
（３）コミュニティ運営
クラウドコンピューティングが他のIT事業と大きく異なるポイントは、ユーザ主導のビジネスである、という事です。つまり、ユーザにとって魅力的なサービスでないと、クラウドコンピューティングのモデルの性格上、直ぐにユーザが離れていってしまう、という意味を持ちます。クラウドサービス自体の魅力でユーザを引き止める、と言うのは段々とクラウドサービスが汎用化されていく中で困難になってきている上、価格で勝負するのも、よっぽど運用コストを他社と比較して低く抑える要素が無いと、リスクが大きい、と言えます。
そこで、主たるクラウドサービスが採用しているのは、ユーザ参加型のコミュニティを構築し、様々な有用な情報が集まるサイトを運営する、という方式です。企業向けのソーシャルネットワーキングサイト等も多く登場している状況の中で、クラウドサービスのSNSを提供したり、オープンソフトウェア事業者がよく運営する、フォーラムやユーザ主体のFAQの運営等、いくつかのアプリケーションを組み合わせて、ユーザが情報を提供しながら、ベンダーが適切なアドバイス、技術質問に対する回答等を提供する様な環境です。このようなコミュニティの運営を通して、特に貢献しているユーザに対して、割引等のクーポンを提供する等、インセンティブを提供するサイトも増えてきている。
（４）CRM等の顧客管理システムとの連携
クラウドサービスを提供する事業社は、既に他のITサービスを提供しているケースも多く、既存のシステム上で顧客管理システムが運用されているケースが多い。この既存のCRMやERPシステムに新たに構築したクラウドサービスを連携させる事によって、クラウドサービス事業の利用状況、収益状況等のレポーティングが出来る様になります。また、既存のITサービスのユーザを新たに追加したクラウドサービスに移行させる際にも、ユーザ情報等を出来るだけ簡単にクラウドシステム上のID管理システムに移す際にも、既存の顧客管理システムとの連携が継続的に必要になってきます。
ここも、課金方式の違い、ユーザ管理方式の違い（トライアルユーザが極端に多い状況、等）、契約形態の違い、等、従来のITサービス事業とクラウドサービス事業との違いを意識した連携を図る必要があり、意外と工数が大きくなる可能性がある、と言えます。
いずれも、通常のE-Commerceシステムには当然実装される機能ではあるが、クラウドサービスであるが故の特徴があり、それが実装上の違いとなって出てくる、という事が理解されると思います。
昨今では、クラウドプラットホームをサポートする製品、という位置づけで、クラウドサービス向けのID管理、課金管理、コミュニティインフラ、レポーティングインフラ、セキュリティインフラ、等のソリューションが多く登場しており、多くはSaaSとして提供されます。SaaSであるが故に、統合も比較的簡単で、以前にも紹介した、クラウドIntegration APIの存在が大きく寄与してきます。
VMWareをベースとした、ほとんどのインスタンス管理作業が人を介した手作業で行われる今日のクラウドインフラと、世界で広く普及しつつあり、上記の機能を有する自動化クラウドサービスインフラとでは、かなり大きな差が生まれてきている、という状況を理解して頂けたと思います。
問題は、これらの機能を実装するとなると、複数のコンポーネントを統合する必要が出てくる、という事です。基本的にSaaSの組み合わせなので然程技術的には難しい事ではないんですが、他で実績をあげている事例をを参考にする事が重要な要件になるでしょうし、とにもかくにも、様々なコンポーネントを連携できるクラウドAPI基盤を実装する事が何にも増して重要な選択になる、という事です。
小生が最近強く提唱しているのは、クラウドAPIの独自開発はもう既に遅い、という点です。
むしろ既に市場で実績をあげている3rd PartyクラウドAPI製品を出来るだけ早く導入し、その上での各種サービスのレイヤーにおいて差別化を図るべく、開発リソースを投入すべき時代に入っている、という事を主張してます。
日本市場は、2011年はクラウド技術からクラウドビジネスの時代に本格突入する、と予測してます。
クラウド基盤の是非を問う事は愚か、クラウド基盤を導入する事だけをゴールとする、という技術主体の事業戦略は既に大きく先に進んでいるクラウド市場に対して、更なる遅れをとる大きなリスクとなります。今でこそ、一歩先を行ったクラウド”事業”戦略を打ち出すタイミングに来ている、と述べたいところです。