クラウドの仕組みと API としての Web サービス

このブログでは、オートデスクのデスクトップ製品の他に、多くのクラウドサービスをご紹介してきました。それらクラウドサービスの他にも、現在では、Autodesk 360 の配下には、非常に沢山のクラウドサービスが用意されています。

個々のサービスは SaaS（Software As A Service）と呼ばれたり、単に Web サービス と呼ばれることがあります。従来のデスクトップ製品が、「アプリケーション」や「ソフトウェア」と呼ばれるのとは少し区別されていることがわかります。今回は、複数のサービスを持つ Autodesk 360 が、具体的にどのように構築されているのか、その概要を最初に説明したいと思います。その後で、これから登場するであろう API について、簡単に提供する仕組みを簡単にご紹介したいと思います。

クラウドインフラで利用されている仮想化

デスクトップ製品を運用する際には、自前でコンピュータを購入して、そのコンピュータに製品をインストールすることになります。Web サービスは、デスクトップ製品のようにプログラムで作成されている点は同じですが、使用するコンピュータにインストールするのではなく、サーバーコンピュータ上でホスティングして、クライアントから要求に応じてサーバー上でプログラムを実行させるようになります。

Autodesk 360 のように膨大な数のユーザ（クライアント）からのリクエストを処理していくためには、膨大な数のサーバーコンピュータが必要になります。それらを自前で購入してセットアップやメインテナンスしていくのは、とても大変でコストがかかるは自明です。そこで、オートデスクは、独自にサーバーコンピュータを多数用意して Web サービス運用をしているのはなく、Amazon Web Services、通称、AWS をプラットフォームにすることを選択しました。AWS は、PaaS（Platform As A Service）とも言われていて、Autodesk 360 のようなクラウドサービスのインフラを提供しています。

PaaS である AWS は、オートデスクのようなソフトウェアベンダーに代わって、ハードウェアを含むプラットフォームを提供しています。その中にはストレージ機能のみを提供する Amazon S3 サービスや、演算処理機能を提供する Amazon EC2 サービスなどのサービスが存在します。オートデスクは、S3 を使って Autodesk 360 のストレージサービスを、EC2 で Autodesk 360 Rendering や Autodesk ReCap 360 などの演算処理サービスを提供しています。もっとも、オートデスクは認証システムも含めて、「Autodesk 360」として作り込んだ形で提供しているので、利用するユーザは、決して AWS の存在を意識することはありません。

さて、AWS クラウドプラットフォームでは、1 台づつのコンピュータに通常の OS をインストールして、ユーザに割り当てているのではありません。当然、そのような行為はコストの増加に繋がってしますからです。実際には、物理的なサーバーコンピュータ上にハイパーバイザーを使って、複数の OS を仮想化しています。EC2 では、Windows Server や Linux といった代表的なサーバーOSを、オートデスクのようソフトウェアベンダーの要望に合わせて仮想化して提供しています。

この仕組みは、以前、ご紹介した「仮想化環境に対応したライセンスについて」でもご紹介しています。つまり、シンクライアントやプライベートクラウドといった環境で、デスクトップ製品を配信する仕組みを、もっと大規模にしたものと捉えることも出来ると思います。

クラウド上で既存のデスクトップ製品を運用することも可能ですが、オートデスクはそういった手法は選択せずに、専用の Web サービスを提供すること選択しています。なぜなら、クラウドを使う利点が次のように明確であるためです。

従来のデスクトップ製品では実現できない、あるいは、デスクトップ製品を使うことでが足かせになってしまうことも同時に抑止する必要があるのです。もちろん、デスクトップ製品は存在し続けることも認識していて、開発の継続も表明しています。

Autodesk 360 も登場から 3 年を経て、各種 Web サービスの種類と機能が充実してきています。そこで、Autodesk 360 をプラットフォームとして開発プラットフォームとして提供することが視野に入ってきているのです。当然、API を利用してカスタマイズすることが想定されることになりますが、デスクトップ製品の API とは少し異なる形態で提供されるはずです。

API としての Web サービス

それが API としての Web サービスです。少し紛らわしいのですが、Autodesk 360 のように、クラウドを使ったソフトウェア機能（アプリケーションサービス）も Web サービスと呼びますが、API として Web サービスと呼ぶこともあります。Web サービスは、クラウドに「ホスティング」してクラウド上で実行する処理を実装します（クライアント側で動作させる仕組みを持つものもあります）。

次に、API としての Web サービスの簡単な例を考えてみましょう。この例では、様々な種類のクライアントから製品を示す番号を送って、対応する製品の価格を取得する機能を仮定します。この Web サービスの根幹は、「クライアントから要求された番号を価格に変換してクライアントに返す」、といった簡単な処理です。

クラウドを利用する利点に沿うなら、おそらく次の動画のようなイメージになるはずです。画面が小さいので、可能でれば最大化してご覧ください。ここでは、Web ブラウザでも、AutoCAD 内のアドオンアプリケーションでも、モバイルデバイスでも、この Web サービスにアクセスしていることが分かります。

様々なタイプのクライアントから Web サービスにアクセスするには、クライアント側のタイプやプラットフォーム、開発環境に関係なくアクセス出来る API が用意されている必要があります。個別に API やソフトウェアライブラリ、SDK などを用意するのは大変です。

「クライアントから要求された番号を価格に変換してクライアントに返す」 Web サービスでは、もちろん、クライアントのタイプを考慮しないようになっています。クライアント側で、どのようなユーザインタフェースを実装するかは、Web サービスを利用する開発者の好みで自由に変化できるよう、逆にクライアントタイプに特化した機能を Web サービス API で提供しないようにしています。また、インターネットが普及した現在、クライアントから要求を送信したり、クラウドからクライアントに結果を戻すのは、標準化されたテクノロジを補うことが出来ます。

デスクトップ製品の API は、クライアントのタイプや製品自体の機能に依存するのが一般的なので、Windows や Mac の違いがあると移植が大変困難です。日本では発売されていませんが、例えば、AutoCAD for Mac のアドオンアプリケーションは、Windows 版の AutoCAD では動作しません。その逆も然りです。

マッシュアップ

API としての Web サービスが、とてもシンプルなものであることが何となくご理解いただけたかと思います。簡単すぎて、何が出来るのか心配になるくらいです。そこで、マッシュアップ という言葉をご紹介しておきましょう。詳細は、先に埋め込んだハイパーリンク先にあるウィキペディアの説明に譲りますが、全く異なるアプリケーションサービスがシンプルな Web サービス（API）を組み合わせることで、全く別のアプリケーションサービスを構築することが出来るのです。もちろん、Web サービスによって得られた結果を、クライアントタイプによって、どう表現するかは開発者の手腕にかかっています。

以前に紹介した GrabCAD 内のオートデスクサービスの利用や、Fusion 360 内で利用されているビューイング機能やレンダリング機能は、マッシュアップの一例です。

By Toshiaki Isezaki