どうも、ソリューションアーキテクト アソシエート iron千葉です。
AWSって、データベースサービスが沢山あって、混乱しますね。色々比較して、特徴・どういう時に使うか等整理したいと思います。
AWS上のデータベース
まずは、どんな種類があるのか見てみましょう。
赤枠の部分が整理するデータベースとなります。
- Amazon RDS
- Amazon DynamoDB
- Amazon ElastiCache
- Amazon Redshift
沢山ありますね(((( ;°Д°))))
以下より結構内容が詰まってる（長い）ので、１項目１日とかで見てもらえるといいかもです。
0からスタートして、まとめるのに1週間程度かかっているので。
【前提知識】RDBMSとNoSQLとか…色々
AWSの話をする前に、必要な前提知識としてRDBMSとNoSQLとか色々お話をします。
RDBMSとは？
みなさんご存知、リレーショナルデータベースとなります。
つまり、Oracle、MySQLとかPostgreSQLですね。
特徴としては、
- 表形式でデータを保存
- SQLを利用してデータを操作
- トランザクション処理により、複数ユーザの同時に同一のデータを参照・更新しても矛盾が発生しない
- データ一貫性（すべての人に同じデータを返す※RDBMSでは当たり前ですが、NoSQLではデータ一貫性がなく、違いう値を返す場合があります。データ一貫性はRDBMSの特徴ですね）
- スケールアウトが困難（高負荷時、アクセスが集中した場合、構造的にスケールアウトできないのでレイテンシを稼ぐのが難しい）
詳細はwikiに頼ります。
NoSQLとは？
RDBMS以外のデータベースを指す言葉となります。
例をあげると、GoogleのBigTable、MongoDB、Redis、Apache HBase、Apache Cassandra
になります。
特徴としては、
- Key-Valueでデータを保存。プログラミング言語を例にすると、連想配列、ハッシュ、辞書という形でデータを保存する。
- トランザクション処理ができない
- スキーマが存在しない
- 結果整合性を保証（長い時間更新がなかったら全ての更新が反映され、一貫性を保つことを保証。つまり、更新直後は更新前の値が返ったり、更新後の値が返る可能性がある）
- 構造的にスケールアウトができる(高負荷時、アクセスが集中しても、スケールアウトすることにより低レイテンシ。データ量が膨大になっても低レイテンシ)
一番の特徴は、スケールアウトができることですね。これにより、RDBMSに比べて大量のデータを扱うことが出来ます。ビックデータの解析、情報のリアルタイム処理なんかに向いてます。
詳細はwikiに頼ります。
列指向データベース（カラムナデータベース）
RDBMSの中でも、列をひとまとまりにして取り出すときに効率的であるように作られたものです。
通常のDBMSでは、行をひとまとまりとしてファイルシステム上近い場所に格納します。列指向では、列をファイルシステム上近い場所に格納します。
列単位での処理が多い場合に、有効なデータベースとなります。
列指向はインタラクティブなトランザクション処理、行指向はデータウェアハウスに向いている。
詳細はwikiに頼ります。
CAP定理から見るRDBMSとNoSQL
まずは、CAP定理についての説明です。
CAP定理とは？
「分散データベースにおいて次の３つを同時に保証することはできない」
- 一貫性（データ更新直後であっても、全てのノードで同じデータを参照できる）
- 可用性（単一障害点が存在しないこと）
- ネットワーク分断耐性（ネットワーク分断が発生しても継続して利用できる）
RDBMSは一貫性＋可用性、NoSQLは可用性＋ネットワーク分断耐性
詳細はwikiに頼ります。
AWS上のデータベースのカテゴライズ
前提知識を元にカテゴライズするとこうなります。
- Amazon RDS → 行指向型RDBMS
- Amazon DynamoDB → NoSQL（Key-Valueストア）
- Amazon ElastiCache → NoSQL（Key-Valueストア＋インメモリ）
- Amazon Redshift → 列指向型RDBMS
これでなんとなくイメージ出来てきたのではないかと思います。
AWSのデータベースサービスを詳しく見てみる
カテゴライズもでき、明確に違うことがわかったので、特徴や使い所などをまとめてみます。
Amazon RDS
リレーショナルデータベースが必要の場合で、管理作業を楽にしたい場合に利用できます。
Oracle、SQL ServerのライセンスはBYOLを利用可能です。（ライセンス購入しなくても、時間課金に含まれる）構築も、Web画面から行え、データセンターレベルでの冗長化構成も簡単に構築できます。
特徴としては
- OSレベル以下の作業（OSパッチ適用やハード障害など）はAmazonにおまかせ
- データセンターレベルのマスター・スレーブ構成（同期レプリケーション）可能
- MySQLに限っては、リージョン間（国レベル）でのリードレプリカ構成（リード専用の非同期レプリケーション）可能
- MySQL、PostgreSQL、Oracle、MS SQL Serverから選択可能
- バックアップもスケージュールで１日１回取得できる（手動でも可能）※ただし、バックアップ中はI/O停止になるので、止めたくない場合はマルチAZを利用する必要あり
- セキュリティグループ（ファイアウォール機能）によりアクセス制御も柔軟に対応できる
Amazon DynamoDB
Key-Valueストアです。膨大なデータであっても、レイテンシを低く抑えることができますが、複雑なクエリやトランザクション処理には向きません。
高いスループット、膨大なデータ量を裁く必要がある場合に利用します。
特徴としては
- OSレイヤはAmazon側で管理。データをどう利用するかに専念できる。
- スキーマが存在しない
- 結果整合性の採用により可用性の向上（逆にいうと一貫性を捨てた）※設定によっては、結果整合性も担保できる
- ストレージに容量制限がない（無限に使える、ディスク追加したりとかしなくてよい）
- データは3箇所のデータセンターに保存
- リザーブドインスタンスが使える
ElastiCache
マネージドなメモリキャッシュです。OS以下のメンテナンスはAmazonで行います。ミドルインストール不要で利用できます。利用できるプロダクトは、
- memcached
- redis
となります。ElastiCacheを利用することにより、バックエンドのDB（Oracleとか、MySQLとか）のリードの負荷を減らすことが可能です。
そもそも、メモリキャッシュって？
そもそも、メモリキャッシュって？メモリ上にデータを格納して高速に取得できるようにします。
それでは、メモリキャッシュがなぜ必要なのか。
すべてのデータをDBで処理してもいいのですが（負荷に耐えられる程度であれば）、アクセス数が多くDB負荷を減らしたい場合、スケールアップやリードレプリカを構築するという手があります。しかし、もっとコストをかけずに高速化できる方法がメモリキャッシュとなります。ただし、メモリ上にデータを格納しているため、ノード障害時にはデータが飛びます。アクセス速度とデータ永続化とのトレードオフということになりますね。揮発性の高いデータを格納するのに向いています。
メモリキャッシュの利用用途としては、
- 負荷の高いDBクエリの結果を一時的に保存（DB負荷低減、クエリの高速化）
- セッションデータを格納して、ステートレスなアプリに
- アプリでの複雑な計算結果を保管（データ再利用）
これらは、アプリ側でDBとキャッシュを分けるように実装する必要があります。
（DBとデータ整合性をあわせ利用に、DBとキャッシュに同時書き込みする等）
以下より、それぞれの特徴について触れます。
memcached
インメモリのKey-Valueストアです。
めちゃめちゃシンプルです。
- レプリケーション機能なし（基本的にアプリ側でクラスタ全ノードに書き込みするなどで冗長化する）
- データの削除は、明示的、期限、LRU
- クラスターという単位で構成。アクセスは、クラスタレベル、ノードレベルで指定できる（対応ライブラリにて）
- バックアップ機能はない（snapshotの取得できない）
- データ永続化できない
- マルチAZ構成対応
- クラスタリングとしてtwemproxyの利用を検討
redis
こちらも、Key-Valueストアです。
memcachedに比べて、高機能です。
- 高機能なデータ構造を持つ（List、Set、Stored、Set、Hash）複雑なデータを扱うのであれば、redisを選択ですかね
- データの永続化ができる
- Snapshotによる永続化（Redisの機能、BGSAVEを内部的に実行）バックアップ、リストアが可能。性能懸念がある場合は、リードレプリカから取得する。日時で取得可能。
- Append only Fileによる永続化（書き込みコマンドをファイルに記録）。ノード障害時はファイルごと消える。。
- リードレプリカ対応（ただし、非同期レプリケーション）
- マルチAZ構成対応（リードレプリカをマスターノードに自動フェイルオーバー。エンドポイントは変わらない）
- クラスタリングとしてtwemproxyの利用を検討
- redis自体はシングルスレッド（複数クエリを同時に実行できない）ため、時間がかかるクエリは避ける必要がある
Redshift
ペタバイト規模の高速データウェアハウスです。PostgreSQLベースの列指向データベースとなります。同時にクエリできる数に制限がありますが、大量なデータに対する高速なクエリが可能です。主にBIツール等の分析用データベースとして利用します。
特徴としては
- MPP(超並列演算)により、データ容量に関係なく低レイテンシ
- 列指向データベースのため分析が得意
- OSレイヤはAmazon側で管理。データをどう利用するかに専念できる。
- SQL文が利用できる
- データロードは、S3、DynamoDB、EMR、Data Pipelineからロードできる（Cross-Reagion機能で別リージョンのデータもCOPYとも連携可能）
- EMRとデータを連携可用能
- 日時で自動スナップショットの取得ができる（別リージョンへのコピーも自動でできる）
- シングル AZ 配置のみサポート（AZが停止した場合は、AZが復旧次第利用可能。データは保持されている）
- データ容量は最大2PBまで拡張できる（16TB✕128ノード）
- リザーブドインスタンスも利用可能
- rebootで設定変更が反映される
- shutdownでクラスターが削除される（再度利用する場合はスナップショット必須）
★Next Step★
「AWS 活用資料集 Redshit by Amazon」で概要を把握。
「気軽に始めてみよう！クラウド時代のデータウェアハウス超入門 by classmethod」で実際に触ってみると理解が深まります。
まとめ
- DynamoDB → 大量のオンライントランザクションがある場合はわしにまかせるのじゃ
- Redshift → 大容量データの分析は、だまってオレに任せとけ
- RDS → 低レイヤ（OS以下）の管理不要、高可用性な、既存データベースを簡単使う場合
- ElastiCache → DBの負荷低減用のメモリキャッシュなら私を使ってね
- Amazon RDS → 行指向型RDBMS
- Amazon DynamoDB → NoSQL（Key-Valueストア）
- Amazon ElastiCache → NoSQL（Key-Valueストア＋インメモリ）
- Amazon Redshift → 列指向型RDBMS