新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

Cloudflareが行うWorkers Analytics Engineを使用した計測サービス

2022-11-18

5分で読了
この投稿はEnglish繁體中文FrançaisDeutschPortuguêsEspañol简体中文でも表示されます。

Workers Analytics Engineは、今年の初めに発表された新ツールです。開発者や製品チームが、高次元、高カーディナリティ、楽なスケーリングな環境で、いかなる時系列分析も構築できるようになりました。チームがWorkersで実行するコードについてのインサイトを得たり、エンドカスタマーに分析を提供したり、使用量ベースの課金を構築したりすることを目的に、Workers Analytics Engineを構築しました。

How Cloudflare instruments services using 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コミュニティに参加するチームと会話することもできます。

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
Developer WeekAnalyticsLogsDataCloudflare Workers開発者Developer Platform

Xでフォロー

Cloudflare|@cloudflare

関連ブログ投稿

2024年10月09日 13:00

Improving platform resilience at Cloudflare through automation

We realized that we need a way to automatically heal our platform from an operations perspective, and designed and built a workflow orchestration platform to provide these self-healing capabilities across our global network. We explore how this has helped us to reduce the impact on our customers due to operational issues, and the rich variety of similar problems it has empowered us to solve....

2024年9月27日 13:00

Our container platform is in production. It has GPUs. Here’s an early look

We’ve been working on something new — a platform for running containers across Cloudflare’s network. We already use it in production, for AI inference and more. Today we want to share an early look at how it’s built, why we built it, and how we use it ourselves. ...