Amazon RedshiftのAUTO VACUUM機能について

記事タイトルとURLをコピーする

技術一課の杉村です。2018/12に Amazon Redshift の AUTO VACUUM 機能がリリースされました。
https://aws.amazon.com/jp/about-aws/whats-new/2018/12/amazon-redshift-automatic-vacuum/
Redshift を利用されているお客様がこのリリースを見て、自動で VACUUM が走ることに対してパフォーマンス影響があるかを気にされたことがあり、そのときに調べた内容を遅まきながらもブログにしてみました。

ポイント

  • 自動的に VACUUM DELETE が走る
  • この機能はユーザによるロードやクエリを極力、邪魔しないようになっている
  • 同時リリースで VACUUM 処理がテーブル全体でなく必要なテーブルの一部に実行されるようになった

AUTO VACUUM の仕様

Redshiftではその元となっているPostgreSQLがそうであるように、 UPDATE や DELETE でレコードが変更されても実際にそのデータはすぐに削除されるわけではなく、削除マークが付けられます。
削除マークの付いた領域は VACUUM を実行することにより解放しなくては使用できません。RedshiftのVACUUMには FULL 、SORT ONLY 、DELETE ONLY 、REINDEX の4オプションがありますが、今回のアップデートで VACUUM DELETE が自動的に行われるようになりました。
※ちなみに Redshift における VACUUM コマンドのデフォルト動作は VACUUM FULL です。( SORT + DELETE と同義 )

VACUUM DELETE は先ほどのように削除マークのついた不要領域を再利用可能状態にする処理であり、またテーブルに対するロック取得もしないためユーザのパフォーマンス体験への影響は限定的といえます。
またユーザ操作(クエリや COPY コマンド等)とバッティングした際は VACUUM は一時停止して、負荷が無いときに再開する仕様になっています。

また今回のアップデートで VACUUM DELETE はテーブルの一部のみに実施されるようになり、かつてカラム数が数百を超える場合にエラーとなった Vacuum Column Limit Exceeded エラーは発生しなくなったようです。

AUTO VACUUM がいつ、どこで走ったか

AUTO VACUUM はバックグラウンドでいつの間にか走っているものなので、基本的に我々ユーザが意識することはありません。
しかし「いつ、どこで AUTO VACUUM が実行されたか」知りたいこともあるかもしれません。

CloudWatch のクラスター別メトリクスで AutoVacuumSpaceFreed というものがあります。
マネジメントコンソールの CloudWatch 画面からはもちろん、 Redshift のコンソールで クラスタ>「クラスターのパフォーマンス」タブでもこのメトリクスの値を確認することができます。

システムテーブルの STL_VACUUM を確認することで VACUUM DELETE の発生時刻・終了時刻・対象のテーブルID等が確認できます。
リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_VACUUM.html

statusカラムに [VacuumBG] Started Delete Only や [VacuumBG] Finished 等とメッセージが記録されます。

なおテーブルIDとテーブル名の対応につきましては、 SVV_TABLE_INFO システムテーブル等で確認できます。
リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_SVV_TABLE_INFO.html

また他にも STL_QUERY システムテーブルで WHERE querytxt like 'Vacuum: delete%' のようにSELECTすることで、VACUUM処理が発行されたかどうかを確認することも可能です。 リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_QUERY.html

なおSTL_*と名の付くログテーブルには2~5日分のログ履歴のみを保持いたしますのでご注意いただき、必要な場合には定期的に他のテーブルにコピーするか、Amazon S3にアンロードいただくなどにてログデータの保存できます。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_intro_STL_tables.html

ディスク容量を管理するため、STL ログテーブルは、ログの使用状況と使用可能なディスク容量に応じて、およそ 2 ~ 5 日分のログ履歴のみを保持します。ログデータを保管するには、定期的に他のテーブルにコピーするか、Amazon S3 にアンロードする必要があります。

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。