YPAC20121日目まとめ

休暇をいただいて参加してきました初YAPC！2日目は体調不良で行けなかったのですが、1日目だけまとめます!
ミスありましたらご指摘いただければ幸いです。では参ります!

Pixivサムネイル

規模

• 33億PV/month
• 6Gbps

画像

• イラスト3千万件
• 各々12〜100件のサムネイルができる仕様
• 総容量30TB

サムネイル生成の仕組み

• 静的なサムネイル生成と動的なサムネイル生成がある
• 静的
  • 画像を登録した後、ロックを発行。ユーザを画像情報登録画面に遷移させる
  • ユーザが画像情報を入力している間に、裏でサムネイルを生成する
  • サムネイル生成が完了するとロックを解除する
  • 画像情報登録画面 から 登録完了画面に行くにはロックの解除を待つ
  • 半非同期。最終的な完了状態に遷移するためにはサムネイルの生成を待つ必要があるが、待っている間に画像情報を入力させる。実質ユーザを待たせない
  • ストレージは自社製のWebDAVクライアント
  • キューの管理はQ4M
  • 画像処理にはImageMagick
    • 処理速度が他ソフトに比べて遅いのは確かだが、画質劣化が小さい。OpenMP無効化、libjpeg turboを使って最適化を行っている

静的サムネイル生成の課題と動的生成

• 課題
  • 新しいサムネイルのサイズを使う際には、全ての画像に対するサムネイルを生成しなおす必要がある
• 動的
  • Disk容量を消費しない
  • アプリの変更に強い
  • mod_small_lightをnginx向けに改造したモジュールを使っている
  • 高速化のために、サムネイル化した画像をキャッシュサーバに保持するようにしている

NHN：データクリーニング

• 生データを解析に使えるようにするためのプロセス

データの問題

• [1]データ自体の問題、[2]データのマージの問題の2つがある
• データ自体の問題
  • スキーマを定義することにより解決できる問題
    • 構造がない
    • セパレータが異なる
    • 表記ゆれにより同一データが別エンティティとして認識される
    • 同種データの表現方式違い。ex. 数字、漢数字の混合
  • スキーマを定義していも解決できない問題
    • null
    • 矛盾。循環参照、同じキーなのに値が異なる
• [2]データのマージの問題
  • 同種データの表現方式違い(数字、日付、...)
  • 単位の違い
  • 矛盾

データクリーニングの方法

• 機械と人による確認の両方が必要

1. データの観察

• 最初に観察!
• データが大量の場合、最初にサンプリングを試みる
  • ソート
  • 制約(ありえない制約を指定して、正しくないデータを探す)
  • 正規表現

2. 機械的処理の試み
3. 人で処理する際のガイドラインの作成
4. プロセスの見なおし

• ポイント
  • 扱うデータにぴったりあうライブラリはない
  • よって、処理しなければならない内容を記録しておく
    • 半角→全角
    • 前後のスペースの削除
    • etc.

• 正しいガイドラインを作るには
  • 日本語の定義を学び直す
  • 紹介していた本は、「日本語練習帳」か「日本語の教室」だったと思う。。。

クリーニングにおいて重視すること

• 精度。精度がでない速い方法を使うことは無意味
• テストを書く

リアルタイム通知システムの実装

通知システムの構成

• 初期構成
  • アプリサーバ以外に、通知専用のサーバがある
  • ユーザは通知専用のサーバに接続する。通知サーバはユーザのIDとコネクションのセットを持つ
    • アプリサーバからユーザXXXに通知してほしいと依頼を受けると、ユーザIDから該当するコネクションを探し、メッセージを流す

• 初期構成の課題
  • 通知サーバを1台しか持てない
  • 複数台の通知サーバを持つと、どのサーバに目的のユーザが接続しているか分からず、アプリサーバから全ての通知サーバに依頼を投げる必要がある

• 対応(第2版構成)
  • アプリサーバがユーザの接続先情報を持つ。ユーザは一度アプリサーバにアクセスし、指摘された接続先に接続する

• 第2版構成の課題
  • Failoverができない

• 対応(第3版構成)
  • DB管理

• 第3版構成の課題
  • 通知サーバによって負荷が異なる。つまり、アクティブなユーザが集まっているサーバに負荷が集中する

理想的な構成の検討

• クラスタ構成。アプリサーバからは巨大な通知システムに依頼すればいい。ユーザも巨大な通知システムに接続すればいい。巨大な通知システムの実態は複数のサーバで構築されている
• 「関心の分離」の実現
  • アプリサーバは「誰」に「何」を通知するかのみ管理する
  • 通知サーバは「誰」に通知するには、「どこに」通知すればいいかのみ管理する

• RabbitMQのPub、Subモデルで実現する
  • アプリサーバは、SubscriberIDと通知メッセージを通知サーバに投げる

平均レスポンス50msをPerlで捌く中規模サービス(Freakout!)

• Web+DB vol.70と併せて読むといい

概要

• Web広告の歴史
  • テクノロジによる先物取引から現物取引への進化
  • メディア主体の料金設定から、顧客主体の料金設定へ
• SSPとの接続ルール
  • 100ms以内にビッドリクエストに応答する
  • ネットワーク処理を差し引くとアプリ処理に使える時間は50〜70ms程度

何が課題か

• DSPの場合、入札サーバに最も負荷が集中する
  • 接続先SSPのimpの合計値が最大リクエスト数になる

アーキテクチャ

• 普通
  • nginx
  • starman
  • 素のpsgiアプリ
• KVS
  • memcached, TC, KT, TTを使っている
  • 複数のKVSの使い分け
  • TTはKCに移行中
  • 消えてはいけないデータは、TC/KT
  • 保存期間が数秒〜数分で応答速度を要求されるデータはmemcached
    • 入札データは一度memcachedに保存する
  • KVSにはメモリを最大限あてている
    • 32Gメモリサーバをキャッシュサーバにも使っていると思われる。本当は64Gメモリ欲しいようだ
• 他社を使ってる部分
  • バナーはCDN経由。必要な帯域がでかいため
  • DNSは他社。リスクがでかいため

高速化の工夫

• ネットワーク通信の最小化
  • DNSをバイパスするためにhostsで名前解決する
  • 入札情報は配信サーバのローカルに保存
• DB
• 高速化戦略。[1]I/Oを発生させない。[2]処理を後回しにする。どこを割り切るかの判断が重要
• [1]I/Oを発生させない
  • シリアライズしたデータをKVSに保存する
• [2]処理を後回しにする
  • 1回ログに書きだす
  • ログを保持するサーバ自信が1度集計する。続いて回収先で集計する
• SSDの利用
  • SSDの劣化を防ぐため、レプリケーションを切った運用をしている(!!)

運用の工夫

• ダウンしたサーバは一度サービスから外す。ウォームアップ処理を施す必要があるため
• 推測より計測
  • システム指標、ビジネス指標をとる
    • nginxのログに、upstream_res_time、restimeを書きだす
• ビジネス指標に基づいて判断を行う
  • ex. 障害の判断：サーバが1系統ダウンしてようと、配信に影響がなければ焦る必要はない

半リアルタイム・分散ストリーム処理をperで

• ストリーム処理
  • I/O処理の発生(システムコール、ディスク書き込み)がネック
  • 一度メモリに溜めて、ある程度溜まったら書きだす(bulk)。都度I/Oを発生させるのは非効率
    • fluentdなどミドルウェア自体がバッファリング処理をサポートしている場合もある
  • 但し、メモリに溜める量が大きい程、そのプロセスが落ちたらそのデータは損失することになる。どのくらいのデータが失われても許容できるかの判断が必要

感想

YAPCは初参加でした!参加のきっかけはFreakout!の発表があったこと。自分も広告の計測ツールを作っているため、勉強しに行ってきました。直前にWeb+DBを読んで疑問に思ったことを質問できたのでよかったです(´▽｀)。答えてくださった@myfinderさんに感謝。
懇親会にも参加でき、楽しい時間をいただきました!一緒に参加してくださった、@mashanさん、運営スタッフの皆さん、発表者の皆さん、懇親会でお話させていただいた皆さん、参加者の皆さん、場所と美味しい料理を提供してくださった東京大に感謝ですヾ(ﾟ∀ﾟ)ﾉ