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

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コマンド自体を多重実行しない
      • ノードスライス数の倍数に揃える
      • ファイルは圧縮しｍ，ファイルサイズはそれぞれ数百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の現場経験則」を意識して構築したいと思います！