皆さんこんにちは。技術創発推進室の高岡です。

私達が開発している MLOps ツール “Knitfab” の最新バージョン v1.3.0 を、9月13日にリリースしました。この記事では、v1.3.0 での変更点についてご紹介します。

新機能: カスタムな Data インポート機構の追加

これまで Knitfab に Data を登録する方法は、「アップロードする」か「Run の出力として得る」か、の 2 種類しかありませんでした。v1.3.0 では、アドバンスドなユーザ向けの機能として、ユーザ側の必要に応じて Data 登録の方法を拡張できるようにする仕組みを追加します。これは、任意の Kubernetes PersistentVolume を Knitfab に Data として登録できるようにするものです。

これによって、たとえば「Amazon S3 にあるファイルを Knitfab に使わせる」とか「NFS 上にすでに存在しているファイルを、アップロードすることなく Knitfab に使わせる」とかいった機能を、ユーザ側で追加開発できるようになります。

このために、Knitfab の”バックエンドWebAPI”に以下のAPIが追加されました。

• POST http://knitd_backned/api/backend/data/import/begin: インポートの開始を Knitfab に通知する
• POST http://knitd_backend/api/backend/data/import/end: インポートの完了を Knitfab に通知する

バックエンドWebAPI とは、通常の Knitfab WebAPI とは異なり、Knitfab がデプロイされている Kubernetes クラスタの内側でのみ利用可能な WebAPI です。同一クラスタ・同一 Namespace 内であれば、通常は knitd_backend というホスト名でアクセスできます。

この新機構を用いた Data インポートは次の手順で行います。

1. POST /api/backend/data/import/begin に空のHTTPリクエストを送ります。
   1. レスポンスとして JSON Web Token (JWT) が返されます。
2. 返された JWT から、sub クレームを読み取ります。
   1. この sub クレームは、Knitfab がデータインポート用に振り出した PersistentVolumeClaim(PVC) の名前です。
   2. JWT の署名検証用の証明書は Knitfab は公開しないので、検証することなくクレームを読み取ってください。
3. sub クレームに指定された名前の PVC と、インポートしたい Data 内容を保持している PersistentVolume(PV) を Kubernetes 上に作成し、両者を Bind します。
4. POST /api/backend/data/import/end に、手順1. で受け取った JWT を送り返します。
   1. JWT を受け取ってからおよそ 30 分以内にこの終了リクエストを送る必要があります。
   2. インポートに成功すれば、成功(200)レスポンスとして登録された Data の情報が返されます。

手順 3. において、PV を作成する方法については制約がないので、任意の内容の PV を構成して Knitfab に自由な手法で Data を登録できる、というわけです。

実際にカスタムなインポート手順を Knitfab 拡張としてデプロイする際には、上記の手順をプログラムして、 Web サーバとして実装し、コンテナイメージにパッケージして、Knitfab と同じ Namespace に （Deployment などを介して） Pod としてデプロイし、Knitfab の拡張 WebAPI として公開するとよいでしょう。また、その拡張 WebAPI のクライアントは、CLI knit の拡張コマンドとして実装できます。

バグ修正など

• インストーラについて
  • installer.sh --prepare を繰り返し行ったとき、一部設定ファイルの内容がリフレッシュされるのではなくて、リフレッシュすべき内容が元のファイルに追記される、という現象がありました。リフレッシュするように修正しました。
  • インストーラを実行した際の条件によって、正常に機能しないアンインストーラが生成されることがありました。修正しました。
  • インストーラのメッセージ中の誤字を修正しました。
• Data Agent や Run Worker について
  • これらは Knitfab が必要に応じて自動的に起動する Pod ですが、 これらの Pod が Node にスケジュールされたあとで正常に起動できないことがわかることがあります（たとえば、NFS を背景にした PVC をマウントしようとしているが、NFS 側には PVC が参照しているディレクトリが存在しなくなってしまっている、というケースがこれです）。このような「スケジュールされたが、開始できない」Data Agent や Worker を検出して、停止させるようにしました。
  • 停止させられた Worker の上で実行されていた Run は、失敗します。実行可能な条件を整えて knit run retry してください。
• データベースについて:
  • これまで、Knitfab をアップグレードする際に、稀にデータベースが破損することがありました。これは、アップグレード前のデータベース Pod が終了する前に新しい データベース Pod が起動してしまい、データベースファイル操作が競合することに原因があるようです。アップグレード時には、データベースは古い方を終了してから新しい方が起動するようにしました。
• knit data find:
  • 処理中の Data が検索結果に上がってこない、という不具合がありました。修正しました。

その他の変更

• Go コンパイラのバージョンを v1.23.1 にアップグレードしました、
• admin-guide を 2 つのパートに分割しました。
  • “installation” 編: Knitfab をインストールする手順について述べています。
  • “deep-dive” 編: Knitfab の運用や拡張に関するトピックを扱っています。

おわりに

以上、v1.3.0 の変更点をご紹介しました。詳細な内容や更新手順、最新版の CLI などは、GitHub のリリースページからアクセスできます。

今後とも Knitfab をよろしくお願いします。

著者プロフィール

名前: 高岡陽太

株式会社オープンストリーム／技術創発推進室　

長らく Web 系のシステム開発をしてきたが、2019年頃から機械学習関連の案件に携わり始めた。
ディープラーニングモデルの開発からその API 化、フロントエンド開発まで、必要とあらば一通り手掛ける。
最近は、機械学習それ自体はもとより、機械学習開発を支える技術としての MLOps に興味を持っている。

MLOps 用基盤ツール Knitfab の開発リード。