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

 「メッセージキューイング(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」の提供を始めた。

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

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

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

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

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

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

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