組織の中で API 基盤を運用していくためには、初めにきちんと API に関するバージョン管理の方針を決めておく必要があります。実際の運用に即したバージョン管理の方針を決めておかないと、後から大きな混乱に繋がる恐れもあります。Mule による API 開発では3つの”バージョン”を管理する必要がありますので、今回はこの Mule API のバージョン管理についてご紹介します。
ソフトウェアにおけるバージョン番号
一般的にソフトウェアのバージョンは下記の3つの番号で管理されます。Mule API で管理すべきバージョン番号も下記の考え方をベースにします。
[ソフトウェアにおける3つのバージョン番号の定義]
Mule で管理すべき3つのバージョン
Anypoint Platform で Mule API を開発・運用するには、3 つのバージョン番号を管理する必要があります。「アセットのバージョン」と「API のバージョン」は Anypoint Platform 上でシステム的に番号が管理されるため、システム上の採番ルールがあります。一方、API 呼出の URL パス（例： /api/v1/customers ）に適用する「API リソースのバージョン」は Anypoint Platform 上でシステム的に管理されないため、自由に採番することが可能です（URL パスにバージョン番号そのものを含めないことも可能ですが、API 更新時の運用を考えると通常は付けることをお勧めします）。
以下の表に 3 つのバージョン番号とその利用箇所を記載します。
[Mule API 開発における3つのバージョン番号]
アセットバージョンと API バージョンの方針
アセットバージョンと API バージョンは、Anypoint Studio 上ではセットで管理されるため組み合わせて考える必要があります。以下の 2 つの案が考えられます。
[API バージョンとアセットバージョンの管理方針]
この 2 つの案のどちらを採用するかですが、大きな考慮事項になるのが以下の Anypoint Platform によるアセットバージョンと API バージョンの制約です。
API バージョンを変更すると、アセットバージョンのメジャーバージョンが自動的にインクリメントされる
API のメジャーバージョンだけではなくマイナーバージョンを変更しても、アセットバージョンのメジャーバージョンが自動的にインクリメントされるため、案 2 を採用すると API バージョンとアセットバージョンのメジャー番号が一致しなくなります。
管理上、上記の問題が発生するのは避けたいため、案1の API のバージョンをメジャーバージョンのみで管理する案をお勧めします。クラウド上で公開されている Google 等の Public な API でも API バージョンはメジャーバージョンのみで管理していることが多いですし、API を利用するクライアント側からは Exchange 上でアセットバージョンを参照することで細かい変更を確認することもできるため、運用上のデメリットはあまりないと考えます。
API リソースバージョンの方針
次に API リソースバージョンの方針ですが、以下の 2 つの案が考えられます。
[API リソースバージョンの管理方針]
これら 2 つの案はどちらも一長一短ですが、お勧めは案1の API のバージョンとリソースバージョンを一致させる案です。クラウド上で公開されている Public な API でもこちらを採用しているものがほとんどです。ただ、案1では 1 つのリソースへの変更が影響のない他のリソースにも影響を与えます（リソースパスが変更になる）。利用しているクライアント側への影響を少なくするには、一定期間は新旧2つのバージョンを公開するといった対応が必要となり、管理・運用の手間が増えるだけではなく、サーバー構成によってはライセンスコストが増えます。案2であれば、変更するリソースのみバージョン番号がインクリメントされるため、こうした問題は発生しませんが、変更が進むにつれてAPI のバージョンは管理しづらくなることが予想されます。
組織によってどちらの方針が適してるかは判断が分かれると思いますので、よく議論して判断するようにしてください。
トレーサビリティ
最後に、参考までに Mule 開発・運用環境の各コンポーネント/リソース間におけるバージョンのトレーサビリティについて触れておきます。簡単に言えば、CloudHub 環境で動作しているアプリケーションはどのアセットバージョンに紐付いているかがトレースできるかです。
以下はそのイメージ図になります。アセットバージョン、API ID、POM Artifact Version の3つの ID を使って、各リソース間でトレーサビリティを持つことができます。
[Anypoint Platform における各コンポーネントのトレーサビリティ]
今回は、Anypoint Platform 上の Mule API の開発・運用に登場する 3 つのバージョン番号の特長とそれをどのように組み合わせて管理するかについて説明しました。冒頭でも述べましたが、最初にきちんと組織としての方針を決めておくことが運用を開始してからの混乱を避けるためには大事です。バージョン管理には、絶対的な正解があるわけではないため、今回ご紹介した各案の特徴およびメリット・デメリットを理解して、MuleSoft を適用する組織ごとに判断するようにしてください。
[MuleSoft 入門シリーズ]
MuleSoft 入門（1）MuleSoft による API-led なアプリケーションネットワーク
MuleSoft 入門（2）ようこそ Anypoint Platform へ
MuleSoft 入門（3）Anypoint Studio による API の実装
MuleSoft 入門（4）DataWeave によるデータ変換
MuleSoft 入門（5）Flow Designer で Mule アプリケーションを開発
MuleSoft 入門（6）MUnit による単体テスト
MuleSoft 入門（7）API 開発におけるテストの考え方
MuleSoft 入門（8）ポリシーと SLA
MuleSoft入門（9）カスタムポリシーの開発
MuleSoft 入門（10）Mule API のバージョン管理
MuleSoft 入門（11）ランタイムログの自動アーカイブ
著者について
Naoki Kitaarashi のコンテンツをもっと見る
