20111215 12 aws-meister-sqs_sns_sdb-public

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

2011年12月15日

大谷 晋平 (@shot6 ) ソリューションアーキテクト

緊急速報

南米リージョンを発表いたします!!

全部で8つ目のリージョン

2011年だけで4つ目

Global Infrastructure for Global Enterprises US West

(Northern

California,

Oregon)

US East (Northern

Virginia)

Europe

West (Dublin)

Asia Pacific

Region (Singapore)

Asia Pacific

Region (Tokyo)

AWS Regions

AWS Edge Locations

GovCloud (US ITAR Region)

South

America (San Paulo)

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とSDK

CreateQueue

SendMessage

ReceiveMessage

ChangeMessageVisibility

DeleteMessage

バッチ処理

SDKはJava/.NET/PHP/Ruby

動作イメージ

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

管理者

メッセージ送信者 (Writer or Producer)

2.メッセージ送信

メッセージ受信者 (Reader or Consumer)

3.メッセージ受信

メッセージの到達保障

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

管理者

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

Visibility Timeout

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 Notification Service～

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-Consumer

SNSはプッシュモデル

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 All

RDBMSが全てではない

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でSelect

SQLライクなシンプルなクエリが書ける

プライマリキーでの検索 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 by

count

RDBMSとSimpleDBの違い

RDBMS

事前定義したスキーマ

管理コスト高い

1台で稼働する事が前提

SQLによるアクセス

リニアにはスケールしない

トランザクションあり

インデックスは明示的

構造化データ

汎用的

SimpleDB

スキーマフリー

管理コスト低い

オートスケール

SQLライクなクエリ

スケールする

トランザクションなし

自動インデックス

半構造化データ

やや目的特化型

SimpleDBの制約

ドメインサイズ -> 10GB/domain or 10億アトリビュート

ドメイン名 -> 3-255(a-zA-Z0-9_-.) characters

1アカウント100ドメインまで

1アイテム256アトリビュートまで

アトリビュートのname/valueの長さ < 1024 bytes

アイテム名の長さ < 1024 bytes

1回の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/GB

SimpleDBの利用料は他に比べてかなり安い

ただし先ほどのような制約がある

SimpleDBをいつ使うか？

シンプルなクエリだがスケールが求められる場合

データベース管理者がいないため、管理コストを下げたい場合

データモデルを理解して開発できる人材は必要

銀の弾丸ではない

ユニークキーによる分散が簡単に出来て、スケールアウトさせやすいケースの場合

データ構造が頻繁に変わるため、それを低コストで行いたい場合

低コストでデータベースを持ちたい場合

高い可用性とスケーラビリティが必要な場合

SimpleDBで顧客は何を動かしているか？

オンラインゲームプラットフォーム

S3のコンテンツのインデックス

設定ファイルなどの置き場所

ソーシャルデータの蓄積

マイニングデータの解析結果のストア

EMRと連携はしないのか？

まとめ

AWS独自のNoSQLデータベース

管理者不要

スケーラブル

高い可用性・高い耐障害性 データは自動レプリケーション、インデクシ

ング

柔軟なデータモデル

圧倒的に低コスト

SQS、SNS、SimpleDBを通じて

AWS SシリーズはAWSクラウドをよりよく使うためのコンポーネント

SQS=疎結合を提供する

SNS=プロトコル非依存な通知

SimpleDB=簡単に使えるDB

ご参加ありがとう ございました

Copyright © 2011 Amazon Web Services