Visual Studio 2008 と Windows 7 (または Vista) で
MANDALA アプリを Windows Azure 上で動かす

アプリテック株式会社

MANDALA アプリの IIS 版 を前提にして、Windows Azure 上で MANDALA アプリを動作させる方法をご紹介いたします。

Windows Azure では、Web Role という形態の IIS を用いた Web システムにすることが主流ですので、この形態で MANDALA アプリの IIS 版 を動作させてみました。

まず、以下からファイル (10 MB ほど) をダウンロードして、解凍してください。

http://www.applitech.co.jp/download/AppliTechAzure.zip

このファイルを解凍すると、フォルダ AppliTechAzure が現れますから、これを C:\ に配置してください。つまり C:\AppliTechAzure とします。

ここで、ご確認していただきたいのですが、フォルダ C:\AppliTechAzure
の配下には、次の三つのフォルダがあり、それぞれ括弧内に示すソリューションがあります。 なお、Cloud という文字列を含む赤で表示した以下のソリューションは、クラウド側のものであり、MANDALA 流の言い方をするとセントラル側だということになります。

以下では、MANDALA アプリを Windows Azure 上で動かすまでの詳細を次の順にご説明いたします。

◆ Windows Azure のための開発環境のセットアップ

Windows Azure 用アプリケーションの作成やデバッグを行うには、VS2008 に加えて、以下の Windows Azure Tools を必要とします。ですから、この追加ソフト (12 MB ほど) を以下からダウンロードして、インストールしてください。この追加ソフトの中には、後述の Azure エミュレータなどが含まれています。

http://www.microsoft.com/downloads/details.aspx?FamilyID=6967ff37-813e-47c7-b987-889124b43abd&displaylang=en

この追加ソフトをインストールすることによって、Windows Azure のための開発環境のセットアップができます。

なお、この追加ソフトが使えるのは、以下の OS に限定されています。Windows 7; Windows Server 2008; Windows Server 2008 R2; Windows Vista Service Pack 1; Windows Vista Service Pack 2

別ページ「MANDALA アプリの IIS 版」に述べてある MANDALA アプリのデバッグ のことを思い出してみましょう。その際には、VS2008 の中に含まれている「ASP.NET 開発サーバー」という IIS エミュレータ を用いました。これに類似しているのですが、この Windows Azure 上での MANDALA アプリのデバッグの際には、「Windows Azure Simulation Environment」という Azure エミュレータ を用います。

◆ Windows Azure アプリケーション開発時の注意事項

◇ 注意事項1

Windows Azure 用アプリの作成やデバッグを行う際には、VS2008 を管理者資格で起動することが必要です。この操作方法は、以下のとおりです。

ソリューションファイルをダブルクリックする操作ではなく、VS2008 の起動のためのメニュー項目またはアイコンをまず見つけてください。通常このメニュー項目またはアイコンをクリックすることによって、VS2008 を起動する操作ができるものがあるはずです。

管理者資格で VS2008 を起動するには、そのメニュー項目またはアイコンを右クリックしてから [管理者として実行] をクリックしてください。

本書の中での決めごとですが、ソリューションの名前に Cloud が付くもの、すなわちクラウドソリューション CloudService1.sln, Jutyu2Cloud.sln は、管理者資格で VS2008 を起動してから、これらを開くようにしてください。

もしも、誤って管理者資格なしに VS2008 によって、赤で表示されたクラウドソリューションを開いて、デバッグ開始の指示をすると、Windows Azure Tools For Visual Studio から以下のメッセージが出て、デバッグを開始できません。

The Development Fabric must be run elevated. Please restart Visual Studio in elevated administrator mode in order to run the project.

◇ 注意事項2

Windows Azure 用アプリのデバッグを行う際には、IIS 7.0 を停止させてください。

IIS 7.0 を停止させる操作は、IIS マネージャに向かって以下のようにします。

IIS マネージャの左側の「接続マネージャとツリー」の先頭には、コンピュータ名が表示されています。これをクリックして右側の「操作ウィンドウ」を見ます。そこには [サーバーの管理] という区画があり、そこでサーバーの開始、停止、再起動の操作ができます。

もしも、誤って IIS 7.0 を停止せずに、Windows Azure 用アプリのデバッグを行うと、ポート番号 80 が既に IIS 7.0 に使われているために、Azure エミュレータ「Windows Azure Simulation Environment」が使うポート番号 が 81 になってしまうというような不都合が発生する恐れがあります。

◇ 注意事項3

マイクロソフト社のバグのためだと思われますが、クラウド関係のソリューションは、その構成要素が突然に壊れてしまい、VS2008 に以下のようなメッセージが出ることがあります。

ファイル "bin\Microsoft.WindowsAzure.Diagnostics.xml" がコピーできません。

このような場合は、以下のページなどを参照して、ソリューションを構成するファイルなどを修復することが必要です。

http://blog.falafel.com/2008/04/09/MicrosoftWebApplicationtargetsWasNotFoundBuildingWithCruiseControlnet.aspx

◆ Windows Azure 開発環境での Web ロール サービス開発

マイクロソフト社の以下のサイト「Windows Azure Platform 開発者向け技術情報」を参照してください。ここには、Windows Azure アプリ開発に関する有益な情報があります。

http://msdn.microsoft.com/ja-jp/azure/default.aspx

このサイトの中には、以下のページ「10 行でズバリ !! Windows Azure の Web ロール サービス開発 (VB)」があります。

http://msdn.microsoft.com/ja-jp/azure/ee839418.aspx

これに沿って ASP.NET Web ソリューションを作成することをお勧めいたします。なぜなら、まず Windows Azure アプリケーションに慣れることが重要だからです。そして、最初に取り組む課題として、このサンプルは最適なものなので、是非トライしてください。これを実施する余裕がない場合であっても、この先に進む前に、少なくとも上記ページの内容には、眼を通してください。これは必須です。

当方でも、これに沿って ASP.NET Web ソリューション CloudService1.sln を作成してみました。

なお、このクラウドソリューションは MANDALA アプリケーションではないので、すなわち ASP.NET のアプリケーションなので、ここにはローカル側のプロジェクトは現れません。ローカル側は、ブラウザだということになります。

別ページ MANDALA アプリの IIS 版 で行ったデバッグの場合と比較してみましょう。MANDALA アプリの IIS 版 のデバッグの際には、「ASP.NET 開発サーバー」という IIS エミュレータを用いました。この Windows Azure 上での MANDALA アプリのデバッグの際には、「Windows Azure Simulation Environment」という Azure エミュレータを用いることになります。

これを具体的に述べると、管理者資格で VS2008 を起動して、クラウドソリューション CloudService1.sln を開いて、デバッグ開始の指示をすると、この Azure エミュレータがタスクバー上に水色の四つ葉マーク (下記に赤丸で示す) として現れます。

タスクバーの画像

この Azure エミュレータは、Azure Storage などの時間のかかる各種の初期設定を行うために、立ち上がるまでに数分かかることにご注意ください。

Azure エミュレータが立ち上がると、クラウドアプリのデバッグをしやすいようにとの配慮から、このクラウドサービスを呼び出すブラウザ (いわばローカル側) が現れます。すなわち、ブラウザが自動起動されます。したがって、デバッグを開始するための手間、すなわちブラウザを開いて、そのアドレスバーに
http://localhost/ または
http://127.0.0.1/
とキーインする操作を省くことができます。なお、これは ASP.NET 流のデバッグ作業を少し楽にするためのものです。クラウド側では、IP アドレス 127.0.0.1 で、ブラウザからのメッセージを待ち受けていますから、ブラウザからそこに向けて通信を始めるためです。

ちなみに、ブラウザが立ち上がったということは、Azure エミュレータが動作可能になり、メッセージを待ち受けるようになったという合図だと見ることもできます。

この Azure エミュレータを終了させるには、下図のように水色の四つ葉マークを右クリックしてから [Exit] をクリックしてください。こうすると、クラウドソリューション CloudService1.sln が終了します。

Azure エミュレータメニュー画像



この Azure エミュレータだけでなく、IIS エミュレータ「ASP.NET 開発サーバー」にも、ASP.NET のデバッグをしやすくするために、ブラウザを自動起動する機能があります。しかし、別ページの MANDALA アプリの IIS 版 を動作させる説明では、この機能は不要なので、これを殺していました。

すなわち、この機能を殺すために CentralWeb のプロパティページの開始オプションの開始動作として「ページを開かずにアプリケーションからの要求を待つ」を選択しました。なお、開始動作の指定には、いろいろありますが「現在のページを使用する」を選択するとブラウザが自動起動されることになります。

ちなみに、Azure エミュレータで MANDALA アプリをデバッグする際には、Azure エミュレータが動作可能になった時期を知るために、このブラウザの自動起動を活用するのがよいでしょう。ですから、この機能を殺すには及びません。

このブラウザの自動起動は、あくまでもデバッグ用の IIS のエミュレータや Azure エミュレータの機能であって、本物の IIS や Windows Azure にはないものです。


◆ Windows Azure 開発環境での MANDALA アプリ の動作確認

ここでは、フォルダ Jutyu2Cloud の中のクラウドソリューション Jutyu2Cloud.sln および Jutyu2Lcl.sln を用います。

以下の二つをマージしたのがクラウドソリューション Jutyu2Cloud.sln です。

◇ Windows Azure 開発環境での動作確認

最初に、クラウドソリューション Jutyu2Cloud.sln が Azure エミュレータ上で動作することを確認してみます。すなわち、Windows Azure 開発環境で MANDALA アプリの IIS 版 の動作確認をすることにします。

管理者資格で VS2008 を起動して、クラウドソリューション Jutyu2Cloud.sln を開きます。そして、デバッグ開始の指示をします。

数分経過すると、ブラウザが自動起動されるので、Azure エミュレータの準備が整ったことが分かります。つまり、クラウド側は、IP アドレス 127.0.0.1 で、ブラウザからのメッセージおよび MANDALA のローカル側からのメッセージを待ち受けることになります。なお、ブラウザのアドレス欄に http://127.0.0.1:81/ と表示された場合には、IIS を停止したかチェックしてください。ポート番号が 80 ではなく 81 になっているからです。

ポート番号を確かめてから、ローカル用としてもう一つ VS2008 を起動して、ローカル側の Jutyu2Lcl.sln を開いて、デバッグ開始の指示をします。

こうすると、Jutyu2 が Azure エミュレータ上で動作することを確認できます。すなわち、MANDALA のローカル・セントラル間の通信が始まります。

◇ クラウドソリューション Jutyu2Cloud.sln の構成

前述のクラウドソリューション CloudService1.sln の中には、以下のクラウドサービスという形態のプロジェクトと ASP.NET Web ロールが含まれています。

MANDALA アプリの IIS 版 の動作に用いたソリューション Jutyu2IIS.sln の中には、以下の一つの ASP.NET Web サイトと二つのプロジェクトが含まれています。

Jutyu2Cloud.sln は、CloudService1.slnと Jutyu2IIS.sln をマージしたものであり、ASP.NET の Web サイト CentralWebWebRole1 に統合して、以下の四つのプロジェクトから構成されるようにしたものです。

CentralWebWebRole1 には、それぞれ web.config というファイルが作られています。これも統合してあります。

WebRole1 の web.config の修正箇所は、MANDALA アプリの IIS 版 の中の CentralWeb の場合と全く同様に 3 箇所あります。それらは「MANDALA.net アプリケーション の動作設定」に関するものが 1 箇所と、「httpHandler の登録」に関するものが 2 箇所です。後者は IIS が受け取った http 通信のメッセージのうち AppRequest.appmsg などを MANDALA が受け取ることができるようにするための修正です。

この他に、WebRole1 の web.config の修正として のトレースに関する指定を削除して (実際にはコメントにして) あります。この指定があると、例外が発生してしまうので、とりあえずの処置として、このようにしました。

それから、VS2008 によって WebRole1 のプロパティを見ていただくと分かりますが、参照設定として、プロジェクト Jutyu2Cnt および JutyuSerializables を含めました。

ここでご注意ですが、WebRole1 のプロパティの Web (CentralWeb のプロパティページの開始オプションに相当するもの) は、指定をしても効果がないようです。

◇ ローカル側のソリューション Jutyu2Lcl.sln

ローカル側のソリューション Jutyu2Lcl.sln は、MANDALA アプリの IIS 版 の動作に用いたソリューション Jutyu2IIS.sln をコピーして、ソリューション名を変更したものです。

MANDALA アプリの IIS 版 では、app.config の設定を変更しました。すなわち、Jutyu2IISLcl.sln のプロジェクト Jutyu2Lcl のフォルダ Customize の中のモジュール app.config の中の CentralServerURL の設定に関する文字列を以下のようにしました。

ここでは、Jutyu2Lcl.sln のプロジェクト Jutyu2Lcl のフォルダ Customize の中のモジュール app.config の中の CentralServerURL の設定を以下のようにしてあります。フォルダ部分を削除し、ポート番号は、標準の 80 なので省略しました。

"http://localhost/AppRequest.appmsg"

なお、不思議なことに、以下のようにホスト名の後のフォルダ部分に CentralWeb を指定しても (実際には何を指定しても) MANDALA のローカル・セントラル間の通信が行われ、問題なく動作します。

"http://localhost/CentralWeb/AppRequest.appmsg"

このことから、Azure エミュレータは、パス指定の中のフォルダ部分を無視して、ローカルからのメッセージを受け取るようです。

ちなみに、http による URL の一般形は、以下のとおりです。

http://<ホスト名または IP アドレス>:<ポート番号>/<パス>

なお、ポート番号が 80 の場合は、この指定を省略して、以下でもかまいません。

http://< ホスト名または IP アドレス>/<パス>

◆本物の Windows Azure 上での MANDALA アプリ の動確認

ここでは、フォルダ Jutyu2Cloud ではなく、フォルダ Jutyu2CloudUp の中のソリューション Jutyu2Cloud.sln および Jutyu2Lcl.sln を用います。

◇ なぜ Jutyu2Cloud でなく Jutyu2CloudUp なのか

 本来であれば、Azure エミュレータで動作確認したクラウドソリューションを実際の Windows Azure にアップロードすべきです。しかし、これまでご覧いただいたサンプルアプリ Jutyu2 は少し特殊なデータベース?を用いています。すなわち、特定のデータベースを用意しなくてもこのサンプルアプリを動作させることができるようにと、テキストファイルをデータベースに見立てて、その“データベースもどき”を用いています。この特殊なデータベース?は、Windows Azure ではサポートされていません。

そこで、この“データベースもどき”の部分を書き換えることが必要です。何に書き換えるかという選択肢は、次の5つがあります。

一番簡単に書き換えることができそうなのは、「ドライブ」です。しかし、これは Windows Azure で最近サポートされることになったものであり、Azure エミュレータでは、まだサポートされていません。

とすると「テーブル」または「SQL Azure」に書き換えることが必要になります。これは手間がかかりそうです。

などと考えた結果、この部分に MANDALA 固有の問題があるわけではないので、とりあえず省略してもかまわないと判断して、Jutyu2 をデータベースなしで「何とか動作するもの」に書き換えることにしました。この結果、サンプルアプリ Jutyu2 の動作は不完全なものになってしまいましたが、これでも Windows Azure 上で MANDALA アプリが動作するかどうかの確認はできるので、まずはこれを実施してみます。

このような考えで、Jutyu2Cloud を書き換えたのが Jutyu2CloudUp です。

◇ 実際の Windows Azure にアップロードする

マイクロソフト社の以下のサイト「Windows Azure Community」を参照してください。ここには、Windows Azure 関係の有益な情報が日本語で書いてあります。

http://windows-azure.jp/community/Top.aspx

このサイトの中には、以下のページ「How to Setup」があります。

http://windows-azure.jp/community/HowtoSetup.aspx

ここには、アカウント登録 (クラウド利用の料金を払うための口座の開設) の方法からはじまり、クラウドプロジェクトを本物の Windows Azure 環境にアップロードする方法など、以下が書いてあります。

とにかく Windows Azure を利用するには、事前にアカウントの登録が必要ですから、まず「アカウント登録」を済ませてください。そして、ご自分の Windows Azure 環境の中に少なくとも一つの「プロジェクト作成」(プログラム格納用のもの) を行ってください。

例えば、当方で用いた認定パートナー向けの MSDN の割引アカウント場合、Storage 用に 5 個、プログラム格納用 (Hosted Service 用) に 20 個までのプロジェクトが作れます。

次の「開発環境の構築」は、既にフォルダ Jutyu2CloudUp の中のクラウドソリューション Jutyu2Cloud.sln として、出来上がっています。ですから、このソリューションを「ステージング環境へ配置」すれば、すなわちアップロードすればよいことになります。なお、このアップロードは、いろいろな言葉で表現されることがありますが、ほぼ同じ意味だと捉えてください。例えば、ポータルへの配置、発行、Publish、Deploy などという言葉が使われることがあります。

このアップロードの際に、以下の二つのファイルのパスを指定することが求められます。ただし、これらのファイルはエクスプローラ上に自動的に表示されるので、エクスプローラを見ながらこれらのパスを指定すればよいだけです。わざわざ分かっている指定をするというような手間を強いる理由は、多分、これらの内容を更新するという高度な使い方ができるようになっているのでしょう。

CloudService1.cspkg

ServiceConfiguration.cscfg

アップロードされたプログラムは、まず Staging 環境 (事前テスト環境) に格納されます。そこで、テストを行った後に、Production 環境 (本番環境) に移送するのが、通常の手順です。

◇ Windows Azure を使って Jutyu2 を動作させる

Staging 環境 (事前テスト環境) にプログラム資材を格納すると、そこにアクセスするための Web Site URL が現れます。しかし、Ready 状態になるまでは、動作テストを行うことはできません。Run ボタンをクリックして、Ready 状態になるまで待ってください。

この待ちの時間を利用して、ローカル側のソリューション Jutyu2Lcl.sln の app.config の設定変更を済ませてください。すなわち、Jutyu2IISLcl.sln のプロジェクト Jutyu2Lcl のフォルダ Customize の中のモジュール app.config の中の CentralServerURL の設定に関する文字列 (サーバーの URL) を例えば以下のように変更することが必要です。

"http://c16ece6dbac1ff8a89ea2b67637367a.cloudapp.net/AppRequest.appmsg"

すなわち、たとえば Web Site URL として、以下のものが知らされた場合には、この URL の後に文字列 AppRequest.appmsg を付けたものを CentralServerURL として設定します。

http://c16ece6dbac1ff8a89ea2b67637367a.cloudapp.net/

WebRole1 の状態が、Initializing や Busy や Stopped や Stopping ではなく、緑色の Ready になってから、フォルダ Jutyu2CloudUp の中のローカル側のソリューション Jutyu2Lcl.sln にデバッグ開始の指示を与えてテストを開始してください。なお、初めて Staging 環境へアップロードした直後は、DNS (Domain Name System) への登録が済んでいないためか、しばらくはアクセスできない空白の時間が続きます。

通信路が開通した後にローカル側のソリューションを起動すると、Windows Azure 上に配置されたセントラル側を呼び出して、Jutyu2 が動作することになります。

当方のテストでは、レスポンスはまあまあでした。もっとも、この Jutyu2 の結果にはデータベースへのアクセス時間が含まれていませんので、これを差し引いて評価することが必要です。一般にレスポンスは、どこのセンターを使うのか、その時間帯はいつか、などによって混み具合が異なりますから、レスポンス時間にはばらつきがあると思われます。当方では、シカゴのセンターを使ってみました。日本と米国では、昼夜が逆転しており、混み具合も逆転していることが期待でき、また日本と米国には太い基幹の光ファイバーの海底ケーブルがあるので、東アジアのセンターよりもレスポンスがよいとも言われています。

Windows Azure のセンター

センターを選択する際、Any (おまかせ) のような指定もできますが、そうすると Storage 用のセンターと、プログラム格納用 (Hosted Service 用) のセンターが異なるものになってしまうこともあり、その場合には「異なるセンター間のデータ転送」という余計な料金がかかることがあります。ですから、センターは、明に指定する方がよいとのことです。

なお、テストが終わったら Stopped 状態にしておきましょう。そうしないと料金がかかります。

◇ Jutyu2 を動作させて気がついたこと

実際の Windows Azure を用いて Jutyu2 のテストを行っていたときに、次のような例外が発生してしまいました。

The string was not recognized as a valid DateTime. There is an unknown word starting at index 0.

Jyutyu2 は和暦を用いているのですが、これが正しく処理されません。多分、Windows Azure のセンターでは、英語版の .NET Framework を用いているので、例外になってしまうのだと思われます。

ちなみに、SQL Azure を用いる場合にも、英語版の SQL Server を用いるのと同じ注意が必要とのことです。日本語文字の扱い、および時刻が世界標準時で表現されるなどに注意して、アプリケーションを修正しなければなりません。

Remoting から IIS に移行する際には、このようなアプリケーションの変更は不要ですが、Windows Azure 上で動作させるためには、少なくともこうした修正が必要になります。Windows Azure は米国仕様のものであり、日本語仕様などの localization はできていないと認識すべきです。

◆ クラウドを活用したビジネス

世の中には、いろいろな種類のクラウドがあります。ニフティクラウドや Amazon の EC2 などに代表されるような、HaaS (Hardware as a Service) または IaaS(Infrastructure as a Service; イアース) という種類のクラウドコンピューティングサービスならば、MANDALA アプリをクラウド上で簡単に動作させることができるでしょう。Windows Azure の場合は、PaaS(Platform as a Service) だと言われており、MANDALA アプリを動作させるためには、それなりの修正 (少量) が必要です。そして、salesforce.com のクラウド上で動作させるためには、全面改築になります。

クラウドのホスティングビジネスを自社で行う場合には、その会社に都合のよいクラウドを構築できるかもしれません。しかし、あまりにも特殊なクラウドにすると、ホスティングサービスの顧客を確保できなくなりそうです。

Windows Azure は、ほんの少しだけ特殊なものであり、その上で MANDALA アプリなどを動作させるためには、アプリ側に少量の修正が必要です。しかし、マイクロソフト社は、VM Role やドライブなどの機能をサポートすることによって、この敷居を低くする方向に動いているように思われます。

一般に、クラウド上でアプリケーションを動作させることは、技術的に大きな問題があるわけではありません。ただし、特定のクラウドに囲い込まれることはできれば避けたいので、どのクラウド上でも動作できるようにしたいものです。こうするためには、それなりの技術的な課題があるかもしれません。しかし、それだけのことです。

クラウドを技術的な問題だと捉えるよりも、むしろどのようにクラウドを活用して、ビジネスに結び付けるのかということが重要になります。

世の中では、salesforce.com のクラウドが SaaS (Software as a Service) として独り勝ちの様相を呈しているので、柳の下の二匹目のドジョウを目指す動きもあるようです。これについては、すなわちこうしたビジネスがうまくいくかどうかの判断は、とても私どもにはできそうにないので、このあたりについては言及しないことにします。

クラウドを活用したビジネスを考える上で、クラウドのホスティングビジネスまで手を広げる場合とそうでない場合で異なりますが、ここではホスティングビジネスは行わずに、他社のクラウドを活用する場合についてのみ考えてみます。

クラウドをクールに見ると、自前でコンピュータ設備を用意するのではなく、(クラウドとして) レンタルすることだと見ることができます。あるいは、Private クラウドという言葉が存在することから言えることですが、仮想化技術によってサーバコンピュータ設備を効率よく使うことのようにも思われます。ただし、これでは仮想化とクラウドの違いが不鮮明になってしまいます。

いずれにしても、クラウドをこのように捉えると、クラウドのレンタル料金体系が気になります。かなり長期にわたって定常的にレンタルする形態しかない料金体系だとすると、これまでのレンタルサーバーとの違いは、料金が少し安くなるだけだと言えそうです。しかし、繁忙期だけレンタルするというようなスポット的な利用を可能にするレンタル料金がクラウドに設定されている場合には、これまで実現できなかったような費用対効果を上げることができそうです。コンピュータ利用の負荷が大幅に変化する場合、または負荷の予測が困難な場合には、クラウドは最適なものになることでしょう。

先ほど、コンピュータ設備を用意するのは誰かについて考えてみましたが、同時にコンピュータ設備などの運用管理をするのは誰かということも問題になります。クラウドでは、ホスティングサービスを行う会社がその大部分を行うことになりますから、クラウドを利用する会社にとっては、運用管理というサービスをアウトソーシングしているのと等価だということになります。この意味で、クラウドは「運用管理サービスを販売している」と捉えることができます。

たとえば、中小企業などでは専任のシステム運用管理者を設けることが難しい場合もあることでしょう。こうした場合に、クラウドを用いることは、コンピュータの運用管理をアウトソーシングするのと同じ効果を上げることになります。しかも低いコストで同じ効果を上げることができそうです。

運用管理の延長線上に、これ以外のいろいろなサービスもクラウドにアウトソーシングできるのではないかという考え方があります。アプリケーションの開発もメンテナンスもソフトウェアのライセンスも ... というように、これら全体をサポートしてくれるのがクラウドだという考え方です。この考え方に従うと、クラウドとはサービスだということになります。

こうしたサービスを提供する側のことを「クラウドサービスプロバイダ」と呼んだらよいのでしょうか? 既に「クラウドサービスプロバイダ」という言葉は存在しますが、どの範囲のサービスを提供するかに関しては、まだ合意が形成されていないようです。

これに似た言葉に ASP (アプリケーションサービスプロバイダ) があり、こちらの言葉の意味は、より明確になっています。私どもでは、アプリケーションサービスプロバイダの延長線上にクラウドサービスプロバイダがあると捉えています。そして、アプリケーションサービスプロバイダを追求することなしに、クラウドサービスプロバイダを論じても、議論が空転するだけのように思っています。

しかし、クラウドサービスプロバイダという言葉は意味があいまいで、夢を与えてくれる力があるようです。このためでしょうか、ASP を抜かして、クラウドサービスプロバイダの話題が取り上げられるのは、困ったことです。

また、サービスの話に戻りますが、クラウドの対象とするサービスは、顧客企業の大勢の社員を相手にして小額のサービスを多量に売る場合が多いように思われます。このためにこうした際のコストを下げるマルチテナント機能が求められたりすることになります。

ここで、ERP パケージなどをサービスとして提供する形態を考えてみると、その利用者の数は限られていることが多く、大量販売ではないことが多いのではないでしょうか。日経コンピュータ (2010 年 2 月 17 日号) のクラウド特集では、ERP においては、その導入コストが一番の問題として取り上げられています。

したがって、この ERP の導入コストの問題に取り組んで、クラウド時代の ERP サービスとして販売する道があるのではないでしょうか。カスタマイズを容易にする部品化合成法などをベースにして、ERP の導入のコストを下げる方法を開発するのがよさそうです。



    


Copyright © 2009-2010 By AppliTech, Inc. All Rights Reserved.
AppliTech および MANDALA および workFrame=Browser は、アプリテック株式会社の登録商標です。 ここに掲載の社名、製品名には、各社の商標または登録商標があります。