Copyright© LIFULL All Rights Reserved.
Kubernetesを利用した機械学習モデ
ルの本番適用例
株 式 会 社 L I F U L L
島 佑 介
Copyright© LIFULL All Rights Reserved.
島 佑介
2015年入社
マ ー ケ テ ィ ン グ の 部 署 で バ ッ ク エ ン ド を 実 装 し て い ま し た が 、
機 械 学 習 の 本 番 適 用 に 関 わ っ て み た い と 思 い 異 動 し ま し た 。
A P I の 実 装 や イ ン フ ラ 設 定 な ど を し て い ま す 。
技 術 メ モ : h t t p s : / / q i i t a . c o m / e l y u n i m 2 6
ポ エ ム : h t t p s : / / n o t e . c o m / e l y u n i m 2 6
自己紹介
Copyright© LIFULL All Rights Reserved.
目次 タイトルに関しての概要についてが記載されます。タイトルに関しての概要につ
いてが記載されます。
3.構成上のポイント
今回の施策の概要と全体感を説明します
2.施策と構成図
Kubernetesを使うにあたった経緯を説明します
1.導入
Copyright© LIFULL All Rights Reserved.
機械学習モデルを作った!
デプロイはどうする🤔
Copyright© LIFULL All Rights Reserved.
\SageMaker/
Copyright© LIFULL All Rights Reserved.
機械学習モデルをデプロイする際の最初の選択肢として
AWS SageMakerがあると思います
モデルのファイルとイメージをアップロードしてポチポチす
れば手軽にデプロイすることができます
手軽にやるならSageMaker
Copyright© LIFULL All Rights Reserved.
でも足りない場合もある
Copyright© LIFULL All Rights Reserved.
シンプルな要件であればSageMakerだけでも運用できますが、
バックエンドAPIを他に作りたくなる場合もあります
• 複数モデルへのリクエストを統合して1レスポンスで返す
• 別APIへのリクエストが必要で推論処理と切り分けたい
バックエンドAPIを別に作る
Copyright© LIFULL All Rights Reserved.
バックエンドAPIを運用するのであれば、モデルの運用も同じ
ように行いたいです
• 監視、ロギング
• CI/CD
• 構成管理の記述
バックエンドAPIを別に作る
Copyright© LIFULL All Rights Reserved.
• 内製ツール「KEEL」
• Kubernetesチームが開発、運用してくれてます
• AWS EC2上にKubernetesクラスタがある
• 主要サービスはほぼAWS上なのでGKEは使いづらい
• EKSは最新バージョンへの追従が遅くて小回りがきかないらしい
• HOME’S系の主要リポジトリは移行済み
LIFULLのKubernetes活用事情
Copyright© LIFULL All Rights Reserved.
• 1つの巨大クラスタによるスケールメリットの獲得
• k8s manifestをより簡易なYAMLから生成
• ロギング、監視、CI/CD等が簡単にできる
• IstioによるRate LimitやCircuit Breaker
• AWS CodeBuildとSpinnakerでデプロイ
• スポットインスタンスも使える
KEELでできること
Copyright© LIFULL All Rights Reserved.
物件リストページのおすすめ順最適化
• ユーザニーズに沿うように最適化
(すみませんが詳細は話せないです)
結果は良かったです
(これも細部は話せないです)
今回の施策
Copyright© LIFULL All Rights Reserved.
構成図
Copyright© LIFULL All Rights Reserved.
Copyright© LIFULL All Rights Reserved.
• モデルはAutoMLで作成
• 事前推論で値をSolrに入れておく
• フロントからはSolrにリクエストしてレコメンド取得
モデル概要
Copyright© LIFULL All Rights Reserved.
• BigQueryにあるユーザ行動データが入力
• 前処理でレアケースな物件を弾く
• (賃料/面積)が規定範囲外など
• 最適化するカラムをコンバージョンに設定
• 入力を採用するカラムを選ぶ
→細かいチューニング抜きにモデルが作れる 😆
AutoMLでのモデル作成
Copyright© LIFULL All Rights Reserved.
• 5つのモデルに並列アクセス
• 比較のために旧モデルも同時に動かす
• スポットインスタンスなので3割ほどのコストで運用できる
• 事前推論なので一時的に止まってても影響は無い
• オンデマンドとスポットを混ぜれば同時停止を回避できる(future work)
• 一括処理時はm5.4xlargeが数個動く
スポットの活用
Copyright© LIFULL All Rights Reserved.
• 非同期処理の扱いがしやすい
• 入力の型チェックの機構がある(Pydantic)
• Pydanticで記述した入出力定義からAPI仕様ページを自動生成
Fast APIでのAPI作成
Copyright© LIFULL All Rights Reserved.
• モデルはビルド時にコンテナイメージに格納
• ECRにモデル別のタグをつけて管理
• 問題があったらビルドで弾きたい
• イメージに全部入ってるので非常時の対応がシンプルになる
• モデルはそんなに頻繁に更新しない前提
• モデル変えるたびにmanifest変えないといけないのは課題(futurework)
モデルの格納方法
Copyright© LIFULL All Rights Reserved.
• コンテナ起動後にs3から取得する方法は採用しなかった
• オペミスでモデルの参照が違ったときが怖い
• 本番システムのSolrとつながってるので問題はなるべく起こしたくない
• モデルを頻繁に更新するのであればこの方法も含めて検討
モデルの格納方法
Copyright© LIFULL All Rights Reserved.
• KEEL用のYAMLを書くだけで設定が完了
• Istioの設定で同時接続数を制限
• podへのアクセスが多くなると即座にpodが503を返す
• Istioのリトライ設定でリトライされる
• 処理できるpodに回されて処理ができる
処理安定化のための取り組み
Copyright© LIFULL All Rights Reserved.
• S o l r の 一 括 ロ ー ド 時 に 一 気 に リ ク エ ス ト が 来 る
• 10000req/min程度
• 落ちないように敏感にスケールさせる
• c p u l i m i t は そ こ そ こ 大 き め
• 非同期処理なので負荷にばらつきがある
• ス ケ ー ル し き い 値 は 小 さ め
• スケールに失敗すると、非同期処理でCPU使用率が上がらないうちに連続
エラーや同時接続数でpodが退避されてスケールしないループに陥る
パフォーマンスチューニング
Copyright© LIFULL All Rights Reserved.
• AutoMLでさくっとモデルを作って、Kubernetesをwrapした社
内ツール「KEEL」で運用しています
• コストカットと安定運用を両立できています 😆
ご清聴ありがとうございました 🙇
まとめ
Copyright© LIFULL All Rights Reserved.
Appendix
私達と一緒に機械学習の本番導入を進めていく方を募集して
います
詳細はこちらをご覧ください
https://hrmos.co/pages/lifull/jobs/010-0041
We are hiring!!
Copyright© LIFULL All Rights Reserved.
再掲、構成図

【Ltech#11】Kubernetesを利用した機械学習モデルの本番適用例

  • 1.
    Copyright© LIFULL AllRights Reserved. Kubernetesを利用した機械学習モデ ルの本番適用例 株 式 会 社 L I F U L L 島 佑 介
  • 2.
    Copyright© LIFULL AllRights Reserved. 島 佑介 2015年入社 マ ー ケ テ ィ ン グ の 部 署 で バ ッ ク エ ン ド を 実 装 し て い ま し た が 、 機 械 学 習 の 本 番 適 用 に 関 わ っ て み た い と 思 い 異 動 し ま し た 。 A P I の 実 装 や イ ン フ ラ 設 定 な ど を し て い ま す 。 技 術 メ モ : h t t p s : / / q i i t a . c o m / e l y u n i m 2 6 ポ エ ム : h t t p s : / / n o t e . c o m / e l y u n i m 2 6 自己紹介
  • 3.
    Copyright© LIFULL AllRights Reserved. 目次 タイトルに関しての概要についてが記載されます。タイトルに関しての概要につ いてが記載されます。 3.構成上のポイント 今回の施策の概要と全体感を説明します 2.施策と構成図 Kubernetesを使うにあたった経緯を説明します 1.導入
  • 4.
    Copyright© LIFULL AllRights Reserved. 機械学習モデルを作った! デプロイはどうする🤔
  • 5.
    Copyright© LIFULL AllRights Reserved. \SageMaker/
  • 6.
    Copyright© LIFULL AllRights Reserved. 機械学習モデルをデプロイする際の最初の選択肢として AWS SageMakerがあると思います モデルのファイルとイメージをアップロードしてポチポチす れば手軽にデプロイすることができます 手軽にやるならSageMaker
  • 7.
    Copyright© LIFULL AllRights Reserved. でも足りない場合もある
  • 8.
    Copyright© LIFULL AllRights Reserved. シンプルな要件であればSageMakerだけでも運用できますが、 バックエンドAPIを他に作りたくなる場合もあります • 複数モデルへのリクエストを統合して1レスポンスで返す • 別APIへのリクエストが必要で推論処理と切り分けたい バックエンドAPIを別に作る
  • 9.
    Copyright© LIFULL AllRights Reserved. バックエンドAPIを運用するのであれば、モデルの運用も同じ ように行いたいです • 監視、ロギング • CI/CD • 構成管理の記述 バックエンドAPIを別に作る
  • 10.
    Copyright© LIFULL AllRights Reserved. • 内製ツール「KEEL」 • Kubernetesチームが開発、運用してくれてます • AWS EC2上にKubernetesクラスタがある • 主要サービスはほぼAWS上なのでGKEは使いづらい • EKSは最新バージョンへの追従が遅くて小回りがきかないらしい • HOME’S系の主要リポジトリは移行済み LIFULLのKubernetes活用事情
  • 11.
    Copyright© LIFULL AllRights Reserved. • 1つの巨大クラスタによるスケールメリットの獲得 • k8s manifestをより簡易なYAMLから生成 • ロギング、監視、CI/CD等が簡単にできる • IstioによるRate LimitやCircuit Breaker • AWS CodeBuildとSpinnakerでデプロイ • スポットインスタンスも使える KEELでできること
  • 12.
    Copyright© LIFULL AllRights Reserved. 物件リストページのおすすめ順最適化 • ユーザニーズに沿うように最適化 (すみませんが詳細は話せないです) 結果は良かったです (これも細部は話せないです) 今回の施策
  • 13.
    Copyright© LIFULL AllRights Reserved. 構成図
  • 14.
    Copyright© LIFULL AllRights Reserved.
  • 15.
    Copyright© LIFULL AllRights Reserved. • モデルはAutoMLで作成 • 事前推論で値をSolrに入れておく • フロントからはSolrにリクエストしてレコメンド取得 モデル概要
  • 16.
    Copyright© LIFULL AllRights Reserved. • BigQueryにあるユーザ行動データが入力 • 前処理でレアケースな物件を弾く • (賃料/面積)が規定範囲外など • 最適化するカラムをコンバージョンに設定 • 入力を採用するカラムを選ぶ →細かいチューニング抜きにモデルが作れる 😆 AutoMLでのモデル作成
  • 17.
    Copyright© LIFULL AllRights Reserved. • 5つのモデルに並列アクセス • 比較のために旧モデルも同時に動かす • スポットインスタンスなので3割ほどのコストで運用できる • 事前推論なので一時的に止まってても影響は無い • オンデマンドとスポットを混ぜれば同時停止を回避できる(future work) • 一括処理時はm5.4xlargeが数個動く スポットの活用
  • 18.
    Copyright© LIFULL AllRights Reserved. • 非同期処理の扱いがしやすい • 入力の型チェックの機構がある(Pydantic) • Pydanticで記述した入出力定義からAPI仕様ページを自動生成 Fast APIでのAPI作成
  • 19.
    Copyright© LIFULL AllRights Reserved. • モデルはビルド時にコンテナイメージに格納 • ECRにモデル別のタグをつけて管理 • 問題があったらビルドで弾きたい • イメージに全部入ってるので非常時の対応がシンプルになる • モデルはそんなに頻繁に更新しない前提 • モデル変えるたびにmanifest変えないといけないのは課題(futurework) モデルの格納方法
  • 20.
    Copyright© LIFULL AllRights Reserved. • コンテナ起動後にs3から取得する方法は採用しなかった • オペミスでモデルの参照が違ったときが怖い • 本番システムのSolrとつながってるので問題はなるべく起こしたくない • モデルを頻繁に更新するのであればこの方法も含めて検討 モデルの格納方法
  • 21.
    Copyright© LIFULL AllRights Reserved. • KEEL用のYAMLを書くだけで設定が完了 • Istioの設定で同時接続数を制限 • podへのアクセスが多くなると即座にpodが503を返す • Istioのリトライ設定でリトライされる • 処理できるpodに回されて処理ができる 処理安定化のための取り組み
  • 22.
    Copyright© LIFULL AllRights Reserved. • S o l r の 一 括 ロ ー ド 時 に 一 気 に リ ク エ ス ト が 来 る • 10000req/min程度 • 落ちないように敏感にスケールさせる • c p u l i m i t は そ こ そ こ 大 き め • 非同期処理なので負荷にばらつきがある • ス ケ ー ル し き い 値 は 小 さ め • スケールに失敗すると、非同期処理でCPU使用率が上がらないうちに連続 エラーや同時接続数でpodが退避されてスケールしないループに陥る パフォーマンスチューニング
  • 23.
    Copyright© LIFULL AllRights Reserved. • AutoMLでさくっとモデルを作って、Kubernetesをwrapした社 内ツール「KEEL」で運用しています • コストカットと安定運用を両立できています 😆 ご清聴ありがとうございました 🙇 まとめ
  • 24.
    Copyright© LIFULL AllRights Reserved. Appendix 私達と一緒に機械学習の本番導入を進めていく方を募集して います 詳細はこちらをご覧ください https://hrmos.co/pages/lifull/jobs/010-0041 We are hiring!!
  • 25.
    Copyright© LIFULL AllRights Reserved. 再掲、構成図