一筋縄ではいかない、Pawooとマストドンのデータ分析について

こんにちは。新卒エンジニアのtohhyとpotato4dです。今回の記事では、新卒研修の一環として行っている、Pawooのデータ解析基盤の整備業務について紹介します。

Pawooのデータとマストドンの思想について

Pawooの開発で社として特に意識している事柄として、マストドン本家の思想の尊重があります。

マストドンは成り立ちとして、SNSというもののあり方に対する問題意識からスタートしたOSSであり、設計の根底には開発者の思想があります。マストドンのランディングページの最下部に特徴として列挙されている項目が、そうした思想の一端を表しています。

マストドンの特徴

この「マストドンの特徴」の中に、トラッキングに関する言及があります。「広告もトラッキングもありません」という記述がそれです。

Pawooは本家マストドンからフォークして実装されており、独自の機能を持ってこそいますが、本家に対して変更を提案したり、本家で生じた変更に追従したりと、相互に密接な関係を持って開発を行っています。マストドン開発者のEugen氏は個々のインスタンスでトラッキングなどを導入することは自由だという見解を示していますが、だとしても、ピクシブとしてはできる限り本家の思想を尊重する形でインスタンス運営をしていきたいと考えています。

Pawooの現時点でのポリシーは以下の通りです。

トラッキングコードを利用したユーザ追跡はしない
ただし、より良いサービス提供のため、サービスの結果生じたログの解析は行う
利用者の行動データが社外に流れるような仕組みの導入は避ける

このポリシーのもとでは、Google Analyticsのような外部のアクセス解析ツールを利用することはできません。ユーザの行動情報がPawooやピクシブの外に出てしまい、意図しない形で広告などに利用される可能性があるからです。一方で、Pawooのように規模の大きなインスタンスになると、統計データを解析することなしには、安定したサービスを提供したり、必要な施策を考えたりしていくことは難しくなります。

したがって、私たちのミッションは、サーバに残っているログやデータのみを使うという制約のもとで、サービス運営に役立つ知見を可能な限り収集していくことです。

研修のスタート時点では、Pawooにはデータ解析に関する基盤がほとんどなく、日ごとのユニークユーザの数すら分からない状態でした。そのため、インフラ担当者にログの形式変更や出力先を調整してもらったり、UAをログに残すためにアプリ版Pawooにプルリクエストを送ったり、社としてPawooのデータ管理にどのようなポリシーを持つか決定するようお願いしたり、あちこち駆け回るところからのスタートとなりました。

Pawooの構成とデータソース

Pawoo.netの構成を再掲します。

structure

PawooはAWS上に構成されているRailsアプリケーションです。データ解析を行うにあたり、まず上記のような構成から、有用な情報が得られそうなデータソースを洗い出す必要があります。候補として考えられるのは以下のようなものです。

ELB（ロードバランサ）のログ
nginx（Webサーバ）のログ
Railsのログ
Sidekiqのログ
ストリーミングサーバーのログ
アプリケーションデータベース

それぞれの内容を吟味した結果、今回の研修では、nginxのログとアプリケーションデータベースの内容を軸にして解析を行っていく方針になりました。

注目する指標の選択

続いて、Pawooのサービスとしての成長を測る指標としてどのようなものが適切かを考えました。ここにもマストドン特有の事情があり、様々な困難がありました。

例えば、マストドンは単一のタイムライン表示ページが主役となるSPAであり、ユーザの主要なアクティビティを通じてページ遷移がほとんど起きません。したがって、PV数でサービスの盛り上がりを測ったり、リファラを用いて行動を分析したりといった、通常のWebサービスに対するアプローチをそのまま適用することは難しくなります。そこで、こうしたサービスの特性を踏まえて、どのような指標をKPIと考えるかを決めていく必要があります。

私たちが直面したもっとも大きな問題として、マストドン特有の機能であるリモートフォローのデータの扱い方をどうするかという点があります。マストドンでは、あるインスタンスに所属しているアカウントから、別インスタンスのアカウントをフォローすることが可能です。これをリモートフォローと呼びます。

リモートフォローしたユーザのトゥートは、連合タイムラインと呼ばれるタイムラインに、あたかもインスタンス内の他ユーザのトゥートと同じようにシームレスに表示されます。複雑な機能ですが、データベース上ではとても簡単に表現されていて、リモートフォローが発生した時点でローカルインスタンスにはアカウントのレコードが発行され、またリモートのトゥートが取得された時点でトゥートのレコードが発行されます。要するに、単純にトゥートやアカウント情報をコピーしてきて保持しているだけです。

したがって、Pawooのデータベース内には、pawoo.netで生じたトゥートやアカウント、mstdn.jpで生じたトゥートやアカウント、friends.nicoで生じたトゥートやアカウント……こうしたものが全て入り混じって存在します。ここから、本当に私たちが注目したいデータを抽出していかなければいけません。この場合も、何を指標とするかが悩みどころです。例えば、トゥートに対するお気に入り数の面からPawooの盛り上がりを測るというシンプルな分析にしても、

PawooユーザによるPawooのトゥートへのお気に入り
Pawooユーザによる外部のトゥートへのお気に入り
外部ユーザによるPawooのトゥートへのお気に入り
外部ユーザによる外部のトゥートへのお気に入り

の4つのうち、どこからどこまでを考慮するのかを考えなければいけません。これは答えが一つに決まるような問題ではないので、分析指標の選択については今も試行錯誤を続けています。

データの抽出と整理、可視化

どのような指標を収集するかを決定したら、いよいよログ処理のための基盤構築を開始します。やるべきことは、定期的なログ加工と可視化手段の提供です。

初めのうちは暫定的な措置としてnginxのログファイルに対して定時にシェルスクリプトを走らせ、数値を取得するバッチ処理をしていましたが、分析が複雑化するにつれて対応が困難になってきたため、Amazon Athenaを利用したログ管理に移行しました。

Amazon Athenaは、Amazon S3上に蓄積したデータに対してSQLを用いて問い合わせを行うことができる分析サービスです。

高度な分析を行うにあたり、インフラ部のエンジニアに依頼し、Pawooで生じたnginxログをfluentdを経由してAmazon S3に送信する仕組みを構築してもらいました。こうすることで、前述のような複雑な条件での検索を容易に実行できるようになります。

現在はAWS上にログ解析用のEC2インスタンスを立て、そこから定期的にAthenaへデータ取得のSQLを発行する仕組みを作り、必要な指標を算出しています。

ユースケースに応じた可視化の事例

算出した指標は、様々なインターフェースを介して社員それぞれにとって使いやすい形で提供されるようにしました。以下に例を示します。

Slack

社員向けに提供しているインタフェースの一つに、SlackによるBot通知があります。

ログ解析基盤が取得した情報はスプレッドシートやデータベースに蓄積されていく仕組みになっていますが、こうした情報をPawooに関わる全ての社員に定期的に確認してもらうことは難しいです。

一方、サービスの異常に気づくためには、正常な状態を知る必要があります。普段からPawooの数字がどのように推移しているかを知っていなければ、異常な事態が起きているかどうかや、それがどの程度の異常なのかを把握することは困難です。そのため、Pawooに生じた何らかの大きな動きや施策の結果を、特別に意識しなくても把握できるような手段が必要になります。

こうした問題に対応するインタフェースとして、私たちは社員間のコミュニケーションツールであるSlackの通知を採用しました。エンジニアからビジネス職まで、様々な人が閲覧するチャンネルに、Pawooの概況を要約したレポートが常に流れる仕組みを構築しています。

Slack Notification

re:dashの利用

また、BIツールであるre:dashも導入しています。

Pawooの分析に携わるメンバーが問題解決のためにデータを掘り下げて見ていきたい場合は、逆にスプレッドシートにまとめられた数字やSlackに流れる簡易レポートでは不十分な場合があります。

そのため、BIツールであるre:dashを導入し、次のアクションのために積極的にデータを解析できるようにしました。 re:dash上ではアプリケーションデータベースやAthenaなど複数のデータソースから得られる情報を横断的に、かつインタラクティブに掘り下げて見ていくことができ、Pawooの方針を決定するマネージャなどが日々活用しています。