Amazon のその他のWebサービス

AmazonはEC2, S3の他に, SimpleDBとSimple Queue ServiceとよばれるWebサービスを提供している.

SimpleDB

SimpleDBは, データベース的な機能をネットワークで提供するもので, EC2の計算資源からアクセスされるデータベースとして機能することを想定しているようだ. 従って, EC2やS3からのアクセスに関しては通信量に対する従量課金は行われない. データベース機能は今日の多くのWebアプリケーションの心臓部であるので, scalableで, reliableなデータベース機能が提供されることで, EC2の価値は飛躍的に高まる.

データベースといってもいわゆるRelational Databaseのように(不必要なほど)強力なモデルを提供する訳ではなく, その名の通りちょっと単純. ほとんどのユーザが実際には使っていないような複雑な機能を排し, 単純にすることによって, scalabilityとreliabilityを得ているわけだ. この辺のコンセプトは, Google App Engineが提供するデータベースモデルとよく似ている.

また, いわゆるスキーマを定義する必要がない. スクリプト言語インスタンスフィールドのようなもので, いくらでもあとから追加することができる. スキーマの更新に気を使わなくて済むのは便利.

SimpleDBのデータベースは, いくつかの「ドメイン」で構成される. 各ドメインは, 任意個数の属性と値をもつことのできる「アイテム」の集合である. アイテムを縦, 属性を横にとればテーブルだと言えなくもないが, 各アイテムが属性に対する値を複数持つことができる点が異なる.

検索には各属性に対する条件式を利用できる.

["price" < "12.00"] INTERSECTION ["color" = "green"]

演算子には =, !=, <, >, <=, >=, starts-with しかない. 文字検索できないのは不便かもしれない.

SimpleDB vs. RDB

もちろんどうしてもフルのRDBでないとどうにもならない, というアプリケーションもたくさんあるのだろうと思う. Amazonとしては, そういう場合にはEC2のなかにRDBをインストールすればいいし, そうでなければSimpleDBをつかえばいい, という立場らしい.

お値段

データ転送量に関してはアメリカ版S3と全く同じ. データ保持量に対する課金も同じといえば同じで1GBあたり15セントなのだが, データ量の計算方法がちょっと面白い.

すべてのアイテムID のサイズの総和+ 
すべての属性名のサイズの総和+
すべての属性値ペアのサイズの総和 +
45byte * (アイテム数+属性名数+属性値ペア数)

45byteは管理領域ということなのだろう.

さらに面白いのはリクエストに対する課金. リクエストのコストはリクエストの内容によって大きく異なる. 特に検索系はドメインのサイズや, 属性の種類, 条件式によって, コストが全く違う. このためS3のように一律の料金を適用することは妥当ではない. ということで, リクエストに対する課金はそのリクエストが消費した計算機使用量で算出されることになっている. 2007年の1.7GHz Xeonに換算して, 一時間あたり14セントということになっている.

これだと, 実際にアクセスしてみるまでどのくらいコストが掛かるか分からない. そのため, 各リクエストに対する返答にBox Usageというフィールドがあり, そこにそのリクエストに掛かった計算時間が書き込まれるようになっている. したがって, 月末に請求がくるまでいくらかかったか分からない, ということはないようだ.

API

API は, Java, C#, Perl, PHP, VB.NET で提供されている. Pythonはないのか...

Amazon Simple Queue Service

メッセージキューを保持してくれるサービス.

  • ユーザはいくつでもキューをつくることができる.
  • 個々のキューに対してメッセージを投げることができる. メッセージには8Kバイトのテキストをおさめることができる.
  • キューからメッセージを取り出すことができる. 取り出し処理中はそのメッセージはロックされるので, 別のマシンが同じメッセージを処理してしまうことは無い. また, ロックは自動的にタイムアウトするので, 取り出し処理中にエラーが生じた場合にも, メッセージが失われてしまうことは無い.
  • 各メッセージは4日間保持しておくことができる.
用途

何に使ったらいいのかピンとこにくいが, 複数のワーカが大量のワークロードを分散で処理する際に使うことを想定しているらしい.

Amazon のページにはビデオコーディング変換サービスでの使用例が書かれている.

  • 入力ビデオはS3にアップロードされ, 変換リクエストが SQSの入力キューに置かれる. リクエストにはS3上のビデオへのポインタと変換するコーディングが指定されている.
  • EC2のいくつかのインスタンス上で変換エンジンが動いていて, SQSの入力キューからそれぞれリクエストを取り出し変換を行う.
  • 変換されたビデオはS3に書き込まれ, レスポンスメッセージが, SQS上の出力キューに書き込まれる. その際に, SimpleDBを使ってメタ情報を管理する.
  • 特定のEC2インスタンスが入力キューを常に監視して, キューの長さに応じて動的に, 変換エンジン用のEC2インスタンスの数を増減する.

かんたんなバッチキューイングシステムとして使えるということだ. ただし, スケジューリングはセルフスケジューリングになるので必ずしも賢くはないが. 4日間しか保持されないというのも, 用途によっては制約になりそう.

お値段

データ転送量課金はおなじみのアメリカS3料金. EC2との間には課金は生じない. リクエストあたりの課金は 10000リクエストあたり1セント. リクエストには, CreateQueue, ListQueues, DeleteQueue, SendMessage, ReceiveMessage, DeleteMessage, SetQueueAttributes, GetQueueAttributesがある.

以前の価格体系(2009年5月6日まではこちらも使える)では, リクエスト単位でなく, メッセージ単位で課金されていたようだ. こちらは 1000メッセージで 10セント. ListQueueを極端に多用することでも無い限り, 新しい料金体系のほうが安いような気がする.