Mulesoftの日本初回 Meets up 参加レポート

はじめに

2018年初頭にSalesforceに買収された Mulesoftの日本での初回Meetsup (2018/7/11)に参加してきたので、そのレポートになります
（聴きながら書いているので多少乱文になります）

Session1 : AnyPoint Platform概要と日本市場での状況

• MuleSoftの基本

  • APIドリブンのアプローチで、組織の変革を引き起こす、デジタルトランスフォーメンションを引き起こす、ことがゴール
  • その根幹となるのがAnypoint Platform
  • Enterprise Integration Platform as a Service (インフォマティカとか) + Full Life Cycle API Management (googleに買収されたApegeeとか)みたいなイメージ

• API Management　とは

  • 間にAPIプラットフォームを挟むことで、バックエンドのDBやフロントエンドのアプリ層が変更されても、柔軟に変更に対応できるとのこと
    
  • フルライサイクルAPIマネジメントについては詳細は下記のリンクを参照

フルライフサイクルAPI管理 api-lifecycle-management

• Mulesoftの今後

  • 買収はされたが、SalesForceのものしか連携できない、とかは今後もない
  • MuleSoftにはまだ日本法人がなく、従業員は不在
  • 日本法人の設立時期は、未決定。（近いとはいうものの・・・）
  • AWSの東京リージョンにデプロイできるが、日本法人を介して購入はできない
  • 買いたい場合は北米に直接連携するか、SalesForceに買収される以前に販売チャネルを持っているオージス総研とかに連絡を取る

• Anypoint Plaftorm

  • APIのDesign, Dev, Test, Deploy, Operate, Scaleまで一気通貫でできる
  • Control Plane で実装、モックアップ、監視、第三者の開発物を共有、とかできる模様
    • Design機能
      • API DesignerでAPIを作成、Mocでテスト、アプリケーションの実装
      • classloaderが入っているためゼロダウンタイムで開発できる
    • Engage機能
    • Manage機能
  • Runtime Plane で実行、横展開
    • Run機能
    • Scale機能

• 各アプリケーションをAPI化し、APIネットワークにする

  • 新機能の開発や既存の変更に対して、Muleが処理の間に入ることで変更の波及を緩和する
  • APIネットワーク内で不具合が起きた場合、Muleの機能でバグ箇所を検知する
  • Application Networkの中でセキュリティもかけることができる

Session2 : MuleSoftの紹介と3レイヤーアーキテクチャ

• MuleSoftの開発において重要となるアーキテクチャの説明
• 一言でまとめると、画面系のフロントエンド層のAPI群とレガシーシステム系のバックエンド系のAPI群の間に、Process系のAPI群を置くことで、画面の変更やレガシーシステムの変更が、ダイレクトに相互に影響を与えないようにする考え方

• 以下、英語のメモ。重要そうなところは日本語で補強。

• Why Mulesoft

  • 4.4 bilioon integration transactions per month
  • 1000 + customers
  • 175,000 + developers
  • Engage customerws with various business channels like mobile, web, etc
  • collablolate with partners via new channels
  • accerlerate employee productivity with micro-apps

• Point to Point Application Integration vs Micro-Service Integration

  • many point of systems with many point of mutual integration, which is impossible to be managed
  • SOA is nice and great idea, but when it comes to big, it'll be chaos
  • the goal of SOA is hard to be achieved

• Buildding Blocks

  • interface
    • presentation
  • orchastration
    • logic
  • connectiviety
    • acccess to source data

• Three layer architecture (3 types of API)

  • First Layer (Experience APIs)
    • purposeful APIs
    • Apps Development Team will be responsible for this layer
  • Second Layer (Process APIs)
    • orchestration
    • composable apis
    • micro-services
    • lob Dev Team will be respobsible for this layer
  • Third Layer (System APIs)
    • legacy modernization (connect to legacy system)
    • Central IT Team will be respobsible for this layer
  • 例として出ていたのが、銀行の融資審査
    • First Layerがログインとかの機能を提供
    • Second Layerが与信審査の機能を提供
    • Third LayerがDBから情報を返したりする機能を提供
    • 画面系が変更されても、DBのテーブルに変更があったとしても、それぞれ疎結合になっているため、変更のインパクトが相互にダイレクトには伝わらない

• Business benefit

  • it as a platform for the business
  • increase developer productivity through re-use
  • more predicable change

• Technical benefits

  • distributed and tailored approach
  • greater agility through loose coupling of sysetems
  • deeper operational visibility

Session3 : Mule Runtimeのアーキテクチャコンセプト ～EIP、Conversation Patterns、SEDA、Non-blocking～

• システム間連携は考慮点が多く簡単ではない

  • 同期なのか非同期なのか、リアルタイムなのかバッチなのか、1:1, N:1, N:Nなのか
  • データサイズ
  • 連携頻度
  • プロトコル、データ形式
  • 経路の信頼性、エラー処理

• EIP (enterprise integration patterns)

  • システム連携にパターンを65種類を網羅した本
  • Mule, Camel, Spring Integration
  • システム連携の共通言語、連携アーキテクチャの議論の出発点

• システム関連系のパターン

  • fire and forget
  • asynchronous request-response
  • request-response with retry
  • polling
  • subscribe-notify
  • quick acknowledgment

• 一貫性に関するパターン

  • ignore error
  • compensating action
  • tentative operation
  • coordinated areement

• Mule3からMule4での大きな更新

  • セルフチューニング
    • システム間連携の時のチューニングをよしなにやってくれる模様

Session4 : Mule ESBを使ってデータベースへのRESTfulなWeb APIを作る

内容やソースはQiitaとGitで公開されているので、そちらを参照

Mule ESBを使ってデータベースへのRESTfulなWeb APIを作る