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

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

Performance ビューとは

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

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

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

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

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

監視のポイント

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

監視項目（必須）

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

監視項目（予兆検出）

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

監視設定

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

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

まとめ

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

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

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

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