DIGGLE開発者ブログ

予実管理クラウドDIGGLEのプロダクトチームが、技術や製品開発について発信します

パフォーマンス分析基盤の構築。S3やAthenaを活用して柔軟性の高いデータの取り扱いを実現した話

はじめに

DIGGLEではすでにDatadogを導入してパフォーマンス指標のトレースデータ*1は取れていますが、以下の課題がありました。

  • ユースケースを分けてパフォーマンス指標を取得したい
  • DIGGLEがターゲットとしたい企業やペルソナユーザーのデータのみを取り出すのが面倒
  • 開発時点でCIが動いた時に、分析結果をプルリクのコメントに出力したい
  • Datadogに保存されているパフォーマンス指標のトレースデータには有効期限がある

上記に対応する為にまずは調査を行いました。

Datadog API Clientによるデータの取得

Datadogに保存されているデータをAPI経由で取得することによって、必要なデータが得られないかを調べました。

結果としては、RUMデータは取得できそうでしたが、APMのトレースデータは現状ではAPI提供されていませんでした。

そしてCI起点でのパフォーマンス分析を考えると、リアルタイムにパフォーマンス指標データを取れない所からDatadogベースでは厳しいです。 またDatadogを選択すると有効期限の問題や、ターゲットとしたいデータを取り出すのが面倒という問題が解消できません。

上記などの理由によりDIGGLEでは、独自でパフォーマンス指標を取得する方針としました。 DatadogはDatadogで有用なのでそちらの利用は継続し、別途パフォーマンス分析基盤を構築して、そちらに分析用のデータを保存するイメージです。

パフォーマンス分析の概要

対象データ

顧客への価値提供に影響が強い部分の、ユースケース別の実行時間などのデータになります。 特定処理の実行時間から、細かい粒度だとSQLの実行時間まで対象としています。 またDIGGLEがターゲットとする、代表的なペルソナユーザーが処理したデータになります。

分析方法

それぞれのユースケース別の実行時間を分析する形になります。 パフォーマンス改善施策などの効果を測定する為に、リリース対応前後の実行時間をクエリ抽出して効果測定します。 また、代表的なペルソナユーザーのデータを定量データとして保持して、予期せぬタイミングでパフォーマンスが悪化していないかなどの時系列分析も行います。

パフォーマンス分析基盤の構成の検討

データ保存先

トレースデータの保存先としては以下のような選択肢が考えられます。

  • DB
  • NoSQL系
  • Bigquery
  • Redshift
  • S3
  • Athena

どの選択肢も一長一短がありますが、DIGGLEではS3へログデータとして転送する方針となりました。 既存システム性能への影響が小さく、S3から先へもAthenaでデータソース化するなど色々な選択肢が取れるためです。 またS3へ保存することにより、Datadogの有効期限の問題は解消されます。

構成

S3へのデータ保存が決まりましたので、パフォーマンス分析基盤の構成はおおまかに以下のようになりました。 3と4の構成についてはデータ保存後も柔軟に変更可能です。

1のRailsから標準出力への出力先を実ファイルへ変更すると、CIでの分析も可能になります。また独自プログラムで実行するのでユースケース分けや、データのフィルタリングについてもやりやすいという利点があります。

  1. ECSのRailsから標準出力にパフォーマンス指標データをログ出力
  2. Firelensを経由してFluent bitでログをS3へ転送
  3. S3に保存されたJSONデータをAthenaでデータソース化
  4. AthenaをデータソースとしてMetabaseからクエリでデータ分析を実施

対応内容

サーバーサイド

こちらはDatadogのソースなどを参考にしながら、Rails標準のActive Support Instrumentationで取得できるパフォーマンス指標はこちらで取得し、それ以外については独自で対象のメソッドをフックして、パフォーマンス指標をリクエストなどの処理ごとに取得するように対応しました。

インフラ

ECSのRailsからは標準出力でログ出力を行い、それがFirelensからFlunet bitに渡り、Fluent bitのrewrite_tagでS3へ振り分けを行います。

Flunet bitの設定例）

jsonデータのhogeキーの値がhogehogeの場合にS3に転送される設定例になります。

# rewrite tag
[FILTER]
    Name          rewrite_tag
    Match         *-firelens-*
    Rule          $hoge hogehoge target true

# output to s3
[OUTPUT]
    Name            s3
    Match           target
    bucket          target-bucket
    region          ap-northeast-1
    use_put_object  On
    total_file_size 1M
    upload_timeout  1m
    retry_limit     False
    compression     gzip

S3に保存したJSON形式のログデータはAthenaで以下のようなクエリでテーブル化が可能です。

CREATE EXTERNAL TABLE IF NOT EXISTS hoge (
  id int,
  name string
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
    'null.format' = ''
)
LOCATION 's3://target-bucket/'
TBLPROPERTIES ('has_encrypted_data'='true');

注意点としてはinteger型を定義した場合は、空白データを許容してくれなくなるので、ログ出力側で0などを出力する必要があります。

最終的にDIGGLEではAthenaをデータソースにMetabaseでクエリを実行する形式にしています。

フロントエンド

フロントエンドはサーバーサイドで作った仕組みに乗っかる形で、処理単位で複数のトレースデータをサーバーサイドに送信する形を取りました。

最後に

今回はパフォーマンス分析基盤の構築について検討から実際の構築まで紹介しました。性能観点と後々の柔軟性という部分で今回はS3へデータを保存する形になりましたが、他にも様々な選択肢があると思います。

この記事が、分析基盤構築などの一助となれば幸いです。

DIGGLEのエンジニアのchikugoがお送りしました。

We're hiring!

DIGGLE では共にプロダクトを開発してくれるエンジニアを大募集中です。

少しでも興味があれば、ぜひ下記採用サイトからエントリーください。
カジュアル面談も実施しているので、気軽なお気持ちでご応募いただければと思います！

https://herp.careers/v1/diggle/_dgvcOQcFfeqherp.careers

*1:トレースデータとはアプリケーションやサービスが実行する一連の操作を表す実行時間などを含むデータです