Etsyを支えるパフォーマンスアラートの技術 ～Velocity Conference 2015レポート #1～

こんにちは！kintone 開発チームの田中裕一(@yuichielectric)です。

O'Reilly Mediaがサンタクララで開催したVelocity Conference 2015に僕と佐藤鉄平(@teppeis)の2人で参加してきました。これから何回かに分けてそれぞれが面白いと思ったセッションの内容を紹介していこうと思います！

Velocity Conferenceとは

O'Reilly Mediaが主催しているカンファレンスで、高速でスケーラブルで価値のあるサービスを作るための方法論がテーマです。

もともとは、技術的なテーマが主だったようですが、最近はそういったサービスを開発するために必要となってくる、継続的インテグレーションや継続的デリバリーの手法や、アーキテクチャ（流行りのmicroservicesの話題も幾つかありました）、開発プロセス、組織論（DevOps絡みの話題が多かったです）など、より広範な内容を扱うようになってきています。

カンファレンスの進行自体は、先月開催されたFluent Conferenceと同じなので、そちらの参加レポートも参考にしてください。

面白かったセッション

今回紹介したいのは Etsy のパフォーマンスチームのメンバーである Allison McKnight さん (@aemcknig) の"Crafting performance alerting tools."というタイトルのセッションです。

このセッションでは、Etsyでパフォーマンスのリグレッションが起きた時のアラートの仕組みの改善の仕方が紹介されました。

Etsyとは

Etsyはハンドメイド作品のオンラインマーケットを提供している会社で、こちらの記事によると作品の販売を行っているアクティブユーザーが140万人、作品を購入しているアクティブユーザーが1980万人いるということで、大きなサービスであることがわかります。

改善前

パフォーマンスチームでは、運用中のサービスの各ページで、パフォーマンスの劣化が起きていないか以下のような監視を行っていました。

• サーバーサイドの各ページの実行時間をログに出力。
• logster を使って、ログからメトリクスを収集。
• そのメトリクス情報を Graphite でグラフ化（他のメトリクスもすべてグラフ化されている）。
• ç›´è¿‘1週間で遅かったページTop5をリスト化
• ç›´è¿‘1週間で遅くなった割合が大きいページをリスト化
• 各ページで設定された閾値を超えたページは Nagios でアラート

問題点

上記のような運用では、幾つかの問題点がありました。

• 小さなリグレッションや徐々に遅くなっていくページに気づくことができない
• 単に遅くなっているという情報だけで、そこから原因の調査をするのにコストがかかる
• アラートが沢山来て大変
• アラートメッセージを読み解くのが大変

今回の発表では、これらの問題点にどう対処していったかという話が中心になります。

アラートの仕組みを変えた

まず、Nagios に設定する良い閾値を見つけやすくするために、Graphite に溜まっているデータをもとにおすすめの閾値を表示したり、Graphite のグラフ上で閾値を設定できるツールを作ったとのことです。こうすることによって、これまでのデータをもとに視覚的にアラートの適切な閾値を選び出すことが出来るようになります。

また、このツールは Graphite のグラフ上で選択した閾値で Nagios の警告の設定情報も出力できるようになっているので、良い閾値が見つかったら、あとは Nagios の設定ファイルに貼り付けるだけで済むようになっています。

アラートメッセージの内容を見直した

Nagios Herald というツールを作って、アラートメッセージの内容をアラートの種類によって切り替えたり、アラートメッセージの中でハイライトしたり、テキストに色を付けたり、画像を埋め込んだり出来るようにしました。

こちらが改善前のアラートメッセージです。

こちらが改善後のアラートメッセージです。重要な情報が目に入りやすくなったり、必要な情報が載るようになっています。

障害発生時に着目すべきメトリクスを気づきやすくした

障害が発生した際、その原因を調査するためにはまずどのメトリクスに着目すべきかを調べる必要があります。そこで、あるタイムスパンで、指定された閾値を大幅に超えているグラフの背景色にオレンジ色をつけるようにしました。これによって、どのメトリクスに着目すべきかがわかりやすくなり、調査コストを下げる効果があります。

ChatOpsへの対応をした

パフォーマンスのリグレッションが発生した場合は、パフォーマンスチームだけでは原因がわからないこともあるので、サービス開発チームのエンジニアと連携する必要があるのですが、Etsyではそのやりとりをチャットツール上で行っているそうです。

そこで、チャット上で "perfnag メトリクス名 タイムスパン" と打ち込むと、ボットがそのメトリクスの指定したタイムスパンのグラフをチャット上に書き込んでくれるようにしたそうです。

こうすることによって、原因調査のやりとりが非常にスムーズになったとのことです。

さらなる改善

何か問題が起きた時にアラートを上げるだけではなく、例えばサービス開発チームがパフォーマンスの改善を行う修正をデプロイして、実際に改善が確認出来たら、それもお知らせするような仕組みも作ったそうです。

これによって、お知らせを見るのが楽しみになったりする効果があったそうです。

感想

実際にパフォーマンスの監視などを行っていてやりづらい点などを運用で回避したり放置したりするのではなく、着実に仕組みを作って改善していくやり方が非常に良いなと思いました。

また、現在のkintone開発チームでも、パフォーマンスのリグレッションがあった場合は、社内で使っているkintone上でインフラを担当しているチームとテキストでのやりとりをしており、パフォーマンスのメトリクスのグラフを手作業で貼り付けて原因の相談をしたりしています。 これが結構な手間で、ボットがグラフを貼り付けてくれる仕組みは是非真似したいと思います。