うごイラTech Talks行ってきた #pixiv_engineering_talks
http://pixiv.doorkeeper.jp/events/13008
会社から近かったので余裕ぶっこいてたら15分ほど遅刻してしまい、最初の方のLT聞き逃したorz
zip_playerの実装の話と、BEの構成の話と、なぜgifやmp4を選択肢なかったのかの話、node .jsでターミナル上で再生する話はとても面白かった。 企画の話は途中からだったけど、あくまでイラストの延長線上であるっていう話がすごい興味深かったので、遅刻したのが本当に悔やまれる。 楽しく仕事しているのがすごく伝わってきて、すごく楽しい&内容の濃いLTばかりで参加してよかったなーと思った。
以下メモ。最初のほうはメモ取れなかった。途中も難しかったり英語聞き取れなかったりでメモ不十分なとこ有り。
うごイラと画像変換
- @totoshi
- 資料
- 画像周り
- アップロード、変換
- うごいらとは?
- →pixiv百科事典みろ
- zip煮詰めて配信してJSで怪盗、canvasで再生
- なぜGIFアニメじゃないのか?
- 画質悪い、文化が違う→お絵かきじゃない
- お絵かきの延長線上で、敷居を下げたかった。
- Twiiter Gifアニメの特徴
- GIF→mp4変換。ファイルサイズを圧縮できる。
- でも画質劣化大きい
- 一方うごイラは
- ファイル重いけど、高画質
- うごイラに適した良いフォーマットが見つからなかった。
- 動画より画像にしたかった → 画質重視
- ImageMagikもつらいのにffmpegと戦うのも嫌だった
- 今後
- 軽くする
- 差分だけ送るとか
- .ugoフォーマット作りたい
- 軽くする
- まとめ
- うごイラはGIFあにめ、動画じゃない
- 技術的には挑戦というよりは悪乗り
UGOKU PLAYER
- ugoira html5 zip player
- @marcan42
- (※英語でトークだったのでほとんどわからなかったです。ごめんなさい。)
- APNG、MNGなどあるが誰も対応してねえ
- ArrayBufferとか使ってJSでzip展開や
- Chunkで送ってるから全部揃わなくても再生可能
- この辺り、詳しくわからんかった。
- https://github.com/pixiv/zip_player
Ugoku backend
- @harukasan
- Apache Traffic Server, nginx, Fulentdとか
- バックエンドの話
- うごイラについてはそんなに気を遣ってない。
- 7K req/s(dynamic), 30K req/s(image), 400 servers
- upload system
- 最大150枚の画像の変換処理
- ユーザを苛つかせないために非同期アップロードしてる
- 画像ファイルアップロード → 詳細情報入力
- Redisでキューイングして、サムネイル作成、変換
- gif画像分割→gifsplits
- 動的サムネイル生成
- Contents Delivery Cluster
- CDNみたいなもの
- ヒット率90%くらい
- nginx(60%)→ATS(90%)→nginx→1Gbpsの回線→ストレージ
- SSDが載ったサーバ
- CORS対応
- preflight requestでRangeヘッダーの許可
- まとめ
- 割と普通
- 綺麗よりうごく
ugoku php deployment
- @notonau
- 俺はうごイラをスクリーンセイバーにしとるで
- https://github.com/notona/ugoira-screen-saver
- 今までのpixivのデプロイはrsync
- うごイラはcomposer
- デプロイ時のエラー
- rsync中にリクエストされると困る
- ソリューション
- Q.他の方法はなかったのか?
- 物理サーバなので、Green-Blue deploymentはできない
- ロードバランサから落として1台づつは、新旧交わる時間が長すぎるので採用してない
うごかなイラ
- @shobyshoby
- iOSアプリ作ってる
- 評判良かったが、アプリから見れないっていう問い合わせが多かったw
- Webと同時にリリースする必要があった。
- 審査があるのでアプリを先に開発する必要があった。
- APIができてない状態で開発してた、モックで
- OHHTTP
- モック化するとキャッシュのバグに気づきづらい
- 実装
- zipをcahceディレクトリに展開
- CADisplayLink
- drawRectでの描画領域を最小限に。デバイスに合わせてスケーリングする。
- 教訓
- APIのURLとレスポンスをDB設計と同時期に決める
- 同時期だと実データでテストできない
- Web側にiOSの審査を待ってもらう→非現実
- 諦める
- Web→Android→iOSの順でリリースがいいと思う
- まとめ
- iOSとWebの同時期リリースはかなりハードル高い
うごイラ in Android
- @RooandQoo
- FragmentとDownloader