ニジエチューニング10月 2014/10/29 インフラボランティア： 

あんただれ ● 名前 ○ ٩( )( )۶とか₍₍⁽⁽(◌ી( ･◡･ )ʃ)とか ○ 匿名ボードだとインちゃんと呼ばれてる ○ コロコロ変わる ● インフラ・バックエンドのボランティアスタッフです ● 2014/03/18にJoin ● 絵は描いてみたいので練習してたり 本業が忙しくてあまり大きな作業してなかった 

POODLE対応 ● 即日SSLv3を落とす ● 最近セキュリティ関係の問題多いですよね 

！ 

DBのCPUリソース食い尽くし ● 10/19~20にかけてDBのCPUが食いつぶされる ○ いっきにslowになりToo many connection ○ もともとRowsが多くなるクエリが多数あって そのうち直そう→本業忙しくなる→忘れる→＼(^o^)／ ○ 手落ちで申し訳ないです。。。 ● 初日(19~20)はmaster/slaveでのバランスでなんとか復旧 ○ １週は持つかなーと思っててその間に改善しよう・・・ ● 翌日再発、小手先では無理と判断して slaveのスケールアップ＋増設 ● 月額費用が高くなってしまったのでなんとかせねば 

オペレーション・スクルド発動 負荷対策チャットの名前 

DBなんとかしたい ● 今回の問題の起因がとにかくDB ○ slowにでたものをpt-query-digestにかけてみたところすごい結果が ○ examine:sent 15.96k:0.99(中央値) ○ 一言で言うなら糞クエリ ■ 幾つかのさくっと直せそうなのを直してもらった ■ とはいえすぐには直せないものもある（コード的な問題） ● これはゆっくりなおせれば・・ ● 直せないものはとりあえずキャッシュしよう 1query! (バッチだけど) 

キャッシュ関係の見直し ● めっちゃざっくりいうとユーザに近いキャッシュは速い ○ 経由が多いとその分遅延する ○ かといって全部ブラウザにキャッシュできない ■ そのキャッシュを使うのは１ユーザのみ ■ ユーザが使うブラウザは何かわからない ■ キャッシュを消すのは困難 ● queryに日付いれれば消えたわけではない ○ 別のキャッシュが作られる ● CDN/Proxyでキャッシュ？動的生成されるものはどうするの？ ○ 同一URLでUser毎に出すデータが違ったら？キャッシュできるの？ ○ 動的生成されるもののキャッシュするのは注意が必要 ● Appでのキャッシュ ○ LL動くとCPUコスト大きいよ！ ● KVSやDBでのキャッシュ ○ Appから読むよ ○ テーブルがバッファから溢れて一気に重くなることあるよ ○ そもそも設計・クエリが不味いとそれどころではない（全てにいえるけど） すごくざっくり図なので 突っ込まれると泣きます なるだけ安全にユーザに近いところでキャッシュしよう (比較的) 

キャッシュ関係の見直し ● SSL通信時に画像でレスポンスヘッダの問題に想定より短い期間しか ブラウザキャッシュが効かなかった（ポカミス） ○ 昔の設定が残っていたので削除して直した ● 今までAppのgwでは安全のためにcss/js/imgなどの静的コンテンツしか キャッシュしていなかったが動的コンテンツの一部をキャッシュするように これだけだと足りない・・・もっとアグレッシブにキャッシュを 

ん？ 

ん？ 同じ！ 

Edge Side Includes(ESI) ● ページの要素毎にキャッシュして Proxy（Varnish）側でマージしようぜ！ ○ 子要素はもちろんキャッシュしてる ○ （暴言）動的コンテンツもだいたい TTLやVaryを組み合わせた静的コンテンツ ● ということでガツガツと再利用出来そうなところは (ごめんやんが)ESI化 ● 別にキャッシュ目的でなくても使いかたによっては効果がある a b c d e f esi.html 

Edge Side Includes(ESI) ● ページの要素毎にキャッシュして Proxy（Varnish）側でマージしようぜ！ ○ 子要素はもちろんキャッシュしてる ○ （暴言）動的コンテンツもだいたい TTLやVaryを組み合わせた静的コンテンツ ● ということでガツガツと再利用出来そうなところは (ごめんやんが)ESI化 ● 別にキャッシュ目的でなくても使いかたによっては効果がある a b c d e f esi.html ここまで即出力 子要素で10秒待つ ↑が出力されたら出力 キャッシュできるのが一番いいけど 途中でレスポンスすることでそこまでの画像などの要素の読み込みをブラウザ側で行うことが出来る （全部揃ってではなくて途中までなんとなく出るので体感では速く感じる） 4.0.xではパラレルESI に対応してないので やたらやるのはNG 銀の弾丸ではない 

ということであくまで途中経過ですがこんな結果 ■10/27~10/28 (改善中) ■10/13~10/14 (未改善) 

トップ 

閲覧ページ 

ログイン 

すごく・・・早くなってます・・・。 (途中でappサーバも削減!) 

とはいえ結構苦労してる ● 今回スケールアップ・増設したものはDBのみ ● もともとESIを想定していなかったのでapp側proxyは超低スペック（画像側もだけど） ● 100MBのメモリの捻出にも苦労するレベル ● 基本TTL短めgrace長めでbgfetchで 安全にパフォーマンス稼ぐつもりだったのでコレは不味い ● なるだけon memoryでやりたかったけどないメモリはない 

とはいえ結構苦労してる ● 仕方ないのでページ・CSS/JSといったそれが読まれないと全体が遅くなるところ はmallocそれ以外はfileとストレージを２つに分けた ● ほぼほぼnukeが収まった ○ まだちょい残ってるのとまだESI要素が増えるので チューニングしながらメモリ増やす Varnish file (中速) malloc (高速) 画像などはこっち ページ・CSS/JSは こっち 

他にもいろいろやってる ● API化とか・・・ 

たたかいはまだまだつづく (現在進行形) 

まとめとかやりたいこと ● とりあえずパフォーマンス関係を何とかしたい ● 前やろうと思ってたプロファイリングそろっとやるかな・・ ● 今回はインフラ的な施策だけだと難しく ごめんやんをはじめとしたメンバーの協力が必要でしたが 迅速なコード修正めっちゃ助かりました！ ● 月額費用上がってしまったのでいろんな幾つかの場所で削って費用を抑えたい ○ あくまで改善して軽くなったら減らすといった感じ ○ ギリギリを攻めるつもりはなくてちゃんと余裕は持たせてます！