うごイラ Tech Talks

うごイラ Tech Talksに行ってきた。

プレイヤーやバックエンド、コードレビューや企画の話まで、一つのプロダクトについてまるっと聞ける機会は珍しい感じで興味深い感じだった。

技術的な部分もさることながら、プロダクトメンバ全体で面白いサービスを作ろうという意志が感じたのが一番印象的だったのだなあ。立場的にはそういう流れを作る側なわけで悩ましさがある。

 

終了後にレーザーでうごイラ描いていたの面白かった。（ソースはこれらしい）

あとフロアの後ろのほうでは、ずっとラブライブの曲が流れていた。

 

以下メモです。

うごく企画と開発管理

  • @bash0C7さん
  • 経緯
    • 片桐社長の意志が強く反映されたもの（ITmediaの記事より）
    • アニメGIFに対応しよう → 単に対応するのは違うのでは
  • 「Webサービス開発徹底攻略」でのクックパッドの手法を採用した
    • マトリクスでやることとかメンバの割り振りとか整理した
    • クッパッ会と呼んでいた
  • idobataを使ってチーム横断したチャットとか、URLを貼ったり画像貼ったりとか
  • マネジメント
    • やりましょうを始める
    • やめましょうを決める（古いブラウザの切り捨てとか）
    • 終わらせる方向への風向きを維持する

うごイラのコンセプトとUI

  • @ykskさん
  • アップロードUIのデザインと実装、プレイヤーUIのデザインと実装を担当
  • アニメ作ろうという話がでた
    • 単にアニメGIF対応ではpixivならでは感がない
  • コンセプト
    • デスクトップの壁紙が「ちょっと」動く感じ → イラストが動いている感じで、動画ではない
    • 高画質・大画面 → アニメGIFでは不可能
    • pixivならでは感
  • 高画質なJPEG/PNGを複数枚アップロードする
  • アップロード時に動きを編集するUIを用意した
    • 複数選択で表示時間の変更や、ドラッグ＆ドロップで順序を入れ替えたりできる
  • 最近のフロンドエンド
  • 処理の流れ
    • FileAPIでローカルファイルを取得して、バイナリ解析してファイル種別を確認
    • 画像をBase64で表示して、FormDataで送信
    • 少し動けばいい
    • pixivはソースマップあるので元のコードも読める
  • プレイヤー
    • フルHDまで表示できる
    • フルスクリーンAPIが使える場合は全画面
  • あくまでイラストが動くコンセプト
  • しっかり設計すれば意図は伝わるっぽい
  • 目的が達成できれば手段は何でも構わない
  • JavaScriptでバイナリ解析するとか、twitterのアニメGIF対応（mp4変換）とか
  • 最近のJavaScriptは結構なんでもできる

うごイラと画像変換

  • @tototoshiさん（資料）
  • 画像周り（アップロード、変換、ストレージ、配信）を担当
  • pixiv百科事典にzipでダウンロードする方法が書かれている
  • 画像をzipに詰めて配信 -> JavaScriptで解凍している
  • 「うごイラについてちょっと考えてみた」という記事 → だいたいあってる（８０点くらい）
  • Canvasに描画しているので右クリックで保存できない話
  • 何故アニメGIFではないのか
    • 画質、文化（アニメGIFでよくある面白動画とは違うコンセプト）
    • GIFの作り方を知らない人でも上げてほしい
    • 目パチとかでも動くと楽しい
  • twitterのアニメGIF対応について
    • mp4変換されて、ファイルサイズは小さくなるけれど画質劣化が激しい
  • うごイラ
    • zipで配信しているので、ファイルサイズは大きいが画質はよい
    • APNGとかMNGとか（APNGは実は対応している）
    • MJPEGは検討したけれど、ノウハウないのとffmpeg使いたくなかった
  • うごイラに適したよいフォーマットがなかった
  • 動画よりは画像のままのほうが画質良い
  • ImageMagickにくわえてffmpegと戦うの嫌だった
  • zipプレイヤーが既に実装されていた（あとで発表ある）
  • 振り返り
    • 画質良いの最高
    • サイズが大きい
  • うごイラの今後
    • ファイルサイズ小さくしたい
    • .ugoフォーマットを作る？
  • まとめ
    • うごイラはアニメGIFじゃない
    • うごイラは動画じゃない

ugoku player

  • @marcan42さん（資料）
  • フォーマットについて
    • GIFは古くて256色しか使えない. APNGはFirefoxのみ. MNGは対応ブラウザないし他のも…
  • HTML5 Canvasは最近のモダンブラウザではだいたい動く
  • zipは展開簡単で作成用のライブラリも多い。枯れてる
  • JavaScriptではArrayBuffer/UTF8Array/DataView/Blob...などを駆使して読み込む
  • rangeリクエストでzipファイルを分割ダウンロードして徐々に展開
  • zip_playerはgithubで公開している
  • プログレス読み込みで逐次ヘッダを展開して、タイミングとか描画とか
  • JSONでメタ情報を保持している
  • IE10未満やAndroid4.0未満では問題がある

Ugoku Backend

  • @harukasanさん（資料）
  • うごイラのために気を使った部分はそれほどない（いつもやっている通りにやった）
  • pixivの数値
    • 37億PV/月,、1100万ユーザ、4500万投稿
    • ピーク時 7Kreq/sec（画像は30Kreq/sec）、12Gbpsを10Gbps x 3、40TBのデータ、400台のサーバ
  • うごイラの画像アップロード
    • 最大150枚がアップロードされるのを、ユーザを待たせずに変換する必要がある
    • 非同期アップロード
      • ファイルアップロード → 情報入力 → 完了画面 という流れ
      • アップロードされたらRedisにキューを積んで、すぐに入力画面に遷移させる
      • 裏でサムネイルマスターの生成とGIF分割を実行して、アクティブとスタンバイにアップロード
      • 情報入力完了時点で処理が終わっていなければ待たせる
    • GIF画像の分割はgifsplitで、githubで公開している
    • うごイラでは小さめの画像とオリジナル画像、サムネイルマスターの3種類を保持する
    • WebDAVでストレージにアップロード
  • ダイナミックサムネイル生成
    • 今回から始めた
    • アップロード時に大量の画像を生成するのは大変
    • デザイン変更でサイズも変えたい
    • あらかじめサムネイルマスターと呼ばれる画像を用意しておく
    • アス比固定と正方形クロップのJPEG（PNG→JPEG変換はコストが高いのでJPEGにしておく）
      • クロップは、横長の場合は中央、縦長の場合は上合わせで切り取る
    • サムネイル生成はmod_small_light
    • ストレージから何度も取得しないようにnginxでキャッシュ（6割程度のヒット率）
  • Contents Delivery Cluster
    • スケーラブルで低遅延（100ms未満）、キャッシュヒット率95%以上、設定変更が用意
    • 前段のnginxキャッシュ（64Gメモリ）が10Gbpsの帯域で60%を捌く
    • 中段のApache Traffic Serverは3*256GB SSDで90%を捌く
    • 残りの10%を最後段のnginxがストレージから取得して返す
    • zip配信とCORS Non-simpleリクエストへの対応
  • うごイラのバックエンドは普通に動いている
  • きれいなシステムもいいけど、動いているのが前提
  • 動いた上で拡張しやすいように
  • 質問
    • 3*256GB SSDの構成を選択したのは何故か
      • コストバランスよいのが256GB SSDだった
      • 容量別でサーバを用意してキャッシュ効率調査した結果こうした
    • 何でサチる？
      • I/Owaitはそれほどでもないが、inodeが結構足りなくなることがある
      • 1台あたり700Mbpsくらい使っているので、1Gbpsの帯域だとそろそろ限界
    • ファイルシステムは？
      • 前はいろいろ試していたけど今はだいたいext4
      • 冒険していない

Ugoku PHP Development

  • @notonauさん
  • うごイラスクリーンセイバー
  • これまではdeployをrsyncで行なっていた
  • うごイラで使用するライブラリの都合で、Composerでのパッケージ管理にした
  • Composerのautoloadが、rsync中に同期されていないファイルへのアクセスを行うので必ずエラーが発生した
  • シンボリックリンクを張り替える運用にした
    • 2分かけて徐々に反映される症状があった → realpath cacheを無効化して対応（負荷に目立った変化はなし）
    • deployのたびにZend Opcacheのwested memoryが増えて開放されない問題 → 空いている時間にgraceful restartするようにした
  • 質問
    • ロードバランサなどで構成を切り替える運用にはしなかったのか
      • アプリサーバが数十台あるが、すべて差し替えるだけのリソースはなかった
      • 1台ずつ切り離して更新する方法もあるが、DB変更などでも不整合のないように一気に更新したかった

うごかなイラ

  • @shobyshobyさん
  • iOSアプリを作っている
  • うごイラリリース → 好評あったが、アプリで閲覧できない問い合わせが多数
  • リリース遅延と深刻なバグ
  • うごかなイラの作り方
    • APIなしでアプリを作る
    • 未実装機能のAPIをモックで
    • 動作確認なしでiOS審査に
  • Webと同時リリースするために（iOS審査があるので）先行で開発を始めた
  • APIは本体側の機能に依存しているが、ぎりぎりまでAPIがないまま審査には出さないといけない状況
  • 直前までAPIができなかったのでモックで開発
    • OHHTTPStubs
    • リリース後にキャッシュ周りで深刻な問題があった（モックでは気付けない問題だった）
  • zipをダウンロードして展開
  • CADisplayLinkが呼ばれるタイミングで描画
    • drawRectは描画領域が大きくなるほど重くなる（iPadなど）
    • 描画は最小限でaffine transで変換かけた
  • 未実装機能のAPI
    • APIのURLとレスポンス、DB設計は同時に決めるのがよい
    • Model部分はモック化すると差し替えに強くなるかも
  • 動作確認なしで審査に出す
    • Web版の完成次第リリースとの足並みを揃える
    • どうする
      • Webに待ってもらう → 現実的じゃない
      • 諦めてアプリをあとでリリース → 理想的
      • Web → Android → iOS の順だとリリースしやすい
    • Webと同時リリースを狙った開発は難しい
  • 質問
    • iOSの事前審査は何日くらいみていたか
      • 審査は平均5営業日程度と言われていたので、8日くらい
    • Webと同時リリースは何故？
      • うごイラは、イラスト・小説などと並んでサービスの根幹に据えるものとして考えていた
      • なるべく多くのユーザにサービスを届けるために、いちはやくリリースする判断をした
      • 開発環境では動作していた…
    • iOS版のプログレッシブ対応は
      • 検討します

うごイラAndroid

  • @RooandQooさん
  • 社員3名とアルバイト1名で開発した
  • ウェブと同時リリースを目指していた → Web版の翌日にリリースできた
  • リリース翌日に「ながもんゲーム」が話題になったが、Android版では一時停止できないので遊べなかった
  • 実装はできたものの、再生/停止のエフェクトで背景が黒くなったりちらついたりの問題で困ったりなどした
  • Android 2系滅ぼしたい

うごいてるコードレビュー

ugocat

  • @edvakfさん（資料）
  • geta6氏がTerminalで画像をcatしていた
  • うごイラでもやりたい
  • node-canvas + ansi.js でイラストは対応できた
  • zip_playerをnpm installしようとしたらpackage.jsonがなかった
  • 通信周りはnode-xhr2、node界隈では壊滅的なBlob/ObjectURLはbase64ByteArrayという素敵polyfillがあった
  • jQuery依存部分はイベント関連のみだったので、event-targetで自作した
  • ここまで作ったところで、AAで動画再生するライブラリ libcaca を教えてもらったので、node-canvasを対応させた
  • nodeのDOM互換ライブラリはいろいろあるけれど、仕様をまたいだものがないので全部のせのものがほしい