データプラットフォームグループの松原です。 弊社各サービスのデータ分析基盤であるLivesense Analytics（以降LA）の開発、運用を行っています。
LAではデータウェアハウスとしてRedshiftを運用しており、社内から比較的自由に利用できる様にしています。
Redshiftには、分析者がアドホックに実行したり、BIツールなどからKPIを取得するために実行されるインタラクティブなクエリと、
比較的長時間かかるような定期的に叩かれるバッチ実行のクエリ（ETLやLivesense Brainからの利用）の2種類のワークロードが混在している状況です。
このようなワークロード下で、アドホックなクエリの実行（や非常に高負荷になるようなETL処理）によりRedshiftの全リソースを使用されてしまい、他のクエリが全てAbort（キャンセル）するような状況が継続的に発生することは望ましくありません。
そのためRedshiftの運用として、主に以下のようなこと対策を行っています。
- Workload Management(以降、WLM) を用いて、高負荷になるクエリを制限
- 指標となるデータをRedashのダッシュボードに表示して毎週、毎朝確認し問題となるようなクエリが頻発していないか、リソースに急激な変化が無いかの確認
- 一部のシステムテーブルのデータを別のテーブルに保存することでモニタリング対象のデータの永続化
今回は、これらの取り組みついて紹介していきます。
WLMを用いて、高負荷となるようなクエリの制限
WLMはインタラクティブなクエリ、バッチクエリが混在するような利用状況下でRedshiftという資源を効果的に利用ための機能です。
LAでは大きく分けると次の方針で WLM によるクエリ制限を行っています。
- 実行ユーザグループごとのクエリ同時実行数・実行時間の制約
- 用途毎のリソース利用に関する制限
上記の制限の内容や利用用途毎にWorkloadキューとして設定しています。
- 分析者・ディレクターの実行するアドホッククエリなクエリやBIツールのクエリ
- バッチシステム
- データの投入
これらの キュー を分割することで、クエリのタイムアウトをそれぞれに設定できたり、特定のキューではリソースへの制限を行ったり同時実行数の制約ということが行えます。 また、読み込み系のクエリと書き込み系のクエリでキューを分けることで、データが書き込まれないというようなことが起こらないようにしています。
インタラクティブなクエリには2つのWLM キューを用意して、並列実行数の多くメモリ割り当ても多いタイムアウトが短いキューから、並列数の低くメモリ割り当てが少ないがタイムアウトが長いキューへクエリホッピングするような設定を行っています。このようにすることでインタラクティブなクエリについては同時に実行される長時間クエリの実行数の制限が可能になります。
また、このキューでは一度にスキャンできるデータ量、Redshift Spectrumでのスキャン量（MB)やクエリの実行結果の行数に制約を掛けて過度の負荷がかからないようにしています。
バッチシステムやデータの投入については用途に応じてWLMキューを分けて並列度やタイムアウトなどの設定を実施しています。
また、Short Query Acceleration（SQA）を有効にしており、最大実行時間は10秒としています。 分析者・ディレクターの実行するアドホッククエリなクエリやBIツールのクエリの実行時間の分布をSTL_WLM_QUERYで確認したところ、80%程度のクエリが10秒以内に完了していることが分かったので、10秒という値になっています。
指標となるデータをRedashのダッシュボードに表示して週次のミーティングなどで確認
日々以下のようなデータをSlackのリマインダーとRedashを連携して確認出来るようにしています。
- S3 scanned mbytes（30日分のデータをユーザ別・日毎で表示）
- stl wlm rule action件数(1週間分)
- Redshiftへのdailyでの実行クエリ数とUU（1ヶ月分）
S3へのscanned（Spectrumの利用量）はWLMで1回あたりのScan量の上限を設定していますが、過度なアクセスが発生して重課金が発生していないか傾向を見ています。 また、 wlm ruleとして、WHERE句なしでクロスジョインのような大量のデータの読み込みなど想定以上のデータの読み込みや、S3へのscanサイズの上限などに達した場合はクエリをAbortさせているので、その数なども確認しています。
また、ワークロードの管理以外にもRedshiftの状況を確認するために、週次のミーティングで以下のようなデータ容量の増減なども確認しています。
主に急にデータ量が増えている箇所は無いかという観点で確認しています。
- 全スキーマのデータ容量合計（半年分）
- スキーマ毎の1ヶ月前とのデータ容量の差分
- データ量が特に多い2つのサービスの、テーブル毎のデータ容量の増減の傾向
- 1ヶ月前と比べて、データ容量の増減率が多いテーブルTop20
- 1週間前と比べて、データ容量の増減率が多いテーブルTop20
ここでのデータ容量はSVV_TABLE_INFOのsizeカラムの値をさしています。
この辺りについては Amazon Redshiftのデータ量監視とエンコードタイプを参照してください。
下図が確認しているダッシュボードの抜粋です。
それ以外にも一定時間以上かかったクエリの通知、DISTKEYの分散状況の悪いテーブルの一覧※、利用の無いテーブルの一覧を取得するようなクエリなどを、確認できるようにして利用状況に合わせて運用の改善を行っています。
※RedshiftのAdvisor機能で確認出来るようなりました
システムテーブルのデータを別のテーブルに保存
システムテーブルのデータはRedshiftの利用状況などを確認するために必要ですが、STL_QUERYなどの一部のシステムテーブルは一定期間より古いデータを削除する仕様になっています。
データを継続的に見ていくには古いデータが欠けると困るため、一部のシステムテーブルのデータを定期的に他のテーブルにCOPY（INSERT）を行うと共に、古いデータについてはRedshift Spectrumに移して容量を気にせずに何かあった時のために見えるようにしています。
また定期的な削除以外にも、クラスターへのノード追加時でもシステムテーブルがクリアされるので注意が必要です※。
※ 以前 Classic-Resize時に確認。Elastic-Resize時は未確認
なお、弊社ではRedshiftの利用状況（MTGで上記の項目の確認や、WLMキュー毎の待ち時間や実行時間など）のモニタリングのために以下のシステムテーブルのデータを取得しています。
最後に
ここ1年ぐらいでRedshiftは多くの機能改善が行われており、ここに書いているようなことも Automatic Workload Management や Advisor機能 の登場により一部の運用は 簡単に実現可能になっています。
今後も多くの新機能が期待されるので、Redshift側の機能として任せられる部分は便利な機能を使いつつ運用を行っていければと思います。
また大きめの新機能が使えるようになったタイミングでWLMの設定の見直しなどをすることによって、Redshiftをより快適に利用していけるようになるかと思います。
ただし、WLMでの制約は不用意な高負荷クエリの抑止には効果がありますが、大規模なデータへのクロスジョインなどを実施しリソースを食いつぶすようなクエリを継続的に実行する必要がある状況に対しては効果的では無いので、処理の一部をEMRやAthenaを利用するなどを行うことで解決していけるのではと考えています。
