Amazon Redshift 動的ワークロードマネジメント(WLM)を試してみた | DevelopersIO
先日、Redshiftのワークロードに割り当てたメモリや最大並列実行数を再起動なしで変更可能になりました。この機能を利用すると、日中はBIツールにリソースを優先的に割り当て、夜間はバッチ処理用といった異なるワークロードに対して柔軟にリソースの割り当て変更するなどの応用が考えられます。実際にバッチ処理用のキューを割当て動的変更した時の動作やこの機能の使い勝手についてレポートします。 WLM（ワークロードマネジメント） Redshiftには実行に長い時間を要するクエリー（ロングクエリー）は、クラスタ全体のボトルネックとなり、ショートクエリを待たせる可能性があります。そこで、用途ごとにクエリーの並列度やメモリ（％）の上限を設けた複数のキューを定義することでクエリー処理の制御が可能になります。 WLM（ワークロードマネジメント）の詳細につきましては、以下の資料を御覧ください。 AWS Black
Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント | DevelopersIO
Amazon Redshift が標準で提供している Redshift Console は 複数ノード構成のアクティビティの確認に便利な Performance ビューを提供しています。今回はメトリックスの読み解き方と、CloudWatchへのアラーム設定のポイントについてご紹介します。 Performance ビューとは Performance ビューとは Redshift メトリックスに対して、ノードごとのアクティビティをグラフ表示することで、Redshift の稼働状況をひと目で確認できる便利な機能です。また、メトリックスに対して、CloudWatchのしきい値とアラーム設定をすることで、これらアクティビティの監視を自動化できます。 メトリックスの目のつけどころ まずは各メトリックスの目的と、着目するポイントについて、ざっくりと解説します。 以下のメトリックスの例は、データをロード（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
