この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どーも、データアナリティクス事業本部コンサルティングチームのsutoです。
本エントリはAWS re:Invent 2022のセッション「ANT317 Self-service analytics with Amazon Redshift Serverless」のレポートです。
セッションの概要
Amazon Redshift Serverless lets you get started in seconds and run data warehousing and analytics workloads at scale, without worrying about data warehouse management. In this session, learn how Amazon Redshift automatically provisions data warehouse capacity and intelligently scales the underlying resources to deliver consistently high performance and simplified operations for even the most demanding and volatile workloads.
Amazon Redshift Serverlessを使用すると、データウェアハウスの管理を気にすることなく、数秒で開始し、データウェアハウスと分析ワークロードを大規模に実行することができます。このセッションでは、Amazon Redshiftがデータウェアハウスの容量を自動的にプロビジョニングし、基盤となるリソースをインテリジェントに拡張して、最も要求が高く不安定なワークロードに対しても一貫した高いパフォーマンスと簡素化された運用を提供する方法を学びます。
スピーカー
- Yan Leshinsky, Vice President, Amazon
- Rajendra Badisa, Sr. Solution Architect, Broadridge Financial Services
- Naresh Chainani, Director of Engineering, AWS
セッション内容
Self-service analytics with Amazon Redshift
- Redshiftがどのようなサービスを目指してきたのか
- Auroraに格納されるようなトランザクションデータや、ストリーミングデータなどあらゆるデータを分析できるようにする
- ETL処理を簡単に、データアクセスをセキュアかつ堅牢性高く（最近アップデートがあったAero-ETL、S3 Auto copy、行レベルアクセス制御などが例）
- 他のクラウドDWHサービスと比べて3倍以上のコストパフォーマンスを実現
- Redshift Serverlessはワークロードごとのスケーリングやパフォーマンスチューニング、メンテナンスなどが自動で、クエリを実行した時間の分だけの課金となる
- 同じJDBCインタフェースとSQL言語を使うため、従来のProvisionedクラスターからServerlessクラスターに移行するのも容易
- Serverlessはクエリの実行プランが短期間かつスパイクが起こるパターンのワークロードに適している
Simplifying analytics at Broadridge Financials
Broadridge Financials様の事例について
- 分析ランドスケープ全体で使用するサービスのリスト
- ポートフォリオパフォーマンス分析、PN分析、リスク分析、市場データ分析、取引ライフサイクル分析などを実現するソリューションを構築し、それを社内外の顧客に提供している
- 以前までのオンプレミス上で構築していたのセルフサービス分析の機能について
- 40TBのデータが蓄積
- ETLバッチ処理について重い計算とレポーティング
- 日中のユーザーとアプリケーションの使用率が大きく変動する
- 日々ユーザー分析データの履歴を集計しレポート生成
- 抱えた課題
- 複雑なクエリが発生した際のレスポンスが長くなってしまう
- データ量が増えたことによるデータ処理の難しさ
- インフラ環境を需要や季節的要因に合わせてスケーリングさせること
- データ量増加に伴うインフラのコストと運用保守の増加
- AWSサポートに要件を示して相談
- 課題解決のためになぜRedshift Serverlessを採用したのか
- オンプレミス環境で数ヶ月かかって環境を作っていたものを数分で作成することができた
- データ量や需要の増加に伴って自動スケーリングできるため
- Auto WLMの機能もあってリソース割り当てを管理する必要がないため
- 30分ごとの自動バックアップとリカバリポイントの生成ができた
- 組み込みのクエリとデータベースのリソース監視をAWSコンソール画面でできる
- 一番嬉しいところがクエリの実行時間に対してのみの支払いになること
- オンプレミスからAWSへマイグレーションする際は、AWS SCTで変換→S3に保存→Redshift取り込みという非常にシンプルなパターンで行えた
- 初期データ（1TBのデータスキャン、20セッション、5000クエリ実行）を使ったパフォーマンステストで比較したところ、以下のような大差となった
- Redshift Serverless（128RPU）で30分
- オンプレミス（768vCPU、6TBメモリ）で3時間
- クエリ時間81％削減、クエリ速度が2〜75倍に向上
- Redshift Serverlessのコストも＄32で収まった（オンプレだと換算すると＄300）
- 今後について
- オンプレミスとのさらなるコスト比較を詳細に調査
- データ取り込みや変換のユースケースを含める
- マルチてナンシーとデータシェアリングについて調査
Low code/no code data pipelines for simpler builder experience
- データソースからETL処理を行うデータパイプラインは、独自で構築するにしてもさまざまなデータソースに対応し、想定外のエラー対応なども発生しやすく運用のためのメンテナンスの負荷がかかる
- 最近のアップデートでは上記の負荷を軽減できるようなデータインジェクションと連携のためのアップデートが発表されている
- Federated Queries
- Aurora Zero-ETL
- Auto-copy from S3
- Streaming ingection
- サードパーティとのデータ共有（Data Exchange）
- Redshift Data sharing
- Redshift MLによる機械学習
- BIツールとの連携
Autonomics for best out-of-the-box price performance
- Autonomicsの目標はチューニングの精査を心配する￥ことなくすぐに使用でき最高のパフォーマンスを提供すること。そしてRedshiftがAutonomicsに対して採用しているアプローチについて解説
- Redshif開発におけるアプローチ
- まず実行されていくワークロードの傾向とパターンを見極め特定（どのようにソート、分散していけば良いかなど）
- 利益を見積もり、アクションを行い、ワークロードの変化に伴いパターンの見極め、という一連のサイクルを回していく
- 開発のアプローチによってRedshiftに導入された機能
- テーブルの自動最適化
- 自動ワークロードマネージャ
- マテリアライズドビューとオートリフレッシュ、オートリライト
- さまざまな種類のクエリを統計し、クエリを実行する最善の方法を最適化する
- これらの統計とクエリが必要とするリソースに基づいて機械学習モデルでクエリの実行時間を予測する
- 予測結果によってコンピュートノードを自動でプロビジョニングする
- クエリによってバックグラウンド側でどのマテリアライズドビューを作成するかどうかを決定し自動更新
- 当初、うまく最適なマテリアライズドビューを自動作成の判定ができるかの課題があったが、Autonomicsのアプローチ導入で課題解決が進み、機能導入に踏み切った
- また、ワークロードが変わったとしても自動削除の判定機能も取り入れることでオーバーヘッドを回避できるようにした
- Autonomicsによってどのくらいのパフォーマンスが得られたのか
- 30TBのデータで、キャッシュ無効の状態でテストし、途中ユーザーからのチューニングなしで経過を測定
- 48時間後、約４０％の速度向上
最後に
データ分析におけるDWHの導入において、必要なインフラストラクチャやパフォーマンスチューニング、運用コストについてこれまでは長い時間をかけて検討しなければなりませんでしたが、Redshift Serverlessの登場、Auto WLM機能強化などによって検討時間が大幅に削減できることがわかります。
とくにAuto WLMにおいて、現在のRedshiftはデフォルトで有効化されているため、運用コスト削減には大きく貢献しているのではないかと思います。
Redshift Serverlessもインスタンスタイプの変更を考えなくて良くなるのでインフラの運用コストがさらに減りますが、継続的にクエリを実行するようなワークロードプランの場合は課金コストが大きくなるので、ご自身のワークロードの傾向を見極めてから導入を決めるのがお勧めです。
10
