$30 off During Our Annual Pro Sale. View Details »

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

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

ニジエインフラ

December 27, 2016
Tweet

More Decks by ニジエインフラ

Other Decks in Programming

Transcript

  1. あんただれ • 名前 ◦ ٩( )( )۶とか₍₍⁽⁽(◌ી( ・◡・ )ʃ)とか ◦

    匿名ボードだとインちゃんと呼ばれてる • インフラ・バックエンドのボランティアスタッフです ◦ SREを名乗っても良い気がする今日このごろです • 2014/03/18にJoin • 来年こそ絵上手くなりたいです ◦ デッサン教室行き始めました ◦ 誰か教えてください>< • そろっと年が明けますね おひさしぶりです
  2. 期間もあいたので • 最近やったこととインフラについてのちょろっと紹介でも • 最近やった安定性を高める施策 ◦ NewRelic ◦ Request rate

    limit ◦ Traffic shaping • 数字とかでみるニジエインフラ ◦ サーバの構成比率 ◦ HTTP/2いれてどうだった?
  3. NewRelic APM導入 • ご存知な方も多いと思う New Relic APM(アプリパフォーマンス監視ツール)を導入 • 高いと思ってて今まで使いたいなーでも使えないなーと思ってたら クラウド向けの価格があったのに気づいた(

    $150/台という印象が強くてちゃんと見てなかったw) • これならニジエでも行けそうということで導入 ◦ ちなみに最小支払いが 4500CU($37.5)なんですが入れたサーバはそれに達してませんでした w
  4. どう改善したか • といっても特別なことは特にしていません • 主な内容はクソクエリ潰しと不要なリクエスト潰し、一括取得などです • また、単純に一括でとるようにしてしまうと問題が起きるケースがあったのでそこはロジックを大幅に変えるなどして改善 しています • これはニジエに限った話ではないんですがキャッシュ=必ず速いというわけではないので注意が必要

    ◦ シリアライズやNWコストなどありますし考えて使いましょう的な • 今回は主にデータストアに対して行っています(db/kvs) ◦ wwwも気持ち減った ◦ 直近でwwwが増えたのはサーバ減らしても平気と判断して減らしたからです ◦ wwwはphp70/71化で一気にパフォーマンスをあげようと考えています DB memcached www
  5. Request rate limit • トークンバケットアルゴリズムを使って制限かけています ◦ 要は特定のパスへのリクエストを例えば 10秒間で20回まで といった制限をいれることでリクエストを絞ってる感じです •

    割とこの制限は緩めにかけていて通常の利用ではそうそう ひっかかりません ◦ かけ方も全体でというより特定の操作といった感じです ◦ 引っかかっても気づかないようなものもあります( APIなど) • もし左のようなエラー画面が出た場合はちょっとお茶でも飲めば すぐ正常に戻ります ◦ ついでに「あ、今負荷かけてるんだ」と抑えてもらえれば・・・ • ちなみにこれに引っかかったからといって「やば、ペナルティを受ける!」 とかというのは一部ケース(次ページ)を除き考えていません • 当然ですがかなりの効果があり最近は対策前のような跳ね方は ほとんどしていません ◦ 一部掻い潜ってくるのもありますが気になったタイミングで チューニングしてます
  6. ニジエでの制限(お仕置き部屋) • 個人的にお仕置き部屋と言ってるモードがあるのですが、 いわゆるBANです • これは悪意を持ったリクエストなどに適用されます ◦ この悪意はシステムに対してです ◦ 割と自分が怒らないと発動しません

    • まず誤爆はしないはずですがもしこれが出て心当たりがないなどの 場合はTwitterで連絡とってみてください ◦ proxyレベルでまるっとdenyしているので・・・ • ちなみに418なのは一度使ってみたかったステータスだったからで す ◦ 418にする前は402(Payment Required)でした
  7. Traffic shaping • ニジエ大明神や音声などのリリースがあるとそこにトラフィックが集中して画像のトラフィックが 気になる事がありました ◦ 今のところこれが原因で刺さったことはないけど今後もあるのでコントロールしたい • もひとつの理由として高帯域なクライアントです ◦

    ニジエのサーバは割と激安構成のためoutbound帯域が結構小さい ◦ システム構成全体としては余裕があるのですが、サーバ1台あたりの帯域を高帯域な クライアントが瞬間的に使い切ってしまうことがありました ▪ これはクライアントが悪いというわけではないです • 左図の数字はトラフィックと考えてください、サーバ全体では30まで捌けて クライアントは18要求しています。ぱっとみ60%負荷ですがクライアントの回線は均一であり ません、しかし振り分けはDNS-RRになりますのでトラフィックが完全にきれいに振り分けされ るわけではありません、特にニジエのようなサーバ1台あたりのキャパが小さい場合は影響を 受けやすくなります ◦ 一番左のサーバは90%負荷になっています • そこでshapingを実施しました ◦ クライアント単位での帯域 ◦ 特定のリソースの帯域(今後の大容量リリースから検討) ◦ トークンバケットとの組み合わせでのシェーピング(検討中) ◦ ただ割と緩めです 公平なリソース割り当てのためご理解ください
  8. グラフと数字でみるニジエインフラ • サーバ台数でみると配信周りがTopで36%です ◦ 本業でもこういう比率のシステムは見たことないです ◦ いかに安くみたいな感じで構成したらこうなった感じですね ◦ といってもコスト比率だと17%とdbは圧倒的・・という感じ •

    ちなみに現状の配信コストは0.5円/GBぐらいです(ストレージ・動的リサイズ込) ◦ 現状キャパシティ的にはまだ余裕あるのでもっとくればコストが低く ◦ リサイズについては改善を検討しています(特にagif) ▪ いい加減agifサムネの崩れは改善したい ▪ 以前本業でやったことあるので後はサーバコストとの兼ね合い
  9. ニジエでの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は驚いたw ▪ ニジエはリソース多いので割と有効に効いてる印象 ◦ おもったよりhttp/2で1回だけのリクエストだけが多い ▪ 調べたところFireFoxで多い ▪ ココらへん掘り下げて調べても面白いかも • チューニングできそうな要素はあるので少しいじっていきたい
  10. まとめとか今後とか • agifのサムネ崩れ問題への対応 ◦ サーバコストとの兼ね合いがあるので必ずやるとはいえないですが・・・ ◦ メモリが・・・メモリが・・・メモリが・・・ ◦ 画像処理ってメモリ食うんですよねー •

    php70 or 71の投入 ◦ 一時期70をテスト投入をしたことあるんですがやはり効果あったので早めに入れたい ◦ 全体投入するにはかなりのコード修正が必要なのでどうすっかなーといった感じです • コードのリファクタリング ◦ php70と合わせて少しずつ進めます・・・ • CentOSからUbuntuへ移行 ◦ 今CentOS(7)/Ubuntu(Xenial)混在なのでこれをUbuntuにしたい • サーバ整理してコスト減らす ◦ 幾つか整理してコストを減らす余地があるのでその辺やりたいなーと 良いお年を