こんにちは、タレンティオの森脇です。

先日、SentryのSession Replay機能が、GA版として公開されましたので紹介します。

Sentryとは

Sentryとは、開発者向けのエラートラッキングとパフォーマンス監視のプラットフォームです。例えば、エラートラッキング機能では、アプリケーションでエラーが発生した場合に、Sentry上でスタックトレース・該当のソースコードなどが確認できます。

Session Replayの紹介

Session Replayは、ユーザーの行動を動画のように再現し、エラーの発生時・発生前後の状況を確認することができます。

今までのSentryが提供する情報だけでは、再現できない問題の解決に時間がかかる場合がありました。 Session Replayでは、ユーザーの行動を視覚的に確認でき、ネットワークリクエスト、DOMイベント、コンソールメッセージ等のより正確な情報を元にトラブルシューティングが行えるようになります。

それでは、実際にどのように見えるかを確認してみます。

SDKのインストール

Session Replayを利用するには、Sentry SDKの Version 7.27.0以上が必要です。

yarn add @sentry/browser

セットアップ

Sentryの初期化時に、以下のように定義します。

examplePublicKeyには、自身の環境のKeyを設定してください。

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://[examplePublicKey]@o0.ingest.sentry.io/0",

  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,

  integrations: [
    new Sentry.Replay({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
});

以上で完了です。

動作確認

確認のために、テキストボックスに特定の文字列を入れると、例外を発生させます。

<input
 type="text"
 onChange={e => {
    console.log(e.target.value)
    if (e.target.value == 'exception') {
        throw new Error('exception occurs')
    }
  }}
/>

画面を操作しエラーを発生させると、Sentry上でエラーが確認できます。以下のようなブラウザのDeveloper Consoleに近い情報を確認できます。

タイムライン
ユーザの行動リプレイ
パンくず
console
network
DOM Events

session replay

再生ボタンを押すと、ユーザの行動を動画のように再現できます。

（実際にTalentioで動かしたときのイメージ）

Session replayの動画

consoleへの出力内容は、タイムラインと共に確認できます。

console

エラー発生時のユーザの画面操作や、DOM・コンソールの情報が明確に分かります。

Privacyの対策

Session Replayでは、ユーザ画面の表示・入力データは、デフォルトでは*でマスクされます。また、テキストデータだけではなく、img,object,iframe等のメディア要素もブロックされるため、個人を特定するデータはSentryへ送信されません。ただし、一部のplaceholderがマスクされていないケースが発生したため、正しくマスクされない箇所は以下で紹介する方法で個別対応が必要です。

特定のDOM要素に属性 or CSSクラスを追加することで、その内容を記録しないようにすることも可能です。

例えば、サイドメニューののDOMにdata-sentry-blockを付与すると、サイドメニューは空白として表示されます。

<div data-sentry-block>
// sidemenu content
</div>

空白のサイドメニュー

パフォーマンスへの影響

Session Replayでは、DOMの変更を検知し、定期的にSentryへデータを送信しています。そのため、多少のオーバヘッドは発生していますが、最適化のための対策が行われているため、確認した環境ではユーザが体感できるほどの影響はありませんでした。

パフォーマンス最適化のための対策

DOMの変更の検知には、ブラウザのAPIであるMutationObserverを利用している
DOMの変更発生時に、全てのDOMを送信するのではなく、初回のスナップショットからの差分だけ送信している
サーバへ送信するDOMは、gzip圧縮されており、圧縮はWeb Workerによりバックグランドで行われている
画像などの静的アセットはクライアントから転送せず、Sentryダッシュボードでの動画の再生時にアセット元のホストサーバーから直接取得されます。

実際に確認しても、一度に送信されるデータは数十バイトほどでした。

価格

エラー監視等と同じく、従量課金となっており一定数を超えると追加料金が発生します。

docs.sentry.io

まとめ

Session Replay機能は、ユーザーの行動が正確に確認できるようになるため、再現が難しいエラーのトラブルシューティングの工数削減が期待できます。

導入も容易で、既にSentryの有料プランを利用している場合は、一定数までは追加費用無しで利用できるのでおすすめです。

宮下(mizzy)です。

タレンティオでも技術ブログやりたいね、という話になり、始めることになりました。よろしくお願いします。

技術ブログをなぜやるのか、という点を明確にしないと、メンバーのモチベーションが維持できず、継続ができないので、始めるにあたってまず最初に、やる目的や意義を明確にし、メンバーと共有する、というところから始めました。

せっかくなので、社内向けにまとめた技術ブログをやる目的や意義を、タレンティオ技術ブログの最初の記事として公開したいと思います。

目的・意義は以下の5つの観点で整理しました。

学習促進
読み手を意識したわかりやすい文章を書く技術の向上
対象への理解を深める
よりよい技術や課題解決方法の導入促進
その他の副次的な効果

それぞれについて説明します。

学習促進

タレンティオには、技術書の購入などを補助する学習支援手当や、各自が自由に技術的なトピックを選び、学習して発表を行う日を月に一度設けるTech Dayと呼ばれる取り組みなど、学習のインプットとアウトプットを促進するための仕組みがあります。

技術ブログを書くことも、このような学習促進の一環として捉えています。

読み手を意識したわかりやすい文章を書く技術の向上

日常業務やTech Dayでは、社内に向けて文章を書くことがほとんどですが、技術ブログでは社外に向けて書くことになります。社外向けとなると、読み手や書くべき内容が変わり、文章の書き方も変わってくるため、読み手を意識したわかりやすい文章を書く訓練になります。

読み手を意識したわかりやすい文章を書く技術は、どのような職種であっても役に立つはず、と考えています。

対象への理解を深める

仕事で利用している技術や学んだ技術などを文章にすることで、自分の中で理解が曖昧な部分が明確になります。また、読み手を意識することで、質問やツッコミなどを想定し、それに対して答えられるよう、更に深く調査したり、内容を整理したりします。これにより、対象への理解をより深めることができます。

よりよい技術や課題解決方法の導入促進

社外に向けて記事を書こうという意識は、よりよい技術や課題解決方法を導入するモチベーションになります。それによって、自社で運用しているサービスもより良いものになっていきます。

また、ブログ記事にするためには、やったこと、解決したことなどを、抽象化・一般化・言語化することが必要となります。課題を抽象化・一般化・言語化することによって、問題意識の共有がしやすくなったり、一般的によく知られているより良い技術や手法を適用しやすくなったりすることが期待できます。

その他の副次的な効果

タレンティオやタレンティオの中の人のことを社外の人に知ってもらうことで、会社の認知や採用への良い効果があるかもしれません。

また、業務ではOSSを活用しており、オープンなコミュニティによるたくさんのアウトプットに支えられています。我々もアウトプットすることで、オープンなコミュニティへの恩返しが少しでもできれば、と考えています。

もしかしたら社外の方から、アウトプットしたことに対して有益なフィードバックが得られるかもしれません。

ただ、これらはあくまでも「副次的」なものなので、これら自体を目的にはしない方が良いと考えています。

参考にした記事

技術ブログをやる目的・意義を整理するにあたって、以下の記事を参考にさせていただきました。ありがとうございます。

余談: 会社ブログと個人ブログ

上に書いた技術ブログをやる目的や意義は、別に会社ブログではなくとも、個人ブログにもあてはまることがほとんどだと思います。なので敢えて「会社の技術ブログ」ではなく「技術ブログ」としていますし、記事を書くのは会社ブログでも個人ブログでもどちらでも構わない、と思っています。

自分が会社員だった頃は、会社の技術ブログはなかったので、個人ブログに書いていましたが、会社のことも問題のない範囲で書いていて、それで何か咎められたことはないですし、会社の認知や採用などに良い影響をもたらしていました。

もし、タレンティオのエンジニアの大半が既に個人ブログで技術記事を書いているのであれば、Ubieさんのように個人ブログを集めたポータルサイトの形にしていたと思います。

タレンティオはそうではないので、技術ブログを書く場を会社で用意する、という形にしましたし、全メンバーの合意を得た上でそのようにしています。

会社で場を用意しましたが、もし個人ブログで書きたい、という人がいれば、個人ブログで書けば良い、とも思っています。

また、会社ブログといえど、個人も大切にしたいので、個人のはてなIDで記事を書いても良いですし、会社のメールアドレスで取得したはてなIDで記事を書いても良い、という形にしています。（自分は個人のはてなIDでこの記事を書いています。）

陳腐な結論になってしまいすが、それぞれにメリット・デメリットありますので、それを理解した上で、目的を実現するためにはどういう形にするのが良いのか、というのを会社やメンバーの状況を踏まえた上で検討し、メンバーの合意を得る、というのが重要なんじゃないかな、と考えています。

ちなみに、この検討や合意のプロセスには、GitHub Discussionsを活用してみたのですが、そのことについていずれ記事として書くかもしれません。

Talentio Tech Blog

Sentry Session Replay機能の紹介