1

Amazon Redshiftへの移行方法と設計のポイント

2016年7月15日アマゾン ウェブ サービス ジャパンソリューションアーキテクト下佐粉 昭（しもさこ あきら）

@simosako Follow me!

2

内容

• データウェアハウス構築の課題

• Amazon Redshiftの基本構造

• 移行時の検討ポイント

• 設計のポイント

• まとめ

3

データウェアハウス構築の課題

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築・維持

– バックアップ＆リストア

– モニタリング

4

データウェアハウス構築の課題とAWSクラウド

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築・維持

– バックアップ＆リストア

– モニタリング

AWSクラウド

• 初期投資不要

• 利用分だけの支払い

• 安価

• いつでもやめられる

5

データウェアハウス構築の課題とAWSクラウド

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築・維持

– バックアップ＆リストア

– モニタリング

AWSクラウド

• 数クリックでDWHが起動

• バックアップやモニタリングといった運用機能を含む

6

Amazon Redshiftの基本構造

7

DWH特化の大規模RDB

ペタバイト級までスケールアウト

フルマネージド

高い汎用性;PgSQL互換性

$1,000/TB/年; 最小$0.314/時から

Amazon

Redshift

より速くよりシンプルにより安価に

※費用は2016年7月時点での東京リージョンのものです

8

Redshiftを大規模に活用いただいているお客様

NTT Docomo | Telecom FINRA | Financial Svcs Philips | Healthcare Yelp | Technology NASDAQ | Financial Svcs

The Weather Company | Media Nokia | Telecom Pinterest | Technology Foursquare | Technology Coursera | Education

Coinbase | Bitcoin Amazon | E-Commerce Etix | Entertainment Spuul | Entertainment Vivaki | Ad Tech

Z2 | Gaming Neustar | Ad Tech SoundCloud | Technology BeachMint | E-Commerce Civis | Technology

9

大規模DWHを実現するための構造

• スケールアウト可能な設計– 1つのSQLを複数ノードでパラレルに処理する設計

– ノードを増やすことでパフォーマンスと容量が増加

• ディスクIOを削減する機能を搭載– ディスクIOがデータベースの一番のボトルネック

10

スケールアウト可能な構成①

SELECT *

FROM lineitem;

リーダーノードがクライアントからSQLを受け取る

CPU CPU CPU CPU CPU CPU

Leaderノード

Computeノード

１つの表を各ノードのストレージに分散して保存

Table A

Table B

11

スケールアウト可能な構成②

SELECT *

FROM lineitem;

SQLをコンパイル、コードを生成し、コンピュートノードへ配信

CPU CPU CPU CPU CPU CPU

Leaderノード

Computeノード

スライス（論理的な処理単位）ごとに並列処理

12

ノードタイプ

• SSDベースのDCとHDDベースのDSから選択– データは圧縮されて格納されるため、ストレージ総量より多くのデータが格納可能

• 最大128ノード：2ペタバイトまで拡張可能– ノードタイプと数は後から変更可能

DC1 - Dense Compute

vCPU メモリ(GB) ストレージ ノード数 価格(※)

dc1.large 2 15 0.16TB SSD 1~32 $0.314 /1時間

dc1.8xlarge 32 244 2.56TB SSD 2~128 $6.095 /1時間

DS2 – Dense Storage

ds2.xlarge 4 31 2TB HDD 1~32 $1.190 /1時間

ds2.8xlarge 36 244 16TB HDD 2~128 $9.520 /1時間

※価格は東京リージョンにおいて2016年7月時点のものです

13

IOを削減する① - 列指向型（カラムナ）

・行指向型（他RDBMS） ・列指向型（Redshift）

orderid name price

1 Book 100

2 Pen 50

…

n Eraser 70

orderid name price

1 Book 100

2 Pen 50

…

n Eraser 70

DWH用途に適した格納方法

14

IOを削減する② - 圧縮とゾーンマップ

• 1MBのブロック単位でデータを格納

• データは圧縮される

• ブロック内の最小値と最大値を保存

ゾーンマップで不要なブロックを読み飛ばし、圧縮で読み取り量を削減

10 | 13 | 14 | 26 |…

… | 100 | 245 | 324

375 | 393 | 417…

… 512 | 549 | 623

637 | 712 | 809 …

… | 834 | 921 | 959

10

324

375

623

637

959

15

最も大きな価値は、利用に集中できる環境

• 数クリックでDWHが起動

• バックアップは自動的にS3へ

• モニタリング機能を内蔵

• パッチ適用も自動化

運用ではなく利用にフォーカス

16

待機系や開発系への考え方が変わる

• 開発や検証のRedshiftは常時不要– 必要な時にスナップショット（バックアップ）から作成すれば良い

• インスタンスタイプやノード数は変えられる– リサイズ機能で変更可能

– リサイズ中は読み取りアクセス可能

• 開発系だからといって小さいサイズで利用しない– 本番のスナップショットから、本番と同じサイズのクラスターで

17

移行時の検討ポイント

18

既存DWHのRedshift移行検討フロー

アーキテクチャの比較

対応機能があるか確認、

代替機能の検討

分散キー等データ配置の最適化検討

データ型のマッピング

データ移行する場合は、

データ移行方式の検討

PoCの実施

アプリケーションの見直し、

移行方式検討移行判断

19

アーキテクチャの確認ポイント

• 移行前のRDBはDWH特化か、通常のRDBか– DWH特化の環境からだと比較的特徴が近いケースが多い

– 汎用（通常の）RDBからの場合は、Redshiftに適したワークロードかを確認

Redshift（DWH特化） 汎用型RDBMS

データストア カラムナ（列指向） 行指向

アクセス単位 1MB（粒度が大きい） 2KB～32KB（粒度が細かい）

高速化手法 スケールアウト（MPP） スケールアップ

データ検索 圧縮、ゾーンマップ インデックス

データロード 大容量データの一括ロードに特化

小規模の並列更新にも対応

20

Redshiftに適したワークロードか？

• Redshiftは１つのクエリをいかに速く処理させるかを重視して設計されたデータベース

• Redshiftに向くワークロード– 巨大なデータ・セット（数百GB～ペタバイト）

– １つ１つのSQLが複雑

– 同時実行SQLは少ない

– データの更新は一括更新が多い

21

Redshift以外を検討すべきワークロード

• 並列クエリ数が多い（※並列接続数ではなくクエリの並列実行数）

• 極めて短いレーテンシが必要

• 非定形データの処理

• RDS (RDB)• DynamoDB (NoSQL)• ElastiCache (インメモリ）

• Elastic MapReduce（Hadoop）• ETLツール＋EC2

22

機能の確認ポイント

• 利用している機能がRedshiftでも使えるかを確認

• 使えない場合は代替方法を検討

機能 Redshift

SQL 一般的なANSI SQL（PgSQLと高い互換性）

接続プロトコル ODBCとJDBC(PgSQLプロトコル互換）

ユーザ定義関数 PythonによるスカラーUDF

ストアドプロシージャ （未対応）別途外部アプリケーションで対応

半構造化データ読み取り JSONに対応

マテリアライズド・ビュー （未対応）別途マート表の作成等で対応

シーケンス列 Identityをサポート

23

アプリケーションの見直し

Redshift

基幹業務アプリ

DWH

分析ソフトウェア

分析プログラム

現状調査

基幹業務を分離し分析に特化させる

分析ソフトウェアのRedshift対応確認

基幹業務アプリ

RDS

分析プログラムの言語確認、SQLでDBMS依存の関数等使っていないか調査

適材適所なDBを使い、データ配置を変えられるか

対応していない分析ソフトの見直し可能か

DWH利用システム（アクセス元）の洗い出し

必要であれば、分析プログラムの修正、SQLの修正、テストが可能か

分析ソフト

分析プログラム

PoCを計画する

必要タスクの洗い出し

24

型のマッピング• 現利用RDBとRedshiftの型（以下）をマッピングする• 注意点

– charはシングルバイトのみサポート– varcharはUTF-8形式でのマルチバイトをサポート

参照）

http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_unsupported-postgresql-datatypes.html

25

データの移行（転送）

• 初期データの転送– ネットワーク転送

• AWS Database Migration Service

– 物理デバイスを活用した転送• AWS Import/Export Snowball

• 日々の更新データ転送– ネットワーク転送

• 日々発生するデータサイズと回線帯域から適切な転送方法を検討する

26

移行を支援するためのAWSサービス

Database Migration Service– 異機種RDBMS間でデータ移

行を支援するサービス– データを型変換しながらコ

ピー– 低負荷の差分レプリケーショ

ン– マルチAZ構成

Schema Conversion Tool– 異機種RDBMS間のスキーマ

（DDL)変換を支援– 表、ビュー、トリガー、プロ

シージャ等– ソースコード（Java, C#, 埋

め込みC）の中にあるDDLの変換も支援

27

プライベートネットワークを構築

• Virtual Private Cloud（VPC）でプライベートなネットワーク領域を作成し、既存環境と接続する

ＡＷＳクラウド

VPC

イントラ

インターネット

プライベートサブネット

分離したNW領域を作成

インターネットVPN接続 (IPSec)

パブリックサブネット

インターネットゲートウェイ

仮想サーバ (EC2)

DBサービス(RDS)専用線接続Direct Connect

28

経路と帯域

• 経路によって帯域・安定性が異なる• インターネット経由

• Direct Connect（専用線）

• 帯域を活かすには、並列化が有効

オンプレミスDC

orders1.csv

1,pencil,100,15-06-01

2,eraser,50,15-06-02

…

・・・

ordersN.csv

30,pen,150,15-06-28

31,book,50,15-06-29

…

• 差分・圧縮• 並列転送

DX（専用線）

インターネット

VPN

OR

プロトコルの選択

29

設計のポイント

30

テーブル設計・データ配置

• DWHではスタースキーマやスノーフレークスキーマが一般的。Redshiftに適している

• DISTKEYやSORTKEYをうまく設定することでスタースキーマでの速度を最適化可能

• QUERY実行時の負荷とロード時の負荷のバランスを見て最適なテーブル設計とする

31

SORTKEYでディスクアクセスを最小にする

• SORTKEY– SORTKEYに応じて、ディスク上にデータが順序を守って格納

– オプティマイザはソート順序を考慮し、最適なプランを構築

– CREATE TABLE時に指定

• CREATE TABLE t1(…) SORTKEY (c1, …)

• SORTKEYの使いどころ– 頻繁に特定のカラムに対して、範囲または等式検索を行う場合

• 時刻列などが一般的

31

32

SORTKEYの例

• orderdate 列をSORTKEY に指定した場合：

2016/07/17

2016/07/18

2016/07/18

2016/07/19

…

I0001

I0002

I0003

I0004

・・・

2016/08/20

2016/08/21

2016/08/22

2016/08/22

…

I0020

I0021

I0022

I0023

orderdate…orderid

SELECT * FROM orders WHERE

orderdate BETWEEN ‘2016-08-01’ AND

‘2016-08-31’;

クエリで必要なデータが固まっているためディスクアクセス回数が減少

33

ジョインを最適化するための分散方式

ALL

Node 1

Slice 1 Slice 2

Node 2

Slice 3 Slice 4

全ノードにデータをコピー

KEY(DISTKEY)

Node 1

Slice 1 Slice 2

Node 2

Slice 3 Slice 4

同じキーを同じ場所に

Node 1

Slice 1 Slice 2

Node 2

Slice 3 Slice 4

EVENラウンドロビンで均一分散（※デフォルト）

CREATE TABLE t(…)

DISTSTYLE { EVEN | KEY | ALL }

34

分散方式＝DISTKEYでコロケーションを実現

6200995 | almond pale linen | Manufacturer#3| Brand#32

part

lineitem

5024338535 | 6200995 | 0.01 |0.08 | A | F |1992-01-02 | 1992-02-14

2201039 | almond pale linen | Manufacturer#1| Brand#11

part

lineitem

121932093 | 2201039 | 0.05 |0.43 | D | E |1994-07-11 | 1994-08-23

35

分散方式＝ALLでコロケーションを実現

part

lineitem

part

lineitem

l_partkey l_partkey

p_partkey p_partkey

更新：全ノードにレプリケーションクエリー：ジョインはローカルで完結

36

一般的なテーブル設計例

履歴テーブルマスターテーブル1

マスターテーブル2

マスターテーブル3

sortkey

distkey

distkey diststyle:all

diststyle:even

スタースキーマ WHERE句で使用するカラム=sortkey例）Timestamp

一番大きいマスターテーブルとのJOINで使用するカラム=distkey例）商品コード

小さいマスターテーブル=diststyle:all

37

より高度な設計：表設計以外の部分

①更新やマージ処理をより高速に実行

②ジョインの高速化と安定化

③ある程度はOLTP的なアクセスを捌く

④より高い可用性の担保

38

①更新の高速化：データの挿入はS3から一括で

S3に保存してから一括ロードが基本– COPYコマンドでS3から高速ロード

– 元データを圧縮し、分割しておく事で高速化

– INSERT等DMLで実行する事も可能

• COMMITの回数を抑えることが高速化のポイント

39

更新の高速化（続き）：ユニーク制約とMERGE

• ユニーク制約への対応– ユニーク制約やPKはあり、オプティマイザーが利用しますが、デー

タのユニーク性は担保しません– 一時表にロードして、INSERT … SELECT DISTINCT …

• MERGE（UPSERT）したい場合– ①一時表にデータをロード– ②元表との差集合を残して削除– ③一時表のデータをINSERThttps://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_best-practices-upsert.html

40

②ジョインの高速化と安定化

ジョインの安定化は大規模環境での速度安定化の鍵

• DISTKEYは表に１つのみ

→基本は「最も良くジョインで利用される列へ」

→用途別にコピー表を作成する方法も検討

• そもそもジョインをさせない設計

→ジョイン済表、大福帳スキーマ

41

③ある程度はOLTP的な応答を確保する

• 重い（バッチ的な）処理が、一般ユーザへのクエリ応答速度を阻害しているケース⇒RedshiftのWorkload Management (WLM)を活用する

• どうしてもSQLを並列に多く実行したいケース⇒Redshift以外のRDBへオフロードする

42

Workload Management（WLM）を活用する

• デフォルトでは５並列までに設定されている– 長時間実行するクエリが多いと待たされ

る可能性

• 最大50並列だが並列度を増やしても速度が上がるとは限らない– 最大でも15並列が推奨

• 並列度を上げる代わりに、キューを分ける

SQL

デフォルト・キュー

実行中（５並列） ウエイト

SQL SQL SQL SQL

⑤並列SQL

43

WLMで待ち行列をコントロールし、適切なサービスレベルを提供する

BIユーザ

Long

Query Group

5並列2並列

Short

Query Group

バッチクエリユーザ

タイムアウト＝120秒

タイムアウト＝∞

タイムアウトのクエリを転送

44

全データ

キャッシュ

高いSQL並列実行性を実現させるために、他RDBへオフロードする

• 例）ホットなデータを他RDBにオフロード– PgSQLからはdblink機能でRedshiftのデータにアクセスが可能

– マテリアライズド・ビューでデータをPgSQL側にキャッシュ

– REFRESHで更新

（※こちらに解説があります）

http://aws.typepad.com/sajp/2016/06/join-amazon-redshift-and-amazon-rds-postgresql-with-dblink.html

dblink

RDS/PgSQL Redshift

CREATE MATERIALIZED VIEW

REFRESH MATERIALIZED VIEW

45

④可用性の担保

• クラウドではノード単体の可用性の考え方が変わる

• Redshiftではノード障害の発見、新ノードでの復帰がビルトイン

• ノードの障害は自動的にリカバー

• 複数ノードの多重同時障害が発生した場合にもスナップショットからのリストアが実行される

新ノードでリスタート

大量のリソース

46

AZ #2

より高い可用性の担保

• より高い可用性を担保する場合はマルチAZ構成

• データセンター全体の障害に対応可能• RDSは数クリックでマルチAZ化

可能

• DWHにどこまでの可用性が必要か？は要検討 AZ #1

Auto Scaling group

47

Redshift＋マルチAZ環境の実現

案）大小２つのRedshiftクラスター

①：1年分データ

HDDでバイト単位のコスト重視

②：ホットデータ（１ヶ月）

SSDで速度重視、サイズを小さく

メリット

②を小さく、コスト最適化

メンテナンスウィンドウを個別に設定可能。表設計も個別に最適化可能

どちらのAZに大きな障害が発生して常にホットデータにアクセス可能

AZ #2AZ #1

S3

HDD

１ヶ月分のデータ

１年間分のデータ

① ②

48

まとめ

49

まとめ

• クラウド上のDWHメリット– 「ちょっと試してみて、無理ならやめる」が可能

– 運用管理の大幅な負荷減

• 移行時には既存RDBとのアーキテクチャ比較を実施

• 性能を引き出すには適切な設計が鍵– 適切なサービスを適切なワークロードに適用する