Anypoint Runtime Fabric の概要

Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。

公開クラウドで作業をしていて、Kubernetes クラスターの管理についてある程度の専門知識がある場合、Runtime Fabric は以下をサポートします。

公開 K8s ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。

Anypoint Runtime Fabric のいくつかの機能を次に示します。

  • アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。

  • 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。

  • 複数のレプリカにわたるアプリケーションのスケーリング。

  • 自動化されたアプリケーションフェールオーバー。

  • Anypoint Runtime Manager を使用したアプリケーション管理。

Anypoint コントロールプレーン機能、Anypoint CLI、Mule Maven プラグインは、すべてのパートナーで広く利用できます。ランタイムプレーンでは、Helm ベースの Runtime Fabric 管理と機能のみが VMWare Tanzu、Alibaba ACK、および Rancher でサポートされています。各プラットフォームでの機能のサポート状況を下表に示します。

ユースケースのサポート状況 AWS EKS および AWS EKS-A IBM Openshift 製品 AKS & GKE VMWare Tanzu、Alibaba ACK、Rancher

Runtime Manager、アクセス管理、Anypoint Monitoring など、Anypoint コントロールプレーンへのアクセスと使用。

はい

はい

はい

はい

Mule Maven Plugin、Runtime Fabric API、Anypoint CLI などの自動化ツール。

はい

はい

はい

はい

互換性のある K8s バージョンでの Runtime Fabric 機能のサポート。

はい

はい

はい

はい

Runtime Fabric コアソフトウェアおよび Mule Runtime Engine イメージのセキュリティ更新。

はい

はい

はい

はい

Helm​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

はい

はい

はい

Helm​ による CRD を使用したアプリケーションワークロードのカスタマイズ。

はい

はい

はい

はい

アプリケーション監視のための Log4j サポート

はい

はい

はい

はい

rtfctl report​ コマンドによるトラブルシューティング。

はい

はい

はい

はい

Operator​ による Runtime Fabric ソフトウェアのライフサイクル管理。

-

はい

-

-

FIPS モードの有効化によるセキュリティの強化。

はい

-

はい

-

コントロールプレーンによる Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ を使用したセキュアプロパティの設定。

はい

-

はい

-

rtfctl​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ によるフルバックアップ/復元。

はい

-

はい

-

リファレンス実装 (テンプレート) - パフォーマンスチューニング、CRD 設定 K8s のベストプラクティス、推奨クラスターサイジング、ネットワーク設定。

はい

-

-

-

共有責任としての Anypoint Runtime Fabric

Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。

Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。

Anypoint Runtime Fabric の共有責任の図

MuleSoft によって提供される内容

MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。

Runtime Fabric コアサービス

Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、GKE、または RedHat OpenShift 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。

Linux ベースのオペレーティングシステムは、Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。

  • Runtime Fabric エージェント

    Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。

    エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。

    エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。

  • Mule クラスター IP サービス

    Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。

  • リソースキャッシュ

    アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。

これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションまたはノードの増加に伴って増加しません。

アプリケーションサービス

Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。

  • 永続性ゲートウェイ: Mule アプリケーション (ユーザーが設定した複製) への永続性 ObjectStore v2 インターフェースを提供します。

  • Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる)

お客様による管理

お客様は、Runtime Fabric に使用される Kubernetes クラスターのプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。

  • イングレスコントローラーと​イングレスリソースのカスタマイズ

  • 内部負荷分散

  • ログ転送

  • 監視

  • ネットワークポート、NAT ゲートウェイ、プロキシ

  • ホストランタイムとネットワーク

  • Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です

    • IT チームによるインフラストラクチャのプロビジョニングと管理

    • ネットワークチームによる許可ポートの指定とプロキシの設定

    • セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得

Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作

Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。

  1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。

  2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。

  3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。

  4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。

  5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。

  6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。

Runtime Fabric のアプリケーションデプロイメントワークフロー

Anypoint Runtime Fabric で名前空間を割り当てる

各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。

  1. Runtime Fabric によって表示ラベルが ​rtf.mulesoft.com/envId=<ANYPOINT_ENVIRONMENT_ID>​ の名前空間が検索されます。

  2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​<ANYPOINT_ENVIRONMENT_ID>​ の名前空間が検索されます。

  3. Runtime Fabric によってその名前空間が見つけられなかった場合、​<ANYPOINT_ENVIRONMENT_ID>​ という名前の新しい名前空間が作成されます。

アプリケーション名前空間の割り当てフローチャート

アプリケーションデプロイメントの監視

Runtime Fabric エージェントでは、​rtf.mulesoft.com/id​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​「ログ」​と​「監視」​を参照してください。

Runtime Fabric の機能サポートリスト

次の表に、サポートされる機能とサポートされない機能を示します。

機能 状況

Mules および API ゲートウェイのデプロイのサポート

サポート

Kubernetes と Docker

含まれない。

Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Linux ディストリビューションでのインストール

サポート

ノードの自動スケーリング

AWS、Azure、Google Cloud、または RedHat OpenShift の機能を使用してサポート

外部ログ転送

ログを外部システムに転送するように Log4j をセットアップできます。

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Anypoint Security Edge

サポート対象外

Anypoint Security トークナイゼーション

サポート対象外

オペレーションセンター

含まれない
AWS、Azure、Google Cloud、または RedHat OpenShift で監視とアラートを有効にできます。

Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント)

Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。

Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。