20111215 12 aws-meister-sqs_sns_sdb-public
DESCRIPTION
ほぼ週間AWSマイスターシリーズのSQS,SNS,SimpleDBの回の資料です。TRANSCRIPT
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