PR

 今回は、AWSのメッセージキューイングサービス「Amazon SQS(Simple Queue Service)」を取り上げる。メッセージキューイング(MQ)は、可用性や拡張性を重視するシステムで多用されており、AWSでも非常に重要なサービスの一つと位置付けられている。

 ただ、現状ではメッセージキューイングを用いないシステムのほうが多いだろう。使ったことがなく馴染みのない読者もいるのではないか。

 そこでAmazon SQSの解説に入る前に、非同期、疎結合性というメッセージキューイングの特性について説明する。

非同期によって疎結合性を高める

 HTTPをはじめWebで利用される通信プロトコルの多くは、同期型だ(図1)。システム間でメッセージをやり取りする際、送信側と受信側が同じタイミングで処理する。受信側に問題があると、送信側はメッセージを送れない。

図1 メッセージキューイングを使わない場合と使う場合のメッセージングの違い
図1 メッセージキューイングを使わない場合と使う場合のメッセージングの違い
[画像のクリックで拡大表示]

 メッセージキューイングは非同期型で、キューという入れ物を介して、メッセージをやり取りする。そのため、送受信する各システムは任意のタイミングで処理できる。

 広く普及している非同期処理の例として、電子メールがある。メールボックスを介して、メールの送信側と受信側がそれぞれの都合の良いタイミングで送受信する。

 システム間の連携が非同期になることで高まるのが疎結合性だ。疎結合とは、平たく言うと、互いに独立していることを意味する。

 独立していると、可用性を高めやすい。同期処理の場合、送信側と受信側が互いに同期を取りながら処理を行うように設計する必要がある。どちらかが停止すると、システム全体が停止するので可用性が低い。

 非同期の場合は、メッセージキューイングに対するインタフェースを考慮するだけで開発できる。受信側が停止しても送信側は稼働し続けられ、可用性を高めやすい。

 同様に、システム同士が独立していると拡張性も高めやすい。

 ただし、メッセージキューイングを使う場合、その信頼性が重要になる。システム全体の信頼性がメッセージキューイングに大きく依存するためだ。

 従来、信頼性の高いメッセージキューイングを構築するには、ハード・ソフトの両面で冗長性を考慮する必要があった。この部分にコストが掛かり、小規模なシステムに導入するのは簡単ではなかった。

 Amazon SQSのようなクラウドのメッセージキューイングによって、この問題が解決された。SQSはAWSのマネージドサービスで可用性が高く、全てのキューとメッセージを複数のアベイラビリティーゾーンに保存している。そのためAWS上のシステムでは、SQSを使うことによって、信頼性の求められるメッセージキューイングを簡単に組み込めるようになった。

 そのSQSの内容を紹介しよう。