nosql on awsの勘所...nosqlで実現したいこと • nosqlをつかう事は目的ではない...

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Akihiro Kuwano

Solutions Architect, Amazon Web Services Japan

3-H1-2-15

RDBMSだけで本当にいいの？

NoSQL on AWSの勘所


自己紹介


自己紹介

桑野章弘(くわのあきひろ)ソリューションアーキテクト

主にメディア系のお客様を担当しております。

元渋谷のインフラエンジニア

好きなAWSのサービス：ElastiCache,

Route53

好きなデータストア：MongoDB


アジェンダ

• 本セッションの目的

• よくある話

• NoSQLとは

• AWSのNoSQLサービス

• NoSQLのユースケース

• NoSQLのデザインパターンの考え方


本セッションの目的


本日持って帰って頂くこと

NoSQLの活用方法を知り、

より良いシステムを目指す！


よくある話


よくある話

• 「特にRDBMSで困ってないし使う必要ないのでは」


よくある話


• 「使ってみたけど運用大変だし、逆に性能悪くなったよ」


よくある話


• 「使ってみたけど運用大変だし、逆に性能悪くなったよ」

• 「そもそもNoSQLってどういう時に使うの？」


よくある話

• その疑問を解決していきましょう！


NoSQLとは


なぜ NoSQL を選択する?

ストレージに最適化計算リソースに最適化

正規化/リレーショナル非正規化/階層構造

SQLを使用可能各データベースによって異なる

クエリ方法

トランザクション処理トランザクション処理は限定的

データの堅牢性／一貫性データの堅牢性／一貫性はデータベースによる

スケールアウトの煩雑さ高いスケーラビリティ

テーブルの運用負荷クラスタの運用負荷

RDBMS NoSQL


NoSQLの種類

キーバリューストアカラム指向データベース

ドキュメント指向データベース

グラフ指向データベース

キーとバリュー（値）の単純な構造超高速なパフォーマンス

カラム指向のデータ構造ログなど大量のデータ解析向き

JSONやXML等のデータ構造に対応

複雑なデータモデリングを容易に実現可能

データ間を相互に結びつけデータ同士の関係で表す複雑な関係性を表すのが得意


NoSQLの種類

キーバリューストアカラム指向データベース

ドキュメント指向データベース

グラフ指向データベース

Key1 Value1

Key2 Value2

Key3 Value3

RowKey

2

Key1

Value3

RowKey3Key1

Value4

Key2

Value5

Key3

Value6

Key1 Object1

Key2 Object2

Key3 Object3

{

”id": "kuwanoa”,

“age”: 40,

}

A

B

C

D E


NoSQLで実現したいこと

• NoSQLをつかう事は目的ではない

• 実現したいことがあるからNoSQLを使う• どこまでスケールしても運用が変わらない基盤

• 低レイテンシ・高スループット

• スケールするWebセッション管理

• Publish・Subscribeモデル

• イベント処理

• JSONなどの複雑なデータの格納

• ペタバイトクラスのビックデータ処理

• ソーシャル・グラフ、BOM（Bill of material）ツリーの検索


こちらもぜひ！

• 去年のAWS SummitではNoSQLの基礎知識についてのセッションを行っておりますのでそちらも見ていただくと更に理解が深まります


AWSのNoSQLサービス


AWS が提供するデータベースサービス

Amazon RDSAmazon DynamoDB

Amazon ElastiCache Amazon Redshift

リレーショナルデータベースAurora, PostgreSQL, MySQL,

MariaDB, Oracle, SQL Server

高速でシームレスな拡張性と信頼性を持つNoSQL データベース

インメモリキャッシュMemcached, Redis

ペタバイト規模のデータウェアハウス

Amazon Neptune

(5/31 GA!!!)

高いパフォーマンス、シームレスな拡張性、信頼性を持つグラフDBサービス


AWS が提供するNoSQLデータベースサービス

Amazon DynamoDBAmazon ElastiCache高速でシームレスな拡張性と信頼性を持つ

NoSQL データベースインメモリキャッシュ

Memcached, Redis

Amazon Neptune

(5/31 GA!!!)

高いパフォーマンス、シームレスな拡張性、信頼性を持つグラフDBサービス


Amazon ElastiCache


Amazon ElastiCacheの特徴

インメモリキーバリューストア

フルマネージド

ハイパフォーマンス

高いスケーラビリティ

Redisと memcachedが利用可能

Amazonによる拡張(Amazon Redis)


Amazon ElastiCacheとは

• フルマネージド• キャッシュクラスタを数クリックで起動

• 可用性を向上させる機能（モニタリング、自動障害検出、復旧、拡張、パッチ適用、バックアップ）

• パフォーマンス• 超高速な2種類のエンジン(memcached, redis)をサポート

• AmazonによるRedisの機能拡張

• 高可用性と堅牢性• セキュリティグループ、VPC対応、暗号化


Amazon ElastiCacheの機能追加

• Redis Cluster Online Cluster Resizing

• セキュリティ機能の強化• Encryption-In-Transit: クライアントとRedis間の通信暗号化

• Encryption-At-Rest: S3とディスク上のデータを暗号化

• Redis AUTH : Redis標準のAUTHコマンド対応

• HIPAA 認証取得


Redis Cluster

• Redis 3.2 で Redis Cluster のサポート

• データをシャード単位に分散保存することで最大15シャード、6TiBのデータが保存可能

• 最大2000万/秒の読み込み、450万/秒の書き込み性能

Shard A

Shard B

Shard CApp

各シャードに分散してデータを保存


Redis Cluster Online Cluster Resizing

• Redis Cluster のシャード数をダウンタイム0で動的に増減変更することが可能になった

• SNSやLambdaと連携することでAutoScaleも可能

3 Shards 5 Shards

AWS LambdaAmazon

CloudWatch AWS SNSシャード数増減のAPIコール

メモリ枯渇


• Redis Cluster のシャード数をダウンタイム0で動的に増減変更することが可能になった

• SNSやLambdaと連携することでAutoScaleも可能

Redis Cluster Online Cluster Resizing

5 Shards 3 Shards

AWS LambdaAmazon

CloudWatch AWS SNSシャード数増減のAPIコール

メモリOK


Amazon DynamoDB


Amazon DynamoDBの特徴


高速、かつ一貫したパフォーマンス


柔軟性

イベント指向のプラグラミングも可

高いセキュリティ


DynamoDBの特長

• 管理不要で信頼性が高い

• プロビジョンドスループット

• ストレージの容量制限がない


特長１：管理不要で信頼性が高い

• SPOFの存在しない構成

• データは3箇所のAZに保存されるので信頼性が高い

• ストレージは必要に応じて自動的にパーティショニングされる

クライアント


プロビジョンドスループット

• テーブルごとにReadとWriteそれぞれに対し、必要なスループットキャパシティを割り当てる（＝プロビジョンする）事が可能

• ReadCapacityUnit（RCU）とWriteCapacityUnit（WCU）が存在し、多くリソースを割り当てればその分料金がかかる

• 運用中にオンラインで変更可能


プロビジョンドスループットの例

読み込み減、書き込み増によりキャパシティが適切ではなくなった

書込読込

現在のアクセス量

プロビジョンした設定

キャパシティユニット変更

書込読込書込読込


特長３：ストレージの容量制限がない

• 使った分だけの従量課金制のストレージ

• データ容量の増加に応じたディスクやノードの増設作業は一切不要


Amazon DynamoDB の機能追加

• バックアップ／リストア（オンデマンド、PITR）

• Global Tables

• Auto Scaling

• DAX

• TTL

• セキュリティ対応• Encryption-In-Transit: クライアントとDynamoDB間の通信暗号化（従来から対応）

• Encryption-At-Rest: ディスク上のデータ暗号化

• VPC-Endpoint


バックアップ／リストア

• バックアップ／リストアにネイティブ対応

• たとえ数百TBのデータベースでもパフォーマンス影響なしにバックアップが可能

• PITRや継続的バックアップ（最大35日前までの好きな所に復元）も可能

BackUp

Restore


DynamoDB Global Tables

• 複数リージョンでデータを共有したテーブルを作成可能に

• グローバルアプリケーションや、DRに

• 全てのローカルにあるリージョンのテーブルに読み書きしたものが非同期にレプリケーション• レイテンシが低く済む

• 書き込みは後勝ち

Globally dispersed users

Replica (N. America)

Replica (Europe)

Replica (Asia)

Global App

Global Tables


Auto Scaling

• キャパシティ設定（WCU、RCUなど）を動的に管理

• ターゲット使用率と上限、下限を設定すると自動で必要なリソースに設定してくれる

Auto Scaling 有効Auto Scaling無し


DynamoDB Acceralator（DAX）

• DynamoDBの前面にマネージドかつDynamoDB API 互換のキャッシュクラスタを置くことが出来るサービス

• 読み込みの低レイテンシ（ms->μs）を実現• パフォーマンス向上

• コスト最適化

DAXAPP DynamoDBAPP DynamoDB


TTL（Time To Live）

• テーブルの Item の有効期限を設定可能、データベースから非同期で削除する

• DynamoDBのサービス側で削除を行うため、プロビジョニングスループットは使用せず、古いデータのストレージ使用量と保存コストを削減可

非同期 Job

PutItem Check & Delete

SessionData

ExpirationTime(TTL)

1461938400

1461927600

UserName SessionId CreationTime

user1 aaaaa 1461931200

user2 bbbb 1461920400


Amazon Neptune

2018年5月31日GA!!!


Amazon Neptune の特徴

グラフデータベース


ハイパフォーマンス


SPARQL と Gremlin でクエリ可能

Apache TinkerPopとW3C RDF が利用可能


Amazon Neptune とは

• 高速• 億レベルのリレーションシップをミリ秒のレイテンシで問合せ可

• 高信頼性• 3つのAZに跨がる6つのレプリカをフルバックアップ/リストアと共に提供

• 簡単• GremlinとSPARQLによる簡単でパワフルなクエリを実行

• オープン• Apache TinkerPop & W3C RDF グラフモデルをサポート


グラフデータベースの得意な領域

• 高度に連結されたデータ

不正取引の検出レストランのレコメンデーションソーシャルネットワーク


例：つながりと推薦

購入購入

購入

フォローフォロー

友達

友達スポーツをフォローしている人

が買っている物

友達かも？

フォロー


NoSQLのユースケース


ユースケース例

• キャッシング

• IoTソリューション

• Pub/Subアプリケーション

• 非同期アプリケーション

• グローバルアプリケーション

• 時系列データが必要なアプリケーション


キャッシング

クライアント

Amazon

ElastiCache

Redis

Amazon

DynamoDB

Elastic Load

Balancing

Amazon

EC2

Amazon

RDS

write-through

reads/

writes

DDB streams

mysql.lambda_async

reads/

writes

Amazon

S3

reads/writes

オブジェクトストレージ

非定型データ

リレーショナルデータ


キャッシング

クライアント

Amazon

ElastiCache

Redis

Amazon

DynamoDB

Elastic Load

Balancing

Amazon

EC2

Amazon

RDS

write-through

reads/

writes

DDB streams

mysql.lambda_async

reads/

writes

Amazon

S3

reads/writes

オブジェクトストレージ

非定型データ

リレーショナルデータ

各DBからLambdaを使

い非同期にキャッシュを生成し、各データベースに対するアクセ

スを軽減


キャッシング

• DAXを活用する



キャッシング

• DAXを活用する


DynamoDBへのアク

セスを減らす事で低レイテンシとコスト最適化を実現


Rules Engine

Amazon

ElastiCache

Redis

AWS

Lambda

標準対応

LambdaSNS SQS

S3 KinesisDynamoDB

AWS

IoT devices

AWS

IoT

センサストア

IoTソリューション

MQTT


Rules Engine

Amazon

ElastiCache

Redis

AWS

Lambda

標準対応

LambdaSNS SQS

S3 KinesisDynamoDB

AWS

IoT devices

AWS

IoT

センサストア


MQTT

IoTデバイスが貯める大量のデータをRedis

Clusterや、DynamoDB

へと保存する


Rules Engine

Amazon

ElastiCache

Redis

AWS

Lambda

標準対応

LambdaSNS SQS

S3 KinesisDynamoDB

AWS

IoT devices

AWS

IoT

センサストア


MQTT

IoTデバイスが貯める大量のデータをRedis

Clusterや、DynamoDB

へと保存する

低レイテンシが必要なものに関してはRedis

Cluster

大量のデータを保存したい場合にはDynamoDB


Pub/Subアプリケーション

https://aws.amazon.com/blogs/database/amazon-elasticache-utilizing-redis-geospatial-capabilities/

Clients

Chat appsApplication

Load Balancer

WebSockets

Amazon

ElastiCache

Redis

PubSub

Serverpersistent

connections

Elastic

Beanstalk

SUBSCRIBE chat_channel:114

PUBLISH chat_channel:114 "Hello all"

>> ["message", "chat_channel:114", "Hello all"]

UNSUBSCRIBE chat_channel:114



Pub/Subアプリケーション


Clients

Chat appsApplication

Load Balancer

WebSockets

Amazon

ElastiCache

Redis

PubSub

Serverpersistent

connections

Elastic

Beanstalk

SUBSCRIBE chat_channel:114

PUBLISH chat_channel:114 "Hello all"

>> ["message", "chat_channel:114", "Hello all"]

UNSUBSCRIBE chat_channel:114

チャットメッセージのSUBSCRIBEとPUBLISHの実行



• 順位表みたいなものはゲームに限らず非常によく使われるものだが、特にゲームはリアルタイム性の高い使い方をする

• ElastiCacheの Redis sorted sets

を活用することで簡単に実現可能

ZADD "leaderboard" 1201 ”Takayama”

ZADD "leaderboard" 963 " Kuwano"

ZADD "leaderboard" 1092 ”Nishitani "

ZADD "leaderboard" 1383 ”Uehara”

ZREVRANGE "leaderboard" 0 -1

1) ”Kuwano"

2) ”Nishitani"

3) ”Takayama"

4) ”Uehara”

ZREVRANK "leaderboard" ”Takayama"

(integer) 3

リアルタイムリーダーボード


グローバルアプリケーション

Global Tables を活用

して世界中で同じテーブルにアクセス

をかける

各リージョンで独自に持てば良いものは通常のテーブルで


非同期処理トリガー• DynamoDB Streamsを使いデータベースの変更内容を他サービスへ連携

Lambda function Notify change

Item/table level metrics

Amazon CloudSearch

Kinesis FirehoseApps


非同期処理トリガー• DynamoDB Streamsを使いデータベースの変更内容を他サービスへ連携

Lambda function Notify change

Item/table level metrics

Amazon CloudSearch

Kinesis Firehose

DynamoDB Streams

から受け取ったデータをLambda で他サービスへ

処理を行う

Apps


時系列データが必要なアプリケーション

• ホットデータとコールドデータでテーブルを分ける

• DynamoDB StreamsとGSIを活用し、非同期でホットデータをコールドデータへと移動する

• ホットデータではWCU、RCUを高く設定、コールドデータでは書き込み、読み込みは最低限必要な分のみに限定する• コスト最適化


時系列データが必要なアプリケーションActive Tickets_Table

Event_id

(Partition)

Timestamp GSIKey

Rand(0-N)

… Attribute N

Expired Tickets GSI

GSIKey

(Partition)

Timestamp

(Sort)

Archive Table

Event_id

(Partition)

Timestamp

(Sort)

Attribute1 …. Attribute N

RCUs = 10000

WCUs = 10000

RCUs = 100

WCUs = 1

Current table

コールドデータ

期限切れのデータをTTLを使用してアーカイブ

AWS LambdaDynamoDB Streams

ホットデータ


NoSQLのデザインパターンの考え方


NoSQLのデータモデリング

• RDBMSでのデータモデリング手法をNoSQLに当てはめてもそれが必ずしも最適ではない場合がある• 例えば非正規化

• 各NoSQLを最大限活用するためのデータモデリングが必要になってくる

• データの連携等にこだわらずに実現したいこと（＝目的）にこだわる


Amazon DynamoDB のデータモデリング例

• ある社員管理用のデータベースを作る場合

• RDBMSとDynamoDBでの考え方の違い


DynamoDBのテーブル構造

テーブル

項目(items)

属性(attributes)

パーティションキー(必須)

ソートキー（オプション）

スキーマなし

パーティションキー + ソートキー(オプション) = プライマリキー


Global Secondary Index (GSI)

• Partition Key属性の代わりとなる

• Partition Keyをまたいで検索を行うためのインデックス

A1(PK)

A2 A3 A4 A5

GSIsA5

(PK)A4

(Sort)A1

(table key)A3

(projected)

Table

INCLUDE A3

A4(PK)

A5(Sort)

A1(table key)

A2(projected)

A3(projected) ALL

A2(PK)

A1(table key)

KEYS_ONLY


RDBMSの場合

勤務地

大阪Rows

Primary Key Index

東京

北海道

社員ID 名前

1

2

3

桑野

塚田

西谷

職種

SA

SA

SA

Columns


RDBMSの場合

勤務地

大阪

Columns

Rows

Primary Key Index

東京

北海道

社員ID 名前

1

2

3

桑野

塚田

西谷

職種

SA

SA

SA

もし勤務地、職種などで検索したければその時必要なIndexを作成する


DynamoDBの場合

Data

東京

AttributePartition Key Sort Key

桑野

SA

社員ID ColA

1

1

1

名前

勤務地

職種


DynamoDBの場合

Data

東京

Partition Key Sort Key

桑野

SA

社員ID ColA

1

1

1

名前

勤務地

職種

Data

東京

桑野

SA

ColA

名前

勤務地

職種

Partition KeySort Key

社員ID

1

1

1

Attribute

GSI


DynamoDBの場合

Data

東京

Partition Key Sort Key

桑野

SA

社員ID ColA

1

1

1

名前

勤務地

職種

Data

東京

桑野

SA

ColA

名前

勤務地

職種

Partition KeySort Key

GSIを作成しColAの値と、Dataの組で検索することで一つのGSIで複数の条件を検索できる

社員ID

1

1

1

Attribute

GSI


ユーザ事例


事例：株式会社はてな様 mackerel

https://d1.awsstatic.com/events/jp/2017/summit/slide/D3T6-6.pdf

• サーバ管理ツールの mackerel のバックエンドではNoSQL

がフル活用されている

• 時系列のデータを保存するために3層の階層構造を作りアーキテクチャを最適化• Redis、DynamoDB、S3を用途によって組み合わせ



事例：株式会社はてな様 mackerel

write

datapoints

Kinesis Streams

Lambda

read

datapoints

ElastiCache

DynamoDB

Lambda

TTL expired

flush

write

Web App

(Golang)

S3

read

read

read




事例： Oracle からDynamoDBの移行

• amazon.comのワークフロー管理ソフトウェア Herd をOracleベースからDynamoDB ベースへと置き換えた

• 得られたもの• ワークフロー処理の遅延が1秒

→100ミリ秒

• スケーリングとメンテナンスの労力が10分の1に減少

• 300以上のOracleホスト停止

Work Item

Storage

Partition

Assigner

Timer

Router

Timer

NodesTimer

NodesTimer

NodesTimer

Nodes

Timer

Host

s

View Router

Timer

NodesTimer

NodesTimer

NodesTimer

NodesView

Hosts


Prime Day 2017:

Amazonの歴史で一番大きなイベントで数千のAmazonチームがDynamoDBを使用


Prime Day 2017:

Amazonの歴史で一番大きなイベントで数千のAmazonチームがDynamoDBを使用

ピーク帯で DynamoDB が 1290万 RPS を記録


まとめ


まとめ

• NoSQLを使用する場合は明確な実現をしたいゴールが必要

• RDBMSと同じ方法論でNoSQLを扱おうとすると失敗する• RDBMS的なモデリングが最適解ではない

• 各データストアのアーキテクチャを理解する事が大事• 良いところを引き出す

• NoSQLを適切に使うことでRDBMSでは到達できない事を実現できる


本日持って帰って頂くこと

NoSQLの活用方法を知り、

より良いシステムを目指す！


行人坂.tech

次回、行人坂.tech #1 Amazon Athena 編を、7/20（金）に開催します

ビジネスを伸ばすための、AWSをはじめとしたサービスを体験していく、エンジニアのための定期勉強会です。

ビジネスの成長に寄与するためには、AWSのマネージドサービスをうまく活用して、実現したいことを最小の労力で達成することが大事になってきます。

マネージドサービスを活用するための代表的な構成を紹介したり、簡単なハンズオンを通して、実際に触ってみて体験していきます。

https://gyoninzaka-tech.connpass.com/event/89923/

https://gyoninzaka-tech.connpass.com/event/89923/


お手元のサミットガイドブックの表紙に記載している『QRコード』からご回答ください。もれなく素敵なAWSオリジナルグッズをプレゼントします。

本セッションのFeedbackをお願いします

プレゼントの引き換えは、パミール3F展示会場内アンケート確認エリア・受付エリアのいずれかにお越しください。


ありがとうございました

nosql on awsの勘所...nosqlで実現したいこと • nosqlをつかう事は目的ではない...

Documents