![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"
}]}](https://image.slidesharecdn.com/2011121512aws-meister-sqssnssdb-public-120123044315-phpapp01/85/SimpleDB-SQS-SNS-AWS-17-320.jpg)
![SimpleDBのデータモデル
ドメイン
アイテムを保持する器=テーブル
アイテム
アトリビュートを保持する1
アトリビュート
アイテム内にあるKey-Valueまたは
Key-[Value]](https://image.slidesharecdn.com/2011121512aws-meister-sqssnssdb-public-120123044315-phpapp01/85/SimpleDB-SQS-SNS-AWS-47-320.jpg)
SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ
- 1. AWSマイスターシリーズ SQS, SNS, SimpleDB 2011 12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 2. AWSマイスターシリーズ Simple Queue Service 2011 12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 4. SQS(Simple Queue Service)とは AWSの隠し技
- 5. SQS(Simple Queue Service)とは 分散キューサービス AWSをスケールアウトして使うためのキーコ ンポーネント 2006
- 6. 何故キューが必要か？ “分割できないものは、スケール出来 ない” by Randy Shoup(eBay) スケールするには疎結合なアーキテクチャに する必要がある 非同期通信
- 8. 分散キューサービス メッセージは自動的に複数DC間でレ プリケーションされる メッセージロストを防ぐ Persistent Message 自分で高い耐障害性を持つキューシ ステムを構築するのは困難
- 9. シンプルなAPIとSDK CreateQueue SendMessage ReceiveMessage ChangeMessageVisibility DeleteMessage SDKはJava/.NET/PHP/Ruby
- 10. 動作イメージ 1.キューの作成/4.キューの削除 (http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2) 3.メッセージ受信 2.メッセージ送信 メッセージ受信者 メッセージ送信者 (Reader (Writer or Consumer) or Producer)
- 11. メッセージの到達保障 1.キューの作成/4.キューの削除 (http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2) 3.メッセージ受信 2.メッセージ送信 Visibility Timeout
- 12. Visibility Timeoutとは Readerがメッセージを受信した場合 に、ある一定期間その他のReaderが メッセージ自体はユーザが明示的に 消さない限り残存する(最大2週間)
- 13. Visibility Timeoutとは(2) あるReader-Aが あるReader-Dが メッセージ1を依頼 あるReader-Bが あるReader-Cが メッセージ1を依頼 依頼 依頼 メッセージは メッセージは 返却されない 返却されない メッセージの返却 削除されてい ない場合 (メッセージの 返却) この間にReader-Aは、
- 15. メッセージサンプリング メッセージは送信後すぐに取れると は限らない 受信リクエストを送り続ければ取れる イベンチュアルコンシステンシ前提 メッセージの SQSキューの分散 受信者 されたサーバ群 サンプリングした サーバからメッ セージを順次返却 (メッセージEが含 まれていない) サンプリング 対象サーバ （グレー）
- 17. 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" }]}
- 19. 最近のSQS機能追加 CloudWatchによるメトリクス監視 AutoScalingと組み合わせやすく ディレイキュー メッセージタイマー バッチAPI
- 21. 顧客はいつSQSを使っているか？ ハイブリッド オンプレミスとAWSクラウド クラウド連携 連携 Webアプリケー 等のシステム間の疎結合なやり ション/SaaS ビッグデータや EMRやAWSクラウドの
- 22. SQSまとめ AWSが提供するキューサービス 分散キューのためスケールする 高い耐障害性 シンプルにすぐに使える セキュア 低コスト
- 23. AWSマイスターシリーズ Simple Notification Service 2011 12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 27. SNSの機能 様々なプロトコルに対応した通知プ ラットフォーム メール、SQSキュー、HTTP/HTTPSコ ールバック、SMS シンプルなAPI/SDK プッシュベースアーキテクチャ 非常に低価格
- 28. 動作イメージ 1.トピックの作成/5.トピックの削除 2.トピック購読 3.メッセージ配信 4.メッセージ受信 メッセージ配信者 メッセージ購読者 (Publisher) (Subscriber)
- 32. 様々なプロトコルを通じたアプリケ ーション間のフックに使う AWSクラウド上のアプリケーション S3 ファイル SNS ジョブ &
- 33. S3上からファイルが削除されたとき をフック AWSクラウド上のアプリケーション ユーザが削除 S3 削除通知依頼 SNS 削除されたことを通知
- 34. SQSとSNSの違い SQSはポーリングモデル 1:1コミュニケーション Producer-Consumer SNSはプッシュモデル 1:Nコミュニケーション Publisher-Subscriber
- 38. AWSマイスターシリーズ SimpleDB 2011 12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 39. SimpleDBとは AWSの
- 41. One Size Does Not Fit All RDBMSが全てではない EC2+EBSまたはRDSは汎用的 より目的特化なデータベース ケールさせる 低コスト
- 42. SimpleDBの出てきた背景 RDBMSが全てではない EC2+EBSまたはRDSは汎用的 目的特化型サービス NoSQL 低コスト
- 43. SimpleDBの出てきた背景 多くのアプリケーションで RDBMSの高機能が必要ない場合 がある 複雑なトランザクション 複雑なジョイン シンプルにデータを永続化したい データモデルの制約
- 44. SimpleDBとは AWS独自のNoSQLデータベース スケーラブル 高い可用性・高い耐障害性 データは複数DCに自動レプリケーション データは自動インデクシング 柔軟なデータモデル 圧倒的に低コスト
- 45. SimpleDBの位置づけ CAP 一貫性(C)、可用性(A) 、ネット ワーク分断耐性(P)のうち、分散 環境では実質上ネットワーク分断 耐性が必須のため、一貫性か可用 性のどちらかを取らなくてはいけ ない。
- 47. SimpleDBのデータモデル ドメイン アイテムを保持する器=テーブル アイテム アトリビュートを保持する1 アトリビュート アイテム内にあるKey-Valueまたは Key-[Value]
- 48. SimpleDBのデータモデル
- 49. SimpleDBの書き込み トランザクションは1アイテムのみ 複数アイテムの同時書き込みにはトランザクシ ョンはかけられない ConditionalPut 現在の値がXXX 楽観的
- 50. SimpleDBの読み込み イベンチュアルコンシステンシな読み込み デフォルト パフォーマンス重視 低レイテンシ、高スループット 読み込みの一貫性がない可能性がある 大体1 一貫性のある読み込み 比較的低いパフォーマンス ただしデータは一貫している ConsistentRead = trueオプション
- 51. SimpleDBで出来る操作 ドメインへの操作 CreateDomain/DeleteDomain/ListDomains アイテム/アトリビュートの追加 PutAttributes/BatchPutAttributes アイテム/アトリビュートの削除 DeleteAttributes/BatchDeleteAttributes アイテム/アトリビュートの GetAttributes/Select
- 52. 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
- 53. RDBMSとSimpleDBの違い RDBMS SimpleDB 事前定義したスキーマ スキーマフリー コスト高い コスト低い 1台で稼働する事が前提 オートスケール SQLによるアクセス SQLライクなクエリ リニアにはスケールしない スケールする トランザクションあり トランザクションなし インデックスは明示的 自動インデックス 構造化データ 半構造化データ 汎用的 やや目的特化型
- 54. 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まで
- 55. SimpleDBをスケールさせるためには？ スケールアウトデザインがフィットする 書き込みをスケール→シャーディング 読み込みをスケール→データ構造/クエリの工夫 SimpleDB ストする • キーの設計がとても重要
- 56. SimpleDBのベストプラクティス ソート ソートのため、数値データは0パディングしてやる 日付はISO 8601フォーマットを使う Selectクエリ WHERE • Name=“Firstname:Lastname” AND LIMITを設定し、レンジクエリを極小化する。LIMIT 2500など
- 57. SimpleDBのベストプラクティス シャーディング 書き込みのスループットを上げるため 一貫性 • イベンチュアルコンシステンシ • read-after-writeコンシステンシ 書き込みはなるべく非同期書き込み or ConditionalPutを使う パフォーマンス BatchPutまたはBatchDeleteをデフォルト使う • 25アイテムの書き込みで20-25%
- 58. SimpleDBのベストプラクティス 巨大データの扱い BLOB的に使うのではなくS3に保存して、ポインタを SimpleDBに保存する • 2ホップかかるがわかりやすい データを分割し、複数のアトリビュートに圧縮して 押し込める • 1ホップだが複雑 設計 データは非正規化する前提 スキーマフリーな点を有効に使う • 分割によるスケールメリット
- 59. SimpleDBの価格 $0.162/hour データトランスファー アウトバウンドは$0.201/GBから $0.29/GB SimpleDB ただし先ほどのような制約がある
- 60. SimpleDBをいつ使うか？ シンプルなクエリだがスケールが求められる場合 い場合 銀の弾丸ではない ユニークキーによる分散が簡単に出来て、スケールアウ トさせやすいケースの場合 たい場合 低コストでデータベースを持ちたい場合 高い可用性とスケーラビリティが必要な場合
- 63. SQS、SNS、SimpleDBを通じて AWS SシリーズはAWSクラウドを よりよく使うためのコンポーネント SQS=疎結合を提供する SNS=プロトコル非依存な通知 SimpleDB=簡単に使えるDB