Your SlideShare is downloading. ×
20111215 12 aws-meister-sqs_sns_sdb-public
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

20111215 12 aws-meister-sqs_sns_sdb-public

4,302
views

Published on

ほぼ週間AWSマイスターシリーズのSQS,SNS,SimpleDBの回の資料です。

ほぼ週間AWSマイスターシリーズのSQS,SNS,SimpleDBの回の資料です。

Published in: Technology

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,302
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
122
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. AWSマイスターシリーズ~SQS, SNS, SimpleDB~ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
  • 2. 緊急速報南米リージョンを発表いたします!!全部で8つ目のリージョン2011年だけで4つ目
  • 3. Global Infrastructure for Global Asia Pacific Asia Pacific US West US East Europe Enterprises GovCloud(US ITAR Region) (Northern (Northern West Region Region California, Virginia) (Dublin) (Singapore) (Tokyo) Oregon) South America (San Paulo) AWS Regions AWS Edge Locations
  • 4. AWSマイスターシリーズ~Simple Queue Service~ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
  • 5. アジェンダSQSとはSQSの機能SQSの使いどころQ&A
  • 6. SQS(Simple Queue Service)とは AWSの隠し技
  • 7. SQS(Simple Queue Service)とは 分散キューサービス  AWSをスケールアウトして使うためのキーコ ンポーネント  最低一度は届くことを保証 信頼性が高く、すぐに使えて、管理 者不要、低コスト 2006年よりある最古参サービス
  • 8. 何故キューが必要か?“分割できないものは、スケール出来ない” by Randy Shoup(eBay) スケールするには疎結合なアーキテクチャに する必要がある 疎結合アーキテクチャに非同期通信が不可欠 非同期通信の典型例がキューシステム
  • 9. SQSの機能“分散”キューサービス最低一度のメッセージ到達保障シンプルなAPIキューシステムのインストール不要、SDKから直接使える
  • 10. 分散キューサービスメッセージは自動的に複数DC間でレプリケーションされる メッセージロストを防ぐ Persistent Message自分で高い耐障害性を持つキューシステムを構築するのは困難
  • 11. シンプルなAPIとSDK CreateQueue SendMessage ReceiveMessage ChangeMessageVisibility DeleteMessage バッチ処理 SDKはJava/.NET/PHP/Ruby
  • 12. 動作イメージ 管理者 1.キューの作成/4.キューの削除 (http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2) 3.メッセージ受信2.メッセージ送信 メッセージ受信者メッセージ送信者 (Reader(Writer or Consumer)or Producer)
  • 13. メッセージの到達保障 管理者 1.キューの作成/4.キューの削除 (http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2) 3.メッセージ受信2.メッセージ送信 Visibility Timeout
  • 14. Visibility Timeoutとは Readerがメッセージを受信した場合 に、ある一定期間その他のReaderが メッセージは見えなくなる メッセージ自体はユーザが明示的に 消さない限り残存する(最大2週間)
  • 15. Visibility Timeoutとは(2) あるReader-Aが あるReader-Dが メッセージ1を依頼 あるReader-Bが あるReader-Cが メッセージ1を依頼 依頼 依頼 メッセージは メッセージは 返却されない 返却されない メッセージの返却 削除されてい ない場合 (メッセージの 返却) この間にReader-Aは、 ・受信したメッセージを処理する ・処理出来たらメッセージを削除する
  • 16. 最低一度のメッセージ到達保障At-Least-Once delivery メッセージは複数DCにコピー 堅牢性・耐障害性にフォーカスデメリット:稀に複数回メッセージが届くこともある メッセージの状態管理 複数回届く前提
  • 17. メッセージサンプリングメッセージは送信後すぐに取れるとは限らない 受信リクエストを送り続ければ取れるイベンチュアルコンシステンシ前提 メッセージの SQSキューの分散 受信者 されたサーバ群 サンプリングした サーバからメッ セージを順次返却 (メッセージEが含 まれていない) サンプリング 対象サーバ (グレー)
  • 18. 開発者に優しい無料枠と価格月間100,000 requestまで無料価格 10,000リクエストあたり$0.01 データトランスファーはAWSから外 部に送出する場合に限り、 $0.201/GBから課金
  • 19. 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"}]}
  • 20. SQSの制約メッセージの順序性は保証しないメッセージの保存は最大2週間までメッセージのサイズは64KBまでキュー内に入るメッセージ数には制限なしキュー名は80文字まで
  • 21. 最近のSQS機能追加 CloudWatchによるメトリクス監視 AutoScalingと組み合わせやすく マネージメントコンソールから利用可能に ディレイキュー メッセージタイマー バッチAPI
  • 22. SQSをいつ使うか?AWSクラウド内での疎結合アーキテクチャを採用したい場合 コンポーネント間の依存関係を減 らしたいAWSクラウドとオンプレミスの間でのやり取りのインタフェース 受諾と処理→結果の送信の分離
  • 23. 顧客はいつSQSを使っているか? ハイブリッド オンプレミスとAWSクラウド クラウド連携 連携 イメージ処理、インデクシング Webアプリケー 等のシステム間の疎結合なやり ション/SaaS 取りに利用 ビッグデータや EMRやAWSクラウドの バッチ処理 その他サービスとの連携に利用
  • 24. SQSまとめ AWSが提供するキューサービス  最低一度は届くことを保証  分散キューのためスケールする  高い耐障害性  シンプルにすぐに使える  セキュア  低コスト
  • 25. AWSマイスターシリーズ~Simple NotificationService~ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
  • 26. アジェンダSNSとはSNSの機能SNSの使いどころQ&A
  • 27. SNS(Simple NotificationService)とは AWSの小道具
  • 28. SNSとはクラウド上の通知サービス簡単に使えて、マルチプロトコル従量課金制で非常に安いインストール・管理不要ですぐに使える
  • 29. SNSの機能様々なプロトコルに対応した通知プラットフォーム  メール、SQSキュー、HTTP/HTTPSコ ールバック、SMS シンプルなAPI/SDK プッシュベースアーキテクチャ 非常に低価格
  • 30. 動作イメージ 管理者 1.トピックの作成/5.トピックの削除 2.トピック購読3.メッセージ配信 4.メッセージ受信メッセージ配信者 メッセージ購読者(Publisher) (Subscriber)
  • 31. 利用用途様々なプロトコルを通じたアプリケーション間のフックに使う AWSクラウド上のアプリケーション S3 ファイル 完了通知依頼 SNS ジョブ 完了通知&ジョブ実行
  • 32. 利用用途S3上からファイルが削除されたときをフック AWSクラウド上のアプリケーション ユーザが削除 S3 削除通知依頼 SNS 削除されたことを通知
  • 33. SQSとSNSの違い SQSはポーリングモデル  1:1コミュニケーション  Producer-Consumer SNSはプッシュモデル  1:Nコミュニケーション  Publisher-Subscriber
  • 34. 開発者に優しい無料枠と価格月間100,000 requestまで無料価格 100,000リクエストあたり$0.06 HTTPは100,000あたり$0.06 メールは100,000通あたり$2.0 100SMSあたり、$0.75 SQSにはチャージなし
  • 35. SNSの制約 最大1アカウント100トピックまで メッセージは最大8KBまで
  • 36. SNSまとめクラウド上の通知サービス簡単に使えて、マルチプロトコル従量課金制で非常に安いインストール・管理不要ですぐに使える
  • 37. AWSマイスターシリーズ~SimpleDB~ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
  • 38. SimpleDBとは AWSの裏ワザ
  • 39. アジェンダSimpleDBが出てきた背景SimpleDBとはSimpleDBの機能SimpleDBの使いどころQ&A
  • 40. One Size Does Not Fit All RDBMSが全てではない  EC2+EBSまたはRDSは汎用的 より目的特化なデータベース  シンプルな利用例でより簡単にス ケールさせる  管理者不要  低コスト
  • 41. SimpleDBの出てきた背景 RDBMSが全てではない  EC2+EBSまたはRDSは汎用的 目的特化型サービス  NoSQL  管理者不要  低コスト
  • 42. SimpleDBの出てきた背景 多くのアプリケーションでRDBMSの高機能が必要ない場合がある  複雑なトランザクション  複雑なジョイン  シンプルにデータを永続化したい  データモデルの制約
  • 43. SimpleDBとは AWS独自のNoSQLデータベース 管理者不要 スケーラブル 高い可用性・高い耐障害性  データは複数DCに自動レプリケーション  データは自動インデクシング 柔軟なデータモデル 圧倒的に低コスト
  • 44. SimpleDBの位置づけ CAP定理  一貫性(C)、可用性(A) 、ネット ワーク分断耐性(P)のうち、分散 環境では実質上ネットワーク分断 耐性が必須のため、一貫性か可用 性のどちらかを取らなくてはいけ ない。
  • 45. SimpleDBのデータモデル ドメイン  アイテムを保持する器=テーブル アイテム  アトリビュートを保持する1行 アトリビュート  アイテム内にあるKey-Valueまたは Key-[Value]
  • 46. SimpleDBのデータモデル
  • 47. SimpleDBの書き込み トランザクションは1アイテムのみ 複数アイテムの同時書き込みにはトランザクシ ョンはかけられない ConditionalPut  現在の値がXXXの場合のみ、データを更新  楽観的並行制御
  • 48. SimpleDBの読み込み イベンチュアルコンシステンシな読み込み  デフォルト  パフォーマンス重視  低レイテンシ、高スループット  読み込みの一貫性がない可能性がある  大体1秒程度で一貫性が保たれる 一貫性のある読み込み  比較的低いパフォーマンス  ただしデータは一貫している  ConsistentRead = trueオプション
  • 49. SimpleDBで出来る操作 ドメインへの操作  CreateDomain/DeleteDomain/ListDomains アイテム/アトリビュートの追加  PutAttributes/BatchPutAttributes アイテム/アトリビュートの削除  DeleteAttributes/BatchDeleteAttributes アイテム/アトリビュートの検索  GetAttributes/Select
  • 50. 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
  • 51. RDBMSとSimpleDBの違いRDBMS SimpleDB 事前定義したスキーマ  スキーマフリー 管理コスト高い  管理コスト低い 1台で稼働する事が前提  オートスケール SQLによるアクセス  SQLライクなクエリ リニアにはスケールしない  スケールする トランザクションあり  トランザクションなし インデックスは明示的  自動インデックス 構造化データ  半構造化データ 汎用的  やや目的特化型
  • 52. 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まで
  • 53. SimpleDBをスケールさせるためには?スケールアウトデザインがフィットする  書き込みをスケール→シャーディング  読み込みをスケール→データ構造/クエリの工夫SimpleDBに対して出来るだけ並行してリクエストする  論理パーティションキー • キーの設計がとても重要
  • 54. SimpleDBのベストプラクティス ソート  ソートのため、数値データは0パディングしてやる  日付はISO 8601フォーマットを使う Selectクエリ  WHERE句ではなく、コンポジットキーを使う • Name=“Firstname:Lastname”  AND句を極力使わない  LIMITを設定し、レンジクエリを極小化する。LIMIT 2500など
  • 55. SimpleDBのベストプラクティス シャーディング  書き込みのスループットを上げるため  ハッシュ値または、より適切なキー分割を指定 一貫性  読み込みではオプションを適切に使う • イベンチュアルコンシステンシ • read-after-writeコンシステンシ  書き込みはなるべく非同期書き込み or ConditionalPutを使う パフォーマンス  BatchPutまたはBatchDeleteをデフォルト使う • 25アイテムの書き込みで20-25%程度は向上する 
  • 56. SimpleDBのベストプラクティス 巨大データの扱い  BLOB的に使うのではなくS3に保存して、ポインタを SimpleDBに保存する • 2ホップかかるがわかりやすい  データを分割し、複数のアトリビュートに圧縮して 押し込める • 1ホップだが複雑 設計  データは非正規化する前提  スキーマフリーな点を有効に使う  クエリベースで考えて極力ドメインを分ける • 分割によるスケールメリット
  • 57. SimpleDBの価格 マシンの利用料金  クエリ毎にかかった消費量を計算  $0.162/hour データトランスファー  インバウンドは無料  アウトバウンドは$0.201/GBから データストレージ料  $0.29/GB SimpleDBの利用料は他に比べてかなり安い  ただし先ほどのような制約がある
  • 58. SimpleDBをいつ使うか? シンプルなクエリだがスケールが求められる場合 データベース管理者がいないため、管理コストを下げた い場合  データモデルを理解して開発できる人材は必要  銀の弾丸ではない ユニークキーによる分散が簡単に出来て、スケールアウ トさせやすいケースの場合 データ構造が頻繁に変わるため、それを低コストで行い たい場合 低コストでデータベースを持ちたい場合 高い可用性とスケーラビリティが必要な場合
  • 59. SimpleDBで顧客は何を動かしているか?オンラインゲームプラットフォームS3のコンテンツのインデックス設定ファイルなどの置き場所ソーシャルデータの蓄積マイニングデータの解析結果のストア  EMRと連携はしないのか?
  • 60. まとめAWS独自のNoSQLデータベース管理者不要スケーラブル高い可用性・高い耐障害性 データは自動レプリケーション、インデクシ ング柔軟なデータモデル圧倒的に低コスト
  • 61. SQS、SNS、SimpleDBを通じてAWS SシリーズはAWSクラウドをよりよく使うためのコンポーネント  SQS=疎結合を提供する  SNS=プロトコル非依存な通知  SimpleDB=簡単に使えるDB
  • 62. ご参加ありがとう ございました Copyright © 2011 Amazon Web Services