自己紹介

皆さん、こんにちは。

ICT統括室の和田です。

(リクルート ICT統括室 Advent Calendar 2023 5日目 以来の登場です。)

私はICT統括室内のデータ基盤とTableau Cloud基盤の管理を担当しており、日々増え続けるデータ量とSlot利用量と対峙する係です。

今回の記事では、管理者として思わぬ負荷問題に直面した事例をシェアさせていただきます。

具体的にはTableauとBigQueryの組み合わせの事例となりますので、データ基盤やTableauの管理を任されたばかりの人や、突然管理を引き継ぐことになった方の参考になれば幸いです。

日々のモニタリングの中で

ICT統括室はデータ活用を積極的に進めており、日々データ量とその利用が増え続けています。

モニタリングが業務の中にあるのですが、ある日、｢このままいくと来期はもっと利用量が増えるのでもしかしたらパフォーマンス低下と予算超過する可能性があるかもしれない・・・｣となりました。

ということで負荷軽減を進めようと思い立ち、｢重いSQLクエリを改善することが負荷軽減策として必要になるだろう｣と思いながら調査を開始しましたが、意外な事実が判明しました。

調査結果：原因はどこだ？！

調査をして想定と違ったことが2つありました。

①重いSQLクエリだけではなく軽いSQLクエリも影響を与えている

確かに重いSQLクエリも存在しましたが、実は軽いSQLクエリも大量に発行されており、それが負荷の要因になっていたことが分かりました。

②Tableau Cloudが負荷の主要因

Tableau Cloudの利用者はBigQueryの直接利用者より少なかったため、大きな負荷にはなっていないと考えていました。しかし、調査の結果、Tableau Cloud経由のクエリが負荷の主要因であることが分かりました。

②をグラフにしたものが図1になります。

つまり、「重いSQLクエリを改善する」ことでは解決にならず、「Tableau Cloudのダッシュボードが原因でありその改善が必要」という認識をしたのでした。

問題のあるダッシュボードの特定と改善

SQLクエリのログを調査し、Tableau Cloudのダッシュボード利用状況を分析したところ、以下のような問題があるダッシュボードを特定できました。

1. 未利用のダッシュボード

2. 更新頻度が過剰（月次でよいのに日次になっている）のダッシュボード

3. データやTableau機能をたくさん搭載した「リッチすぎる」ダッシュボード

図1をTableauのみに絞り、問題のあるダッシュボードと問題のないダッシュボードを色づけしたものが図2になります。

図2の通り、問題のあるダッシュボードを改善することで負荷改善ができそうな見立てが出てきたため、その対応策として、それぞれ下記の対応をすることにしました。

1. 未利用のダッシュボードを廃止

2. 更新頻度を適正化

3. リッチすぎるダッシュボードを適正化

問題のあるダッシュボードのデータ更新を停止し、アクセス権を削除する対応(※)を2024/11/4に実施しました。それにより適正負荷になるだろうと想定していました。

作業結果は、図3の通り、2024/11/5の利用量は、想定通り減っている・・・のですが、まだ残っているのは何故だ！？しかも、問題がないダッシュボードより利用量が多いとはどういうこと！？という状態です。

※当環境では、いきなり物理削除ではなく、まずは論理削除という運用ルールとしているため、このような対応となっています。

新たな課題の発生：想定外のクエリ発行の原因は？！

ダッシュボードのデータ更新を停止し、アクセス権も削除したため、通常であればSQLクエリの発行は止まるはずでした。しかし、実際には図4のようにSQLクエリが継続して発行されており、その原因を特定できませんでした。

2024/11/5に絞ってSQLログを確認すると、0時から7時ごろにかけてクエリが発行されており、ユーザーアクセスによるものではないことのあたりをつけることができました。

何らかの設定が悪さをしているのでは？と思い、改めてTableau Cloudの設定を見直したのですが、原因となるような設定を特定できず、最終的にTableauのサポートへ問い合わせを行いました。

原因の特定と解決策の実施

数日後、サポートからの回答により｢ビューの高速化(≒キャッシング)機能｣が負荷の原因ということが判明しました。

「ビューの高速化機能」とは、ダッシュボードの描画を高速化するために定期的にデータへSQLクエリを発行する機能でSQLクエリが止まらない原因になっていました。

最後までSQLクエリが発行され続けた原因がビューの高速化機能だったことは想定外でした。

解決策の実施に向けた検証

解決策は判明したものの、いきなり機能停止させるのは業務的な影響もあるかもしれないため、調査することにしました。

負荷の高いダッシュボード10個をコピーし、機能のON/OFFで描画時間を比較したところ、OFFにしてもほぼ変わらず、むしろOFFの方が速くなることもありました。(※)

この検証結果をもとにサポートと再度やりとりし、環境全体で｢ビューの高速化機能｣を停止することに決定しました。

※描写時間については利用環境やダッシュボード仕様により変動する可能性がある旨の回答をサポートよりいただいています。

解決策の実施

｢ビューの高速化機能｣の停止は、2024/11/13に実施しました。

その結果、、、図5のように継続的に発行され続けていたSQLクエリをゼロにできました。

今回の学びと今後に向けた反省

今回の事例を振り返ると、以下の7つのStepで対応を行いました。

1. 問題の特定（軽いSQLクエリが積み重なっていた）

2. 負荷の原因を特定（Tableau Cloudが主因）

3. 問題のあるダッシュボードの特定

4. ダッシュボードの廃止・最適化（論理削除・更新頻度の適正化など）

5. 想定外の負荷継続を検知

6. 新たな原因を特定（ビューの高速化機能）

7. ビューの高速化機能を停止し、負荷削減を完了

今回発生したような負荷問題を発生させないために重要と感じた学びは2点です。

1. 負荷を検知できるモニタリングの仕組みを持つこと

2. 設定変更を見直しできる仕組みを持つこと

1は、問題のあるダッシュボードが放置され、不要なSQLクエリが継続的に発行されていたことです。

そもそもその状態に気がつく仕組みがなかったことが原因と感じています。モニタリング自体はやっていましたが負荷の詳細部分までは見ておらず問題が大きくなったのだと感じています。

2は、状況に応じた見直しができていませんでした。

導入時に最適だった設定が、環境の変化に伴って不適切になっていたということに気がつける仕組みを導入するべきだったと感じています。

余談ですが、私自身が導入したTableau Cloudではありますが、当時の私は、デフォルト設定は推奨設定のはずだから問題ないだろうと考え、ビューの高速化機能も単純に高速化につながると思い、そのまま有効にしていました。導入設計時にこの機能は必要だから使う/使わないを考え切れていなかったことも一因だろうと思っています。

もう少し言うと、管理者になったばかりの方や管理を引き継いだ方は前任者のやり方や設定をそのまま利用していることもあるはずです。

もしモニタリングの仕組みが足りていないならば導入を検討いただきたいですし、今回の設定を含めて前任者からの引き継ぎであるならば、管理している環境で導入している設定が本当に適切なのか？を見直してみてください。

まとめ

今回の事例では、Tableau CloudとBigQueryの組み合わせでしたが、他のSaaS製品やツールでもモニタリングの仕組みがなかったり、設定を見直す仕組みがないと同様の負荷問題が発生する可能性があります。

繰り返しになりますが、管理を引き継いだらそのまま利用するのではなく、一度、管理の仕組みや設定を見直すのが良いと考えます。

特に設定については既存の設定やデフォルト設定が必ずしも最適とは限らず、状況が変わるにつれ最適な設定が変わっている可能性もあります。

定期的に見直し、現環境に適しているかどうかを確認することをお勧めします。

このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。

-  キャリア採用サイト 募集職種一覧

-  カジュアル面談フォーム

また、他にも色々な記事を投稿していきます！

過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。
・Recruit Tech Blog
・リクルート ICT統括室 Advent Calendar 2024
・リクルート ICT統括室 Advent Calendar 2023