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

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

一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。

Mule Runtime Engine のクラスターではすべてのノードが同時にメッセージを処理するため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。

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

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

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

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

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

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

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

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

Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。

Mule Runtime Engine (ノード) 間で負荷分散を行うために明示的に 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 クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。

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

このセクションは、オンプレミスデプロイメントにのみ適用されます。高パフォーマンスの実装は CloudHub と Pivotal Cloud Foundry で異なります。
これらの各デプロイメントについての詳細は、​「デプロイメント戦略」​を参照してください。

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

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

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

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

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