翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon MQ for ActiveMQ のベストプラクティス
このセクションは、Amazon MQ での ActiveMQ ブローカーの使用時にパフォーマンスを最大限に引き出し、スループットコストを最小限に抑えるための推奨事項をすばやく見つけるために使用してください。
## Amazon MQ Elastic Network Interface を変更または削除しない
初めて [Amazon MQ ブローカーを作成](getting-started-activemq.md)するときは、Amazon MQ がアカウントの [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Introduction.html) 内に [Elastic Network Interface](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) をプロビジョンするため、多数の [EC2 許可](security-api-authentication-authorization.md)が必要になります。このネットワークインターフェイスは、クライアント (プロデューサーまたはコンシューマー) が Amazon MQ ブローカーと通信することを可能にします。このネットワークインターフェイスは、アカウントの VPC の一部であるにもかかわらず、Amazon MQ の*サービス範囲*内であると見なされます。
**警告**
このネットワークインターフェイスを変更または削除しないでください。このネットワークインターフェイスを変更または削除すると、VPC とブローカーとの間の接続が完全に失われる可能性があります。
![\[Diagram showing Client, Elastic Network Interface, and Amazon MQ Broker within a Customer VPC and service scope.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-network-configuration-architecture-vpc-elastic-network-interface.png)
## 常に接続プールを使用する
単一のプロデューサーと単一のコンシューマーを使用するシナリオ ([開始方法: ActiveMQ ブローカーの作成と接続](getting-started-activemq.md)チュートリアルなど) では、各プロデューサーおよびコンシューマーに単一の [http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html) クラスを使用できます。以下はその例です。
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Establish a connection for the consumer.
final Connection consumerConnection = connectionFactory.createConnection();
consumerConnection.start();
```
ただし、複数のプロデューサーやコンシューマーが関与するより現実的なシナリオでは、複数のプロデューサーのために多数の接続を作成することはコスト高および非効率的になる場合があります。このようなシナリオでは、[http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html) クラスを使用して複数のプロデューサーリクエストをグループ化する必要があります。以下はその例です。
**注記**
メッセージコンシューマーには、`PooledConnectionFactory` クラスを*一切使用しない*でください。
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Create a pooled connection factory.
final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory();
pooledConnectionFactory.setConnectionFactory(connectionFactory);
pooledConnectionFactory.setMaxConnections(10);
// Establish a connection for the producer.
final Connection producerConnection = pooledConnectionFactory.createConnection();
producerConnection.start();
```
## 常にフェイルオーバートランスポートを使用して複数のブローカーエンドポイントに接続する
[アクティブ/スタンバイ](amazon-mq-broker-architecture.md#active-standby-broker-deployment)デプロイモードを使用するとき、または[オンプレミスメッセージブローカーから Amazon MQ に移行](https://docs.aws.amazon.com//amazon-mq/latest/migration-guide/)するときなど、アプリケーションを複数のブローカーエンドポイントに接続する必要がある場合は、[フェイルオーバートランスポート](http://activemq.apache.org/failover-transport-reference.html)を使用して、コンシューマーがそれらのいずれかにランダムに接続できるようにします。例えば、次のようになります。
```
failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-west-2.amazonaws.com:61617)?randomize=true
```
**重要**
マルチアベイラビリティーゾーンブローカーでは、メンテナンスウィンドウやブローカーの再起動中にフェイルオーバーが発生する可能性があります。フェイルオーバートランスポートを使用して、ブローカーの可用性を確保します。
## メッセージセレクタを使用しない
[JMS セレクタ](https://docs.oracle.com/cd/E19798-01/821-1841/bncer/index.html)を使用して、トピックのサブスクリプションにフィルターをアタッチする (コンテンツに基づいてコンシューマーにメッセージを送信するため) ことは可能ですが、JMS セレクタを使用すると Amazon MQ ブローカーのフィルターバッファが満杯になり、メッセージをフィルタリングできなくなります。
一般的に、コンシューマーによるメッセージのルーティングは避けます。コンシューマーとプロデューサーが適切に非干渉化されるために、コンシューマーとプロデューサーはどちらもエフェメラルである必要があるためです。
## 永続サブスクリプションよりも仮想送信先を優先する
たとえば接続が失われて復元された後などに、トピックに発行されたすべてのメッセージをコンシューマーが受信するには、[永続サブスクリプション](http://activemq.apache.org/how-do-durable-queues-and-topics-work.html)が役立ちます。ただし、永続サブスクリプションを使用する場合、競合するコンシューマーの使用は不可能であり、パフォーマンスの大規模な問題が発生する可能性があります。代わりに、[仮想送信先](http://activemq.apache.org/virtual-destinations.html)を使用することを検討してください。
## Amazon VPC ピアリングを使用する場合は、CIDR 範囲 `10.0.0.0/16` 内のクライアント IP を避けてください。
オンプレミスインフラストラクチャと Amazon MQ ブローカーの間に Amazon VPC ピアリングをセットアップしている場合は、CIDR 範囲 `10.0.0.0/16` 内の IP でクライアント接続を設定しない必要があります。
## 低速コンシューマーのキューに対して同時保存とディスパッチを無効にする
デフォルトで、Amazon MQ は高速コンシューマーのキューに対して最適化を行います。
+ コンシューマーは、プロデューサーによって生成されるメッセージの速度に対応できる場合、*高速*とみなされます。
+ キューによって未確認メッセージのバックログが生成され、プロデューサーのスループットが低下する可能性がある場合、コンシューマーは*低速*とみなされます。
低速コンシューマーのキューに対して最適化を行うよう Amazon MQ に指示するには、`concurrentStoreAndDispatchQueues` 属性を `false` に設定します。設定の例については、「[`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues)」を参照してください。
## 最良なスループットのために正しいブローカーインスタンスタイプを選択する
[ ブローカーインスタンスタイプ](broker-instance-types.md)のメッセージスループットは、アプリケーションのユースケースおよび以下の要因に依存します。
+ ActiveMQ を永続モードで使用する
+ メッセージサイズ
+ プロデューサーとコンシューマーの数
+ 送信先の数
### メッセージサイズ、レイテンシー、およびスループット間の関係の理解
ユースケースによっては、より大きなブローカーインスタンスタイプはシステムスループットを向上させない場合があります。ActiveMQ が耐久性のあるストレージにメッセージを書き込むと、メッセージのサイズはシステムの制限要因を決定します。
+ メッセージが 100 KB 未満の場合、永続的ストレージのレイテンシーが制限要因となります。
+ メッセージが 100 KB 以上の場合、永続的ストレージのスループットが制限要因となります。
ActiveMQ を永続モード使用すると、ストレージへの書き込みは通常、前のコンシューマーがいくつか存在するか、あるいはコンシューマーが低速の場合に発生します。非永続的なモードでは、ブローカーインスタンスのヒープメモリに空き容量がない場合にも、低速のコンシューマーによるストレージへの書き込みが発生します。
アプリケーションにおける最適なブローカーインスタンスタイプを決定するには、異なるブローカーインスタンスタイプをテストすることが推奨されます。詳細については、「[Amazon MQ for ActiveMQ ブローカーインスタンスタイプ](broker-instance-types.md)」および「[Measuring the Throughput for Amazon MQ using the JMS Benchmark](https://aws.amazon.com/blogs/compute/measuring-the-throughput-for-amazon-mq-using-the-jms-benchmark/)」を参照してください。
### より大きなブローカーインスタンスタイプのユースケース
より大きなブローカーインスタンスタイプがスループットを向上させるには、3 つの一般的なユースケースがあります。
+ **非永続モード** – アプリケーションが[ブローカーインスタンスのフェイルオーバー](amazon-mq-broker-architecture.md#active-standby-broker-deployment)中におけるメッセージの喪失による影響を受けにくいときは、多くの場合 ActiveMQ の非永続モードを使用できます。このモードでは、ブローカーインスタンスのヒープメモリに空き容量がない場合にのみ、ActiveMQ は永続的ストレージにメッセージを書き込みます。非永続モードを使用するシステムは、大きなブローカーインスタンスタイプで利用できるより大きなメモリ容量、高速の CPU、および高速のネットワークの利点を活用できます。
+ **高速コンシューマー** – アクティブなコンシューマーが利用可能で、[`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues) フラグが有効になっていると、ActiveMQ は、永続モードになっている場合でも、ストレージにメッセージを送信することなく、プロデューサーからコンシューマーへの直接的なメッセージのフローを許可します。アプリケーションが素早くメッセージを消費できる場合 (あるいは、コンシューマーがその処理を行えるように設計できる場合)、アプリケーションはより大きなブローカーインスタンスタイプの利点を活用できます。アプリケーションがより素早くメッセージを消費できるようにするには、アプリケーションインスタンスにコンシューマースレッドを追加するか、あるいはアプリケーションインスタンスを水平あるいは垂直にスケールアップします。
+ **バッチトランザクション** – 永続的モードを使用しており、トランザクションごとに複数のメッセージを送信するときは、より大きなブローカーインスタンスタイプを使用することによって、全体的に高いメッセージスループットを達成することができます。詳細については、ActiveMQ ドキュメントの「[Should I Use Transactions?](http://activemq.apache.org/should-i-use-transactions.html)」を参照してください。
## 最高のスループットのために正しいブローカーストレージタイプを選択する
複数のアベイラビリティーゾーン全体で優れた耐障害性とレプリケーションを活用するには、Amazon EFS を使用します。低レイテンシーと高スループットを活用するには、Amazon EBS を使用します。詳細については、「[Amazon MQ for ActiveMQ ストレージタイプ](broker-storage.md)」を参照してください。
## ブローカーのネットワークを正しく設定する
[ブローカーのネットワーク](network-of-brokers.md)を作成するときは、アプリケーションに合わせて正しく設定します。
+ **永続モードを有効にする** – 同等のものと比べると、各ブローカーインスタンスはプロデューサーまたはコンシューマーのように動作するため、ブローカーのネットワークはメッセージの分散レプリケーションを提供しません。コンシューマーとして機能する最初のブローカーはメッセージを受信し、それをストレージに永続化します。このブローカーは確認をプロデューサーに送信し、そのメッセージを次のブローカーに転送します。2 番目のブローカーがメッセージの持続性を確認すると、最初のブローカーはそのメッセージを削除します。
永続モードが無効になっている場合、最初のブローカーはメッセージをストレージに保持せずにプロデューサーに確認します。詳細については、Apache ActiveMQ ドキュメントの「[レプリケートされたメッセージストア](http://activemq.apache.org/replicated-message-store.html)」および「[永続的配信と非永続的配信の違い](http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html)」を参照してください。
+ **ブローカーインスタンスのアドバイザリーメッセージを無効にしない** – 詳細については、Apache ActiveMQ ドキュメントの「[Advisory Message](http://activemq.apache.org/advisory-message.html)」を参照してください。
+ **マルチキャストブローカー検出を使用しない** – Amazon MQ はマルチキャストを使用したブローカー検出をサポートしません。詳細については、Apache ActiveMQ ドキュメントの「[検出、マルチキャスト、および zeroconf の違い](http://activemq.apache.org/multicast-transport-reference.html)」を参照してください。
## 準備された XA トランザクションを復旧することで再起動が遅くならないようにする
ActiveMQ は分散型 (XA) トランザクションをサポートしています。ActiveMQ が XA トランザクションを処理する方法を理解しておくと、Amazon MQ でのブローカーの再起動とフェイルオーバーにかかる長い復旧時間の回避に役立ちます。
未解決の準備済み XA トランザクションは、再起動のたびに再実行されます。これらのトランザクションが未解決のままである場合、その数は時間の経過とともに大きくなり、ブローカーの起動に必要な時間が大幅に長くなります。これにより、再起動とフェイルオーバー時間に影響があります。`commit()` および `rollback()` を使用してこれらのトランザクションを解決し、時間の経過とともにパフォーマンスが低下しないようにする必要があります。
未解決の準備された XA トランザクションをモニタリングするには、Amazon CloudWatch Logs の `JournalFilesForFastRecovery` メトリクスを使用できます。この数値が増えるか、常に `1` より高い場合は、次の例のようなコードを使用して、未解決のトランザクションを復旧します。詳細については、「[Amazon MQ のクォータ](amazon-mq-limits.md)」を参照してください。
以下のコード例は、準備された XA トランザクションを確認し、`rollback()` でそれらを終了します。
```
import org.apache.activemq.ActiveMQXAConnectionFactory;
import javax.jms.XAConnection;
import javax.jms.XASession;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
public class RecoverXaTransactions {
private static final ActiveMQXAConnectionFactory ACTIVE_MQ_CONNECTION_FACTORY;
final static String WIRE_LEVEL_ENDPOINT =
"tcp://localhost:61616";;
static {
final String activeMqUsername = "MyUsername123";
final String activeMqPassword = "MyPassword456";
ACTIVE_MQ_CONNECTION_FACTORY = new ActiveMQXAConnectionFactory(activeMqUsername, activeMqPassword, WIRE_LEVEL_ENDPOINT);
ACTIVE_MQ_CONNECTION_FACTORY.setUserName(activeMqUsername);
ACTIVE_MQ_CONNECTION_FACTORY.setPassword(activeMqPassword);
}
public static void main(String[] args) {
try {
final XAConnection connection = ACTIVE_MQ_CONNECTION_FACTORY.createXAConnection();
XASession xaSession = connection.createXASession();
XAResource xaRes = xaSession.getXAResource();
for (Xid id : xaRes.recover(XAResource.TMENDRSCAN)) {
xaRes.rollback(id);
}
connection.close();
} catch (Exception e) {
}
}
}
```
実際のシナリオでは、XA トランザクションマネージャーに対して準備済み XA トランザクションを確認することができます。その後、`rollback()` または `commit()` を使用して準備されたトランザクションのそれぞれを処理するかどうかを決定できます。