アーキテクチャ

TensorFlow Servingは、機械学習モデル向けの柔軟で高性能なサービングシステムであり、本番環境向けに設計されています。 TensorFlow Servingを使用すると、同じサーバーアーキテクチャとAPIを維持しながら、新しいアルゴリズムと実験を簡単にデプロイできます。 TensorFlow Servingは、TensorFlowモデルとの統合をすぐに利用できますが、他のタイプのモデルにサービスを提供するように簡単に拡張できます。

重要な概念

TensorFlowサービングのアーキテクチャを理解するには、次の重要な概念を理解する必要があります。

サーバブル

サーバブルは、TensorFlowサービングの中心的な抽象概念です。サーバブルは、クライアントが計算(たとえば、ルックアップや推論)を実行するために使用する基礎となるオブジェクトです。

Servableのサイズと粒度は柔軟です。単一のServableには、ルックアップテーブルの単一のシャードから、単一のモデル、推論モデルのタプルまで、あらゆるものが含まれる場合があります。サーバブルは任意のタイプとインターフェースにすることができ、次のような柔軟性と将来の改善を可能にします。

  • ストリーミング結果
  • 実験的なAPI
  • 非同期動作モード

サーバブルは、独自のライフサイクルを管理しません。

典型的な使用可能なものは次のとおりです。

  • TensorFlow SavedModelBundle( tensorflow::Session
  • 埋め込みまたは語彙ルックアップ用のルックアップテーブル

提供可能なバージョン

TensorFlow Servingは、単一のサーバーインスタンスの存続期間にわたってservableの1つ以上のバージョンを処理できます。これにより、新しいアルゴリズム構成、重み、およびその他のデータを時間の経過とともにロードできます。バージョンを使用すると、サーバブルの複数のバージョンを同時にロードできるため、段階的な展開と実験がサポートされます。提供時に、クライアントは特定のモデルの最新バージョンまたは特定のバージョンIDのいずれかを要求できます。

サーブ可能なストリーム

servableストリームは、バージョン番号の増加によってソートされた、servableのバージョンのシーケンスです。

モデル

TensorFlowサービングは、モデルを1つ以上のサーバブルとして表します。機械学習モデルには、1つ以上のアルゴリズム(学習された重みを含む)とルックアップテーブルまたは埋め込みテーブルが含まれる場合があります。

複合モデルは、次のいずれかとして表すことができます。

  • 複数の独立したサーバブル
  • 単一の複合サービス可能

サーバブルは、モデルの一部に対応する場合もあります。たとえば、大きなルックアップテーブルを多くのTensorFlowサービングインスタンスに分割できます。

ローダー

ローダーは、サーサブルのライフサイクルを管理します。 Loader APIは、関連する特定の学習アルゴリズム、データ、または製品のユースケースから独立した共通のインフラストラクチャを可能にします。具体的には、ローダーはサーバブルをロードおよびアンロードするためのAPIを標準化します。

ソース

ソースは、servablesを見つけて提供するプラグインモジュールです。各ソースは、0個以上のサービス可能なストリームを提供します。ソースは、サーブ可能なストリームごとに、ロード可能にするバージョンごとに1つのローダーインスタンスを提供します。 (ソースは実際には0個以上のSourceAdaptersとチェーンされており、チェーンの最後のアイテムはローダーを放出します。)

TensorFlow Servingのソース用インターフェースは、任意のストレージシステムからサーバブルを検出できます。 TensorFlow Servingには、一般的なリファレンスソースの実装が含まれています。たとえば、ソースはRPCなどのメカニズムにアクセスし、ファイルシステムをポーリングできます。

ソースは、複数のサーバブルまたはバージョン間で共有される状態を維持できます。これは、バージョン間でデルタ(差分)更新を使用するサーバブルに役立ちます。

意欲的なバージョン

意欲的なバージョンは、ロードして準備ができている必要があるサービス可能なバージョンのセットを表します。ソースは、一度に1つのサービス可能なストリームに対してこのサービス可能なバージョンのセットを通信します。ソースが希望するバージョンの新しいリストをマネージャーに提供すると、そのサービス可能なストリームの以前のリストに優先します。 Managerは、リストに表示されなくなった以前にロードされたバージョンをアンロードします。

バージョンの読み込みが実際にどのように機能するかについては、高度なチュートリアルを参照してください。

マネージャー

管理者は、以下を含むServablesのライフサイクル全体を処理します。

  • サーバブルのロード
  • サーバブルを提供する
  • サーバブルのアンロード

管理者はソースをリッスンし、すべてのバージョンを追跡します。 Managerはソースの要求に応えようとしますが、必要なリソースが利用できない場合など、目的のバージョンのロードを拒否する場合があります。管理者は「アンロード」を延期することもできます。たとえば、マネージャは、少なくとも1つのバージョンが常にロードされることを保証するポリシーに基づいて、新しいバージョンのロードが完了するまでアンロードを待機する場合があります。

TensorFlowサービングマネージャーは、クライアントがロードされたサーバブルインスタンスにアクセスするためのシンプルで狭いインターフェースGetServableHandle()を提供します。

標準のTensorFlowサービングAPisを使用して、 TensorFlowサービングコアはサーバブルの次の側面を管理します。

  • ライフサイクル
  • メトリック

TensorFlow Serving Coreは、サーバブルとローダーを不透明なオブジェクトとして扱います。

サーバブルの寿命

tfサービングアーキテクチャ図

大まかに言って:

  1. ソースは、提供可能なバージョンのローダーを作成します。
  2. ローダーはAspiredVersionsとしてManagerに送信され、Managerはそれらをロードしてクライアントの要求に提供します。

さらに詳細に:

  1. ソースプラグインは、特定のバージョンのローダーを作成します。ローダーには、Servableをロードするために必要なメタデータが含まれています。
  2. ソースはコールバックを使用して、Aspiredバージョンをマネージャーに通知します。
  3. Managerは、構成されたバージョンポリシーを適用して、実行する次のアクションを決定します。これは、以前にロードされたバージョンをアンロードするか、新しいバージョンをロードすることです。
  4. Managerが安全であると判断した場合、ローダーに必要なリソースを提供し、ローダーに新しいバージョンをロードするように指示します。
  5. クライアントは、バージョンを明示的に指定するか、最新バージョンを要求するだけで、マネージャーにServableを要求します。 ManagerはServableのハンドルを返します。

たとえば、ソースが頻繁に更新されるモデルの重みを持つTensorFlowグラフを表すとします。重みはディスク上のファイルに保存されます。

  1. ソースは、モデルの重みの新しいバージョンを検出します。ディスク上のモデルデータへのポインタを含むローダーを作成します。
  2. ソースは、DynamicManagerにAspiredバージョンを通知します。
  3. Dynamic Managerはバージョンポリシーを適用し、新しいバージョンをロードすることを決定します。
  4. Dynamic Managerは、十分なメモリがあることをローダーに通知します。ローダーは、新しい重みを使用してTensorFlowグラフをインスタンス化します。
  5. クライアントがモデルの最新バージョンへのハンドルを要求し、DynamicManagerが新しいバージョンのServableへのハンドルを返します。

拡張性

TensorFlow Servingは、新しい機能を追加できるいくつかの拡張ポイントを提供します。

バージョンポリシー

バージョンポリシーは、単一のサービス可能なストリーム内でのバージョンのロードとアンロードのシーケンスを指定します。

TensorFlow Servingには、ほとんどの既知のユースケースに対応する2つのポリシーが含まれています。これらは、可用性保持ポリシー(ゼロバージョンをロードしたままにしないでください。通常、古いバージョンをアンロードする前に新しいバージョンをロードします)とリソース保存ポリシー(2つのバージョンを同時にロードしないようにして、リソースを2倍にする必要があります。ロードする前に古いバージョンをアンロードします)です。新しいもの)。モデルのサービングの可用性が重要で、リソースのコストが低いTensorFlow Servingの簡単な使用法では、可用性保持ポリシーにより、古いバージョンをアンロードする前に、新しいバージョンがロードされ、準備ができていることが保証されます。複数のサーバーインスタンス間でバージョンを管理するなど、TensorFlowサービングの高度な使用法の場合、リソース保存ポリシーに必要なリソースは最小限です(新しいバージョンをロードするための追加のバッファーはありません)。

ソース

新しいソースは、新しいファイルシステム、クラウドオファリング、およびアルゴリズムバックエンドをサポートできます。 TensorFlow Servingは、新しいソースを簡単かつ迅速に作成できるようにするためのいくつかの一般的な構成要素を提供します。たとえば、TensorFlow Servingには、ポーリング動作を単純なソースにラップするユーティリティが含まれています。ソースは、特定のアルゴリズムおよびデータホスティングサービスのローダーと密接に関連しています。

カスタムソースを作成する方法の詳細については、カスタムソースのドキュメントを参照してください。

ローダー

ローダーは、アルゴリズムとデータバックエンドを追加するための拡張ポイントです。 TensorFlowは、そのようなアルゴリズムのバックエンドの1つです。たとえば、新しいタイプのサービス可能な機械学習モデルのインスタンスをロード、アクセス、およびアンロードするために、新しいローダーを実装します。ルックアップテーブルと追加のアルゴリズム用のローダーを作成する予定です。

カスタムServableを作成する方法については、CustomServableドキュメントを参照してください。

バッチャー

複数のリクエストを1つのリクエストにバッチ処理すると、特にGPUなどのハードウェアアクセラレータが存在する場合に、推論を実行するコストを大幅に削減できます。 TensorFlow Servingには、リクエストバッチウィジェットが含まれています。これにより、クライアントは、リクエスト全体でタイプ固有の推論を、アルゴリズムシステムがより効率的に処理できるバッチリクエストに簡単にバッチ処理できます。詳細については、バッチガイドを参照してください。