AWS re:Invent2013参加レポート #13 AWS Storage and Database Architecture Best Practices

AWS re:Invent 2013

#Amazon RDS

#Amazon CloudSearch

#Amazon DynamoDB

#イベントレポート

#AWS Data Pipeline

横田慎介

2013.11.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSのエンタープライズソリューションアーキテクトである、Siva Raghupathyさんによる「AWS Storage and Database Architecture Best Practices」に参加してきました。

各ストレージ、データベースの向き不向きとベストプラクティスを網羅的に紹介する内容でした。
AWSはデータベースだけでも沢山のサービスがあるので、どのサービスを利用するのが一番いいのか迷うことがよくあります。
以下は発表内容の直訳ですが、それぞれのサービスの特性を押さえておくことで、より確かな選定をするための一助になればと思います。

英語が分からなくて、訳せていない部分があります。
自信が無いところは元の英語を併記しています。
CloudSearchなどの使ったことが無いサービスはほとんど訳せていません。すみません...
理解が進んだら訳していきます。

RDS

向く場面

トランザクション処理が多いもの
複雑なクエリが必要なもの
中から高程度の読み込み/書き込み

3万IOPS(15000読み込み/秒 + 15000書き込み/秒)くらいまで

データ容量は数百GBから数TBまで
1ノードで処理できるくらいの負荷
高い耐久性が必要

向かない場面

大量の読み込み/書き込み

15万書き込み/秒とか

シャーディングが必要なくらいのデータサイズやスループットが求められる場合

数十から数百TBのデータサイズ

クエリがシンプルなPUT/GETばかりでNoSQLで対応できる場合
複雑な分析

ベストプラクティス

適切なインスタンスクラスを選択する
EBS-optimizedインスタンスを利用する

db.m1.large, db.m1.xlarge, db.m2.2xlarge, db.m2.4xlarge, db.cr1.8xlarge

Provisioned IOPSを利用する
冗長化のためMulti-AZを利用する
Read Replicaを利用する

読み込みスケールのため
スキーマ変更のため
障害に備えて

DynamoDB

向く場面

高速かつ予測可能なパフォーマンスが必要
シームレスで巨大な規模が必要
自動シャーディング
安定した短いレイテンシ
容量やスループットの上限が決まってない
非常に高い耐久性が求められる
Key-Value型、もしくは単純なクエリで十分

向かない場面

複数アイテムもしくは複数テーブルにまたがったトランザクションが必要
複雑なクエリやJOINが必要
時系列データのリアルタイム分析が必要
アクセスの少ないデータの保存

ベストプラクティス

アイテムのサイズは小さく
メタデータはDynamoDBに、でかい本体データはS3に
Use a table with a hash key for extremely high scale
時系列データを保存する場合は、月、週、日等ごとにテーブルを作る
Use hash-range key to model

1 N relationships
Multi-tenancy

特定のハッシュキーにアクセスが集中しないようにする

ElastiCache(Memcached)

向く場面

Key-Value型データの一時的な保存
高速な読み込み/書き込みが必要
発行頻度の高いSQLやNoSQLの結果を保存
一時的で更新頻度の高いデータを保存

増減の激しいゲームのスコア
ウェブアプリケーションのセッション

データの重複を許容できる

向かない場面

あまり利用されないデータの保存
永続性が必要

ベストプラクティス

Auto Discoveryを利用する
Share Memcached client objects in application
TTLを利用する
コネクションによるメモリのオーバーヘッドを考慮する
CloudWatchのアラームとSNSのアラートを利用する

コネクション数
Swap利用量
空きメモリ量

ElastiCache(Redis)

向く場面

より複雑なKey-Value型データが必要

文字列型、リスト型、セット型、ソート済みセット型、ハッシュ型

キャッシュ用途
リーダーボード
高速並び替え
アトミックカウンター
キューイングシステム
アクティビティストリーム

向かない場面

シャーディングやスケールアウトが必要
「強い」永続性が必要
データがメモリに乗り切らない場合
例外発生時にもトランザクションロールバックが必要

ベストプラクティス

TTLを利用する
適切なインスタンスタイプを選ぶ

高CPUかつネットワークパフォーマンスがいいインスタンスほど高いスループットを出せる(m2.4xlarge, m2.2xlarge)

Read Replicaを利用する

読み込みスループット向上のため
AOFだけでは防げない障害があるから
Read Replicaをプライマリに昇格できるから

オンプレミスからの移行時はRDBスナップショットファイルを利用する
主要な設定

パラメータ設定の「appendfsync」は「always」にしない。パフォーマンスの悪化がきわめて激しいので。
「appendfsync」は「everysec」にする。耐久性とパフォーマンスのバランスが一番良い
Publish/Subscribe構成のときは「client-output-buffer-limit-pub-sub-hard-limit」と「client-output-buffer-limit-pub-sub-soft-limit」をセットする

CloudSearch

向く場面

検索に関する専門知識が無い(No search expertise)
全文検索(Full-text search)
ランキング(Ranking)
Relevance
データは構造化されている場合も構造化されていない場合もどちらでもOK(Structured and un-structured data)
ファセット(Faceting)

例えば、0~10ドルは4件ヒット、10ドル以上は３件ヒットみたいな検索結果が欲しい場合

向かない場面

データベースの代わりにはならない(Not as replacement for a database)

Not as a system of record
Transient data
Non-atmic updates

ベストプラクティス

Batch documents for updating
CloudSerchは検索用に利用し、結果表示用には他のデータストアを利用する。つまり、かえってきた値は表示には利用しない。(Use CloudSearch for searching and another store for retrieving full records for the UI. i.e. don't use return fields)
documentに人気度といった他のデータを含める(Include other data like popularity scores in documents)
検索対象にしたくないような一般的な単語を取り除くため「stopwords」を設定する。(Use stop words to remove common items.)
Use fielded queries to reduce match sets.
Query latency is proportional to query specificity.

Redshift

向く場面

分析、レポーティング
Complex DW queries that summarize historical data.
Batched large updates e.g. daily sales totals.
同時に発行されるクエリ数が数十個
データ量が数百GBからペタバイト
Compression
Column based
非常に高い耐久性が求められる

向かない場面

オンライントランザクション処理が多い

同時ユーザ数が数千
一意な列の更新を大量に行う(Large number of singleton updates)

ベストプラクティス

大量のデータを更新するときはコピーコマンド(COPY from S3/DynamoDB)を利用する。

データを複数のファイルに分割すること
GZIP圧縮やLZOP圧縮を利用すること
マニフェストファイルを利用すること

ソートキーには適切なものを選択する。

WHERE句で指定するもの。範囲指定も可。(Renge or equality on WHERE clause)

分散キーには適切なものを選択する。

JOIN用のカラム、外部キー、largest dimension、GROUP BYカラム
正規化されていないカラムは避ける

※Redshiftのテーブル設計についてはこちらのエントリも参考になるかと。
Amazon Redshift DB開発者ガイド – テーブル設計のベストプラクティス

Elastic MapReduce

向く場面

バッチ処理、分析

応答に数分から数時間かかっても良い場合

データは構造化されている場合も構造化されていない場合もどちらでもOK(Structured and un-structured data)
全データに対する並行したスキャンを安定した性能で行いたいとき
Hive QLや他の言語を利用したいとき
ギガバイトからペタバイトまでのデータ量
Replicated data store(HDFS) for ad-hoc and real-time queries(HBase).

向かない場面

リアルタイム分析

数秒での応答が必要な場合

同時ユーザ数が数千

ベストプラクティス

運用も含む全コストを考慮して、一時クラスタを使うか、永続クラスタを使うか選択する。

耐久性の高いS3と、内部ストレージをうまく組み合わせる
クラスタ内のインスタンスは各ジョブに適切なものを選ぶ。あらゆるジョブに適しているインスタンスサイズは無い。
コストを効率化するために、インスタンスサイズの調整やスポットインスタンスの数の調整を行う(Leverage resizing and spot to add and remove capacity cost-effectively.)

Hadoopのコードをチューニングするよりはクラスタのインスタンスをチューニングする方が楽。

S3

向く場面

巨大なオブジェクトの保存
Key-Valueストアとして。(GET/PUT/LISTが使える)
無制限のストレージとして。
オブジェクトのバージョニングがしたいとき。
非常に高い耐久性が欲しいとき。

99.999999999%

非常に高いスループットが欲しい場合。ただし、クライアントが並列でないと性能が落ちる。
永続的なデータ保存。

バックアップ
EMRのソース/結果
メタデータをSQL/NoSQLデータベースに入れて、本体を保存

向かない場面

複雑な問い合わせが使いたい場合
ミリ秒レベルの非常に低いレイテンシが求められる場合
検索
書き込み(更新)後の読み込み一貫性が必要な場合
トランザクションが必要な場合

ベストプラクティス

キーのプレフィックスにランダムなハッシュ値をつける
アクセスパターンがランダムになるようにする
GETやPUTに高いスループットが必要な場合は、CloudFrontを利用する
高い耐久性とスループットというS3の特徴を活かし、バックアップや一般的なデータ保存場所として利用する(Leverage the high durability, high throughput design of S3 for backup and as a common storage sink)