Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)
15 likes8,054 views
2016/07/15のdb tech showcase講演資料です。
![[AKIBA.AWS] VPCをネットワーク図で理解してみる](https://cdn.slidesharecdn.com/ss_thumbnails/akibaaws5vpc-design-180419110936-thumbnail.jpg?width=560&fit=bounds)
![[PGConf.ASIA 2018]Deep Dive on Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20181212pgconfasiaaurorapostgresql-181212055637-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016) (20)
![[db tech showcase OSS 2017] A22: NoSQL：誰のための、何のためのデータベース？その将来は？by Aerospike, ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbtechshowcaseoss2017aerospike-170621081031-thumbnail.jpg?width=560&fit=bounds)
Ad
More from Amazon Web Services Japan (20)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=560&fit=bounds)
Ad
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 が起動 • バックアップやモニ タリングといった運 用機能を含む
- 8. 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. 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 移行時の検討ポイント
- 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をサポート
- 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
- 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
- 41. 41 ③ある程度はOLTP的な応答を確保する • 重い（バッチ的な）処理が、一般ユーザへのク エリ応答速度を阻害しているケース ⇒RedshiftのWorkload Management (WLM)を活用する • どうしてもSQLを並列に多く実行したいケース ⇒Redshift以外のRDBへオフロードする
- 42. 42 Workload Management（WLM）を活用する • デフォルトでは５並列までに設 定されている – 長時間実行するクエリが多いと待たされ る可能性 • 最大50並列だが並列度を増やし ても速度が上がるとは限らない – 最大でも15並列が推奨 • 並列度を上げる代わりに、 キューを分ける SQL デフォルト・キュー 実行中（５並列） ウエイト SQL SQL SQL SQL ⑤並列 SQL
- 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とのアーキテクチャ比較を実施 • 性能を引き出すには適切な設計が鍵 – 適切なサービスを適切なワークロードに適用する