AWSマイスターシリーズ〜SQS, SNS, SimpleDB〜

2011年12月15日大谷 晋平 (@shot6 )ソリューションアーキテクト

AWSマイスターシリーズ〜Simple Queue Service〜

2011年12月15日大谷 晋平 (@shot6 )ソリューションアーキテクト

アジェンダSQSとはSQSの機能SQSの使いどころQ&A

SQS(Simple Queue Service)とは

AWSの隠し技

SQS(Simple Queue Service)とは分散キューサービス� AWSをスケールアウトして使うためのキーコ

ンポーネント� 最低⼀度は届くことを保証信頼性が⾼く、すぐに使えて、管理者不要、低コスト2006年よりある最古参サービス

何故キューが必要か？“分割できないものは、スケール出来ない” by Randy Shoup(eBay)� スケールするには疎結合なアーキテクチャに

する必要がある� 疎結合アーキテクチャに非同期通信が不可⽋� 非同期通信の典型例がキューシステム

SQSの機能“分散”キューサービス最低⼀度のメッセージ到達保障シンプルなAPIキューシステムのインストール不要

、SDKから直接使える

分散キューサービスメッセージは自動的に複数DC間でレプリケーションされる�メッセージロストを防ぐ�Persistent Message自分で高い耐障害性を持つキューシ

ステムを構築するのは困難

シンプルなAPIとSDKCreateQueueSendMessageReceiveMessageChangeMessageVisibilityDeleteMessageバッチ処理SDKはJava/.NET/PHP/Ruby

動作イメージ1.キューの作成/4.キューの削除(http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2)

管理者

メッセージ送信者(Writeror Producer)

2.メッセージ送信

メッセージ受信者(Readeror Consumer)

3.メッセージ受信

メッセージの到達保障1.キューの作成/4.キューの削除(http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2)

管理者

2.メッセージ送信 3.メッセージ受信

VisibilityTimeout

Visibility TimeoutとはReaderがメッセージを受信した場合

に、ある一定期間その他のReaderがメッセージは⾒えなくなるメッセージ自体はユーザが明示的に

消さない限り残存する(最大2週間)

Visibility Timeoutとは(2)あるReader-Aがメッセージ1を依頼 あるReader-Dが

メッセージ1を依頼あるReader-Bが依頼

あるReader-Cが依頼

メッセージは返却されない

メッセージは返却されない

メッセージの返却 削除されていない場合(メッセージの返却)

この間にReader-Aは、・受信したメッセージを処理する・処理出来たらメッセージを削除する

最低⼀度のメッセージ到達保障At-Least-Once delivery�メッセージは複数DCにコピー�堅牢性・耐障害性にフォーカスデメリット：稀に複数回メッセージ

が届くこともある�メッセージの状態管理�複数回届く前提

メッセージサンプリングメッセージは送信後すぐに取れるとは限らない� 受信リクエストを送り続ければ取れるイベンチュアルコンシステンシ前提

サンプリングしたサーバからメッセージを順次返却(メッセージEが含まれていない)

メッセージの受信者

SQSキューの分散されたサーバ群

サンプリング対象サーバ（グレー）

開発者に優しい無料枠と価格月間100,000 requestまで無料価格� 10,000リクエストあたり$0.01�データトランスファーはAWSから外部に送出する場合に限り、$0.201/GBから課⾦

SQSのキューのセキュリティIAMまたはポリシーベースでユーザ

とアクションを制限する事が可能{ "Statement":[{

"Effect":"Allow", "Action":"sqs:SendMessage", "Resource":"arn:aws:sqs:*:123456789012:SampleQueue" }, {"Effect":"Deny", "NotAction":"sqs:SendMessage", "NotResource":"arn:aws:sqs:*:123456789012:SampleQueue"

} ] }

SQSの制約メッセージの順序性は保証しないメッセージの保存は最大2週間までメッセージのサイズは64KBまでキュー内に入るメッセージ数には制

限なしキュー名は80文字まで

最近のSQS機能追加CloudWatchによるメトリクス監視� AutoScalingと組み合わせやすくマネージメントコンソールから利⽤可能にディレイキューメッセージタイマーバッチAPI

SQSをいつ使うか？AWSクラウド内での疎結合アーキテ

クチャを採用したい場合�コンポーネント間の依存関係を減らしたい

AWSクラウドとオンプレミスの間でのやり取りのインタフェース�受諾と処理→結果の送信の分離

顧客はいつSQSを使っているか？

Webアプリケーション/SaaS

ビッグデータやバッチ処理

ハイブリッドクラウド連携 オンプレミスとAWSクラウド

連携

EMRやAWSクラウドのその他サービスとの連携に利⽤

イメージ処理、インデクシング等のシステム間の疎結合なやり取りに利⽤

SQSまとめAWSが提供するキューサービス�最低⼀度は届くことを保証�分散キューのためスケールする�高い耐障害性�シンプルにすぐに使える�セキュア�低コスト

AWSマイスターシリーズ〜Simple NotificationService〜

2011年12月15日大谷 晋平 (@shot6 )ソリューションアーキテクト

アジェンダSNSとはSNSの機能SNSの使いどころQ&A

SNS(Simple Notification Service)とは

AWSの小道具

SNSとはクラウド上の通知サービス簡単に使えて、マルチプロトコル従量課⾦制で非常に安いインストール・管理不要ですぐに使

える

SNSの機能様々なプロトコルに対応した通知プ

ラットフォーム� メール、SQSキュー、HTTP/HTTPSコ

ールバック、SMSシンプルなAPI/SDKプッシュベースアーキテクチャ非常に低価格

動作イメージ1.トピックの作成/5.トピックの削除管理者

メッセージ配信者(Publisher)

3.メッセージ配信

メッセージ購読者(Subscriber)

2.トピック購読

4.メッセージ受信

利⽤⽤途様々なプロトコルを通じたアプリケ

ーション間のフックに使うAWSクラウド上のアプリケーション

S3ファイル

SNS完了通知依頼

ジョブ 完了通知&ジョブ実⾏

利⽤⽤途S3上からファイルが削除されたとき

をフックAWSクラウド上のアプリケーション

S3

SNS削除通知依頼

削除されたことを通知

ユーザが削除

SQSとSNSの違いSQSはポーリングモデル� 1:1コミュニケーション� Producer-ConsumerSNSはプッシュモデル� 1:Nコミュニケーション� Publisher-Subscriber

開発者に優しい無料枠と価格月間100,000 requestまで無料価格� 100,000リクエストあたり$0.06�HTTPは100,000あたり$0.06�メールは100,000通あたり$2.0� 100SMSあたり、$0.75� SQSにはチャージなし

SNSの制約最大1アカウント100トピックまでメッセージは最大8KBまで

SNSまとめクラウド上の通知サービス簡単に使えて、マルチプロトコル従量課⾦制で非常に安いインストール・管理不要ですぐに使

える

AWSマイスターシリーズ〜SimpleDB〜

2011年12月15日大谷 晋平 (@shot6 )ソリューションアーキテクト

SimpleDBとは

AWSの裏ワザ

アジェンダSimpleDBが出てきた背景SimpleDBとはSimpleDBの機能SimpleDBの使いどころQ&A

One Size Does Not Fit AllRDBMSが全てではない�EC2+EBSまたはRDSは汎用的より目的特化なデータベース�シンプルな利⽤例でより簡単にスケールさせる

�管理者不要�低コスト

SimpleDBの出てきた背景RDBMSが全てではない�EC2+EBSまたはRDSは汎用的目的特化型サービス�NoSQL�管理者不要�低コスト

SimpleDBの出てきた背景多くのアプリケーションで

RDBMSの高機能が必要ない場合がある�複雑なトランザクション�複雑なジョイン�シンプルにデータを永続化したい�データモデルの制約

SimpleDBとはAWS独自のNoSQLデータベース管理者不要スケーラブル高い可用性・高い耐障害性� データは複数DCに自動レプリケーション� データは自動インデクシング柔軟なデータモデル圧倒的に低コスト

SimpleDBの位置づけCAP定理�一貫性(C)、可用性(A) 、ネットワーク分断耐性(P)のうち、分散環境では実質上ネットワーク分断耐性が必須のため、一貫性か可用性のどちらかを取らなくてはいけない。

SimpleDBのデータモデルドメイン� アイテムを保持する器=テーブルアイテム� アトリビュートを保持する1⾏アトリビュート� アイテム内にあるKey-Valueまたは

Key-[Value]

SimpleDBのデータモデル

SimpleDBの書き込みトランザクションは1アイテムのみ複数アイテムの同時書き込みにはトランザクションはかけられないConditionalPut� 現在の値がXXXの場合のみ、データを更新� 楽観的並⾏制御

SimpleDBの読み込みイベンチュアルコンシステンシな読み込み� デフォルト� パフォーマンス重視� 低レイテンシ、高スループット� 読み込みの一貫性がない可能性がある� 大体1秒程度で⼀貫性が保たれる一貫性のある読み込み� 比較的低いパフォーマンス� ただしデータは一貫している� ConsistentRead = trueオプション

SimpleDBで出来る操作ドメインへの操作� CreateDomain/DeleteDomain/ListDomains

アイテム/アトリビュートの追加� PutAttributes/BatchPutAttributes

アイテム/アトリビュートの削除� DeleteAttributes/BatchDeleteAttributes

アイテム/アトリビュートの検索� GetAttributes/Select

SimpleDBでSelectSQLライクなシンプルなクエリが書けるプライマリキーでの検索� select Year from ‘mydb’ where ItemName() = ‘Akio'

レンジクエリ� select Name, category, Year from `mydb` where every(Year) Between '2005' and '2008'

=, !=, >, <, >=, <=などの演算子like, not like, in, between, inなどの演算子order bycount

RDBMSとSimpleDBの違いRDBMS� 事前定義したスキーマ� 管理コスト高い� 1台で稼働する事が前提� SQLによるアクセス� リニアにはスケールしない� トランザクションあり� インデックスは明示的� 構造化データ� 汎用的

SimpleDB� スキーマフリー� 管理コスト低い� オートスケール� SQLライクなクエリ� スケールする� トランザクションなし� 自動インデックス� 半構造化データ� やや目的特化型

SimpleDBの制約ドメインサイズ -> 10GB/domain or 10億アトリビュートドメイン名 -> 3-255(a-zA-Z0-9_-.) characters1アカウント100ドメインまで1アイテム256アトリビュートまでアトリビュートのname/valueの⻑さ < 1024 bytesアイテム名の⻑さ < 1024 bytes1回のPutAttributesで登録できるのは256個まで1回のSelectで検索できるアトリビュートは256個まで1回のSelectで検索できるアイテムは2500まで1回のクエリの最⼤実⾏時間は5秒まで1回のレスポンスサイズは1024 bytesまで

SimpleDBをスケールさせるためには？スケールアウトデザインがフィットする� 書き込みをスケール→シャーディング� 読み込みをスケール→データ構造/クエリの工夫SimpleDBに対して出来るだけ並⾏してリクエストする� 論理パーティションキー

• キーの設計がとても重要

SimpleDBのベストプラクティスソート� ソートのため、数値データは0パディングしてやる� 日付はISO 8601フォーマットを使う

Selectクエリ� WHERE句ではなく、コンポジットキーを使う

• Name=“Firstname:Lastname”� AND句を極⼒使わない� LIMITを設定し、レンジクエリを極小化する。LIMIT

2500など

SimpleDBのベストプラクティスシャーディング� 書き込みのスループットを上げるため� ハッシュ値または、より適切なキー分割を指定

一貫性� 読み込みではオプションを適切に使う

• イベンチュアルコンシステンシ• read-after-writeコンシステンシ

� 書き込みはなるべく非同期書き込み or ConditionalPutを使う

パフォーマンス� BatchPutまたはBatchDeleteをデフォルト使う

• 25アイテムの書き込みで20-25%程度は向上する�

SimpleDBのベストプラクティス巨大データの扱い� BLOB的に使うのではなくS3に保存して、ポインタを

SimpleDBに保存する• 2ホップかかるがわかりやすい

� データを分割し、複数のアトリビュートに圧縮して押し込める

• 1ホップだが複雑設計� データは非正規化する前提� スキーマフリーな点を有効に使う� クエリベースで考えて極⼒ドメインを分ける

• 分割によるスケールメリット

SimpleDBの価格マシンの利⽤料⾦� クエリ毎にかかった消費量を計算� $0.162/hourデータトランスファー� インバウンドは無料� アウトバウンドは$0.201/GBからデータストレージ料� $0.29/GBSimpleDBの利⽤料は他に⽐べてかなり安い� ただし先ほどのような制約がある

SimpleDBをいつ使うか？シンプルなクエリだがスケールが求められる場合データベース管理者がいないため、管理コストを下げたい場合� データモデルを理解して開発できる⼈材は必要� 銀の弾丸ではない

ユニークキーによる分散が簡単に出来て、スケールアウトさせやすいケースの場合データ構造が頻繁に変わるため、それを低コストで⾏いたい場合低コストでデータベースを持ちたい場合高い可用性とスケーラビリティが必要な場合

SimpleDBで顧客は何を動かしているか？オンラインゲームプラットフォームS3のコンテンツのインデックス設定ファイルなどの置き場所ソーシャルデータの蓄積マイニングデータの解析結果のストア� EMRと連携はしないのか？

まとめAWS独自のNoSQLデータベース管理者不要スケーラブル高い可用性・高い耐障害性� データは自動レプリケーション、インデクシ

ング柔軟なデータモデル圧倒的に低コスト

SQS、SNS、SimpleDBを通じてAWS SシリーズはAWSクラウドを

よりよく使うためのコンポーネント� SQS=疎結合を提供する� SNS=プロトコル非依存な通知� SimpleDB=簡単に使えるDB