AWS上にあるDBシステムの使い分けについて。
- フルマネージド・データベースの特性に応じた使い分け
- 運用管理システム管理者がやってたことをAWSが受け持ち。
- 運用管理コストを下げる。
SQL vs. NoSQL
- 日本ではSQLDBが多用
- ACID属性
- NoSQL
- 低レイテンシ、高スループット、シンプルなAPI
- Webセッション管理]
SQLデータベース
RDS
- 特徴
- 数クリックで作成
- セキュリティグループ、VPC対応
- EC2で自作 VS.RDS
- ハードウェアにかかわる作業は一切やらない
- アプリケーションのみに特化
- ReadReplica(MySQL)
- MultiAZ
- トランザクションログ(5分に1回S3に)
- FailOverかかっても、DNSが自動に登録するため、アプリケーションではなにもしない。
- 使いどころ
- 容易なスケールアップ
- 既存資産の活用(人材、アプリ)
- 運用管理コスト(バックアップ、パッチ適用)の削減
- DCをまたいだ可用性 Multi-AZ
Redshift
- 分析用の大容量業務統合DB
- 列指向型(カラムナ)データベース
- 分析処理向き
- S3、DynamoDB等から直接データ取り込みが出来る。
- Case Study(MUJI Passport)
- ターゲットマーケティング
- AccessLog→サイトカタリストの内容を格納しBIツールで解析
- 使いどころ
- データウェアハウス(100GB以上が向く)
- OLTPでは使用しない(トランザクションはダメ)
- BIツールからの分析
- ROI(投資対効果)が不透明な中で大規模な投資リスクを下げる
NoSQL
ElastiCache
- 端的にいうとメモリキャッシュ
- RDBでもシャーディングすればできるけど、後々大変。
- 何が出来る？
- memcached, redisをサポート
- MultiAZ
- Auto Discovery for memcached
- Java,PHP client
- マネックス証券 Monex Insight
- 速度を求められるところ
- 各Tierが数分でスケールアップ可能
- つかいところ
- key-valueでのアクセス
- RDSで永続化されたデータを前提とし、キャッシュとして利用。
DynamoDB
- AWSが独自で開発
- データが3箇所のAZに保存される
- ストレージ容量も自動でスケールアップ
- Read/writeはそれぞれ必要な分だけ設定
- 利用分だけの従量課金ストレージ
- 使い始めるには？
- テーブルKey-Indexを決める
- Read-Writeを決める
- Hash Key - Range Key
- Hash Key：RDBでいうPK
- Range Key：セカンダリキーのような使い方。
- 使いところ
- キーとクエリでのアクセス
- 堅牢性
- スループットの容易な増減によるピーク付加への対応
- 事実上無制限なDB(前段階で考えなければいけない、要件がカットできる。)
EC2で自作する
- 用途に合わない場合は、EC2で自作する
- AWSでできないことはEC2でやる。
- が、当然運用コストは上がる。