「ユーザーにとって本質的に価値があること（同社では「マジ価値」と呼ばれる）を届けきる」をコミットメントとして掲げる同社の、AI技術を使ったアプローチ方法を連載形式でお届けする。
第3回のテーマは、機械学習の開発環境。
機械学習やディープラーニングの自社開発を続けるうえで、その開発環境について考えるべき事項は多い。データ基盤の開発に始まり、分析やモデル開発、運用までスムースにこなせることに加えて、さまざまなアプリケーションやデータベースとの接続といった部分への配慮も欠かせない。
今回はfreeeの機械学習開発・研究を支えるインフラ基盤とその仕組みを同社AIラボの田中浩之氏に紹介いただく。
freeeでは「スモールビジネスを、世界の主役に。」をミッションに掲げ、「アイデアやパッションやスキルがあればだれでも、ビジネスを強くスマートに育てられるプラットフォーム」の実現を目指してサービスの開発および提供をしています。
今回は、freeeではどのように機械学習を使ったサービスを研究開発し、実際に運用を行っているのか、主にインフラ面についてご紹介していきます。
何故MLOpsをやるのか？
近年、DevOpsというワードをよく目にするようになりました。freeeでもユーザーに価値をいかに早く届けていくかというテーマは重要な課題の1つであり、スクラムなどのアジャイル開発への取り組みを継続的に行っています（詳しくは弊社記事1，2，3をご参照ください）。
我々は機械学習に関連するサービスの研究・開発もソフトウェア・エンジニアリングの延長線上にあると考えており、組織面、システム面の両面から日々改善を行っています。最近ではMLOpsといった概念も定着しつつあり、大手クラウドベンダーなどはMLOpsを支えるための関連サービスを矢継ぎ早に打ち出すなど盛り上がりを見せています。
我々がMLOpsを推進する主な目的としては以下の3つがあります：
- 研究開発リードタイム（Research → Product）の短縮・実験サイクルの短縮
- ガバナンスの強化
- セキュリティの担保
1.のリードタイム短縮・実験サイクル短縮については比較的想像しやすいかと思います。NetflixではMetaflowというデータサイエンティスト向けのツールを整備することで、プロジェクトを開始してからサービスに組み込むまで、従来では数ヶ月を要するような工程を1週間程度で行えるようになった、と発表しています。
2.のガバナンス強化は、チームメンバーが変わったり、時間が経つなどしてさまざまな負債化が起こりづらくする仕組みを入れていくことです。「あのプロダクトの学習データどこいったっけ？」や「最近学習やり直したらエラー出まくりで辛い」といったような事態を抑制します。モデルの管理やコードの管理を行ってバージョンの切り戻しを行えるようにする、といった運用面の事柄も含まれます。
3.のセキュリティに関しては、仕事内容として種々のデータを扱う特性上、盗難やマルウェア・ウイルス感染などによる情報漏えいリスクを下げるために、ローカルの開発マシン上にデータを置かないようにしています。
弊社ではデータの種別に応じてセキュリティレベルが定義されており、一定レベル以上のデータはローカルPC上にダウンロードしてはいけない決まりになっています。システム的にアクセス制御を行っていますが、PC盗難やマルウェア感染などのリスクやヒューマンエラーが生じる恐れもあります。
そのため、情報が機微であるかに関わらず業務で使用するデータはAWS上に置くようにし、決してそこから出ていかないような仕組みを整えています。CSIRTというセキュリティの専門チームと協力してAWS上でのセキュリティを高める仕組みも日々アップデートしています。
次節から、より具体的にAIラボで運用しているインフラ基盤について解説していきます。
機械学習基盤の全体像
AIラボはここ1年ほどで全てのインフラをKubernetes上に移行しました。上記画像が大まかなインフラ構成となります。freeeでは全社的にKubernetesを活用する動きがあり、AIラボでもそれに沿った形で開発を進めています。
図の右側のProduction EKS（Elastic Kubernetes Service）クラスターはクラウド会計ソフトfreee（以下、会計freee）などの各種サービスで利用される推論マイクロサービスをデプロイするクラスターで、いわゆる「本番環境」といわれるものです（他にもステージング環境などもありますが図からは割愛）。
図の左側の学習基盤EKSは、AIラボのメンバーがデータの検証やプロトタイピング、モデル開発といった全ての開発作業が可能になるように色々なツールが入っているクラスターです。こちらは本番環境とは違う学習基盤用の独立したVPC内に構築されています。ここで作ったモデルを内包した推論コンテナイメージをECRに登録し、右側の本番環境にデプロイします。
モデルをイメージに含めるか否かについては、モデルサイズが大きくなってしまうというデメリットよりも、バージョン管理など運用が楽になるというメリットを考えて含めるようにしています。なにか問題があった場合でもデプロイするコンテナイメージのバージョンを戻すことですぐにモデルごと元に戻すことができます。
学習や分析に用いるデータはAmazon AthenaやRedshiftからクエリを介して取得したり、S3上から直接取得したりします。プロダクトのデータなどはデータを分析しやすくする基盤を整えるチームがおり、データを一元化して提供してもらえているため、我々はそこにあるデータを取ってくるだけで良い状態になっています。
本番環境のクラスターについては全社的に運用整備がなされているため、GitHubにPull Requestを作成してコメント欄にコマンドを発行する事で簡単にデプロイが行える仕組みが整っています。
GitOpsでクラスタにデプロイしているところ
学習基盤
現時点での学習基盤は以下の主な機能を提供しています：
- KubeflowによるJupyter Notebook serverの提供
- CoderがOSSとして提供しているcode-serverを使ったクラウドVisual Studio Code環境
- Apache Airflowを用いたパイプライン管理
- 独自のリモートジョブ実行ツール
Kubeflow
Kubeflowは機械学習ワークフローをKubernetes上で実行する際に利用できるさまざまな機能を提供するツールキットです。先日初のメジャーリリースとなるv1.0がリリースされました。まだアルファやベータな機能が多いですが、AI-Labでは先行的に半年ほど前から試験的に導入して部分的に活用しています。
Kubeflowは多様なツールが内包されており、パイプライン機能やTensorflow/PyTorchでの分散学習機能、ハイパーパラメータチューニングなどさまざまな機能がついていますが、AIラボではIstioなどのネットワーク周りの設定とJupyter Notebook Serverの管理機能を主に使用しています。
Jupyter Notebook ServerはWebUI上から簡単に作成して立ち上げることができるようになっています。基本の使い方として、各メンバーが自分用のNotebook Serverを1つ立ち上げて普段の開発用のコンピューティングリソースとして使い、GPUを使いたい場合などの必要に応じて一時的に追加のサーバーを立ち上げて利用するスタイルをとっています。
簡単にNotebook Serverを作る事ができる。実体はPod
このJupyter Notebook Serverの実体はKubernetesのPod*として動いており、メンバーが開発作業をする時の仮想マシンとして利用しています。ディスクもHOMEにマウントされているので、通常の仮想マシンと同じような感覚で利用することができます（ただし、apt-getなどでパッケージをインストールしても再起動すると元に戻る）。
*Pod：KubernetesでDockerコンテナを管理するための最小単位
さらに、Amazon EFSをNFSストレージとしてマウントしているので、チームでデータを共有したり、万が一クラスターが消失しても作業中のデータは消えないようにしています。Notebook Serverはカスタムイメージを利用することができるため、自分たちで環境をカスタマイズしたコンテナを使っています。
また、開発を行うためにはエディタやターミナルも必要になってきます。Jupyter Notebookにも簡単なエディタやターミナル機能もついていますが、やはり物足りないので、Pod内にcode-serverを立ち上げ、ブラウザ上でVisual Studio Code（実際はほぼ同じもの）が立ち上がるようにしています。これがあるとグッとローカルでの開発環境に近づいてくるのでおすすめです。ターミナルはVS Code(code-server)のターミナル機能を使っています。
普段の開発作業はブラウザ上で完結。Notebookとエディタ・ターミナルを行き来している
Apache Airflow
前述のJupyter Notebook Serverを使って普段のコーディングや初期実験・評価を行った後は、モデル作成の再現性を担保したり、モデル改善のイテレーションを回す効率を上げるために、実験時の作業を一連のデータ・学習処理にまとめてプロダクションで利用できる形にまとめます。また、コードを一箇所にまとめることで負債化を抑制する効果も期待できます。
データ処理・学習パイプラインの構築にはAirflowを採用しています。当初はKubeflow Pipelinesを採用しようと思っていたのですが、パイプラインの実行の仕方を定義するDAG（Directed Acyclic Graph）をGitOpsベースで管理したかったのと、検討時、Kubeflow Pipelinesの機能がまだ成熟していない感じがあったのでトータルでAirflowを採用しました。AirflowではKubernetes Pod OperatorやKubernetes ExecutorといったKubernetes上で動かすための仕組みがすでにあったので、比較的簡単に使い始めることができました。
今後の状況によってはTektonなどの新興pipelineツールだったり、成熟したKubeflowのpipelineに戻ったり、ということがあるかもしれません。
リモートジョブ実行
大規模なデータ処理や分散学習処理を簡単に実行するためのジョブ実行基盤についても整備を行っています。
当初はSageMakerを全面的に使う案や、Kubeflow Fairing、あるいはMetaflowを使うことも検討しましたが、弊社での使い方にフィットするものがなかったため、現在独自にツールを開発しています。このツールについては現在精力的に開発をしている段階であり、まだ詳しくはお話することはできませんが、将来的に開発が進み安定してきたらOSSでの公開なども視野に入れて作っています。
最後に
AIラボが普段開発で利用している各種インフラや仕組みについてご紹介させていただきました。
AIラボでは少数精鋭で最大の価値を創出してユーザーに届けきるために、機械学習エンジニアリングを支える基盤作りに積極的に取り組んでいます。この記事を見て少しでもfreeeという会社に興味を持っていただけた方は是非気軽に遊びに来てください。よろしくお願いします。
