AWS Black Belt Techシリーズ Amazon DynamoDB

1. Amazon DynamoDB AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) アマゾンデータサービスジャパン株式会社ソリューションアーキテクト　今井雄太

2. Agenda •  NoSQLとRDB •  DynamoDBとは •  テーブル設計 •  テーブル設計サンプル •  運⽤用関連 •  ツールとエコシステム •  まとめ

4. よく⾒見見かけるNoSQLデータベース •  Neo4j •  Couchbase •  DynamoDB •  MongoDB •  Riak •  HBase •  Cassandra

5. NoSQL vs RDB トランザクション特性 ➔BASE 得意/メリット ➔スケーラビリティ不得意/デメリット ➔複雑なクエリ ➔トランザクショントランザクション特性 ➔ACID 得意/メリット ➔柔軟なクエリ ➔トランザクション不得意/デメリット ➔スケーラビリティ NoSQL RDB

6. BASE?

7. Basically Available, Soft-‐‑‒state, Eventually consistent •  主に分散システム上でのスケーラビリティを確保するために厳密なトランザクションをあきらめている –  Basically Available:サービス提供中であっても、古いデータが返ることや、データ更更新作業のためにクエリが失敗する可能性がある –  Soft-‐‑‒state:⼊入⼒力力がない状態でも、結果整合性をたもつためのデータ更更新作業により、状態の変化がある可能性がある –  Eventually consistent:データ更更新モデルは結果整合性が取られており、⼊入⼒力力後の即時更更新は保証されない •  すべてのNoSQLが完全にBASEとは限らない（実装による）

8. CAP定理理?

9. CAP定理理とは •  分散データベースにおいて、次の3つを同時に保証することはできない (2つを保証すると、残り1つを妥協しなければならない) –  Consistency = ⼀一貫性 –  Availability = 可⽤用性 –  Partition-‐‑‒tolerance = ネットワーク分断耐性参考　http://ja.wikipedia.org/wiki/CAP定理理 DynamoDBはAとPを優先したデータベースただしオプションでCの特性も確保可能

10. NoSQLの使いドコロ？

11. NoSQLの使いドコロ⼀一般的にNoSQLの特徴として、下記の点があげられる –  ストレージ容量量をスケールさせやすい –  スループットをスケールさせやすい –  実際にストレージやスループットが増えてきた時に性能劣劣化しにくいこれらの特徴が必要とされるところがNoSQLの使いドコロ。ただし、これもNoSQLの⼀一般的な特徴として、⾃自前で運⽤用するのにはかなりの労⼒力力が必要とされる。

12. DynamoDBはNoSQL as a Serviceなので運⽤用作業を最⼩小化できる

14. DynamoDBとは •  NoSQL as a Service •  超⾼高速・予測可能な⼀一貫したパフォーマンス •  シームレスなスケーラビリティ、そして低コスト運⽤用管理理必要なし低レイテンシ、SSD プロビジョンスループット無限に使えるストレージ

15. DynamoDBの⽣生い⽴立立ち •  Amazon.comではかつて全てのアクセスパターンをRDBMSで処理理していた •  規模が⼤大きくなるにつれて、RDBMSの課題に直⾯面 –  スケーラビリティ •  処理理能⼒力力を向上させるのが難しい。データの再配置、より⼤大きなHWを導⼊入するなどの対処が必要。 –  可⽤用性 •  RDBMSは可⽤用性よりもデータの整合性を重視する設計 •  トランザクション処理理が不不要な場⾯面でも、全てはトランザクションとして処理理される èパフォーマンスのオーバーヘッド⼤大

16. DynamoDBの⽣生い⽴立立ち •  RDBMSの課題に対処するため、Amazon Dynamo (DynamoDBの先祖)を設計・開発 •  Amazon Dynamoの特⻑⾧長 –  ベネフィット •  結果整合性モデル採⽤用による可⽤用性向上 •  HWを追加する毎に性能が向上するスケーラビリティ •  クエリーモデルが単純なためパフォーマンスが予測できる –  妥協点 •  強い整合性モデルではない •  スケールアップの際にHWの追加やクラスタのリバランスが必要 •  開発者がDB管理理作業から開放されるわけではない èAmazon S3のように”サービスとして使いたい”という声

17. DynamoDBの誕⽣生 •  AWS上に「サービス」として実装 •  Amazon Dynamoをサービス化したものではないので注意 •  パフォーマンスのために堅牢牢性・可⽤用性を妥協しない •  常に低レイテンシーで応答を返す •  開発者（利利⽤用者）はスケーラビリティを気にしなくて良良く、いつでも簡単に増減できる •  サーバーやディスク台数ではなく、シンプルに必要な読み書きの性能数値を指定するだけ •  管理理作業が不不要

18. DynamoDBの特⻑⾧長 •  管理理不不要で信頼性が⾼高い •  プロビジョンドスループット •  ストレージの容量量制限がない

19. 特⻑⾧長１：管理理不不要で信頼性が⾼高い •  SPOFの存在しない構成 •  データは3箇所のAZに保存されるので信頼性が⾼高い •  ストレージは必要に応じて⾃自動的にパーティショニングされるクライアント

20. 特⻑⾧長２：プロビジョンドスループット •  テーブルごとにReadとWriteそれぞれに対し、必要な分だけのスループットキャパシティを割り当てる（＝プロビジョンする）ことができる •  例例えば下記のようにプロビジョンする –  Read : 1,000 –  Write : 100 •  書き込みワークロードが上がってきたら –  Read : 500 –  Write : 1,000 •  この値はDB運⽤用中にオンラインで変更更可能 –  ただし、スケールダウンに関しては⽇日に４回までしかできないので注意

21. 特⻑⾧長３：ストレージの容量量制限がない •  使った分だけの従量量課⾦金金制のストレージ •  データ容量量の増加に応じたディスクやノードの増設作業は⼀一切切不不要

22. DynamoDBの整合性モデル •  Write •  少なくとも２つのAZでの書き込み完了了が確認とれた時点でAck •  Read •  デフォルト •  ⼀一貫性保証のないRead •  Consistent Readオプションを付けたリクエスト •  Readリクエストを受け取る前までのWriteがすべて反映されたレスポンスを保証 •  ただし、Capacity Unitを２倍消費する

23. DynamoDBの料料⾦金金体系 •  プロビジョンドスループットで決まる時間料料⾦金金 –  Read/Writeそれぞれプロビジョンしたスループットによって時間あたりの料料⾦金金がきまる –  ⼤大規模に利利⽤用するのであればリザーブドキャパシティによる割引もあり •  ストレージ利利⽤用量量 –  保存したデータ容量量によって決まる⽉月額利利⽤用料料⾦金金 –  計算はGBあたりの単価が適⽤用される –  GBあたり$0.285(2014/05現在@東京リージョン) http://aws.amazon.com/jp/dynamodb/pricing/ 　

24. DynamoDBの料料⾦金金体系 •  プロビジョンドスループット –  書き込み •  $0.00742 :10 ユニットの書き込み容量量あたり/1 時間 –  読み込み •  $0.00742 : 50 ユニットの読み込み容量量あたり/1 時間 •  キャパシティユニット上記で「ユニット」と呼ばれている単位のこと –  書き込み •  1ユニット：最⼤大1KBのデータを1秒に1回書き込み可能 –  読み込み •  1ユニット：最⼤大4KBのデータを1秒に1回読み込み可能（強⼀一貫性を持たない読み込みであれば1秒辺り2回）

25. DynamoDBが使われているユースケース •  KVSとして –  Webアプリケーションのセッションデータベース –  ユーザー情報の格納するデータベース •  広告やゲームなどのユーザー⾏行行動履履歴DBとして –  ユーザーIDごとに複数の⾏行行動履履歴を管理理するためのデータベース •  ソーシャルアプリのバックエンドとして –  モバイルアプリから直接参照できるデータベースとして •  他にも –  バッチ処理理のロック管理理 –  フラッシュマーケティング –  ストレージのインデックス

26. DynamoDBを使い始めるには 1.  テーブルのKeyやIndexを決める 2.  Read/Writeそれぞれのスループットを決める Thatʼ’s it, write your code!

27. DynamoDBの構成要素 API SDK オペレーションはHTTPベースのAPIで提供されている Database Client SideService Side Client application

28. 提供されているAPI •  PutItem •  UpdateItem •  GetItem •  DeleteItem •  Query •  Scan •  BatchWriteItem •  BatchGetItem •  CreateTable •  DescribeTable •  UpdateTable •  DeleteTable

29. 提供されているAPI •  PutItem •  UpdateItem •  GetItem •  DeleteItem •  Query •  Scan •  BatchWriteItem •  BatchGetItem •  CreateTable •  DescribeTable •  UpdateTable •  DeleteTable SDK経由で利利⽤用するのが楽。もちろん、⾃自前実装も可能です。

30. AWS SDKs and CLI •  各種⾔言語むけのオフィシャルSDKやCLIを利利⽤用 Java Python PHP .NET Ruby nodeJS iOS Android Javascript in the Browser AWS CLI

31. オフィシャルSDK以外にも •  Perl –  Net::Amazon::DynamoDB •  Erlang –  wagerlabs/ddb •  https://github.com/wagerlabs/ddb •  Go –  goamz •  https://github.com/crowdmob/goamz

33. •  Hash keyをプライマリキーとして定義したテーブルの例例 DynamoDBのデータモデル(1/2) Table Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Table Item Attribute1 (Number) Hash key Item Attribute1 (Number) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Hash key Itemは必ずHash keyに指定された Attributeを持ち、これがプライマリキーになるプライマリキー以外のAttributeは事前定義の必要はなくput時に指定したものを格納できる

34. •  Hash keyとRange keyをプライマリキーとして定義したテーブルの例例 DynamoDBのデータモデル(2/2) Table Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Table Item Attribute1 (Number) Hash key Item Attribute1 (Number) Attribute3 (Binary) Hash key Item Attribute1 (Number) Hash key Itemは必ずHash keyとRange　 keyに指定されたAttributeを持ち、これがプライマリキーになるプライマリキー以外のAttributeは事前定義の必要はなくput時に指定したものを格納できる Range key Range key Range key Attribute2 (String) Attribute2 (String) Attribute2 (String) Range key Range key Range key

35. テーブル設計のための基礎知識識(1/2) •  Table –  いわゆるテーブル –  プライマリキーの持ち⽅方が２つあり、Hash keyをプライマリキーとするパターンと、Hash keyとRange keyの複合キーをプライマリキーとするパターンがある •  Hash key –  順序を指定しないハッシュインデックスを構築するためのキー –  単体でプライマリキーとして利利⽤用されることがある •  Range key –  Hash keyに該当する複数のデータの順序を保証するためのキー –  Hash + Rangeでプライマリキーとすることもできる

36. テーブル設計のための基礎知識識(2/2) •  Item –  RDBで⾔言ういわゆるレコード –  1つ以上のAttributeを持つ •  Attributes –  データの中⾝身。RDBで⾔言うカラム。 –  Hash key, Range keyに該当するAttributes以外は事前に定義する必要はない。 –  レコード間でAttributesが不不揃いであっても問題ない。 •  Attributesの型 –  String –  Number –  Binary –  Set of String –  Set of Number –  Set of Binary

37. A,D B,E C,F 1　2　3　4　5　6　7　8　9 Parition1 Partition2 ParitionN Range key Partition内でのデータの並びを保証する Hash key Partition間でのデータ分散に利利⽤用される Partition DynamoDBでは、性能を確保するためにデータはパーティションに分散して格納される Hash keyとRange keyの概念念(1/2)

38. A,D B,E C,F 1　2　3　4　5　6　7　8　9 Parition1 Partition2 PartitionN Hash keyとRange keyの概念念(2/3) Partition •  DynamoDBはプロビジョンされたスループットを確保するためにデータを複数の Partitionに分散して格納している •  Partitionは格納データ容量量やプロビジョンされたスループットによって⾃自動的にリパーティショニングが実施される •  いま現在のPartition数を確認することはできない

39. A,D B,E C,F 1　2　3　4　5　6　7　8　9 Parition1 Partition2 ParitionN Hash keyとRange keyの概念念(3/3) スループットはPartitionに均等に付与される •  プロビジョンしたスループットは各パーティションに均等に付与され、全体で合計値の性能が出るように設計されている •  アクセスされるキーに偏りが発⽣生すると思うように性能がでないという⾃自体を招くため、Hash keyの設計には注意が必要プロビジョンドスループット: x x/N x/N x/N

40. テーブル設計のための基礎知識識+1 •  Local Secondary Index –  Range key以外に絞り込み検索索のためのキーを持つことができる –  Hash keyが同⼀一のアイテム群の中からの検索索のために利利⽤用 –  インデックスもテーブルにプロビジョンしたスループットを利利⽤用する •  Global Secondary Index –  Hash Keyをまたいで検索索を⾏行行うためのインデックス –  インデックスにテーブルとは独⽴立立したスループットをプロビジョンして利利⽤用する

41. Local Secondary Indexes(LSI) •  任意のアトリビュートに張れるQuery⽤用Index –  各テーブルに5つまで –  Hash key内のローカルのセカンダリインデックスを貼る仕組み LSIナシだと、QueryできるのはRange keyのみ ForumName=S3 && Subnect=ʻ‘aaaʼ’ LSIを定義すればKeyでないアトリビュートに関してもQuery可能に(ただしテーブル作成時にAttributeを LSIとして事前設定する必要あり) 　ForumName=S3 && Replies >= 10 　ForumName=S3 && LastPostDateTime >=.. Forumの投稿を保持するテーブルの例例：

42. •  LSIの実体 –  元のテーブルのRange keyがAttributeのテーブルが作成される –  インデックスのスループット/ストレージ費⽤用もかかる Local Secondary Indexes(LSI) テーブルとインデックスはPartitionのスループットを共⽤用する

43. Local Secondary Indexes(LSI) •  なぜ”Local” Secondary Indexesなの？ハッシュキーが⼀一致する範囲の中のSecondary Indexであるため àハッシュキーが異異なるアイテムを横断的にQueryすることは出来ない RepliesIndexを使って Query可能なのは？ •  ForumNameがS3で Repliesが9以上 •  任意のForumNameで Repliesが９以上 à 3つハッシュキーがあるので3 Query必要 RepliesIndex

44. Local Secondary Indexes(LSI) •  Attributeのプロジェクション –  指定したAttributeをインデックスにプロジェクションできる –  元テーブルへのアクセスを減らすことでReadキャパシティの節約とレイテンシの改善が望める。 –  ⼀一⽅方、Write時のキャパシティやストレージ利利⽤用量量は増える

45. テーブルのスループットテーブルのスループット Local Secondary Indexes(LSI) •  LSIの読み書きモデル Table Index インデックスのみでデータを返せるRead Write Table Index Table Index インデックスのみでデータを返せないRead 1 read 2 read 2 write テーブルのスループット

46. Global Secondary Indexes(GSI) •  Hash keyをまたいでAttributeに貼れるインデックス Range keyもしくはLSIだけでは、UserIdをまたいだ Queryはできない。例例えば下記のようにGameTitleでのQueryはできない。 GameTitle=ʻ‘Galaxy Invadersʼ’ & TopScore >= 100 ゲームのスコアを保持するテーブルの例例：

47. Global Secondary Indexes(GSI) •  GSIの実体 –  元のテーブルのHash keyがAttributeのテーブルが作成される –  インデックスのスループット/ストレージ費⽤用もかかる –  LSIと違い、スループットは独⾃自に定義する –  GSI⾃自体もHash keyによるPartitionを持つテーブルとインデックスはPartitionのスループットを共⽤用しない

48. Global Secondary Indexes(GSI) •  Attributeのプロジェクション –  指定したAttributeをインデックスにプロジェクションできる –  GSIの場合、インデックスにないAttributeはテーブルから⾃自動取得されない –  Write時のキャパシティやストレージ利利⽤用量量は増える

49. Global Secondary Indexes(GSI) •  GSIの読み書きモデル Table Index インデックスのみでデータを返せるRead Write Table Index インデックスのみでデータを返せないRead

50. Global Secondary Indexes(GSI) •  GSIの読み書きモデル Table Index インデックスのみでデータを返せるRead Write インデックスのみでデータを返せないRead 1 read テーブルのスループットインデックスのスループット Table Index 1 write テーブルのスループットインデックスのスループット 1 write

51. LSI/GSIを使う際の注意点 •  LSI/GSIは便便利利だが、スループットやストレージ容量量を追加で必要とする •  特にインデックスの数が増えれば増えるほど書き込みコストが上がる •  セカンダリインデックスに強く依存するようなテーブル設計になるようであれば、⼀一度度RDBで要件を満たせないかを確認してみるのがベター

52. テーブル操作についての基礎知識識(1/3) •  GetItem •  Hash keyを条件として指定し、⼀一件のアイテムを取得 •  PutItem •  1件のアイテムを書き込む •  Update •  1件のアイテムを更更新 •  Delete •  1件のアイテムを削除 •  Query •  Hash keyとRange keyの複合条件にマッチするアイテム群を取得 •  BatchGet •  複数のプライマリキーを指定してマッチするアイテム群を取得 •  Scan •  テーブル総ナメするよく使われるオペレーションは以下のとおり

53. テーブル操作についての基礎知識識(2/3) •  強⼀一貫性を持ったReadオペレーション •  GetItem、QueryにはConsistent Readというオプションを指定することができ、これを利利⽤用すると、Readリクエストを受け取るよりも前に成功しているすべてのWriteリクエストが反映された結果が返る。Read Capacity Unitを通常の2倍消費するので注意。 •  Conditional Write •  「キーにマッチするレコードが存在したら/しなかったら」や「この値が○○以上/以下だったら」という条件付き書き込み/更更新ができるより⾼高度度なオペレーション

54. テーブル操作についての基礎知識識(3/3) •  UpdateItemにおけるAttributeへの操作 •  Attributeに対して、UpdateItemでPut、Add、Deleteという3種類の操作が可能 •  Put：Attributeを指定した値で更更新 •  Add：AttributeがNumber型なら⾜足し算/引き算、Set型ならそのセットに対して値を追加する •  Delete：当該Attributeを削除する •  Atomic Counter •  上記のAddを利利⽤用することによって、Atomicなカウンターを実現することもできるより⾼高度度なオペレーション

56. 冒頭で紹介した以下のユースケースから幾つかのサンプルを紹介 •  KVS的な使い⽅方 –  Webアプリケーションのセッションデータベース –  ユーザー情報の格納するデータベース •  広告やゲームなどのユーザー⾏行行動履履歴DBとして –  ユーザーIDごとに複数の⾏行行動履履歴を管理理するためのデータベース •  ソーシャルアプリのバックエンドとして –  モバイルアプリから直接参照できるデータベースとして •  他にも –  バッチ処理理のロック管理理 –  フラッシュマーケティング –  ストレージのインデックス

57. テーブル設計サンプル1 KVS的な使い⽅方：ユーザー情報データベース

58. KVS的な使い⽅方：ユーザー情報データベースユーザーIDをプライマリキーとしたKVS的なテーブル –  UserIdで⼀一意のItemを特定し情報の参照や更更新、削除を⾏行行う UserId (Hash) Name Nicknames Mail Address Interests aed9d Bob [ Rob, Bobby ] foo@example.com some address [ Car, Motor Cycle] edfg12 Alice [ Allie ] a8eesd Carol [ Caroline ] f42aed Dan [ Daniel, Danny ] Users Table ※DynamoDBにはauto_increment等でユニークIDを払い出す機能はないので注意

59. テーブル設計サンプル2 KVS的な使い⽅方：セッションデータベース

60. KVS的な使い⽅方：セッションデータベースセッションIDをプライマリキーとしたKVS的なテーブル –  新規セッションごとにItemを払いだしてExpire管理理を⾏行行う –  PHP SDKにはDynamoDBを利利⽤用したSession Handlerも同梱されている •  http://docs.aws.amazon.com/aws-‐‑‒sdk-‐‑‒php/guide/latest/ feature-‐‑‒dynamodb-‐‑‒session-‐‑‒handler.html SessionId (Hash) Expiry _a12fh 2014-02-01 00:00:00 _ee12a 2014-02-02 00:00:00 Sessions Table

61. テーブル設計サンプル３ゲームの⾏行行動履履歴管理理データベース

62. ゲームの⾏行行動履履歴管理理データベース User (Hash) Timestamp (Range) Opponent Result Alice 2014-02-21 12:21:20 Bob Lost Alice 2014-02-21 12:42:01 Bob Won Alice 2014-02-24 09:48:00 Dan Won Alice 2014-02-25 16:21:11 Charlie Won Battle History ⾃自分のバトル履履歴を確認するケースを想定 –  Userに⾃自分(Alice)を指定し、更更にTimestampが7⽇日以内のデータをクエリしたりできる Charlie 02-25 16:21 Won! Your Battle History Dan 02-24 09:48 Won! Alice 02-21 12:42 Won!

63. テーブル設計サンプル４：ソーシャル画像共有アプリ

64. ソーシャル画像共有アプリ Home My Posts My Profile UserA Hello World! 10:18 UserB Hello World! 10:12 UserA Hello World! 10:11 UserA Hello World! 10:18 UserA Hello World! 10:11 UserA Hello World! 10:09 Name: UserA Mail: foo Profile: some texts

65. テーブル設計 Users TableFriends Table "   2つのテーブルを定義 •  ユーザ情報テーブル •  友達リストテーブル

66. User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] 友達⼀一覧を取得 Users Table Item Attribute (string, number, binary, set) Primary Key (Hash)

67. User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] 友達⼀一覧を取得 Friends Table User (Hash) Friend (Range) Bob Alice Alice Bob Alice Carol Alice Dan Users Table Hash + Range Primary Key

68. Friends Table Users Table User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] User (Hash) Friend (Range) Bob Alice Alice Bob Alice Carol Alice Dan 友達⼀一覧を取得 Aliceの友達一覧を取得 1.  Query (Table = Friends, Hash = Alice, Range = *) 2. BatchGetItem(Bob, Carol, Dan)

69. 投稿画像の保存と検索索 Images Table User （Hash) Image （Range) Date Link Bob aed4c 2013-10-01 s3://… Bob cf2e2 2013-09-05 s3://… Bob f93bae 2013-10-08 s3://… Alice ca61a 2013-09-12 s3://… Bob Bobの投稿画像一覧を取得 Query (Table=Images, Hash= Bob, Range=*) でもある時刻以降の画像を取得したかったら…?

70. ある⽇日時の画像取得 Images Table User Image Date Link Bob aed4c 2013-10-01 s3://… Bob cf2e2 2013-09-05 s3://… Bob f93bae 2013-10-08 s3://… Alice ca61a 2013-09-12 s3://… User Date Image Bob 2013-09-05 cf2e2 Bob 2013-10-01 aed4c Bob 2013-10-08 f93bae Alice 2013-09-12 ca61a Table ByDate Local Secondary Index Local Secondary Index をDateに張る

71. 画像にユーザのタグ付け ImageTags Table Image User aed4c Alice aed4c Bob f93bae Alice f93bae Bob Image f93baeにAliceをタグ付け PutItem(Table = ImageTags, Hash = f93bae, Range = Alice) Bob でもあるユーザがタグ付けされてる画像の一覧を取得したかったら…? Image f93baeにタグ付けされたユーザ一覧 Query(Table = ImageTags, Hash = f93bae, Range = *)

72. ユーザのタグ付き画像⼀一覧 ImageTags Table UserにImageをRangeキーとした Global Secondary Indexを張る User (Hash) Image (Range) Bob aed4c Bob f93bae Alice aed4c Alice f93bae ByUser Global Secondary Index Image (Hash) User (Range) aed4c Alice aed4c Bob f93bae Alice f93bae Bob Table Bob Aliceがタグ付けされた画像一覧

73. テーブル設計サンプル５：バッチ処理理のロック管理理

74. テーブル設計 "   １つのテーブルを定義 •  ジョブテーブル Process1 JobID (Hash) Progress (LSI) Created Time aed4c Done 2014-01-01 00:00:00 aed4c Done 2014-01-01 00:00:02 f93bae InProcess 2014-01-01 00:01:10 f93bae NotYet 2014-01-01 00:01:18

75. バッチ処理理のロック管理理 S3 S3 S3 EMR EMR 処理理１処理理２ジョブのロック管理

76. バッチ処理理のロック管理理 S3 S3 処理理１ Jobs Table JobID (Hash) Created Time(Range) Process1 Process2 aed4c 2014-01-01 00:00:00 Done InProcess aed4c 2014-01-01 00:01:00 NoｔYet NotYet Process1が未処理のジョブ一覧を取得 1.  Scan (Table = jobs, Process1 = ‘NotYet’) Process1が未処理のジョブ一覧を取得 1.  Scan (Table = jobs, Process1 = ‘NotYet’) ワーカーが複数クラスタいるので、複数箇所で同じデータが取得される

77. バッチ処理理のロック管理理 S3 S3 処理理１ Jobs Table JobID (Hash) Created Time(Range) Process1 Process2 aed4c 2014-01-01 00:00:00 Done InProcess aed4c 2014-01-01 00:01:00 NoｔYet NotYet Process1をLockする UpdateItem (Table = jobs, HashKey=aed4c, Action=‘Put’, Attributes=‘Process1:InProce ss’) Process1をLockする片方だけUpdateに成功する (Lockできる) UpdateItem (Table = jobs, HashKey=aed4c, Action=‘Put’, Attributes=‘Process1:InProce ss’)

79. 性能監視はCloudWatchで(1/2)

80. 性能監視はCloudWatchで(2/2) •  CloudWatchで監視できる項⽬目 –  Read Capacity •  消費されているRead Capacity Unit –  Throttled Read Requests •  Capacity Overでエラーを返したReadリクエスト数 –  Write Capacity •  消費されているWrite Capacity Unit –  Throttled Write Requests •  Capacity Overでエラーを返したWriteリクエスト数 –  Get Latency –  Put Latency –  Query Latency –  Scan Latency –  User Errors

81. データのレプリカ •  DynamoDBではRDBのように静⽌止点をとってバックアップするという機能は提供されていないが、下記のいくつかの⽅方法でデータのレプリカを保持することができる 1. AWS Data Pipelineを使ったCross Region Replication •  別のリージョンのDynamoDBのテーブルに対して完全コピーもしくは Incrementalコピー、選択したAttributeのみの完全コピー、選択した AttributeのみのIncrementalコピーのジョブを実⾏行行することが可能 2. Amazon Elastic MapReduceを使ったコピー •  S3や別のDynamoDBに対してAmazon Elastic MapReduceのhiveを使ってデータをコピーすることができる 3. ダブルライトパターン •  アプリケーションからデータを書き込む時点で複数のDynamoDBテーブルに対して書き込む

83. データ操作はマネージメントコンソールで •  テーブルに対してSCANやQUERY、PutItemをマネージメントコンソールから実⾏行行することができる

84. DynamoDB Local •  開発/テスト⽤用のツール –  今までは開発やテストをするために実際のDynamoDBのテーブルを作る必要があった。これには”費⽤用が発⽣生する”、”静的なテスト環境を作れない”、”オフラインで開発できない”などの問題があった。 –  このツールを利利⽤用することにより、開発やCIをより便便利利に⾏行行うことができる •  JARファイルで提供され、ローカルにインストールして動かすことができる(要Java7) •  あくまでAPIの機能的を再現しているテストツールなので本番では利利⽤用しない •  プロビジョンスループットは再現されていないので注意 •  詳細は http://bit.ly/1d9fN5c を参照

85. Transaction Library for DynamoDB •  AWS SDK for Javaのひとつの機能としての実装 –  このSDKを使うことでDynamoDB上でTransactionを利利⽤用できる –  ライブラリ側でTransaction管理理テーブルを作成することにより Transactionを実現している •  使い⽅方は次のページのサンプルコードを参照 •  詳細は http://bit.ly/16KbppP

86. Amazon EMRのHiveから利利⽤用する CREATE EXTERNAL TABLE Audience ( AudienceId Int, ActionTimestamp string, Action string ) STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' TBLPROPERTIES ( "dynamodb.table.name" = ”Audience2", "dynamodb.column.mapping" = ”AudienceId:AudienceId, ActionTimestamp:Timestamp, Aciton:Action“ 　); •  hiveのExternal Tableとして利利⽤用可能 –  DynamoDB上のデータを集計したいときなどに利利⽤用 –  詳細は http://amazn.to/19goT17

87. hiveを使ってS3へデータをバックアップする EMR上のhiveはDynamoDBだけでなくS3も External Tableとして利利⽤用できるのを活かし、 DynamoDBバックのExternal Tableから SelectしたデータをS3バックのExternal Table にInsertする。INSERT OVERWRITE TABLE s3_̲as_̲external_̲table SELECT * FROM dynamodb_̲as_̲external_̲table;

88. •  COPYコマンドでRedshiftにデータをロード –  詳細は http://amazn.to/19goT17 Amazon Redshiftにデータをロードする COPY audience FROM ʻ‘dynamodb://Audience2ʼ’ CREDENTIALS 'aws_̲access_̲key_̲id=<Your-‐‑‒Access-‐‑‒Key-‐‑‒ ID>;aws_̲secret_̲access_̲key=<Your-‐‑‒Secret-‐‑‒Access-‐‑‒Key>' READRATIO 50;

90. Webinar資料料の配置場所 •  AWS クラウドサービス活⽤用資料料集 –  http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/

91. まとめ •  NoSQLはRDBとは全く特性が異異なるので、それらを理理解した上で適所でうまく活⽤用する！ •  運⽤用はゼロではないが、拡張性の⾯面や性能⾯面ではとても楽ができるのがNoSQLの中でのDynamoDBの特徴。

https://twitter.com	57
http://localhost	15
http://www.slideee.com	13
https://cybozulive.com	13
http://s.deeeki.com	9
https://www.chatwork.com	2
https://www.rebelmouse.com	1
https://kcw.kddi.ne.jp	1

SlideShare for iOS

AWS Black Belt Techシリーズ Amazon DynamoDB

by Amazon Web Services Japan

on May 22, 2014

Statistics

Views

Actions

8 Embeds 111

Accessibility

Categories

Upload Details

Usage Rights

Report content

AWS Black Belt Techシリーズ Amazon DynamoDB Presentation Transcript