機械学習ライブラリを使ったPredictなAPI開発
WebサービスでAIを活用する場合、多くはmicroservices的にVPC内にAPIを独立してデプロイし、インターナルに利用することが増えてきた。ことChainerやTensorflowといった機械学習系のライブラリは、その歴史的背景や数学ライブラリからPythonと相性がよいため、必然的にPythonのWAFを選択することになる。
pythonでmicroservicesなAPIでのWAF
PythonでWebアプリケーションを開発するには、WAFとしてDjango,Flaskの二大巨頭が台頭しているが、概ねシンプルな推論のAPI開発にDjangoは大して冗長であって、Flask辺りがつかっていて小気味良い。
マルチスレッドにおけるモデルデータの参照問題
Tensorflowにしろ、Chainerにしろ、APIでの推論は、機械学習の成果として得られるモデルの読み込みが必要になる。
Tensorflow + Keras では、 サーバ起動時に事前にモデルをメモリに展開し、グラフを構築しておく。リクエスト時にはそれを利用する形になる。
この時、マルチスレッドで動作していると、構築されたグラフのスレッドとは別のスレッドでリクエストを受け付けることになるので、グラフをスレッド間で共有する必要がある
global thread:
self.model = load_model(model_path)
self.model._make_predict_function()
self.graph = tf.get_default_graph()
another thread:
with self.graph.as_default():
labels = self.model.predict(data)
サーバレスアーキテクチャにおけるTensorflowの利用
昨今流行りのサーバレスであるが、GCP Cloudfunctionはそもそもnodejsしか使えないので除外、 AWS Lambdaが選択肢となる。
Tensorflowガンガン肥大していくが、学習はともかく認識時に必要最低限のモジュールだけを切り出したい
— ふわこ (@yurfuwa ) 2017年11月8日
このようなニーズがある。しかしAWS Lambdaには 50MB制限というのがあり、ひとつのLambda関数においての容量制限が厳しい。
ServerlessでTensorflowやろうと躍起になってたんですが、tensorflowどころかnumpyやらscipyやらが既に重すぎてaws lambdaで死ぬし、.soをstripしたり.pyc消しても焼け石に水だった
— ふわこ (@yurfuwa ) 2017年10月26日
素直にサーバーレスは諦めて、GCP AppEngineあたりで手を打つのが打倒っぽい。
AWSさん、なんとかなりませんか、これ。
Top comments (1)