使ってみよう！
データベースとストレージ
〜 Getting Started with AWS Database and Storage Services 〜
Amazon Web Services Japan
テクニカルトレーナー
本セッションの概要
AWS におけるデータストアの使い分けについて解説します
Ø
データストアの役割
Ø
AWSのストレージサービス
•
S3, Glacier
Ø
AWSのデータベースサービス
•
RDS, DynamoDB
⼀般的なWebアプリケーション構成（ストレージなし）
APサーバ
ELB
トランザクション
データ
DB
ユーザ
ファイル
⼀般的なWebアプリケーションの構成（NFS）
APサーバ
ELB
ファイル
トランザクション
データ
DB
NFS
ユーザ
・可⽤性？
・パフォーマンス？
NFS
⼀般的なWebアプリケーションの構成（S3）
APサーバ
ELB
ファイル
トランザクション
データ
DB
S3
ユーザ
HTTP
・⾼耐久性
・⾼可⽤性
・スケーラブル
・低コスト
⼀般的なWebアプリケーションの構成
APサーバ
ELB
ファイル
トランザクション
データ
DB
S3
ユーザ
HTTP
⼀般的なWebアプリケーションの構成
APサーバ
ELB
ファイル
トランザクション
データ
DB
S3
ユーザ
HTTP
セッションデータ
データストレージに関する考慮事項
万能のデータベースはない
以下を検討することによりデータ要件を分析する
Ø
データ形式
Ø
データサイズ
Ø
クエリの頻度
Ø
データのアクセス速度
Ø
データの保持期間
AWS のマネージド ストレージ & データベース サービス
コンピュー
ティング
ストレージ
データ
ベース
アプリケーションサービス
デプロイと管理
ネットワーキング
Amazon DynamoDB
Amazon ElastiCache
Amazon RDS
Amazon Redshift
AWS Database
Migration Service
Amazon S3
Amazon Glacier
Amazon Simple Storage Service (S3)
Amazon S3
インターネット対応のストレージ
常にオンラインで HTTP でアクセス可能
どのような量でも、データの保存、取り出しを
いつでも、ウェブ上のどこからでも実⾏可能
スケーラビリティ、信頼性、耐久性に優れ、
かつ⾼速
Amazon S3 の特徴
バケットに無制限のオブジェクトを保存可能
最⼤ 5 TB のオブジェクトを保存可能。バケットのサイズ制限なし
年間 99.999999999% のオブジェクト耐久性と、99.99% の
オブジェクト可⽤性を提供するように設計
HTTP/S エンドポイントにより、データの量がどれほど多くても、
いつでもどこからでも保存や取得をウェブ上で実⾏可能
スケーラビリティと信頼性に優れ、⾼速で安価
オプションで、AWS またはお客様が管理するクライアント側暗号化を
使⽤したサーバー側の暗号化をサポート
監査のためのアクセスログ
標準ベースの REST および SOAP インターフェイスを提供
⼀般的な使⽤シナリオ
ストレージとバックアップ
アプリケーションファイルのホスティング
メディアホスティング
ソフトウェア配信
AMI とスナップショットの保存
Amazon S3 の料⾦設定
使⽤した分のみの料⾦が発⽣
最低料⾦はない
Amazon S3 バケットのロケーションに基づく価格設定
AWS 簡易⾒積りツールを⽤いた⽉額料⾦の⾒積もり
料⾦の内訳:
Ø
ストレージ料⾦
Ø
リクエスト料⾦
Ø
データ転送料⾦: Amazon S3 からのデータ転送
Amazon S3 の概念
Amazon S3 では、データがオ
ブジェクトとしてバケットに保存される
オブジェクトは、ファイルと、そのファ
イルについて説明する任意のメタデータ
(省略可能) で構成される
アカウントあたり最⼤ 100 のバケット
を所有できる
バケットとそのオブジェクトのアクセス
ログを制御できる
Amazon
S3
オブジェクト
が保存された
バケット
バケット
オブジェクト
オブジェクトキー
オブジェクトキーとは、バケット内のオブジェ
クトが持つ⼀意の識別⼦
http://
doc
.s3.amazonaws.com/
2006-03-01/AmazonS3.html
Amazon S3 のセキュリティ
以下によりバケットとそのオブジェクトのアク
セスを制御可能:
Ø
アクセスコントロールリスト (ACL)
Ø
バケットポリシー
Ø
Identity and Access Management (IAM) ポリシー
SSL で暗号化されたエンドポイント経由で Amazon S3
にデータをアップロードまたはダウンロード
Amazon S3 バージョニング
パフォーマンスに影響を与えずに偶発的な上書きや
削除から保護する
アップロードごとに新しいバージョンを⽣成する
削除されたオブジェクトの取得や以前のバー
ジョンへのロールバックが可能
Amazon S3 バケットの 3 種類の状態:
Ø
バージョニング無効 (デフォルト)
Ø
バージョニング有効
Ø
バージョニング⼀時停⽌
バージョニング有効
Key: photo.gif
ID: 121212
Key: photo.gif
ID: 111111
Amazon Glacier
低コストの⻑期アーカイブサービス
低頻度アクセスのデータに最適
99.999999999% の耐久性を実現するように設計
アクセス可能になるまでの時間により取り出し料⾦が異なる
Ø
迅速：1〜5分
Ø
標準：3〜5 時間
Ø
⼤容量：5〜12時間
1 GB あたり⽉額 0.005 USD 未満 (リージョンによっ
て異なる)
Amazon S3 ストレージクラス
ストレージクラス
耐久性
可⽤性
その他の考慮事項
Amazon S3 標準
99.999999999%
99.99%
なし
Amazon S3
標準 – 低頻度
アクセス (IA)
99.999999999%
99.90%
•
オブジェクトに関連付け
られる取り出し料⾦あり
•
低頻度アクセスのデータ
に最適
Glacier
99.999999999%
99.99%
(オブジェクト復元後)
•
リアルタイムアクセスには
利⽤不可
•
アクセスする前にオブジェ
クトを復元する必要あり
Amazon S3 オブジェクトのライフサイクル
ライフサイクル管理
は、
オブジェクトをその存続期間にわたって
Amazon S3 でどのように管理するかを定義する。 S3バケットに格納するファ
イルの中には、ライフサイクルルールを定義すべきものが多くある:
ログファイル
アーカイブ⽂書
デジタルメディアアーカイブ
⾦融レコードと健康管理レコード
ゲノムシーケンスのrawデータ
⻑期的なデータベースバックアップ
規制順守のために保持する必要があるデータ
AWS マネージドデータベースサービス
データ・ストアの特性に応じて使い分ける
Amazon DynamoDB
Amazon ElastiCache
SQL
NoSQL
•
低レンテンシ
•
インメモリ
•
3拠点間での
レプリケーション
•
⾼速パフォーマンス
•
⼀貫したスループット
•
トランザク
ション処理
•
汎⽤⽤途
•
集計・分析処理
•
⼤容量データ
•
DWH
SQL データベースと NoSQL データベース
SQL
NoSQL
データストレージ
⾏と列
キーと値
スキーマ
固定
動的
クエリ
SQL 使⽤
ドキュメントのコレクション
に焦点を合わせる
スケーラビリティ
垂直
⽔平
ISBN
タイトル
著者
形式
9182932465265
クラウドコンピュー
ティングの概念
Wilson,
Joe
ペーパー
バック
3142536475869
The Database Guru
Gomez,
Maria
電⼦
ブック
SQL
NoSQL
{
ISBN: 9182932465265,
Title: "
クラウドコンピューティングの概念",
Author: "Wilson, Joe",
Format: "ペーパーバック"
}
Amazon Relational Database Service (RDS)
コスト効率に優れ、サイズ変更が可能なキャパシ
ティー
時間のかかるデータベース管理タスクが不要に
なる
Amazon Aurora、MySQL、MariaDB、
Microsoft SQL Server、Oracle、および
PostgreSQL の各データベースのすべての機能を
利⽤できる
Amazon
RDS
Amazon RDS
シンプルかつ迅速なデプロイ
⼀般的なデータベース管理タスクの処理
アプリケーションとの互換性
⾼速で予測可能なパフォーマンス
シンプルかつ迅速なスケール
安全
コスト効率
DB インスタンス
DB インスタンスは Amazon RDS の基本構成要素
である
DB インスタンスは、クラウド内の独⽴したデータ
ベース環境である
DB インスタンスには、複数のユーザーが作成した
データベースを含めることができる
Amazon RDS バックアップの使⽤⽅法
⾃動バックアップ:
Ø
データベースを特定時点ま
で復元する
Ø
デフォルトで有効
Ø
最⼤ 35 ⽇間までの保持期
間を選択できる
⼿動スナップショット:
Ø
スナップショットから新しい
データベースインスタンスを
作成できる
Ø
ユーザーによって開始される
Ø
ユーザーによって削除される
まで持続される
Ø
Amazon S3 に保存される
Amazon RDS のセキュリティ
Amazon VPC で DB インスタンスを実⾏する
IAM ポリシーを使⽤して Amazon RDS リソースへのアクセスを許可する
セキュリティグループを使⽤する
DB インスタンス (Amazon Aurora、Oracle、MySQL、MariaDB、
PostgreSQL、Microsoft SQL Server) には Secure Socket Layer (SSL)
接続を使⽤する
保管時の RDS DB インスタンスとスナップショットを保護するには、
Amazon RDS の暗号化を使⽤する
Oracle DB インスタンスおよび Microsoft SQL Server インスタンスでは
ネットワーク暗号化と Transparent Data Encryption (TDE) を使⽤する
DB エンジンのセキュリティ機能を使⽤して、DB インスタンスへのアクセ
RDS のマルチ AZ 配置
マルチ AZ の動作により、データベースは同じ
AWS リージョン内の別の AZ に同期的にレプリ
ケートされる
マスターデータベースに障害が発⽣した場合は、⾃
動的にスタンバイに対してフェイルオーバーを⾏う
計画されたメンテナンスをまずスタンバイデータ
ベースに適⽤
弾⼒性と耐久性のあるアプリケーションアーキテクチャ
Amazon RDS データベース
インスタンス:
マスターおよびマルチ AZ ス
アプリケーション
(Amazon EC2 インスタ
ンス内)
Elastic Load Balancing
ロードバランサーイン
スタンス
Amazon RDS のベストプラクティス
メモリ、CPU、ストレージの使⽤状況をモニタリングする
マルチ AZ 配置を使⽤して、同期されたスタンバイレプリカを別のアベイラ
ビリティーゾーンに⾃動的にプロビジョンし、維持する
⾃動バックアップを有効にする
1 ⽇のうちで WriteIOPS が低くなる時間帯に実⾏されるようにバックアップ
ウィンドウを設定する
DB インスタンスの I/O 処理能⼒を⾼めるには
Ø
I/O 処理能⼒の⾼い DB インスタンスクラスに移⾏する
Ø
標準ストレージからプロビジョンド IOPS ストレージに変換し、プロビジョンド IOPS
に合わせて最適化された DB インスタンスクラスを使⽤する
Ø
プロビジョンド IOPS ストレージを使⽤している場合は、追加のスループット性能をプ
ロビジョニングする
クライアントアプリケーションが DB インスタンスの DNS データをキャッ
シュに格納する場合は、設定する TTL を 30 秒未満にする
DB インスタンスのフェイルオーバーをテストする
Amazon RDS for Aurora
特徴
(
http://aws.amazon.com/jp/rds/aurora/
)
Ø
MySQL5.6と互換性あり (PostgreSQL版preview中）
Ø
3AZに6本のディスクに書き込み2本のディスク障害で
はRead/Write可能。3本のディスク障害でもRead可能
Ø
キャシュとログをAuroraプロセスから分離することで
Auroraプロセスのリスタートでもキャッシュが残る
Ø
レプリケーション遅延は10-20ms程
Ø
64TBまでディスクがシームレスにスケールする
価格体系
(http://aws.amazon.com/jp/rds/aurora/pricing/)
Ø
インスタンスタイプによる
Ø
実際に利⽤したディスク容量 (プロビジョニング不要)
Amazonがクラウド時代に再設計したデータベース
Aurora
のストレージ
SSD
を利⽤したシームレスにスケール
するストレージ
Ø
64TB
まで⾃動的にスケール
標準で⾼可⽤性を実現
Ø
2
つのコピー障害時でも読み書きに問題なし
Ø
3
つのコピー障害時でも読み込み可能
Ø
継続的なS3へのバックアップ
リードレプリカもマスタと同じ
ストレージを参照
Ø
レプリケーション遅延は10ms-20ms
SQL
TransactionsAZ 1
AZ 2
AZ 3
Caching
SQL
TransactionsCaching
レプリケーション
Aurora Master
30% Read
70% Write
Aurora Replica
100% New
Reads
Shared Multi-AZ Storage
MySQL Master
30% Read
70% Write
MySQL Replica
30% New Reads
70% Write
シングルスレッド
でBinlog適⽤
Data Volume
Data Volume
MySQL read scaling
レプリケーションにはbinlog / relay logが必要
レプリケーションはマスターへ負荷がかかる
レプリケーション遅延が増加していくケースが
PAGE CACHE UPDATE
