Gurobiのライセンスタイプの選び方

注意: このページの目的は、Gurobiがお客様の環境にどのように配備およびライセンスされるかの、各種の方法についての概要を説明することです。この記事にはすべてのライセンスタイプと、その長所と短所を含むわけではなく、商業的な情報を提供するものでもありません。目的はあくまで 、ライセンスタイプを選択する際に重要となる要因が何かを説明することです。お客様の状況に合った正しい選択をするために、Gurobiのセールスチームがお手伝いさせていただきます。

概念 

この記事で使用する、Gurobiの各概念を指す用語について説明します

• モデル: Gurobiに解いてほしい特定の問題の数学的表現。
• API: 自分のアプリケーションコードを書くときに操作するGurobiソフトウェアのインターフェース。モデルを記述、Gurobiによる最適化の実行、解を取得するためにAPIを呼び出します。
• エンジン: モデルを読み込み、最適な解を見つけるGurobiソフトウェアのコアとなる部分。この部分には、数理最適化に必要なすべてのアルゴリズムが含まれています。

アーキテクチャ

Gurobiを使用するためには、エンジンとAPIの両方が必要です。これら二つの部分をつなぐ基本的な方法は3つあります。どの方法を選ぶかに関わらず、APIの使用方法とモデル解決のためにエンジンで使用されるアルゴリズムは同じです。

• インプロセス(ローカル実行): APIを使用して、モデルをローカルメモリ内で定義します。Gurobiにモデルの求解を指示すると、エンジンは同じプロセスでメモリ内のモデル表現を使用して最適化を実行します。
• クライアント-サーバー: APIを使用してローカルでモデルを構築する点は同じです。同時に、（通常は）別のマシンやコンテナで、Gurobi Compute Serverコンポーネントを別のプロセスとして実行しておきます。モデルの求解を指示すると、APIはエンジンをホストしているCompute Serverに対し、自動的にモデルを送信します。解が利用可能になると、APIを通じて取得可能です。
• クラウド: 上記の方法はすべて、お客様自身の環境（オンプレミスまたはお客様が管理するクラウド環境）で実行されます。第三の方法は、AWSまたはAzure環境でGurobi社がエンジンを管理し実行することを許可するものです。引き続きAPIを使用する点は同じですが、モデルを求解させる際は、それがGurobi Instant Cloudに送信されます。モデルを受けとったマシンがモデルを求解し、解を返します。内部では、上記と同じCompute Serverテクノロジーを使用しています。

ライセンスの仕組み

Gurobiのライセンスの目的は、契約で合意された方法でGurobiが使用されていることを確認することです。これには、同じライセンスの同時使用数をカウントすることが含まれます。これには様々なメカニズムを提供しています。

• マシンベース: ライセンスをアクティベートすると、そのライセンスは特定のマシンに「ロック」されます。他のマシンでアクティベートまたは使用することはできません。ライセンスがあるマシンがGurobiのエンジンが動作するマシンです。
• トークンサーバー: この場合もライセンスは特定のマシンにロックされますが、そのマシンはGurobiトークンサーバーをホストします。エンジンは任意のマシン（通常はトークンサーバーとは異なるマシン、またはコンテナ内）で実行できます。エンジンがモデルを求解したい場合、同時使用をカウントする機能があるトークンサーバーからトークンを取得する必要があります。このアプローチを「フローティング使用」とも呼び、このライセンスタイプはコンテナでも機能します。
• Web License Service: もう一つの方法は、クラウドでライセンスとトークンを管理することです。トークンサーバーを実行する必要はありません。代わりに、お客様の環境で動作するGurobiエンジンはオンラインサービスに接続してトークンを取得します。

Instant Cloud の場合、GurobiエンジンはGurobi社が管理しているため、上記のオプションは必要ありません。

ライセンスをどう選ぶか？

ライセンスタイプを議論する際には、以下の要因を考慮する必要があります。

• 柔軟性: Gurobiを呼び出すアプリケーションが実行されるマシン/コンテナはいくつあるか？ アーキテクチャはどのくらいの頻度で変更されるか？
• セキュリティ: Instant CloudやWeb License Serviceなどの外部サービスに接続することが許可されるか？あるいはそれを妨げるポリシーがあるか？
• 期待されるパフォーマンス: エンドユーザーはどれくらいの時間で結果を出すことを期待しているか？ エンドユーザーはどれくらい待つことができるか？
• 使用頻度: どのくらいの頻度で最適化問題の求解にGurobiを利用するか？ 一日の平均利用量はどのくらいか？ピーク時の使用量はどうか？
• パフォーマンス: 解きたいモデルの典型的な実行時間はどれくらいか？ 実行時間を改善できるかもしれないパラメータの選定やログファイルの分析をしたか？またはGurobiチームとこれらについて話し合ったか？
• スケーリング: Gurobiエンジンとは独立してアプリケーションをスケールアップする必要があるか？
• 機能: キューイング、優先順位付け、認証/承認、非同期解決、ダッシュボード、REST APIのような機能が必要か？

上記のとおり、ライセンスタイプの選択は単なる好みや価格の問題ではありません。上記の問への回答を検討することで、適切なアーキテクチャとライセンスタイプを選ぶためのガイドとなるはずです。