MuleSoft Platform Integration アーキテクトのお勉強

MuleSoft

Last updated at 2026-10-16Posted at 2026-10-15

はじめに

Salesforce 認定 MuleSoft Platform Integration アーキテクト（旧称：MCIA - Level 1） の受験に向けて、「いろんな用語は聞いたことがあるけれど、MuleSoft全体のアーキテクチャが頭の中で繋がっていない…」という状態から、約3時間で一気に全体像の理解と頻出パターンの暗記を完了させるためのまとめ記事です。

MuleSoft公式ドキュメントの仕様と試験で問われやすいアーキテクチャのトレードオフ、さらに引っかけ選択肢を確実に切るための周辺知識（Mule 4のスレッドモデル、クラスローダー分離、トランザクションアクション、CloudHub 2.0との違いなど）まで体系的に網羅しています。

📌 試験の基本情報（おさらい）

正式名称：Salesforce 認定 MuleSoft Platform Integration アーキテクト（MCIA）
問題数 / 試験時間：60問（単一・複数選択式） / 120分
合格ライン：70%
姉妹資格（MCPA）との違い：
- MCPA（Platform Architect）：全社的なAPI戦略、C4E組織論、API Managerでのポリシー設計など「プラットフォーム全体（アプリケーションネットワーク）」が主眼。
- MCIA（Integration Architect）：ランタイムの内部構造、クラスタ・ネットワーク設計、トランザクション（XA/Saga）、非同期キュー、バッチ処理、MUnitなど**「Muleアプリケーションの実装・詳細設計と非機能要件」**が主眼。

🕒 3時間攻略ロードマップ

【1時間目】Muleの全体像とインフラ・ネットワーク設計（Control Plane / Runtime Plane / VPC / LB / クラスタ / スレッドモデル）
【2時間目】Muleアプリ内部の設計とデータ・状態管理（API-led / キュー / Object Store / トランザクション / バッチ・ストリーミング）
【3時間目】セキュリティ・CI/CD・監視・直前暗記チェックリスト（mTLS / 暗号化 / クラスローダー / Maven・CLI / ロギング）

【1時間目】Muleの全体像とインフラ・ネットワーク設計

まずは「どこで管理し（Control Plane）、どこでアプリが動くのか（Runtime Plane）」という全体像を整理します。

1. Anypoint Platformの全体像（Control Plane と Runtime Plane）

MuleSoftは**「管理画面（Control Plane）」と「アプリの実行環境（Runtime Plane）」**が明確に分離されています。

① Control Plane（管理プレーン）の主要コンポーネント

Design Center (API Designer)：RAMLやOAS（OpenAPI Specification）を使ってAPI仕様やフラグメント（再利用可能なデータ型定義など）を設計する場所。
Anypoint Exchange：API仕様、コネクタ、テンプレート（ベストプラクティスを組み込んだプロジェクトの骨格）、**API Notebook（半技術者向けの対話型ドキュメント）を共有する社内ストア。アセットの閲覧・編集権限はチーム（Teams）**を使って制御します。
- (周辺知識) Exchange上のAPIを社外開発者向けにブランド化したWebポータルとして公開したい場合は API Community Manager (ACM) を使います。
API Manager：APIにセキュリティやレート制限などの「ポリシー」を適用する場所。
- 💡 重要（Autodiscovery）：MuleアプリにAPI Managerのポリシーを適用するには、まず仕様をExchangeに公開してAPI ManagerでAPI Instance IDを発行し、Muleアプリ側の API Autodiscovery 設定にそのIDを紐付ける必要があります。
Runtime Manager：Muleアプリをデプロイし、起動・停止、ワーカー数の変更、アラート設定、ログ管理を行う場所。
Anypoint Visualizer (追加知識)：デプロイされたMuleアプリ間の依存関係（Experience ➔ Process ➔ System APIの呼び出し関係）やトラフィックを**自動的に可視化（アーキテクチャ図を自動生成）**し、ポリシー適用の抜け漏れやボトルネックを把握するツール。

② Runtime Plane（実行プレーン）のデプロイモデル比較【超頻出】

どこでMule Runtimeを動かすかによって、アーキテクチャ上の制約が大きく異なります。

デプロイモデル	アーキテクチャの特徴	試験で狙われる設計ポイント・制約
CloudHub 1.0	MuleSoftがAWS上で提供するフルマネージドPaaS。 1アプリ＝専用VM（Worker）で動作（Linuxベース）。	・ゼロダウンタイム更新：再デプロイや設定変更時、新Workerが起動完了するまで旧Workerがリクエストを処理し続ける。・Windows Serverは非対応。・Muleドメインプロジェクトは使用不可（1ワーカー1アプリで完全分離されているため）。
CloudHub 2.0 (周辺知識)	AWS上のマネージドKubernetesベースに進化したPaaS。WorkerではなくReplica（コンテナ）として動作。	・VPCの代わりに Private Space を使用し、DLBの代わりに組み込みの Ingress Controller が自動でルーティングを行う。 ※試験問題で単に「CloudHub（Shared Worker Cloud / VPC / DLB）」と書かれていたら CloudHub 1.0 の仕様で解答すること！
Runtime Fabric (RTF)	顧客のAWS/Azure/GCPやオンプレVM上に構築するコンテナ（Docker/K8s）基盤。	・コンテナ化されているため実行環境の一貫性が保証され、アプリごとのポート競合管理が不要（すべて同一ポート8081等で待受可能）。既存アプリの書き換えも不要。・Windows Serverは非対応。・Anypoint Security（Edgeポリシー / トークン化）を適用するには適切なライセンス権限とインバウンド通信設定が必要。
Customer-hosted (オンプレミス等)	顧客自身のオンプレサーバーやクラウドVMにMule Runtimeを直接インストールして運用。	・1つのMule Runtime上に複数のMuleアプリを同居させられる。・Windows Server必須のネイティブライブラリ/カスタムコネクタがある場合はこれ一択。・同居する複数アプリ間でHTTPリスナー（同一ポート）やDB接続設定を共有するには Muleドメインプロジェクト（Mule Domain Project）を使う。

💡 周辺知識①：Control Plane自体のホスティング場所
通常、Control PlaneはMuleSoftのクラウド（US / EU / GovCloud）にありますが、厳格な規制により「管理画面のメタデータすら外部クラウドに出せない」場合は、顧客環境内にControl Planeごと構築する Anypoint Platform Private Cloud Edition (Anypoint PCE) を選択します。

💡 周辺知識②：3つのAPIゲートウェイの使い分け

Mule Gateway：Mule Runtimeに組み込まれた標準ゲートウェイ（AutodiscoveryでMuleアプリを直接保護、またはAPIプロキシアプリをデプロイして保護）。

Anypoint Flex Gateway（現 Omni Gateway）：Envoyベースの超軽量ゲートウェイ。Linuxサービス、Docker、K8s Ingressとしてどこでも動作し、Mule以外のAPI（非Mule API） も保護可能。UIで管理する Connected Mode と、YAML設定ファイルで宣言的にCI/CD管理する Local Mode の2種類がある。

Anypoint Service Mesh：IstioとKubernetes上で動く非Muleマイクロサービス群の内部通信（East-Westトラフィック）をサイドカープロキシで管理する仕組み（Connected Modeのみ）。

2. CloudHub 1.0 のネットワークとロードバランサー【超頻出】

CloudHub 1.0 にアプリをデプロイすると、デフォルトで共有ワーカークラウド上で動き、<アプリ名>.<リージョン>.cloudhub.io というURL（FQDN）が付与されます。

① SLB（共有ロードバランサー）と DLB（専用ロードバランサー）の違い

機能・要件	SLB（Shared LB：標準・無料）	DLB（Dedicated LB：有料・Anypoint VPC必須）
カスタムドメイン（バニティURL）	❌ 不可（`*.cloudhub.io` のみ）	⭕ 可能（`api.acme.com` 等。自社DNSでDLBのパブリックAレコードへ CNAME を向ける）
サーバー証明書（X.509）	❌ MuleSoft提供の証明書のみ	⭕ 自社のカスタム証明書を登録可能（証明書はMuleアプリ内ではなくDLBに設定する）
双方向TLS（mTLS）	❌ 不可	⭕ 可能（DLBでクライアント証明書を検証可能）
IPホワイトリスト（Allowlist）	❌ 不可	⭕ 可能（アクセス元IPレンジの制限が可能）
URLマッピングルール変更	❌ 不可	⭕ 可能（URLパスやサブドメインに応じて裏側の異なるMuleアプリへ振り分け可能）
待受ポートのルール	外部からの `80/443` を、Muleアプリの `http.port (8081)` / `https.port (8082)` へ転送	外部からの `80/443` を、VPC内のMuleアプリの `http.private.port (8091)` / `https.private.port (8092)` へ転送

⚠️ 【公式仕様】Anypoint VPCのファイアウォールとワーカーURLの仕組み

Anypoint VPCはインバウンド通信のみを制限し、アウトバウンド通信は制限しません。

CloudHubのDNSには以下の3種類があります：

<app>.<region>.cloudhub.io（SLB経由）

mule-worker-<app>.<region>.cloudhub.io（WorkerのパブリックIP直指定：8081/8082）

mule-worker-internal-<app>.<region>.cloudhub.io（VPC内部のプライベートIP直指定：8091/8092）

本番環境でSLBやワーカーのパブリックIP直叩きを禁止し、DLB経由またはVPC内部からのアクセスのみに強制するには、VPCのファイアウォールルールからデフォルトの 8081/8082（Anywhere許可）を削除し、8091/8092（Local VPCのみ許可） でアプリを待ち受けさせます。

② プライベートネットワーク接続（Anypoint VPC）

CloudHub上のアプリから、インターネットに出さずに社内（オンプレ）や自社AWSと通信したい場合は Anypoint VPC を構築します（※ベースサブスクリプションには通常本番用・非本番用の2つのAnypoint VPCライセンスが含まれ、一度作成したVPCの名前・リージョン・CIDRブロックは後から変更不可です）。

対顧客AWS VPC（同一リージョン）：VPC Peering（VPCピアリング） または AWS Transit Gateway で直結します（※社内ネットワークやピアリング先のCIDRとIP帯が重複しないように設計すること）。
対オンプレミスデータセンター：IPsec VPNトンネル（Anypoint VPN） または AWS Direct Connect で接続し、双方でファイアウォールルールを合わせます。

③ 【必出計算】Anypoint VPCのIPアドレス（CIDR）サイジング

Anypoint VPCを作成する際、将来を見越したCIDRブロック（最小 /24 ＝ 256 IP 〜最大 /16 ＝ 65,536 IP）の計算問題が必ず出ます。

【試験問題の解き方（最小IP計算）】：
ゼロダウンタイムデプロイ時は「旧ワーカー」と「新ワーカー」が同時にIPを消費するため、最低でもワーカー数の2倍のIPが必要です。
$$\text{最小必要IP数} = \text{環境数} \times \text{アプリ数} \times \text{アプリあたりのWorker数} \times \mathbf{2\text{（ゼロダウンタイム用）}}$$
- 過去問の計算例：「3つの本番環境 × 150アプリ × 各2 Worker」の場合
  $3 \times 150 \times 2 \times 2 = \mathbf{1,800\text{ IPs}}$ ➔ これを超える最小のCIDRブロックは /21（$2^{32-21} = 2,048\text{ IPs}$） が正解！（/22 は 1,024 IPなので不足）。
【公式ドキュメントの厳密な仕様（AZ分割の考慮）】：
MuleSoft公式の『Provision a VPC』ガイドでは、高可用性のためにVPCサブネットが内部で最大4つのAvailability Zone (AZ) に分割され、さらにインフラ予約IP（ネットワークアドレスとブロードキャスト等）が引かれる仕様になっています。そのため、1つの /24（256 IP）でデプロイ可能な最大ワーカー数は $(256 - 2) \div 4\text{ AZ} \div 2\text{ (ゼロダウンタイム)} \fallingdotseq \mathbf{31\text{ Workers}}$ となります。問題文に「4つのAZを考慮せよ」という条件があるかないかで使い分けてください。

3. Customer-hosted（オンプレ）のクラスタと高可用性（HA）

オンプレミス等で複数のMule Runtimeを束ねる場合、「サーバーグループ（Server Group）」と「ランタイムクラスタ（Cluster）」の2種類があります。

① ランタイムクラスタ vs サーバーグループ

サーバーグループ：単にRuntime Managerから複数サーバーへ一括デプロイ・管理するための論理グループ。ノード間のメモリ共有や自動フェイルオーバー機能はありません。
Muleランタイムクラスタ（Active-Active）：複数ノード（最大8ノード推奨）間でインメモリデータグリッド（Hazelcast）を共有し、状態（Object Store）やVMキューを共有して協調動作する構成。
- 高可用性（HA）のレベル順：ダウンタイム最小・コスト制約なしなら Active-Active（クラスタ） が最強（以下、Hot Standby ➔ Warm Standby ➔ Cold Standby の順）。

② クラスタの挙動とポーリングの鉄則【超頻出】

プライマリノードとポーリング：ファイル監視（On New or Updated File）やDB監視（On Table Row）、スケジューラーは、複数ノードが同時に取りに行って重複処理するのを防ぐため、デフォルトでクラスタ内の「プライマリノード（1台）」のみが実行します。
プライマリノード障害時の動き：
1. プライマリノード（例：ノードA）が停止すると、セカンダリノード（例：ノードB）が自動的にプライマリに昇格し、ポーリング処理を引き継ぎます。
2. その後、元のノードAが復旧してクラスタに戻っても、プライマリはノードBのまま維持されます（勝手に主導権を奪い返しません）。
3. なお、クラスタの前段にロードバランサーを置かず、クライアントが各ノードのIPに直接HTTPリクエストを送信している場合、停止したノードへの通信は失敗し、生きているノードへの通信だけが処理されます。
クラスタへのノード追加時に手動設定が必要なもの：
- クラスタ内部の通信やObject Storeの共有は自動認識されますが、「外部ロードバランサーの振り分け先」「外部の監視ツール」「外部のログ収集エージェント」には新ノードの追加設定が必要です。
ノード増減とパフォーマンスの算数：
- 2ノード ➔ 4ノードに倍増：クラスタ全体のキャパシティは倍になり、各ノードが受けるリクエスト数は50%減少します（※単一リクエストの応答時間＝レイテンシーが半分になるわけではありません！）。
- 4ノード中2ノードが停電（残り2ノード）：残りのノードのキャパシティに余裕があれば全体のスループットは維持され、**生き残った各ノードが処理するリクエスト数が100%増加（2倍に）**します。

4. Mule 4 のリアクティブ・イベント処理とスレッドプール

「性能を上げるためにスレッドプール（wrapper.conf等）をいじるべきか？」という選択肢を切るための公式仕様です。

非ブロッキング・リアクティブ実行エンジン：
- Mule 3までは開発者がフローごとにスレッドプールを手動チューニングしていましたが、**Mule 4からはイベントプロセッサの種類に応じてMule Runtimeが自動的にスレッドプールを切り替えて最適化（Proactorパターン）**します。
3種類の処理タイプとUBERスレッドプール：
1. CPU_LIGHT：非ブロッキングI/Oや高速な処理（HTTPルーティング、フィルタリングなど）。
2. CPU_INTENSIVE：DataWeave（Transform Message）など、CPUを長時間使う変換処理。
3. BLOCKING_IO：DB接続（JDBC）やトランザクション、ファイル操作など、応答を待つブロッキング処理。
- Mule 4.3以降ではこれら3つを1つの UBERスレッドプール で動的共有する方式がデフォルトになっています。Mule全体の wrapper.conf やスレッドプール設定を手動変更するのは、同居する他アプリやランタイム全体に悪影響を与えるためアンチパターン（NG） です。

【2時間目】Muleアプリ内部の設計とデータ・状態管理

次に、APIをどう分割し、データをどう連携・保持・変換するかというアプリケーション設計のルールを固めます。

1. API-led Connectivity（3層アーキテクチャ）と C4E・CDM

① 3つのレイヤーの役割と設計ルール

Experience API（エクスペリエンス層）：Webアプリ、モバイルアプリなど、特定のコンシューマー（利用者）ごとにデータを整形・提供する窓口。
Process API（プロセス層）：特定のバックエンドやフロントエンドに依存せず、複数のデータを組み合わせるビジネスロジック・オーケストレーション層。
System API（システム層）：DB、SAP、Salesforce、メインフレームなどの基幹システム（System of Record）に直接繋がり、裏側の複雑なプロトコルや変更を隠蔽する層。
- ⚠️ 注意：1つのSystem APIが「複数の異なるバックエンドドメイン（例：ERPとCRMの両方）」に直接繋ぐのはアンチパターンです。

② 【引っかけ注意】いつでも3層すべて作るわけではない！

例外パターン：「1つのクライアントから1つのレガシーシステムへデータを送るだけで、今後他のどこでもデータの再利用やロジックの共有が一切発生しない」と明記されている場合、わざわざProcess APIや共通データモデル（CDM）を作るのはオーバーエンジニアリングです。Experience API ➔ System API と直結させるのが最もシンプルで正解となります。

③ CDM（Canonical Data Model：共通データモデル）と C4E

CDM（共通データモデル）：全社で統一した標準データ形式。主に Process API レベル で使用されます。クライアント固有の形式に合わせるべき Experience API には通常CDMを使いません。また、無理にすべてのデータ型をCDMで定義する必要もありません。
C4E（Center for Enablement）のKPI：C4Eの目的は「APIやアセットの再利用による開発加速」です。したがってC4Eの成功指標（KPI）は「作ったAPIの総数」ではなく、**「各事業部（LOB）のAPIのうち、C4Eが公開した共通APIや資産と接続（再利用）している数・割合」**で測ります。

2. 非同期メッセージング（Anypoint MQ / VM Queue / JMS）の使い分け

どのキューをいつ使うかは、以下の比較表で一発で見分けられます。

サービス・機能	特徴・使われるシチュエーション	試験で必ず狙われるトラップ（ここが出る！）
Anypoint MQ	MuleSoftのクラウドメッセージング（PaaS）。ポート 80/443（HTTPS）で通信できるため、FW制限が厳しい環境やMuleアプリ外（外部コンシューマ）との連携に最適。	・1対1のコマンド送信は Queue、1対多（ブロードキャスト/Pub-Sub）は Exchange を使う。・⚠️ トランザクション（XAやローカル）には非対応！・順序保証が必要なら FIFO Queue を使う。
VM Queue	同一Muleアプリ内（または同一Muleクラスタ/同一CloudHubアプリの複数Worker間）のフロー間で非同期受け渡しをする軽量キュー。外部アプリとは連携不可。	・CloudHubでWorkerクラッシュ時にデータ消失ゼロにするには、Runtime Managerで Persistent Queues（永続キュー）にチェックを入れ、Workerを2台以上にスケールアウトする。・複数Worker環境で永続VMキューを使うと、メッセージは非決定的（非ラウンドロビン）に利用可能な任意の1つのWorkerへ少なくとも1回（At-least-once）振り分けられる。
JMS (ActiveMQ等)	標準メッセージブローカー。通信プロトコルはJMSプロバイダー側が決定する。	・1対1（コマンド）は JMS Queue、1対多（イベント通知）は JMS Topic を使う。送信側と受信側は同じJMSプロバイダーを共有する。・⭕ トランザクション（ローカル / XA）に対応！

💡 DBのポーリング制限がある場合のリアルタイム連携パターン
DB側の制約で「1時間に10回しかSELECT（ポーリング）してはいけない」といった制限がある場合、Muleの On Table Row は使えません。DB側のトリガー＆ストアドプロシージャからMuleのHTTPエンドポイントへRESTコールさせ、Muleから Anypoint MQ Exchange へ投げて複数システムへPub/Sub配信するのが正解です。

3. Object Store（状態管理・キャッシュ・Watermark）

① 主な用途

Cacheスコープ（Caching）：GETリクエスト等の応答速度（Responsiveness）を上げるため、特定のフロー処理やサブフローの結果をObject Storeにキャッシュします（API ManagerでHTTP Cachingポリシーをかけるより、アプリ内部で細かく制御したい場合に有効）。
- Cacheスコープはデフォルトでインメモリ（非永続）ですが、クラスタや複数Worker間でキャッシュを共有したい場合は 永続Object Store（Persistent Object Store） を指定します。また、ペイロードが消耗型ストリーム（Non-repeatable stream）の場合はキャッシュできない点に注意が必要です。
Watermark（ウォーターマーク）：定期同期（例：5分おきにSalesforceから差分取得）で「前回どこまで読んだか（最終更新日時や最大ID）」を複数Worker間で共有するには、永続オブジェクトストア（Persistent Object Store） に保存します。

② 【超頻出】別アプリや別環境からの Object Store v2 アクセス方法

Object Store Connector で直接共有できるのは 「同一CloudHubアプリの複数Worker間」 のみです！
別のCloudHubアプリ間（例：Inventoryアプリ ⇔ Cleanupアプリ） や、RTF ⇔ CloudHub間 でObject Store v2のデータにアクセス・削除したい場合は、コネクタではなく Object Store v2 REST API をHTTP Requestで呼び出します。
Object Store v2 REST APIの公式仕様と認証手順：
1. 対象CloudHubアプリのRuntime Manager（Object Store画面 ➔ Show Client Credentials）または Connected Apps から client_id と client_secret を取得する。
2. Anypoint Platformの認証エンドポイント（https://anypoint.mulesoft.com/accounts/oauth2/token または /accounts/api/v2/oauth2/token）へ grant_type=client_credentials でPOSTし、Bearerトークン を取得する。
3. Authorization: Bearer <token> ヘッダーを付与して Object Store v2 REST API を呼び出す（※公式仕様上、このAPIには1クライアントアプリあたり10リクエスト/秒のレート制限があります）。

③ 【引っかけ注意】Object Storeを使わないケース

JMSからメッセージを受信し、そのフロー内で同期的に冪等（idempotent）なSOAPサービスを呼んでCorrelation IDを照合し、すぐ応答キューへ返すだけ（Competing Consumersパターン）なら、わざわざObject Storeに永続化する必要はありません。**Muleイベントの変数（Variables）や属性（Attributes）**に持たせるだけで十分です。

4. トランザクション管理（ローカル vs XA vs Saga vs Reliabilityパターン）

① トランザクションに参加できるコネクタ（暗記必須！）

Mule 4でトランザクション（イベントソースやTryスコープでのトランザクション開始）に対応しているのは、以下の 3つだけ です。

⭕ Database (JDBC)、JMS、VM
❌ 非対応：HTTP、SFTP、File、Anypoint MQ、Object Store、Salesforce 等

② ローカルトランザクション（Single Resource） vs XAトランザクション（Extended Architecture）

種類	特徴・参加条件	試験で狙われる仕様・注意点
Single Resource (Local) (デフォルト)	同一コネクタ種類かつ同一Global Configuration（`config-ref`）内の操作のみ参加可能（例：1つのDB設定内での複数INSERT）。	・XAより高速。・ネストされたトランザクション（Nested transactions）は非対応。
Extended Architecture (XA)	2つの異なるデータベース間や、JMS ＋複数DB間など、異なるリソースをまたいで2フェーズコミット（2PC）により完全な一貫性（All-or-Nothing）を保証する。	・ロック調整が入るためパフォーマンスは大幅に低下する。・ネストされたトランザクションに対応。・1つのトランザクション内に複数のメッセージソースは持てない。・オンプレ等では Bitronix Transaction Manager をGlobal Elementsに定義して調整役とする（デフォルトタイムアウト60秒）。・手順の鉄則：①XAトランザクションを開始してJMSを読む ➔ ②同じXAトランザクション内で両方のDBにInsertする（個別ACKはしない）。

③ 【追加知識】Transactional Action（トランザクションアクション）の5種類

各オペレーションがトランザクションにどう関わるかを定義する属性です。

ALWAYS_BEGIN：常に新しいトランザクションを開始する（すでにSingle Resourceトランザクションが存在する場合はエラー、XAが存在する場合はネストされたトランザクションを作成）。
BEGIN_OR_JOIN：進行中のトランザクションがあればそれに参加し、なければ新規に開始する。
ALWAYS_JOIN：常に進行中のトランザクションへの参加を期待する（進行中のトランザクションがなければエラー）。
JOIN_IF_POSSIBLE：進行中のトランザクションがあれば参加し、なければトランザクションなしで実行する。
NONE：トランザクションに参加しない。

④ Sagaパターン（補償トランザクション）と Reliability Pattern（信頼性パターン）

Sagaパターン：航空券・ホテル・レンタカーなど複数のSystem API（REST/HTTP）をまたぐビジネストランザクションでは、HTTPがXA非対応のためXAは使えません。各System API内部でローカルトランザクションを実装し、全体は Sagaパターン で連携し、失敗箇所に応じて 補正アクション（Compensating actions：キャンセル処理） を実行します。
Reliability Pattern（信頼性パターン） (追加知識)：HTTP ListenerやFile/SFTPなどトランザクション非対応のイベントソースからデータを受け取る際、データ消失をゼロ（At-least-once）にするためのMule公式パターン。受信直後のメインフローでまず永続VMキューやJMSキューにメッセージを格納してからクライアントへ応答（202 Accepted等）を返し、後続のトランザクション対応フローでキューから取り出して処理します。

5. ルーティング・バッチ処理・エラーハンドリング・データ変換

① 複数処理・大量データ処理の使い分け

コンポーネント	特徴・選ぶべきキーワード
Scatter-Gather	複数のAPI（在庫APIと販売履歴APIなど）を同時並行（マルチスレッド）で呼び出し、最小のレイテンシーで全ルート完了後に結果を結合（`Object` of `MuleMessage`）する。
For Each	配列やCSVの各行を単一スレッドで元の順序通りに1件ずつ同期処理する（完了後のペイロードは元の入力のまま）。 💡 1件失敗しても他を止めずにログだけ出す方法：For Eachの中に Tryスコープ（On Error Continue）を入れる！
Parallel For Each	コレクションの各要素を並列に分割処理し、すべて終わったら元のフローに合流（出力は各処理後のペイロードのリスト）する。
Batch Job	数百万〜数千万件のCSV/DWH同期（バッチトリガーETL）など、メモリを超える大量データを非同期処理する。最後のBatch Step内で Batch Aggregator ＋ DB Bulk Insert を使うと最速。

② Batch Jobの内部仕様とチューニング【超頻出】

Batch Jobの3フェーズ：
1. Load and Dispatch：入力データを分割し、**永続キュー（ディスク）**に書き込む。
2. Process：複数スレッドがキューから Block size（デフォルト100件） 単位でメモリに読み出し、各Batch Stepインスタンスへ 一度に1レコードずつ ペイロードとして渡して、ステップ内およびステップ間で**並列（任意の順序）**で処理する。
3. On Complete：成功件数や失敗件数のサマリ（BatchJobResult）を集計して終了処理を行う。
Batch Stepのフィルタリング属性 (追加知識)：
- acceptExpression：DataWeave式が true のレコードだけをそのステップで処理する。
- acceptPolicy：NO_FAILURES（デフォルト：前のステップで成功したものだけ処理）、ONLY_FAILURES（前のステップで失敗したエラーレコードだけを救済・ログ処理）、ALL（すべて処理）の3種類。
Batch Jobを高速化する方法：
- ⚠️ 注意：Customer-hostedでクラスタノード数を増やしてもBatch Jobはスケールしません。
- 正解のチューニング：アプリの設計で Batch Jobの同時実行数（Max Concurrency）とレコードブロックサイズ（Block size）を大きくすること！（Mule全体のwrapper.confは他アプリに影響するため触らない）。

③ エラーハンドリングと障害回復・リトライの使い分け

On Error Continue vs On Error Propagate：
- On Error Continue：エラーを処理して「正常終了」として扱い、呼び出し元には HTTP 200 OK（または正常レスポンス）を返します。トランザクションはコミットされます。
- On Error Propagate：エラーを処理した後、上位へエラーを再スロー（伝播）し、トランザクションをロールバックさせ、呼び出し元には HTTP 500 Server Error を返します。
コネクタの再接続戦略（Reconnection strategy）：JMSブローカーの定期メンテ（10分停止）やDBの4時間停止など、インフラ接続自体の切断からMuleアプリの再起動なしで自動回復させるために設定します。
Until Successfulスコープ：高可用でないレガシーバックエンドAPIの呼び出しが一時的に失敗した際、成功するまで一定間隔で再試行します。
Dead Letter Queue (DLQ) パターン：バックエンドが長時間停止したり特定メッセージを拒否したりする場合、無限リトライせず、エラー時に ActiveMQ等のDead Letter Queue（DLQ） に退避させ、手動処理対象を最小限にします。

④ ストリーミングとDataWeaveの注意点

Repeatable in-memory stream（反復可能インメモリストリーム）：
- 例：maxBufferSize="512"（KB）の設定で1,000KBのペイロードが来た場合、OutOfMemoryErrorでJVMが落ちるのではなく、ランタイムエラー（StreamMaximumSizeExceededException）がスローされます。
- デフォルトのストリーム戦略は Repeatable file store stream（メモリ上限を超えたら自動でディスクに退避する方式） です。
巨大XMLのストリーミング：巨大なXMLは単一のJavaオブジェクト（POJO/DOM）に変換せず、XMLストリームのまま処理します（DataWeaveでも @StreamCapable と deferred=true でストリーム変換が可能）。
DataWeaveのベストプラクティス：
- Javaの共通オブジェクトモデルのマッピングも、カスタムJavaコードを書くより Transform Message（DataWeave） を使うのが最も簡単です。
- すでに社内に成熟した外部変換サービスがあるなら、Mule内にロジックを複製せず DataWeave（またはフロー）から既存の外部サービスを呼び出す のが適切です。
- ⚠️ application/dw 形式の罠：DataWeave独自の application/dw フォーマットはデバッグ用であり、10MB以下をメモリ保持してパフォーマンスに悪影響があるため本番環境では非推奨です。

【3時間目】セキュリティ・CI/CD・監視・直前暗記チェックリスト

最後の1時間は、知っていれば10秒で解ける知識問題とセキュリティ・運用周りを一気に暗記します。

1. セキュリティ（mTLS・証明書・プロパティ隠蔽・IdP・ポリシー）

① 双方向TLS（mTLS）の Keystore と Truststore【超頻出】

鉄則：「HTTPリスナーで KeystoreとTruststoreの両方 を設定する目的は何か？」と問われたら、答えは必ず 「クライアントとのTLS相互（双方向）認証（mTLS）のサポート」 です！（※通信データの暗号化自体は片方向TLS＝Keystoreのみでも行われるため、引っかけ選択肢に注意）。
Keystore と Truststore に何を入れるか？：

ストア名	役割のイメージ	格納する鍵・証明書
Keystore（キーストア）	「自分の身分証明書」	自分自身の秘密鍵（Private key）と公開鍵証明書（Public key / Certificate）
Truststore（トラストストア）	「信じる相手のリスト」	通信相手（クライアントまたは対向サーバー）の公開鍵証明書（Public key / CA証明書）

② 証明書や認証情報の外部化・共有

オンプレで証明書が頻繁にローテーションされる場合：HTTPリスナー設定は Muleドメインプロジェクト に入れ、サーバー証明書ファイル自体はドメインやアプリのJARファイルの外側にある Muleランタイムのクラスパス上の共有ファイルシステム に配置します。
オンプレとCloudHubの両方からバックエンド認証情報を共有する場合：MuleドメインプロジェクトはCloudHubで使えないため、両方からアクセスできる 外部クレデンシャルサービスを構成し、アプリ起動時に呼び出してプロパティを取得 させます。

③ Runtime Managerでのパスワード非表示化 vs ファイル暗号化

やりたいこと	正しい設定方法
Runtime Managerの「Propertiesタブ」やログ出力でパスワード（`dbPassword`等）を `` とマスクして隠蔽したい	プロジェクトルート直下の `mule-artifact.json` ファイルの `secureProperties` セクションにプロパティ名を配列でリストアップしておく！
YAMLやPropertiesファイル内のパスワード文字列自体を暗号化（`![...]`）したい	Secure Configuration Properties Module を使い、復号キー（Key）はコードに含めずデプロイ時にRuntime Managerのプロパティ等で渡す。

④ Anypoint PlatformのID管理（SSO）と権限（RBAC）

Master Organization（ルート組織）レベルでのみ設定するもの：ユーザーのID管理（外部IdP設定） です（ビジネスグループレベルでは設定しません）。ログイン資格情報を自社で完全制御するには フェデレーションID管理（Federated Identity Management） を使います。
SSOの規格：SAML 2.0 が使えない場合は OpenID Connect (OIDC) を使います。
複数のIdPを事業部（LOB）ごとに使い分ける機能：APIクライアント用のIdP（OAuthプロバイダー）を複数登録してLOBごとに使い分けたい場合は クライアント管理（Client Management） 機能を使います。
外部IdPでは制御できず、必ずAnypoint Control Plane側で行うこと：
- 「ロール（Role）に対するAnypoint Platform権限（Permission）の割り当て」 です（IdP側のグループとAnypointのロール/チームを紐付けるマッピングはできますが、「そのロールにどの環境へのデプロイ権限を与えるか」という中身自体はAnypoint側で定義します）。

⑤ APIポリシーと外部認証

JSON脅威保護（JSON Threat Protection）ポリシー：認証なしで公開しているPOST APIを、極端に巨大なJSONや階層が深すぎる悪意あるペイロード（インジェクション等）から守ります。
クライアントID施行（Client ID Enforcement）ポリシー：ステージング環境等でテストする前には、Exchange/ポータルから 「ステージング環境のAPIインスタンス」へのアクセスをリクエストし、発行されたClient IDとClient Secretを取得 する必要があります。
Muleアプリから外部のOAuth 2.0保護されたAPIを呼ぶとき：自前でトークン管理フローを作らず、HTTP Request Connector標準のAuthentication機能（OAuth 2.0設定） を使います。

2. CI/CD・テスト・自動化ツール

① 自動化ツールの明確な線引き【超頻出】

ツール・API名	できること・使われる場面
Anypoint CLI	APIの作成・Exchangeへの公開・API Manager設定・デプロイなど、Anypoint Platform全体のライフサイクル操作を、プラットフォームREST APIを直接叩かずにコマンドライン/スクリプトで自動化するツール。
Mule Maven Plugin / MUnit Maven Plugin	Muleアプリのコンパイル、パッケージ化（JAR生成）、MUnit単体テスト実行、テストカバレッジ検証、ランタイムへのデプロイを自動化する。 ⚠️ 注意：API DesignerからのインポートやAPI ManagerでのAPIインスタンス作成・ポリシー適用はMavenプラグインの対象外！
Runtime Manager Agent REST API	セキュリティ規制により Runtime Manager（クラウド側）へ一切接続せず、社内ネットワーク内だけでオンプレMuleランタイムへ自動デプロイ・制御する場合、Mule内に導入した Runtime Manager Agent のREST APIを直接呼び出す。
Connected Apps（接続アプリケーション）	CI/CDパイプラインからMule Maven PluginやAnypoint CLIを実行する際、人間のユーザーID/パスワード（MFAあり）を使うのではなく、OAuth 2.0 Client Credentialsで安全に最小権限（スコープ）を付与して自動認証する仕組み。
バイナリーアーチファクトリポジトリ (Nexus / Artifactory等)	CI/CDでMuleアプリのビルド成果物（JAR）や依存ライブラリを「全社共通の場所」で一元管理するために必要。

② テスト戦略（MUnit・パフォーマンステスト）

MUnit（ホワイトボックス単体テスト）：
- 外部のDB（SELECT文）やSOAPサービスには実際に接続せず、Mock Whenプロセッサで外部呼び出しをモック化して単体テストを独立させます。
- カバレッジが80%で止まっている場合の対策：正常系ルートだけでなく、テストが漏れている エラーハンドラー（Error Handler）に対してMUnitテストケースを設定 してカバレッジを引き上げます。
パフォーマンステスト（性能テスト）：
- 「数百万件のデータに対し3秒以内に応答する」といった非機能要件のリスク評価で行います。
- ステージング環境のバックエンドに厳しいレート制限がある場合：そのまま負荷をかけるとバックエンドにブロックされるため、バックエンドの本番性能特性（応答遅延など）を模倣したモックサービスを作成して性能テストを実施します。

3. 監視・ロギング・トレース

① 監視ツールの使い分け

API Functional Monitoring：パブリックインターネット上の Mule APIと非Mule APIの両方 に対して、外部からスケジュール実行で実際にリクエストを投げてヘルスチェック・動作監視を行う機能。
Runtime Managerのアラート：オンプレMuleランタイムに対してカスタムコードなしで出せる標準アラートは 「高いメモリ消費量」や「CPU使用率」 です（※ライセンス有効期限、ディスク空き容量、SSL証明書期限は標準アラートにはありません）。また、PCE環境等で非MuleSoftの外部分析基盤へ分析データを送るのも Runtime Manager の役割です。
Audit Log Query Platform API：「過去1年間に誰がいつ本番APIを停止・変更したか」といったプラットフォーム上の操作履歴（監査ログは最大6年間保持）を調べる際に呼ぶAPI。
JMXエージェント：有効化すると、Muleアプリの再起動なしで実行中に 特定のlog4j2パッケージのログレベルを動的にTRACEへ変更 する操作などが可能になります。

② ロギング（Splunk連携・同期 vs 非同期）

CloudHub 1.0 から外部（Splunk等）のみにログを出す手順：
1. Runtime Managerで CloudHubのデフォルトロギング（Disable CloudHub logs）を無効化 する。
2. 各Muleアプリの log4j2.xml にSplunk用のアペンダー（Appender）を定義 する（※CloudHub 2.0ではカスタムアペンダーは非同期のみサポートされます）。
Customer-hosted（オンプレ）でのみ可能なロギング構成：
- 複数のMuleアプリから1つの共有・カスタマイズされた log4j2.xml（$MULE_HOME/conf/log4j2.xml 等）を直接参照 すること（CloudHubでは1ワーカー1アプリのため、アプリごとに個別の log4j2.xml が必要です）。
同期ロギング vs 非同期ロギングの公式仕様：
- Mule 4のデフォルトは 非同期ロギング（Asynchronous logging） です。ログ出力がメッセージ処理スレッドとは別のスレッドで行われるため高スループット・低遅延ですが、バッファがディスクにフラッシュされる前にJVMがクラッシュすると直前のログが消失するリスクがあります。
- トランザクションと同期ロギング：進行中のトランザクション内で確実に監査証跡を残し、ログ書き込み失敗時に即座にエラーを検知してトランザクションをロールバックさせるには、メッセージ処理と同じスレッドで書き込む同期ロギング（Synchronous logging） が必要です。
- ベストプラクティス：普段のスループットを維持しつつ重要な例外ログの消失も防ぐには、非同期ロガーと同期ロガーの混合構成（通常のINFO/WARNは非同期、致命的な例外のみ同期記録） に構成します。

③ エンドツーエンドの追跡（Correlation ID と MDC）

Experience ➔ Process ➔ System API間で一連の処理ログを紐付けて追跡するには Mule相関ID（Mule Correlation ID） を使います（さらにTracingモジュールの MDC: Mapped Diagnostic Context を使うと、log4j2.xml のパターンにビジネスID等のコンテキスト情報を自動付与できます）。
外部システムから一貫したIDで追跡したい場合：呼び出し元（Javaバックエンド等）が X-Correlation-ID HTTPリクエストヘッダー にIDを入れてMule APIを呼び出せば、Mule側は何のカスタムコードも書かずに自動的にそのIDを correlationId として引き継ぎ、後続のMule APIやJMSへ自動伝播します。

4. 直前暗記チェックリスト（出たら10秒で解ける知識問題）

最後に、細かい仕様やプロトコル、Mule SDK・クラスローダーに関する知識問題をまとめます。

SLAとタイムアウトの計算：
- 下流APIに信頼できるSLAがなく、上流APIのHTTP Requesterでタイムアウトを設定しない場合 ➔ スレッドが枯渇し、上流API自身のSLAを提供（保証）できなくなる。
- 上流APIの目標SLAが「99%が800ms以内」なのに、直列で呼ぶ3つの下流APIの1つ目が「95%で1,000ms」かかる場合 ➔ どんなタイムアウト値を設定しても目標達成は算数的に不可能なので、下流APIと別SLAを交渉するか、より高速な代替APIを呼ぶ しかない。
HTTPステータスコードの解釈：
- HTTP Requestが 3xx を返した ➔ 別のURLにリダイレクトされた。
- HTTP Requestが 4xx を返した ➔ Muleが送信したHTTPリクエスト自体に問題（クライアント側エラー：パラメータ不正や認証エラー等）があったと外部APIが報告した。
プロトコル・言語・コネクタ仕様：
- REST APIの標準インターフェース定義言語：OpenAPI仕様（OAS） または RAML。
- SOAP（WSDL）内でデータ構造を定義する言語：XSD（XML Schema）。
- RESTではなくあえて SOAP / WS-* を選ぶべき要件：すべてのコンシューマーに 有効なSAMLトークン（WS-Security）の送信をメッセージレベルで義務付ける必要がある場合。
- Salesforce連携の2つの留意技術：標準のSalesforce Connector（REST / SOAP / Bulk / Streaming API）に加え、高スループットなイベント連携には gRPC ベースの Salesforce Pub/Sub API Connector（ReplayId とObject Storeを組み合わせてイベント再取得を制御）を使用する。
- IBMメインフレームとSalesforce Marketing Cloudの連携：両方ともRESTをサポートしているなら REST が最もシンプルで適切。
- パブリックインターネット越しの安全なファイル連携：SFTPコネクタ（SSH暗号化）。
- パブリックインターネット越し・クロスプラットフォームで安全なデータ交換技術の組み合わせ：EDIFACT、XML over SFTP、JSON / REST over HTTPS（平文のFTPなどが含まれる選択肢を除外する）。
Mule SDK / Javaクラスローダー分離（Classloading Isolation）の公式仕様：
- Serialization APIの特徴：スレッドセーフ であり、シリアライズ時に OutputStream を渡し、入力ソースとして InputStream を使用できる。
- クラスローダー分離とバージョン競合の条件：本来Mule 4は各コネクタ/モジュールごとにクラスローダーが分離されていますが、1つのMuleアプリ内の2つのカスタムモジュールが同じパッケージ名の別バージョン（例：Joda-Time 2.9.5と2.1.1）を持ち、かつ mule-artifact.json の exportedPackages でそのパッケージを外部公開（Export）してアプリ側で両方を使用した場合、デプロイ自体は成功するものの 片方のバージョンしか読み込まれず、実行時に ClassCastException や NoSuchMethodException が発生しやすくなる（※公式ベストプラクティスでは、GuavaやJoda-Time等のサードパーティライブラリは exportedPackages に含めてはいけません）。

おわりに

MCIA試験は問題文が長文のシナリオ形式になっていますが、問われているコアの知識は上記のパターンの組み合わせです。
問題文を読む際は**「デプロイ先はCloudHub 1.0かオンプレ（クラスタ）かRTFか？」「トランザクション（データ消失ゼロ）が求められているか？」「単一アプリ内か複数アプリ間か？」**というキーワードに目を光らせることで、迷わず正解のアーキテクチャを選び抜くことができます！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up