オープンソース開発者がDeNAを選ぶ理由

オープンソース開発者がディー・エヌ・エーを選ぶ理由

株式会社ディー・エヌ・エー

奥　一穂

自己紹介

 氏名：　奥　一穂  所属：　株式会社ディー・エヌ・エー　　　　　　CTO室

2011年7月16日オープンソース開発者がディー・エヌ・エーを選ぶ理由 2


主な仕事

 Palmscape  1997年～　後に Xiino に改名  Palm OS 用ウェブブラウザ (実質世界初)

 IBM WorkPad, Sony CLIE 等にバンドル  NTT DoCoMo にライセンス

 M.I.T. TR100/2002 受賞  オフラインコンテンツの配信プラットフォームを兼ねる

 Webアプリケーション統合開発環境の開発  IPA 未踏 2004 – スーパークリエータ

主な仕事 (2)

 前職: サイボウズ・ラボ株式会社  2005年8月~2010年11月  Japanize

 Web UI の日本語化サービス

 パストラック  リアルタイムアクセス解析／データマイニングサービス

 Q4M  メッセージキュー (MySQLの拡張)


主な仕事 (3)

 現職: 株式会社ディー・エヌ・エー  2010年11月入社

 システム統轄本部IT基盤部

 2011年5月より CTO室


アジェンダ

 どうして DeNA に入ろうと思ったか  前職で開発した OSS の話と絡めて

 DeNA に入ったあと、どのように OSS と関わっているか

 一般論は難しいと思うので、自分の話になります


入社前の話（ビフォー）


Q4M


What is Q4M?

 A message queue  runs as a storage plugin of MySQL 5.1

 Why is it a MySQL plugin?  accessible by using existing MySQL clients

 no need for a new client library

 administrable by using SQL  friendly to DB admins

 First release: Jan 2008


Design Goals of Q4M

 Robust  Does not lose data on OS crash or power failure

 necessary for Tokyo wo. nuclear power plants… orz

 Fast  Transfer thousands of messages per second

 Easy to Use  Use SQL for access / maintenance  Integration into MySQL

 no more separate daemons to take care of


Users of Q4M

 Many leading web services in Japan  DeNA Co., Ltd.  livedoor Co., Ltd.  mixi, Inc.  Zynga Japan (formerly Unoh, Inc.)


What is a Message Queue?


What is a Message Queue?

 Middleware for persistent asynchronous communication  communicate between fixed pairs (parties)  a.k.a. Message Oriented Middleware

 MQ is intermediate storage  RDBMS is persistent storage

 Senders / receivers may go down


Minimal Configuration of a Message Queue


 Senders and receivers access a single queue

Sender Receiver

Queue

Using MQ as a Relay


 Separate queue for sender and receiver  Messages relayed between queues

Sender

Queue

Receiver

Queue

Relay

Merits of using Message Relays

 Destination can be changed easily  Relays may transfer messages to different

locations depending on their headers

 Robustness against network failure  no loss or duplicates when the relay fails

 Logging and Multicasting, etc.


Message Brokers

 Publish / subscribe model  Separation between components and their

integration  Components read / write to predefined queues  Integration is definition of routing rules between

the message queues  Messages are often transformed (filtered) within

the relay agent


What about Q4M?

 Q4M itself is a message queue  Can connect Q4M instances to create a

message relay  Provides API for creating message relays

and brokers


Performance of Q4M


 over 7,000 mess/sec.  message size: avg. 512 bytes  syncing to disk

 Outperforming most needs  if you need more, just scale out  Can coexist with other storage engines without

sacrificing their performance

see http://labs.cybozu.co.jp/blog/kazuhoatwork/2008/06/q4m_06_release_and_benchmarks.php

Q4M in DeNA


 uses Q4M for sending notifications asynchronously

http://engineer.dena.jp/2010/03/dena-technical-seminar-1-2.html

Q4M in DeNA

 Q4M のユーザーとして、おそらく最大  2,000万通/日以上の通知を処理

 バグ報告のかなりの割合は DeNA から  バグの切り分けや修正版のテストをいっしょに行う  入社前から


HandlerSocket Plugin


Memcached の利点と欠点

 利点  RDBMS の読込負荷低減 / 同時接続数が足りない  スケールアウトするキャッシュ

 欠点  RDBMS との一貫性維持が不可能

 クライアントがキャッシュを変更する限りは不可避

 問い合わせが複雑  Memcached に聞いて、なかったら RDBMS に問い合わせ

 データが溢れる  primary storage として使えない


「Memcached の利点」の前提

 RDBMS がスケールアウトしない  だから、読込負荷低減が必要  だから、別途「スケールアウトするキャッシュ」が必要

↓   シャーディング + スレーブ増設で解決可能

 解決不可能な問題:  同時接続数  あと、やっぱり SQL は遅い


遅いなら捨ててしまえ SQLパーサー (字余り)


Mycached

 2009年8月に公開  mysqld が memcached プロトコルを話せるようにする拡張  テーブルの中身を memcached プロトコルで get  ただしプライマリキーによる get 専用

 書き込みは SQL で


Mycached – 図説

2011年7月16日オープンソース開発者がディー・エヌ・エーを選ぶ理由 27 http://dev.mysql.com/doc/refman/5.1/en/pluggable-storage-overview.html を改変

mycached

Mycached – 実装

 1,200行くらい  JSON, msgpack, 独自形式によるレスポンス

 Picoev を使用 (I/O イベント駆動ライブラリ)  MySQL の内部構造は、多数のスレッドによる並行アクセスにむいていない (というのが定説)

 イベント駆動ライブラリで同時アクセス数を低減  get は軽いので、データ読込中に他の接続がブロックしても問題ない


Mycached – ベンチマーク


 SQL だと 40,000qps 程度

Mycached の問題

 作ったものの、サイボウズ・ラボでは使いどころがなかった  自分で使わない → 放置プレイ


HandlerSocket Plugin の登場

 DeNA樋口証が開発  2010年8月公開  モバゲーで実際に使用  MySQL Contributor Award 2011 受賞

 MySQL に非 SQL の高速インターフェイスを追加  同時接続数と qps の大幅向上  ぶっちゃけ mycached と同じ発想


…なんということでしょう！


僕のほうが先に作ってたもん…


僕のほうが先に作ってたもん… 僕のほうが先に作ってたもん…


僕のほうが先に作ってたもん… 僕のほうが先に作ってたもん… 僕のほうが先に作ってたもん…


転職して、中の人になる！！


教訓

 僕の価値観  アイデアをもっているだけでは不十分  ブログに書くだけでは不十分  実装するだけでは不十分  実際に使ってもらって、なんぼ

 そのためには、自分の書いたソフトウェアが実際に使われている（使われる可能性のある）現場に入るべき


ちなみに HandlerSocket Plugin の良いところ

 mycached より高速  テーブルの開閉タイミングの最適化等

 コンパクトなバイナリプロトコル  FastEther 環境でも安心

 主キー以外でのクエリ発行や更新処理


入社後の話（アフター）


ホットデプロイ


ホットデプロイ – 背景

 大規模・高負荷の環境で、高速にウェブアプリケーションロジックを更新したい  ゲームのイベント等が頻繁にあるので重要

 アプリケーションサーバをロードバランサから切り離しては再起動するのは遅すぎる

 アプリケーションサーバをロードバランサにつないだまま、ロジックのバージョンアップを行うことはできないだろうか?


ホットデプロイ – 解決策

 奥のモジュール群を使うことで解決しよう  Server::Starter – デーモン管理デーモン  Parallel::Prefork – プリフォーク型サーバのためのライブラリ

 Starlet – 上記モジュールを使う PSGI 互換のアプリケーションサーバ


ホットデプロイ – プリフォーク型サーバの問題


 ワーカープロセスの起動コストが大きい  fork が多発するタイミングでパフォーマンスが劣化

 既存解決策: mod_bumpy_life (Apache)  by hirose31++  MaxRequestsPerChild をランダマイズ

 ワーカープロセスの終了時期を分散する効果 ⇒ ワーカープロセス再起動のタイミングが分散される

 同様の機能を Parallel::Prefork に実装

ホットデプロイ – アップデート時のプロセス管理

 古いワーカープロセス回収時 ⇒ MaxRequestsPerChild のランダム化で対処済

 アプリケーションのアップデート時 ⇒ 一気に fork したらダメだし、どうしよう…


ホットデプロイ – 解決策: Slow Restart


 「じわじわ起動／終了する機能  ワーカープロセスの数を保ちながらforkのタイミングを分散

listen

spawn app. servers

accept

app. logic

fork & exec accept

app. logic

SIGUSR1

fork & exec

accept

app. logic

SIGHUP

ホットデプロイ – 成果は OSS に反映

 いずれの Perl モジュールも github 上で開発し、CPAN で配布  変更は反映済

 でもバグも発覚…


非同期シグナルの、たったひとつの冴えた待ち方

 Q. コードの問題点は?

$SIG{HUP} = sub { $got_sig = 1 }; … while (! $got_sig) { sleep(1000); // シグナルを受信したら眠りから覚める }




 Q. コードの問題点は?

$SIG{HUP} = sub { $got_sig = 1 }; … while (! $got_sig) { // このタイミングでシグナルを受信すると1000秒寝ちゃう！ sleep(1000); // シグナルを受信したら眠りから覚める }


 同様の問題が Parallel::Prefork にあった  負荷があがると、再起動が遅れるサーバが発生  ワーカープロセスの回収なんて滅多にないイベントなのに… ⇒ 大規模環境おもしろい

 解決策: 待機には pselect を使うこと  これ自体は FAQ  問題点: Perl には pselect がない！！！

 しかも XS (Perl のC拡張) としての実装が必要

 隣に座っている Perl XS のプロに、お♡ね♡が♡い♡


OSS開発者としてDeNAで働くということ


新しいものを使える企業文化

 Perl を例に…  2009年の段階で Plack を使用

 Perl における WSGI or Rack

 Furl (開発が進んでいる高速な HTTP クライアント)  最近のバグフィックス、機能追加は DeNA の id:xaicron が多い

 ハッカーが多いので、自分たちでリスクテイクできる  MySQL や他の分野についても同様


層の厚さと勉強する文化

 社内外での勉強会  例：社内勉強会の講師がMySQLエキスパートの松信  YAPC 等カンファレンスでの発表者多数  MySQL Conference での受賞を始め海外への派遣も

 層の厚さ  一部のエキスパートががんばる会社ではありません

 例: MySQL Casual

 パッチを送ったりしてる人多数  みんな結構個人ブログで技術ネタを書いてたりとか


まとめ


まとめ

 OSSは、もう空気みたいなもの  当然のように使ってる

 自分たちが必要とするものを自分たちで作るのがOSSの基本。だから「現場」がおもしろい

 大規模で先進的なことができると、いろいろフィードバックできる

 社内外でいろいろ相談できると楽しい 2011年7月16日オープンソース開発者がディー・エヌ・エーを選ぶ理由 54

オープンソース開発者がDeNAを選ぶ理由

Technology

Transcript of オープンソース開発者がDeNAを選ぶ理由