2019年10月から2020年2月まで開発チームで取り組んだアンケートフォーム(β版)のリリースまでのリアルな道のりを記しています。エンジニア、デザイナー、プロダクトマネージャーにはぜひ読んで欲しい内容です。

KARTEのアンケートフォーム(β版)公開までの道のり

<html><head></head><body>こんにちは、エンジニアの <a href="https://twitter.com/kargo113" target="_blank" rel="noreferrer">@kargo</a> @nichimu です。KARTEのDatahubというプロダクトに携わっており、KARTEのデータ及びお客様のデータを活用したプロダクトの開発を行っています。 
今回は、KARTEにおいて活用しているコンテナネイティブのワークフロー基盤であるKubeflow Pipelineの組み込みについての概要をご紹介したいと思います。
<h1 id="Kubeflow とは">Kubeflow とは</h1>
ここ数年でMLOpsという言葉が浸透するようになり、機械学習の実運用についての具体例がたくさん見受けられるようになりました。 
<a href="https://www.kubeflow.org/docs/about/kubeflow/" target="_blank" rel="noreferrer">Kubeflow</a> はそのような機械学習の実運用をスムーズに行うためのオープンソースのプラットフォームです。Kubernetes上で動作することを前提とされているので、GKEやEKS、オンプレミスのKubernetes基盤にデプロイすることができます。直近では最新のv1.0が公開されているようにかなりのスピードで発展してきており、コミュニティも盛んです。 
Kubeflowは様々な機能がありますが、今回はその中でも Kubeflow Pipeline というコンテナのワークフロー基盤を活用した事例についてご紹介していきます。 
Kubeflow Pipelineの基本的な使い方についてはそれだけで1つのブログが書けるボリュームですので、以下の内容では使い方については触れません。それを前提とした上で、活用方法について述べていきます。基本的な使い方は<a href="https://www.kubeflow.org/docs/about/kubeflow/" target="_blank" rel="noreferrer">ドキュメント</a>がわかりやすいので是非ともご参考にして頂ければと思います。
<h1 id="Components について">Components について</h1>
弊社では、KARTEに蓄積されたデータを用いて、クラスタリング・需要予測・レコメンデーション・購買予測・不正検知など様々な取り組みを行っています。 
Kubeflow Pipelineで動かすPipelineは大きく分けて
<ul>
<li>学習用パイプライン</li>
<li>推論用パイプライン</li>
</ul>
の2つがあります。これらを各タスクごとに管理しています。
各タスクごとにコンポーネントはなるべく共通化したく、<a href="https://www.tensorflow.org/tfx" target="_blank" rel="noreferrer">TFX</a> の概念を大いに参考にさせて頂きました。TFXは機械学習タスクに必要なコンポーネントが丁寧に抽象化されており、今回は以下の図のようなコンポーネントを参考にしました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2149e535-f318-4b6a-ba94-70c8adc5bb2d/tfx.svg" alt="">
実際に学習用パイプラインで構築したコンポーネントは
<ul>
<li>ExampleGen</li>
<li>SchemaGen</li>
<li>Transform</li>
<li>Trainer</li>
<li>Evaluator</li>
<li>Pusher</li>
</ul>
の6つです。
ExampleGenでは、BQにある膨大なデータからクエリによりデータを抽出 
SchemaGenでは、抽出したデータのスキーマを自動で判定 
Transformでは、LabelEncorder等により前処理を実行 
Trainerでは、GridSearch等を用いて最適なモデルの学習 
Evaluatorでは、学習済モデルの評価を行い、モデルの妥当性を検証 
Pusherでは、評価されたモデルをデプロイする 
といった実装になっています。 
これらをPipelineとして単純に直列に以下の図のように繋いでいます。 
各コンポーネントでのデータの受け渡しはGCSを用いており、データのPATHを受け渡すようにしています。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5ae769ac-5242-4cba-a50c-a349015431de/kubeflow-1.svg" alt="">
推論パイプラインでは、 
ExampleGen, SchemaGen, Transformerまでは同様で、これにデプロイしたモデルを用いたPredictorというコンポーネントを直列に繋いで推論を行っています。
また、直列で繋いでいる理由として大量のリソースを消費するものに関しては、各コンポーネント内で外部にジョブを投げているからです。
例えば、ExampleGenにおいてはApache Beam SDKを用いて実装しているので、大規模分散処理に関してはDafaflow上で実行することが可能です。さらに、Trainerにおいても、学習ジョブはAI Platform Trainingで実行しているため、こちらも大規模並列学習が可能になっています。 
つまり、Kubeflow Pipelineをデプロイしているクラスタのリソースは最小で、必要に応じて外部のマネージメントサービスを活用することで、簡単なタスクから複雑なタスクまで幅広く対応できるようになっています。
<h1 id="Pipelines SDK の活用">Pipelines SDK の活用</h1>
Kubeflow Pipeline には <a href="https://www.kubeflow.org/docs/pipelines/sdk/sdk-overview/" target="_blank" rel="noreferrer">Pipeline SDK</a> と呼ばれるものも用意されており、外部からでも簡単にパイプラインの実行や管理ができるようになっています。これを活用しフロントエンドと連携をしています。 
例えば、
<pre><code class="hljs">client = kfp.Client(
 host="YOUR_KUBEFLOW_HOST", 
 client_id="OAUTH_CLIENT_ID"
)
res = client.run_pipeline(
 experiment_id="YOUR_EXPERIMENT_ID",
 job_name="JOB_NAME",
 pipeline_id="PIPELINE_ID",
 params="ARGUMENTS",
)

</code></pre>
といったように指定したパイプラインの実行ができます。 
paramsに任意の引数を渡すことで柔軟にパイプラインの実行が可能です。
wait_for_run_completionやget_runメソッドも用意されているので、パイプラインの実行状況を確認することも容易です。
補足ですが、私たちの環境ではCloudIAP認証を用いているため、client_idが必要です。また、実行するサービスアカウントにIAP で保護されたウェブアプリ ユーザーという権限を付与する必要がある点にも注意が必要です。
<h1 id="フロント画面との連携">フロント画面との連携</h1>
KARTEの管理画面で使用している技術を簡単に述べると、フロント: Vue.js、バックエンド: Node.js、DB: MongoDBで構成されています。 
管理画面から任意のパラメータを入力し、Kubeflow Pipelineのパイプライン処理を実行をさせた上で、モデルの結果はいつでも管理画面から取得できる状態にしたいというのが今回の要件です。
現状、Pipeline SDKにはpythonのものしかなく、バックエンドがNode.jsであるKARTEで使おうと思うと、Node.jsにあるPython-shellを使用するかFlask等を使ってRESTの口をつくるかの2通りありました。 
その中で、我々は、新たにPythonベースのコンテナをGKEに立てて、Node.jsベースのコンテナとkubeflow clusterの橋渡しとなるようなinternalなAPIとして用いる方針をとりました。 
PythonベースのコンテナでPipeline SDKを使えるようにすることで、KARTE管理画面からKubeflow Pipelineを実行できるようにしました。
また、PipelineのジョブパラメータはMongoDBに保存しておくことで、いつでもKARTE管理画面からジョブの実行結果を確認できるようにしました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f84d0fa8-a21d-4fd4-8975-c8d3c24297d7/backend.png" alt="">
このようにKARTEの管理画面からも簡単に任意のパラメーターでパイプラインを実行し、結果を取得することが可能です。
こういったSDKもきちんと用意されており、連携も簡単にできる点も素晴らしいですね。
<h1 id="今後の課題">今後の課題</h1>
<h4 id="サービスアカウント問題">サービスアカウント問題</h4>
現状のKubeflow Pipelineの仕組みではパイプラインをKubeflowにデプロイする段階でSecretをコードで指定する仕組みになっています
<pre><code class="hljs">dsl.ContainerOp(
 name="NAME",
 image="IMAGE",
 command=["COMMAND"],
 arguments=["ARGUMENTS"],
)
.apply(gcp.use_gcp_secret("user-gcp-sa"))

</code></pre>
そのため、実行するパイプラインごとに引数等でサービスアカウントを指定することができません。こちらも柔軟に変更できた方が権限管理は非常に便利になるのですが、現状は未対応なので場合によっては裏側で色々と権限管理を頑張る必要性が出てきます。
<h4 id="Kubeflow? TFX? AIPlatform?">Kubeflow? TFX? AIPlatform?</h4>
少し余談にはなりますが、このあたりきちんと使い分けられている方は少ないのではないでしょうか。 
Kubeflowはドキュメントにしたがってデプロイするとやや大きめなMachineTypeでNodePoolが作成され、GPU Node Poolも作成されます。つまり、このクラスタ内のリソースを使うのだろうと思っていたのですが、exampleを見ると Data Proc や AI Platform にジョブを投げているものもあります。さらに、TFXではTensoflow Transformerというものがあり、これはDataFlowにジョブを投げるものとなっています。こうなってくるとかなりややこしく、結局どういう構成がベストプラクティスなのかが見えづらい状況です。 
あくまで私たちの仕組みでは、Kubeflow Pipeline自体のリソースは最小限に、コンポーネントの各ジョブは外部リソースを使ってスケールさせるという選択肢をとったに過ぎないので、この内容がみなさまの実際のケースに沿って最適な選択の一助となれば幸いです。
</body></html>

KARTEにおけるフロントエンドと連携させたKubeflow Pipelineの活用方法について解説します

KARTEにおけるKubeflow Pipelineの活用 | PLAID engineer blog

KARTEにおけるKubeflow Pipelineの活用

2019年以降、Slack APIがどのように変化し何に注意すべきかについてご紹介します。主にBlock Kit、Modal、Home tabなどSlack上での新しい表現や、Granular permissionsと呼ばれる新しい権限モデルへの対応方法について詳しく説明しています。