APS（旧 Forge）開発に際して…

言うまでもなく、Autodesk Platform Services（旧 Autodesk Forge）はオートデスクのクラウド開発プラットフォームです。Web 開発のテクノロジ基盤を利用する Web API（Web サービス API）の特徴から、他社やオープンソースの Web API と融合し易い特徴を持っています。

APS の利用者（開発者）は、APS と他の Web API を利用して、いままでにない新しいソリューションを構築することが出来るようになります。ちょうど、さまざまなカタチや色を持つブロックを組み合わせて、新しい「何か」を組み立てるような感覚です。

2016 年の正式導入から 5 年以上経過した Forge（現 APS）は、ここ日本でも数多く利用されています。Forge を知る効果的なデモ サイト でも触れていますが、現在、大きく 3 つの利用形態が主流になっています。

APS Viewer を使ってデザイン データに含まれる情報を視覚化、洞察力を得る Visual Insight（別名 Viewer ソリューション）、BIM 360/Autodesk Construction Cloud や Fusion Team など、ストレージ サービスに保存・利用されているデータを独自に活用する BIM 360 統合（別名ストレージ統合ソリューション）、クラウド上の CAD エンジンにデスクトップ製品アドインをロード、実行させて、デザインデータの作成や編集、データ抽出を自動化する Design Automation（別名 自動化ソリューション） です。

このような中、いままでのオートデスクの歴史から、Revit や AutoCAD、Inventor などのデスクトップ製品アドイン（別名、アドオン、プラグイン）開発に携わる方が APS に取り組むケースが増えています。

そこで、今回は、デスクトップ開発者の方が APS 開発に着手する際に、把握いただきたい点をまとめてみたいと思います。

Web アプリ

APS の 3 つの利用形態でほぼ共通しているのは、フロント エンドとして Web ページを持つ点です。APS Viewer を使った 2D 図面や 3D モデルの表示も Web ページへの埋め込みです。

Web ページを配信するには、Web サーバーを作成する必要があります。Web ページの表示では、クライアント デバイスの Web ブラウザから URL をリクエスト（要求）して、Web サーバーが URL に対応するコンテンツ（HTML で定義されたページ）をクライアント デバイスにレスポンス（応答）することで、ブラウザにコンテンツが表示されます。

Web ブラウザに内蔵されるデベロッパーツールを使用すると、リクエストやレスポンスの情報をトレース出来るだけではなく、レスポンスとして返された HTML（ページ）の内容や、HTML に付帯する JavaScript コード（ソースコード）を参照することが出来ます。

このため、Web ページ コンテンツ（HTML、特に JavaScript コード）には、ユーザ認証で利用する保護すべきクレデンシャルな情報はハード コードすべきではありません。

Web ブラウザからのリクエストには、Web ページを要求する URL のほか、Web サーバーとのコミュニケーションで使用する エンドポイント 呼び出しも含まれます。

エンドポイントとは、デスクトップ開発で使用する関数やメソッドに相当するもので、APS が提供するエンドポイント以外に、Web サーバー側で独自に作成することも出来ます。エンドポイントは URL と同じような表記を持つ URI で呼び出します。

独自にエンドポイントを作成してクライアントからのリクエストに応じた Web サーバー上の一連の処理とを結び付けることをルーティング、ないしは Web ルーティングと呼ぶことがあります。デスクトップ開発でも独自に関数やメソッドを作成、サブルーチンとして利用しますが、それと似た感覚です。エンドポイントは、クライアント実装からだけでなく、Web サーバー実装からも呼び出すことが出来ます。

クライアントの Web ブラウザでクレデンシャル情報が過度に露見してしまうことを避けるため、独自のエンドポイントを用意して、クレデンシャルが必要な処理を Web サーバーで実行するのが一般的です。（もちろん、例外もあります。）

Web サーバー実装は、Web ページ コンテンツ配信以外の役割を持たせることが可能でもあり、Web アプリケーション（Web アプリ）とも表現されます。

通信経路

APS に限らず、クラウアント デバイスからのリクエストや Web サーバーからのレスポンス、総じてクラウドとのコミュニケーションで伝送路として使用するのは、言うまでもなく、公衆回線を流用したインターネットです。

このため、「今日は Web ページの表示が早い」、「エンドポイント呼び出しからレスポンス受信までの時間が昨日より遅い」など、アクセスする時間帯や状況によってコミュニケーション時間に差が出る可能性が考えられます。

インターネットでは、クライアントとサーバーが直接やり取りをするわけではなく、ゲートウェイやルーターといった中継を担う機器、ドメイン名解決処理、が介在していて、それらを運用・管理する企業が存在します。中継機器の故障や処理の問題で、稀にインターネット全体が影響を受けることがあります。

このような問題は、ネットワークの負荷状況によって一時的に発生する場合もあります。クライアントからのリクエストにエラーが返されている場面で、少し時間を空けて再リクエストすると、期待したレスポンスが得られるケースです。これは、APS サーバーに問題がなくても、経路上の問題でリクエストが Web サーバーやクラウド リソースに到達出来ない可能性があろことを意味します。

呼び出し数制限

APS が提供するエンドポイントは、1 分間に呼び出すことが出来る数が制限されています。この制限は Rate Limit の表現でドキュメントで明記されています。

Rate Limit は API やエンドポイントによって一定ではありませんが、明示的に指定されるものには、Authentication API（OAuth API）、Data Management API、BIM 360 API、Autodesk Construction Cloud API、Model Derivative API、Webhooks API、Design Automation API、Reality Capture API などがあります。

この制限によって、Dos/DDos などの攻撃を防ぐだけでなく、すべての APS アプリに可用性と一貫したサービス品質を保証します。

指定数を超えたエンドポイント呼び出しには、429 コードのレスポンスが返されます。レスポンス（レスポンス ヘッダー）には再試行（再呼び出し）までの時間（秒）が含まれますので、同秒後に再度エンドポイント呼び出しすることが期待されます。

過剰な再呼び出しの繰り返しは、ネットワーク トラフィックの増大や APS サーバーの過剰な処理を招き、APS 環境全体のパフォーマンス低下につながってしまいます。

なお、APS サービスが何らかの理由で過負荷状態になっている場合にも、過負荷状態が終了するまで Rate Limit が実質的に低下する可能性がありますのご注意ください。Rate Limit の詳細は、Rate Limit（レート制限、呼び出し回数制限） をご確認ください。

非同期処理

すべての処理がローカル環境で完結するデスクトップ開発では、作成したプログラムは記述順に上から下へ順番に実行されます。途中の関数やメソッドの処理終了まで時間はかかっても、それらの終了を待って次の関数/メソッドが同期的に実行されることになります。

インターネットを使ったコミュニケーションでは、非同期処理を意識する必要があります。

ここまでの内容から、リクエスト送信からレスポンス受信まで、インターネットを使ったコミュニケーションでは、時々で応答時間が異なることをご理解いただけるはずです。

別の表現をするなら、リクエストに対するレスポンスは即時に得られるわけではない、ということになります。プログラム自体は上から下へ順番に実行される点は変わりませんが、リクエスト①の次にリクエスト②を記述した場合、リクエスト①のレスポンスが来る前に、リクエスト②のレスポンスが着信する場合も当然あり得ます。

使用する開発言語が非同期処理をサポートする記述/手法を提供しているはずですが、少なくともデスクトップ開発との差は意識すべきです。

仮想環境

Design Automation/自動化ソリューションで使用する Design Automation API は、Web 開発とデスクトップ製品用アドイン開発の両方の知識が必要なハイブリッド環境と言えます。

Design Automation API のアドイン処理も含め、CPU リソースを利用する演算サービスでは、クラウドの自動伸張機能（elastic computing）の特性も理解していただきたい点です。具体的には、Design Automation API は、リクエスト数に応じて、実行環境となる仮想マシンを動的に増減させます。

もし、短い間に数多くにリクエストが集中した場合、必要な数の仮想マシン展開に時間がかかり、処理完了までに「通常」より時間を要してしまう場合もあります。

オンプレミスとの違い

このように、APS の開発はデスクトップ製品のアドイン開発とは大きく異なります。Visual Insight（別名 Viewer ソリューション）や BIM 360 統合（別名ストレージ統合ソリューション）は、APS でしか実現出来ないものです。一方、アドインが介在する Design Automation（別名 自動化ソリューション）では、兎角、ローカル環境でのアドイン実行パフォーマンスと比較されがちです。

なるべく処理に問題が発生しないよう、オートデスクは APS に投資を続けていますが、インターネット経路など、一社ではどうにもならない部分があるのも事実です。

パブリック クラウドのインフラ（AWS）上に構築されている APS は、世界中の APS デベロッパとの共有リソースである、といった視点も重要です。

これらの点を理解していただき、Web やクラウド環境で得られるワークフローの見直しや新しい価値の創出・発見に重きを置いたソリューション開発に挑んでいただきたく思います。

By Toshiaki Isezaki