Mule は、さまざまなトポロジでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、クラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 お問い合わせください。
以下の実現するには、アプリケーションをクラスタにデプロイすることが効果的です。
高可用性 (HA): クラスタの 1 つ以上のサーバまたはデータセンターに障害が発生してもシステムを継続的に使用できます。
フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。
スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。
このページでは、いくつかのクラスタリングソリューション候補について説明します。
Enterprise Edition
Mule 高可用性では、Mule の基本的なフェイルオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。 シームレスなフェイルオーバーは、次のようなクラスタ化された Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。
現在、Mule 高可用性は次のトランスポートで使用できます。
|
|
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、お問い合わせください。
JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。
プラス面:
簡単に実行できる
開発者の理解が深い
マイナス面:
多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある
XA を使用している場合、パフォーマンスが低下する
ロードバランサは、各サーバの現在の負荷と現在稼働しているサーバに基づいて、要求を各サーバにルーティングします。ロードバランサは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタ化されたデータベースで使用されます (下記参照)。
プラス面:
簡単に実行できる
開発者の理解が深い
マイナス面:
これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。
このサンプルアーキテクチャでは、HTTP 要求がロードバランサから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバ間でクラスタ化されています。サーバは、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 で正式にサポートされていない
効率化のためにパフォーマンス調整が必要となる