Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)
•
15 gefällt mir•8,015 views
2016/07/15のdb tech showcase講演資料です。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016)
Ähnlich wie Amazon Redshiftへの移行方法と設計のポイント(db tech showcase 2016) (20)
Mehr von Amazon Web Services Japan
Mehr von Amazon Web Services Japan (20)
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とのアーキテクチャ比較を実施 • 性能を引き出すには適切な設計が鍵 – 適切なサービスを適切なワークロードに適用する