MuleSoft 入門(10)Mule API のバージョン管理

December 19, 2019 Naoki Kitaarashi

組織の中で 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

アピリオのシニアコンサルとしてクラウドの世界に身を投じてはや5年あまり。プロジェクトでの立場に応じて、アーキテクト、リーダー、デベロッパーと様々なロールの仕事に携わっています。続々と新しいサービスと技術が登場するSalesforceの世界はエンジニアとして常に刺激を持ち続けられるエリアであり、2019年からはMuleSoftソリューションの起ち上げに関わっています。しばらくはAPI-ledなシステム連携を広めることに全力投球!!

Naoki Kitaarashi のコンテンツをもっと見る
戻る
MuleSoft 入門(11)ランタイムログの自動アーカイブ(1/2)
MuleSoft 入門(11)ランタイムログの自動アーカイブ(1/2)

今回の記事では、Mule API の本番運用で必要となる Anypoint Platform のランタイムログを定期的にアーカイブする機能を持つ、Mule アプリケーションの実装方法について紹介しようと思います。

次へ
MuleSoft 入門(9)カスタムポリシーの開発
MuleSoft 入門(9)カスタムポリシーの開発

MuleSoft のAPI管理は標準のポリシーの組み合わせで幅広い要件をカバーできますが、場合によっては既存機能の拡張や新機能の定義が必要になります。今回は、「カスタムポリシー」の開発手順についてご紹介します。

アピリオまでお気軽にお問合せください

ご質問はこちら