305-AWS SAP AWS 「理論・実践・一問道場」 Concurrency Scaling

type

status

date

slug

summary

理論

Amazon Redshift のスケーリングと負荷対策

Amazon Redshift を使っていると、突然クエリが増えてCPU使用率が高くなることがあります。そのような場合に役立つ機能や対策をまとめました。

1. スケーリングの方法

Redshift は、負荷が増えた時にリソースを増やして対応できます。以下の3つが主な方法です：

クラシックリサイズ (Classic Resize)

クラスター全体のサイズを変える方法。

特徴: 大規模な変更ができるが、時間がかかり、その間クラスターが停止する。

適している場面: 長期的にリソースを増やしたい時。

エラスティックリサイズ (Elastic Resize)

クラスターを停止せずに素早くリソースを増やす方法。

特徴: 迅速だが、急激な負荷増加に完全には追いつけない場合がある。

適している場面: 一時的にリソースを増やしたい時。

Concurrency Scaling (同時実行スケーリング)

クエリが増えた時だけ、自動で追加リソースを使う機能。

特徴: 必要な時にだけ課金され、コスト効率が良い。クエリが減ると自動でリソースを解放。

適している場面: 短時間のクエリ集中に対応したい時。

2. CPU負荷が高い時の対策

クエリを最適化する

無駄な結合や計算を減らす。
データを事前に整理（ETL）する。

外部サービスで処理を分散する

Amazon EMR や AWS Glue で、Redshift 以外のサービスに負荷を分ける。

モニタリングと自動化

Amazon CloudWatch でCPU使用率を監視し、閾値を超えたら通知やリサイズを自動化する。

3. コストを抑える方法

ピーク時だけリソースを増やす

Concurrency Scaling を使えば、必要な時だけリソースが追加され、コストを抑えられる。

長期利用ならリザーブドノードを使う

長期間使う場合、予約購入することで割引を受けられる。

4. ベストな選択肢

短期的な負荷増加には Concurrency Scaling が最適。

自動対応で、常にクエリを処理しながらコストも抑えられる。

長期的な需要増加には Elastic Resize や リザーブドノード を検討。

これらを活用すれば、Redshift のパフォーマンスを維持しつつ、コスト効率を最大化できます！

実践

略

一問道場

質問 #305

トピック 1

あるデータ分析会社が、いくつかのリザーブドノードで構成される Amazon Redshift クラスターを使用しています。このクラスターでは、従業員チームが詳細な監査分析レポートを作成しているため、予期しない使用量の急増が発生しています。このレポートを生成するクエリは複雑な読み取りクエリであり、CPU 集中型です。

ビジネス要件として、クラスターは常に読み取りおよび書き込みクエリに対応できる必要があります。

ソリューションアーキテクトは、この急増する使用量に対応するための最もコスト効率の良いソリューションを考案する必要があります。

どのソリューションがこれらの要件を最もコスト効率よく満たしますか？

選択肢:

A. Amazon EMR クラスターをプロビジョニングし、複雑なデータ処理タスクをオフロードする。

B. AWS Lambda 関数をデプロイし、Amazon CloudWatch でクラスターの CPU メトリクスが 80% に達した際に、クラシックリサイズ操作を使用して Amazon Redshift クラスターに容量を追加する。

C. AWS Lambda 関数をデプロイし、Amazon CloudWatch でクラスターの CPU メトリクスが 80% に達した際に、エラスティックリサイズ操作を使用して Amazon Redshift クラスターに容量を追加する。

D. Amazon Redshift クラスターの Concurrency Scaling 機能をオンにする。