今年はリモート開催となったPresto Conference Tokyo 2020で、トレジャーデータのPrestoサービスのテスト戦略について発表させていただきました。
スライドはこちらです。
www2.slideshare.net
社内ではpresto-query-simulatorと呼んでいるテストシステムなのですが、基本的な考え方としては現行バージョンとテスト対象のバージョンの2つのPrestoクラスタで実際にプロダクション環境で実行された過去一定期間のクエリを流し、結果を比較するというものです。
2年前に私が入社した時点ですでにこのテストの仕組みは存在していたのですが、さらなる効率・カバレッジ改善と共に、テスト結果の分析に非常に手間がかかる上に分析が個人のナレッジに依存しがちで、結果的にテストを実施しているにも関わらず問題を検出できていないケースもあったため、最近になって結果の自動解析とレポートの自動生成機能を追加し、テスト結果を迅速かつ定量的に評価できるようになりました。
発表では他社さんの類似のテスト事例についても軽く紹介させていただいたのですが、SnowflakeではSnowtrailという内製のテスティングフレームワークが使われているようです。以下のペーパーを読むと同じSaaSならではの苦労やテストの難しさなどかなり共感できる部分があります。
Snowflakeはプラットフォームとしてタイムトラベル機能をサポートしているので、テストでも実際にクエリが実行された時点でのデータを使ってテストを行うことができているようです。また、SnowflakeはSQLでのデータ書き込みができないはずなので、Writeのパフォーマンスや、クエリエンジンによるWriteを駆使したトリッキーなユースケースについて考えなくてもよいであろう点は若干羨ましいところですw
また、TiDBを開発しているPingCAPではKubernetes上でFault Injectionまで含んだテストを行なっているようです。さらなるサービスの安全性と安定性のためにはこういった異常系のテストについても充実させていく必要があるかと思います。
それからカンファレンス後にTwitterで教えていただいたのですが、Googleでも同様のアプローチでクエリエンジンのデグレードを検出するためのテストを行なっているようです。こちらはVLDB 2020で発表があったようなのですが見落としていました。後で目を通してみようと思います。
Query EngineのPerformance Degradationのチェックと言えば、Googleも同じことをやっていますね DIAMetrics: Benchmarking Query Engines at Scale https://t.co/NYDJcB3AeH #prestosql
— onestar (@oneonestar) November 20, 2020
なお、今回のPresto Conference Tokyo 2020全体については弊社のサポートチームのKammyさんが執筆された以下のブログ記事に大変よくまとまっていますので、こちらをご参照いただければと思います。
参加者の皆さん、登壇者の皆さん、お疲れ様でした。またいつの日か昨年同様、Prestoクリエーターのお三方やBrianさんもお招きしてオフラインでPresto Conference Tokyoが開催できる日が再びやってくることを願っています。
