【レポート】AWS Summit Tokyo 2017：クックパッドの機械学習を支える基盤のつくりかた #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『クックパッドの機械学習を支える基盤のつくりかた』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通り。

セッションレポート

• クックパッド
• 17言語、62カ国に対応
• 2011年にDCから完全移行
• ap-northeast1/us-east-1を主に使用

クックパッドの機械学習基盤

背景

• 研究開発部がある
• 2016年7月発足
• 機械学習を中心に食文化系の研究における実績も
• 去年の12月に「料理きろく」を公開
  • アプリのユーザのスマートフォンの写真の内料理の写真のみを自動的に収集・記録する

アーキテクチャ

• 画像のアップロード、判定処理には時間がかかる(〜数百ms)
  • APIサーバと統合して同期処理するのは非現実的 => 非同期処理を行う
• アプリサーバと必要な計算機環境が異なる => 判定処理は自由な環境にしてあげることが必要

SQSとS3を介した非同期処理

• クライアントからPre-SIgned URLの発行をアプリにリクエスト
• 判定用画像をアップ
• イベントをSQSにEnqueue(バケットとkeyのみ)
• 判定用のワーカーはECS Clusterで構成
• ECSはSQSをポーリングしている
• パスを拾ってS3からダウンロード、判定結果をAPI越しに伝える

SQSのCloudWatchメトリクスに基づいたアラーム

• 日次バッチではなく1時間以内という要件がある
• SQSのメトリクス「ApproximateAgeOfOldestMessage(どれくらい待たされてるか)」をCloudWatchで取る
• 待たされてる時間によってECSをスケールアウト

ECS上での写真判定

• eagletmt/hakoを利用
  • yaml型式のファイルで判定処理workerを定義、CLIコマンドで立ち上げる
  • オートスケールの設定もhakoで出来る
• 写真反転にGPUを使っている。G2タイプのインスタンスを使用。
  • GPUアクセラレーションを使うことでCPUインスタンスに比べて4-5倍の性能差

コンテナからGPUを操作するために必要な設定

• NVIDIA Driverのインストール
  • クラスタにドライバをインストールしてTaskからはvolumeで見る
• privilegedオプションを使う
  • privilegedなTaskのrootユーザは強い権限を持つ
  • "--device"オプションが使えない
  • コンテナの中でrootじゃないユーザで動かす
• クラスタ上のドライバが見えなくなる
  • クラスタと同じバージョンのLibraryをコンテナにインストールする
  • コンテナのバージョンが依存
• 結果、10万人以上のユーザに利用され、420万以上の料理写真がアップされている
• 画像認識モデルを一度アップデートしている

機械学習基盤について

• 研究開発部が周りを気にせずに自由に手を動かせる場所
  • 本番環境と切り離している

背景

• 研究開発部の設立当初は依頼を受けてそれをもとにインフラ部が必要なリソースを準備していた
• 本番環境と同様の環境
• AWSの管理体制はインフラ部が全権限を持っていた
• コード化されている箇所も"実行"はインフラ部が担当していた

起きた問題

• リソースの用意が追いつかない
• 本番に比べて研究開発は優先度が下がる
• 本番環境で行っていた運用に合わない
• 対象のミドルウェアを把握している前提で設定をコード化したりする。機械学習環境はドライバのインストール等自動化が難しい。
• 研究開発は手探りが増える。 => たくさん手を動かしたい。試行錯誤したい。 => 中央管理の限界(インフラ部がボトルネックに)
• そもそもAWSの利点をいかせていないのでは、という疑問
• 本来やるべきことに時間を使えるようにしたい

管理方針の転換

• 権限と責任を各開発者に移譲するようにシフト
• 管理すべき部分は押さえておく

自由な環境のために必要なもの

• メンバーが自由に触れられる環境: アカウントの分離
• 研究開発用のAWSアカウントを作成してそちらを使う
• 支払は本番環境のアカウントにまとめる（コンソリ)
• 権限管理: 本番環境はIAM Userを発行していた => そこからAssume Roleする
• CloudTrailやConfigを有効にし、アウトプット先を権限を制限したS3に
• 開発者に権限を渡すが改竄不可能な形でトレースする

ネットワーク構成

• インスタンスへの侵入からの事故を防ぐ
• 踏み台サーバがあるVPCからVPC Peeringで接続
• 管理系のVPCの中にゲートウェイを用意、そこから本番環境VPC、研究開発VPCへアカウントをまたいでPeering

セキュリティグループの監視

• Config Rulesでセキュリティグループの開放をチェック
• AWS提供のfunctionレポジトリからLambda functionを作ってチェック
• 細かいAPIはCloudTrailから

予算管理

• Billing Consoleで抵抗されているBudgetsを利用
• 予算を超えそう、予算のN割を使った場合にSNS Notificationをあげる

AWSに関する相談、ノウハウ

• 今まではインフラ部が持っていた
  • ノウハウが共有できない
  • 本来自分たちが説かなくてもいい問題に時間を使っていた
• エンタープライズサポートへの移行: TAMアサイン、ケース対応の時間短縮 => 応答の品質が上がり、解決までの時間が短くなった
  • Auroraなど勢いのあるプロダクトを使う時は地味に効いてくる
  • 開発者が自由にケースをあげるように
  • TAMアサインによりコンテキスト共有がしやすくなった
  • 上限緩和制限が爆速に(体感で3,4分)
  • AWS管理運用で地味にかかっていたコストがかなり下がった

現状

• 意図通り活発に利用されている
• 新サービスの開発
• 新しい機械学習モデルのテスト、改善

(GPU)計算機環境

• GPUインスタンス(G2,P2)の利用
  • 深層学習系のタスクではGPUインスタンスを利用したい
• 素のAMIにプロビジョニングツールで自動環境構築をしてみた => ドライバのインストール等は時間がかかる
  • Packerを利用してバージョンごとにプロビジョニング済みAMIを作成・管理

インスタンスの利用方法

• 他の開発者と同時には利用しづらい
  • 個人ごとに専有インスタンスを用意
• インスタンスの落とし忘れ
  • 利用単価の高いインスタンスについてアイドル状態を監視
  • Lambdaをスケジュールで立ち上げてインスタンスを監視(3時間ごと)
  • アイドルなインスタンスについてSlackに警告
• ChatBotによるインスタンスの操作

まとめ

• 機械学習の力を確かめながら素早く手を動かしサービスを作る為に自由な環境を用意
• その自由な環境をつかって研究開発を進め「料理きろく」をリリース

まとめ

やはり実際に起きた課題とその解決法の発表は迫力が違います。前半のアプリのアーキテクチャはトライアンドエラーの結果となるいいTipsが沢山あり、後半の環境づくりは組織としてのAWS運用のヒントになる、大変勉強になるセッションでした。