背景
筆者の所属チームは、自社で唯一のデータエンジニアリングチームであり、 Snowflake を使って自社のデータウェアハウスを構築・運営すると共に、データパイプラインの構築・運用、利用者への技術サポートを行なっています。
データウェアハウスは社内のデータ分析や機械学習など様々なプロジェクトで利用されますが、データウェアハウスの直接的な利用者の多くは、データ分析を行なっているチームです。利用者も構築側の我々もお互いにデータ分析のワークロードがどういうものか理解した状態でプロジェクトが運営されます。
しかし、利用範囲が広がっていくにつれ、段々、データ分析のワークロード、データウェアハウス（あるいは Snowflake ）の特性をよく知っているエキスパートではない人が利用し始め、利用者と運営者（データエンジニアリングチーム）の認識の食い違いにより、運営側が想定してない問題に発展することがあり得ます。
今回の記事では、クエリ応答時間要求が比較的厳しく、 OLTP とも分類できそうな要件に Snowflake が使われてしまい、クエリの応答時間が利用者の想定より長くなってしまったというケースで著者が調査した内容や解決策の案などを紹介します。
発生した課題の概要
Snowflake を利用している社内サービスのバックエンドチームから以下の相談がありました。
- 社内サービスの API バックエンドから直接、データエンジニアリングチームによって整備されているマートテーブルにクエリを投げている。これは、事前に集計した結果を参照するだけなので、クエリ自体のデータ処理量は多くない。
- クエリの応答時間のうち 90 パーセンタイルは問題ないが、10 パーセンタイルは想定より遅い。
- また、一部、異常に遅いクエリがあり、応答時間は 30 秒超えるケースもある。
このチームは OLTP 系の DB （ MySQL や PostgreSQL など）と同じ感覚で Snowflake を使っており、常に一定の応答時間（しかも小さい）でクエリ結果が返ってくることを想定して利用しているようでした。データエンジニアリングチームが DBA として権限管理を行なっているので、許可された範囲でアクセスを付与したのは覚えていました。しかし、各チームが具体的にどういう用途で使っているかを完全に把握しているわけではなかったので、他チームが OLAP とは異なる想定で利用していることに驚きました。
クエリ応答時間が長くなった原因
想定の応答時間より長くなったクエリをいくつか調べたところ、以下が分かりました。
- 想定より応答時間が長くなったケースは、クエリ結果のキャッシュを再利用できず、テーブルを再スキャンしたものが多かった。
- 特に応答時間が長いものは、サポートに支援をお願いして調査したところ、ウェアハウスが再起動中にクエリを受け取っており、起動が完了するまでクエリが待たされていたため。
Snowflake には 3 つのレイヤーがあり、それぞれクエリのキャッシュが保管されています。クエリ結果を含め、キャッシュが再利用できる場合、テーブルを再スキャンする必要がないため、クエリへ高速に応答できます。ただし、再利用できるかどうかは一定の条件があり、それを満たさない場合、テーブルスキャンが発生するため、キャッシュ再利用に比べて応答時間が遅くなります。キャッシュについて、詳細は以下の記事を参照ください。
また、 Snowflake のウェアハウスは起動している時間に対して課金する課金モデルのため、コスト削減策として一定時間クエリがこない場合にウェアハウスを自動停止できます。
- ただし、ウェアハウスを停止・再起動するとキャッシュが消されてしまいます。
- 上記に書いた通り、起動中にクエリを受けた場合、完全にウェアハウスが起動するまでクエリが待たされることがあります。
この 2 点は、クエリの応答時間に大きな影響を与えるので、パフォーマンス面を設計する際は考慮が必要です。
本件はそもそも何が問題だったか？
データベースの世界では、大まかに 2 つのデータ処理の種類があります。それぞれの種類について要件が全く異なるため、それぞれの要件をサポートする形でデータベースも異なる進化の形を遂げてきました。よって自分がやりたいデータ処理が主にどちらに当たるかを認識し、適切なデータベースを選択する必要があります。
- OLTP (OnLine Transactonal Processing)
- 特性
- データ量：小
- 応答時間：小
- 頻度：高
- ユースケース例： ホテル予約、オンライン銀行の取引、 E -コマースの決済、など
- 特性
- OLAP (OnLine Analytical Processing)
- 特性
- データ量：大
- 応答時間：大
- 頻度：低
- ユースケース例： データ分析、意思決定、など
- 特性
Snowflake は OLAP に分類されるデータベースであり、今回の相談があったユースケースはどちらかというと OLTP に分類される要件でした。データ量が小さいクエリを常に小さい応答時間で応答することを期待するのであれば、 Snowflake は適切な手段とは言えません。要件に対して適切な手段を選択しなかった場合、コスト、パフォーマンスなどにおいて、問題が発生する可能性が高いです。
クエリ応答時間を改善するための簡易的な対策
ということで、要件に対して手段が合っていないことを分かった上で、クエリ応答時間を改善することを求められたら、どうしたら良いでしょうか？
簡易的、短期的な対策としては、サービスのピーク時間の間、ウェアハウスを継続的に起動させ続けることが考えられます。ウェアハウスが起動し続けると、キャッシュに当たる可能性が高まりますし、ウェアハウスの再起動でクエリが待たされる問題も無くなります。
一方で、ウェアハウスの起動時間が長くなるため、ウェアハウスコストが大幅に上がります。 XS サイズのウェアハウスであれば、1 時間あたり 1 クレジットを消費します。1 クレジットあたり、 USD でいくらになるかは、エディションによって異なりますが、簡易的に試算することが可能です。もし似たような要件があるならば、ウェアハウスを集約させることで、パフォーマンス要件は満たしながら、コストは多少最適化できる可能性があります。
一方で、 AWS RDS Aurora など OLTP に適したデータベースであれば、パフォーマンス要件を満たしつつ、コストは大幅に低減できます。よって、ウェアハウスを稼働させ続ける対策はコスト最適ではないので、長期的には適切な手段とは言えません。
中長期的な対策
中長期的な対策としては、少量データ・小応答時間の要件があるのであれば、利用側で AWS RDS Aurora など OLTP の DB を用意しておき、 Snowflake 上のデータマートから定期的に同期をかける方法も取れるでしょう。
その際、 Airflow などワークフローのツールを使い、自前で ETL パイプラインを組むこともできます。また、開発コスト・運用コストを低減したいのであれば既存の ETL ツールも利用できるでしょう。 ETL ツールを利用すると、テーブルの数が増えてきた場合でも、比較的、容易に対応できます。
- Trocco
- 日本発の ETL サービス。
- データ転送元として Snowflake をサポートしています。 https://documents.trocco.io/docs/data-source-snowflake
- Airbyte
- 米発の ETL サービス。
- データ転送元として Snowflake をサポートしています。 https://docs.airbyte.com/integrations/sources/snowflake/s
- US / EU リージョンしかないので、ローカルリージョンじゃなければだめな場合、 OSS 版を自前でホストすることも可能。 https://docs.airbyte.com/category/deploy-airbyte-open-source
（もしかして） Unistore が解決してくれる？
Snowflake 上で OLTP と OLAP の両方に対応する仕組みとして Unistore （テーブルの種類として Hybrid table ）が発表されているので、もしかすると将来的にはこれで解決されるかもしれません。ただし、まだプレビュー中なので、パフォーマンス面、コスト面はまだ分からない状態ですので、 GA になった後に十分検証してから使ったほうが良いでしょう。
まとめ
今回は、 Snowflake がデータストアとして適していない OLTP （少量データ、小さい応答時間）な要件に Snowflake が使われてしまい、クエリ応答時間が利用者の想定より遅いケースがあるという問題に出くわし、原因の調査や解決策の検討などを行なった件について紹介しました。
データベースに限らず、目的と手段が合っているかは常に検討が必要です。合っていない場合、上記の通り、コスト・パフォーマンス・可用性などシステムを運用する上で重要な指標で問題が起きる可能性があります。
目的と手段が合っているかどうかの判断では、技術の背景、特性などを十分理解する必要があります。それを理解するためのドキュメント、書籍、コミュニティなど情報源は豊富にありますので、自分が利用中、また今後利用する可能性がある技術については情報収集することが重要だと思います。
Discussion