AWSデータベースアップデート2017

AWSデータベースアップデート 2017
JAWS DAYS 2017
Amazon Web Services Japan K.K.

内容についての注意点
• 本資料では2017年3⽉11⽇時点のサービス内容および価格についてご説明しています。最新
の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。
• 資料作成には⼗分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に
相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。
• 価格は税抜表記となっています。⽇本居住者のお客様が東京リージョンを使⽤する場合、別途
消費税をご請求させていただきます。
• AWS does not offer binding price quotes. AWS pricing is publicly available and is
subject to change in accordance with the AWS Customer Agreement available at
http://aws.amazon.com/agreement/. Any pricing information included in this
document is provided only as an estimate of usage charges for AWS services based
on certain information that you have provided. Monthly charges will be based on your
actual use of AWS services, and may vary from the estimates provided.

AWSのデータベースサービス群⼀覧 (⼀部)
• Amazon Relational Database Service (RDS)
– マネージドRDBMS
• Amazon DynamoDB
– マネージドNoSQL
• Amazon ElastiCache
– マネージドインメモリキャッシュ
• Amazon Redshift
– マネージドDWH
• AWS Database Migration Service (DMS)
– マネージドDB移⾏

Amazon
RDS
Amazon S3
Request Rate
High Low
Latency
Low High
Data Volume
Low High
Amazon
Glacier
Amazon
CloudSearch
Structure
Low
High
Amazon
DynamoDB
Amazon
ElastiCache
HDFS

• Redis Cluster
• 3.5TB in-memory capacity
• ~4.5 million writes per second
• ~20 million reads per second
• Auto-Sharding with support up to 15 shards
• Cluster Level Backup and Restore
• Faster Failover (~30 seconds, 4X times faster)
• Enhanced Redis Engine for Improved Robustnes
s and Stability
• Redis 3.2 Engine
Redis Cluster

Amazon
ElastiCach
e
Amazon
EC2
Data
Sources
AWS
Lambda
(Dashboard)
1
Amazon
Kinesis
Streams
Amazon
DynamoDB
Hot Data
Longer
Retention
Use case for BigData

• Ex: Throttling requests to an
API
• Leverages Redis Counters
ELB
Externally
Facing
API
Reference: http://redis.io/commands/INCR
FUNCTION LIMIT_API_CALL(APIaccesskey)
limit = HGET(APIaccesskey, “limit”)
time = CURRENT_UNIX_TIME()
keyname = APIaccesskey + ":” + time
count = GET(keyname)
IF current != NULL && count > limit THEN
ERROR ”API request limit exceeded"
ELSE
MULTI
INCR(keyname)
EXPIRE(keyname,10)
EXEC
PERFORM_API_CALL()
END
Use Case - Rate Limiting

WRITE PERFORMANCE READ PERFORMANCE
インスタンスサイズによるスケール
Aurora MySQL 5.6 MySQL 5.7

P o s t g r e S Q L F o r A u r o r a
Aurora is now fully compatible with
both PostgreSQL and MySQL

1/10th The Cost Of
Commercial Grade
Databases
Fully PostgreSQL
Compatible
Several times better
performance than typical
PostgreSQL database
Scalable,
Durable and Secure
Migrate From
RDS For PostgreSQL
Amazon Aurora PostgreSQL-Compatible Edition

Performance Insights
• DBの知識を持ったエンジニアがいな
くとも、クエリパフォーマンスの評
価やDBの状態チェックを実施可能に
する機能
• Amazon Aurora PostgreSQL-
Compatible Editionには既に組み込
まれた状態でリリースされる
• 他のデータベースエンジンにも順次
展開予定

可⽤性向上のために
•可⽤性の低下はハードウェア故障以外にも
以下のような原因で発⽣する
1. データベース・ソフトウェアへのパッチ適⽤
2. スキーマの変更
3. リストアが必要なデータベースエラー

ゼロダウンタイムパッチ

ゼロダウンタイムパッチ
Network
ing
state
Applicati
on
state
Storage Service
App
state
Net
state
App
state
Net
state
Before
ZDP
New
DB
Engine
Old DB
Engine
New
DB
Engine
Old DB
Engine
WithZDP
セッションはパッチ
適⽤時に切断される
パッチ適⽤中でも
セッションは維持される
Storage Service

ゼロダウンタイムパッチ - 現在の制限 -
• ゼロダウンタイムパッチは以下の状態の場合、現在の⽅法でパッチを適⽤する
• ⻑時間実⾏中のトランザクションが存在する
• バイナリログが有効
• パラメータの変更が適⽤されずpending状態
• ⼀時テーブルが開かれている
• テーブルがロックされている
• SSLコネクションが使⽤されている
• リーダインスタンス

Online DDL: Aurora vs. MySQL
§ フルテーブルコピー: 全てのインデックスを
再構築 - 数時間から数⽇かかることも
§ DMLクエリ実⾏のために⼀時領域が必要
§ DDLクエリがDMLクエリスループットに影響
§ DMLクエリ実⾏中にテーブル・ロックが起こる
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
§ メタデータテーブルにエントリーを追加し、
スキーマバージョニングを利⽤する
§ 変更を適⽤するために最新のスキーマへブロック
をアップグレードする際はmodify-on-write
§ 現在はテーブルの最後にNullableなカラムを
追加する場合に対応
§ 他のadd column, drop/reorder, modify
datatypesに対応するために実装を⾏っている
MySQL Amazon Aurora

Online DDL performance
On r3.large
On r3.8xlarge
10GB table 0.27 sec 3,960 sec 1,600 sec
10GB table 0.06 sec 900 sec 1,080 sec

Aurora Auditing
MariaDB server_audit plugin Aurora native audit support
• We can sustain over 500K events/sec
Create event string
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
Write
to File
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free
queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance

様々な性能改善
• Improved index build
• Throughput improvement for workloads with hot row
contention
• Aurora独⾃のSpatial indexing
• Insert performanceの向上
• などなど

Faster index build
§ MySQL 5.6 はLinuxの先読みを活用しています
が、これにはbtreeに連続したブロックアドレスが
必要です。そのためエントリーをトップダウンで新
しいbtreeに挿入する際に、分割とたくさんのロギ
ングを引き起こします。
§ Auroraはtree内のポジション(ブロックアドレスで
はなく)を元にブロックをスキャンしてプリフェッチ
§ Auroraはリーフブロックを作製してからブランチを
作製していく
• 分割が発生しない
• 各ページは1度のみ参照される
• 1ページに1ログレコード
2-4X better than MySQL 5.6 or MySQL 5.7
0
2
4
6
8
10
12
r3.large on 10GB
dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours
RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

Cached read performance
• Catalog concurrency: データ・ディク
ショナリの同期とキャッシュ破棄の効率化
• NUMA aware scheduler: NUMA を考慮
したスケジューラへ変更すること、複数
CPUが搭載されているインスタンスで性能
向上
• Read views: read viewを作成する際に
ラッチフリーなread viewを作成するアルゴ
リズムに変更 0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 read requests/sec
* R3.8xlarge instance, <1GB dataset using Sysbench
25% Throughput gain

• Smart scheduler: IOヘビー・CPUヘ
ビーなワークロードそれぞれに動的に処理
スレッドを割り当てるスケジューラに変更
• Smart selector: 最も良いパフォーマンス
のストレージノードにあるデータを選択す
ることでリードレイテンシーを軽減
• Logical read ahead (LRA): btreeの順序
に応じて事前にpageを読み込んで置くこと
で、IO waitを軽減
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 requests/sec
* R3.8xlarge instance, 1TB dataset using Sysbench
10% Throughput gain
Non-cached read performance

§ プライマリーキーでソートされている
データのバッチインサートの速度を改善。
インデックス⾛査を⾏う際のカーソル位
置をキャッシュ
§ データパターンに応じて動的に機能を有
効・無効化
§ ツリーを下⽅向に⾛査する際のラッチ
ロックの競合を軽減
§ 双⽅向で全てのINSERTワークロードで
有効
– LOAD INFILE, INSERT INTO SELECT, INSERT
INTO REPLACE, Multi-value inserts.
Insert performance
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL: 全てのINSERTがrootからB-treeをトラバースする
Aurora: indexトラバースを抑制

Spatial Index Benchmarks
Sysbench – points and polygons
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . .. .
. . . . . . . . . . . . .
* r3.8xlarge using Sysbench on <1GB dataset
* Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS
0
20000
40000
60000
80000
100000
120000
140000
Select-only (reads/sec) Write-only (writes/sec)
Aurora
MySQL 5.7

AWS Database Migration Service
AWS Schema Conversion Tool

同種DB間で、ダウンタイムを最⼩限に移⾏
ソース:
オンプレミス、EC2、
RDS上のOracle
AWS Database
Migration Service
ターゲット:
RDS上のOracle
ソース:
RDS上のMySQL
AWS Database
Migration Service
ターゲット:
Amazon Aurora

異なるDB間で、ダウンタイムを最⼩限に移⾏
ソース:
RDS上のOracle
AWS Schema
Conversion Tool
ターゲット:
Amazon Aurora
ソース:
RDS上のOracle
AWS Database
Migration Service
ターゲット:
Amazon Aurora

対応データベース詳細
プラットフォームソースターゲット
Oracle Database 10g R2, 11g, 12c 10g, 11g, 12c
Microsoft SQL Server 2005, 2008, 2012, 2014 2005, 2008, 2012, 2014
SAP ASE 15.7以降 15.7以降
MySQL / MariaDB /
Aurora 5.5以降 5.5以降
PostgreSQL 9.4以降 9.3以降
Redshift - すべて

データベースの統合
ソース:
オンプレミス、EC2、RDS上の
複数のMySQL
AWS Database
Migration Service
ターゲット:
Amazon Aurora

継続的なデータレプリケーション
ソース:
Amazon Aurora
AWS Database
Migration Service
ターゲット:
異なるリージョンのAurora、
テスト用Aurora、
オンプレミスMySQL

AWS Schema Conversion Tool（SCT）
• 異なるRDB間での各種オブジェクトの
移⾏（変換）を補助するツール
• Windows, Mac, Linux にダウンロードして利⽤
• 稼動OSは64bit版のみサポート
• ODBCで接続。SSLサポートあり
• ソースコード内のSQL分析に対応
• 移⾏対象：
• 表、インデックス、トリガー、プロシージャ、制約、ビュー

対応データベース詳細
Source Database Target Database on Amazon RDS
Microsoft SQL Server (version 2008 and later)
Amazon Aurora (MySQL or PostgreSQL), Microsoft
SQL Server, MySQL, PostgreSQL
MySQL (version 5.6 and later) Amazon Aurora (PostgreSQL), MySQL, PostgreSQL
Oracle (version 10.2 and later)
Amazon Aurora (MySQL or PostgreSQL), MySQL,
Oracle, PostgreSQL
PostgreSQL (version 9.1 and later) Amazon Aurora (MySQL), MySQL, PostgreSQL
Greenplum Database (version 4.3 and later) Amazon Redshift
Netezza (version 7.2 and later) Amazon Redshift
Oracle (version 11 and later) Amazon Redshift
Teradata (version 14 and later) Amazon Redshift

ソースコード内のSQL分析に対応
OracleからPostgreSQLへの例

データベース移⾏の⼿順:SCTとDMSの位置づけ
(SCT)
(DMS)
DDL・スキーマの移行
＋プロシージャ等
データの移行

埋め込みSQLの変換⽀援
• ソースコードをスキャンして、
埋め込みSQL（DML）を発⾒し、
変換（右表の対応）
• C++, Java, C#に対応
• 事前にスキーマ（DDL）の変換が必要

Migrating Databases To AWS
20,000+
databases migrated
Migrate between
on-prem and AWS
Migrate between
databases
Automated schema
conversion
Data replication for
zero downtime migrations

よくある課題
• Amazon S3 内のデータを分析するための
⼯数が多い
• ユーザーは明細データにアクセスできない
• HadoopクラスターやDWHの管理には
専⾨知識が必要

Amazon Athena とは
標準SQLを使って直接 Amazon S3 から
データ分析を簡単に⾏える
インタラクティブクエリサービス

Athenaはサーバーレス
• インフラ管理不要
• すぐに起動する
• ⾃動アップグレード

Athena の想定ユースケース
ユースケースデータユーザ
新しく取得したデータに対して，
DWに⼊れる価値があるか探索的に検証
新しく取得したデータアナリスト
利⽤頻度の低い過去のデータに対する，
BIツール経由のアドホックな分析
コールドデータアナリスト
Webサーバで障害が発⽣したときに，
ログを漁って原因追求
アクセスログサーバ運⽤
⼤規模でないデータに対しての，
低頻度で実施するETL処理
⽣データ開発者

Athena のデータ形式 / 圧縮形式
項⽬値注意点
データ形式
CSV, TSV,
Parquet, ORC,
JSON, Regex,
Avro
• 2017/2/16 に Avro と OpenCSV
Serde* をサポート
• JSONについては Hive-JsonSerDe と
Openx-JsonSerDe の2つが利⽤可能
圧縮形式 Snappy, Zlib, GZIP • 現状，LZOはサポートしていない
* Serialize/Deserialize の略で，データの⼊出⼒形式の変換クラス

Athena のテーブル定義
• 標準のテーブル定義の後に，データ形式，圧縮形式，データの場所などを指定
• 既に Hive DDL がある場合，Athena で実⾏すれば，すぐクエリを投げられる
• 既存の EMR の Hive メタストア⾃体に，直接アクセスすることはできない
• schema-on-read なので，同⼀データに複数のスキーマを定義可能
CREATE EXTERNAL TABLE IF NOT EXISTS action_log (
user_id string,
action_category string,
action_detail string
year int,
month int,
)
PARTITIONED BY (year int, month int)
STORED AS PARQUET
LOCATION 's3://athena-examples/action-log/’
TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');
パーティション
データ形式
データの場所
圧縮形式

Athena のクエリ
• Presto と同様，標準 ANSI SQL に準拠したクエリ
• WITH句，Window関数，JOINなどに対応
• Presto で⽤意されている関数は，基本的に使⽤可能
[ WITH with_query [, ...] ]
SELECT [ ALL | DISTINCT ] select_expression [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ]
[ HAVING condition ]
[ UNION [ ALL | DISTINCT ] union_query ]
[ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ]
[ LIMIT [ count | ALL ] ]

データ設計に影響する Athena の特性
• OLTP* ではなく OLAP** 向け
– そもそもトランザクションは未サポート
• ETL ではなく分析向け
– データをフルスキャン & 変換するのは⾼コストな設計
– リトライ機構がないため，安定的なバッチ処理には向かない
• いかにして読み込むデータ量を減らすかが重要
– パーティション
– 列指向フォーマット
– 圧縮
* Online Transactional Processing ** Online Analytical Processing

簡単に使えるAthena
• コンソールにログイン
• テーブルを作成
– Hive DDL で記述
– テーブル追加ウィザードをコンソールから使⽤
• クエリ実⾏

Athenaの冗⻑構成
• サービスエンドポイントまたはコンソールにログインするだけ
• 複数のアベイラビリティゾーンにまたがった複数台のサーバー
を使⽤
• データは Amazon S3 にあり、⾼い可⽤性と99.999999999%
の耐久性を実現

Amazon S3 から直接クエリ
• データのローディング不要
• そのままのフォーマットでクエリ可能
– テキスト、CSV、JSON、ウェブログ、AWSサービスログ
– さらなる性能向上とコスト削減のためにORCやParquetなどを利⽤することも
可能
• ETL不要
• Amazon S3 から直接ストリーム可能
• Amazon S3 の耐久性と可⽤性を享受

Athenaの⾼速性能
• パフォーマンスチューニング済み
• ⾃動パラレルクエリ
• 結果はコンソールにストリームで表⽰
• 結果はS3に同時保存
• データの圧縮や列指向フォーマットの
利⽤でさらなるパフォーマンス向上も可能

現⾏のデータ処理フロー
複数のソースから
S3にデータを
アップロード
Amazon EMR を
使⽤してETL
ETLされた
データを
S3に保存
データを
Redshiftに
ロード
QuickSight で
分析

現⾏のデータ処理フロー
複数のソースから
S3にデータを
アップロード
Amazon EMR を
使⽤してETL
ETLされた
データを
S3に保存
データを
Redshiftに
ロード
QuickSight で
分析
SQLを使⽤して⽣データに
アドホックアクセス
集計したデータを
クエリすることも可能

リファレンスアーキテクチャ
Athena
⽣ログに対する
調査，検証などの
アドホッククエリ DWロード前の軽い分析
⼩規模の新サービス
既存のデータパイプラインを補完する形で活⽤
ちょっとしたダッシュボードのバックは Athena が活躍

ユースケース: DataXu 社
Athena
CDN
Real Time Bidding
Reporting Platform
Kinesis ETL
(Spark SQL)
S3
Data Visualization
Reporting
180TB / ⽇のデータを Athena で分析
http://www.slideshare.net/AmazonWebServices/announcing-amazon-athena-instantly-analyze-your-data-in-s3-using-sql

Amazon QuickSight とは
クラウドのパワーによって作られた
⾼速なBIサービス
旧来型のBIソフトの10分の1のコストで提供

直感的なビジュアライゼーション
• 簡単な操作で可視化を実現
• データ型を認識し、⾃動的にグラフを
サジェストするオートグラフ
• 複数の分析結果を「ストーリー」
としてまとめて、共有
• 読み取りのみ許可したいグラフは
「ダッシュボード」として共有

13種類のVisual + Auto Graph
• 13種類のVisualを利⽤可能
– 棒グラフ（⽔平・垂直）
– 積み上げ棒グラフ（⽔平・垂直）
– 100%積み上げ棒グラフ（⽔平・垂直）
– 折れ線グラフ
– エリアラインチャート（⾯グラフ）
– ピボットテーブル
– 散布図
– ツリーマップ
– 円グラフ
– ヒートマップ
• Auto Graphでグラフを⾃動選択可能

SPICE
• インメモリ処理に最適化された⾼速データベース
• カラムナ：1/2~1/4のサイズに圧縮
• フルマネージド：運⽤管理不要
– ⾃動的にスケール、⾼い可⽤性
• RDBのデータやファイルをSPICEに保存することで
⾼速なクエリを実現
• QuickSight Standard Edition １ユーザあたり
10GBのSPICE⽤領域が利⽤可能（追加可能）
※ SPICE = Super-fast, Parallel, In-memory, Calculation Engine

AthenaによるRedshiftとEMRの補完
Amazon S3
EMR Athena
QuickSight
Redshift

RedshiftとAthenaの⽐較
Redshift
• 形式化および整理された
企業全体の「信頼できる
唯⼀の情報源」として
データを保存
• ⾮常に⼤規模なデータに
対する複雑なクエリを
⾼速に実⾏可能
Athena
• ⼀部のウェブログなどに
すばやくクエリし、
サイトのパフォーマンス
問題解決を⾏なう
• データの形式化や
インフラ管理について
意識する必要がない

EMRとAthenaの⽐較
EMR
• SQLクエリ実⾏を超える
機械学習、グラフ分析、
データ変換などの
スケールアウトする
幅広いデータ処理
タスクを実⾏可能
Athena
• ⼀部のウェブログなどに
すばやくクエリし、
サイトのパフォーマンス
問題解決を⾏なう
• クラスター管理や
インフラ管理について
意識する必要がない

Athenaでの課題解決
• Amazon S3 内のデータを分析するための⼯数が多い
ETL不要。ローディング不要。データに直接クエリ
• ユーザーは明細データにアクセスできない
ユーザーが欲しい粒度のデータにクエリ可能
• HadoopクラスターやDWHの管理には専⾨知識が必要
インフラ管理不要

AWS Glue
• データストア間でデータ移動を簡単に⾏うための
マネージドETL サービス
• データ検出、変換、マッピング、ジョブスケジューリングの
タスクを簡単に、⾃動で⾏える
• ETL ジョブをスケジュールし、必要なすべての
インフラストラクチャのプロビジョニングとスケーリングを⾏う
• AWS Glue では、Amazon S3、Amazon RDS、
Amazon Redshift と統合し、JDBC 準拠のデータスト
アに接続可能
• データソースを⾃動的にクロールし、データフォーマットを
識別してからスキーマと変換を提案するため、データフローを
⼿作業でコーディングする時間を費やす必要がなくなる

Amazon Glue
• データカタログを構築
• JSON、CSV、Parquet などの⼀般的な
ソースフォーマットやデータタイプに
対して、あらかじめ作成された分類⼦
を
使⽤してデータソースをクロールし作
成
• 独⾃の分類⼦を追加することや、
AWS Glue コミュニティから分類⼦を
選択してクロールに使⽤することも可
能

Amazon Glue
• データ変換を⽣成、編集
• AWS Glue によって Pythonコードが
⽣成されてソースからデータが
抽出され、そのデータがターゲットの
スキーマに合わせて変換されて
ターゲットにロードされる
• ⽣成されるコードは⼀般的な
エラーハンドリングなども⼊っている
• IDEを使って編集も可能

Amazon Glue
• ジョブをスケジュールして実⾏
• フローを定期的に、トリガーに応じて、
または AWS Lambda イベントに
対応して実⾏
• ETL ジョブが Apache Spark ノードに
⾃動的に配布されるためデータ量が
増加しても ETL の実⾏時間を⼀定に
保つことが可能
• ジョブの実⾏を適切な順序で調整し、
失敗したジョブを⾃動的に再試⾏可能。
時間通りにジョブを完了させてコストを
最⼩限に抑えるために、必要に応じて
スケーリングすることも可能

AWSデータベースアップデート2017

AWSデータベースアップデート2017

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a AWSデータベースアップデート2017

Semelhante a AWSデータベースアップデート2017 (20)

Mais de Amazon Web Services Japan

Mais de Amazon Web Services Japan (20)

Último

Último (9)

AWSデータベースアップデート2017