Amazon Redshift Performanceビューから読み解くアクティビティと監視のポイント
Amazon Redshift が標準で提供している Redshift Console は 複数ノード構成のアクティビティの確認に便利な Performance ビューを提供しています。今回はメトリックスの読み解き方と、CloudWatchへのアラーム設定のポイントについてご紹介します。
Performance ビューとは
Performance ビューとは Redshift メトリックスに対して、ノードごとのアクティビティをグラフ表示することで、Redshift の稼働状況をひと目で確認できる便利な機能です。また、メトリックスに対して、CloudWatchのしきい値とアラーム設定をすることで、これらアクティビティの監視を自動化できます。
メトリックスの目のつけどころ
まずは各メトリックスの目的と、着目するポイントについて、ざっくりと解説します。
以下のメトリックスの例は、データをロード(COPY)後にINSERT INTO xxx SELECT ...を実行して集計テーブルを作成を何度か繰り返した時のグラフとなります。
監視のポイント
一般的に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 クリックして、アラーム設定するノードのメトリックスを選択してください。
監視対象によっては、ご検知にならないように、しきい値や監視対象を設定してください。
まとめ
慣れてくると Performance ビュー 見て全体像を把握し、問題解決の切り分けが容易になります。前提知識なしで Performance ビュー見ても、負荷が高いことはわかるだけで、適切な問題解決に至るにはアーキテクチャの理解が必要ですが、今回は数ある監視メトリックスから必須3項目、予兆検出3項目の合計6つに絞りました。障害が発生した時、遅い何かおかしいと思った時は、「メトリックスの目のつけどころ」を参考に原因を絞り込んでください。
関連記事として、以下のブログがございますので合わせてお読みいただけると問題解決の手法や理解が深まるのではないかと思われます。