ニジエチューニング 2017-12 2017/12/28 インフラボランティア：

あんただれ ● 名前 ○ ٩( )( )۶とか₍₍⁽⁽(◌ી( ･◡･ )ʃ)とか ○ 匿名ボードだとインちゃんと呼ばれてる ● インフラ・バックエンドのボランティアスタッフです ● 最近バックエンドを手伝ってくれる人が増えて嬉しいです ● 2014/03/18にJoin ● 絵上手くなりたいです ● そろっと年が明けますね おひさしぶりです

Twitter権限問題 ● Twitter上でニジエはDM権限を要求してる超ヤバイという指摘があった ● 確かにDM権限要求してる＋でもそんな権限使うのあったけ・・と調査開始 ● とりあえず当時のチャットログ見たほうが流れがわかるかなと

Twitter権限問題 実際のコード（全部で9箇所あった）

Twitter権限問題 そもそも生きてるのかログだして確認

Twitter権限問題 で、権限落とし

Twitter権限問題 開発者が選択できるもの 1.読み込みのみ 2.読み書きのみ(DM除く) 3.DMを含む読み書き ユーザから見えるもの つらい！！

Twitter権限問題 ● そもそも実装されていた Tw関連機能は ○ プロフ取得(twのid等) ○ つぶやく ○ DM送信(実際は使われていないですが・・ ) ● だったのでDM読んだりはしてないのですが、こればっかりは信用してもらうしか無いので 難しいところではあります ● あと、ニジエ以外のサイトでも権限問題でいろいろ騒がれてました ○ この話題は定期的に出てきてなんというか複雑な気持ちになります ○ もう少し細かく設定できれば、ユーザの疑心暗鬼を生まずにすむのですが・・ ● 一連のTwの投稿はここ参照 ○ https://twitter.com/nijieinfra/status/823390262143524864 ● 権限落とした後の障害が実はもっとつらかった（補正つらかった・・） ○ 丁度翌日に本業の代休取っていたので補正が捗りました・・・（つらい） ご迷惑ご心配かけて本当に申し訳ありませんでした

アニメーションGIF対応 ● ニジエは現在サムネイルは動的に生成しています。このお陰でデザイン修正を行っても適切なサイズのサムネを使用で きます。 ● しかしここで問題が起きたのがアニメーションGIF(AGIF)で、当時使っていたMWでは先頭フレームのみを使用してサム ネとしていました。 ○ この場合だと先頭フレームに絵が全部含まれていないと変な崩れ方をします。 ● これについては以前からもなんとかしたいとは思っていたのですが、AGIFの変換コストが非常に高くなかなか踏み切れ ませんでした。　 ○ 専用の変換サーバなんて用意できるわけもないので、別用途のサーバに相乗りさせる形で置いてたんですがメ モリがとにかくすくない・・ ■ ニジエのサーバ群は512MB~4GBのメモリで動いていて、この変換してるのは2GBで動いてました。 ● ですがTwitterでニジエはせっかくAGIFが強いのにサムネ崩れが致命傷という意見を見かけまして、やるだけやってみる かーで投入しました。 ところが・・・

アニメーションGIF対応 想像以上につらい！！ 負荷が高まって処理しきれずに バランサから外れた変換サーバ (Vじゃないところ) 全変更じゃないのにこの負荷

アニメーションGIF対応 ● 正直なんどか落とすか迷いました・・・ ○ 実際に一部を切り戻したりとかを何度かやってます ● でも反応もよく、自分もこの機能は欲しかった（というか本当に前からやりたかった）のでなにか手をと考えました

アニメーションGIF対応 ● 困ったときは一旦基本に戻って見直してみると新しい気付きがあるものです ● で、画像配信部分の構成はざっくりこんな感じです ○ アプリ側はL1で優先度で3段階で分割されており 重要なキャッシュはnukeしにくいようにしています ■ 詳しくは2014/12のスライド ● https://speakerdeck.com/nijieinfra/nizietiyuningu2014-12 ○ イメージ側はp3ストレージを使っており優先度は低く またL2においても単一のストレージを使用していました

アニメーションGIF対応 あれ、高コストと低コストオブジェクト混在してない？

アニメーションGIF対応 ● ストレージが単一なため、サムネとオリジンが混在してしまい 結果としてサムネが押し出されていました ● 当然ですが動的なサムネより静的なファイルのコストは低いです ● なのでサムネ用ストレージを用意してしまえば負荷は激減します ○ もちろんオリジンが押し出されるので トラフィックは増えますが許容範囲 ↓このあたりで分割 AGIF投入前より負荷が減ってる とりあえず基本に戻るのは大事 AGIF投入

他にも新機能いれました ● イラストレコメンド ○ 協調フィルタリングがベース ○ 使っているデータは抜いただけではないです（メインは抜いたですが） ○ バッチではなくリクエストのタイミングで計算 ■ ただしESIキャッシュは行っている ○ 計算量が爆発しないように幾つかの仮説を元にかなり刈込みを行っている ○ 思ったより精度出たんじゃないかなと考えています ● 抜かれた解析 ○ Twで「ニジエは明け方投稿した絵はいいねはつくけど抜いたがつかない～」とあって もしかしたらそういうのが見れたら嬉しいかな？と思って実装 ○ 基本は夜なんですが、意外と朝メインで抜かれている作品もあったりと発見がありました ● などなど

今年は割とメンテナンスが多かった ● 気づいた方もいるかもしれませんが、今年はニジエにしては珍しく停止メンテを 数回やっています ● なるだけ無停止でやっているのですが今年はいろいろ無停止だと難しいもしくは リスクが高い変更が多くあり停止メンテをしました

ロケーション変更 ● ニジエは元々サーバを置いてるロケーションが複数ありました。 ○ これは当時の事情によるものと、あと長時間メンテ抜きでの移設が難しくなかなか踏ん切りがつかなかった感じで す（これだけにトンネルつくるのもなぁ・・的な） ■ 実は以前も改善のために最低限の変更はしてたりします ● 詳しくは2014年4月のスライド ○ https://speakerdeck.com/nijieinfra/nizietiyuningu2014-04 ○ しかし業者がL2接続に対応したことで、ダウンタイムをあまり取らずとも切り替え出来る目処がたったため検討を はじめました

ロケーション変更のメリット ● ロケーションをまとめるメリットはざっくり2つありました ○ proxy-app間のRTTが小さくなることでの全体的なパフォーマンス向上 ■ 当時に全部移設するべきだったんですが幾つかのBlockerがあって難しかったのです・・ ● なので最低限の対応としてproxy/cacheだけ東京にもってきてました ○ コスト的に有利なインスタンスが使えるようになる ■ 結構大きかった・・・ニジエはコストとの戦い

ロケーション変更のデメリット 全サーバ構築しなおし（つらい）

ロケーション変更 ● そもそも ○ 台数がそんなに多くない ○ ディストリも混在(CentOS/Ubuntu) ○ 頻繁にサーバの増減は無い ○ そのうち大型の構成変更（PHP7など）をやるときに構成管理はやればいいや・・・ なので手構築してた

ロケーション変更 ● 流石に全部手構築は嫌だなということと、これを期にとwishlistを一気にやることとしました ○ 構成管理(Ansible) ○ Ubuntu16.04化 ○ MySQL5.7化 ○ PHP7.0化 ● 言うならば夏休みの宿題が最終日に襲ってきたようなもので大変つらい

Ubuntu16.04/Ansible対応 ● もともとニジエはCentOSを使っていたのですが、http/2に対応するためにOpenSSL1.0.2が使えるUbuntu16.04を一部 で導入していました。 ○ なお、今年リリースされたCentOS7.4(1708)はOpenSSL1.0.2対応なので今はCentOSでもh2は可能です ■ 切り替え初めたころはまだなかったので・・・ ● 構成管理についてはエージェントレスで割と書きやすいのでAnsibleを採用しました

MySQL5.7化 ● 特に奇をてらったやり方ではなく一般的な切り替え ● MySQL5.7化自体は割とスムーズでした。 ● 同時にチューニングしたということもあるんですがi/o負荷がかなり減ってすごく満足 ○ グラフも取ってますがパラメータも結構いじっていて同条件ではなく誤解を招くので割愛 ● ちょろっとしたところでの気付きだと、5.7のstb01を作った際にテストでバッチをそれに向けていたのですが、ロケーション 跨ぎになるので当然ながら激遅になってしまい、光の速度を再認識しました

PHP7.0化 ● これが本当に大変だった・・・ ● 移行前は5.6だったんですが、まず問題だったのは使ってるPECL/PEARで、サポートがされなくなったものや、開発中断 してしまっているものが多数ありそれを代替のものへの載せ替えが本当に大変でした （memcache->memcachedなど） ○ この時のログ見てたら70コミット/dayぐらいあってうわぁ・・みたいな ■ 割と自分は細かく刻むというのもあるんですが多い・・ ● この作業自体は特に一括でスマートにやる方法はなく、ひたすら泥臭い修正を延々とやる感じです ○ factorio楽しかったです でもその甲斐もあって

PHP7.0化 PHP7.0(Ubuntu16.04) PHP5.6(CentOS7) 半端ない負荷軽減

PHP7.0化 PHP5.6 PHP5.3 ちなみに過去に5.3->5.6にしたときはこんな感じだった PHP7.0の凄さがわかる・・

コスト減った ● これらの施策でもろもろ負荷が減ったりしたことで余剰となったサーバを減らしたり 増強が必要なところは増やしたり（特に配信は随時見ながら増強してます） ● あくまでサーバだけですがニジエのコストは66,979円/月まで減らしました(2017/12概算) ○ 他のコストだとNewRelicとかgithubとかいろいろ ○ 実は更に増強しつつコストを減らすネタもあったりするのでいろいろ考えてる・・ ● 過去は10万超えてるときもあったのですが、その当時より増強しつつ、このサービス規模でこれは割と頑張ってる方じゃ ないかなとか思います

まとめとか今後とか ● とりあえずインフラ的に大規模なところは一段落したかなと考えています ○ php7.2/mysql8.0も見えてきてますが・・とりあえずは！ ● 投稿を速くしたい ○ これは原因はわかってるのですが根が深いのでいろいろ事前作業やりつつって感じです ● 次はマイクロサービスまではいかないものの、各サービスで共通機能を切り出して独立させようとか 考えてたりします ● ランキング周りの追加機能 良いお年を