Workers Analytics Engineは、今年の初めに発表された新ツールです。開発者や製品チームが、高次元、高カーディナリティ、楽なスケーリングな環境で、いかなる時系列分析も構築できるようになりました。チームがWorkersで実行するコードについてのインサイトを得たり、エンドカスタマーに分析を提供したり、使用量ベースの課金を構築したりすることを目的に、Workers Analytics Engineを構築しました。
本記事ではAnalytics Engineをどのように使ってAnalytics Engineを構築しているかをお伝えします。Analytics EngineのSQL APIをAnalytics Engine自身を使って計測し、このデータをバグの発見や新しい製品機能の優先順位付けに使用しています。自社製品の計測やフィードバック収集の方法を模索している他のチームに参考となるような情報がお伝えできたら嬉しいです。
Analytics Engineが必要な理由
Analytics Engineは わずか数行のコードを使ってWorkersでイベント（または「データポイント」）を生成することができます 。GraphQLまたは SQL API を使用すれば、これらのイベントを照会して、ビジネスやテクノロジースタックに関する有益なインサイトを得ることができます。Analytics Engineを使用開始方法の詳細については、 developer docsをご覧ください。
9月のAnalytics Engineオープンベータ版リリース以降 、開発者の方々からのフィードバックに基づいて新機能を順次追加してきました。しかし、製品に対する可視性において2つの大きなギャップがありました。
ギャップの1つ目は、エンジニアリングチームは、「リクエストを受ける数はどれくらいか」「そのうちエラーになるのはどれくらいか」「エラーの内容は何か」など、オブザーバビリティに関するよくある問いに答えを出さなければいけないというものです。平均エラー率やp99の応答時間などの集計データと、個々の事象を掘り下げることの両方ができる必要があるのです。
2つ目のギャップは、新製品であるために、当社ではプロダクトインサイトを求めているということです。SQL APIをインストゥルメント化することで、お客様の書くクエリや表示エラーを把握し、不足している機能の優先順位付けに役立てることができるのです。
Analytics Engineは技術的な観測可能性に関する問いに答えが出せるだけではなく、製品のインサイトを収集する素晴らしいツールであることがわかりました。それというのも、すべてのクエリーのイベントをSQL APIに記録し、パフォーマンスの問題を集計するだけでなく、お客様が実行した個別のエラーやクエリーの両方を照会できるためです。
次のセクションではAnalytics Engineを使用して、そのAPIを監視する方法をご紹介します。
SQL APIにインストルメンテーションを追加する
Analytics EngineのSQL APIでは、通常のデータベースと同じようにイベントデータに問い合わせることができます。SQLはこれまで何十年もの間、データを照会するための最も一般的な言語として使用されてきました。私たちは新しいクエリー言語を習得することなく、データに関する質問をすぐに始められるようなインターフェイスを提供したいと考えました。
当社のSQL APIはユーザーのSQLクエリーを解析し、変換・検証した後、バックエンドのデータベースサーバーに対して実行します。そして、Analytics Engineにクエリーの情報を書き戻すことで、独自の分析を行えるようにしています。
Cloudflare WorkerからAnalytics Engineへのデータの書き込みは非常に簡単で、 ドキュメントで説明しています 。ユーザーと同じようにSQL APIをインストルメントしています。このコードの抜粋は、Analytics Engineに書き込むデータを示しています。
そのデータをAnalytics Engineに格納することで、レポートするすべてのフィールドに関するインサイトを引き出すことができるようになりました。
インサイトのクエリー
SQLデータベースで分析を行うことで、どんなクエリーでも自由に作成することができます。メトリクスのように、あらかじめ定義され目的に応じて使い分るものに比べ、カスタムデータセットを自由に定義し、データを照会して新しく質問することができます。
当社では何兆ものデータ点からなるデータセットへの対応が求められています。その実現するために、Adaptive Bit Rate（ABR）と呼ばれるサンプリング手法を実施しています。ABRにおいて大量のデータがある場合、合理的な時間で応答するために、クエリーはサンプリングされたイベントを返すことがあります。データ量が一般的である場合には、Analytics Engineはすべてのデータにクエリーを実行します。これにより、どんなクエリーを実行しても、短時間で応答を得ることができます。今のところクエリーの作成方法において、サンプリングを考慮する必要がありますが、当社ではその自動化を検討しています。
どのようなデータ可視化ツールでも、分析結果を可視化することができます。CloudflareではGrafanaを多用しています（きっとあなたもそうでしょう ）。これは、特に観測可能性のユースケースに有効です。
クエリーの応答時間を観測する
当社ではバックエンドのデータベース・クラスタのパフォーマンスに関する情報を伝えるクエリーに注目しています。
ご覧のように、99%パーセンタイル（1%の最も複雑なクエリーを実行することに相当）では、約300msまで急増することがあります。しかし、当社のバックエンドは平均して100ms以内にクエリーに応答しています。
このビジュアライゼーションは、それ自体がSQLクエリから生成されています。
高カーディナリティデータから得られる顧客インサイト
Analytics Engineにはもう1つ、顧客の行動からインサイトを引き出すという使い方があります。特に当社のSQL APIは、SQLのパワーをフルに活用できるため、このような場合に適しています。当社のABR技術により、膨大なデータセットに対して高価なクエリーも実行することができます。
この能力をAnalytics Engineの改善の優先順位付けに使用しています。当社のSQL APIはかなりSQLの標準的なダイアレクトをサポートしていますが、まだ機能として完全なものではありません。ユーザーがSQLクエリーでサポートされていないことを行おうとすると、構造化されたエラーメッセージが返されます。これらのエラーメッセージはAnalytics Engineに報告されます。お客様が遭遇したエラーの種類を集計することで、次にどの機能を優先させるべきかを判断するのに役立ちます。
SQL APIはtype of error: more detailsというフォーマットでエラーを返すので、コロンの前の最初の部分を取って、エラーの種類を知ることができます。それを元にグループ化し、そのエラーが何回発生し、何人のユーザーに影響を与えたかをカウントします。
通常のメトリクスを使って上記の問い合わせを行うには、エラーの種類ごとに異なるメトリクスで表す必要があります。各マイクロサービスからそれほど多くのメトリクスのレポートがあると、スケーラビリティの面で課題が生じます。Analytics Engineは高カーディナリティのデータを扱うように設計されているため、そのような問題が起こりません。
Analytics Engineのような高カーディナリティストアのもう一つの大きな利点は、具体的に掘り下げることができることにあります。SQLエラーが大量に発生した場合、どの顧客に問題が発生しているのか、あるいはどのような機能を使いたいのかを特定するために、発生している問題の中身を知りたいというケースがあります。別のSQLクエリーを使用することで簡単に解決することができます。
これまでCloudflareでは、この種の情報はバックエンドのデータベースサーバーへの問い合わせに頼っていました。Analytics EngineのSQL APIの使用により、当社の技術をお客様に公開することが可能になり、あらゆるスケールのサービスに関するインサイトを簡単に収集していただけます。
まとめと今後について
SQL API の使用に関して収集した分析情報は、製品の優先順位を決定するための非常に役立つ情報です。上記のビジュアライゼーションで使用した部分substring、そしてposition関数へのサポートの追加は完了しています。
SQLエラーの上位を見ると、列の選択に関連するエラーが多数見受けられます。これらのエラーの多くはGrafanaプラグインに関連するいくつかのユーザビリティの問題が原因となっています。DESCRIBE 関数のサポートを追加すると、これが緩和されるはずです。これがないと、Grafanaプラグインはテーブル構造を理解できないからです。これはGrafanaプラグインのその他の改善と同様に、ロードマップに含まれています。
また、ユーザーが存在しなくなった古いデータの時間範囲を問い合わせしようとしていることがわかります。これはデータ保持期間が延長されたことをお客様に高く評価していただいていることを示しています。先日、リテンションを31日から92日に延長しましたが、さらなる延長をすべきかどうか、今後も注視していきたいと思います。
よくある間違いや適切な SQL 構文の誤解に関連する多くのエラーが見られました。これはユーザーのトラブルシューティングへのサポートに、ドキュメントでさらにいい事例やエラーの説明を提示できることを示唆しています。
開発者向けドキュメントで、今後の機能追加をご確認ください。
Workers Analytics Engineは今すぐ使い始めることができます。Analytics Engineは現在、90日間の無料延長付きのオープンベータ版です。 今すぐ使い始めるか、あるいはDiscordコミュニティに参加するチームと会話することもできます。