[レポート]Amazon Redshift の設計・運用大原則 #AWSSummit

AWS Summit 2018 Tokyo

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2018年5月30日(水)〜2018年6月1日(金)の3日間にわたり、 品川にて開催されておりますAWS Summit Tokyo 2018

こちらで講演されたセッション「Amazon Redshift の設計・運用大原則」を聴講しましたのでレポートします。

概要

Amazon Redshift は、高速で完全マネージド型のデータウェアハウス(DWH)です。Redshift により、DWH のローカルディスクに保存されたデータや、Amazon S3 上にある膨大な量の非構造化データに対して、簡単に分析クエリを実行することができます。本セッションでは、Redshift および S3 を活用してクラウド上にデータウェアハウスシステムを構築する上で、意識すべき設計と運用のポイントについてご説明します。

スピーカー

  • 仲谷 岳志
    • アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス シニア・インフラストラクチャー・アーキテクト

※敬称略

レポート

  • Amazon Redshiftおさらい
    • カラムナーと超並列処理(MPP)を特徴とするDWHエンジン
      • 大量データの高速処理に特価
    • 簡単に始められ、拡張性に優れる
      • 最小1ノード/160GB、最大128ノード/2PB
    • 常に進化し続ける
      • 月1〜2回ペースでアップデート
    • 高度なデータセキュリティ
      • プライベートアクセスや自由なポート制御
      • サーバサイド暗号化、通信暗号化
    • AWSサービスとの強固な連携
      • S3を介した高速ロード/アンロード
      • S3オブジェクトへの直接クエリー
    • 多彩なクエリー支援機能
      • ワークロード管理(WLM)
      • クエリーモニタリングルール(QMR)
      • ショートクエリーアクセラレーション(SQA)
      • 結果セットキャッシュ(RSC)
  • Redshiftをよりよく使うための8の現場経験則
    • サイジングをちゃんとする
      • 設計段階である程度シュアなサイジングを行う
      • 初期容量のみでサイジングしない
      • 可能な場合は大きめのノードサイズを選択する
    • Spectrumのアーキ原則を押さえる
      • パーティション、列指向ファイルフォーマットを活用する
        • とにかく「読み取り量を減らす」
      • データ量に応じたノードスライス数を用意する
      • データの持ち方を工夫する
    • COPYの基本ルールを守る
      • 1COPYで複数ファイルを並列ロードする
        • COPYコマンド自体を多重実行しない
        • ノードスライス数の倍数に揃える
        • ファイルは圧縮しm,ファイルサイズはそれぞれ数百MB〜1GBとる
      • 可能な場合は常にS3からロードする
      • 一意制約の特性(重複は許容される)を理解する
      • エラーハンドリングを実装する
    • ロード経路をセキュアにする
      • COPY元のS3にはVPCエンドポイント経由でアップロードする
      • バケットポリシーとAWS ConfigでS3のパブリック化を防ぎ、かつGuardDutyで不正な漏出を検知する
    • 同時実行要件に正しく対処する
      • 実測する
        • 15という参考数値はあるがあくまで目安
        • むやみにスロットを増やすとスループットが下がる可能性がある
        • 逆に15以上で問題ないケースもある
      • 「現行システム要件」の実態を見極める
      • 本当に多数の同時実行クエリー数が必要な場合は、スロット細分化以外の方法を考える
    • クエリー特性を考慮する
      • スループット重視のバッチとレスポンス重視の対話クエリーはキューを分ける
      • 探索的クエリーなどのロングクエリー/ローグクエリーが想定される場合はクエリーモニタリングルールで予防線を張る
      • BIツールからの定型クエリーに対する備えをする
    • VACUUMを工夫する
      • VACUUMを実行しないで済むように設計する
        • VACUUM不要なスキーマにする
        • 更新や削除を極力なくす
      • それでも必要な場合は・・・
        • VACUUM FULLで実行する
        • カラム数が数百に及ぶテーブルは、実行時に複数スロットを割り当てる
        • VACUUMの代わりにディープコピーを使うことも考慮する
    • 更新処理を工夫する
      • Redshiftは大容量データの集計・分析処理に最適化されており、ランダムな更新処理や一件ごとのループ処理には適さない
      • 更新自体を回避するパターン
        • 更新・削除が頻発するテーブルでは、テーブルを丸ごと入れ替える「洗い替え」を検討する
      • 更新を効率化するパターン
        • 一時テーブルを活用したUPSERT処理など、極力まとまった単位での更新方式を実装する
  • まとめ
    • Amazon Redshiftは2012年の登場以来、S3を始めとするAWSサービス郡と共に進化を重ねてきたクラウド型DWH
    • DWHである以上、設計・運用に際してはベストプラクティスやアンチパターンに留意することが望ましい
    • ポイントを押さえておくことで、従来型DWHとの互換性とクラウドの恩恵を両立することが可能

さいごに

Redshiftの現場経験則を知れる貴重なセッションでした。
Redshiftを構築する際は、この「8の現場経験則」を意識して構築したいと思います!