技術

MuleSoft 入門 Part1

MuleSoft について知る

レザボア・コンサルティングの中西です。
本記事から数回に渡って、MuleSoft に関する入門記事を連載していきます。

MuleSoft とは

MuleSoftは2006年にMuleSourceとして創業され、2009年にMuleSoftに社名を変更しました。

2018年5月にSalesforceが買収し、Salesforceのシステム間連携のソリューションとして推奨されるようになりました。

MuleSoftのメインプロダクトは Anypoint Platform と呼ばれる 統合プラットフォームです。

あらゆるものをつなぎ、すべての人を支援する
（引用：MuleSoft公式HP）

とトップページで謳っているように、あらゆるアプリケーション、サービス、データベース、ネットワーク等を繋ぎ、管理するための iPaaS を提供しています。

MuleSoft の特徴

MuleSoftは、API-led Connectivity（API主導のシステム間連携）を推進しています。

API-led Connectivity（API主導のシステム間連携） とは

API主導のシステム間連携を指す言葉で、APIを使ってデータとアプリケーションを再利用可能な形式で接続するための方法です。

MuleSoftにおけるAPIとは、HTTPベース の RESTful API を指します。

このAPIを3つのレイヤーにAPIの役割別に分けて構築し、柔軟性と再利用性を高めることがベストプラクティスとされています。

３層のAPI設計

API-led Connectivityは、MuleSoftのAPI設計で最も重要な原則です。

プロジェクト推進においては、原則、このレイヤーに従ってAPIを設計することが求められます。

この３つの層のそれぞれの役割に従ってアプリケーションネットワークを構築します。

APIの種類説明
Experience APIAPIを使用するクライアントアプリケーションの差異（認証、I/F項目、セキュリティなど）を吸収する層。この層を設けることで、Process層のAPIの再利用性を高めることができる。
Process API複数のSystem APIを組み合わせて、1つの業務的な機能を提供するAPIを定義する層
System API企業内部の既存のリソースやクラウド上の外部リソースにアクセスしてデータを取得・更新する機能を提供するAPIを定義する層。この層では、再利用性を高くするために業務色をできるだけ排除してI/Fを設計する。

mulesoft-layers

上記画像がイメージしやすいかもしれません。

System API は様々なデータソースにアクセスし、企業内のデータをアンロックする役割を持ちます。

Process APIは、System APIを組み合わせながらビジネスロジックを構築します。

Experience API では、例えばモバイル向け、特定のアプリケーション向け、といったクライアント専用のAPIとして構築します。
Process APIを直接呼ぶのではなく、Experience API を構築することによって、機能特有の要件（流量制御等のポリシーや、PC版とのリクエストパラメータの違い 等）をこの層で吸収することができます。

別のアプリケーションでも同様のデータを使用したい場面が出てきたら、Experience API を一つ追加します。
そして、既存のロジックが構築されている Process API にのIFに適したデータに変換してリクエストを送ることで、Process API 以降のロジックは再利用することができます。

このように、再利用性を高めつつAPIネットワークを構築し、管理できるのがMuleSoftの大きな特徴・強みと言えます。

Modern API について

MuleSoftの提唱する API（Modern API） は、以下のような特徴を持ちます。

  • HTTPベースのRESTful API（SOAPではない）
  • 利用者が自由にAPIを検索できて、簡単に利用できる
    • 組織内の誰かにお願いしなくても能動的に見つけることができる
  • 実装が簡単で、再利用し易い、変更に強い
  • 非機能（セキュリティ、スケーラビリティ、性能）の事も配慮されている

このような特徴を持つAPIを構築し、サービスの幅を広げていくための統合環境が MuleSoft の Anypoint Platform なのです。

Why Mule? 従来のESBからAPI-ledへ

MuleSoft-Integration

この図のように、従来のモデルでは単一のデータソースに集約されたデータを中心とし、さまざまなアプリケーションやシステムが密接に連携し合うような、いわゆるスパゲティ構造のような連携になりがちでした。

これを、３つのレイヤーに分けてAPI管理することで、データソースとフロントの役割を明確にできるとともに、ロジックを再利用しつつ将来的な拡張を前提とした連携を行うことができるようになります。

MuleSoft を適用すべき組織

では、MuleSoftを導入すると必ず幸せになれるかというと、そうとは限りません。

連携するシステムが少ない中小企業や、Point to Point の接続が中心となる連携の場合は、API-ledConectivityの良さを活かしきれません。

次のような場合（一例）にMuleSoftを検討することになります。

  • 社内に3つ以上のシステムがあり、接続する必要がある
  • 将来的に、複数のサービス（クラウド、オンプレ）が必要とされている
  • 複数のプロトコル（REST API、SOAP、JMS、ホスト接続等）を用いてシステム間を連携する必要がある
  • 1つのサービスを複数のサービスと接続した
  • レガシー資産が数多くあるが、縦割りの組織なのでサービス（機能）の再利用が簡単ではない

「連携が発生するからMuleSoftを利用する」のではなく、MuleSoftが適切なソリューションかを考える必要があります。

おわりに

本記事では、MuleSoft 社自体についてと、MuleSoft の提唱するデータ連携のモデル、API設計について紹介しました。

関連記事

TOP