ニジエチューニング2016-12

Transcript

1. ニジエチューニング 2016-12 2016/12/27 インフラボランティア：
2. あんただれ • 名前 ◦ ٩( )( )۶とか₍₍⁽⁽(◌ી( ･◡･ )ʃ)とか ◦ 匿名ボードだとインちゃんと呼ばれてる • インフラ・バックエンドのボランティアスタッフです ◦ SREを名乗っても良い気がする今日このごろです • 2014/03/18にJoin • 来年こそ絵上手くなりたいです ◦ デッサン教室行き始めました ◦ 誰か教えてください＞＜ • そろっと年が明けますね おひさしぶりです
3. 前回の資料から2年ぐらい • 本当にいろいろありました・・・ • 結局ごめんやんに直接会えなかったので残念でした ◦ 一度大阪に行ったことあったんですが風邪で会えず・・・ • ということで僕がバックエンドも見ています • ニジエのインフラもいろいろかわりました
4. 期間もあいたので • 最近やったこととインフラについてのちょろっと紹介でも • 最近やった安定性を高める施策 ◦ NewRelic ◦ Request rate limit ◦ Traffic shaping • 数字とかでみるニジエインフラ ◦ サーバの構成比率 ◦ HTTP/2いれてどうだった？
5. NewRelic APM導入 • ご存知な方も多いと思う New Relic APM（アプリパフォーマンス監視ツール）を導入 • 高いと思ってて今まで使いたいなーでも使えないなーと思ってたら クラウド向けの価格があったのに気づいた（ $150/台という印象が強くてちゃんと見てなかったｗ） • これならニジエでも行けそうということで導入 ◦ ちなみに最小支払いが 4500CU($37.5)なんですが入れたサーバはそれに達してませんでした ｗ
6. NewRelic効果 • NewRelicを入れたことによって問題となる箇所がはっきり見えるのが良い ◦ 特にデータサイズによって速度が変わるものだと、開発環境だと再現しづらく気付かないことも 多いのでプロダクションのデータで解析できるのは大変良い • ちょっと時間のレンジが少し違うのでアレなんですが APPServerのレスポンスはだいたい 40%高速、ブラウザでも25％高速になっています • 以前に比べてピーク時の速度低下がかなりマシになり安定化につながっています 改善前 改善後 ピークに効く改善をした時 (実線がピーク時間になっても あまりぶれてないのがわかる )
7. どう改善したか • といっても特別なことは特にしていません • 主な内容はクソクエリ潰しと不要なリクエスト潰し、一括取得などです • また、単純に一括でとるようにしてしまうと問題が起きるケースがあったのでそこはロジックを大幅に変えるなどして改善 しています • これはニジエに限った話ではないんですがキャッシュ＝必ず速いというわけではないので注意が必要 ◦ シリアライズやNWコストなどありますし考えて使いましょう的な • 今回は主にデータストアに対して行っています（db/kvs) ◦ wwwも気持ち減った ◦ 直近でwwwが増えたのはサーバ減らしても平気と判断して減らしたからです ◦ wwwはphp70/71化で一気にパフォーマンスをあげようと考えています DB memcached www
8. 結局NewRelicどうなん？ • とはいえだいたいの Web系の人たちは使ってる印象はあるので耳タコかなーとも（本業でも使ってる し） • モニタリングしただけで満足すると全く意味ないけど、きちんとそこから改善できるのであれば 大抵の場合は投入コスト以上の効果が生まれる ◦ パフォーマンス向上だけでなく単純にサーバコストの削減も可能 • そもそも全台入れる必要もないしそんなにコストかからない ◦ 入れられたら良いのは確かですが、コスト的に 使おう。
9. もともと入れようかずっと考えていた・・・
10. いよいよブチ切れ ということでリクエストベースでのRate limitを投入
11. 本当なら制限なんてかけたくない • お互いにとって幸福なのは何も制限なく使え、そしてリソースが枯渇することもなくサービスが継続できることです • とはいってもAppの仕組み、インフラ構成、コストの問題などで無限にスケールするシステムはまずありません • システムを構築する際に想定される負荷、障害などを考えます これをキャパシティプランニングといい、もちろんニジエも行っています（ちなみに本業でもキャパプラしてます） • そして一般公開されているWebサービスのようなシステムの場合はどうしても想定外の動きをするクライアントがいます • これは悪意があるリクエストもあればないリクエストもあります • そのようなリクエストによる影響をなるだけ減らして安定化させるためにニジエでは制限をかけるようにしています
12. 実際の制限がないときの状況(Request) • 見てもらえればわかりますが突然ピョコンと上がったり、一番下のグラフでは完全に 枯渇しています • こういうリクエストでもさばけるぐらいのコストをかけられれば良いのでしょうがニジエ はそんなに体力もなく、またこれらを捌いたからといって多くのユーザの方々にメリット があるとも（自分は）思えませんでした • このようなリクエストをされると他のユーザが重くなったりするので制限をかけざるを 得ません
13. Request rate limit • トークンバケットアルゴリズムを使って制限かけています ◦ 要は特定のパスへのリクエストを例えば 10秒間で20回まで といった制限をいれることでリクエストを絞ってる感じです • 割とこの制限は緩めにかけていて通常の利用ではそうそう ひっかかりません ◦ かけ方も全体でというより特定の操作といった感じです ◦ 引っかかっても気づかないようなものもあります（ APIなど） • もし左のようなエラー画面が出た場合はちょっとお茶でも飲めば すぐ正常に戻ります ◦ ついでに「あ、今負荷かけてるんだ」と抑えてもらえれば・・・ • ちなみにこれに引っかかったからといって「やば、ペナルティを受ける！」 とかというのは一部ケース（次ページ）を除き考えていません • 当然ですがかなりの効果があり最近は対策前のような跳ね方は ほとんどしていません ◦ 一部掻い潜ってくるのもありますが気になったタイミングで チューニングしてます
14. ニジエでの制限（お仕置き部屋） • 個人的にお仕置き部屋と言ってるモードがあるのですが、 いわゆるBANです • これは悪意を持ったリクエストなどに適用されます ◦ この悪意はシステムに対してです ◦ 割と自分が怒らないと発動しません • まず誤爆はしないはずですがもしこれが出て心当たりがないなどの 場合はTwitterで連絡とってみてください ◦ proxyレベルでまるっとdenyしているので・・・ • ちなみに418なのは一度使ってみたかったステータスだったからで す ◦ 418にする前は402(Payment Required)でした
15. リリースでトラフィックが跳ねる！ たまにある大容量リリースで帯域がきになる・・・ ニジエ大明神 音声アップデート
16. Traffic shaping • ニジエ大明神や音声などのリリースがあるとそこにトラフィックが集中して画像のトラフィックが 気になる事がありました ◦ 今のところこれが原因で刺さったことはないけど今後もあるのでコントロールしたい • もひとつの理由として高帯域なクライアントです ◦ ニジエのサーバは割と激安構成のためoutbound帯域が結構小さい ◦ システム構成全体としては余裕があるのですが、サーバ1台あたりの帯域を高帯域な クライアントが瞬間的に使い切ってしまうことがありました ▪ これはクライアントが悪いというわけではないです • 左図の数字はトラフィックと考えてください、サーバ全体では30まで捌けて クライアントは18要求しています。ぱっとみ60%負荷ですがクライアントの回線は均一であり ません、しかし振り分けはDNS-RRになりますのでトラフィックが完全にきれいに振り分けされ るわけではありません、特にニジエのようなサーバ1台あたりのキャパが小さい場合は影響を 受けやすくなります ◦ 一番左のサーバは90%負荷になっています • そこでshapingを実施しました ◦ クライアント単位での帯域 ◦ 特定のリソースの帯域（今後の大容量リリースから検討） ◦ トークンバケットとの組み合わせでのシェーピング（検討中） ◦ ただ割と緩めです 公平なリソース割り当てのためご理解ください
17. ニジエで一番台数が多いサーバって？ 配信サーバ！
18. グラフと数字でみるニジエインフラ • サーバ台数でみると配信周りがTopで36%です ◦ 本業でもこういう比率のシステムは見たことないです ◦ いかに安くみたいな感じで構成したらこうなった感じですね ◦ といってもコスト比率だと17%とdbは圧倒的・・という感じ • ちなみに現状の配信コストは0.5円/GBぐらいです(ストレージ・動的リサイズ込) ◦ 現状キャパシティ的にはまだ余裕あるのでもっとくればコストが低く ◦ リサイズについては改善を検討しています（特にagif) ▪ いい加減agifサムネの崩れは改善したい ▪ 以前本業でやったことあるので後はサーバコストとの兼ね合い
19. 実はニジエはhttp/2対応しています で、結局どんな感じだったの？
20. http/2どれぐらいつかわれてるの？ • どれ位http/2が使われているか見てみたところ全体の31%と結構使われている ◦ HTTPSを使用するかはユーザ任意 • h2対応していないブラウザだとどんなんだろうとみたところこんな感じ（多い順） ◦ Chrome55が引っかかってるのが解せないけど 偽装とか変な環境なのかなとか（会社のgwとか) ▪ でも採取したのが休日なんだよなぁと・・
21. ニジエでのhttp/2の傾向 • ヘッダサイズ（HPACK）について ◦ リクエスト(Rx)について ▪ 初回転送時でも割と静的テーブルで圧縮される ▪ 2回目以降はさらに効く（動的テーブル） ▪ 88%削減出来ているのは結構驚いた ◦ レスポンス(Tx)について ▪ 想定より動的テーブルの圧縮が効かない ▪ 調べてみたら割と可変なヘッダが多かった(Dateなど) ので当然か・・・ • セッションあたりのリクエスト数 ◦ タイムアウト秒数がそれぞれ違うので参考程度に ▪ 5秒　　http/1.1 keep-alive ▪ 180秒　http/2 ◦ 最大リクエスト数はhttp/1.1で25回、http/2.0で641回 ▪ 流石に641は驚いたｗ ▪ ニジエはリソース多いので割と有効に効いてる印象 ◦ おもったよりhttp/2で1回だけのリクエストだけが多い ▪ 調べたところFireFoxで多い ▪ ココらへん掘り下げて調べても面白いかも • チューニングできそうな要素はあるので少しいじっていきたい
22. まとめとか今後とか • agifのサムネ崩れ問題への対応 ◦ サーバコストとの兼ね合いがあるので必ずやるとはいえないですが・・・ ◦ メモリが・・・メモリが・・・メモリが・・・ ◦ 画像処理ってメモリ食うんですよねー • php70 or 71の投入 ◦ 一時期70をテスト投入をしたことあるんですがやはり効果あったので早めに入れたい ◦ 全体投入するにはかなりのコード修正が必要なのでどうすっかなーといった感じです • コードのリファクタリング ◦ php70と合わせて少しずつ進めます・・・ • CentOSからUbuntuへ移行 ◦ 今CentOS(7)/Ubuntu(Xenial)混在なのでこれをUbuntuにしたい • サーバ整理してコスト減らす ◦ 幾つか整理してコストを減らす余地があるのでその辺やりたいなーと 良いお年を