サーバーサイドボトルネックの探し方

ボトルネックの探し方プロファイリングの考え方とツール紹介

自己紹介清水 佑吾

@yamionp

株式会社 gumi 勤務

Python歴約2年半

サーバーさわりはじめて約10年

関わったもの

HTML + FlashLite

Cocos2d-x

アジェンダ

最適化について

ツール紹介

事例紹介

使用環境

Python 2.7

Django

MySQL 5.5/5.6 (RDS)

Redis

RabbitMQ

構成

DB

LB App KVS

MQ

Job

App

ログ

Jobエラーログ

Log

アジェンダ

最適化について

ツール紹介

事例紹介

最適化してますか？

最適化とは

システムより効率的に動作するよう変更すること

最適化でよくある失敗

最初から性能チューニング

予想だけで修正

予測するな、計測すべし

アジェンダ

最適化について

ツール紹介

事例紹介

ツール

三種の神器

CloudWatch

JetProfiler

NewRelic

CloudWatch

カバーエリア

DB

LB App KVS

MQ

Job

全部

CloudWatch

AWSの提供するシステムモニタリングツール

CPU, Memory, Disk, Network I/O, LoadAverage, etc..

もっとも基本的な情報

障害時のアラートなども行える

JetProfiler

カバーエリア

DB

LB App KVS

MQ

Job MySQL専用

JetProfilerとは

MySQLに対するリアルタイム解析ツール

クエリやステートの種類/数/頻度/割合

スロークエリ

クエリ/テーブル毎の処理時間使用率, etc…

スレッド別

ステート別

テーブル別

クエリ種別割合

ロック状態

スロークエリ

NewRelic

カバーエリア

DB

LB App KVS

MQ

Job

アプリケーシ

ョン

コード

NewRelicとはアプリケーションに埋め込むプロファイラ

Java/.NET/node.js/PHP/Ruby/Pythonに対応

関数/メソッド毎の処理時間を調査可能

統計情報表示

色々なAPIを提供

サーバー概要

処理時間

リクエスト数

URL別遅い順 エラー率

平均レスポンスタイム

処理割合

Python

外部API MemcacheMySQL

URLごとの詳細

URL別リスト

URLごとの変化の推移

リクエスト数とレスポンスタイム

個別の最も遅いレスポンス

テキスト

APIでデプロイを記録どのデプロイで変化があったかがわかる

DBもいける

処理時間 上位クエリ

上位クエリの推移グラフ

種類ごとの 割合グラフ

種類ごとの レスポンスタイム

アジェンダ

最適化について

ツール紹介

事例紹介

ある日の夜

イベントリリース！

しばらくは問題なく動作していたが…

ページが開けない！と苦情が

CloudWatch

AppサーバーCPU使用率もリクエスト数も問題ないが．．．

DBのCPU使用率が張り付いていた

即JetProfilerを起動

ここが真っ赤だった

テキスト

クリック一つて即Eplainグラフィカル＆レーティングしてくれる。 DBにくわしくなくてもいかにもダメそうな感じ

インデックスがなかった

特定クエリが処理時間の９割以上を占めていた

緊急メンテに入りインデックスを追加

インデックスをはったら5%以下に

ほとんど同じ状況で 別パターン

無駄インデックス問題

特定クエリが処理時間の３割以上を占めていた

スローではないが一クエリ当たりの時間が多い

Explainしたら index merge

インデックスを削除したら100倍高速化

教訓

負荷試験をしよう

負荷試験の結果で必要なインデックスだけを貼る

インデックスショットガン、だめ絶対

超オススメです

最適化

十分早いが回数が多いクエリに複合キーなど

いらないインデックスを削除して高速化

ある日のNewRelic

逆にmemcache速い！っと思ってしまった

Cache.get多すぎプレイヤーデータ->マスターデータへのプロパティで発生

DB分割しているとなりやすい

Join出来ないのでプロパティなどで動的につなげる

マスターデータに関してはjsonでappサーバーに配置することで解消

ある日のNewRelic2

テキスト

Redis.getに2.5sかかったredisのマスターでsave(メモリデータのダンプ)を止めappendonlyのみにし スレーブでダンプするように変更する事でだいたい解消

Redis.get一回に2.5秒

平均では1ms(最低値)なので統計グラフには出ない。

NewRelicのTransaction Detail で発見

Redisのbgsave時に起こる（EC2だと起きやすい）

ほかに取れる統計情報

テキスト

どこに時間がかかっているかPython:DB:Memcacheの割合が 40:1:1 程度

テキスト

スケーラビリティ50req/mでも500req/mでもレスポンスタイムには変化が無いので遅いのは個々の処理を行っているコードや仕様の問題

ブラウザもわかる

サーバー側の処理時間の 2～5倍はレンダリングまでにかかる

Androidの 絶望的遅さiOS（平均500ms）比で Chromeで２倍 AndroidBrowserだと ３～４倍強。

質疑応答

ご静聴ありがとうございました