Más contenido relacionado Más de Ryuichi Tokugami (18) DynamoDB (2012-02-18 JAWS-UG Osaka勉強会 第5回)1. ⼆二
⽉月
⼗十
⼋八
Japan AWS User Group ⽇日
(JAWS-‑UG)
-‑ Osaka勉強会 第5回
2. 昨⽇日デブサミ⾏行ってきた Open
Developer
Summit
2012
2012.2.16〜~2012.2.17
10年⽬目の
けっこういっぱい⼈人が集まる凄いイベント
3. OpenJam しゃべ
セッションとは別に⽤用意されている、
コミュニティの 参加コミュニティが発表できる場
紹介と
最近の動向とか
4. しゃべって来ました。 Nextタ
瞬間最⼤大
観客動員数:2⼈人
DynamoDBについて30分間話そうと
思ってました。
5. 勝⼿手にAWSアップデート Nextタ
VPC内でロードバランサ(Elastic Load Balancing)が利⽤用可能に,Amazon ElastiCacheが東京リージョンで利⽤用可能
に,Amazon S3にマルチオブジェクトデリートを追加,アーキテクチャのダイアグラムのためのAWSシンプルアイコ
ンの発>
表,CloudFrontとRoute 53のエッジロケーションを3か所追加,リザーブドインスタンスに新しい2つの料⾦金モデルを
追加,Amazon Simple Email Service (SES)がSMTPをサポート,南⽶米 (サンパウロ) リージョンの発表,CloudFrontが
⼤大フ>
ァイルサイズ(20GB)のコンテンツ配信をサポート,VPC内でマルチゾーンにまたがったAuto Scalingが利⽤用可能
に,Amazon EMRでクラスターコンピュートCC2が使えるように,Virtual Private Cloudの中でネットワークインタ
フェースを>⾃自在にコントロールできるElastic Network Interfaceの発表,AWS Management Console上で各EC2
インスタンス、EBSボリューム から直接アラームを作成できるように,EC2インスタンスのステータスチェックと
レポーティング,Amazon S3の有効期限機能の発表,Amazon RDSでも3種類のリザーブドインスタンスが利⽤用可能
に,クラウドに専⽤用線接続できるAWS Direct Connectが東京リージョンでも利⽤用可,AWS無料使⽤用枠でEC2の
Microsoft Windowsサーバも利⽤用可能に,
Amazon DynamoDB -‑ インターネット時代
のアプリケーションのために 設計された⾼高
速でスケーラブルなNoSQL データストレージ,Identity Federationのコ
ンソール統合,Virtual Private Cloudの中でRelational Database Serviceが利⽤用 可能に,AWS Storage Gateway,Auto
Scaling Groupのタギング機能,AWS Premium SupportのThird-‑Party Software SupportとAWS Trusted Advisor
(⽇日本では未発表),Amazon S3に保存されているオブジェクトの数は7620億に,EMRの新機能:新メトリクス、
VPC、CC2対応,⼤大阪とミラノにAmazon CloudFrontとAmazon Route 53の拠点追加,Amazon S3の価格さらに値下
げ
6. Amazon DynamoDB Amaz
Amazon
DynamoDB
2012.1.18
release
クラウドのために作られた⾼高いパフォーマ
ンスを持ったNoSQLデータベースMySQL
9. Amazon⽈曰く Amaz
0.1秒遅くなると、売り上げが1%減少する
342億400万ドル
その1%は3億4240万ドル
amazon.com ⽇日本円だと約260億円
昨年の私のブログでのアフィリエイト14円
10. Amazonに必要なDB 求めら
どんなにレコードが増えてもレスポンスが
早い
ノードが落ちてもシステムは動き続けなく
てはいけない
在庫のこととかを考えると⼀一貫性も欲しい
って考えたと想像出来ます。
11. 求められる 速度 求めら
速度だけなら
スケールアウト
スケールアップ
どちらでも
ただ⾼高速に書きこむだけならそんなに難し
速度だけなら くない。
やり⽅方は
いくらでもある
12. 求められる 可⽤用性 RDBM
可⽤用性だけなら
冗⻑⾧長
にすればいい
サーバが停⽌止してもシステムは⽌止まらない
可⽤用性だけなら データセンターが爆発しても⽌止まらない
やり⽅方は
いくらでもある
13. RDBMSのツラい所 RDBM
⼀一貫性と可⽤用性
の両⽴立困難
This excess functionality requires
expensive hardware and highly skilled
personnel for its operation, making it a
very inefficient solution. In addition, the
(>_̲<) available replication technologies are
limited and typically choose consistency
over availability.
14. RDBMSは必要なのか? 02 Oc
殆どの場合
PrimaryKey
だけでいいぜ
俺達に Most of these services only store and
RDBMSの retrieve data by primary key and do not
require the complex querying and
複雑な照会は
management functionality offered by an
いらなかった RDBMS.
15. 02 Oct 2007 Amaz
俺が作った
Amazonʼ’s
Dynamo absolutely,
の論⽂文だ honored to!
Amazonʼ’s Highly Available Key-‑value Store
http://www.allthingsdistributed.com/
Amazon.com
2007/10/amazons_̲dynamo.html
CTO
Werner Vogels
16. Amazonʼ’s Dynamo そこか
Amazonʻ‘s
Dynamo
無駄なHOPはなし、⼀一発でデータにアクセ
ス出来る分散ハッシュテーブル
ノードが何個か死んでも⼤大丈夫
それがAmazon Dynamo
17. そこから更に進化 IOPS
Amazon
DynamoDB
論⽂文のDynamoから進化してサービス化
別物!?
18. IOPS保証 Atom
Read,Write
IOPS 保証
IOPS= Input Output Per Second
1秒間辺りにどれくらいのreadとwriteが出
来るかが保証される。
そのIOPSによって時間課⾦金
Write:10Unit Read:50Unit で1時間$0.01
メンテナンスは、どれくらいのIOPSが必要
かをAPIで指⽰示するだけ
19. Atomic Counter ⼀一貫性
値を取ってくる→
アプリ側で加算-‑>
上書き
結果整合性の
こんな加算では整合性はすこぶる怪しい。
弱点
DynamoDBなら⼤大丈夫。CAS操作が可能
20. ⼀一貫性 集計と
⼀一貫性も
欲しいのか?
必要のないところでは結果整合性を
強⼀一貫性 コストは倍かかるが
と 必要なところだけ強い⼀一貫性も可能
結果整合性 WriteじゃなくてReadのリクエスト毎にこの
オプションをつけられる。
21. 集計とかは⾮非効率? Nextタ
RDBMSの
AVGとか
SUMとか
集計は集計結果を保存するテーブルに⼊入れ
ておけば良い。
CAS操作の出来るDynamoDBなら可能。
BatchGet 複数テーブルから同時にデータが取れる
BatchGetもある。
22. EMRとの連携 バック
Hadoopで
処理
With ⼤大規模な集計であればAmazon
ElasticMapReduce(Hadoop)を使って処理
Amazon が可能。
Elastic
MapReduce
23. バックアップもEMRで データ
信頼性
99.999999999
のS3に
バックアップ
Amazon Elastic MapReduceを使って
S3にバックアップも可能
バックアップしたデータとのJOINも可能
24. データの構造 ソフト
Keyは2種類
単純な HashKeyとRangeKey
RangeKeyは使わなくてもOK
KeyValue
Valueには4種類の型
ではない STRING,NUMBER,
STRING_̲SET,NUMBER_̲SET
25. サービス vs ソ
サービスとして提供されるから
ハードウェアの⼼心配も必要ない。
ネットワークや、パフォーマンス確保の為
メンテナンス
のインフラエンジニアも必要ない。
フリー 必要なのは、欲しいパフォーマンスを
知らせる為にAPIを叩く事だけ。
26. vs ソフトウェアとか Dyna
ハードウェアスペックから、パフォーマン
スがある程度⾃自動で決まる
欲しいのは
=>ハードウェアスペックを調整可能
スペック?
パフォーマンス? パフォーマンスからハードウェアの調整を
⾃自動でやってくれる。
=> パフォーマンスを調整可能
27. スケールが必要なら Nextタ
スケールする データベースのスケールが必要なアプリ
ケーションでアレばDynamoDBは選択肢に
必要があるなら
なる。
とりあえず
DynamoDB 急成⻑⾧長を望むならスケールに⼿手間がかかる
けど、強⼒力な照会機能があるDBと、メンテ
フリーなNoSQLどっちを選ぶのか
28. なんか事例も話したい ⼤大規模
機会学習で
実現する
オンライン機械学習で実現する
⼩小規模からのデータ処理
数Mバイトから、
⼩小規模からの
数T,数Pバイトオーダまで
データ処理 を扱うテキストマイニングサービスが
もうすぐ出てくるらしい。
29. 事例:MiningBrownie社 どんな
テキスト
マイニング
サービス
テキストマイニングを
APIから使えて、
従量課⾦金だから、簡単に始められる
簡単にやめられる
hotaru クラウドっぽいサービス
33. そして分類へ Nextタ
この⽂文章を判定してくれや
とAPIに尋ねれば
こいつはこれだと返します。
34. なぜDynamoDB 何に使
RDBMSじゃ
ダメだったの
か?
スモールスタートを提供するためには重量
SimpleDBじゃ 課⾦金のデータベースが必要だった
ダメだったの
想定レコード数:10billionのオーダー
か? 天井が⾒見えちゃいけない
スケールを⾃自動化(パフォーマンス&容量)