Beeeat’s log

Beeeat’s log

プログラミングで出くわした知識やツール、日常生活、働き方その他色々なことをメモしていくブログ

「Page Analytics」で自サイトのアクセス解析を視覚的に把握する

自サイトのアクセス解析をする時に Google Analytics (以下,GA) をよく使うが、そもそも GA にアクセスするのが面倒だったりクリック率を把握するのがパット見でわからなかったりする.

そんな風に思っていたら「Page Analytics」という Chrome 拡張が便利だと聞き,使ってみたら感動したので今回はそれについてまとめる.

前提

アクセス解析したいサイトに GA が設定されていること. はてなブログでの設定方法はこちら.

help.hatenablog.com

使い方

以下の拡張機能をインストールする.

chrome.google.com

アクセス解析したいサイトを表示する(いつものように自分のブログを例とする).

f:id:bake0937:20201019224834p:plain

Page Analytics のアイコンを見ると OFF の状態になっているためクリックして ON にする.

f:id:bake0937:20201019224903p:plain

すると,PV数や平均ページ滞在時間などリアルタイムの情報を把握できる.

さらに,画面に表示されているリンクのクリック率も把握できる.

f:id:bake0937:20201019225049p:plain

左下の日付をクリックすると指定した期間のアクセス解析の情報も表示できる.

f:id:bake0937:20201019225601p:plain

まとめと所感

今回は Page Analytics という Chrome 拡張について紹介した.おそらく普段からアクセス解析をしている人にはおなじみの拡張機能だとは思うが,GA の拡張機能は「Google Analytics Debugger」しか使ったことがなかったので,こんな便利なものがあることを知って少し驚いた.

chrome.google.com

自サイトのクリック率が視覚的に把握できるのはかなりテンションが上がった. アクセス解析の情報も把握できるのでこれからは上手く活用していこうと思う.

ISUCON10 の練習・予選・本選でやってきたことをふりかえる

実は先月開催された ISUCON10 で「Team MN」のメンバーとして参加しました.

isucon.net

そして本選に出場することができました!!!(正直今でも驚いている...)

今回のISUCONでは主にアプリ・DB 周りの分析を担当したため,今回はISUCON10 の練習・予選・本選で私が分析まわりでどんなことをやってきたのかをまとめようと思います.

アプリ・DBの分析まわりで少しでも参考になれば幸いです...というか,他のチームがどう分析しているのか気になる...

本記事で書かないこと

  • 本選での技術的な作業内容
    • 内容がさらに長くなるため別記事にてまとめようと思います🙇‍♂️

前回のISUCON9では...

実は去年も参加していました(初参加でした).結論から言うとあっさり予選落ちしました... 今思うと当時の私は何をすれば良いのかわからずひたすらアワアワしていただけでした...

engineerblog.mynavi.jp

ISUCON10 での私の役割

前回の反省を踏まえて,「今年はせめて何かしら手を動かせるようになるぞ」と思いで参加しました. チームで練習を何回かやった結果,主にアプリ・DB 周りの分析周りを担当しました. 各担当については下記を参照.

zenn.dev

そのため今回の ISUCON では「分析した結果を共有し,チームメンバーがアプリケーションの仕様について調べる時間を可能な限り減らし,生産性を上げる」というのが自分の役割だと判断し,取り組むことにしました.

やったこと

hirosuzuki はアプリケーション,beppu4 はインフラ周りを取り組んでいる中,私は Google スプレッドシートを使って下記のことに取り組みました.

やることの洗い出しとロギング

まずは競技開始時(Opening)や終了前(Closing)にやることが決まっていることは事前に洗い出しておきました. 本番では特に緊張するため,やり忘れが起きる可能性が非常に高いため結構役に立ちました.

f:id:bake0937:20201011183853p:plain

競技中(Playing)にやったこともスコアとともに適宜ロギングし,ふりかえりができるようにしました.

ER図の作成

DB のテーブルの全体像を把握するためにER図を作成します.ER図は MySQL Workbench で作成しました.

課題のアプリーケーションが起動したタイミングで手元の PC から ISUCON の競技用マシンに SSHポートフォワーディング で接続し,MySQL Workbench でER図を作成します.DB に接続さえできれば下記のように簡単にきれいなER図を作成することができます.(下記は予選のアプリケーションである ISUUMO のER図です.)

f:id:bake0937:20201011153629p:plain

アプリケーションが複雑だった場合やテーブル数が想定よりも多い場合はER図を印刷し,わかったことをメモしていきます. (下記は本選のアプリケーションである XSUCON のER図です.)

f:id:bake0937:20201011154102j:plain

テーブルの調査

各テーブルのレコード数やカラム,インデックス情報をシートにメモしました. SHOW INDEX などの構文をテーブルごとに実行するのも良いですが,クライアントツールを使うと該当箇所を箇所をクリックするだけでわかりやすく表示され,メモしていくのが早かったです.

私は DBeaver を使って下記のようにスプレッドシートにメモしていきました. (MySQL Workbench はあくまでER図の作成でしか使ったことがなかっため,普段使っている DBeaver で調べました.)

f:id:bake0937:20201011154705p:plain

CRUD分析

ヘッダ列にアプリケーションのファンクション名を,ヘッダ行にテーブル名を記入し,どのファンクションでどのテーブルにどんな SQL が実行されているのかを調べました.

作業の流れとしてはテーブル名でアプリケーションのプロジェクトを grep 検索し,該当の箇所のファンクションに書いてある SQLスプレッドシートにメモしました.

f:id:bake0937:20201011163802p:plain

コード量の多いアプリケーションの場合,調べ切るに時間が掛かりますが,これによりどのファンクションの処理がオンメモリキャッシュできそうなのかがわかります

例えば各ファンクションから様々なテーブルに対してSQL文が実行されていますが調べていくと各ファンクションからUPDATE文やDELETE文では無く,SELECT文またはINSERT文しか実行されていないテーブルが実は見つかったりします.

その場合はファンクションでオンメモリキャッシュ化の処理を実装することでスコアが上がる可能性があるため,見つけたら下記のように別シートでメモしていきました.

f:id:bake0937:20201011163928p:plain

※オンメモリキャッシュ化の処理の実装後,ベンチマークが fail や不安定になる場合は元に戻します.

遅い SQL の調査 

hirosuzuki が事前に用意した「isucon-viewlog」にあるSQLログ解析には総実行時間が大きい順で SQL が表示されるため,その SQL を EXPALIN で実行計画の情報を取得し,INDEX が貼れそうな SQLスプレッドシートにメモしていきました.

f:id:bake0937:20201011164047p:plain

isucon-viewlog はベンチを回した後のログを利用し,各ログを一覧で見ることができます.

f:id:bake0937:20201011162857p:plain

このツール,結構便利なのですがリポジトリを見ると README が無さそうなので記憶があるうちにプルリクを投げようと思います(汗).

github.com

ペアプロ・N+1 の調査

上記までの作業を ISUCON の練習・予選・本番で私が担当してきたことでした. 最初のうちは一つ一つの作業に時間が掛かってしまいましたが,回数を重ねるごとに取り組む課題アプリケーションは違いますが作業が段々慣れていきました.

慣れていくと飽きてくるように思いますが,「余裕が生まれた」とも言い換えることができます. そのため競技の後半の時間は hirosuzuki が改修したコードを git clone し,N+1になっている処理の調査やペアプロをしコードを多少読むことができて良かったです.

取り組んだ結果

役割分担をする前は情報共有が上手く行かなかったり,各メンバーが適宜 DB に接続して「SHOW TABLES」などを実行するなど無駄が作業が多い状態でしたが, 各メンバーからの「各テーブルのリレーションを知りたい!」,「Aテーブルのレコード数は?」,「Bテーブルはキャッシュできそう?」のような質問に対して即答・または私が作成したシートを見るようになり,無駄な作業を減らせたことで各々の担当領域に集中してもらうことができました. また予選では早いうちに「アプリ-DB-DB」サーバの構成にする意思決定をすることができたきっかけにもなりました.

ISUCON を通して学んだこと

チューニングできそうな箇所がわかってきた

今までは APM を何となく眺めたり,「N + 1 は bullet っていう gem を入れればわかるんでしょ?」程度のものでしたが,アプリケーションサーバの負荷が大きく,DBサーバの負荷が大きい場合は SQLボトルネックがある,N + 1はループ文の中にある SQL を発行している処理を見つけ出すなど,実際に手を動かせるようになってきました.

仕様を把握するためのヒントを得ることができた

大事な箇所は印をつけるのは勿論,その仕様の裏を推測する・言い方を変える・仮設(または問い)を立てることで,ただ書いてあるドキュメントを何となく読むのに比べて素早く集中して仕様を理解できることが今回でよくわかりました.

チームメンバーの技を盗むことができた

エディタやツールの使い方,ログや仕様の着眼点や読み方,物事の考え方など自分には無い視点だらけで沢山吸収し,することができました(特に beppu4 のドキュメントの読み方や着眼点はとても参考になった).普段の業務では一緒に仕事をしていないメンバーなこともあり ISUCON が無かったら吸収できなかったかもと考えると,とても良い時間を過ごすことができたと実感しました.

まとめと所感

今回は ISUCON10 で私がやったことについてまとめてみました. 去年は自分が何もできなかった分,チームに貢献できたのが嬉しかったです.ましてや予選を突破して本選に出場できたのは去年の今頃の自分では考えられないほどの快挙でした.

チューニングできそうな箇所を見つける力がまだまだな点やスプレッドシート頼りな作業ではありますが今回の経験を業務でも活かし,更に磨いていこうと思います. 加えて自分は何かしらの方法でチームの生産性に貢献するのが結構好きなんだなぁとも改めて思いました.

本選の結果は12位という何も賞がもらえない結果となりましたが,ISUCON を通して様々なことを学ぶことができたのと自分ができることの幅を広げることができました. ここまでの結果を残せたのはチームメンバーの hirosuziki,beppu4 のおかげです!ありがとうございました!

そして ISUCON の運営・スポンサーの皆さん,完全オンラインという新しい形式で面白い課題と環境を提供頂きありがとうございました!

来年以降の参加は未定ですが,もしやるならアプリメインで挑戦してみたいです,

GitHub の Slack App の使い方について改めて調べてみた

もう開発ではおなじみだとは思うが GitHub の Slack App を使えば GitHub でのコメントやプルリクエストなどのイベントを Slack のチャンネルに通知することができる.

おそらく殆どのチームが利用しているとは思うがこの GitHub の Slack App について知らなかったことや勘違いしていたことについて今回はまとめてみる.

設定方法

このヘルプセンターの通りに進めれば簡単に設定できる

slack.com

各種通知の意味について

GitHub の Slack App ではデフォルトで通知を行う機能として下記がある.

  • issues (イシュー)
  • pulls (プル)
  • statuses (ステータス)
  • コミット
  • deployments (デプロイメント)
  • public (パブリック)

「issues」や コミット は何となくわかるが,「statuses」や「public」はどんな通知なのかパット見わからない... 調べようにも先程あげたヘルプセンターに各通知の意味については載っていない...

「ではどうすればわかるのか?」となると思うが下記の紹介ページにある「Learn more about the GitHub and Slack integration」のリンクにアクセスする必要がある. (正直言うと文字が小さくて気が付かなかった..)

するとアクセス先は GtiHub リポジトリで,ここの README に各通知についての説明が記載されている. 通知についての説明は下記にある.

github.com

どうやら「statuses」はプルリクエストのステータス(CI の進捗状況など)について,「public」はプライベートリポジトリからパブリックリポジトリに変更した時の通知だということがわかる.

不要な通知は/github unsubscribeで解除する必要がある

先程記載したが,GitHub の Slack App ではデフォルトで通知を行う機能がある.しかしこの中で不要な通知がある場合は/github unsubscribeを実行する必要がある. 例えば,「statuses」,「deployments」,「public」が不要な場合は通知しているチャンネルで/github unsubscribe owner/repository statuses,deployments,publicを実行すれば通知を解除できる.

ここに関してはヘルプセンターの「以下のスラッシュコマンドも通知のカスタマイズに便利です。」という項目にサラッと書いてはいる.しかし,私は「/github subscribe 〜を実行するとそこで指定した通知しかチャンネルに通知されなくなる」と勝手に勘違いしてしまっていた.

まとめと所感

今回はかなり基本ではあるが GitHub の Slack App についてまとめてみた.かなり基本的な内容ではあったが,通知の設定自体はたまに行う程度でその度に忘れてしまっていたので改めてまとめることができて良かった.もう忘れない...はず!!!

Jira の「課題」に定型文(テンプレート文)を設定する方法

最近個人的に Jira を使い始めてみた.前々から話は聞いていたが,確かにスクラムやカンバンなどのアジャイル開発をする時に良いツールだと実感した.

機能が沢山ある分,カスタマイズ性が高いこともよくわかった. そこでかなり初歩だとは思うが課題を作成する時に定型文(テンプレート文)を設定したくなった. 調べてみたら以下のようなやり方を見つけた.

community.atlassian.com

qiita.com

www.ricksoft.jp

確かに方法は何となくわかったが.「思っていたより手間が掛かりそうだなぁ...」という印象だったため,引き続き自分で色々触ってみると簡単に設定できる方法がわかったためまとめてみる.

方法

すごい簡単だった.サイドバーにある「プロジェクト設定」→「課題タイプ」から設定したい課題タイプを選択し(今回は「Story」を選択),説明をクリックすると「既定の説明 (オプション)」の項目に定型文を設定することができる.

f:id:bake0937:20200928220644p:plain

課題を作成してみると以下のように定型文が入った状態になっていることを確認できた.

f:id:bake0937:20200928215819p:plain

まとめと所感

今回は Jira の「課題」で定型文を設定する方法についてまとめてみた. ひょっとしたら最初に私が調べた方法は定型文の意味合いが少し違っていたのかもしれないが, ひとまず今回やりたったレベルの定型文を設定できたのでひとまずOKとした.

Jira を使い始めてまだ2日くらいなので,来月くらいまでひとまず使ってみて使用感やどのように使ったかをまとめていこうと思う.

create-nuxt-app で現在のディレクトリにNuxtプロジェクトを作成する時に気をつけること

Nuxt.js の勉強していた時に最新のcreate-nuxt-app(v3.3.0)を使ってNuxtプロジェクトを作成した時にCan't create . because there's already a non-empty directory . existing in path.というエラーを踏んでしまったのでその時にどう対応したのかのメモをまとめておく.

前提

使用するファイルは以下になる.

# sample-nuxt/docker-compose.yml
version: "3"
services:
  frontend:
    build: ./frontend
    ports:
      - 8080:8080
    command: /bin/sh -c "yarn dev"
    volumes:
      - ./frontend:/app
      - frontend-node_modules:/app/node_modules
    environment:
      - HOST=0.0.0.0
      - PORT=8080
    tty: true
volumes:
  frontend-node_modules:
# sample-nuxt/frontend/Dockerfile
FROM node:12.9.0-alpine

ENV APP_HOME /app
ENV PATH ${APP_HOME}/node_modules/.bin:$PATH
ENV TZ Asia/Tokyo

ENV HOST 0.0.0.0
ENV PORT 8080

WORKDIR ${APP_HOME}
ADD . ${APP_HOME}

RUN apk update \
    && apk upgrade \
    && yarn install \
    && yarn global add create-nuxt-app \
    && rm -rf /var/cache/apk/*

EXPOSE ${PORT}

CMD ["yarn", "dev"]

rails new .(現在のディレクトリでRailsプロジェクトを作る)のような要領で現在のディレクトリでNuxtプロジェクトコードを作ろうとするとエラーになった.

$ pwd
sample-nuxt
$ docker-compose run --rm frontend yarn create nuxt-app .
yarn create v1.17.3
[1/4] Resolving packages...
⠠ color-name@1.1.3(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added to [TLSSocket]. Use emitter.setMaxListeners() to increase limi

・・・省略・・・

warning Your current version of Yarn is out of date. The latest version is "1.22.5", while you're on "1.17.3".
info To upgrade, run the following command:
$ curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
success Installed "create-nuxt-app@3.3.0" with binaries:
      - create-nuxt-app

create-nuxt-app v3.3.0
Can't create . because there's already a non-empty directory . existing in path.
Done in 16.75s.

原因

本家のリポジトリを見てみると,どうやらプロジェクトの作成する先のディレクトリが空ではない場合はエラーになる仕様のようだ. 今回の場合,frontendディレクトリにDockerfileがあるからエラーになったと考えられる.

github.com

回避方法

仕様なので仕方ないため力技ではあるが,さらに新しくfrontendプロジェクトを作成し(つまりfrontend/frontendの中にNuxtプロジェクトが作られる状態になる),その後でfrontend/直下にNuxtプロジェクトのファイル・ディレクトリを移動するようにする.

$ docker-compose run --rm frontend yarn create nuxt-app frontend
yarn create v1.17.3
[1/4] Resolving packages...
⠈ graceful-fs@^4.1.6(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added to [TLSSocket]. Use emitter.setMaxListeners() to increase limit
・・・省略・・・
create-nuxt-app v3.3.0
✨  Generating Nuxt.js project in frontend
? Project name: (frontend) 
・・・省略・・・
各設定を入力していく
# frontend直下にNuxtプロジェクトのファイル・ディレクトリを隠しファイル込みで移動する.
$ mv frontend/frontend/{*,.[^\.]*} frontend
# frontend/frontendは削除する
$ rm -r frontend/frontend
# node_modules内のパス等の情報を更新させるためにyarn installし直す
$ docker-compose run --rm --service-ports frontend yarn install

これで,docker-compose upすればNuxtプロジェクトが起動される.

まとめと所感

今回は create nuxt-app v3.3.0 でプロジェクトを作成する時に少し躓いたことについてまとめてみた.

前(今年の春頃)に使っていた create nuxt-app では現在のディレクトリにNuxtプロジェクトを作成することができていたように思えた(先程のプルリクエストも今年の7月にマージされたようなので...)が,Railsプロジェクトの作成方法とごっちゃに考えていたようにも思えるため混乱しないように気をつける.

docker-compose run --rm --service-ports frontend create-nuxt-app -hでヘルプを見てもそれらしい便利なオプションも見当たらないため,今後のアップデートに期待かなぁと思いながら作業を再開した.

Rails で URL の末尾にスラッシュを付ける方法

SEOチームから URL の末尾にはスラッシュを付けて欲しいという依頼を対応した時に文字連結とかでゴニョゴニョしようとしたが,Rails で用意されている機能で簡単にできることがわかったのでメモしておく.

やり方

とても簡単でroutes.rbでルーティングの設定の最後にtrailing_slash: trueをつければ良い.

これで URL の末尾にスラッシュが付くようになる.

# routes.rb
get '/hoge/:id', to: 'hoge#show', trailing_slash: true

まとめと所感

今回は Rails で URL の末尾にスラッシュを付ける方法についてメモをした.SEO 的に URL の末尾にスラッシュが必要かどうかは,正直人によって色々意見があるとは思うがだが,個人的には統一はしておいた方が良いと思った.

今回はホントにちょっとしたメモだが,ちょくちょく対応しそうなので他にわかったことがあったらここに追記していく.

参考

api.rubyonrails.org

CLS(Cumulative Layout Shift)を調査する時に使ったツールやサービスをまとめてみた

Google が「Core Web Vitals(コアウェブバイタル)」という新しいWebの指標を2021年以降に導入予定ということで話題になっています.

web.dev

developers-jp.googleblog.com

Core Web Vitals は LCP(Largest Contentful Paint), FID(First Input Delay), CLS(Cumulative Layout Shift)の3つに分かれています.

今回は担当している Webサイトの CLS...つまりどれだけレイアウトのズレが発生したのかを調査する時に使ったツールやサービスをまとめようと思います.

Web Vitals

現状のスコアをサクッと知りたい場合は「Web Vitals」というChrome拡張を使えばすぐにわかります. chrome.google.com

インストール後,調査したいページで Web Vitals を押すとスコアが表示されます.CLS はスコアの値がより小さければ良いです.

f:id:bake0937:20200907073217p:plain

少し脱線しますがインストールした拡張機能が表示されない場合は拡張機能のマークを選択し,ピンマークを押すと表示されるようになります(地味にここで時間が掛かった笑).

f:id:bake0937:20200907073329p:plain

PageSpeed Insights

Google が提供しているおなじみの Web パフォーマンスツールです.

developers.google.com

調べたいWebサイトのURLを入力すると,スコアの他に「累積レイアウト変更」という名前で CLS のスコアと詳細について把握することができます.

f:id:bake0937:20200907233044p:plain

Web Vitals Leaderboard

Core Web Vitals を比較できるサービスのようです.つまり自分が担当しているWebサイトと競合でどれだけ差があるのかを比較することができます.

デフォルトでスコアのランキングが1位のWebサイトが載っているため,優秀なサイトを研究したい時にも便利です.

vitals-leaderboard.pazguille.me

f:id:bake0937:20200907230512p:plain


Chrome DevTools

Chrome DevTools には以下のように様々な機能があります.

Rendering

Chrome DevTools を起動した状態で「⌘ + Shift + P」を押した後に「Show Rendering」と入力するとRendering ドロワーが候補に表示されるため選択する.

f:id:bake0937:20200907065914p:plain

Console ドロワーの隣に Rendering ドロワーが表示されます.そして Layout Shift Regions にチェックを入れます.

f:id:bake0937:20200907065933p:plain

ページをリロードし,スクロールするとどの箇所で Layout Shift が発生しているのかを視覚的に把握することができて便利です.

f:id:bake0937:20200907065833p:plain

Lighthouse

ちょっと前まで拡張機能を入れないといけなかった Lighthouse が実は Google Chrome に搭載されております.

Chrome DevTools を起動した状態で Lighthouse タブを選択し, 「Generate report」を押すと,測定が始まります.

f:id:bake0937:20200907070652p:plain

少し待つと測定結果が表示されます.

f:id:bake0937:20200907071255p:plain

「Avoid large layout shifts」を見ると Layout Shift がどの箇所で発生しているのかを要素レベルで調べることができます.どの要素を改善すれば良いのかを調べる時に便利です.

f:id:bake0937:20200908001703p:plain

まとめと所感

今回は担当プロダクトの CLS を調査する時に使ったツールやサービスをまとめてみました. 色々と調べてみると.現在この Core Web Vitals について様々な人が試行錯誤をしながら対策している真っ最中な印象を受けました.

ザッと確認したい時は,Web Vitals と PageSpeed Insights, 具体的な対策を取る時は Chrome DevTools など場面によって使い分けています. ちなみに Web Vitals Leaderboard をきっかけに THEGUARDIAN というメディアサイトを知ることができました. CLS のスコアが良く,どのように保っているのかを知るために最近ちょくちょく見てます.

今回は調査についてまとめましたが,実際にやってみた対策についても内容がまとまったタイミングで書いてみようと思います.

追記 2020/11/05

PageSpeed Insights の下の方にサラッと Stack Overflowメーリングリストのリンクを見つけた.見てみると PageSpeed Insights の使い方についての質問の他にも CLS の改善方法について議論しているようなので,定期的に覗いたり思い切ってコメントしてみよう.

f:id:bake0937:20201105085058p:plain