IBM Cloud Messages for RabbitMQ はバージョン3.8をご利用ください

記事をシェアする:

この投稿は、2020年7月21日に、米国 IBM Cloud Blogに掲載されたブログ（英語）の抄訳です。

IBM Messages for RabbitMQ が、RabbitMQ 3.8のPreferredステータスを取得しました。

RabbitMQ 3.8では多くの新機能（英語、IBM外のサイトへ）が追加されましたが、中でも注目なのは quorum queues（英語、IBM外のサイトへ）が導入されたことです。この新しいキュータイプは、Raftコンセンサスアルゴリズムに基づいてレプリケーションされたキューです。
quorum queueは、高可用性とデータの安全性を実現するためのRabbitMQの戦略的なキュータイプで、従来のミラーキューの代わりになるものです。quorum queueを使うことで、RabbitMQの古典的なミラーリングキューの同期問題（英語、IBM外のサイトへ）が解決されます。すなわち、quorum queueはレプリカの大多数がディスクにメッセージを書き込んだ場合にのみメッセージの受信を確認できるよになるため、キューの同期問題が生じません。

今後、IBM Messages for RabbitMQ サービスを使用する際には、従来のミラーリングキューではなく、 quorum queueを利用することを強く推奨いたします。

サービスの変更

可用性と柔軟性を向上させるために、RabbitMQ サービスにいくつかの変更が加えられています。

• 保証された耐久性と一貫したサービス品質でメッセージを配信するために、quorum queueをご利用ください。RabbitMQコミュニティが推奨しているように、トランザクションや従来のミラーキューを使用しているワークロードは、quorum queueに切り替える必要があります。多くのケースで、キューを設定する際のちょっとしたコード変更のみで実現できます。
  • quorum queue で利用できる機能には制限（英語、IBM外のサイトへ）があるため、利用する際は注意が必要です (例：動的なキュー名、TTL、メッセージの優先度など)

• 古典的なキューの利用について：
  • より高いスループットの “過渡的な” ワークロード向けに、古典的な過渡的なキューを使い続けることができます。デフォルトでは、これらのキューは 3 つのノード間でミラーリングされますが、メッセージはディスクに書き込まれません。これらのキューは過渡的なワークロードを対象としており、 一貫性よりも可用性を優先することになります。”undefined” （または “leaderless”） となったキューは、自動的に削除され、回復することはできません。キューの再作成は、利用者の責任で実施する必要があります。
  • quorum queue で利用できる機能が限られているため、古典的なミラーリングされた耐久性のあるキューを使うこともできますが、キューの同期問題を避けるためにできるだけミラーリングキューの使用は避けてください。古典的なミラーリングキューは、データの一貫性よりもサービスの可用性に焦点を当てています。その結果、古典的なミラーリングキューで同期の問題が発生した場合、データが失われる可能性があります。

• RabbitMQ 3.8では、ネットワークパーティションの扱い方（英語、IBM外のサイトへ）が “pause-minority “から “autoheal “に変更されます。さらに、ha-promote-on-shutdownポリシーキー（英語、IBM外のサイトへ）を “when-synced “から “always “に変更します。これらの変更は、上記で説明したように、古典的なミラーリングキューのためのデータ一貫性よりもサービス可用性の方を重視したアプローチに効力を持ちます。詳細については、RabbitMQのドキュメント（英語、IBM外のサイトへ）を参照してください。

なお、Messages for RabbitMQ 3.7 は 2020年 9月に IBM Cloud でのご提供が終了となります（英語）。現在 3.7をご利用中のお客様は3.8へのアップグレードをご検討ください。

IBM Cloud Messages for Rabbit MQ はこちらからご利用ください。

翻訳：IBM Cloud Blog Japan 編集部