---
schema_version: "1"
id: 1486a650dc4aeb35f34c23185465c67951e85cdad0839388a7e7850bc712d5b7
title: CloudHub 高可用性機能
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/cloudhub/cloudhub-fabric.md
canonical_url: https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric
source_site: docs.mulesoft.com
content_type: documentation
content_hash: da38198a235cdbacf17b9440bf0709f38161e7ae8563b4ae70fad20012d809b6
description: MuleSoft Documentation Site
latest: true
---
# CloudHub 高可用性機能

CloudHub 高可用性 (HA) 機能を使用すると、CloudHub のアプリケーションで拡張性、ワークロードの分散、信頼性の向上を実現できます。この機能は、CloudHub の拡張性の高い負荷分散サービス、ワーカーのスケールアウト、永続的なキュー配置機能によって提供されます。

新しいアプリケーションをデプロイするときや、既存のアプリケーションを再デプロイするときに Anypoint Runtime Manager コンソールを使用して、アプリケーションごとに HA 機能を有効にできます。

## [](#前提条件)前提条件

CloudHub HA では、以下が必要です。

- この機能を使用できるようにする CloudHub Enterprise または Partner アカウント種別。
- Runtime Manager コンソールを使用したアプリケーションのデプロイについての理解。

## [](#ワーカーのスケールアウト)ワーカーのスケールアウト

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

**\[workers (ワーカー)\]**​ の横にあるドロップダウンメニューを使用して、アプリケーションのワーカーの数とサイズを選択し、必要な計算能力を設定します。

サブスクリプションに応じて、任意の種類の最大 8 個のワーカー、アプリケーションごとに最大 128 個の vCore でアプリケーションをデプロイできます。 十分なリソースがあることを確認するには、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。

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

アプリケーションを 2 つ以上のワーカーにデプロイすると、それらの Mule インスタンスでワークロードを分散できます。CloudHub では、以下が提供されます。

1. HTTP 負荷分散サービス。割り当てたワーカーで HTTP 要求を自動的に分散します。
2. 永続的なメッセージキュー (下記参照)

バッチジョブは、一度に 1 つのワーカーでのみ実行され、複数のワーカーで分散できません。 同じデプロイメントで Mule が再起動すると、その状況は保持され、バッチの処理が続行されます。バッチの実行中にアプリケーション全体が更新または再デプロイされると、残りのバッチジョブは続行されません。CloudHub の永続的なバッチジョブの主な解決策は、クラウドオブジェクトストアを使用することです。

## [](#永続的なキュー)永続的なキュー

永続的なキューにより、メッセージの損失がなくなり、ワークロードを一連のワーカーで分散できます。

- アプリケーションを複数のワーカーにデプロイする場合、永続的なキューを使用すると、ワーカー間の通信とワークロードの分散を実現できます。たとえば、大きなファイルがキューに配置された場合、ワーカーはこれを分割して並列で処理できます。
- 永続的なキューでは、大きな利害が関係する処理のメッセージセキュリティが追加されており、1 つ以上のワーカーまたはデータセンターがダウンしても、メッセージが確実に配信されます。
- アプリケーションで永続的なキューが有効になっていると、実行時に Runtime Manager コンソールの ​**\[Queues (キュー)\]**​ タブでキューを表示できます。
- すべての永続的なキューで保存時のデータの暗号化を有効にできます。この機能を有効にすると、永続的なキューに書き込まれる共有アプリケーションデータが暗号化され、セキュリティとコンプライアンスのニーズを満たすことができます。
- 永続的なキューのメッセージの保持期間は最大 4 日です。永続的なキューのメッセージのサイズや数に制限はありません。
- ワーカーの永続的なキューは、ワーカーと同じリージョンにあります。

永続的なキューでは 1 回のみのメッセージ配信は保証されません。重複するメッセージが送信される場合もあります。1 回のみのメッセージ配信が重要なユースケースの場合、永続的なキューを有効にしないでください。

アプリケーションでの永続的なキューの動作についての詳細は、​[「キューの管理」](https://docs.mulesoft.com/jp/cloudhub/managing-queues)​を参照してください。

## [](#cloudhub-ha-機能の有効化)CloudHub HA 機能の有効化

次の 2 つのいずれかの方法で CloudHub HA の機能のいずれかまたは両方を有効/無効にできます。

- 初めてアプリケーションを CloudHub にデプロイするときに Runtime Manager コンソールを使用する
- 以前にデプロイされたアプリケーションの Runtime Manager コンソールで ​**\[Deployment (デプロイメント)\]**​ タブにアクセスする
    
    1. **\[Workers (ワーカー)\]**​ の横で、ドロップダウンメニューからオプションを選択し、アプリケーションに割り当てられているワーカーの数と種別を定義します。

複数のワーカーへのデプロイについての詳細は、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。

アプリケーションをクリックして概要を表示し、​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。​**\[Settings (設定)\]**​ をクリックして ​**\[Persistent Queues (永続的なキュー)\]**​ チェックボックスをオンにし、キューの永続性を有効にします。

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

## [](#ha-の実装方法)HA の実装方法

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

クライアントは、ワーカーの直接 URL を使用してアプリケーションのロードバランサーをバイパスできます。特定の CloudHub ワーカーでアプリケーションにアクセスする方法についての詳細は、​[「CloudHub ネットワークガイド」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide)​を参照してください。

## [](#ユースケース)ユースケース

単一のアプリケーションでは、HA 機能のどちらか片方または両方を使用する、あるいはどちらも使用しないように選択できます。

- 永続的なキューを利用するには、この機能をサポートするように Mule アプリケーションを設定します。詳細については、「​[永続的なキューをサポートする Mule アプリケーションの構築](#永続的なキューをサポートする-mule-アプリケーションの構築)​」を参照してください。
- 永続的なキューを有効にすると、パフォーマンスに影響があります。小さなメッセージ (50KB 以下) をキューに配置する場合は 10 ～ 20 ミリ秒 (ms) かかりますが、同じメッセージをキューから取り出す場合は 70 ～ 100 ミリ秒かかります。
- ワーカーを追加すると、サービスのコストが増加します。

<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 33.3333%;">
<col style="width: 33.3333%;">
<col style="width: 33.3334%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">ユースケース</th>
<th class="tableblock halign-left valign-top">推奨される HA 設定</th>
<th class="tableblock halign-left valign-top">影響</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>アプリケーションをスケールアウトしたいが、サービスの中断とメッセージの損失については、既存の可用性の高い CloudHub アーキテクチャに満足している。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>永続的なキューを有効にしない。</p>
</div>
<div class="paragraph">
<p>ワーカーの数: 2 つ以上</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>キューのレイテンシーによるアプリケーションパフォーマンスへの影響はない。</p>
</li>
<li>
<p>キューの永続性をサポートするようにアプリケーションを設定する必要はない。</p>
</li>
<li>
<p>1 つのデータセンターが停止しても、別のデータセンターでワーカーを使用できる。</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>メッセージの損失に対する保護が必要な大きな利害が関係するプロセスがあるが、処理負荷の対処に問題は発生しておらず、データセンターが停止した場合に一部のサービスが中断されても問題はない。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>永続的なキューを有効にする。</p>
</div>
<div class="paragraph">
<p>ワーカーの数: 1</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>アプリケーションでキューのレイテンシーが発生する可能性がある。</p>
</li>
<li>
<p>デプロイする前にキューの永続性をサポートするようにアプリケーションを設定する必要がある。</p>
</li>
<li>
<p>ワーカーが動作しているデータセンターが停止すると、CloudHub によって自動的にアプリケーションが別の可用性ゾーンに移行される。移行時にダウンタイムが発生する場合もありますが、永続的なキューにより、メッセージの損失はありません。</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>メッセージの損失に対する保護が必要な大きな利害が関係するプロセスがあり、サービスの中断を避けて、大きな処理負荷に対処する。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>永続的なキューを有効にする。</p>
</div>
<div class="paragraph">
<p>ワーカーの数: 2 つ以上</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>アプリケーションでキューのレイテンシーが発生する可能性がある。</p>
</li>
<li>
<p>デプロイする前にキューの永続性をサポートするようにアプリケーションを設定する必要がある。</p>
</li>
<li>
<p>1 つのデータセンターが停止すると、ワーカーが自動的に分散されて冗長性が確保される。</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>処理負荷やメッセージの損失に関して特殊な要件のないアプリケーションがある。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>永続的なキューを有効にしない。</p>
</div>
<div class="paragraph">
<p>ワーカーの数: 1</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>キューのレイテンシーによるアプリケーションパフォーマンスへの影響はない。</p>
</li>
<li>
<p>キューの永続性をサポートするようにアプリケーションを設定する必要はない。</p>
</li>
<li>
<p>ワーカーが動作しているデータセンターが停止すると、CloudHub によって自動的にアプリケーションが別の可用性ゾーンに移行されるが、移行時にダウンタイムやメッセージの損失が発生するが場合がある。</p>
</li>
</ul>
</div></div></td>
</tr>
</tbody>
</table>

## [](#バッチジョブが含まれるアプリケーションの永続的なキュー)バッチジョブが含まれるアプリケーションの永続的なキュー

バッチジョブが含まれるアプリケーションを永続的なキューが有効になっている CloudHub にデプロイする場合、バッチジョブは CloudHub の永続的なキューを使用して、バッチキュー機能を実現します。

永続的なキューを有効にする場合、次の制限事項に留意してください。

- CloudHub の永続的なキューを使用すると、バッチジョブのレイテンシーが増加します。
    
    パフォーマンスを向上させるには、永続的なキューを無効にしてください。
- CloudHub の永続的なキューは、複数回メッセージを処理することがあります。
    
    メッセージが 1 回だけ処理されるようにするには、永続的なキューを無効にしてください。
- アプリケーションが再起動されると、メッセージの損失が起こる場合があります。

これらの制限事項を踏まえて、Mulesoft ではバッチジョブについては永続的なキューを無効にすることをお勧めします。

バッチジョブの永続的なキューを無効にするには、次のプロパティをアプリケーションに追加します。

```xml
batch.persistent.queue.disable=true
```

デフォルトでは、このプロパティの値は ​`false`​ です。 true に設定すると、アプリケーションではバッチジョブに永続的なキューが使用されませんが、他の Mule コンポーネントについては永続的なキューが有効なままになります。

## [](#永続的なキューをサポートする-mule-アプリケーションの構築)永続的なキューをサポートする Mule アプリケーションの構築

アプリケーションで永続的なキューの利点を得るには、信頼性パターンをアプリケーションコードに実装して、個々の XA トランザクションを VM トランスポートから分離します。詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns)​を参照してください。

![信頼性パターン](/mulesoft/current/ja-jp/cloudhub/_images/ch-fabric.png)

信頼性の高い取得フローでは、インバウンド HTTP Connector からアウトバウンド VM エンドポイントにメッセージが確実に配信されます。信頼性の高い取得フローでメッセージを VM キューに配置できない場合、クライアントが要求を再試行できるように「要求失敗」応答をクライアントに返して、メッセージの損失を回避します。

アプリケーションロジックフローでは、インバウンド VM エンドポイントからアプリケーションのビジネスロジック処理にメッセージが配信されます。このフローは、1 つのトランザクションを表します。各自のビジネスロジックには、表示されていない他のトランザクションがいくつか含まれる可能性があります。

信頼性の高い取得フローでコミットされたメッセージは、アプリケーションロジックフローで処理する準備が整うまで、これらの 2 つのフローの間にある永続的な VM キューで保持されます。トランザクション内で処理エラーが発生した場合や、トランザクションがタイムアウト (トランザクションに割り当てられている時間を超過) した場合、Mule はロールバックをトリガーします。このロールバックにより、メッセージで行われた部分的な処理が消去され、メッセージがキューに戻ります。Mule インスタンスが停止した場合や、トランザクションを明示的にロールバックできない場合、トランザクションに割り当てられている時間を超えると、トランザクションが自動的にロールバックします。割り当て時間は、トランザクション要素の ​`timeout`​ 属性によって決まります。自分でタイムアウトを設定することも、デフォルトを受け入れることもできます。

3 つのステップで各トランザクションを考えるとわかりやすくなります。

1. 開始。Mule は、トランザクション内のすべてのサブコンポーネントの処理を開始します。
2. コミット。Mule は、完了したトランザクションの結果を次のステップに送信します。XA トランザクションの場合、コミットステップは、​_コミット要求フェーズ_​と​_コミットフェーズ_​の 2 つのフェーズになります。コミット要求フェーズでは、Mule はトランザクションのスコープ内の複数の応答の結果を調整し、すべての処理が正常に実行されて、コミットの準備が整っていることを確認します。その後、コミットフェーズで各リソースがコールされ、その処理がコミットされます。
3. ロールバック。「開始」または「コミット」ステップのいずれかでエラーが発生した場合、Mule は部分的な完了がないようにトランザクション内の処理をロールバックします。

次のコードスニペットは、CloudHub でキューの永続性を確保するために VM トランスポートを使用する信頼性パターンでセットアップされたアプリケーションの例です。

```xml
<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd

http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd

http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd

http://www.mulesoft.org/schema/mule/jbossts http://www.mulesoft.org/schema/mule/jbossts/current/mule-jbossts.xsd">

    <vm:connector name="vmConnector" doc:name="VM">
    </vm:connector>
    <http:listener-config name="listener-config" host="..." port="..."/>

    <!-- This is the reliable acquisition flow in the reliability pattern.  -->

    <flow name="reliable-data-acquisition" doc:name="reliable-data-acquisition">
        <http:listener config-ref="listener-config" path="/" doc:name="HTTP Connector"/>
        <expression-filter expression="#[message.inboundProperties.'http.request.path' != '/favicon.ico']" nullReturnsTrue="true" doc:name="Expression"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="input" connector-ref="vmConnector" doc:name="VM"/>
    </flow>

    <!-- This is the application logic flow in the reliability pattern.
         It is a wrapper around a subflow, "business-logic-processing".
    -->
    <flow name="main-flow" doc:name="main-flow">
        <vm:inbound-endpoint exchange-pattern="one-way" path="input" connector-ref="vmConnector" doc:name="VM">
            <xa-transaction action="ALWAYS_BEGIN" timeout="30000"/>
        </vm:inbound-endpoint>
        <flow-ref name="business-logic-processing" doc:name="Flow Reference"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="output" connector-ref="vmConnector" doc:name="VM">
    </flow>

    <!--
            This subflow is where the actual business logic is performed.
        -->
    <sub-flow name="business-logic-processing" doc:name="business-logic-processing">
    ....
    </sub-flow>
</mule>
```

### [](#ハイブリッド-vm-キューと-cloudhub-vm-キューの違い)ハイブリッド VM キューと CloudHub VM キューの違い

次の表に、ハイブリッド VM キューと CloudHub VM キューの主な違いを示します。

<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 50%;">
<col style="width: 50%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">オンプレミスアプリケーションの VM キュー</th>
<th class="tableblock halign-left valign-top">CloudHub にデプロイされているアプリケーションの VM キュー</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>queue-profile 要素を使用して、未処理メッセージの最大数を設定できます。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>CloudHub では、未処理メッセージの数に制限はありません。アプリケーションで未処理メッセージの最大数を使用して queue-profile 要素をコーディングしていても、​<strong>[Persistent Queues (永続的なキュー)]</strong>​ チェックボックスをオンにしてアプリケーションを CloudHub にデプロイすると、未処理メッセージは無制限になります。</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>queue-profile 要素を使用して、キューの永続性を切り替えることができます。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>キューの永続性は、[deployment (デプロイメント)] ダイアログの ​<strong>[Advanced Details (高度な詳細)]</strong>​ セクションにある ​<strong>[Persistent Queues (永続的なキュー)]</strong>​ チェックボックスを使用して管理します。アプリケーションで queue-profile 要素をコーディングしていても、​<strong>[Persistent Queues (永続的なキュー)]</strong>​ チェックボックスをオンにしてアプリケーションを CloudHub にデプロイすると、これらの設定は上書きされます。</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>使用する VM キューのキューストアを定義できます。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>キューストアは CloudHub で管理されるため、キューストアを定義する必要はありません。</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>XA トランザクションのコミットとロールバックは、2 フェーズコミットアルゴリズムに従って処理されます。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>CloudHub でメッセージをキューに追加する場合、XA トランザクションの 2 フェーズコミットアルゴリズムの動作に重要な例外があります。詳細は、以下の既知の問題を参照してください。注意: CloudHub で永続的なキューのメッセージをコンシュームする場合、この 2 フェーズコミットアルゴリズムの例外は適用されません。</p>
</div></div></td>
</tr>
</tbody>
</table>

## [](#考慮事項)考慮事項

CloudHub でメッセージを VM キューに追加する場合、次の条件を満たすと、XA トランザクションの 2 フェーズコミットプロトコルが失敗し、完了したトランザクションがロールバックされる可能性があります。

- コミット要求フェーズが正常に完了した。トランザクション内の関連するすべての処理が正常に実行されるため、メッセージをキューにコミットできるようになります。
- コミットフェーズでエラーが発生し、トランザクション内のサブプロセスをコミットできなくなり、トランザクションのロールバックがトリガーされる。
- ロールバックが発生する前に VM アウトバウンドエンドポイントでコミットが完了する。

上記の 3 つの条件をすべて満たす場合、メッセージは意図したとおりトランザクションロールバックプロセスでロールバックされる代わりにキューに追加されます。メッセージの損失は発生せず、トランザクションを引き続き繰り返すことができますが、アウトバウンド VM キューに意図しないメッセージが追加されます。

<table><tbody><tr><td class="icon"><i class="fa icon-note" title="Note"></i></td><td class="content">この問題は、VM キューに追加する必要のあるメッセージがフローで生成される場合にのみ発生します。キューのメッセージをコンシュームするプロセスには影響はありません。</td></tr></tbody></table>

## [](#関連情報)関連情報

- [CloudHub ワーカー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)
- [キューの管理](https://docs.mulesoft.com/jp/cloudhub/managing-queues)
- [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture)
- [トランザクションの管理](https://docs.mulesoft.com/mule-runtime/latest/transaction-management)
- [VM Connector](https://docs.mulesoft.com/jp/vm-connector/latest/)
- [信頼性パターン](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns)