LoginSignup
28
22

More than 5 years have passed since last update.

機械学習使っても技術的負債を残しにくいAWSのインフラ構成

Last updated at Posted at 2018-04-09

はじめに

それでも機械学習を使いたい

googleの機械学習:技術的負債の高利子クレジットカード論文を読んで感銘を受けたので、ここのところ機械学習の恩恵に預かりつつ技術的負債の返済で死なない方法を考えていました。

昨今のAIブームの中、なんか分からんけど良い結果が出るので機械学習的システムを導入したはいいものの、保守・運用で馬鹿でかいコストを払っている会社は少なくないはずだと思います。
こんなに保守・運用でコストかかるなら、今後のシステムで機械学習使うのは慎重にならざるを得ないな・・・」と思い始めている人も多いかと思います。
それでもやっぱり機械学習は便利なので、これから新しいシステムやアプリケーションを作る際に「ガンガン機械学習使っていこう!」と言えるようなシステム構成を考えてみました。

この記事の目的・対象読者

記事の目的

立ち上げ期のWebアプリケーションに機械学習を組み込む際のAWSインフラパターンを共有すること

対象読者

  • これから機械学習を用いたWebアプリを作成する人
  • 技術的負債をできるだけ残したくない人
  • 保守・運用・拡張をできるだけ低コストで実現したい人

考えたアーキテクチャ

以下、作ってみた構成です。
ポイントは、「Main Application(メインアプリケーション)」と「Machine Learning System(機械学習システム)」に分かれているところです。
いわゆるフェイルソフトなんですが、今回は立ち上げの小規模チームでもフェイルソフトをするために必要な構成とはどんなものかを考えているところがポイントです。

Data friend architecture (3).png

アーキテクチャの説明

メインアプリケーション

ぶっちゃけここはできるエンジニアがいれば、どんな構成でも良いです。笑

が、Elastic Beanstalkを使うことによってインフラ構築と運用のコストを極力まで抑えています。
Elastic Beanstalkで構築するアプリケーションは、PythonでもRubyでもPHPでもOKです。
フレームワークも有名どころは一通り揃えているので、開発者の好き・得意で作れるのは良いですね。(自分はRailsが使えるのが神だと思いました。)

機械学習システム

LambdaAPI Gatewayを使うことによって、ほとんど「コード乗っけてハイおしまい」状態になります。
また、ここ最近で機械学習と言ったらほぼPython一択な雰囲気を感じますが、LambdaではPython2系、3系をカバーしているので、このあたりの実装で困ることはほぼないかと思います。
AWS Lambdaによるサーバーレスな機械学習APIの作り方 なんかが参考になります。
Lambda + API Gatewayの構成では面倒なスケーリングやモニタリング等は全てAWSに任せることができ、エンジニアやデータサイエンティストは本来の主業務である分析やモデルの磨き込みに時間を使うことができます。

予測などに使うモデルやベクトル値などを保存して置くためにサーバーを立てるのも面倒なのでフルマネージドなデータストアであるDyanamo DBを使っています。
あまりにもでかいモデルなどはS3などに保存していただければと思います。

メインアプリケーションと機械学習システムの繋ぎ方

今回示したインフラ構成の一番のキモです。
基本的にはAPI Gatewayを通してRESTなやり取りをします。

ポイントはAPIが死んでもアプリケーションは死なないようにすることです。
以下、具体的な例で確認していきます。

例1) 本のEコマース

Amazonのようなサービスを考えます。
メインアプリケーションは「顧客管理、本の購入」などの機能を担い、機械学習システムではユーザーの購入履歴に基づいたレコメンドを行うとします。
事前にレコメンド結果(APIのレスポンス)がどうであれば正常か異常かを事前に定めておき、異常であればレコメンド結果を表示しないようにしておきます。

さらに、検索結果を機械学習に基づいて並び替えたい場合も上記と同様に事前に「異常・正常」を定めて置くことで、APIのレスポンスがおかしな時はAPIの結果を無視することができます。

例2) ソーシャルネットワーキングサービス

FacebookのようなSNSを考えます。
Main Applicationは「友人と繋がる、近況の投稿、友人の近況閲覧」などの機能を担います。
そして機械学習システムではユーザー直近の行動に基づいた広告の表示を行うとします。
Main Applicationは、APIを通してユーザーの興味ある広告を取得しますが、もしこの時APIの挙動がおかしい場合は事前に準備しておいた別の方法(例えばルールベース)の代価手段を用いて広告を出すようにします。

さらに、ユーザーが好きそうな投稿を中心にタイムラインに並べたいとなった際は、タイムラインの並び替え機能など新たな機能をさくっとAPIに持たせてそこでやり取りさせるようにします。

おわりに

関わる人みんながハッピーなシステムを

機械学習でシステムを作ることができる人は世の中にたくさんいますが、作った後に運用したり保守したりする人がいるということまできちんと考えてシステムを作れる人はどれだけいるでしょうか。
エンドユーザーがハッピーになるからといってやたら高度な機能を作りまくって、考えなしに高利子なシステムを本番環境に乗っけてはならないと思っております。
システムと人は良い関係でありたいですねー。

上記の構成は自分が個人的に運営しているサイトで使っています。
今のところ問題は起こっていないので、引き続き運用してみようと思います。

注意

クラウドサービスに関する体型的知識を持たないまま書いてしまったので、間違っている部分があるかと思っています。
間違い等ありましたら、ご指摘いただけると嬉しいです。

それから、AWS等のクラウドサービスでアーキテクチャ考えてる人いたら情報交換したいです!

余力があれば、次回はこのインフラ構成を実際にAWSで作る記事を書こうかと思います(意外にハマりポイントあったので)。

28
22
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
28
22