AWSマイスターシリーズ～CloudFront Route53～ - Amazon Web

AWSマイスターシリーズ
～SQS, SNS, SimpleDB～
2011年12月15日
大谷晋平 (@shot6 )
ソリューションアーキテクト
緊急速報
南米リージョンを発表いたします!!
全部で8つ目のリージョン
2011年だけで4つ目
GlobalUSInfrastructure
for
Global
Enterprises
West
US East
Europe
Asia Pacific Asia Pacific
GovCloud
(US ITAR Region)
(Northern
California,
Oregon)
(Northern
Virginia)
West
Region
Region
(Dublin)
(Singapore)
(Tokyo)
South
America
(San Paulo)
AWS Regions
AWS Edge Locations
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)
2.メッセージ送信
メッセージ送信者
(Writer
or Producer)
3.メッセージ受信
メッセージ受信者
(Reader
or Consumer)
メッセージの到達保障
管理者
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-Bが
依頼
メッセージは
返却されない
あるReader-Cが
依頼
あるReader-Dが
メッセージ1を依頼
メッセージは
返却されない
メッセージの返却
この間にReader-Aは、
・受信したメッセージを処理する
・処理出来たらメッセージを削除する
削除されてい
ない場合
(メッセージの
返却)
最低一度のメッセージ到達保障
At-Least-Once delivery
 メッセージは複数DCにコピー
 堅牢性・耐障害性にフォーカス
デメリット：稀に複数回メッセージ
が届くこともある
 メッセージの状態管理
 複数回届く前提
メッセージサンプリング
メッセージは送信後すぐに取れると
は限らない
 受信リクエストを送り続ければ取れる
イベンチュアルコンシステンシ前提
メッセージの
受信者
SQSキューの分散
されたサーバ群
サンプリングした
サーバからメッ
セージを順次返却
(メッセージEが含
まれていない)
サンプリング
対象サーバ
（グレー）
開発者に優しい無料枠と価格
月間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.トピックの削除
3.メッセージ配信
2.トピック購読
4.メッセージ受信
メッセージ購読者
メッセージ配信者
(Subscriber)
(Publisher)
利用用途
様々なプロトコルを通じたアプリケ
ーション間のフックに使う
ファイル
S3
AWSクラウド上のアプリケーション
完了通知依頼
SNS
ジョブ
完了通知&ジョブ実行
利用用途
S3上からファイルが削除されたとき
をフック
ユーザが削除
S3
AWSクラウド上のアプリケーション
削除通知依頼
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

Download Report