Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ニジエチューニング2017-12
Search
ニジエインフラ
December 28, 2017
Programming
0
2.6k
ニジエチューニング2017-12
なんか貼った画像が潰れてるのでDownloadPDFで見てもらえれば
ニジエインフラ
December 28, 2017
Tweet
Share
More Decks by ニジエインフラ
See All by ニジエインフラ
ニジエチューニング2023-12
nijieinfra
0
460
ニジエチューニング2016-12
nijieinfra
0
960
ニジエチューニング2014-12
nijieinfra
0
650
ニジエチューニング2014-11
nijieinfra
0
400
ニジエチューニング2014-10
nijieinfra
0
480
ニジエチューニング2014-04
nijieinfra
0
340
ニジエチューニング2014-03
nijieinfra
0
570
Other Decks in Programming
See All in Programming
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
290
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
450
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
820
MCP with Cloudflare Workers
yusukebe
2
230
PHPで学ぶプログラミングの教訓 / Lessons in Programming Learned through PHP
nrslib
4
400
Amazon S3 NYJavaSIG 2024-12-12
sullis
0
110
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
180
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
290
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
5
950
GitHubで育つ コラボレーション文化 : ニフティでのインナーソース挑戦事例 - 2024-12-16 GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
120
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
260
Zoneless Testing
rainerhahnekamp
0
120
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.4k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
GraphQLとの向き合い方2022年版
quramy
44
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Building Applications with DynamoDB
mza
91
6.1k
Adopting Sorbet at Scale
ufuk
73
9.1k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
What's in a price? How to price your products and services
michaelherold
244
12k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Transcript
ニジエチューニング 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も見えてきてますが・・とりあえずは! • 投稿を速くしたい ◦ これは原因はわかってるのですが根が深いのでいろいろ事前作業やりつつって感じです •
次はマイクロサービスまではいかないものの、各サービスで共通機能を切り出して独立させようとか 考えてたりします • ランキング周りの追加機能 良いお年を