2019.06.06

MuleSoftに関する考察

はじめに

米国時間2018年3月26日にsalesforce.com社より買収が発表された米MuleSoft社ですが、昨年のDreamforceやSWTTでは非常に高い関心を集め、その後の日本国内での動向に注目してきました。ようやく日本国内においても販売・サポート体制が整備されつつある状況になってきたようです。

そのような中、テラスカイはiPaaSのカテゴリで競合に位置付けられるサービスを担いでおり、MuleSoftとの関係をどう考えるべきかは重要なテーマとなりました。今回のブログでは、MuleSoftと従来のEAIとの違い、優位性、課題などをお伝えしたいと思います。

※ 米MuleSoft社が提供するAnypoint Platformが製品名称になりますが、本ブログでは便宜上MuleSoftの表記で記載しております。

米MuleSoft社買収の背景

salesforce.com社はここ数年で多くの企業を買収することにより、サービス強化を継続していることはSalesforceビジネスに関わる方であればよくご存知のことでしょう。これまでに買収したサービスの一部(Marketing Cloud、B2C Commerce Cloudなど)はSalesforceのコアサービスとは異なるインスタンスで稼働しているものもあり、結果として顧客第一を視点としたシステム統合が不十分な状態となったことは否めません。さらに、真に顧客第一な視点を持つシステム統合を果たすには、Salesforce以外のクラウドサービスや既存のレガシーシステム、オンプレミスで稼働するERPシステムなどとの統合も視野に入れる必要があり、この課題を解決するためのソリューションとして、昨年Cusotmer360が発表されました。

Customer360においてSalesforceとは異なるインスタンスで稼働するサービス群の統合には、当初MuleSoftがバックグラウンドを担うものと思われましたが、独自実装になるようです。一方、Salesforce以外のクラウドサービスや既存のレガシーシステム、オンプレミスで稼働するERPシステムなど、Salesforceの外部に存在するシステムをCustomer360に統合する際には、MuleSoftを介した統合が念頭に置かれているものと思います。

つまり、Customer360のリリースタイミングはさておき、salesforce.com社のビジョンを実現するためには、Salesforce Connectによる外部データの表示・参照・更新からさらに踏み込んだ、インテグレーション自体を担うサービスを持つことが欠かせないと判断されたものと思います。

MuleSoftの優位性

MuleSoftの最大の特徴であり優位性は、インテグレーション機能に加え、APIマネジメント機能を持つことにあると思います。従来のEAI製品の生い立ちは、企業内外に散在するシステム連携を目的に、ソースシステム/ターゲットシステムの双方に極力手を入れることなく、中間層としてプロトコル変換、フォーマット変換、エラーハンドリング、トランザクション処理などの実現にあり、そこに注力してきました。

一方、APIマネジメント機能にはWeb APIの作成と公開、使用ポリシーの適用、アクセス制御、使用統計の収集と分析、パフォーマンスレポートなどが必要とされ、各社からAPIマネジメント製品として提供されています。

インテグレーション機能に加えAPIマネジメント機能が必要とされる場合、APIマネジメント製品とEAI製品の組み合わせを構成するのが一般的でした。MuleSoftの場合、APIマネジメントとインテグレーションで必要とする機能を、開発・運用双方の側面からすべてをサポートする製品コンセプトが特徴的です。

逆にインテグレーション機能だけを必要とした場合、APIマネジメント機能の両方を持つことがオーバースペックとなり、投資対効果を考えた場合に少なからず足枷となる場合はあるでしょう。

MuleSoftが推奨するアーキテクチャー

MuleSoftではAPIを3つのレイヤーに分離し、疎結合でつなぐ”API-led Connectivity”と呼ばれるアーキテクチャーが推奨されています。Point to Pointでシステム連携を行う場合、システム連携対象システムの増加と共にシステム間は密結合化が進み、その結果依存関係が高まり、システムの維持や改修に影響を及ぼすことがあります。

API-led Connectivityの採用により、システム間の依存関係が分離され、APIの再利用性やメンテナンス性などの向上が期待できると言われています。

3階層アーキテクチャーの課題

複数のシステムをMuleSoftが推奨するAPI-led ConnectivityのアーキテクチャーでAPI化を進める場合、接続対象となる複数システム全体を俯瞰して、再利用性を含む最適な粒度で各レイヤーに分離したAPI化が求められます。企業内に存在する複数システムを個別に精通した開発者は存在すると思いますが、”複数システム全体を俯瞰”し、”最適な粒度でAPI化”できる開発者の存在は課題になることでしょう。

つまり、システム個別に精通した開発者はSystem APIの設計・開発はできると思いますが、システム間を横串に処理するProcess API、さらに上位レイヤーのExperience APIは、個々のシステムに関する知識だけでは設計・開発は難しいであろうということです。

また、API-led Connectivityの3つのレイヤーへの分離は(同列に並べて比べるには無理がありますが...)、概念的にSOA(Service Oriented Architecture)を彷彿させます。SOAは必ずしも成功を収めたとは言えず、API-led Connectivityをベースとした設計・開発も決して低いハードルでは無いでしょう。逆に適切に設計・開発できた場合の効果はとても高いと思いますし、是非ともチャレンジしたい領域です。

いずれにせよ、MuleSoftの導入を進めるプロジェクトでは、プロジェクトのチーム体制とAPI-led Connectivityを適用するためのメソドロジーに精通したエンジニアの確保が鍵を握ることでしょう。


MuleSoft vs DataSpider Cloud(EAI)

従来のEAIはもともと企業内外に散財するシステムをソース/ターゲットシステムに極力手を加えることなく、システム連携することを目的に提供されてきました。 DataSpider CloudのエンジンとなるDataSpiderの歴史は米MuleSoftの創業より古く、また国産製品ということもあり、国産アプリケーションとの接続性(例. HULFT、勘定奉行V、Dr.Sumなど)や、海外製品では課題となりやすい日本語対応、豊富な編集・加工ロジックの提供などには優位性があります。MuleSoftでもコネクタが接続対象アプリケーションに対応していない場合、SDKを利用したコネクタ開発を行うことはできますが、生産性や品質、維持・運用面を考慮したトレードオフとなるでしょう。

DataSpider Cloudの優位性を簡単に述べましたが、その生い立ちや製品コンセプトは明らかに異なります。そのため、採用検討において機能面の細かな優劣を比較検討するものでは無いというのが基本的な見解です。コンセプトの違いを理解し、MuleSoftを選択すべき(あるいはMuleSoftが持つメソドロジーを採用したい)、MuleSoftではオーバースペックとなる、あるいは併用が効果的となるといった検討が早い段階で必要でしょう。

接続すべきシステムが大量にありマイクロサービスを念頭にした連携基盤を再構築したい、今後のシステム連携にはAPI-led Connectivityを採用して進めたい、レガシーシステムなど自社ノウハウを持つシステムをAPI化してサービスとして公開したい、などのようなケースであれば、MuleSoftの選択をお勧めするでしょう。少なくともSalesforceが提供するDataLoaderの延長で採用するような製品では無いことは間違いありません。

一方、特定システムや少数システムとの複雑かつ大量なインターフェースの構築(Point to Pointでの連携が効果的)、DataLoaderでは限界を感じる場合の手軽なリプレースなどであればDataSpider Cloudをお勧めします。

そして、MuleSoftを採用したとしても、接続対象に国産アプリケーションが含まれている、日本語固有の処理が必要、部分的に特定システムとの複雑かつ大量なインターフェースの構築がある場合などでは併用も選択肢となるでしょう。併用する場合、API-led Connectivityのレイヤーの中で部分的にProcess APIとSystem APIの領域をカバーするデザインが効果的になります。

比較ポイント

製品コンセプトの違いから、機能面で両サービスを比較検討するものではないとの見解を示したものの、実際の検討においては最低限の比較検討が要求される場面は多いことでしょう。DataSpider CloudにはAPIマネジメントはありませんので(※1)、インテグレーションの観点で比較検討されるであろうポイントを記します。

※1. DataSpider CloudにはHTTPリクエストを起点にインテグレーションを行う機能は備わっていますが、APIマネジネントで一般に要求される機能を網羅して備えているものではありません。
管理・運用面 開発機能面 実行タイミング
サーバ管理 動作環境 起動方法の種類
ユーザ管理 対応接続先 起動有無の制御(休日対応など)
アクセス制御 Salesfoce対応状況 -
スケールアップ ロジック(条件・分岐・回帰) -
VPN対応 ロジック(編集・加工・変換) -
ログ管理 エラーハンドリング -
分析(負荷・トラフィック) コーディング可否 -
- テストサポート -
- バージョン管理 -

おわりに

MuleSoftに関する考察と題してお伝えしましたが、如何でしたでしょうか?結論として、生い立ちや製品コンセプトの違いから、直接競合するものではなく、目的や用途の違いに応じて住み分けられ、必要に応じて併用が効果的であろうというのが見解です。

Salesforceビジネスは大変活況でありますが、米MuleSoft社の買収により、Salesforce界隈のインテグレーション市場も、ますます活況を呈することを期待すると共に、MuleSoft単独の導入プロジェクトであっても積極的な関わりを持っていきたいと思います。

そして、いちエンジニアとしてもMuleSoftに関わることは新たなチャレンジであり、新たな技術の習得は楽しいものです。これからも引き続き注目して行きたいと思います。
21 件
     
  • banner
  • banner

関連する記事