Mule Runtime 高可用性 (HA) クラスターの概要

デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。

一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。

Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。

次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。

自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。

クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。

高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。

Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。

Anypoint Runtime Fabric では、デプロイ時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。

Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。

Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。

注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。

次に示すように、クラスター内のすべてのノードはメモリを共有します。

コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスター化された Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。

高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。

トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。

JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。

トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。

すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。

高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​「信頼性パターン」​で見つかります。

アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。

アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。

これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。

TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。

TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。

このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。
その他のデプロイメントオプションについての詳細は、​「デプロイメント戦略」​を参照してください。

(信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。

mule.cluster.network.encryption.key​ プロパティを ​wrapper.conf​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。

暗号化キーを定義すると、定義したキーと AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。

FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。

クラスタリングに関しては多くの推奨事項があります。例を挙げます。