この記事は クラウドワークスAdvent Calendar 2015 18日目の記事になります。
ことのはじまり
私がクラウドワークスにジョインしたのは2014年11月になりますが、入社直後に始めたお仕事が表示速度改善になります。数ヶ月の改善作業の末に目標値を超えたもののひとつの課題が残っていました。「多くの開発者が関わるサービスでその表示速度をどのように保っていくか」です。
理想を考える
表示速度も障害監視と同じく毎回人がチェックするようなものではないことは明らかです。抜け漏れはもちろん、優先度が低くなりがちでそのうち忘れられるでしょう。
問題があれば通知が来てそれに対してアクションする。というのが理想だと考えられます。
理想に近づくには何が必要か
まず考えるのは外部の表示速度監視サービスの利用です。いくつかあるものの数が少なく、また監視対象のページを増やすと料金も増える傾向があります。そして、そもそもクラウドワークスは表示速度改善の指標に domContentLoaded と Speed Index を用いてます。2015年1月時点でこの Speed Index の計測をサポートしているのは WebPagetest のみだったことがあり、自ずと選択肢は大分限られたものとなりました。
WebPagetest を利用した監視方法でお手軽なのは、本家 WebPagetest.org の API 経由での利用になります。この方法は後ほど述べる理由によりクラウドワークスでは採用できませんでしたので WebPagetest.org の提供している AWS EC2 の AMI を利用することにしました。
通知方法を考える
クラウドワークスでは Slack が広く使われており、エンジニアに通知するには最適です。しかし残念ながら WebPagetest は計測するだけの機能しか用意されていません。
ツールを組み合わせる
ここで他のツールの出番になります。 Datadog では WebPagetest に不足している 充実したロギングの機能と Slack へのアラートがサポートされており、ここではまさに最適なツールです。ここまでできればあとは構築するのみです！
構築する
以下のような構成になります。
プライベートな WebPagetest を用意する
こちらの記事を参考に構築を行います。AWS の VPC の設定などひっかかりポイントがいくつかありましたが、最低でも共有しておきたいのは以下になります。
ポイント1. WebPagetest に必要なインスタンスは2つ以上
インスタンスの1つは司令塔的な Web Server になり、基本常時立ち上げておきます。インスタンスタイプは micro で十分です。もう一方は計測を行う Test Agent になります。こちらは計測時にのみ起動し、表示速度の計測が終わると落ちます。
ポイント2. 計測のために安定した回線が必要
AWS EC2 はインスタンスタイプによって回線速度が異なるので Test Agent は安定した表示速度監視を実施できるインスタンスタイプを選ぶ必要があります。こちらの記事が参考になるかと思います。
監視スクリプトを書く
本家と同じくプライベートな Webpagetest でも API を利用することができます。また Datadog からも API を利用するための Gem が提供されているのそれを利用してスクリプトを書き、cron で定期実行するようにします。
Datadog で閾値とアラートの設定する
本家 Webpagetest を利用できないことが判明したのはここです。 1日1回の測定では Datadog のアラートがワークしない状況でした。最低でも1日2回測定する必要があったのです。
おわりに
これで表示速度を監視できる用意はできました。実際遅くなるとこのように Slack に通知がきます！
まだ弊社でも試験運用の段階ですのでフィードバックいただけるとうれしいです。
またこの記事が速度監視で困っている誰かの参考になれば幸いです。