みなさんこんにちは。株式会社オープンストリーム・技術創発推進室の高岡です。

2024 年 9 月 30 日に、私たちが開発しているMLOps 基盤ツール “Knitfab” の v1.3.1 をリリースしましたので、その変更内容をご紹介いたします。

v1.3.1 で変わったこと

v1.3.1 では、機能面の変更も、バグ修正もありません。

では、なにをしたのか、というと、これまでの Knitfab 本体のリポジトリ( opst/knitfab )から、2 つのディレクトリを新たなリポジトリとして独立させる、ということをしました。

• opst/knitfab-docs
• opst/knitfab-api-types

opst/knitfab-docs

リポジトリ opst/knitfab-docs は、 Knitfab のドキュメント類が格納されていたディレクトリ docs を独立させたものです。

これを独立させた目的は「Knitfab 本体のリリースサイクルにとらわれずにドキュメントを更新できるようにしたい」というところにあります。

これまでは、ドキュメントは Knitfab 本体リポジトリと統合されていたので、ドキュメントの更新にも main ブランチへのマージ = Knitfab 全体のリリースが必要でした。

「Knitfab の機能追加があって、それに伴ってドキュメントも拡充される」というパターンであれば、Knitfab 本体もドキュメントも両方更新されるので、リリース上何の問題もありません。一方で、「ドキュメント上の誤字脱字などの些細な誤記載の訂正」とか「既存機能について、よりわかりやすく説明する新規文書を追加したい」とかいった、Knitfab 本体側には一切変更がないケースでは、どうリリースするか悩ましい問題が生じてしまいます。ドキュメント更新のタイミングを Knitfab の次のリリースまで先延ばしにするか、Knitfab を本体に変更がなくともリリースすることにするか、どちらかを選ばなくてはならないのです。

この悩ましさは、ドキュメントのリリースサイクルが Knitfab 本体のリリースサイクルと一致しないものであるために生じています。であれば、互いに独立してリリースできるようにすれば、問題は解決するはずです。

そこで、今回のリリースから、ドキュメントと本体をリポジトリのレベルで分割して、それぞれ必要なときにリリースできるようにしました。

なお、公式サイト（ https://knitfab.opst.co.jp ）からのリンクも、もう新しいリポジトリを参照するようになっています。

opst/knitfab-api-types

リポジトリ opst/knitfab-api-types は、 Knitfab の WebAPI に関連する go 言語の型の定義パッケージ pkg/api/types （の一部）を独立させた、主に Knitfab のエクステンション機能を使おうとしているパワーユーザ向けのリポジトリです。

これを独立させた目的は「Knitfab エクステンションを書きたい人たちに、型情報を再利用してもらえるようにしたい」というところにあります。

ここのところ、Knitfab は、拡張 API/拡張 CLI サブコマンドであるとか、ライフサイクルフックの追加であるとかいった、「Knitfab を拡張（エクステンション）できるようにする」機能群を追加してきました。

ところでユーザ側の立場に立ってみた時、そうしたエクステンションを実装しようとすると、Knitfab WebAPI を活用する必要があり、つまり WebAPI とのリクエストやレスポンスをうまくマーシャリングできる必要があります。そのための型がどこかに必要になる、ということです。

もちろん、Knitfab 自身のリポジトリ ( opst/knitfab ) を go 言語のモジュールとして取り込んで使っても良いといえばよいのですが、そうして開発した Kntifab 拡張も BSL1.1 ライセンスの影響を受けてしまいます。特に「リリース後 4 年で GPL になる」という制約は大きいものでしょう。ユーザは開発した拡張をインハウスで利用するだけだとしても、ライセンスの問題は気にかかるところかと思います。

では、WebAPI とのマーシャリングのために、エクステンション開発者はそれぞれ、自前で型を用意しなくてはいけないのでしょうか？ いいえ。Knitfab 開発チームとしては、パワーユーザの皆さんに車輪の再発明を要求したいわけではありません。

そこで今回、 WebAPI 関連の型をリポジトリとして独立させ、 MIT ライセンス下で公開することにしました。

次のようにすると、最新の opst/knitfab-api-types を依存関係に追加できます。

go get github.com/opst/knitfab-api-types

もちろん Knitfab 自身も opst/knitfab-api-types に依存するようになったので、これを使って Knitfab 拡張を開発すれば、 WebAPI 越しの入出力のマーシャリングに Knitfab 本体と同じものを使える、ということになります。

バージョンの関係

Knitfab 本体と opst/knitfab-api-types との間で、バージョン番号がどういう関係にあるか、という点に触れておきましょう。

原則として、Knitfab 本体と opst/knitfab-api-types のバージョン番号は一致します。たとえば、 Knitfab v1.3.1 の WebAPI は、 opst/knitfab-api-types v1.3.1 を使って読み書きできる、ということです。

また、開発中のバージョンは “-beta” というサフィックスがついてリリースされることがあります。たとえば、opst/kntifab-api-types v1.4.0-beta は 「v1.4.0 互換となることを目指す、最初の開発版」を意味します。それは、Knitfab の v1.4.0 開発ブランチ（の、ある範囲）に対応するでしょう。もし開発版を複数回リリースすることがあれば、サフィックスに -beta.2、 -beta.3 …… と番号付けてゆく予定です。

まとめ

以上、v1.3.1 の更新点と、その意図をご紹介しました。

私たちは、Knitfab 周辺のエコシステムも、より良いものにしていこうと考えています。その一環として、ドキュメントと WebAPI 関連の型をリポジトリのレベルで独立させることにしました。

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

著者プロフィール

名前: 高岡陽太

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

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

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