今回は弊社サービスのMARKETING PLATFORMでのパフォーマンス監視について書いてみます。
私は開発エンジニアなのでここではアプリケーション側の話だけですが、他にもインフラチームがサーバリソースの監視もちゃんと行っています。
さて、私は半年ほど前から仕事内容が機能開発メインからパフォーマンス対策メインに変わりました。
機能開発のひとつとしてパフォーマンス対策はちょこちょこやってましたが、専任でやるのは初めてですし、シャノンとしても初めてです。
その背景には、
・サービスの利用者増加により扱うデータ量が増加。それによってアプリケーションへの影響が出始めたこと
・機能追加やバグFIXをリリースしたことによるパフォーマンスデグレードが頻繁に起きていたこと
があります。
今現在パフォーマンス関連として行っているのは
・監視
・調査、分析、対策の企画
・対策の実装
・他のエンジニアが開発したもののパフォーマンスレビュー
です。
さて本題のパフォーマンス監視の話です。
私が行っているパフォーマンス監視はアプリケーションに関する情報についてのものです。
CPUやメモリ等のリソース監視はインフラチーム側で行っています。
それぞれの監視には良い所、悪い所があり、それを補完し合っている関係です。
それぞれは別のチームで監視していますが、そこはうなく連携してサービスとしてのパフォーマンスの問題を監視しています。
アプリケーションの監視ですが、情報として使用しているのはアクセスログのレスポンスタイムです。
今のところ、監視の最大の目的はリリースによるレスポンスタイムの悪化をなるべく早く検知して対策を打つことです。
ですので、まずはレスポンスタイムを監視し、いち早く異常を検知する仕組みを構築しています。
実際の監視内容ですが、レスポンスタイムを日次・週次で顧客・機能別に集計し、前回データ(前日・前週)との比較を行っています。
その比較した結果の中で閾値(今のところは前回との比較が2倍)を超えたものの一覧を作成し、メールで通知しています。
xxx.smktg.jp /public/menu/document/download 2.370437 xxx.smktg.jp /public 2.177086 yyy.smktg.jp /services/rest/visitor 5.460901
こんな感じのメールが飛んできます。
比較しているデータは集計データの中央値です。
平均値ではなく中央値を利用しているのは、サーバの一時的な負荷でレスポンスタイムが悪化することによる外れ値の影響をできるだけ受けたくな<なかったからです。
80～90％ラインで上下の値を切り捨ててからの平均値でも同様の効果は得られますが、リクエスト数の多くない顧客・機能別のデータには適さないと考えました。
また、日次・週次で比較しているのはそれぞれ目的があります。
まず日次ですが、これは出来るだけ早くパフォーマンスのデグレードを検知するためです。
日次での比較だと早ければリリースの次の日には検知可能です。
ただ、日次なので比較するにはリクエスト数が十分でない顧客・機能別のデータがあります。
そこで週次の比較があるわけです。
1日分のリクエスト数は多くなくても1週間分あれば比較可能なデータ数が溜まります。
日次はできるだけ早く検知してできるだけ早くその修正パッチをリリースするためという目的がありますが、週次の方は緊急度は低いけれど、そのうち直した方が良い(直さなければならない)パフォーマンスバグを検知し、対策を打っていくためのものです。
また、日次と週次では検知の精度が違います。
日次の方はどうしても少ないリクエスト数での比較になるので週次に比べると誤検知は多くなります。
検知によって異常と判断されたものについては、個々のリクエストのアクセスログやアプリケーションのログ、データベース内のデータ量等をチェックし、何が原因なのかを調査します。
調査した結果、プリケーションをリリースしたことが原因の場合、バグとして登録されます。場合によってはすぐに修正して緊急リリースすることもあります。
リリースに関係なくデータ量が増えたことが原因の場合、緊急に対応しなければならない可能性は高くはありませんが、状況によっては近いうちに対策を打たなければならない可能性もあるので、これもバグ登録しておき、後日分析・対策を検討します。
現在はレスポンスタイムによる監視がメインですが、リクエスト毎のメモリ増加やバックエンドアプリケーションのレスポンスタイム等の監視も行う必要があります。
監視項目は随時増やしていく予定ですし、比較方法も移動平均を使ってより精度を上げていこうと考えています。
今回は監視のお話でした。実際は監視だけだと後手後手になってしまうので、リリース前のパフォーマンステストも必要になります。
こちらも少しずつ取り組んではいますが、やはりデータのバリエーションが少ないのが現状ですし、例えバリエーションを増やしても完全に網羅することは難しいと思います。
ですので、両者バランスよく補完し合いながら運用していけたらと思っています。
こんな感じで監視する日は来るのか？
