データプラットフォームチームの野本です。機械学習基盤の構築やその周辺アプリケーションの実装を行っています。以前は DOOR 賃貸の開発運用をしていてこんなことなどしてました。
機械学習システム運用の課題
リブセンスでは 2014 年ごろから機械学習システムの開発導入を行っており以降様々な機械学習システムを各サービスに導入してきました。また自社でのデータ分析基盤の運用も行うようになってから機械学習システムの開発の幅が広がり導入の要望も次第に増えてきました。(参考:リブセンスのデータ専門組織のこれまでとこれから)
当初は機械学習システムに対する運用知見などが少なかったため、専用のインフラというものは保持せず各サービスのインフラに相乗りし、サービスのアプリケーションと密に連携し機械学習システムを実装運用することが多かったです。各サービスは元々オンプレミスで運用されていたものが多かったのですが、現在は AWS などクラウド環境への移行を行ったり新規サービスは最初からクラウドを利用したりと各サービスのインフラは多様になってきています。 また、機械学習システム自体の数も増えており、次第に以下のような課題が顕著になってきました。
- 導入するサービスのインフラに依存しがちになる
- 利用したい言語 / ライブラリに制限
- マシンリソースの制限
- 似たようなシステムの複数サービスへの導入
- 同じような実装が色々なところにちらばる
- 運用コストが増える
- 機械学習エンジニアが機械学習の実装以外のことにリソースを取られることがある
- デプロイ作業
- 各サービスのインフラ上でのオペレーション / 調査
これらの課題を解決するため、また運用の知見やノウハウも蓄積されてきたこともあり機械学習基盤を構築することとなりました。
機械学習基盤の構築
マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化でも触れていますが、GCP / GKE 上にコンテナを利用した機械学習基盤の構築を進めています。 現状のシステム概要図は以下です。
ざっくりとした概要図ですが、以下にその目的と全てではないですが実際にどのよう構成になっているかを簡単に解説をしていきます。
柔軟な機械学習システムの開発 / 検証 / 運用を目指す
今までの運用から、機械学習システムの開発において次のような課題解決の実現を目指しました。
- 利用言語 / ライブラリの柔軟な選択
- その為のプロビジョニング負荷の軽減
- 開発者のローカル環境と本番の差異をなくす
- モデルのアルゴリズム / パラメータを繰り返し調整しながら開発が出来る環境
- 計算リソースの柔軟な確保
- 本番同等の検証環境
これらを実現するのには現在はやはり Docker のようなコンテナを利用するのがベターであると考え、それを運用する環境として Kubernetes を採用することとしました。
Kubernetes の利用
Kubernetes の機能の詳細の紹介はここでは省きますが、Kubernetes を選んだ理由は次のようなものが上げられます。
- ほぼ全ての設定をコード化 (yaml) 出来る
- 開発 / 本番ごとに共通の設定で環境を構築出来る
- デプロイ / ロールバックを素早く行える
- クラスタ内の各 Pod / Service の連携が楽
- ConfigMap / Secrets を利用して設定を共通化出来る
- CronJob により簡易にバッチを運用出来る
実際に利用してみると Kubernetes 上でのコンテナのデプロイは本当に簡単/柔軟に行え、これであれば柔軟な機械学習システムの開発に十分活用出来ると思い採用に至りました。
GCP / GKE の採用
Kubernetes を運用する環境としては GCP / GKE を採用しました。
現在の機械学習基盤構築チームの前提として
- 現状機械学習基盤には専任のインフラエンジニアがいない
- アプリケーションや機械学習システムの開発運用も並行して行っている
といった状況で、出来るだけインフラ管理のコストがかからない GKE のようなマネージドサービスの利用が理想です。
他にも以下のような GCP 利用のメリットがあります。
- リブセンスでは Google Apps を利用しているので Google のアカウント連携が出来る
- 組織を GCP のリソース階層にマッピングする のような管理を行える
- GCE インスタンスの起動が速い
- GKE の Stackdriver Logging との連携が便利
- タグによるネットワークのルーティングが便利
- Identity-Aware Proxy によるアプリケーションの認証
今回は 0 からの構築のため大規模な移行などのような状況よりも選択の自由度が大きかったこともあり GCP / GKE を全面的に利用することに大きな障壁はあまりなかったので採用出来ました。
コンテナレジストリ
リリース前の検証クラスタも構築しており、本番と同等のコンテナ / Kubernetes の設定を検証出来るようになっています。 Docker のレジストリには GCR (Google Container Registry) を利用しています。 GCR はそれ専用の独立した GCP プロジェクトで運用しており、本番 / 検証プロジェクト双方からアクセス出来るようになっています。 またコンテナのビルドには Container Builder を利用しており、基本的に GitHub 上のリポジトリで master へのマージが行われた際にビルドするようになっています。
helm / デプロイ
Kubernetes の設定は最初は標準の yaml で行っていましたが現在は helm を利用しています。 helm にすることにより、検証 / 本番環境の設定の切り替えが容易に行えます。 またデプロイは担当のエンジニアがまだ小人数であることもあり、各エンジニアのローカルマシンから行っています。 より多くのエンジニアがこの基盤を利用し始める場合には学習コストがそれなりにあったり不慮の事故にもつながるので今後改善すべき課題と思っています。
ちなみに手元で kubectl を操作する時 auto completion を使うととても便利です。
CronJob
CronJob は Kubernetes で提供されている機能で、いわゆる crontab の機能を Kubernetes 上で実現出来るものです。 現状稼動しているシステムはほぼバッチであり、その運用を考えた時フローがさほど複雑でないバッチの実行にワークフローエンジンのようなものの運用を行わないで CronJob を利用出来るのはとても便利です。 基盤の構築開始時には alpha クラスタのみでしか利用出来なく、実際に利用出来るようになるまでは crond で kubectl exec などをスケジュール実行するような簡易的なコンテナを作成して対応していましたが現在は CronJob に置き換えています。
データ分析基盤の活用
今までもブログなどで繰り返し紹介していますが、リブセンスでは自社でデータ分析基盤を構築運用しています。 データ分析基盤は AWS 上に構築していて、各サービスの各種ログはこの基盤上に構築している AWS Redshift に集約して保持しています。 各サービスの開発者 / 運用者は日常的にこのデータを使ってサイト性能などを分析しており、既存の機械学習システムも基本的にはこのデータを元に実装しています。 なので、機械学習基盤からも手軽にこの Redshift にアクセス出来る必要があるのですが、データ周りのことはこのデータ分析基盤を中心に考えることによりむしろ機械学習基盤の構築にフォーカスを絞ることが出来ます。
現在は機械学習基盤からの接続は Pgpool をプロキシとして利用し Redshift にアクセスするように構築しています。
- Redshift へのアクセス許可を固定 IP で行う
- 各コンテナからは Pgpool の URL でアクセス
- ロードバランサを利用した冗長構成も取りやすい
- 現在は利用していないが、必要であればクエリキャッシュも導入出来る
- GCE での運用ではあるが、Container-Optimized OS を利用し Pgpool をコンテナ化して運用している
データ分析基盤の活用の現状と今後は以下のように考えています。
- データが AWS 上に保持、計算は GCP 上で処理となっているが、現状バッチがメインなので転送コストやレイテンシは今のところそれほど問題ではない
- リアルタイム性が必要になるなど機械学習固有の要求が発生するようなログ収集は機械学習基盤側で構築していくかもしれない
- 各サービスのログ以外のデータも一部データ分析基盤には取り込まれているのでそれを利用出来る
- 存在しないデータが出てきた時のために embulk を利用した取り込みも行えるようにはなっている
まとめ
よかったところ
- Docker / Kubernetes の利用によるデプロイの早さ / 容易さ
- Docker を利用することでアプリケーション個別のプロビジョニングがほぼ必要ない
- コンテナ化 / helm による設定により環境のコード化を強制出来る
- どのような環境を構築するのかが分かりやすい
- 検証環境 / 本番での差異が出にくい
- GCP の各サービスの活用も視野に入れやすい
- Flexible Environment になり便利になった GAE の活用
- データ分析基盤で補えないログに対する BigQuery の活用
- ML 系サービスの活用
今後やっていきたいこと
- CI / CD の確立
- 出来るだけ Kubernetes のことを知らないエンジニアでも利用出来るように
- 出来るだけ機械学習システムの開発フローに寄り添ったものに
- Spinnaker などのツールも検証中
- 計算リソースの柔軟なスケーリング
- 機械学習にはつきものの潤沢な計算リソースの分配を手軽に
- GPU の利用も機会があれば
- 機械学習固有の問題解決
- モデルの精度監視環境の構築
- オンラインシステムの構築
- などなど
機械学習基盤の構築はまだ始まったばかりで現状は既存のシステムの移行を行いながらこれら基盤の構築を進めているという現状です。変化のとても速い Kubernetes 周辺技術を適切に取り込んでいくとともに、基盤上で新たなシステムを実装しながらより柔軟な基盤を作っていければと思っています。(半年後には全然違う構成になってるかもしれません。)また、今後この基盤上で実装していく個別の機械学習システムに関しても紹介出来ればと思います。