クラスタリング

高可用性​とは、クラスタリングとは異なり、各レプリカ間でデータを共有しない複数のレプリカがあることを指します。 クラスタリング​では、複数のレプリカが相互に通信し、メモリを共有しているためにデータを共有できます。

クラスタリングでは、以下が必要です。

CloudHub 2.0 では、アプリケーションの vCore オプションを選択して、水平方向に拡張できます。 このように計算能力のプロビジョニングを詳細に制御できるため、高い負荷に対処する場合はアプリケーションをスケールアップし、負荷が低い期間はスケールダウンするという作業を任意のタイミングで柔軟に行うことができます。

最大 8 個 (Anypoint Integration Advanced パッケージや、Anypoint Platform の Platinum または Titanium サブスクリプションがある場合は最大 16 個) のレプリカを使用してアプリケーションをデプロイできます。 十分なリソースがあることを確認するには、​「CloudHub 2.0 レプリカ」​を参照してください。

レプリカのスケールアウトにより、信頼性も向上します。 Mule Runtime Engine (Mule) は、自動的に同じアプリケーションで複数のレプリカを 2 つ以上のデータセンターで分散し、最大限の信頼性を確保します。

アプリケーションを 2 つ以上のレプリカにデプロイすると、それらの Mule インスタンスでワークロードを分散できます。 CloudHub では、割り当てたレプリカで HTTP 要求を自動的に分散する、次の HTTP 負荷分散サービスが提供されます。

バッチジョブは、一度に 1 つのレプリカでのみ実行され、複数のレプリカで分散できません。 同じデプロイメントで Mule が再起動すると、その状況は保持され、バッチの処理が続行されます。 バッチの実行中にアプリケーション全体が更新または再デプロイされると、残りのバッチジョブは続行されません。 CloudHub 2.0 の永続的なバッチジョブの主な解決策は、Object Store v2 の概要を参照してください。

Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードをスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングでは、負荷の増加に対応してより多くのポッドが自動的にデプロイされます。これらの定期的な自動スケーリング操作により、ユーザーアクションなしでアプリケーションを新しいレプリカに変更できます。

次の 2 つのいずれかの方法でクラスタリングの機能のいずれかまたは両方を有効/無効にできます。

複数のレプリカへのデプロイについての詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。

アプリケーションがすでにデプロイされている場合、新しい設定を有効にするには、再デプロイする必要があります。

HTTP 負荷分散は、内部リバースプロキシサーバーで実装されます。 アプリケーション (ドメイン) URL への要求は、自動的にすべてのアプリケーションのレプリカ URL で負荷分散されます。

クラスタリングを有効にすると、Mule アプリケーションのすべてのレプリカがユニットとして機能します。クラスターとは複数のレプリカで構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、情報を共有します。つまり、データがさまざまなレプリカのメモリ間で複製されます。

詳細は、Mule Runtime High Availability (HA) Cluster Overviewを参照してください。

単一のアプリケーションで、クラスタリング機能を組み合わせることができます。