この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Summit Osaka 2019 のセッション、「AWS におけるデータベースの選択肢とその選定方針」をレポートします。
セッション概要
データベースは、企業のシステムにおいて重要なコンポーネントの1つです。AWS ではデータベースを利用するにあたり、自分たちでEC2上にデータベースをインストールして利用する、あるいはAWSが提供するマネージドサービスを利用するなどの方法があります。加えて、マネージドサービスを利用するにあたっても、多くの選択肢があります。このセッションではそれらの技術特性をもとにその選択肢の中から最適なものを選ぶ指針をご紹介します。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
江川 大地さん
セッションレポート
目的
- AWSのDBサービスの特徴を理解し適切なデータベースを選択できるようにする
対象者
- AWSをこれから利用する方/データベースの選定を行う方
データベース
- 単なるデータを置くストレージではない
- データを操作するソフトウェアという一面も
- DBの歴史
- 1970〜80年代
- 商用DB RDB
- 1990年代
- もう少し手軽に・OSS
- 2000年代後半
- 要件が多様化するにつれ様々なNoSQLも台頭
- 近年要件が変わってきている、厳しくなってくる
- ユーザー数の桁が一つ増える
- データの単位も変わる（増える）
万能のDBは存在しない
- by werner vogels CTO amazon.com
従来のエンプラDBシステム
- アプリ
- オンライントランザクション OLTP DB
- ETLツール
- 分析 OLAP DB
- BIツール
- → 用途によりDBを分けて利用している
データベースの選択
- AWS では多様なデータベースの選択肢がある
- ワークロードに応じて最適な選択が可能
- 適材適所の選択が大事！
データカテゴリ
- relational
- key value
- document
- in-memory
- graph
- time-series
- ledger
-
それぞれ対応するAWSサービスがあるよ
- どれもマネージドサービス
マネージドサービス
AWSが運用管理をする、ということ
DB構築の選択肢
- オンプレ
- EC2にDBインストール
- データベースサービスを利用する
- DB管理のフルマネージド化
管理作業
- オンプレだと全ての管理が必要 ハードウェア、OS
- 仮想サーバー(EC2)の場合物理的な作業やOSインストールなどは不要、一方でOSパッチ適用、DBインストール、設定は必要
- データベースサービス
- アプリケーション最適化のみに集中できる
- マネージドサービスを使うことは導入運用面でメリットが多い
- まずはマネージドサービスを導入することから検討する、要件に見合わない場合のみ仮想サーバ上に構築することを考える
それでも仮想サーバに構築する例
- 提供エンジンがマネージドサービスにない
- サービスの仕様・制限に要件が合わない
AWSのデータベースサービス
RDS
リレーショナルデータとは
- テーブル間でデータ分割
- 構造化されたデータ
- キーを介した結合
- データの正確性と一貫性
- 多 vs 1
ユースケース
- 課金周りの処理
- 堅牢な処理
選択指針
- 汎用用途
- 既存アプリ移行
- 正規化・リレーショナル
- SQL使いたい
- 柔軟なクエリ
- トランザクション処理
- データの堅牢性
RDS
- 様々なDBエンジンを選択可能
事例:住信SBIネット銀行
- オンプレOracleをAuroraへ移行中
- リンク 住信SBIネット銀行、オンプレのOracle DBをAWSのクラウドDBに移行、移行費用を3年で回収
Non Relational 他の6つ全て
Not Only SQL
- RDBMSではないDBの総称
- 従来のRDBMSの課題を解決するために生まれた
- NoSQLは非常に多くの種類がある
- それぞれ得意不得意がある、特性を理解することが大事
RDBMSとNoSQLの比較
| RDBMS | NoSQL |
|---|---|
| SQLを使ってアクセス | 各DBによって異なるクエリ方法 |
| トランザクション | トランザクション処理は限定的 |
| ストレージ最適化 | 計算リソース最適化 |
| 正規化リレーショナル | 非正規化 階層構造 |
| データ堅牢性・一貫性 | DBによる |
| スケールアウト煩雑 | 高いスケーラビリティ |
DynamoDB
キーバリューストア
- キーとバリューという単純構造
- 超高速なパフォーマンス
- RDBMSに比べて読み書きが高速
ユースケース
- あらゆる規模で低レイテンシーと高スループットのデータアクセス
- モバイル
- ウェブ Eコマースのショッピングカート ホリデーシーズンなどのピーク時の更新処理など
- ゲーム 永続化が必須のアイテムステータスなど
- 広告技術
解決したい課題
- インターネットスケールのシステム
- スケール規模を事前に予測するのは難しい
- 低レイテンシーと高スループットが求められる
- RDBはスケーリングに限界がある
- スケーリングに関わる課題の解決
- スケールアップはハードウェアに依存
選択指針
- スケーラビリティが求められる
- レスポンスタイム数ミリ描画求められる
- シンプルなクエリで済む
- 規模に関係なく数ミリ秒のレスポンス
- １日に10兆件以上のリクエスト処理可能
- どんな規模にも対応できる高速なキーバリューシステム
事例:amazon.com
- 世界最大のECビジネスであるamazon.comはその規模、パフォーマンス、およびメンテナンスの利点から、非リレーショナルクラウドデータベースで運用されています
- 1290万件/秒のアクセスをさばけた実績あり
DocumentDB
ドキュメント指向データベース
- JSONやXMLなどの不定形なデータ構造に対応
- 複雑なデータモデリングを容易に表現可能
ユースケース
- コンテンツ管理
- ニュース記事、レシピ
- カタログ
- E-コマースアプリケーション
- プロファイル管理
解決したい課題
- 頻繁に変更される属性情報
- 変更に対して柔軟に対応できるか
選択指針
- スキーマを決められないデータの格納
- 構造を意識したドキュメント指向の検索
DocumentDB
- フルマネージド、高速でスケーラブルかつ高可用性のMongoDB互換サービス
ElastiCache
インメモリデータベース
- キーバリュー
- 非常に高いパフォーマンス
ユースケース
- データキャッシュ
- クエリキャッシュ
解決したい課題
- リアルタイム性の高いアプリ
- マイクロ秒レベルのレイテンシ
選択指針
- ミリ秒未満のレイテンシーが求められる
- キャッシュ可能
- 障害時のデータ損失リスクを許容できる
- インメモリ処理のため障害によるデータ損失の可能性がある
- 非同期レプリケーション
ElastiCache
Redis Memcached互換のインメモリデータストア、キャッシュ
事例 Expedia
- リアルタイム分析基盤
- うまくDBサービスを使い分けている
- Aurora
- DynamoDB
- ElastiCache
Neptune
グラフ指向データベース
- データ間を相互に結びつけてデータ同士の関係をグラフという形で表す
- 多対多の関係を表すのが得意
- 例 SNS
ユースケース
- レコメンデーション
- 不正検出
- SNS newsfeed
解決したい課題
- グラフ構造を扱うアプリ
- 多対多の関係の扱い
選択指針
- トラバーサルか
- 短いクエリが大量に来る要件があるか
Neptune
- フルマネージドなグラフDBサービス
Timestream
時系列データ
- 時間が主軸
ユースケース
- IoTデバイス
- DevOpsイベント
- 産業用テレメトリ
解決したい課題
- 大量ログの絶え間ない格納
- ログ格納と分析の両立
選択指針
- 時系列データを扱うか
Timestream
- 高速でスケーラブルな完全マネージド型の事例列データベース
- preview
QLDB
台帳データベース
- データの変更履歴はイミュータブル
- 意図しない変更が発生していないことを暗号技術で検証
ユースケース
- 集中管理を行う元帳として利用
解決したい課題
- 台帳管理したい
- なんでもできる特権ユーザーの存在
Amazon QLDB
- フルマネージド台帳DB
- プレビュー
まとめ
- AWSは多様なデータカテゴリをサポート
- ユースケースに対応、運用・管理負荷を軽減できる
- 適材適所の選択
感想
万能のDBは存在しない。だから適材適所の選択が大事!
各データベースサービスの特性とユースケースをたった40分で学ぶことができる良いセッションでした。しっかり理解して適切な選択をできるようになりたいと思います！
2
