20111215 12 aws-meister-sqs_sns_sdb-public
•
9 j'aime•6,123 vues
ほぼ週間AWSマイスターシリーズのSQS,SNS,SimpleDBの回の資料です。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 20111215 12 aws-meister-sqs_sns_sdb-public
Similaire à 20111215 12 aws-meister-sqs_sns_sdb-public (20)
Plus de Amazon Web Services Japan
Plus de Amazon Web Services Japan (20)
Dernier
Dernier (10)
20111215 12 aws-meister-sqs_sns_sdb-public
- 1. AWSマイスターシリーズ ～SQS, SNS, SimpleDB～ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 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 ) ソリューションアーキテクト
- 6. SQS(Simple Queue Service)とは AWSの隠し技
- 7. SQS(Simple Queue Service)とは 分散キューサービス AWSをスケールアウトして使うためのキーコ ンポーネント 最低一度は届くことを保証 信頼性が高く、すぐに使えて、管理 者不要、低コスト 2006年よりある最古参サービス
- 8. 何故キューが必要か？ “分割できないものは、スケール出来 ない” by Randy Shoup(eBay) スケールするには疎結合なアーキテクチャに する必要がある 疎結合アーキテクチャに非同期通信が不可欠 非同期通信の典型例がキューシステム
- 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" }]}
- 21. 最近のSQS機能追加 CloudWatchによるメトリクス監視 AutoScalingと組み合わせやすく マネージメントコンソールから利用可能に ディレイキュー メッセージタイマー バッチAPI
- 22. SQSをいつ使うか？ AWSクラウド内での疎結合アーキテ クチャを採用したい場合 コンポーネント間の依存関係を減 らしたい AWSクラウドとオンプレミスの間で のやり取りのインタフェース 受諾と処理→結果の送信の分離
- 23. 顧客はいつSQSを使っているか？ ハイブリッド オンプレミスとAWSクラウド クラウド連携 連携 イメージ処理、インデクシング Webアプリケー 等のシステム間の疎結合なやり ション/SaaS 取りに利用 ビッグデータや EMRやAWSクラウドの バッチ処理 その他サービスとの連携に利用
- 24. SQSまとめ AWSが提供するキューサービス 最低一度は届くことを保証 分散キューのためスケールする 高い耐障害性 シンプルにすぐに使える セキュア 低コスト
- 25. AWSマイスターシリーズ ～Simple Notification Service～ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 29. SNSの機能 様々なプロトコルに対応した通知プ ラットフォーム メール、SQSキュー、HTTP/HTTPSコ ールバック、SMS シンプルなAPI/SDK プッシュベースアーキテクチャ 非常に低価格
- 30. 動作イメージ 管理者 1.トピックの作成/5.トピックの削除 2.トピック購読 3.メッセージ配信 4.メッセージ受信 メッセージ配信者 メッセージ購読者 (Publisher) (Subscriber)
- 34. 利用用途 様々なプロトコルを通じたアプリケ ーション間のフックに使う AWSクラウド上のアプリケーション S3 ファイル 完了通知依頼 SNS ジョブ 完了通知&ジョブ実行
- 35. 利用用途 S3上からファイルが削除されたとき をフック AWSクラウド上のアプリケーション ユーザが削除 S3 削除通知依頼 SNS 削除されたことを通知
- 36. SQSとSNSの違い SQSはポーリングモデル 1:1コミュニケーション Producer-Consumer SNSはプッシュモデル 1:Nコミュニケーション Publisher-Subscriber
- 37. 開発者に優しい無料枠と価格 月間100,000 requestまで無料 価格 100,000リクエストあたり$0.06 HTTPは100,000あたり$0.06 メールは100,000通あたり$2.0 100SMSあたり、$0.75 SQSにはチャージなし
- 40. AWSマイスターシリーズ ～SimpleDB～ 2011年12月15日 大谷 晋平 (@shot6 ) ソリューションアーキテクト
- 43. One Size Does Not Fit All RDBMSが全てではない EC2+EBSまたはRDSは汎用的 より目的特化なデータベース シンプルな利用例でより簡単にス ケールさせる 管理者不要 低コスト
- 44. SimpleDBの出てきた背景 RDBMSが全てではない EC2+EBSまたはRDSは汎用的 目的特化型サービス NoSQL 管理者不要 低コスト
- 45. SimpleDBの出てきた背景 多くのアプリケーションで RDBMSの高機能が必要ない場合 がある 複雑なトランザクション 複雑なジョイン シンプルにデータを永続化したい データモデルの制約
- 46. SimpleDBとは AWS独自のNoSQLデータベース 管理者不要 スケーラブル 高い可用性・高い耐障害性 データは複数DCに自動レプリケーション データは自動インデクシング 柔軟なデータモデル 圧倒的に低コスト
- 47. SimpleDBの位置づけ CAP定理 一貫性(C)、可用性(A) 、ネット ワーク分断耐性(P)のうち、分散 環境では実質上ネットワーク分断 耐性が必須のため、一貫性か可用 性のどちらかを取らなくてはいけ ない。
- 49. SimpleDBのデータモデル ドメイン アイテムを保持する器=テーブル アイテム アトリビュートを保持する1行 アトリビュート アイテム内にあるKey-Valueまたは Key-[Value]
- 50. SimpleDBのデータモデル
- 51. SimpleDBの書き込み トランザクションは1アイテムのみ 複数アイテムの同時書き込みにはトランザクシ ョンはかけられない ConditionalPut 現在の値がXXXの場合のみ、データを更新 楽観的並行制御
- 52. SimpleDBの読み込み イベンチュアルコンシステンシな読み込み デフォルト パフォーマンス重視 低レイテンシ、高スループット 読み込みの一貫性がない可能性がある 大体1秒程度で一貫性が保たれる 一貫性のある読み込み 比較的低いパフォーマンス ただしデータは一貫している ConsistentRead = trueオプション
- 53. SimpleDBで出来る操作 ドメインへの操作 CreateDomain/DeleteDomain/ListDomains アイテム/アトリビュートの追加 PutAttributes/BatchPutAttributes アイテム/アトリビュートの削除 DeleteAttributes/BatchDeleteAttributes アイテム/アトリビュートの検索 GetAttributes/Select
- 54. 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
- 55. RDBMSとSimpleDBの違い RDBMS SimpleDB 事前定義したスキーマ スキーマフリー 管理コスト高い 管理コスト低い 1台で稼働する事が前提 オートスケール SQLによるアクセス SQLライクなクエリ リニアにはスケールしない スケールする トランザクションあり トランザクションなし インデックスは明示的 自動インデックス 構造化データ 半構造化データ 汎用的 やや目的特化型
- 56. 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まで
- 57. SimpleDBをスケールさせるためには？ スケールアウトデザインがフィットする 書き込みをスケール→シャーディング 読み込みをスケール→データ構造/クエリの工夫 SimpleDBに対して出来るだけ並行してリクエ ストする 論理パーティションキー • キーの設計がとても重要
- 58. SimpleDBのベストプラクティス ソート ソートのため、数値データは0パディングしてやる 日付はISO 8601フォーマットを使う Selectクエリ WHERE句ではなく、コンポジットキーを使う • Name=“Firstname:Lastname” AND句を極力使わない LIMITを設定し、レンジクエリを極小化する。LIMIT 2500など
- 59. SimpleDBのベストプラクティス シャーディング 書き込みのスループットを上げるため ハッシュ値または、より適切なキー分割を指定 一貫性 読み込みではオプションを適切に使う • イベンチュアルコンシステンシ • read-after-writeコンシステンシ 書き込みはなるべく非同期書き込み or ConditionalPutを使う パフォーマンス BatchPutまたはBatchDeleteをデフォルト使う • 25アイテムの書き込みで20-25%程度は向上する
- 60. SimpleDBのベストプラクティス 巨大データの扱い BLOB的に使うのではなくS3に保存して、ポインタを SimpleDBに保存する • 2ホップかかるがわかりやすい データを分割し、複数のアトリビュートに圧縮して 押し込める • 1ホップだが複雑 設計 データは非正規化する前提 スキーマフリーな点を有効に使う クエリベースで考えて極力ドメインを分ける • 分割によるスケールメリット
- 61. SimpleDBの価格 マシンの利用料金 クエリ毎にかかった消費量を計算 $0.162/hour データトランスファー インバウンドは無料 アウトバウンドは$0.201/GBから データストレージ料 $0.29/GB SimpleDBの利用料は他に比べてかなり安い ただし先ほどのような制約がある
- 62. SimpleDBをいつ使うか？ シンプルなクエリだがスケールが求められる場合 データベース管理者がいないため、管理コストを下げた い場合 データモデルを理解して開発できる人材は必要 銀の弾丸ではない ユニークキーによる分散が簡単に出来て、スケールアウ トさせやすいケースの場合 データ構造が頻繁に変わるため、それを低コストで行い たい場合 低コストでデータベースを持ちたい場合 高い可用性とスケーラビリティが必要な場合
- 64. まとめ AWS独自のNoSQLデータベース 管理者不要 スケーラブル 高い可用性・高い耐障害性 データは自動レプリケーション、インデクシ ング 柔軟なデータモデル 圧倒的に低コスト
- 65. SQS、SNS、SimpleDBを通じて AWS SシリーズはAWSクラウドを よりよく使うためのコンポーネント SQS=疎結合を提供する SNS=プロトコル非依存な通知 SimpleDB=簡単に使えるDB
- 66. ご参加ありがとう ございました Copyright © 2011 Amazon Web Services