はじめに
こんにちは、CTOの今村です。
先日弊社のiQONが3年連続でGoogle Play「2016年ベストアプリ」に選ばれました。また、今回ベストイノベーティブ部門の大賞を受賞しました。
イノベーティブ部門ということなので、Androidアプリの品質だけでなく、アプリの中にある様々な機能の技術的な取り組みも評価してもらった背景があるのかなと個人的には感じています。
さて、ちょうど先日Minami Aoyama Night #1にて、弊社のデータまわりのアーキテクチャについてお話させていただく機会がありました。
今回は2016年12月時点での、機械学習とデータ分析を支えるAWSとGCPを利用したマルチクラウドアーキテクチャについて紹介したいと思います。
最近のデータまわりの取り組み
今年になってからVASILYは過去のテックブログでも紹介したように、データまわりの取り組みを一層強化しています。
機械学習関連の事例
ユーザーの好みに応じたレコメンドエンジン
iQONにはfor Youというユーザーの好みを学習してアイテムを推薦する機能があります。
ここにも機械学習やディープラーニングが取り入れられています。
VAEとGANを活用したファッションアイテム検索システム
IBIS2016で弊社が発表した、VAEとGANを応用したファッションアイテム検索システムです。 例えば元画像のワンピースの形を保ったまま、色の違うワンピースなどを検索することができます。 http://tech.vasily.jp/entry/retrieval_using_vae_gan
ディープラーニングによるファッションアイテム検出と検索
最近では似たような取り組みをしている事例もちらほら出てきていますが、精度の面ではかなりの高さを誇っています。 http://tech.vasily.jp/entry/detection_and_retrieval
ディープラーニングを活用して画像から商品カテゴリを判定する
http://tech.vasily.jp/entry/deepleaning_microservice 弊社の強みであるクローラーの部分でももちろんディープラーニングは活用しています。 画像からカテゴリを判定して、自動的にアイテムを分類することでメタデータからだけでは分類しづらいようなアイテムにも対応しています。
このように機械学習関連やディープラーニング関連だけでも様々なことに取り組んでおり、実際のサービスへと展開しています。
マルチクラウドの基本方針
主にAWSをサービスのメインインフラとして、GCPをデータ分析/計算のインフラとして利用しています。マルチクラウドと言っていますが、実際はオンプレ環境も利用しています。
基本的な方針としては以下の通りです。
- AWSでできることはAWSでやる
- Pythonを用いたり、Spark(DataProc)を扱ったり、大量の計算を扱う部分はGCPでやる
- GPUなどクラウドでの値段が高くて、検証中にリソースを常時大量消費するものはオンプレ
- 最終的な計算済結果はRedisに保存して、WebAPIから高速に呼び出せるようにする
- 各クラウド間の実装はBigQueryを中心として疎結合を意識する
例えば類似アイテム画像APIのアーキテクチャは以下のようになっています。
機械学習を支えるアーキテクチャ
類似アイテム画像APIのアーキテクチャ
こちらはあるアイテムに似ているアイテムを表示する類似アイテム画像APIの例になります。
まず、データ生成には3つのステップが存在しています。そして、それぞれのステップをそれぞれ異なる基盤で行っています。 もう少し詳しくしたのが以下の図です。
まず、オンプレ環境で大量の画像の特徴量抽出を行います。ここはGPUの真価が発揮されるところであり、リソースを大量に消費する部分です。特徴量抽出を行うべき画像のリストなどをBigQueryから取得し、画像をダウンロードして、処理を行います。処理を行って得た特徴量はBigQueryに保存します。
次にGCP内のBatchにて、BigQueryに保存した特徴量を取得し、Pythonで類似度の計算を行います。計算した類似度の結果は再度BigQueryに保存します。
次にAWSにてBatch処理で、BigQueryから計算済の類似アイテムのリストを取得し、APIから参照するRedisに保存します。 あとはアプリケーション側からそのRedisを参照することによって、高速に類似アイテムを表示することができます。
上記の3ステップの中心となる存在はご覧の通りBigQueryです。このようなシステムを組む場合、リトライや冪等性を意識した仕組みにする必要性があったり、ジョブの関連性が複雑になったりしがちですが、それぞれの基盤からBigQueryを介することによって、システム全体としての結合度を下げて運用しやすくしています。
タスク制御
それぞれの基盤でバッチ処理を安全に運用するためにはワークフローマネージャーは必須といえます。弊社では、主に以下の2つの製品を利用しています。
AirFlow
弊社ではAirFlowをメインのワークフローマネージャーとして使っています。運用して約1年ほどになりますが、今のところ問題なく動いています。もともとはAirbnb社が開発したものですが、3月にApache IncubatorのOSSになっています。
Luigi
最近ではSpotify社が開発したLuigiも使い始めました。Airflowは高機能すぎるため、シンプルにジョブ制御を行いたい場合に利用しています。
データ分析を支えるアーキテクチャ
次にデータ分析を支えるアーキテクチャの紹介です。
施策の数値確認やダッシュボード
弊社では、アプリ内行動ログやユーザーデータの分析などあらゆるデータの分析を常に行っています。 現在上図のようなビューが約300以上存在し、様々な施策のKPIを日々確認しています。 いくつかの重要なビューは、レンダリングされたグラフとともにSlackの全体チャンネルに日々自動的に共有されるようになっています。
ログデータまわりのアーキテクチャ
アプリ内行動ログや、マスターデータ、あらゆるログデータ関しては、全てBigQueryに保存しています。
アプリ内行動ログの取得にはAndroidはCookpad社製のPuree、iOSは独自のSDK(Yabaimo)を用いています。 ログを待ち受けるサーバー部分は自分達でサーバーを用意してfluentd経由でBigQueryに保存しています。昔はLocalyticsを使っていたのですがサポート面の遅さや料金の問題もあり、今は利用していません。
どのBIツールがいいのか？
最近はGoogle Data Studio、re:dash、superset、など様々なBIツールが登場してきており、どれを採用していいか迷うことが多いかと思います。
上記の表は2016年12月時点での弊社の独自の調査に基づくものです。
Tableu Desktop + Tableau Server
弊社ではデータ分析にはTableau Desktop + Tableau Serverの組み合わせを使っています。
高度な分析を必要とするデータサイエンティストやエンジニアにはTableau Desktop、さらに彼らが作ったダッシュボードを他の職種の人たちに共有して閲覧できるようにTableau Serverを利用しています。データサイエンティスト以外の人たちは、Tableau Server経由で共有されたKPIやダッシュボードを閲覧します。
最近は無料のものから有料のものまで、様々なBIツールが登場していますが、BIツールを選ぶ際に重要視していることは、BigQueryに対応していることとツール自体にバグがないことです。重要指標を多く含むため、ツール自体にバグがあって数値がうまく表示されなかったりすると誤った判断をしてしまうかもしれない為、安定性を重要視しています。安定性の観点ではTableauはサポートも充実しており、弊社環境でしか起こらないようなバグなども全て対応してもらっています。
まとめ
上記をまとめたものを以下のスライドにしてありますので、ぜひ御覧ください。
現時点ではAWSやGCPもそれぞれのプラットフォームで得意なものが違うので、 うまく使いこなして、運用負荷とコストを削減していくのが今のところベストなソリューションかなと感じています。 また、今はAWSとGCPを主に利用していますが、AzureにもGPUインスタンスが登場しましたし、 今後はAzureの検証も進めていければと思います。
総括になりますが、今年はVASILYとして、弊社の持つ膨大な量のファッションのデータを使った取り組みを色々と強化することができました。 来年も引き続き、機械学習や深層学習をはじめとするAI分野に投資をしていきたいと思います。
データを使って面白いことがしてみたい、研究もしたいし、プロダクトに自分の技術を使ってユーザーに価値を届けてみたい、そんな気持ちを持っているデータサイエンティストの方々、ぜひご応募お待ちしています。
