こんにちは、アピリオ北嵐です。今回から MuleSoft 入門編ブログをシリーズに渡ってお届けしたいと思います。昨年 Salesforce 社に買収された MuleSoft は今年から日本でも本格的に展開が開始されています。アピリオ/ウィプロはグローバルでは 2016 年からお客様への MuleSoft 導入を支援しており、現在も世界中に延べ 200 名以上の資格保有者を有し、各拠点からプロジェクトを支援しています。日本でも MuleSoft Japan の立ち上げと歩調を合わせて MuleSoft チームを立ち上げ、お客様への支援を開始しております。
まだまだ日本語でのリソースが少なく日本人の開発者にとって MuleSoft の学習は少し大変な状況ですので、この入門シリーズでは MuleSoft が提唱する API 主導のシステム連携、MuleSoft Anypoint Platform の紹介、Anypoint Studio による API 開発の流れ、API の管理/デプロイ、カスタム開発の方法など、MuleSoft による API 開発の基本から簡単な応用テクニックまでを網羅しようと思っています。ブログは私と弊社 MuleSoft チームの中西が担当します。
MuleSoft とは
MuleSoft は 2006 年に MuleSource として創業され、2009 年に MuleSoft に社名を変更、そして 2018 年 5 月に Salesforce に買収され現在は Salesforce 傘下で事業活動が行われています。メインプロダクトである Mule は、Java ベースのライトウェイトな ESB（Enterprise Service Bus）であり、様々なアプリケーション、システム、ネットワークを統合するための統合プラットフォーム（Integration Platform）です。Mule は iPaaS（Integration Platform as a Service）として機能し、クラウドサービスとオンプレミスサービスを統合するための様々な機能とツールを提供します。
API-led Connectivity: API 主導のシステム連携
MuleSoft の最大の特徴は、クラウド環境でシステム間を連携する技術として主流になった RESTful API を使ってシステムを接続することをゴールにしていることです。従来のESBと言えば、レガシーからオープンまで様々なリソース/プロトコルをサポートし、それらを単一のデータソースに接続することを特徴としていましたが、MuleSoft は API-led Connectivity（API主導のシステム間連携）により、データとアプリケーションを再利用可能な形式で接続し提供することを目指しています。
[従来の ESB と MuleSoftプラットフォームの違い]
※ モノリシック：全ての機能を1つの固まりとして集約している状態
MuleSoft における API はフラットに準備するのではなく、3層に分けて API によるアプリケーション・ネットワークを構築します。各層の特徴は下記の表のようになり、これらの層に分けて API を設計・開発することで、柔軟性と再利用性を最大限高めるのがベストプラクティスとされています。
[MuleSoft における3層 API]
API の再利用
MuleSoft による API 環境の導入では、API の再利用性を高めることが重要視されています。この API の再利用を最大化できるように、API は下記の特徴を持つべきとされています。
- HTTP ベースの RESTfull API として提供する（SOAPではなく REST ）
- 利用者が API を自由に検索できて、簡単に利用できる（組織内を探し回らなくても、能動的に見つけることが可能）
- 実装が簡単で、再利用し易い単位で API が提供されている
- 非機能（セキュリティ、性能、スケーラビリティ）もきちんと配慮されている
これらの特徴を全て満たせるように、MuleSoft は API の管理・運用のプラットフォーム、設計・実装のツール、クラウド上の API の実行環境、公開リポジトリと、組織における API の導入を支援する統合的なプラットフォームを提供しています。
C4E：Center for Enablement
C4E は MuleSoft による API-led なアプリケーションネットワークの構築を支える組織横断チームであり、組織への API の導入を支えるための要となります。この手のチームとしてはよくCoE（Center Of Excellence）が使われることが多いですが、CoE が物理的に単独のチーム（Centerlized）を表すのと比べると、 C4E は 複数のチームが協業して活動（Federated）することが大きな特徴となっていて、Mule の世界では再利用中心の API-led を広めていく役割を持つ組織横断チームを C4E と呼んでいます。
MuleSoft の導入を検討すべき組織とは
どのような組織が ESB の導入を検討すべきかについて、MuleSoft のホームページでは下記のようにガイドされています。
- 社内に3つ以上のシステムがあり、接続する必要がある
- 将来的に、複数のアプリケーション（クラウド、オンプレ）を接続する必要がある
- 複数のプロトコル（REST API、SOAP、JMS、ホスト接続等）を用いてシステム間を連携する必要がある
- 1つのサービスを複数のアプリケーションから利用させたい
MuleSoft は従来の ESB と比べて導入のしきいが低いプラットフォームではあるものの、社内にあるいくつかのシステムを Point to Point で接続するために使用するには too much だと考えます。レガシーシステムを含む多数のシステムとデータが社内に混在しているエンタープライズな企業で、"顧客データにアクセスしたいけど、最新かどうか分からない仕様書しか見つからない。担当者はAさんだったけど、部門移動して現在は誰に聞けばよいか分からない・・・。そもそもネットワーク的に繋がるのだろうか？"などという感じで、社内システムの複雑さゆえに DX 時代に求められるスピード感のある開発が行えないユーザーこそ、MuleSoft 導入の価値が大きいのではないでしょうか。
このシリーズを通して、MuleSoft を使った API ベースのシステム間連携の具体的なイメージをつかんでいたければ幸いです。
次回は Mule による API 開発・運用の要である Anypoint Platform について紹介したいと思います。
[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 のコンテンツをもっと見る
