ニューラルネットワークに基づいて外観を評価するためのサービスアーキテクチャの概要

エントリー

Привет！

この記事では、ニューラル ネットワークを使用してプロジェクトのマイクロサービス アーキテクチャを構築した私の経験を共有します。

アーキテクチャの要件について話し、さまざまな構造図を確認し、完成したアーキテクチャの各コンポーネントを分析し、ソリューションの技術的指標を評価します。

読書をお楽しみください！

問題とその解決策について一言

写真をもとにその人の魅力をXNUMX段階で評価するというのが主な考え方です。

この記事では、使用されるニューラル ネットワークと、データの準備とトレーニングのプロセスの両方の説明から離れます。 ただし、次の出版物のいずれかで、詳細なレベルでの評価パイプラインの分析に必ず戻ります。

ここで、トップレベルの評価パイプラインを調べます。プロジェクト アーキテクチャ全体のコンテキストにおけるマイクロサービスの相互作用に重点が置かれます。 

魅力度評価パイプラインに取り組むとき、タスクは次のコンポーネントに分解されました。

1. 写真内の顔を選択する
2. 人それぞれの評価
3. 結果のレンダリング

XNUMX つ目は、事前に訓練された力によって解決されます。 MTCNN。 XNUMX 番目では、バックボーンが使用されたため、畳み込みニューラル ネットワークが PyTorch でトレーニングされました。 レスネット34 - 「CPU上の推論の品質/速度」のバランスから

機能評価パイプライン図

プロジェクトのアーキテクチャ要件の分析

ライフサイクルの中で ML モデルの展開のアーキテクチャと自動化に関する作業のプロジェクト段階。多くの場合、最も時間とリソースを消費する段階の XNUMX つです。

ML プロジェクトのライフサイクル

このプロジェクトも例外ではありません。評価パイプラインをオンライン サービスにラップすることが決定されました。そのためには、建築に没頭する必要がありました。 次の基本的な要件が特定されました。

1. 統合されたログ ストレージ - すべてのサービスはログを XNUMX か所に書き込み、分析しやすくする必要があります。
2. 評価サービスの水平スケーリングの可能性 - 最も可能性の高いボトルネックとして
3. 推論時間の分布の急増を避けるために、各画像の評価には同じ量のプロセッサ リソースを割り当てる必要があります。
4. 特定のサービスとスタック全体の両方の高速 (再) デプロイメント
5. 必要に応じて、異なるサービスで共通のオブジェクトを使用する可能性

アーキテクチャ

要件を分析した結果、マイクロサービス アーキテクチャがほぼ完璧に適合していることが明らかになりました。

不要な頭痛の種を取り除くために、Telegram API がフロントエンドとして選択されました。

まず、完成したアーキテクチャの構造図を見て、次に各コンポーネントの説明に進み、画像処理が成功するプロセスを形式化してみましょう。

完成した建築の構造図

図の各コンポーネントについて詳しく説明し、画像を評価するプロセスにおける単一の責任としてそれらを示します。

マイクロサービス「attrai-telegram-bot」

このマイクロサービスは、Telegram API とのすべての対話をカプセル化します。 主なシナリオは 2 つあります。カスタム イメージを使用する作業と、評価パイプラインの結果を使用する作業です。 両方のシナリオを見てみましょう。

画像付きのカスタム メッセージを受信した場合:

1. フィルタリングは次のチェックで構成されます。
   • 最適な画像サイズを持つ
   • すでにキューに入っているユーザー画像の数
2. 一次フィルタリングを通過すると、イメージは Docker ボリュームに保存されます
3. タスクは「to_estimate」キュー内に生成されます。このキューには、ボリューム内のイメージへのパスなどが表示されます。
4. 上記の手順が正常に完了すると、ユーザーは、キュー内のタスクの数に基づいて計算された推定画像処理時間を含むメッセージを受け取ります。 エラーが発生した場合、何が問題になった可能性があるかについての情報を含むメッセージを送信することにより、ユーザーに明示的に通知されます。

また、このマイクロサービスは、セロリ ワーカーとして、評価パイプラインを通過したタスクを対象とした「after_estimate」キューをリッスンします。

「after_estimate」から新規タスクを受信した場合：

1. 画像が正常に処理された場合は結果がユーザーに送信され、そうでない場合はエラーがユーザーに通知されます。
2. 評価パイプラインの結果であるイメージの削除

Attrai-estimator 評価マイクロサービス

このマイクロサービスはセロリ ワーカーであり、画像評価パイプラインに関連するすべてをカプセル化します。 ここで機能するアルゴリズムは XNUMX つだけです。それを分析します。

「to_estimate」から新規タスクを受信した場合：

1. 評価パイプラインを通じてイメージを実行します。
   1. 画像をメモリにロードする
   2. 画像をご希望のサイズに調整します
   3. すべての顔を検索 (MTCNN)
   4. すべての面を評価します (最後の段落で見つかった面を ResNet34 バッチと推論でラップします)
   5. 最終イメージのレンダリング
      1. 境界ボックスを描画する
      2. 成績を描く
2. カスタム (オリジナル) イメージの削除
3. 評価パイプラインからの出力の保存
4. タスクを「after_estimate」キューに置き、上で解析した「attrai-telegram-bot」マイクロサービスによってリッスンされます。

グレイログ (+ mongoDB + Elasticsearch)

グレイログ は、ログを一元管理するためのソリューションです。 このプロジェクトでは、本来の目的に使用されました。

選択は普通の人ではなく彼に下された ELK スタックは、Python の下から操作できるため便利です。 Graylog にログを記録するには、パッケージから GELFTCPHandler を追加するだけです。 グレイピー Python マイクロサービスの残りのルート ロガー ハンドラーに送信します。

これまで ELK スタックでしか作業したことがなかった私は、Graylog を使用する際に概ね前向きな経験をしてきました。 唯一残念なのは、Kibana の機能が Graylog Web インターフェイスよりも優れていることです。

RabbitMQの

RabbitMQの AMQP プロトコルに基づくメッセージ ブローカーです。

このプロジェクトでは、次のように使用されました。 最も安定しており、実績のあるもの Celery のブローカーであり、耐久モードで動作しました。

Redisの

Redisの キーと値のデータ構造を操作する NoSQL DBMS です

場合によっては、データ構造を実装するさまざまな Python マイクロサービスで共通のオブジェクトを使用することが必要になることがあります。

たとえば、Redis は「telegram_user_id => キュー内のアクティブなタスクの数」という形式のハッシュマップを保存します。これにより、XNUMX 人のユーザーからのリクエストの数を特定の値に制限し、それによって DoS 攻撃を防ぐことができます。

画像処理を成功させるプロセスを形式化します

1. ユーザーが画像を Telegram ボットに送信します
2. 「attrai-telegram-bot」は Telegram API からメッセージを受信し、それを解析します
3. 画像を含むタスクが非同期キュー「to_estimate」に追加されます
4. ユーザーは推定評価時間を含むメッセージを受け取ります
5. 「attrai-estimator」は「to_estimate」キューからタスクを取得し、パイプラインを通じて推定を実行し、「after_estimate」キューにタスクを生成します。
6. 「after_estimate」キューをリッスンする「attrai-telegram-bot」が結果をユーザーに送信します

DevOps

最後に、アーキテクチャを確認した後、同様に興味深い部分である DevOps に進むことができます。

DockerSwarm

 

DockerSwarm  はクラスタリング システムであり、その機能は Docker エンジン内に実装されており、すぐに使用できます。

「swarm」の助けを借りて、クラスターのすべてのノードをワーカーとマネージャーの 2 つのタイプに分けることができます。 最初のタイプのマシンではコンテナのグループ (スタック) がデプロイされ、XNUMX 番目のタイプのマシンはスケーリング、バランス調整、および その他の優れた機能。 マネージャーはデフォルトでは労働者でもあります。

XNUMX 人のリーダー マネージャーと XNUMX 人のワーカーからなるクラスター

可能な最小クラスター サイズは 1 ノードで、唯一のマシンがリーダー マネージャーとワーカーとして同時に機能します。 プロジェクトの規模とフォールト トレランスの最小要件に基づいて、このアプローチを使用することが決定されました。

今後の展望としては、XNUMX 月中旬の最初の本番配信以来、このクラスター組織に関連する問題は発生していないと言えます (ただし、これは、このような組織がどの媒体でも少なくともある程度受け入れられることを意味するわけではありません)。大規模なプロジェクトはフォールト トレランス要件の対象となります)。

ドッカースタック

「swarm」モードでは、スタック (Docker サービスのセット) のデプロイメントが責任を負います。 ドッカースタック

docker-compose 構成をサポートしているため、オプションでデプロイ オプションを使用できます。  

たとえば、これらのパラメーターを使用して、評価用マイクロサービス インスタンスごとにリソースが制限されました (N 個のインスタンスに N 個のコアを割り当てます。マイクロサービス自体では、PyTorch で使用されるコアの数を XNUMX つに制限します)。

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

Redis、RabbitMQ、Graylog はステートフル サービスであり、「attrai-estimator」のように単純にスケールすることは機能しないことに注意することが重要です。

なぜ Kubernetes ではないのか?という疑問の予兆です。

中小規模のプロジェクトで Kubernetes を使用するとオーバーヘッドになるようです。必要な機能はすべて Docker Swarm から取得できます。Docker Swarm はコンテナ オーケストレーターにとって非常に使いやすく、導入しきい値も低いです。

インフラ

これらはすべて、次の特性を持つ VDS にデプロイされました。

• CPU: 4 コア Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM: 8 GB
• SSD：160GB

ローカル負荷テストの結果、ユーザーが大量に流入する場合には、このマシンで十分であることがわかりました。

しかし、導入直後に、CIS で最も人気のあるイメージボードの XNUMX つ (はい、同じものです) へのリンクを投稿したところ、人々が興味を持ち、数時間でサービスは数万枚の画像を処理することに成功しました。 同時に、ピーク時には、CPU と RAM のリソースは半分も使用されていませんでした。

さらにグラフィックを追加

導入以降の日別のユニーク ユーザーと評価リクエストの数

推定パイプラインの推論時間の分布

所見

要約すると、コンテナのオーケストレーションに対するアーキテクチャとアプローチは完全に正当なものであり、ピーク時であっても処理時間の低下や沈下はなかったと言えます。 

プロセスで CPU 上のニューラル ネットワークのリアルタイム推論を使用する小規模および中規模のプロジェクトは、この記事で説明したプラクティスをうまく導入できると思います。

最初は記事が長かったことを付け加えておきますが、長文を投稿しないようにするために、この記事ではいくつかの点を省略することにしました。それらについては、次の出版物で再び説明します。

Telegram - @AttraiBot でボットを攻撃することができます。少なくとも 2020 年の秋の終わりまでは機能します。 念のため言っておきますが、ユーザー データは保存されず、元の画像も評価パイプラインの結果も保存されず、処理後にはすべて破棄されます。

出所： habr.com