iPaaSとは
iPaaSとはintegration Platform as a Serviceの略で、既存のレガシーシステムやSaaSなど様々なサービスを連携し、新たなサービスを提供するための中核となるクラウドサービスです。
iPaaSをシステム間連携の中心に据えることで、従来、運用管理の負担が大きい複雑なアーキテクチャをシンプルなアーキテクチャとすることが可能です。
図1：iPaaSとは
iPaaSは様々なサービスが提供されていますが、ここでは連携処理をAPIとしてサービス化することに特徴のあるMuleSoftをご紹介します。
MuleSoftとは
MuleSoft社はiPaaSの一つであるAnypoint Platform（本稿上では、便宜上MuleSoft =Anypoint Platformとして記述）を提供しています。
MuleSoft社は、MuleSoft上のアプリケーションを3層に分割するアーキテクチャを提唱しています。クライアントの差異を吸収するためのExperience層、データ加工などの処理ロジックを持つProcess層、データソースからデータを取得するためのSystem層。3層アーキテクチャを適切に構築することで、APIの再利用を促進しアジリティの高い開発が可能となります。
図2：MuleSoftの3層アーキテクチャ
これらのコンポーネントはAPIで連携されているため、その実態はマイクロサービスと同等と言えます。一般的に、マイクロサービスはアジリティ向上やスケールのし易さなどのメリットを期待できる一方、構築の難しさや運用管理が複雑であることが知られています。
では、MuleSoftにおけるマイクロサービスはどうでしょうか？以降では、一般的なマイクロサービスの視点からMuleSoftの特徴を述べようと思います。
モノリス視点およびマイクロサービス視点から見たMuleSoftの特徴
そもそもマイクロサービスの特徴はなんでしょうか？様々な観点があると思いますが、本稿では下図に示す観点で従来のモノリシックアーキテクチャとマイクロサービスアーキテクチャを比較し、マイクロサービスのメリット、デメリットを示しています。では、これらの観点に対し、MuleSoftではどのような特徴があるかを述べていきます。
図3：モノリスとマイクロサービスの特徴
アジリティ
モノリスは単一のアプリケーションで構成されるため、一部の改修であってもアプリケーション全体のリリースが必要です。対して、マイクロサービスでは小さいアプリケーションが疎に結合されているため、改修のあるアプリケーションのみリリースすることでアジリティ向上することが可能です。MuleSoftの場合も、マイクロサービス同様にAPI単位のリリースによるアジリティ向上が可能です。加えてローコードでの開発プラットフォームも提供されているため開発生産性の向上も期待できます。また、マイクロサービスでは別途方式検討や製品導入が必要なゼロダウンタイムリリースも標準機能で実現することが可能です。従ってMuleSoftはマイクロサービス以上にアジリティ向上を期待できます。
図4：アジリティの比較
耐障害性
モノリスは単一のアプリケーションでリソースを共用しているため、特定のサービスの障害がアプリケーション全体の障害に直結します。対して、マイクロサービスではアプリケーション毎にリソースが独立しているため、特定のサービスの障害が全体に波及することはありません。MuleSoftの場合も、一部のAPIの障害が全体に波及することはありません。また、APIのデプロイ先リージョンをGUIで簡単に変更できたり、APIランタイム数を簡単に多重化できるため、マイクロサービス以上に耐障害性が高いと言えます。
図5：耐障害性の比較
スケーリング
モノリスは一部機能の性能要件に合わせ、全体のスケールが必要です。この場合、余剰なリソースも発生しがちで費用に対して効率が悪くなる可能性が高いです。対して、マイクロサービスはサービス単位でリソース割り当てが可能で、より最適な構成を取ることが可能です。MuleSoftの場合もAPI単位に律ソース割り当てが可能で、この点はマイクロサービスと同等と言えます。
図6：スケーリングの比較
組織面の一致
これは複数の組織やチームでアプリケーションを構築するケースの観点です。モノリスの場合、単一アプリケーション内で役割分担をすることになります。組織を跨った機能連携が必要であれば、機能連携を加味した開発スケジュールの考慮や、必要以上のモックライブラリの作成などでオーバヘッドが大きくなることが想定されます。マイクロサービスの場合、サービス単位で役割分担をすることで、それぞれ独立した開発スケジュールを立てることが可能です。この場合も、サービス間連携をする際はIF調整などのすり合わせが必要ですが、モノリスと比較するとオーバヘッドは小さいと考えています。一部、モノリスの場合はコンパイルエラーで発見できたIF誤りは、マイクロサービスではサービス結合テスト時に初めて検出されることになるため、この点はマイクロサービスのデメリットと言えるかもしれません。MuleSoftの場合は、マイクロサービスと同等の役割分担が可能です。加えて、モックAPIの自動生成機能を標準で提供しているため、よりメリットを享受できると言えます。
図7：組織面の一致の比較
再利用
モノリスの場合は、他システムから機能の再利用要件が発生した場合、その機能が公開されていなければ再利用することはできません。再利用するためには機能改修してIFを公開する必要があります。マイクロサービスの場合、他システムからの再利用要件に対しては、APIのアクセス制御の設定変更で比較的簡単に再利用を実現可能です。MuleSoftの場合、マイクロサービスのメリットに加え、APIマーケットプレイスを標準機能として提供しています。マーケットプレイス上に再利用可能なAPIなどを公開することで、開発者は再利用可能なサービスを簡単に探すことが可能です。
図8：再利用の比較
技術仕様・要件充足
モノリスの場合、システムの技術スタックをシンプルに構成することが可能です。シンプルな技術スタックは保守の容易性やノウハウ共有のし易さがメリットと言えるでしょう。マイクロサービスの場合、各サービスの特性や担当する組織が得意とする技術などで柔軟に技術スタックを構成できるメリットがあります。一方、技術の乱立によりガバナンスが効かなくなる、ノウハウの共有がしにくいなどのデメリットも発生します。MuleSoftの場合は、モノリスと同様にMuleSoftという技術スタックで完結します。
図9：技術仕様・要件充足の比較
パフォーマンス
モノリスの場合、各機能の連携はプロセス内通信となるため、小さいオーバヘッドで高速な処理が可能です。マイクロサービスの場合、連携先システムのロケーションに応じてサービス単位で最適なシステム配置が可能である一方、サービス間の通信はHTTPなどのネットワーク通信となるため、通信オーバヘッドを考慮した方式設計等が必要です。MuleSoftの場合もマイクロサービスと同等にメリット、デメリットが発生します。
図10：パフォーマンスの比較
運用／監視
モノリスの場合、シンプルなアーキテクチャであるため運用／監視もシンプルに実現が可能です。マイクロサービスの場合、複数サービスの運用／監視が必要であるため、マイクロサービス用の監視製品を導入するなどの対処が必要です。また、監視製品を導入したとしても、システム拡張に伴うサービス追加する際に、管理漏れが発生するなどの懸念が生じます。MuleSoftの場合、MuleSoft上のアプリケーションは標準機能で管理可能です。新たなAPIを追加したとしても、管理漏れなども発生しません。また、マッシュアップされたAPIをビジュアルに表示するツールも存在するため、障害時にその影響を確認することも容易です。
図11：運用／監視の比較
データの一貫性
単一のデータソースで完結するシステムは障害発生時にDBMSのロールバック機能で簡単にリカバリが可能ですが、複数のデータソースで構成されるシステムは障害発生時のデータ一貫性のためのリカバリ方式を考慮しなければなりません。モノリス、マイクロサービス、MuleSoftいずれのアーキテクチャにおいても、この考慮は必要です。しかし、モノリスは単一アプリケーション内でリカバリ処理を制御できるため、比較的簡単な実装でリカバリ処理を実現することが可能です。一方、マイクロサービス、MuleSoftの場合はサービスを跨いだリカバリ処理が必要なため、その実装は非常に複雑なものになりがちです。自動リカバリではなく手動リカバリも視野に対応方針を検討する必要があります。
図12：データの一貫性の比較
以上に示した、各観点、各アーキテクチャの特徴をまとめると下図になります。
MuleSoftはモノリス、マイクロサービスそれぞれのメリットを享受できるサービスと言えるでしょう。
図13：モノリスとマイクロサービスとMuleSoftの比較
おわりに
本稿では、マイクロサービス視点でMuleSoftの特徴についてご紹介しました。
MuleSoftはマイクロサービスのメリットを手ごろに受けられるiPaaSで、マイクロサービスのメリットはそのままに、マイクロサービスのデメリットもカバーしています。
一方、本稿の主旨とは逸れますが、MuleSoft固有のデータ変換言語（DataWeave）、バッチ処理（Batch Job）の効率的な実装方法など、MuleSoft開発特有の難しさも存在しています。これらの難しさに対して、NTTデータは開発ノウハウを蓄積しています。社内の開発標準であるTERASOLUNAをベースとしたMuleSoft開発ガイドライン、データ一貫性を考慮したMuleSoftアプリケーションの実践ハンズオン、MuleSoftの開発／運用を補助するライブラリなど、様々な知見を有しています。
以上、NTTデータは今後もMuleSoftを含むiPaaSの取組に注力していく予定です。iPaaS導入を検討されている場合は是非お声がけください。
