Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)

1. 1 Amazon Redshiftへの移行方法と設計のポイント 2016年7月15日アマゾンウェブサービスジャパンソリューションアーキテクト下佐粉昭（しもさこあきら） @simosako Follow me!

2. 2 内容 • データウェアハウス構築の課題 • Amazon Redshiftの基本構造 • 移行時の検討ポイント • 設計のポイント • まとめ

3. 3 データウェアハウス構築の課題 • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ＆リストア – モニタリング

4. 4 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ＆リストア – モニタリング AWSクラウド • 初期投資不要 • 利用分だけの支払い • 安価 • いつでもやめられる

5. 5 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ＆リストア – モニタリング AWSクラウド • 数クリックでDWH が起動 • バックアップやモニタリングといった運用機能を含む

6. 6 Amazon Redshiftの基本構造

7. 7 DWH特化の大規模RDB ペタバイト級までスケールアウトフルマネージド高い汎用性;PgSQL互換性 $1,000/TB/年; 最小$0.314/時から Amazon Redshift より速くよりシンプルにより安価に ※費用は2016年7月時点での東京リージョンのものです

9. 9 大規模DWHを実現するための構造 • スケールアウト可能な設計 – 1つのSQLを複数ノードでパラレルに処理する設計 – ノードを増やすことでパフォーマンスと容量が増加 • ディスクIOを削減する機能を搭載 – ディスクIOがデータベースの一番のボトルネック

10. 10 スケールアウト可能な構成① SELECT * FROM lineitem; リーダーノードがクライアントからSQLを受け取る CPU CPU CPU CPU CPU CPU Leaderノード Computeノード１つの表を各ノードのストレージに分散して保存 Table A Table B

11. 11 スケールアウト可能な構成② SELECT * FROM lineitem; SQLをコンパイル、コードを生成し、コンピュートノードへ配信 CPU CPU CPU CPU CPU CPU Leaderノード Computeノードスライス（論理的な処理単位）ごとに並列処理

12. 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. 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. 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. 15 最も大きな価値は、利用に集中できる環境 • 数クリックでDWHが起動 • バックアップは自動的にS3へ • モニタリング機能を内蔵 • パッチ適用も自動化運用ではなく利用にフォーカス

16. 16 待機系や開発系への考え方が変わる • 開発や検証のRedshiftは常時不要 – 必要な時にスナップショット（バックアップ）から作成すれば良い • インスタンスタイプやノード数は変えられる – リサイズ機能で変更可能 – リサイズ中は読み取りアクセス可能 • 開発系だからといって小さいサイズで利用しない – 本番のスナップショットから、本番と同じサイズのクラスターで

17. 17 移行時の検討ポイント

18. 18 既存DWHのRedshift移行検討フローアーキテクチャの比較対応機能があるか確認、代替機能の検討分散キー等データ配置の最適化検討データ型のマッピングデータ移行する場合は、データ移行方式の検討 PoCの実施アプリケーションの見直し、移行方式検討移行判断

19. 19 アーキテクチャの確認ポイント • 移行前のRDBはDWH特化か、通常のRDBか – DWH特化の環境からだと比較的特徴が近いケースが多い – 汎用（通常の）RDBからの場合は、Redshiftに適したワークロードかを確認 Redshift（DWH特化）汎用型RDBMS データストアカラムナ（列指向）行指向アクセス単位 1MB（粒度が大きい） 2KB～32KB（粒度が細かい）高速化手法スケールアウト（MPP）スケールアップデータ検索圧縮、ゾーンマップインデックスデータロード大容量データの一括ロードに特化小規模の並列更新にも対応

20. 20 Redshiftに適したワークロードか？ • Redshiftは１つのクエリをいかに速く処理させるかを重視して設計されたデータベース • Redshiftに向くワークロード – 巨大なデータ・セット（数百GB～ペタバイト） – １つ１つのSQLが複雑 – 同時実行SQLは少ない – データの更新は一括更新が多い

21. 21 Redshift以外を検討すべきワークロード • 並列クエリ数が多い（※並列接続数ではなくクエリの並列実行数） • 極めて短いレーテンシが必要 • 非定形データの処理 • RDS (RDB) • DynamoDB (NoSQL) • ElastiCache (インメモリ） • Elastic MapReduce （Hadoop） • ETLツール＋EC2

22. 22 機能の確認ポイント • 利用している機能がRedshiftでも使えるかを確認 • 使えない場合は代替方法を検討機能 Redshift SQL 一般的なANSI SQL（PgSQLと高い互換性）接続プロトコル ODBCとJDBC(PgSQLプロトコル互換）ユーザ定義関数 PythonによるスカラーUDF ストアドプロシージャ（未対応）別途外部アプリケーションで対応半構造化データ読み取り JSONに対応マテリアライズド・ビュー（未対応）別途マート表の作成等で対応シーケンス列 Identityをサポート

23. 23 アプリケーションの見直し Redshift 基幹業務アプリ DWH 分析ソフトウェア分析プログラム現状調査基幹業務を分離し分析に特化させる分析ソフトウェアの Redshift対応確認基幹業務アプリ RDS 分析プログラムの言語確認、 SQLでDBMS依存の関数等使っていないか調査適材適所なDBを使い、データ配置を変えられるか対応していない分析ソフトの見直し可能か DWH利用システム（アクセス元）の洗い出し必要であれば、分析プログラムの修正、 SQLの修正、テストが可能か分析ソフト分析プログラム PoCを計画する必要タスクの洗い出し

24. 24 型のマッピング • 現利用RDBとRedshiftの型（以下）をマッピングする • 注意点 – charはシングルバイトのみサポート – varcharはUTF-8形式でのマルチバイトをサポート参照） http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_unsupported-postgresql-datatypes.html

25. 25 データの移行（転送） • 初期データの転送 – ネットワーク転送 • AWS Database Migration Service – 物理デバイスを活用した転送 • AWS Import/Export Snowball • 日々の更新データ転送 – ネットワーク転送 • 日々発生するデータサイズと回線帯域から適切な転送方法を検討する

26. 26 移行を支援するためのAWSサービス Database Migration Service – 異機種RDBMS間でデータ移行を支援するサービス – データを型変換しながらコピー – 低負荷の差分レプリケーション – マルチAZ構成 Schema Conversion Tool – 異機種RDBMS間のスキーマ（DDL)変換を支援 – 表、ビュー、トリガー、プロシージャ等 – ソースコード（Java, C#, 埋め込みC）の中にあるDDLの変換も支援

27. 27 プライベートネットワークを構築 • Virtual Private Cloud（VPC）でプライベートなネットワーク領域を作成し、既存環境と接続するＡＷＳクラウド VPC イントラインターネットプライベートサブネット分離したNW 領域を作成インターネット VPN接続 (IPSec) パブリックサブネットインターネットゲートウェイ仮想サーバ (EC2) DBサービス(RDS)専用線接続 Direct Connect

28. 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. 29 設計のポイント

30. 30 テーブル設計・データ配置 • DWHではスタースキーマやスノーフレークスキーマが一般的。Redshiftに適している • DISTKEYやSORTKEYをうまく設定することでスタースキーマでの速度を最適化可能 • QUERY実行時の負荷とロード時の負荷のバランスを見て最適なテーブル設計とする

31. 31 SORTKEYでディスクアクセスを最小にする • SORTKEY – SORTKEYに応じて、ディスク上にデータが順序を守って格納 – オプティマイザはソート順序を考慮し、最適なプランを構築 – CREATE TABLE時に指定 • CREATE TABLE t1(…) SORTKEY (c1, …) • SORTKEYの使いどころ – 頻繁に特定のカラムに対して、範囲または等式検索を行う場合 • 時刻列などが一般的 31

32. 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. 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. 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. 35 分散方式＝ALLでコロケーションを実現 part lineitem part lineitem l_partkey l_partkey p_partkey p_partkey 更新：全ノードにレプリケーションクエリー：ジョインはローカルで完結

36. 36 一般的なテーブル設計例履歴テーブルマスターテーブル1 マスターテーブル2 マスターテーブル3 sortkey distkey distkey diststyle:all diststyle:even スタースキーマ WHERE句で使用するカラム=sortkey 例）Timestamp 一番大きいマスターテーブルとのJOINで使用するカラム =distkey 例）商品コード小さいマスターテーブル=diststyle:all

37. 37 より高度な設計：表設計以外の部分 ①更新やマージ処理をより高速に実行 ②ジョインの高速化と安定化 ③ある程度はOLTP的なアクセスを捌く ④より高い可用性の担保

38. 38 ①更新の高速化：データの挿入はS3から一括で S3に保存してから一括ロードが基本 – COPYコマンドでS3から高速ロード – 元データを圧縮し、分割しておく事で高速化 – INSERT等DMLで実行する事も可能 • COMMITの回数を抑えることが高速化のポイント

39. 39 更新の高速化（続き）：ユニーク制約とMERGE • ユニーク制約への対応 – ユニーク制約やPKはあり、オプティマイザーが利用しますが、データのユニーク性は担保しません – 一時表にロードして、INSERT … SELECT DISTINCT … • MERGE（UPSERT）したい場合 – ①一時表にデータをロード – ②元表との差集合を残して削除 – ③一時表のデータをINSERT https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_best- practices-upsert.html

40. 40 ②ジョインの高速化と安定化ジョインの安定化は大規模環境での速度安定化の鍵 • DISTKEYは表に１つのみ →基本は「最も良くジョインで利用される列へ」 →用途別にコピー表を作成する方法も検討 • そもそもジョインをさせない設計 →ジョイン済表、大福帳スキーマ

41. 41 ③ある程度はOLTP的な応答を確保する • 重い（バッチ的な）処理が、一般ユーザへのクエリ応答速度を阻害しているケース ⇒RedshiftのWorkload Management (WLM)を活用する • どうしてもSQLを並列に多く実行したいケース ⇒Redshift以外のRDBへオフロードする

42. 42 Workload Management（WLM）を活用する • デフォルトでは５並列までに設定されている – 長時間実行するクエリが多いと待たされる可能性 • 最大50並列だが並列度を増やしても速度が上がるとは限らない – 最大でも15並列が推奨 • 並列度を上げる代わりに、キューを分ける SQL デフォルト・キュー実行中（５並列）ウエイト SQL SQL SQL SQL ⑤並列 SQL

43. 43 WLMで待ち行列をコントロールし、適切なサービスレベルを提供する BIユーザ Long Query Group 5並列2並列 Short Query Group バッチクエリユーザタイムアウト＝120秒タイムアウト＝∞ タイムアウトのクエリを転送

44. 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. 45 ④可用性の担保 • クラウドではノード単体の可用性の考え方が変わる • Redshiftではノード障害の発見、新ノードでの復帰がビルトイン • ノードの障害は自動的にリカバー • 複数ノードの多重同時障害が発生した場合にもスナップショットからのリストアが実行される新ノードでリスタート大量のリソース

46. 46 AZ #2 より高い可用性の担保 • より高い可用性を担保する場合はマルチAZ構成 • データセンター全体の障害に対応可能 • RDSは数クリックでマルチAZ化可能 • DWHにどこまでの可用性が必要か？は要検討 AZ #1 Auto Scaling group

47. 47 Redshift＋マルチAZ環境の実現案）大小２つのRedshiftクラスター  ①：1年分データ  HDDでバイト単位のコスト重視  ②：ホットデータ（１ヶ月）  SSDで速度重視、サイズを小さく  メリット  ②を小さく、コスト最適化  メンテナンスウィンドウを個別に設定可能。表設計も個別に最適化可能  どちらのAZに大きな障害が発生して常にホットデータにアクセス可能 AZ #2AZ #1 S3 HDD １ヶ月分のデータ１年間分のデータ ① ②

48. 48 まとめ

49. 49 まとめ • クラウド上のDWHメリット – 「ちょっと試してみて、無理ならやめる」が可能 – 運用管理の大幅な負荷減 • 移行時には既存RDBとのアーキテクチャ比較を実施 • 性能を引き出すには適切な設計が鍵 – 適切なサービスを適切なワークロードに適用する

Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)

Amazon Web Services Japan

Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)