Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント

Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント

Clock Icon2015.07.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon Redshift が標準で提供している Redshift Console は 複数ノード構成のアクティビティの確認に便利な Performance ビューを提供しています。今回はメトリックスの読み解き方と、CloudWatchへのアラーム設定のポイントについてご紹介します。

Performance ビューとは

Performance ビューとは Redshift メトリックスに対して、ノードごとのアクティビティをグラフ表示することで、Redshift の稼働状況をひと目で確認できる便利な機能です。また、メトリックスに対して、CloudWatchのしきい値とアラーム設定をすることで、これらアクティビティの監視を自動化できます。

redshift-performance-view_rev2

メトリックスの目のつけどころ

まずは各メトリックスの目的と、着目するポイントについて、ざっくりと解説します。

以下のメトリックスの例は、データをロード(COPY)後にINSERT INTO xxx SELECT ...を実行して集計テーブルを作成を何度か繰り返した時のグラフとなります。

メトリックス グラフの目的と着目するポイント
Queries 実行したクエリーを視覚化するのが目的のビューです。クエリーをクリックすると実行されたSQL文が表示されます。ここで、極端に長いクエリーや実行した覚えのないクエリーが実行されていたら要注意です。redshift-performance-queries
CPU Utilization CPU 使用率(パーセンテージ)を把握するのが目的のビューです。演算処理がボトルネックになっていないか、各コンピュートノード間でネットワーク性能が平準化されているかを確認します。redshift-performance-cpu
Network Receive Throughput ノードがデータを受け取るレートを把握する目的のビューです。テーブルジョインした非更新クエリーを実行した時にネットワーク負荷が高い時は再分散が発生して可能がありますのでプランを確認してください。redshift-performance-nw-receive
Network Transmit Throughput ノードがデータを書き込むレートを把握する目的のビューです。テーブルジョインした非更新クエリーを実行した時にネットワーク負荷が高い時は再分散が発生して可能がありますのでプランを確認してください。redshift-performance-nw-transmit
Write IOPS 1 秒あたりのEBSへの書き込み操作の平均回数を把握する目的のビューです。IOがボトルネックになっていないか、各コンピュートノード間で書込み負荷が平準化されているかを確認します。redshift-performance-write-iops
Write Throughput 1 秒あたりのディスクへの平均書き込みバイト数を把握する目的のビューです。Write IOPSの値と傾向に違いがある場合はデータ領域に断片化が生じている可能性がありますので、VACUUMを実行を検討してください。redshift-performance-write-throughput
Write Latency ディスク書き込み I/O 操作にかかる平均時間を把握する目的のビューです。IO待ちによる遅延や、各コンピュートノード間で遅延に大きな差がないかを確認します。redshift-performance-write-latency
Read IOPS 1 秒あたりのEBSへの読み取り操作の平均回数を把握する目的のビューです。IOがボトルネックになっていないか、各コンピュートノード間で読込み負荷が平準化されているかを確認します。redshift-performance-read-iops
Read Throughput 1 秒あたりのディスクからの平均読み取りバイト数を把握する目的のビューです。Read IOPSの値と傾向に違いがある場合はデータ領域に断片化が生じている可能性がありますので、VACUUMを実行を検討してください。redshift-performance-read-throughput
Read Latency ディスク読み取り I/O 操作にかかる平均時間を把握する目的のビューです。IO待ちによる遅延や、各コンピュートノード間で遅延に大きな差がないかを確認します。redshift-performance-read-latency
Database Connections クラスターへのデータベース接続の数を把握する目的のビューです。極端に接続数が多くないか等確認します。redshift-performance-connections
Health Status クラスターの状態を把握する目的のビューです。HEALTHY(1)または UNHEALTHY(1 より小さい値)。UNHEALTHYはサービス停止を意味します。redshift-performance-health-status
Maintenance Mode クラスターがメンテナンスモードかどうかを把握する目的のビューです。ON(0 より大きい値) または OFF(0)。メンテナンスタスクのためクラスターを利用できなかったとしても、HEALTHY(0)はHEALTHY(0)を返しますのでこちらも合わせて確認しください。redshift-performance-maintenance-mode
Percentage of Disk Space Used  ディスク使用率(パーセンテージ)を把握する目的のビューです。ディスク使用率が100%にならないようにご注意ください。ディスクの使用率が、通常は60%であったとしても、テンポラリ領域を大量に消費するクエリー実行すると100%に達する場合があります。実際の設定値は過去のディスク使用量の変動実績を把握してください。redshift-performance-disk-usage

監視のポイント

一般的にRedshift(DWH)は日次や月次などのバッチ処理で大量データの更新(データ一括投入、集計処理)やVACUUM/ANALYZE(データのメンテ作業)する事が多く、通常に比べCPU使用率、ReadIOPS、WriteIOPSなどが一気に高くなる傾向が高いので、全てのメトリックスに対して、単純にしきい値を設定すると、Alert監視設定をするのはお勧めできません。

監視項目(必須)

以下の項目についてはサービス停止につながったり、不正な利用の可能性があるアクティビティの検知が目的です。設定して直ちに検知・通知して構わない項目です。

監視メトリックス アラームのしきい値
HealthStatus クラスターの状態がUNHEALTHY(1未満)をしきい値とする。
PercentageDiskSpaceUsed ディスクの使用率が、通常は60%であったとしても、テンポラリ領域を大量に消費するクエリー実行すると100%に達する場合があります。実際の設定値は過去のディスク使用量の変動実績から試算して、サイジングとしきい値設定するのが良いでしょう。
DatabaseConnections パフォーマンス低下が懸念される同時実行や、想定していない利用を検知します。設定値は全てのWLMキューの同時実行レベル(デフォルト:5)の合計数より大きな値を設定してください。

監視項目(予兆検出)

以下の項目については想定外の利用の検知やクラスタのパフォーマンス不足によって生じる、長時間の処理遅延やサービス品質に低下を検知することが目的です。CloudWatchのPriodは1時間など長めの値を設定して、誤検知にならないようなしきい値設定が重要です。また、LeaderNodeとComputNodeではメトリックス値とタイミングが異なりますので、異なるしきい値を設定してください。

監視メトリックス アラームのしきい値
CPUUtilization CPU使用率が長時間に渡り高止まりしている場合は、クエリの見直し、ノードの増強を検討しください。
WriteIOPS WriteIOPSが長時間に渡り高止まりしている場合は、クエリの見直し、列圧縮タイプ・ソートキー見直し、ノードの増強を検討しください。
ReadIOPS ReadIOPSが長時間に渡り高止まりしている場合は、クエリの見直し、列圧縮タイプ・ソートキー見直し、ノードの増強を検討しください。

監視設定

監視設定は、一般的なCloudWatchのAlert設定と変わりません。Metrics から Redshift クリックして、アラーム設定するノードのメトリックスを選択してください。

redshift-cpu-cw-1

監視対象によっては、ご検知にならないように、しきい値や監視対象を設定してください。

redshift-cpu-cw-2

まとめ

慣れてくると Performance ビュー 見て全体像を把握し、問題解決の切り分けが容易になります。前提知識なしで Performance ビュー見ても、負荷が高いことはわかるだけで、適切な問題解決に至るにはアーキテクチャの理解が必要ですが、今回は数ある監視メトリックスから必須3項目、予兆検出3項目の合計6つに絞りました。障害が発生した時、遅い何かおかしいと思った時は、「メトリックスの目のつけどころ」を参考に原因を絞り込んでください。

関連記事として、以下のブログがございますので合わせてお読みいただけると問題解決の手法や理解が深まるのではないかと思われます。

Amazon Redshift Queries ビューで問題のクエリを特定する

Amazon Redshift Loads ビューでデータのロードを管理する

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.