[レポート] Amazon Redshiftにおけるパフォーマンスと伸縮性 #ANT416 #reinvent

こんにちは！DA事業本部の大高です！現地ラスベガスがらお送りします。

本記事はAWS re:Invent 2019のセッションレポートとなります。

概要

This session dives deep into the capabilities of Amazon Redshift. See how Amazon Redshift achieves its state-of-the-art performance and learn about all aspects of elasticity, from the compute and data elasticity within a single cluster to elasticity across multiple clusters.

このセッションでは、Amazon Redshiftの機能について詳しく説明します。 Amazon Redshiftが最先端のパフォーマンスをどのように達成するかを確認し、単一クラスター内のコンピューティングとデータの伸縮性から複数のクラスターにわたる伸縮性まで、伸縮性のあらゆる側面について学びます。

また、本セッションはチョークトークセッション（少人数でのディスカッション形式）で、リピートセッションの「ANT416-R1」となります。

スピーカー

スピーカーは以下の方々になります。

• Thanos Papathanasiou - Principal Engineer, Amazon Web Services
• Yuval Pemper - SVP Engineering, Innovid

セッションの流れ

まずはThanosさんから「Redshiftのパフォーマンスと伸縮性について」、その次にInnovid社のYuvalさんから「具体的なRedshiftの利用事例の紹介」がありました。

そのあとは、出席者とのQA形式で進む形となります。

Performance and elasticity in Amazon Redshift

まずはThanoさんによるセッションです。

Amazon Redshiftのアーキテクチャ

• クラウドネイティブな分散データアーキテクチャ
• リーダーノードとコンピュートノード
  • リーダーノードはコネクション、カタログ、実行計画を管理する
  • コンピュートノードはデータと処理実行を担当する
• 分散クエリ処理
  • テーブルデータはコンピュートノードを横断してパーティショニングされる
  • テーブルアクセスは分散される

伸縮性の要求

• 統一性のない、または、予測不可能なワークロードパターン
  • ピークとアベレージの隔たり
  • ピークに合わせてプロビジョニングした場合は、コストがかかる
• コンピュートとストレージは独立性を求められる
  • コンピュートスケーリング: 高いクエリコンカレンシーを制御
  • ストレージスケーリング: データを保持し、保持ポリシーと監査要件に準拠する
  • ストレージをコンピュートから切り離し、独立してスケーリングする
• ユーザは必要な時だけ支払いをする

２つのコンピュート伸縮性

• Elasticリサイズ：ノード数を増減してスケール
• コンカレンシー スケーリング: 複数のクラスタへスケールアウト

エラスティック リサイズを用いたコンピュートの伸縮性

• インプレース
  • 既存クラスタへの追加、または、削除
• スケールアウト
  • パフォーマンスに比例したスケーリング
• 高速
  • 数分で完了
  • 限定的なセッション、クエリへの影響

コンカレンシー スケーリングを用いたコンピュートの伸縮性

• 単一のエンドポイントから複数のRedshiftクラスタへのスケールアウト
• 秒単位でのスケール
• 追加クラスタ料金は秒単位での課金
• 日次で、1時間の無料利用枠

2つのストレージ伸縮性

• Spectrum
  • S3上のオープンなデータフォーマットファイルへのクエリ
• Amazon Redshift マネージドストレージ
  • 分析に最適化されたストレージレイヤ

Amazon Redshift Spectrumを利用したストレージの伸縮性

• 数千ノードを利用したS3への直接クエリ
• オープンファイルフォーマット
• コンピューテーションのプッシュダウン

Amazon Redshift マネージドストレージを利用したストレージの伸縮性

• トランザクション機能と、大規模なデータセットに対する効率的なRedshiftフォーマット
• ストレージプロビジョニング
  • ローカルストレージに格納されるよりも、より多くのデータを収集・分析
• ローカルにアタッチされるストレージよりもパフォーマンスの向上
  • ホットなデータをローカルに保持
• データの利用頻度をトラッキング
  • システムは利用頻度と最近のアクセスからホットデータをランキングする

InnovidにおけるRedshiftのコンカレンシー スケーリング

次に、Innovid社の具体的に利用しているコンカレンシー スケーリングについての話です。

具体的なユースケース

• 日に5億以上のイベントを処理
• 主にSpark EMRクラスタを利用した処理
• ビジネスロジックレイヤはRedshiftで実装

商用環境の構成

環境としては、図にあるように統計データを「本番環境」と「テスト環境」の両方にロードしているとのことです。

具体的なテスト結果について

テストとして、以下にあるような評価軸とクエリタイプでテストした結果の説明です。

ショートクエリとミディアムクエリ、それぞれのパターンの結果です。

ショートクエリの場合、ほとんど効果的な差は見られません。

一方で、ミディアムクエリの場合には、スケーリングを有効にすることで明確な差がうまれています。

さらに、より現実的なテストとして混ぜたパターンのテストです。

少しでこぼこしますが、トータルとしてはスケーリングを行ったほうが良いパフォーマンスが出ることが見て取れます。

こちらはパフォーマンスのメトリクスです。

下のグラフにあるように長いクエリを実行している時に、上のグラフで読み取れる通り、自動でコンカレンシースケーリングがうまく走っている様子が伺えます。

重要なポイント

以上を踏まえた上で、どう利用すべきかのまとめです。スケールアウトの指針として、以下が参考になりますね。

• スケールアウトはミディアム、または、ロングクエリに有効
• 以下におすすめ
  • ピークタイム
  • サービスレベルの維持
  • 想定されるユーザ数の増加
• 非推奨
  • ロードのほとんどが書き込み
  • ショートクエリが多い
  • コンスタントなロード

チョークトーク

ここからは、出席者とのQAとなりました。

Q. どれぐらいコンカレンシースケーリングは増やせるのか？
A. 10が最大となる

Q. Redshiftにおける可用性はどう担保しているか？（Innovid社のYuvalさんへ
A. クロスリージョンのスナップショットや、先ほどの複数環境をもつことで、すぐに復旧できるようにしている。

Q. コンカレンシースケーリングのデータはどこから持ってくるのか？
A. S3からデータ取得している

Q. 設定はどのようにすればよいのか？WLMにも設定がいるのか？
A. WLMの設定は不要。ピークタイムが分かっているのなら、スケジュールでエラスティックリサイズすると良い。コンカレンシースケーリングは自動にする。なお、手動で設定したい場合はコンソールから設定もできる。

まとめ

以上、「Amazon Redshiftにおけるパフォーマンスと拡張性」のレポートでした。

講義自体は短く、参加者とのQAを多くとるチョークトーク形式のセッションに始めて参加しましたが、講演者と参加者の距離が近くて、面白いセッションでした。なかなか英語を聞き取るのに苦労したので、もう少し英語力を付けて自分でも質問できるようになりたいと思ったセッションでもありました。

それでは、また！