Amazon SQSの使いどころ その2 Tweet

前回、キューを使って、時間がかかる処理を非同期で処理するフローを書きました。今回は、キューにAmazon SQSを使うと、なぜ嬉しいのか？を書いてみたいと思います。

メリット

その1：キューを作らなくていい

なんだかバカみたいですが、前回も書いた通り、信頼性のあるキューを作るのは大変な事です。既に実績のあるサービスを、格安（激安）で使えるのですから、利用しない手は無いです。信頼性という意味では、

メッセージを複数のデータセンターにコピーするので、メッセージが消える心配をしなくてよい。

とAmazon側は言っています。これぞまさにクラウドって感じですね。メッセージのやり取りはSSL経由で、さらにユーザー認証がかかっていますので、基本的なセキュリティーは保たれていると思います。

その2：導入が簡単

AmazonのAPIは大抵REST/SOAPの二種類が用意されていますが、SQSも例外ではありません。ただ、APIを素のまま利用するケースはまれだと思います。Java、Ruby、Pythonなど主要な言語のライブラリがありますので、そちらを使う事になるでしょう。自分の場合だと、メッセージを投げるフロントエンドはRubyでRightAwsを、メッセージを受けるバックエンドはJavaでtypicaを使っています。そもそもSQSで出来る事が単純なので、ライブラリ側のAPIも単純なものになっています。

その3：激安

一番大事な所ですが、安いというより、激安です。料金は、

$0.01 per 10,000 Amazon SQS Requests ($0.000001 per Request)

ですが、これだけ見ても？？だと思います。実際に経験したケースだと、30秒おきにSQSにポーリングするスレッドを4本持ったサーバが2台、丸一ヶ月動いた時（単純計算で、30秒おきに8回、SQSにメッセージを取りに行く）で、

2,763,389 Requests $2.76

という請求が来ました。日本円にして250円くらいですので、為替レートの変動する事を考えるとほとんど誤差と言っても良いでしょう。仮に10倍だとしても2,500円ですから。

デメリット

とは言うものの、いい事ばかりではありません。かといって悪い事ではないんですが、独特のクセを知っておかないと想定外の動きをするので要注意です。

その1：メッセージの順番が保証されない

キューってFIFOだから、メッセージを入れた順番に受け取れると思いがちですが、実際は結構ばらついて返ってきます。これは、SQSがメッセージを複数データセンターにコピーする時間が影響してるのかな？と思います。

ですので、順番にシビアな事をやりたい場合は、別途その情報を管理する必要があります。

その2：メッセージ個数カウントが適当

これは「現在キューに何個のメッセージが溜まっているのか？」を正確に知る事が不可能という意味です。適当はちょっと言い過ぎですが、だいたい合っているというか、おおざっぱです。この辺もシビアにやりたい場合は問題になるかもしれません。

その3：メッセージの削除が保証されていない

自分は最初この制約を見たときに「えぇっ！」と思いましたが、実際はそれほど大変な問題ではありません。一度処理したメッセージには印をつけておいて、仮に再度受け取ったとしても実行済みで処理させない様にすれば良いだけです。自分はそうしています。ただし、経験上二重にメッセージを受け取った事は無いです。

総合するとメリットが上回る

デメリットに関しては、使う側で工夫すれば割と簡単に乗り越えられる問題じゃないかと思います。総合的に考えると、非常にコストパフォーマンスが高いのではないでしょうか？

ちなみに、今までの経験からすると、メッセージを投げてから受け取れるまで数秒、長い時だと30秒ほどかかる場合があります。肝心の信頼性ですが、今までメッセージが消えた事はありません。EC2やS3は結構な頻度で落ちてますが、SQSはそれほどでもないです。（気がついてないだけだったりして・・）

次回はサンプルコードを交えて、具体的にどのような実装になるのか解説してみたいと思います。