クラスタランタイムインスタンス

Mule は、さまざまなトポロジでデプロイできます。Mule アプリケーションを構築する場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、クラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 お問い合わせください。

クラスタリングについて

以下の実現するには、アプリケーションをクラスタにデプロイすることが効果的です。

  • 高可用性 (HA): クラスタの 1 つ以上のサーバまたはデータセンターに障害が発生してもシステムを継続的に使用できます。

  • フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。

  • スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。

このページでは、いくつかのクラスタリングソリューション候補について説明します。

Mule 高可用性

Enterprise Edition

Mule 高可用性では、Mule の基本的なフェイルオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェイルオーバーは、次のようなクラスタ化された Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスタ (ローカル VM トランスポートを置き換える)

HA-arch

Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、お問い合わせください。

JMS キュー

JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。

jms queues

プラス面:

  • 簡単に実行できる

  • 開発者の理解が深い

マイナス面:

  • 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある

  • XA を使用している場合、パフォーマンスが低下する

ロードバランサ

ロードバランサは、各サーバの現在の負荷と現在稼働しているサーバに基づいて、要求を各サーバにルーティングします。ロードバランサは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタ化されたデータベースで使用されます (下記参照)。

プラス面:

  • 簡単に実行できる

  • 開発者の理解が深い

マイナス面:

  • これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない

このサンプルアーキテクチャでは、HTTP 要求がロードバランサから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバ間でクラスタ化されています。サーバは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。

http_and_jms

サーバがダウンすると、トランザクションがロールバックされ、別のサーバがメッセージを取得して処理を開始します。

注意: ロードバランサはサーバ間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。

データベースでの状態の保持

クラスタ化されたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバ間で継続的にデータを複製できます。

プラス面:

  • 簡単に実行できる

  • 開発者の理解が深い

マイナス面:

  • すべての状態をデータベースに保存できるわけではない

ステートフルコンポーネントの処理

上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。

この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサのメッセージを集計するアグリゲーターがあるとします。プロデューサ #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサ #2 がメッセージを送信するまでメモリに保持します。

Producer #1 --->  |----------|
                  |Aggregator| --> Some other component
Producer #2 --->  |----------|

プロデューサ #1 がメッセージを送信してからプロデューサ #2 がメッセージを送信する間にアグリゲーターのあるサーバがダウンすると、プロデューサ #2 はそのメッセージを別のサーバに送信できません (そのサーバにプロデューサ #1 のメッセージがないため)。

この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。これらのツールのいずれかを使用することで、プロデューサ #2 は別のサーバにフェイルオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。

プラス面:

  • すべてのクラスタリングケースで機能する

  • キャッシュとしても機能する

マイナス面:

  • MuleSoft で正式にサポートされていない

  • 効率化のためにパフォーマンス調整が必要となる

関連トピック

このドキュメントには記載されていませんが、トポロジを設計するときに考慮すべきいくつかのトピックが他にもあります。

  • 各地域に分散しているクラスタの管理

  • データパーティション分割

  • ACID トランザクションと BASE トランザクション

  • 補正とトランザクション

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub