日経クラウドファースト編集長 中山秀夫

 「メッセージキューイング(MQ)」というシステム連携方式をご存じだろうか。詳しくは後述するが、クライアント(システムあるいはシステムを構成するサービス)同士が、「キュー」と呼ぶ入れ物を介して、メッセージをやり取りする仕組みだ。

 ホスト機の時代から使われてきた実績のある技術で、2000年代前半に注目を集めたサービス指向アーキテクチャー(SOA)では、サービス同士の連携方式として用いられた。企業情報システムの基盤を担当してきたITエンジニアにとって、メッセージキューイングは馴染みのある技術の一つだろう。

 ところが2010年ごろからSOAが下火になるとともに、メッセージキューイングは「使っている人しか知らない地味な存在」になっていった。あるアーキテクトは「特に、Web系のシステムから入った若手エンジニアの間で、メッセージキューイングはあまり知られていない」と指摘する。

 これは問題だ。Amazon Web Services(AWS)やMicrosoft Azureなどのパブリッククラウドサービスにおいて、メッセージキューイングの重要性が高まっているからである。

 メッセージキューイングを使うことで、システムの可用性や拡張性を高めやすくなる。そのため今も新サービスが投入されている。最近ではAWSが2016年11月に、メッセージキューイングサービス「Amazon SQS(Simple Queue Service)」の機能を強化したのに加え、SQSと組み合わせて使える新サービス「AWS Step Functions」の提供を始めた。

 メッセージキューイングを「地味な昔の技術」と考えるのは間違いだ。ホットなメッセージキューイングの一端を紹介しよう。

送信側と受信側の独立性が高まる

 まず、メッセージキューイングを使うと、なぜ可用性や拡張性を高めやすくなるのか。

 一般にメッセージキューイングでは、送信側のクライアントはメッセージを受信側に直接送るのではなく、キューと呼ぶメッセージの入れ物に渡す。キューは多数のメッセージをためておくことができる。受信側のクライアントは、キューからメッセージを受け取り、処理する。これが基本的な仕組みだ。

 キューを介してメッセージをやり取りするだけだが、利点は大きい。送信側は受信側の負荷や稼働の状態に関係なく、メッセージをキューに送れば、手離れする。受信側のリソースがひっ迫していたり、停止していたりしても、送信側は待つ必要がない。

 受信側は、自らの負荷や稼働の状態に応じてメッセージを受け取れる。例えば、キューからメッセージを受け取って処理を終えたら、次のメッセージを受け取ればよい。処理中でリソースがひっ迫している最中に、別のメッセージを送りつけようとする送信側の相手をする必要はない。

 このように、キューを挟んで、送信側と受信側の独立性を高められる。片方の応答遅延や障害がもう片方に悪影響を与えるリスクが減り、システム全体の可用性が高まる。

この先は会員の登録が必要です。有料会員(月額プラン)は申し込み初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら