Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

6,698 views

Published on

2016/07/15のdb tech showcase講演資料です。

Published in: Data & Analytics
  • Be the first to comment

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

  1. 1. 1 Amazon Redshiftへの移行方法と設計のポイント 2016年7月15日 アマゾン ウェブ サービス ジャパン ソリューションアーキテクト 下佐粉 昭(しもさこ あきら) @simosako Follow me!
  2. 2. 2 内容 • データウェアハウス構築の課題 • Amazon Redshiftの基本構造 • 移行時の検討ポイント • 設計のポイント • まとめ
  3. 3. 3 データウェアハウス構築の課題 • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ&リストア – モニタリング
  4. 4. 4 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ&リストア – モニタリング AWSクラウド • 初期投資不要 • 利用分だけの支払い • 安価 • いつでもやめられる
  5. 5. 5 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築・維持 – バックアップ&リストア – モニタリング AWSクラウド • 数クリックでDWH が起動 • バックアップやモニ タリングといった運 用機能を含む
  6. 6. 6 Amazon Redshiftの基本構造
  7. 7. 7 DWH特化の大規模RDB ペタバイト級までスケールアウト フルマネージド 高い汎用性;PgSQL互換性 $1,000/TB/年; 最小$0.314/時から Amazon Redshift より速く よりシンプルに より安価に ※費用は2016年7月時点での東京リージョンのものです
  8. 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. 9 大規模DWHを実現するための構造 • スケールアウト可能な設計 – 1つのSQLを複数ノードでパラレルに処理する設計 – ノードを増やすことでパフォーマンスと容量が増加 • ディスクIOを削減する機能を搭載 – ディスクIOがデータベースの一番のボトルネック
  10. 10. 10 スケールアウト可能な構成① SELECT * FROM lineitem; リーダーノードがクライア ントからSQLを受け取る CPU CPU CPU CPU CPU CPU Leaderノード Computeノード 1つの表を各 ノードのスト レージに分散し て保存 Table A Table B
  11. 11. 11 スケールアウト可能な構成② SELECT * FROM lineitem; SQLをコンパイル、 コードを生成し、コン ピュートノードへ配信 CPU CPU CPU CPU CPU CPU Leaderノード Computeノード スライス(論理的な処理 単位)ごとに並列処理
  12. 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. 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. 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. 15 最も大きな価値は、利用に集中できる環境 • 数クリックでDWHが起動 • バックアップは自動的にS3へ • モニタリング機能を内蔵 • パッチ適用も自動化 運用ではなく利用にフォーカス
  16. 16. 16 待機系や開発系への考え方が変わる • 開発や検証のRedshiftは常時不要 – 必要な時にスナップショット(バックアップ)から作成すれば良い • インスタンスタイプやノード数は変えられる – リサイズ機能で変更可能 – リサイズ中は読み取りアクセス可能 • 開発系だからといって小さいサイズで利用しない – 本番のスナップショットから、本番と同じサイズのクラスターで
  17. 17. 17 移行時の検討ポイント
  18. 18. 18 既存DWHのRedshift移行検討フロー アーキテクチャの 比較 対応機能があるか 確認、 代替機能の検討 分散キー等 データ配置の 最適化検討 データ型の マッピング データ移行する 場合は、 データ移行方式 の検討 PoCの実施 アプリケーションの 見直し、 移行方式検討 移行判断
  19. 19. 19 アーキテクチャの確認ポイント • 移行前のRDBはDWH特化か、通常のRDBか – DWH特化の環境からだと比較的特徴が近いケースが多い – 汎用(通常の)RDBからの場合は、Redshiftに適したワークロードかを確認 Redshift(DWH特化) 汎用型RDBMS データストア カラムナ(列指向) 行指向 アクセス単位 1MB(粒度が大きい) 2KB~32KB(粒度が細かい) 高速化手法 スケールアウト(MPP) スケールアップ データ検索 圧縮、ゾーンマップ インデックス データロード 大容量データの一括ロードに 特化 小規模の並列更新にも対応
  20. 20. 20 Redshiftに適したワークロードか? • Redshiftは1つのクエリをいかに速 く処理させるかを重視して設計され たデータベース • Redshiftに向くワークロード – 巨大なデータ・セット(数百GB~ペタバイト) – 1つ1つのSQLが複雑 – 同時実行SQLは少ない – データの更新は一括更新が多い
  21. 21. 21 Redshift以外を検討すべきワークロード • 並列クエリ数が多い (※並列接続数ではなくクエ リの並列実行数) • 極めて短いレーテンシ が必要 • 非定形データの処理 • RDS (RDB) • DynamoDB (NoSQL) • ElastiCache (インメモリ) • Elastic MapReduce (Hadoop) • ETLツール+EC2
  22. 22. 22 機能の確認ポイント • 利用している機能がRedshiftでも使えるかを確認 • 使えない場合は代替方法を検討 機能 Redshift SQL 一般的なANSI SQL(PgSQLと高い互換性) 接続プロトコル ODBCとJDBC(PgSQLプロトコル互換) ユーザ定義関数 PythonによるスカラーUDF ストアドプロシージャ (未対応)別途外部アプリケーションで対応 半構造化データ読み取り JSONに対応 マテリアライズド・ビュー (未対応)別途マート表の作成等で対応 シーケンス列 Identityをサポート
  23. 23. 23 アプリケーションの見直し Redshift 基幹業務 アプリ DWH 分析 ソフトウェア 分析 プログラム 現状調査 基幹業務を分離し 分析に特化させる 分析ソフトウェアの Redshift対応確認 基幹業務 アプリ RDS 分析プログラムの言語確認、 SQLでDBMS依存の関数等 使っていないか調査 適材適所なDBを使い、デー タ配置を変えられるか 対応していない 分析ソフトの見 直し可能か DWH利用システム (アクセス元)の洗い出し 必要であれば、分析 プログラムの修正、 SQLの修正、テスト が可能か 分析 ソフト 分析 プログラム PoCを計画する 必要タスクの洗い出し
  24. 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. 25 データの移行(転送) • 初期データの転送 – ネットワーク転送 • AWS Database Migration Service – 物理デバイスを活用した転送 • AWS Import/Export Snowball • 日々の更新データ転送 – ネットワーク転送 • 日々発生するデータサイズと回線帯域から適切な 転送方法を検討する
  26. 26. 26 移行を支援するためのAWSサービス Database Migration Service – 異機種RDBMS間でデータ移 行を支援するサービス – データを型変換しながらコ ピー – 低負荷の差分レプリケーショ ン – マルチAZ構成 Schema Conversion Tool – 異機種RDBMS間のスキーマ (DDL)変換を支援 – 表、ビュー、トリガー、プロ シージャ等 – ソースコード(Java, C#, 埋 め込みC)の中にあるDDLの 変換も支援
  27. 27. 27 プライベートネットワークを構築 • Virtual Private Cloud(VPC)でプライベートなネットワーク領域を 作成し、既存環境と接続する AWSクラウド VPC イントラ インターネット プライベート サブネット 分離したNW 領域を作成 インターネット VPN接続 (IPSec) パブリック サブネット インターネット ゲートウェイ 仮想サーバ (EC2) DBサービス(RDS)専用線接続 Direct Connect
  28. 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. 29 設計のポイント
  30. 30. 30 テーブル設計・データ配置 • DWHではスタースキーマやスノーフレーク スキーマが一般的。Redshiftに適している • DISTKEYやSORTKEYをうまく設定すること でスタースキーマでの速度を最適化可能 • QUERY実行時の負荷とロード時の負荷のバ ランスを見て最適なテーブル設計とする
  31. 31. 31 SORTKEYでディスクアクセスを最小にする • SORTKEY – SORTKEYに応じて、ディスク上にデータが順序を守って格納 – オプティマイザはソート順序を考慮し、最適なプランを構築 – CREATE TABLE時に指定 • CREATE TABLE t1(…) SORTKEY (c1, …) • SORTKEYの使いどころ – 頻繁に特定のカラムに対して、範囲または等式検索を行う場合 • 時刻列などが一般的 31
  32. 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. 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. 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. 35 分散方式=ALLでコロケーションを実現 part lineitem part lineitem l_partkey l_partkey p_partkey p_partkey 更新:全ノードにレプリケーション クエリー:ジョインはローカルで完結
  36. 36. 36 一般的なテーブル設計例 履歴テーブル マスターテーブル1 マスターテーブル2 マスターテーブル3 sortkey distkey distkey diststyle:all diststyle:even スタースキーマ WHERE句で使用す るカラム=sortkey 例)Timestamp 一番大きいマスター テーブルとのJOINで 使用するカラム =distkey 例)商品コード 小さいマスターテー ブル=diststyle:all
  37. 37. 37 より高度な設計:表設計以外の部分 ①更新やマージ処理をより高速に実行 ②ジョインの高速化と安定化 ③ある程度はOLTP的なアクセスを捌く ④より高い可用性の担保
  38. 38. 38 ①更新の高速化:データの挿入はS3から一括で S3に保存してから一括ロードが基本 – COPYコマンドでS3から高速ロード – 元データを圧縮し、分割しておく事で高速化 – INSERT等DMLで実行する事も可能 • COMMITの回数を抑えることが高速化のポイント
  39. 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. 40 ②ジョインの高速化と安定化 ジョインの安定化は大規模環境での速度安定化の鍵 • DISTKEYは表に1つのみ →基本は「最も良くジョインで利用される列へ」 →用途別にコピー表を作成する方法も検討 • そもそもジョインをさせない設計 →ジョイン済表、大福帳スキーマ
  41. 41. 41 ③ある程度はOLTP的な応答を確保する • 重い(バッチ的な)処理が、一般ユーザへのク エリ応答速度を阻害しているケース ⇒RedshiftのWorkload Management (WLM)を活用する • どうしてもSQLを並列に多く実行したいケース ⇒Redshift以外のRDBへオフロードする
  42. 42. 42 Workload Management(WLM)を活用する • デフォルトでは5並列までに設 定されている – 長時間実行するクエリが多いと待たされ る可能性 • 最大50並列だが並列度を増やし ても速度が上がるとは限らない – 最大でも15並列が推奨 • 並列度を上げる代わりに、 キューを分ける SQL デフォルト・キュー 実行中(5並列) ウエイト SQL SQL SQL SQL ⑤並列 SQL
  43. 43. 43 WLMで待ち行列をコントロールし、適切なサービスレ ベルを提供する BIユーザ Long Query Group 5並列2並列 Short Query Group バッチクエリユーザ タイムアウト =120秒 タイムアウト =∞ タイムアウトのクエリを転送
  44. 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. 45 ④可用性の担保 • クラウドではノード単体の可用性 の考え方が変わる • Redshiftではノード障害の発見、 新ノードでの復帰がビルトイン • ノードの障害は自動的にリカバー • 複数ノードの多重同時障害が発生 した場合にもスナップショットか らのリストアが実行される 新ノードで リスタート 大量のリソース
  46. 46. 46 AZ #2 より高い可用性の担保 • より高い可用性を担保する 場合はマルチAZ構成 • データセンター全体の障害 に対応可能 • RDSは数クリックでマルチAZ化 可能 • DWHにどこまでの可用性 が必要か?は要検討 AZ #1 Auto Scaling group
  47. 47. 47 Redshift+マルチAZ環境の実現 案)大小2つのRedshiftクラスター  ①:1年分データ  HDDでバイト単位のコスト重視  ②:ホットデータ(1ヶ月)  SSDで速度重視、サイズを小さく  メリット  ②を小さく、コスト最適化  メンテナンスウィンドウを個別に設定 可能。表設計も個別に最適化可能  どちらのAZに大きな障害が発生して常 にホットデータにアクセス可能 AZ #2AZ #1 S3 HDD 1ヶ月分の データ 1年間分の データ ① ②
  48. 48. 48 まとめ
  49. 49. 49 まとめ • クラウド上のDWHメリット – 「ちょっと試してみて、無理ならやめる」が可能 – 運用管理の大幅な負荷減 • 移行時には既存RDBとのアーキテクチャ比較を実施 • 性能を引き出すには適切な設計が鍵 – 適切なサービスを適切なワークロードに適用する

×