この記事は、の一部として公開されました データサイエンスブログソン
ディープラーニングとニューラルネットワークの速度は、何千もの業界にとってますます不可欠になっています。 彼らが直面する主な問題のXNUMXつは 複雑な展開 アプリケーションの種類。 クラウドテクノロジーやクラスターの専門家である必要がない、このような展開の実用的で便利な方法を紹介したいと思います。 このために、 サーバーレス インフラストラクチャー。 移動しましょう!
概要
最近、深層学習またはニューラルネットワークによって作成されたモデルを使用して、製品の多くの問題が解決されました。 多くの場合、これらは従来の決定論的方法によって長年解決されてきた問題であり、MLを介して解決するのがより簡単で安価になりました。
KerasやTensorflowなどの最新のフレームワークと既製のソリューションのカタログを使用すると、製品に必要な精度を提供するモデルを簡単に作成できます。
最も重要なことは、今日、モデルを見つけたり、ダウンロードしたり、トレーニングしたりするのが簡単であり、同じように簡単にデプロイできるようにしたいということです。
繰り返しになりますが、新興企業や中小企業で働く場合、技術的な仮定だけでなく、市場の仮定もすばやくテストする必要があります。 同様に、モデルを迅速、簡単、かつスマートに展開する必要があります。
このようなデプロイメントの問題を解決するために、私はクラウドマイクロサービスを使用するのが好きでした。
FaaS –サービスとしての機能は比較的安価で、デプロイが簡単で(Dockerは不要)、ほぼ無制限の数のエンティティを並行して実行できます。
次に、AmazonのFaaSであるAWSLambdaにTensorFlow / Kerasモデルをデプロイする方法を紹介します。 その結果、画像上のコンテンツを認識するためのAPIは、1回の認識に対して20,000ドルの費用がかかります。 安いですか? 多分。 簡単にできますか? ありそうもない。
サービスとしての機能
さまざまなタイプのアプリケーション展開の図を検討してください。
画像1
次に、IaaS(Infrastructure-as-a-Service)が表示されます。ここでは、サーバーがデータセンターに配置されており、すでに特定の仮想マシンを使用しています。 次のステップは、マシン自体にアクセスできなくなったときのPlatform-as-a-Serviceですが、アプリケーションが実行されるコンテナーを管理します。 そして最後に、FaaS(Function-as-a-Service)では、コード以外のすべてが非表示になっており、制御する必要があります。 これは後で説明するように朗報であり、非常に優れた機能を提供します。
AWS Lambdaは、AWSプラットフォームでのFAAS実装です。 実装について簡単に説明します。 そのコンテナはzipアーカイブ[コード+ライブラリ]です。 AWSは、外部リクエスト(トリガー)の数に基づいてこのコードをコンテナーにデプロイします。 基本的に上からの境界はありません。現在の制限は、同時に動作するコンテナを1000個ですが、サポートによって簡単に10000以上に上げることができます。
AWS Lambdaの主な利点:
-
デプロイが簡単(Dockerなし)–コードとライブラリのみ
-
優れたスケーリング–本番環境では、同時に40万回を超える呼び出しを実行しました。 もっと可能です。
-
低通話コスト。 BDの方向からの私の同僚にとって、マイクロサービスがサービスを使用するための従量課金モデルをサポートすることも重要です。 これにより、スケーリング時にモデルを使用する単位の経済性が明確になります。
ニューラルネットワークをサーバーレスに移植するのはなぜですか?
まず、使用します テンソルフロー アプリケーションの目的のため。 これは、開発者がディープラーニングモデルを作成、テストトレーニング、およびデプロイできるようにするオープンフレームワークです。 これは、群を抜いて最も人気のあるディープラーニングライブラリであり、専門家と初心者の両方が使用します。
現時点では、機械学習モデルをデプロイするための主な方法はクラスターです。 ディープラーニング用のRESTAPIの外観は次のようになります。
画像2
面倒そう? 今、あなたが最も世話をする必要があるものを見てください:
-
クラスタマシンにトラフィックを分散するためのロジックを記述します
-
ダウンタイムとブレーキングの間の中庸を見つけようとして、スケーリングのロジックを記述します
-
コンテナの動作のロジックを規定する–ロギング、受信リクエストの管理
AWS Lambdaでは、アーキテクチャははるかに単純に見えます。
画像3
まず、このアプローチは非常にスケーラブルです。 追加のロジックを記述せずに、最大10万の同時リクエストを処理できます。 この機能により、アーキテクチャは追加の処理時間を必要としないため、ピーク負荷の処理に最適です。
次に、サーバーのダウンタイムを支払う必要がありません。 サーバーレスアーキテクチャでは、25つのリクエストに対して支払いが行われます。 つまり、25のリクエストがある場合、どのストリームに入ったかに関係なく、20のリクエストに対してのみ支払うことになります。後で示すTensorflowの例では、コストは25ドルあたり1万から1のリクエストです。 。まったく同じ機能を持つクラスターのコストは非常に高く、非常に多数のリクエスト(> XNUMX万)でのみ発生する方が収益性が高くなります。
第三に、インフラストラクチャははるかに大きくなっています。 Dockerを使用する必要はなく、スケーリングと負荷分散のロジックを記述します。 つまり、会社はインフラストラクチャをサポートするために追加の人を雇う必要はなく、データサイエンティストであれば、すべて自分で行うことができます。
以下に示すように、上記のアプリケーションのインフラストラクチャ全体をデプロイするには、4行以下のコードが必要です。
サーバーレスインフラストラクチャの欠点とそれが機能しない場合は言うまでもなく、間違いです。 AWSLambdaには かたい 処理時間とメモリ 制約 心に留めておくべき。
まず、ピーク負荷がなく、リクエストが多い場合、クラスターの収益性が高くなります。
次に、AWS Lambdaの開始時間は小さいですが明確です(100〜200ミリ秒)。 ディープラーニングのアプリケーションの場合、ダウンロードにはもう少し時間がかかります。 以下に示す例では、コールドスタートは4.5秒、ウォームスタートは3秒になります。 一部のアプリケーションでは、これは重要ではない場合がありますが、アプリケーションが単一の要求を可能な限り迅速に処理することに重点を置いている場合は、クラスターの方が適しています。
AWSLambdaでのサーバーレスTensorflowのアプリケーション
この例では、かなり人気のあるニューラルネットワークのアプリケーションを使用しています– 画像認識。 このアプリケーションは、入力として写真を撮り、その上のオブジェクトの説明を返します。 これらの種類のアプリケーションは、画像をフィルタリングし、多くの画像をグループに分類するために広く使用されています。 私たちのアプリケーションは、パンダの画像の認識作業も行います。
画像4
次のスタックを使用します。
-
リクエストを管理するためのAPIゲートウェイ
-
処理用のAWSLambda
-
サーバーレス展開フレームワーク
AWSLambdaでのサーバーレスTensorflowの実装コード
まず、アプリケーションのオーケストレーションとデプロイに使用するサーバーレスフレームワークをインストールして構成する必要があります。 ガイドへのリンク.
空の新しいフォルダを作成し、指定されたコマンドを実行するだけです。
サーバーレスインストール-uhttps://github.com/ryfeus/lambda-packs/tree/master/tensorflow/source -n tensorflow cd tensorflow serverless deploy serverless invoke-function main--log次の応答が返されます。 、Ailuropoda melanoleuca(スコア= 2012)indri、Indri brevicaudatus(スコア= 0.89107)カスタードアップル(スコア= 0.00779)アーススター(スコア= 0.00147)
ご覧のとおり、モデルによるパンダの画像(0.89)の正常な出力。
わお! AWS LambdaのTensorflowで、4行のコードを使用して、画像認識の目的でニューラルネットワークを正常にデプロイしました。
AWSLambdaでのサーバーレスTensorflowのコードを詳しく見ていきましょう
設定ファイルから始めましょう。 特別なことは何もありません。基本的なAWSLambda構成を使用しています。
サービス:tensorflow FrameworkVersion: "> = 1.2.0 <2.0.0"プロバイダー:名前:awsランタイム:python2.7 memorySize:1536タイムアウト:300関数:メイン:ハンドラー:index.handler
'index.py'ファイル自体を見ると、最初にモデル( '.pb'ファイル)をAWSLambdaの '/ tmp /'フォルダーにダウンロードしてから、標準的な方法でインポートしていることがわかります。 Tensorflow経由。
以下は、独自のモデルを埋め込む場合に留意する必要があるGithubのコードへのリンクです。
S3からモデルをダウンロードする
strBucket = 'ryfeuslambda' strKey = 'tensorflow / imagenet / classify_image_graph_def.pb' strFile = '/ tmp / imagenet / classify_image_graph_def.pb' downloadFromS3(strBucket、strKey、strFile)print(strFile)
モデルのインポート
def グラフの作成(): tf.gfile.FastGFile(os.path.join( '/ tmp / imagenet /'、'classify_image_graph_def.pb')、'rb') as f:graph_def = tf.GraphDef()graph_def.ParseFromString(f.read())_ = tf.import_graph_def(graph_def、name = '')
画像をダウンロードする
strFile = '/ tmp / imagenet / inputimage.jpg' if ( 'imagelink' in イベント):urllib.urlretrieve(event ['imagelink']、strFile) ほかに:strBucket = 'ryfeuslambda' strKey = 'tensorflow / imagenet / Cropped_panda.jpg' downloadFromS3(strBucket、strKey、strFile)print(strFile)
モデルから予測を取得する
softmax_tensor = sess.graph.get_tensor_by_name( 'softmax:0')predictions = sess.run(softmax_tensor、{'DecodeJpeg / contents:0':image_data})predictions = np.squeeze(predictions)
それでは、APIをラムダに追加しましょう。
APIの例
APIを追加する最も簡単な方法は、YAML構成ファイルを変更することです。
サービス:tensorflowフレームワークバージョン: "> = 1.2.0 <2.0.0"プロバイダー:名前:awsランタイム:python2.7 memorySize:1536タイムアウト:300関数:メイン:ハンドラー:index.handlerイベント:-http:GETハンドラーNowスタックを再デプロイしましょう:serverlessdeploy次のようになります。 サービス情報サービス:tensorflowステージ:開発領域:us-east-1スタック:tensorflow-dev apiキー:なしエンドポイント:GET-https://.execute-api.us-east-1.amazonaws.com/dev/handler関数:main:tensorflow-dev-main APIをテストするには、リンクとして開くだけです:https://.execute-api.us-east-1.amazonaws.com/dev/handlerまたはcurl:curlを使用しますhttps://.execute-api.us-east-1.amazonaws.com/dev/handler
取得します:
{"return": "ジャイアントパンダ、パンダ、パンダクマ、クマ、Ailuropoda melanoleuca(スコア= 0.89107)"}
まとめ
サーバーレスフレームワークを使用して、AWSLambdaに基づくTensorflowモデルのAPIを作成しました。 私たちはすべてを非常に簡単に行うことができ、このアプローチは従来のアプローチと比較して多くの時間を節約しました。
設定ファイルを変更することで、ストリーム処理タスク用のSQSなど、他の多くのAWSサービスに接続したり、AWSLexを使用してチャットボットを作成したりできます。
参照:
- Image 1 – https://miro.medium.com/max/875/1*b6MXaZWwYJATdF6vw2Z8Hw.png
- 画像2-https://aws.amazon.com/blogs/machine-learning/deploy-deep-learning-models-on-amazon-ecs/
- 画像3-https://s3-us-west-2.amazonaws.com/assets.blog.serverless.com/tensorflow/serverless-tensorflow-architecture.png
- 画像4– https://upload.wikimedia.org/wikipedia/commons/thumb/0/0f/Grosser_Panda.JPG/330px-Grosser_Panda.JPG
この記事に示されているメディアは、Analytics Vidhyaが所有しておらず、作成者の裁量で使用されています。
関連記事
PlatoAi。 Web3の再考。 増幅されたデータインテリジェンス。
アクセスするには、ここをクリックしてください。