ニジエチューニング2014-03

Transcript

1. ニジエチューニング3月 2014/04/01 インフラボランティア：
2. あんただれ • 名前 ◦ ٩( )( )۶とか₍₍⁽⁽(◌ી( ･◡･ )ʃ)とか ◦ コロコロ変わる • インフラ・バックエンドのボランティアスタッフです • 2014/03/18にJoin • 絵は描いてみたいので練習してたり お手柔らかにおねがいします！
3. 今回は • 3/18ぐらいにJoinしたので3月にやったことのまとめ • 配信系がざっくり安定してきたので整理
4. インフラ構成（変更前） • ２つのサービスを利用 ◦ Notオンプレ • サーバスペックは貧弱 （メモリ1GBとか・・）
5. 3/30時点のインフラ構成 • 画像キャッシュに多段に • img.nijie.infoをnijie.info に統合 • 高速化などでAP1台削減 • 総台数に変更なし
6. 初期段階 • インフラ構成の資料なかったので作った • 幾つか重要なパフォーマンス関連の測定をしていなかったので取れるように ◦ レスポンスタイム ◦ スロークエリ
7. AP側の改善ポイントの探し方 • リクエストが多い順にソートして上位から対策可能か見ていく • DBのスロークエリを眺める • エラーログを眺める • 不具合グループ・Twitter眺める • 画像配信の方を優先させたかったので効果が大きいところをつまみ食い 特に特別なことはしてない
8. AP側の改善 • 不要なリクエストの廃止 • ブラウザキャッシュが可能なものはキャッシュ • スロークエリつぶし • Safari系でのjQueryのstack over flow 問題点を指摘するとごめんやんが速攻直してくれるので楽
9. 不要なリクエストの廃止 ブラウザキャッシュの使用 • 不要だったリクエストの廃止＋ブラウザキャッシュの利用で6割強のリクエスト減 wsのRPSグラフ
10. スロークエリつぶし • 取り敢えず2秒超えていたものは全潰し、1秒超えの一部も潰した • メモリも少ないのでテンポラリになりがちなので特にRows多いところを潰した • 対策の結果DBのIO負荷が減った • ページの速度も全体的に上がった ◦ PVが多いあるページの場合 ◦ 0.71sec → 0.49sec（1h平均） ◦ PVも増えた！ 最初の対策 二回目
11. jQueryでstack over flow • Twitterでニジエで検索してみたところどうもiOSで固まるらしい • 自分のiPhoneでも再現できた • というかMacのSafariでも再現できた • ステップ実行してどこで詰まってるかを確認 ◦ スタンプの情報を取得しているところを起点に再起してる($.post) • ここ怪しいよねと話してたらごめんやんが$.getJSONになおしてくれて収まった • フットワーク軽い！
12. 画像配信系の改善ポイントの探し方 • とにかく不安定なので安定させる（第一） • キャッシュの効果を最大にすべき対策を行う ◦ サーバで対策するのは当然として可能ならブラウザでキャッシュさせる • 構成的にスケールしない仕組みだったので変更 • アクセスパタンの調査 ちなみに画像配信を先に安定させたかったのは 『ページが重いけどめちゃシコな画像がちゃんと見られる』よりも 『ページは軽いけどチンポップが大量出現』のほうが サービス的にイラッとするとだろうなぁという考えで優先させた感じです
13. 画像配信系の改善 • 再起動を繰り返してたVarnishの対策 • Could not get storage(nuke)問題 • Persistent storageのファイルサイズの不一致問題 • 画像配信系のSSLが重い件の対策 • ブラウザキャッシュ出来るように • 多段構成へ変更 • img.nijie.infoの廃止 • storageのswap対策 • サムネ生成がスケールするように構成変更 • 漫画スパイク対策
14. 再起動を繰り返してたVarnishの対策 • mallocストレージを使えば解決するけど十分なヒットレートを稼げるほどメモリがないのでダメ • 再起動を繰り返した問題点は 2つ ◦ スワップしてないがメモリの確保に失敗 (Cannot allocate memory) ▪ フラグメントしてたとおもう ◦ persistentのsilo使いきりからの開放処理からの再開時の失敗 • メモリの確保に失敗は全てのサーバではなく特定のサーバで頻発 ◦ サーバによってsysctlの値が違った ◦ vm.overcommit_memoryが2だったので0に変更して有効化 • persistentのsilo使いきり問題 ◦ expireしていない状態でsiloを使い切ると再起動を行い幾つかの siloを確保しようとする ◦ ここで運が悪いと綺麗に上がってこない (まぁまだexperimentalだし・・・） ◦ なのでTTLとstorageサイズを調整して溢れないように変更 ◦ ちゃんと検証してないけど 4.0系で直りそうな気がするので出たら突っ込む
15. Could not get storage(nuke)問題 • 安定化させようと試行錯誤した際にmallocを使っていたため起きた問題 • Could not get storage多発で503 • nuke(evict)が間になってない、Varnish使って長いけど初めて見た • 最もreqが多いのが20KB前後で10MBのagifもある • nukeの試行回数はデフォルト50なので足りない(nuke_limit) • 取り敢えず増やした • といってもpersistentに統合したのであまり意味がｗ 10~100KB サムネ等 10MB agif等
16. Persistent storageのファイルサイズの不一致問題 • persistentでストレージサイズが指定サイズ以下で確保されるケースが有る • 動作的に不安定にはならないが想定した期間以下でsiloを使い切るのが問題 • キャッシュごと消してしまうケースはファイルサイズ確認するようにした • もうちょい調査して類似ticketがなければ本家に報告するつもり 50G指定 正しい なぜか31GB
17. 画像配信系のSSL重い問題 • 画像のSSL通信が妙に重い ◦ キリのいい数字でレスポンスするのでTCP的な問題くさいなと調査 ◦ tcpdumpを取りながらIPアドレス指定でつないでみる ◦ →そもそも繋げない（！？） • 4台中（DNS-RR）ポート443を開いてるのは1台だけだった(iptables) • 取り敢えず定義追加して解決・・・ • と思ったら日時バッチで元の設定が復活してた ◦ 直した！
18. ブラウザキャッシュの有効化 • VCLのinlineCで時刻計算してレスポンスヘッダ付与(Expiresなど）
19. • キャッシュは4台なので同じリクエストが最大4回オリジンに直撃する可能性 • 静的なファイルであればそこまで目くじらを建てる必要もないけど・・・ • サムネイルを動的生成(ngx_smalllight)しているので致命的 • 1段目を3台・2段目を2台で構成（Hash Director) • 増えた1台はimg.nijie.infoをnijie.infoに統合して捻出 ◦ 1台でシングルポイントだったので構成的にも統合が好ましい • 一気にstorageの負荷を軽減できた 多段構成への変更 img.nijie.infoの廃止 切り替え ※切り替え直後でキャッシュが 温まってない状態でも効果絶大
20. • nginxのngx_smalllightを使用 • なんかswapして定期的にnginxをreloadする必要がある • 放置するとswapで一気にio食いつぶしてstorageが応答不可になる • 動き的にスレッド毎まで抱え込むかリークかcacheの開放が間に合ってない ◦ 軽く調べたところcacheではなくnginxが単純にメモリ抱えている ◦ きちんと調査してもいいけどまずは対策をしたい • リークしても問題ないようにPreforkなApacheに変更(mod_smalllight) ◦ MaxRequestPerChildを低めに設定（まだ要調整） storageのswap問題 swap 対策前 対策後 切り替え ※切り替え前にswapの上がり幅が低くなって いるのはキャッシュ多段化などの対策のため リクエスト数が減ったため
21. storageのswap問題（ログ） nginxがswap nginxがメモリ食ってる キャッシュは食ってない swapし過ぎで 一気にslowdownしたケース
22. サムネがスケールしない問題への対策 漫画スパイクへの対策 • スケールしない問題 ◦ サムネは各ストレージで動的に作成している ▪ つまりpic01のものはpic01のストレージでサムネ生成される ◦ サムネ生成とストレージサーバが紐付いているため種類増やした際に破綻する可能性が高い • 漫画スパイクへの対策 ◦ 画像は投稿時点でランダムで storageが選ばれる ▪ 但し画像毎ではなく投稿毎なので 1回の投稿で複数の画像が上げられる漫画は全て同じ storageになる ▪ varnishstatを見ているとRPSが異常かと思うぐらい凄いスパイクしている ◦ 漫画の表示画面はオリジナルサイズの 1枚目と残りのサムネ ◦ つまり初回アクセスで来ると一気に特定のストレージに負荷がかかる ▪ Thundering herd問題は対策出来ているけど非力なので力技解決できない ▪ 多段化だけでは完全に防げない ◦ グラフ上は負荷は低いが vmstatを見ているとidle0％で数秒張り付く事がある ▪ レスポンスの一時的な悪化 ▪ 変換エンジンをimlib2にしたら負荷結構減るが画質の問題有り（どうしてもぼける） ▪ でもimlib2が使えないgifのサムネは解決できない（ jpgに比べて10倍以上のCPUコスト）
23. サムネがスケールしない問題への対策 漫画スパイクへの対策 全て同じサーバ を参照 グラフ上は負荷 低いけど・・ 1ページ目 （オリジン） 2ページ目以降 （サムネ）
24. サムネがスケールしない問題への対策 漫画スパイクへの対策 • 対策として生成をランダムで分散するように変更 • サムネ処理のオリジン取得先はstorage ◦ 画像キャッシュのヒットレートは極めて高いため そもそも初回アクセスなどで元画像もミスする可能性が高い ◦ 無駄に中継するよりページキャッシュに期待 • 大量にリクエストが来ても分散できる ◦ 平均では以前より高速化 • 現在は投入していないが負荷が高まった時点で CPUリソースが余ってるVarnishサーバでもサムネ処理をさせる • グラフ上は微かにスパイク減って見えるけど凄く微妙なので割愛
25. まとめ • サーバをコスト的な面から増やせないという縛りプレイでのチューニングは なかなかおもしろい経験 • 如何にスパイクをなくして使うリソースを平滑化するかが勝負 • 大規模でもこの規模でも見てるポイントや問題を発見する 手順・改善プロセスには極端な違いはない ◦ 大きく違うのはそのリスクに対してコストをかけて95％持っていくのか かけずに80％まで持っていくのかのバランス感覚 ◦ もちろんまだ見なくてもいいリソースもある • なんだかんだ言ってパズルゲームみたいで面白い
26. 4月以降にやりたい事 • AP側の構成変更を行って適切なキャッシュと冗長構成を取る • sysctlが違うところがまだあるので整理してより安定化させる ◦ リビルドも検討 • プログラムのプロファイリングを行う • RUM導入 • サーバのLocationを整理してレイテンシを下げる • DNSからのヘルスチェック追加 • 構築の自動化（そんな規模の台数ではないけど） • Varnish4投入