MQのキューマネージャーを冗長化する機能の1つとして、MQクラスター機能がある。この機能は、V2.1（z/OS版）／V5.1（分散プラットフォーム版）の新機能として登場して以来、多くのユーザーで利用されている。
IBM MQ for z/OSには、このMQクラスター機能に加えて、V5.2から「キュー共用」と呼ばれる冗長化機能を備えている。それぞれに特徴は異なるものの、この2つの機能を組み合わせることにより、MQの最も高い可用性構成が可能になる。しかしこの構成は、実はあまり知られていない。
そこで本稿では、このMQクラスターとキュー共用を組み合わせることで、z/OS版のMQだけが実現しうる高可用性構成について解説する。
MQクラスターの効用
まず、MQクラスターの基本を確認しよう。
MQクラスターでは、要求・応答型のシステムで応答側のキューマネージャーを複数台、並行稼働させ、要求側のキューマネージャーと論理的なクラスターを形成する（図表1）。
要求アプリケーションからクラスター・キューへ送信されるメッセージは、MQクラスター機能（ワークロード管理機能）によって振り分けられ、応答側キューマネージャーの負荷分散やMQ障害時の自動切り離しが可能となる（図表2）。
MQクラスターの利点は、これらの負荷分散や切り離しの動作がMQレベルで完結していることであり、負荷分散装置や監視・自動制御の仕組みを別途に必要としない（もちろん、MQシステム全体としての監視は必要である）。
MQクラスター構成における考慮点
ただしMQは正常だが、応答アプリケーションに障害が発生したケースでは考慮する必要がある。この障害は、MQ自体では検知できない。したがって、障害発生後もメッセージは障害系のキューマネージャーに送信され、キューには大量の要求メッセージが滞留する。
早期にアプリケーションが復旧しない限り、要求側はタイムアウトし、滞留メッセージはExpiryにより自然消滅する。ハイ・トランザクションのシステムでは、障害系ノードの切り離しに数秒かかるだけで、数千件のトランザクションが処理されない事態を招く可能性もある。
要求アプリケーションが要求メッセージの送信と応答メッセージの受信を同期的に処理している場合には、事態はさらに悪化する。
要求アプリケーションではリクエストを並行処理するため、リクエストごとにスレッドをアサインし、各スレッドが要求メッセージを送信し、その応答メッセージを待機する。そして、同時に稼働できるスレッド数には上限を設けていることが多い。
ここで、以下のようなオンライン・トランザクションのシナリオを考えてみる（図表3）。
◆ シナリオ概要
・ 平均トランザクション量は400件／秒
・ 1トランザクションのレスポンス・タイムはおよそ500ミリ／秒
・ 要求側、応答側とも2ノード構成
・ 要求アプリケーションは平時およそ100スレッドで200件／秒を処理
・ 要求側アプリケーションのスレッド数の上限は1000（1ノード当たり）
・ 応答待ちのタイムアウトは60秒
このシナリオで、応答側の1号機のアプリケーションがダウンした場合をシミュレートする。
障害発生後、要求側では、1号機に要求メッセージが流れたスレッドは応答メッセージが戻らず、待機状態になる。処理中のスレッドの半分、つまり1ノード当たり50スレッドが待機状態となる。
その後も1ノードに付き200件／秒のリクエストが送られてくると、その半分は1号機に送信されるため、単純計算でも10秒程度で待機スレッドが上限の1000に達する。
タイムアウトは60秒なので、最初のスレッドが待機状態から抜けるまでに、さらに50秒かかる。この間、追加のスレッドを生成できず、新規リクエストを受け付けられなくなる。つまり全面的なサービス停止に陥る（図表4）。
このような事態を避けるには、短時間（数秒）でアプリケーション障害を検知し、障害系ノードの切り離しまでを実行する仕組みが必要である。
検知および切り離しの仕組み自体はさまざまな実装が考えられるが、誤検知することなく、数秒で確実に障害を検知するのは困難である。
ここで、キュー共用が登場する。
キュー共用のメリット
キュー共用とは、z/OS並列シスプレックス・テクノロジーを活用し、複数のキューマネージャーでキューを共有できる機能である。キュー共用では、キューをカップリング・ファシリティ（CF）上に配置する。このように構成したキューのことを「共用キュー」と呼ぶ。
シスプレックス内の複数のノード上のアプリケーションは、それぞれローカルのキューマネージャーを通して、同じ共用キューにメッセージを送受信できる（図表5）。
したがって１ノードで障害が発生した場合でも、ダウンタイムなしに正常系ノードでメッセージ処理を継続できる。これがキュー共用の最大のメリットである（図表6）。
さらにキュー共用では、ノン・パーシステント・メッセージもCF上に格納されるため、キューマネージャーがダウンしても消失しない。これは、ｚ/OS版以外のMQでは実現できない可用性である。
ハイブリッド・クラスター構成
このキュー共用を、MQクラスターと組み合わせて構成することができる。つまり、共用キューをクラスターキューとしても定義できるのである。こうすることで、MQクラスターによるPUSH型の負荷分散と、キュー共用によるPULL型の負荷分散を融合したハイブリッド型の負荷分散を実現できる（図表7）。
前述のシナリオに、この構成を当てはめてみる。
この構成でも、応答アプリケーションの障害はMQレベルでは検知できない。しかし、すべての要求メッセージはCF上の共用キューに集約され、正常な応答アプリケーションによって処理が継続される。先ほどシミュレートしたような短時間でサービスの全面停止に陥る事態は回避できる（図表8）。
以上本稿では、MQクラスターとキュー共用を組み合わせた構成について、１つのシナリオを例に、MQシステムの可用性がさらに高くなることを解説した。
実際にこの構成を適用するには、ユーザーのシステム特性に合わせてさまざまな角度から検討・検証する必要はあるが、今後MQシステムの冗長化を検討する際には、ぜひこのハイブリッド・クラスター構成も検討してほしい。
松本 昇平
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
第二テクノロジーMQグループ
ITスペシャリスト
著者プロフィール
2000年に日本アイ・ビー・エム システムズ・エンジニアリングに入社以来、MQのスペシャリストとして大小問わず多数の案件をサポートしている。
