Azure でのイメージの分類

Blob Storage
Computer Vision
Cosmos DB
Event Grid
関数

このシナリオは、イメージを処理する必要があるビジネスに関連があります。

応用の可能性としては、ファッション Web サイトのイメージの分類、保険金請求のテキストおよびイメージの分析、ゲームのスクリーンショットからの利用統計情報の把握などが挙げられます。 従来、企業では、機械学習モデルで専門知識を開発したうえで、そのモデルをトレーニングし、最終的にカスタム プロセスによってイメージを実行し、イメージからデータを取得していました。

Computer Vision API、Azure Functions などの Azure サービスを使用すると、企業はサーバーを個別に管理する必要がなくなり、コストを削減できるほか、既に Microsoft で開発済みの、Cognitive Services でのイメージ処理に関する専門知識を活用することができます。 この例では、特にイメージ処理ユース ケースを扱っています。 別の AI ニーズがある場合は、一連の Cognitive Services について検討してください。

関連するユース ケース

その他の関連するユース ケース:

  • ファッション Web サイトの画像の分類。
  • ゲームのスクリーンショットの利用統計情報の分類。
  • 保険金請求のイメージの分類。

Architecture

イメージ分類のアーキテクチャ

このシナリオでは、Web またはモバイル アプリケーションのバックエンド コンポーネントに対応できます。 シナリオのデータ フローは次のとおりです。

  1. API レイヤーは、Azure Functions を使用して構築されています。 これらの API により、アプリケーションでイメージをアップロードし、Cosmos DB からデータを取得できます。
  2. API 呼び出しでアップロードされたイメージが Blob Storage に格納されます。
  3. 新しいファイルを Blob Storage に追加すると、EventGrid 通知がトリガーされ、Azure 関数に送信されます。
  4. Azure Functions により、新しくアップロードされたファイルへのリンクが、分析のために Computer Vision API に送信されます。
  5. Computer Vision API からデータが返されたら、Azure Functions によって、Cosmos DB のエントリに分析の結果とイメージ メタデータが保持されます。

Components

  • Computer Vision API は、Cognitive Services スイートに含まれ、各イメージに関する情報の取得に使用されます。
  • Azure Functions は、Web アプリケーションにバックエンド API を、また、アップロードされたイメージにイベント処理を提供します。
  • Event Grid は、新しいイメージが Blob Storage にアップロードされたときに、イベントをトリガーします。 その後、イメージは Azure 関数で処理されます。
  • Blob Storage には、Web アプリケーションにアップロードされたすべてのイメージ ファイルと、Web アプリケーションによって使用される任意の静的ファイルが格納されます。
  • Cosmos DB には、Computer Vision API からの処理結果を含め、アップロードされた各イメージに関するメタデータが格納されます。

代替

  • Custom Vision Service。 Computer Vision API は、一連の分類ベースのカテゴリを返します。 Computer Vision API によって返されていない情報を処理する必要がある場合は、Custom Vision Service を検討してください。これにより、カスタム イメージ分類子を構築できます。
  • Cognitive Search (以前の Azure Search)。 特定の条件を満たすイメージを検索するために、ご自身のユース ケースでメタデータにクエリを実行する必要がある場合は、Cognitive Search を検討してください。 現在、プレビュー中の Cognitive Search では、このワークフローがシームレスに統合されます。
  • Logic Apps。 Blob に追加されたファイルにリアルタイムに応答する必要がない場合は、Logic Apps の使用を検討できます。 ファイルが追加されたかどうかを確認できるロジック アプリは、繰り返しトリガーまたはスライディング ウィンドウ トリガーによって開始される可能性があります。

考慮事項

スケーラビリティ

このシナリオの例で使用されるコンポーネントの大半が、自動スケーリングされるマネージド サービスです。 注目すべき例外がいくつかあります。Azure Functions のインスタンス数は最大 200 個に制限されています。 この限界を超えてスケーリングする場合は、複数のリージョンまたはアプリ プランを検討してください。

Cosmos DB は、SQL API の自動スケーリングに対してのみプロビジョニングできます。 他の API の使用を計画している場合は、ご自身の要件の推定に関するガイダンスをご覧ください。Microsoft ドキュメントの要求ユニットに関するページをご覧ください。 Cosmos DB でスケーリングのメリットを十分に活用するには、Cosmos DB でのパーティション キーのしくみを理解してください。

NoSQL データベースでは、可用性、スケーラビリティ、および分断性と引き換えに、一貫性 (CAP 定理という意味で) が犠牲になることがよくあります。 ただし、このシナリオの例では、キーと値のデータ モデルが使用され、ほとんどの操作が本質的にアトミックであるため、トランザクションの一貫性が必要になることはほとんどありません。 追加のガイダンスについては、Azure アーキテクチャ センターの「適切なデータ ストアの選択」を参照してください。 実装で高い一貫性が必要な場合は、Cosmos DB で整合性レベルを選択することができます。

スケーラブルなソリューションの設計に関する一般的なガイダンスについては、Azure アーキテクチャ センターの「パフォーマンス効率のチェックリスト」を参照してください。

Security

Azure リソース用のマネージド ID は、自分のアカウントの内部にある他のリソースへのアクセスを提供するために使用された後、Azure Functions に割り当てられます。 これらの ID の必要なリソースへのアクセスのみを許可して、余分なものがお使いの関数 (およびご自身の顧客) に公開されないようにします。

セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。

回復性

このシナリオのすべてのコンポーネントが管理されているため、すべてについて、リージョン レベルの回復性が自動的に確保されます。

回復性に優れたソリューションの設計に関する一般的なガイダンスについては、回復性に優れた Azure 用アプリケーションの設計に関するページを参照してください。

価格

このシナリオの実行コストを調べることができるように、すべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースについて価格の変化を確認するには、予想されるトラフィックに合わせて該当する変数を変更します。

トラフィックの量に基づいて、次の 3 つのサンプル コスト プロファイルが用意されています (すべてのイメージのサイズが 100 KB であると想定しています)。

  • Small: この価格例は、1 か月あたり < 5,000 件のイメージの処理に対応します。
  • Medium: この価格例は、1 か月あたり 500,000 件のイメージの処理に対応します。
  • Large: この価格例は、1 か月あたり 50,000,000 件のイメージの処理に対応します。

ガイド付きラーニング パスについては、以下を参照してください。

このシナリオの例を運用環境にデプロイする前に、Azure Functions のパフォーマンスと信頼性を最適化するための推奨プラクティスをご確認ください。