「ソーシャルゲームのためのMySQL入門」の続きを書こうと思っていた矢先に、Software Designの編集部の方にお声をかけて頂き、特集に記事を書かせて頂くことになりました。『ベンダ任せにしない 運用エンジニア「攻め」の仕事術』の第3章『「動き続けるものを作る」というオペレーショナルメンタリティ』ということで、私が日々携わっているMobageにおける運用エンジニアの現場の話を、結構細かめに書かせて頂きました。
技術に特化した内容よりも、むしろメンタリティだったり立ち居振る舞いといった部分に主眼を置いて、日々我々が思っていたり実践していることを紹介しております。DeNAのインフラはこんな感じですというのが少しでも伝わって、何か参考にして頂けるものがあれば幸いです。
同特集は他にも多種多様な運用エンジニアの方々がすばらしい記事を書かれていますし、その他の記事も非常に気になるものばかりですので、ぜひ皆さんお手に取って頂ければと思います！
]]>
初めまして、プラットフォームシステムグループの xaicron こと嶋田です。一部では鈴木と呼ばれていますが、実在する個人、団体とは関係ありませんのでご了承ください。
6/24 発売の Web+DB PRESS vol.63 に 「高速なWeb APIの実装とテスト」というタイトルで記事を書きましたのでちょこっと紹介します。
Mobage API を例に、どのようなことに気を付ければ高速な Web API を実装できるのかという割とニッチなネタを書きましたが、通常の Web アプリケーションであっても、そのまま転用して使えると思いますので「Web API とか興味ないし〜」と言う人も騙されたと思って読んでいただけると幸いです。
「Web API をOAuthに対応させよう」という記事や、pixiv さんの「段階的サービス拡張」という記事も載っているので、これ一冊あれば、Web API サーバーの全てを作ることが出来ますね！
また、見捨てられがちな DB や memcached を実際に使ったテスト方法についても少し説明してますので、この記事を読まれた方は、ぜひテストに挑戦していただければと思います。
樋口さん（大先輩ですので「さん」は欠かせませんね）が開発した Handler Socket についてもちょこっとだけ解説しています。 一部ではすでに導入されていて、すでに効果のほどが実証されており、今後もマッチする場所には積極的に使っていく予定です。 Handler Socket について詳しくは、こちらをご覧ください。
興味のある方は、ぜひお手に取って読んでみてください！
]]>Perlで書かれたアプリを動かしているときに、Perlのプロセスが今コードの何処を実行中なのか知りたいことがよくあります。そのような場合には、gdbで実行中のプロセスにアタッチし、Perlインタプリタインスタンスの内部を覗くことによって調べることができます。また同様の方法で、プロセスのコアダンプを取り、後でじっくりデバッガで調べることも可能です。
]]> デバッグシンボル付きのPerlを用意するまず前提として、Perlの実行形式にデバッグシンボルが付いている必要があります。無い場合でも不可能ではありませんが、現実的には難しいでしょう。デバッグシンボル付きのPerlを用意する方法はOSによりますが、例えばrpmを使っているGNU/Linuxディストリビューションであればperl-debuginfoのように分離されたパッケージにデバッグシンボルが入っていることが多いようです。
例として、以下のコードで無限ループさせたプロセスにアタッチしてみます。
#!/usr/bin/perl
sub foo {
my $a = $_[0];
print "$a\n";
while (1) {
}
}
sub bar {
foo("abc", "xyz", 999, 333.333);
}
bar();
gdbで実行中のプロセスにアタッチするには、以下のように実行します。
$ gdb -p プロセスid
アタッチすると対象プロセスは実行を停止し、gdbのプロンプトで止まります。
まずCコードの呼出しトレースを取ります。
(gdb) bt
#0 0x008de98f in Perl_runops_standard (my_perl=0x8c7e008) at run.c:37
#1 0x0088420e in S_run_body (my_perl=0x8c7e008) at perl.c:2372
(以下省略)
アタッチした瞬間に実行していた場所に応じて、色々な場所で停止することがありえます。まずここではmy_perlという名前の変数を探します。このmy_perlがPerlのインタプリタインスタンスです。今の例では末端のフレームにmy_perlがありますが、たまたま停止した位置がCの関数の中であった場合には末端のフレームには有りません。無い場合にはmy_perlが有るフレームまで移動します。(Perlのビルド方法によっては、my_perlが呼出し引数に無いかもしれません。その場合はグローバル変数としてmy_perlが有ると思いますが未確認です。)
(gdb) fr 0
#0 0x008de98f in Perl_runops_standard (my_perl=0x8c7e008) at run.c:37
37 while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
(gdb) p my_perl
$1 = (PerlInterpreter *) 0x8c7e008
このmy_perlの中を覗いて現在の状態を調べてみます。まず最初に、実行を停止した時点でPerlコードのどの位置にいたのかを調べます。
(gdb) p *my_perl->Tcurcop
$2 = {op_next = 0x8c9bf60, op_sibling = 0x8c9bf90,
op_ppaddr = 0x8dfe10 , op_targ = 0, op_type = 174,
op_seq = 11, op_flags = 1 '\001', op_private = 0 '\000', cop_label = 0x0,
cop_stashpv = 0x8c9bff8 "main", cop_file = 0x8c9bda8 "debug.pl",
cop_seq = 2, cop_arybase = 0, cop_line = 6, cop_warnings = 0x0, cop_io = 0x0}
cop_fileとcop_lineがファイル名と行です。cop_stashpvがパッケージ名です。この位置までの呼出しトレースは以下のようにして調べられます。
(gdb) p my_perl->Tcurstackinfo->si_cxix
$3 = 3
(gdb) p *my_perl->Tcurstackinfo->si_cxstack[3].cx_u.cx_blk.blku_oldcop
$4 = {op_next = 0x8c9bf60, op_sibling = 0x8c9bf90,
op_ppaddr = 0x8dfe10 , op_targ = 0, op_type = 174,
op_seq = 11, op_flags = 1 '\001', op_private = 0 '\000', cop_label = 0x0,
cop_stashpv = 0x8c9bff8 "main", cop_file = 0x8c9bda8 "debug.pl",
cop_seq = 2, cop_arybase = 0, cop_line = 6, cop_warnings = 0x0, cop_io = 0x0}
(gdb) p *my_perl->Tcurstackinfo->si_cxstack[2].cx_u.cx_blk.blku_oldcop
$5 = {op_next = 0x8c9c288, op_sibling = 0x8c9c1c8,
op_ppaddr = 0x8dfe10 , op_targ = 0, op_type = 174,
op_seq = 17, op_flags = 1 '\001', op_private = 0 '\000', cop_label = 0x0,
cop_stashpv = 0x8c9c220 "main", cop_file = 0x8c9c210 "debug.pl",
cop_seq = 4, cop_arybase = 0, cop_line = 11, cop_warnings = 0x0,
cop_io = 0x0}
(gdb) p *my_perl->Tcurstackinfo->si_cxstack[1].cx_u.cx_blk.blku_oldcop
$6 = {op_next = 0x8c9d438, op_sibling = 0x8c9d458,
op_ppaddr = 0x8dfe10 , op_targ = 0, op_type = 174,
op_seq = 27, op_flags = 1 '\001', op_private = 0 '\000', cop_label = 0x0,
cop_stashpv = 0x8c9a068 "main", cop_file = 0x8c9b878 "debug.pl",
cop_seq = 5, cop_arybase = 0, cop_line = 14, cop_warnings = 0x0,
cop_io = 0x0}
Tcurstackinfo->si_cxixが呼出しの深さで、その値のオフセットが呼び出された側の末端です。呼出し先のパッケージ名と関数名は次のようにすればわかります。
(gdb) p my_perl->Tcurstackinfo->si_cxstack[2].cx_u.cx_blk.blk_u.blku_sub.cv->sv_any->xcv_gv->sv_any->xgv_stash->sv_any->xhv_name
$8 = 0x8c92848 "main"
(gdb) p my_perl->Tcurstackinfo->si_cxstack[2].cx_u.cx_blk.blk_u.blku_sub.cv->sv_any->xcv_gv->sv_any->xgv_name
$9 = 0x8c9c0a0 "foo"
呼出しの引数は以下の変数に入っています。
(gdb) p my_perl->Tcurstackinfo->si_cxstack[2].cx_u.cx_blk.blk_u.blku_sub.argarray
$10 = (AV *) 0x8c7f618
このAVというのはPerl配列の内部表現です。配列の中を見るには次のようにします。
(gdb) p $10->sv_any->xav_fill
$11 = 3
(gdb) p *((SV**)($10->sv_any)->xav_array)[0]
$12 = {sv_any = 0x8c7fc20, sv_refcnt = 1, sv_flags = 75760388}
(gdb) p *((SV**)($10->sv_any)->xav_array)[1]
$13 = {sv_any = 0x8c7fc2c, sv_refcnt = 1, sv_flags = 75760388}
(gdb) p *((SV**)($10->sv_any)->xav_array)[2]
$14 = {sv_any = 0x8c98e3c, sv_refcnt = 1, sv_flags = 25232129}
(gdb) p *((SV**)($10->sv_any)->xav_array)[3]
$15 = {sv_any = 0x8c9c2c8, sv_refcnt = 1, sv_flags = 42074882}
SVはPerlスカラ値の内部表現です。SVの型を調べるには次のようにします。
(gdb) p $12.sv_flags & 0xff
$16 = 4
(gdb) p $13.sv_flags & 0xff
$17 = 4
(gdb) p $14.sv_flags & 0xff
$18 = 1
(gdb) p $15.sv_flags & 0xff
$19 = 2
値の意味は次のようになっています。SVt_PVは文字列型、SVt_IVは整数型、SVt_NVは浮動小数点数型です。
typedef enum {
SVt_NULL, /* 0 */
SVt_IV, /* 1 */
SVt_NV, /* 2 */
SVt_RV, /* 3 */
SVt_PV, /* 4 */
SVt_PVIV, /* 5 */
SVt_PVNV, /* 6 */
SVt_PVMG, /* 7 */
SVt_PVBM, /* 8 */
SVt_PVLV, /* 9 */
SVt_PVAV, /* 10 */
SVt_PVHV, /* 11 */
SVt_PVCV, /* 12 */
SVt_PVGV, /* 13 */
SVt_PVFM, /* 14 */
SVt_PVIO /* 15 */
} svtype;
データの中身を取り出すには、各データの型に応じて次のようにします。
(gdb) p *(XPV*)$12.sv_any
$20 = {xpv_pv = 0x8c9c148 "abc", xpv_cur = 3, xpv_len = 4}
(gdb) p *(XPV*)$13.sv_any
$21 = {xpv_pv = 0x8c9c198 "xyz", xpv_cur = 3, xpv_len = 4}
(gdb) p *(XPVIV*)$14.sv_any
$22 = {xpv_pv = 0x0, xpv_cur = 0, xpv_len = 4257, xiv_iv = 999}
(gdb) p *(XPVNV*)$15.sv_any
$23 = {xpv_pv = 0x0, xpv_cur = 0, xpv_len = 0, xiv_iv = 0,
xnv_nv = 333.33300000000003}
以上の結果は、基本的にはPerlのソースコードを読んで調べました。呼出しトレースの取得方法は、Perlのcaller関数のソースを参考にしました。
]]>今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。
]]> その前に。。。先日行われたJAPAN INNOVATION LEADERS SUMMITで弊社松信が「ソーシャルゲームのためのデータベース設計」という発表を行いました。
このエントリの最後にslideshareの資料を貼っておきましたが、僕のエントリなんかよりずっとずっと勉強になるのでぜひぜひ御覧ください。データベースの教科書的な話とのことですが、僕みたいに現場叩き上げの人間は教科書的な勉強をしていないので、知識を体系的に整理するのにはうってつけの資料です。
また、31枚目の「インフラエンジニアのキャリア」という図が秀逸です。インフラエンジニアに興味のある方はぜひとも目を通して頂いてイメージをふくらませて頂きたいと思います。
さて、それでは本題に入りましょう。前回はinsert中心のログ系のデータということでしたが、今回前半はユーザID毎に1レコードになるようなデータ、いわゆる「ユーザデータ系」のご紹介です。
このタイプのデータでは、どう頑張ってもレコード数はゲームのユーザ数にしかなりません。さすがに巨大SNSとかになってくると何千万や何億というユーザ数になってしまうのでバカになりませんが、ソーシャルゲームではそこまでいくことは稀ですし、もしユーザが猛烈に増えたとしてもユーザ数に比例してしか大きくなりませんのでサイズについてそこまで恐れることはありません。
次回以降説明する予定の「ユーザID1つで複数レコード持つデータ」や「ソーシャルグラフ的データ」はユーザ数が増えると爆発的にレコード数が増える可能性があるので注意が必要ですが、ユーザID毎に1つしかレコードがなければそこまで注意する必要はありません。
user_idでユーザデータ系のデータをレンジで検索することは少ないと思います。ほとんどの場合、user_idを指定して更新・参照するパターンばかりだと思いますので素直にuser_idをPKにすると良いでしょう。次回説明予定ですが、InnoDBを利用する場合クラスターインデックスという形になるのでPK指定でのルックアップは非常に効率がよいです。
user_idをキーにしたデータというのはソーシャルゲームではものすごい沢山あると思います。ニックネーム、レベル、攻撃力、経験値、あげればキリがないと思います。これらを全て1つのテーブルのカラムとしてもつのが素朴な実装ではあるのですが、それぞれのカラムが更新・参照される頻度には相当バラツキがあると思います。
例えばニックネームはそんなに頻繁に更新されることは無いですが、ほぼ全てのページでニックネームを出す設計なら参照回数は非常に多くなります。反対に経験値などは更新は頻繁に行われますが、参照される回数はそこまでではないことがあります。
そういう場合に、アクセスパターンや用途に応じてテーブルを分けておくと便利です。例えばこんな感じ。
CREATE TABLE `user_data` (
`user_id` int(10) unsigned NOT NULL,
`nickname` varchar(40) NOT NULL,
`type` tinyint(10) NOT NULL,
...
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB
CREATE TABLE `user_param` (
`user_id` int(10) unsigned NOT NULL,
`exp` int(10) NOT NULL,
`hp` int(10) NOT NULL,
...
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB
CREATE TABLE `event_user_param` (
`user_id` int(10) unsigned NOT NULL,
`event_point` int(10) NOT NULL,
`event_status` int(10) NOT NULL,
...
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB
こうしておくとよい点は以下の様なものがあげられます。
user_dataテーブルはmemcached等にどんどんキャッシュする
user_paramテーブルはカラムを絞ってサイズを小さく保つ
event_user_paramテーブルは別で持つ
drop tableすることでサイズを減らせるそして、このようなuser_idをキーでひっぱってくる様なデータには弊社樋口が開発したHandlerSocket pluginを利用すると非常に効果的です。memcachedなどのキャッシュを挟むとどうしてもRDBとキャッシュ層でのデータのズレが発生する可能性があります。2相コミットでもしない限りどちらか片方だけ更新に失敗してしまうということは原理的に避けられません。
そこで特に参照にHandlerSocketを用いることで、SQLを使ってselectするよりもはるかに高速に参照しつつ、データソースはInnoDBを直接叩いているのでデータが不正なものかどうかの心配をしなくてもよいといいことづくめになります。
DeNAではすでにHandlerSocketを本格導入しており、今までmemcachedを利用してuser_idをキーにした参照をしていた部分を数台のslave DBに向けることで高速かつサーバの集約をすることができました。memcachedを利用していた時にはDBの更新を検知してmemcachedのデータも更新するという仕組みが必要でしたが、HandlerSocketの更新はMySQLのレプリケーションに任せておけばよいのでそれも気にする必要がなく非常に運用が楽になります。もちろん、参照をslaveに向けている場合にはレプリケーションの遅延があり得ますのでその点は注意する必要があります。
さて、後半はゲームのパラメータなどのマスターデータについてです。マスターデータとは、例えばアイテムの名前やモンスターの出現確率など、運営側が更新する以外には更新されることのないデータを指します。
ユーザからの更新はあり得ないので、これも先のuser_data同様に基本はキャッシュさせることが重要です。いくらMySQLが速いからと言っても1リクエストの中で何度も何度も通信を行うことは非効率です。どれだけ高速になったところで最悪TCPのラウンドトリップの時間はかかってしまいますので通信する必要のないものは通信を控えるのが肝要です。
というわけで、ここではちょっと話を横にそれてキャッシュの簡単な考え方を紹介します。一般的なwebのシステムの場合、キャッシュをさせる層としては簡単には以下の様に分類できます。
一般的なwebアプリケーションではmod_perlやFastCGIと言ったアプリケーションのプロセスを永続的に起 動させておく構成にしておくと思います。その際にプロセスの持っているメモリ空間を利用して一度利用した情報をキャッシュさせておくのが１．になります。あるキャッシュが効果を発揮するのが1プロセスに限られるので効果の範囲は一番狭いですが最も高速です。あるユーザのリクエストが続けて同じプロセスにやってくることは普通は稀だと思いますのでキャッシュ効果の薄いものを沢山乗せ過ぎてプロセスのメモリが肥大化しないように注意する必要があります。
1台のサーバ上ではアプリケーションのプロセスが複数立ち上がっているのが普通だと思いますがそれらのプロセス間でキャッシュを共有するのが２．になります。実現方法としてはいくつか考えられて、共有メモリを利用する方法や、ファイルキャッシュを利用する方法があります。または、アプリケーションサーバ上にローカルなmemcachedやKyotoTycoonなどのデーモンを立ててしまうという方法もありますね。いずれのやり方でもネットワーク越しの通信は発生しませんし、キャッシュが効果を発揮する範囲がサーバ上のプロセス全体になるため、プロセス単位でキャッシュするよりヒット率は高まります。
そして３．が一般に良く使われるmemcachedなどを使ったキャッシュの仕組みになります。1度キャッシュされてしまえば、全てのリクエストでキャッシュの効果が発揮されますが、キャッシュサーバとの通信が発生してしまうのがネックになります。Consistent Hashingなどを利用して複数サーバでのキャッシュプールを形成している場合にキーの命名を間違えて単一キーへアクセスが集中すると、あるサーバにだけトラフィックが集中してしまいそのサーバの限界(トラフィックや同接数など)を超えてしまうことがあるのでキーの命名には注意が必要です。
基本的には更新頻度が低くアクセス頻度の高いものほど１．に向いていると思います。その意味でマスターデータはうってつけです。それぐらいだったら、アプリケーションのコードの中にベタッと書いてしまってもいいんじゃないかという意見もあると思いますが、あくまでもマスターデータはMySQLに持っておくことで、ゲーム内の確率などをバックエンドツールから簡単に変更することができて便利だと思います。永続化したプロセスはおそらく諸々の理由で適当なタイミングで再起動させていることが多いと思いますので再起動によってキャッシュはクリアされて最新の情報が反映されます。
プロセス単位ではそこまでキャッシュヒットしなさそうなデータや、キャッシュサイズが大きくてメモリの肥大化が気になる様なデータは２．のサーバ単位でのキャッシュをしておくと1サーバの中で1度でも使われればキャッシュされますし、メモリを節約しつつ利用することができます。また、プロセスの再起動後も継続してキャッシュを利用することもできます。ただし、キャッシュライブラリを使う場合、実装によっては思わぬバグがあったりするので安易に過信はしないことが重要です。
３．については主にリアルタイムな更新反映が必要なキャッシュに向いています。１．や２．では各プロセスや各サーバ毎でキャッシュの破棄のタイミングがバラバラになってしまいます。そんな時はmemcachedの様に一元管理してしまえば、そこを更新すればすぐに全てのリクエストに対して反映される様になります。
もちろんマスターデータをHandlerSocketで取るというのも一つの手だとは思いますが、マスターデータはjoinして取りたい場合などもあると思いますので意外と単純ではないことが多いと思います。なにより先述の通り無駄な通信は減らすに越したことはないですので、なるべくローカルにキャッシュすることが大規模を目指す場合には大事だと思います。
今回はMySQL特有の話はほとんど無くなってしまい、タイトルは完全に釣りでした。すみませんすみません＞＜ キャッシュの考え方はかなり単純化した話になっていますので適時脳内補完して皆様の管理されているシステムにご活用頂ければと思います。
次回は皆さんお待ちかねのInnoDBのお話です。あの本とあの本読んどけって説もありますがそんな時間ねぇよって人の為に3分で分かる様にまとめてみたいと思います(多分無理)。その次の性能管理やトラブルシュートのTIPSなどが本当は一番書くネタが豊富なんですがそこに辿りつくまでが長いですね！
というわけで、MySQLと楽しくソーシャルゲームを作っていきましょう！
God bless your MySQL!
ngCore engine とは iOS/Android/Flash アプリケーションとして開発出来る SDK でモバゲータウン及び、ngmoco のプラットフォームをベースとする英語圏向けのモバゲータウンの双方のプラットフォーム向けに出す事が出来ます。
開発言語としては JavaScript でアプリケーション開発を行う事が出来て、尚かつ高速に動くように設計されております。
講演の中では次のような事を説明しております。
特に ngCore では普通の Web 開発における JavaScript による UI の記述と開発の仕方やその確認方法までほとんど同じ様に出来ます。この点がネイティブSDKで Java や Objective-C で記述する際の手続きの多さに比べた優位性だと思います。
現時点では一般の開発者の方に触って頂く事は出来ないのですが、今年の春くらいを目処にサードパーティ向け SDK を出す予定ですので、詳しくは デベロッパーサイト にて法人アカウントを取得して頂けると幸いです。
今度とも弊社では SmartPhone 上でのプラットフォームを充実させて行く予定です。引き続きこのブログでも ngCore や周辺技術についてアウトプットしていきたいと思っております。
]]>
気付けば、DeNA Technology Seminar の #3 の企画を立てている zigorou です。さて、だいぶ公開が遅れてしまった事を冒頭お詫び致します。
本、エントリ自体は 2010/07/02 に作成された物ですので、時間軸に関しては察してあげて下さいませ。
先日行われました DeNA Technology Seminar #2 にお越し頂いた皆さん、ust を視聴して下さった皆さんありがとうございます。
当日のスライド及び動画の方を公開致します。
究極の HA ソリューションと呼び声の高い Spider Storage Engine の最新の話を含んだ講演でした。実績も積みつつあるようなので要チェックです！
MySQL の Storage API を SQL 解析せずに直接叩く形の plugin である handlersocket plugin の話です。memcached とはおさらば出来るかもしれません。今後、本ブログにてコードを公開する予定ですのでお楽しみに。
動画撮影の都合上、斯波様の動画の後半にあります。
ご存知 nippondanji こと奥野様による MySQL 5.5 の新機能の解説。魅力的な機能が増えつつも速度面も向上しているとの事ですので、今後 5.5 から目が離せないですね。
こちらは2010/11/15に行われました DeNA Technology Seminar #3 のスライドです。今回はJavaScript と UI 特集と銘打って行われました HTML5 や SmartPhone 向けの開発についての話です。
]]>弊社横江による、Y!モバゲーでの OpenSocial JavaScript API の裏側でどのように実装やテストを行っているかと、 osapiへの対応、さらには今後のどのような展開をしていくかと言う話を致しました。
株式会社ミクシィの瀧本様によるご講演です。まだ語られていない Smart Phone 向けアプリケーションプラットフォームの mixiTouch の裏側についてお話頂きました。
弊社岸による、Pirate Nationの開発でHTML + CSS + JSを使ってみて得られたノウハウについて。主にCanvasやCSS Animationについて話しました。
The Tale of JavaScript, The Future of ECMAScript
Cookpad の太田様にご講演頂きました。JavaScript の今までと現在、未来について HTML5 や User Interface を絡めてお話頂きました。
外部講師のお二方には実サービスの裏側で用いられている JavaScript のテクニックや、最新の HTML5 の動向などをお話頂きました。SmartPhone に搭載されている特に WebKit ではこれらの新しいテクニックを用いる事が出来る現実的なブラウザが搭載されておりますのでとても参考になります。
また弊社では今回は今年度(横江)、昨年度(岸)の新卒エンジニアが登壇致しました。mixi 瀧本様も08新卒だそうで、新卒のエンジニアが現場の第一線で最先端のテクノロジーに触れながらサービスとしてリリースすると言う事が実際の仕事として行われています。
これからも有望な新人が来ると思うと楽しみですね。さて、次回の DeNA Technology Seminar #4 もお楽しみに！
2010-12-22 (水) 発売の WEB+DB PRESS Vol. 60 に「ソーシャルゲームの創り方・育て方」という記事を、同じ DeNA の山田、城戸と共同で寄稿しました。特集 3 の「本番プロジェクト運営ノウハウ大公開」の中の第 4 章となっており、他にチームラボさん、英和システムマネジメントさん、ゼロベースさんが 1 章ずつ執筆されています。
パートごとの概要は以下のとおりです。
* DeNA の開発スタイルの背景 (執筆 = 能登)
DeNA での開発で重視されている、考えた人がそのままつくる、少数精鋭チームでシンプルでありながらユーザインパクトの大きなものをつくる、などの考え方を紹介し、そういう考え方に至った理由やビジネス背景を紹介します。
* ゲームを生み出すフェーズ (執筆 = 山田)
新規ゲーム開発の流れを、チーム発足、ゲームコンセプト設計、プロトタイプ作成、α版/β版の開発、正式版のリリースなど順を追って紹介します。また、リリース後のふりかえりの実例についても触れています。
* ゲームを育てるフェーズ (起案 = 城戸, 文章化 = 能登)
ゲームをリリースした後に大きく育てるフェーズのほうが初期開発より関わるメンバが増え、よりシステマティックな体制や開発サイクルが必要になります。このパートではそういった側面について紹介しています。
* ゲームチーム横断の情報共有・施策 (執筆 = 山田)
生み出す/育てるフェーズに関わらずソーシャルゲームチームに導入されている情報共有や開発支援ツールの紹介と、個別ゲームをまたがった施策を実施するチームの取り組みを紹介します。
興味を持っていただけるようでしたら、ぜひ書店で手にとっていただきたいと思っています。よろしくお願いします。
]]>DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。
僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。
「MySQLの話か、なんだアプリ開発の自分には関係ないな」と思ったそこのあなた！今回僕がこういう記事を書いている趣旨は、むしろ開発側の人たちにこそもっといいMySQLの使い方を知ってもらいたいと思ったからです。データストア層を使いこなせてこそ真のアプリ開発者ですよね！
]]>世の中流行りは「NoSQL」とか言われてるみたいですが、DeNAでは携帯ソーシャルゲームという高トラフィックなシステムでもデータストア層にはMySQLをヘビーに使っています。なぜでしょうか。
それは僕がMySQLが好きだからです
嘘です。すいませんすいません。真面目に書きます。MySQLにはなんといっても「輝かしい実績」があります。10年を数えるレプリケーションシステム、高速・安全なトランザクショナルストレージエンジンInnoDB、そしてFacebookやGoogle、弊社のモバゲータウンをはじめとした大規模サイトでの実績。
今では枯れた技術感のあるmemcachedですら、先般mixiさんが遭遇したようなクリティカルなバグがあったりしました。その意味では大規模サイトでの実績充分、バクデータベースも豊富なMySQLは最も安定したデータストアであると言えます。NoSQLとかで話題になっているミドルウェアは確かに新しく、適切な使い方をすれば非常に有効だと思います。しかし、安定感や使い方という意味でMySQL程に枯れたものは存在しません。さらに弊社松信の言葉にもある様に「これから」も安心できるミドルウェアでもあります。
例えばその昔は「InnoDBは遅い」と言われていた時代もありましたが、今では十分に速く、弊社樋口が開発したHandlerSocket pluginの能力を見てもらえれば分かるとおり、うまく使えばInnoDBは十分に高速です。うまく使えば。。。
そう、この「うまく」の部分がなかなか難しいのです。特にソーシャルゲームは普通のSNSと比べて高トランザクションになりがちで、それでいてテーブルのサイズは猛烈な勢いで肥大化します。InnoDBを効率良く使いこなすためには、必然的にそのデータ構造を理解した上でスキーマを考えクエリを考えていく必要があります。
というわけで前置きが長くなりましたが、今回はInnoDBをソーシャルゲームで使う時にどういう風にテーブルを作ったらいいのか、ということを少しだけお話したいと思います。(MySQLの設定とかの話はまた今度でー)
MySQLの設定パラメータを変更するだけで高速にできることは限られています。何よりもスキーマとクエリを効率的にすることが重要です。ソーシャルゲームでよく用いられるテーブルにはどういうタイプのモノがあるかを考えてみましょう。全てではないですが、よくあるタイプはこんな感じです。(一度でもRDBを使ってアプリ作ったことがない人には少々わかりにくいかも知れません＞＜)
これは分かりやすいですね。例えばuser_idをプライマリーキーにして、ニックネームや経験値などのデータを保存する類です。
CREATE TABLE `user_data` (
`user_id` int(10) unsigned NOT NULL,
`nickname` varchar(40) NOT NULL,
...
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB
これは例えばユーザの持っているアイテムのデータなどです。user_idとitem_idの複合キーがプライマリーキーになる感じです。
CREATE TABLE `user_item` (
`user_id` int(10) unsigned NOT NULL,
`item_id` int(10) unsigned NOT NULL,
`num` int(10) unsigned NOT NULL,
...
PRIMARY KEY (`user_id`,`item_id`)
) ENGINE=InnoDB
これがソーシャルゲームならではのデータです。例えばあるユーザの友達のデータとか、あるユーザと別のユーザのやり取りを記録するデータとか。user_id-Aとuser_id-Bの複合キーがプライマリーキーになる様な感じです。
CREATE TABLE `user_relations` (
`user_id` int(10) unsigned NOT NULL,
`tgt_user_id` int(10) unsigned NOT NULL,
`visit_num` int(10) unsigned NOT NULL,
...
PRIMARY KEY (`user_id`,`tgt_user_id`)
) ENGINE=InnoDB
これは例えば何かのアクションの履歴データなどです。自分や他人からのアクションの履歴を表示したいときなどに活用すると思います。これはシーケンシャルな数字がプライマリーキーになり、それを他のテーブルに格納しておいたり、セカンダリインデックスで検索する形になると思います。
CREATE TABLE `action_log` (
`id` bigint(20) unsigned NOT NULL,
`date` timestamp NULL DEFAULT 0,
`value` int(10) unsigned NOT NULL,
...
PRIMARY KEY (`id`)
) ENGINE=InnoDB
これは敵の出現確率とかアイテムの名前とか、主に運営側のみが更新するデータです。こういうデータは別にRDBに保持する必要はなくて、ファイルにまとめてアプリサーバにデプロイする運用もあると思いますが、バックエンドツールを使ってエンジニア以外の人でもパラメータが変更したいとかがある場合にはRDBに保持している方が楽ちんだと思います。
CREATE TABLE `item_conf` (
`item_id` int(10) unsigned NOT NULL,
`item_type` tinyint(3) unsigned NOT NULL,
`name` varchar(255) DEFAULT NULL,
...
PRIMARY KEY (`item_id`)
) ENGINE=InnoDB
もちろんこれら以外にいろんなデータはあると思いますが、多くのソーシャルゲームで共通しているのはここに当てはまるものが多いと思いますし、この辺のデータの扱い方が分かってくれば、これら以外のデータについても適切な扱い方のコツが分かってくると思います。
これらのテーブルについて、ソーシャルゲーム＋InnoDBという組み合わせにおいてどういったアプローチを取るのがよいかという話をしたいのですが、全部やると多いので今回はまずログ系のテーブルについてフィーチャーしてみたいと思います。
いろんな欲求からログ系のテーブルを作りたくなることはしばしばあると思います。お金がらみのものが動くときの記録や、あるアクションの履歴をユーザ毎に見せたいとか。
ログ系のテーブルでは基本は新しくinsertされた行への参照がほとんどになる様に設計すべきです。何よりもこれが大事。ログ系のテーブルは放っておけばどんどんサイズが大きくなります。アクセスされるデータの量が昔のものまで満遍なく存在していると、buffer poolというメモリキャッシュに載せるべきデータが時間と共にどんどん増えていき、すぐにメモリから溢れてIOが発生します。IOは怖いです。まんじゅう怖いとは違います。マジで怖いです。
これにはサービス的な割り切りが必要になることもあります。「2週間より前のデータは見れません」という仕様にしてしまえば、サービス的に2週間より前のデータは不要になるはずですが、「サービス開始時点から全て見れます」という仕様にしてしまうと、結構大変です。
下手にこんな仕様にしてしまうと、Twitterさんがやっている(と言っている)様に、いずれ時系列でサーバ自体を分ける様な運用が必要になってしまうでしょう。
とは言え、こういう背景を知らない人が普通の感覚で言ったら「全部見れて当たり前」という風になってしまうもの。ここはエンジニアが費用対効果を良く検討して、どういう仕様が適切なのかを考えてあげる必要があると思います。
さて、最近のデータだけあればよい、という設計ができたとしましょう。しかし、一度insertしてしまったデータは消さない限り基本的にはずっとDBには残り続けてしまいます。極端な例で言えばアクセスログの様に全PVで1レコードをこのテーブルに入れてしまうと、ソーシャルゲームの様にPVの多いサービスではあっという間に数億件とか数十億件とか、そういうサイズになってしまいます。
buffer pool的にはアクセスのないデータはメモリから追い出されるのであまり性能的な劣化はないかも知れません。しかしこのままでは物理的な「容量」がいずれ問題になってしまいます。DISKも無限ではありません。
そこでよくある方法としては、古いデータをdeleteで消す(パージする)というやり方です。先程も書いた様にこの手のテーブルで必要なデータは「最近」のものであることが多いので、思い切って消してしまうという戦略は当然アリです。ただし注意が必要で、deleteはクソ重いです。大切なので2回言います。deleteはクッソ重いです。ログ系のテーブルの場合、わざわざbuffer poolに乗ってないデータを読みだして消す必要があるため、ゲロ遅いです。
仕方ないので、MySQL 5.0の頃はパージするスクリプトを作って夜中のアクセスが少ない時間に毎日回してせっせと消すといった作業が必要でした。
しかし、MySQL 5.1からは念願の「パーティション機能」が追加されていますのでこれを使わない手はないでしょう。
パーティションを知らない人のために説明しますと、簡単に言えば1つのテーブルを「ある規則」に従って別のテーブルの如く格納させる仕組み、と言えると思います。「ある規則」は色々設定できますが、データパージという意味でよく使うのは「RANGEパーティション」といって、あるカラムの値の幅で切るというやり方です。言葉の説明だけだと分かりにくいですが、こんな感じ。
CREATE TABLE `action_log` (
`id` bigint(20) unsigned NOT NULL,
`date` timestamp NULL DEFAULT 0,
`value` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`,`date`)
) ENGINE=InnoDB
PARTITION BY RANGE (UNIX_TIMESTAMP(date))
(PARTITION p20101004 VALUES LESS THAN (UNIX_TIMESTAMP('20101004')),
PARTITION p20101011 VALUES LESS THAN (UNIX_TIMESTAMP('20101011')),
PARTITION p20101018 VALUES LESS THAN (UNIX_TIMESTAMP('20101018')),
PARTITION p20101025 VALUES LESS THAN (UNIX_TIMESTAMP('20101025')),
PARTITION p20101101 VALUES LESS THAN (UNIX_TIMESTAMP('20101101')),
PARTITION p20101108 VALUES LESS THAN (UNIX_TIMESTAMP('20101108')),
PARTITION p20101115 VALUES LESS THAN (UNIX_TIMESTAMP('20101115')),
PARTITION over VALUES LESS THAN MAXVALUE)
idはログのユニークな番号でこれについてはまた後述します。pYYYYMMDDというパーティションはYYYYMMDDまでのレコードが格納されるように設定されています。なおパーティションの細かい文法とかはMySQLのドキュメントを参考にして下さい。
一つ注意する必要があるのは、現在の仕様ではパーティションに切りたいカラム(↑ならdate)は全てのunique indexについてその一部である必要があります。そのため、action_logはidカラムだけで完全にユニークにできるのですが、敢えてPKにdateが入っています。
さて、こうしておくと例えば20101004のデータはもう不要なのでパージしたいと思ったときに、5.0時代は
delete from hoge_log where date < XXXXXXXX;
とか書いてたものを(本当はこんなの実行したら死にますが)
alter table hoge_log drop partition p20101004;
とするだけで、あたかもdrop tableするかの如く、高速にパージすることができます。データが巨大なInnoDBを触ったことがないと実感がわかないかも知れませんが、これは本当にありがたい機能です。もはやちまちまdeleteするスクリプトを書く必要もなく、スピード調整に失敗してレプリ遅延に泣かされることもなく(しかも大抵夜中＞＜！)、テーブルサイズをある程度のサイズで管理することができるようになるわけです。DBAにはヨダレものですね！
実はパーティションには他にも恩恵があります。それがプルーニング(刈り込み)と呼ばれる機能です。さっきのテーブルをselectする際に、dateの条件を与えてあげると、場合によっては見る必要のないパーティションが出てくると思いますが、それをオプティマイザが判断してくれて必要なパーティションのみ見るようになってくれます。1週間単位の集計を行いたいとか、サービスからの参照は2週間前までのみでよいとかを明示的にwhere句で与えてあげることで、より効果的にテーブルを使うことができます。
プルーニングが効いているかどうかは「explain partitions」を実行することで分かります。
mysql> explain partitions select * from hoge_log where id > XXXXX\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hoge_log
partitions: p20101004,p20101011,p20101018,p20101025,p20101101,p20101108,p20101115,over
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: *********
Extra: Using where
mysql> explain partitions select * from hoge_log where date > XXXXXXX\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hoge_log
partitions: p20101108,p20101115,over
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: **************
Extra: Using where
下のクエリではwhere句にdateを入れていて、刈り込みが効いていることが「partitions」のカラムを見ると分かりますね！
なんか通販みたいですが、パーティションにはさらにさらに特典があります。それは削除だけでなくINSERTについても性能が向上するということです。前述の様にログ系のテーブルはINSERT中心になるのでこれもおいしい恩恵ですね。RANGEパーティションによるINSERT性能の改善効果については、弊社松信の発表資料(英語ですが)も参考にしてください。http://www.mysqlconf.com/mysql2009/public/schedule/detail/6661(ここからたどれるPDFのp.44-46)
さて、ログ系のテーブルのもう一つのトピックとしては「id」をどうやって決めるか、というのがあります。素朴にやるなら、idカラムにauto_increment属性をつけてしまえば、MySQLが勝手にユニークなidをつけてくれるのでお手軽ですね。
ところが、規模が大きくなり秒間クエリ数が増大してくると困ったことになってきます。一つはMySQL 5.0以下のInnoDBを使っている場合には、弊社松信が書いているこちらのエントリにもあるように、並列性が低いという問題があります。こちらの解決の1つの方法はMySQL5.1以上のInnoDBを使うことで解決されます。
もう一つの大きな問題としては、このテーブルを2つ以上のデータベースに分割(Sharding)したくなった時です。この場合、複数データベースにまたがってユニークなidを確保するにはauto_incrementだけではちょっと面倒です。
そこでモバゲータウンではidだけを払い出すテーブルを1つ作って1レコードだけinsertして、updateにより採番し、実際のテーブルには採番したidを指定してinsertするという手段を用いています。
CREATE TABLE `seq_log` (
`id` bigint(20) unsigned NOT NULL
) ENGINE=MyISAM
INSERT INTO seq_log VALUES (0);
my $sth = $dbh->prepare_cached("update seq_log set id=LAST_INSERT_ID(id+1)");
$sth->execute();
return($dbh->{'mysql_insertid'});
Perlでユニークなidを引っ張るならこんな感じ
この方式であれば、Shardingした系統がいくつになっても常にユニークなidが採番できるため、アプリの作りもデータの持ち方もシンプルにすることができます。なお、MyISAMのテーブルロックがあるため同時並列性はないですが、現状のモバゲータウンのトラフィックであってもこの方式で特に問題は発生していません。ある程度の規模が見込まれて、Shardingすることが予想されるのであれば、こういった方式がおすすめです。
というわけでまとめ
実は、今回紹介した以外の方法でログ系のテーブルを一定程度のサイズに押さえこむテクニックもあるのですが、それはこの記事が人気が出たら書くことにしましょう＾＾
今回は以上です。列挙しといて1種類しか話しなくてすみませんすみません。また、言葉ばっかりで分かり辛く、ベンチとか正確に取ってるわけじゃないのでいい加減な話ですが、「モバゲータウンではこうやってるよ」的な話として小耳に挟んで頂ければ幸いです。
buffer poolとかInnoDBのデータ構造とか、そういう話も今回は省略してしまいました。その辺の仕組みは小難しい本を読むのが一番なのですが、忙しいあなたのために3分クッキングしたいなとかも思ってたりします。
で、なんで僕がこんなことやってるかと言うと、丁度約1年前には僕はselect文すら満足に書けない人だったんですが、1年もやればこんだけ色々できるようになるんだよー、インフラって別に怖くないよー、みんなインフラも興味持とうよー、ということが伝えたいのであります。
ではでは。
God bless your MySQL!
ところで、最近 iOS SDK Hacks という本の一部を書きました。
まぁ、マニアックな... 他の章は、もう少し即戦力っぽい内容ですのでご心配なく。
企画が持ち上がってからずいぶん経っての出版となったために、いささか情報が古いところはあるかもしれません。 とはいえ、 iOS 開発まわりの本が既に多数出ているなか、 SDK を深堀りして iOS の深淵に触れるためのテクニックが書かれているものはそうないと思います。
主著者の 吉田さん 曰く:
本書を踏み台にして，よりGeekなコードを書く足がかりにしてください。
ということで、既に開発しているアプリケーションに一工夫加えたい、もっときびきび動かしたい、といったふうに、ひとつ上のアプリケーション開発をする際の入り口になればと思います。ワンクリックでおひとつどうぞ。
]]>JavaScriptを使ってiPhone/Android用アプリケーションを構築できる、Appcelerator社の開発ツール「Titanium Mobile」の解説記事が、@ITさんに掲載されました。
Objective-C/Javaには抵抗があるけど、スマートフォンでアプリケーションを作ってみたい。そんな方は、ぜひお読みください。
今回は、拡張モジュールの使い方を紹介しています。書籍のバーコードを読み取り、AmazonへのリンクとしてTwitterにポストする「Zebratter」というアプリケーションを開発してみました。
Web技術でネイティブアプリを作れるTitanium（3）
OAuthでバーコード情報をTwitterに投稿するiPhoneアプリ作成
http://www.atmarkit.co.jp/fwcr/design/tool/titanium03/01.html
これまでの連載の一覧は、こちらでご覧頂けます。
http://www.atmarkit.co.jp/fwcr/design/index/index_titanium.html
DeNA では Perl を使っているのは周知の所ですが、先日行われた YAPC Asia 2010 にもスポンサーとして協賛し、また LT も含めてスピーカーとしても何名か参加しております。今回はそれぞれの発表について簡単に紹介し、また各スピーカーのスライドを公開しているブログエントリのまとめです。
]]>このセッションでは モバゲーオープンプラットフォーム のインフラエンジニアであるプラットフォーム統括部システムグループの久森さんが、 実際の運用上で得て来た知見を活かして特に(モバイル向け)ソーシャルゲームを作る際にどういった点に留意すべきかを解説しています。
実践的なネットワークや MySQL のチューニングの為の様々なアプローチからプラットフォームがどのようにパートナー様のアプリケーションを監視しているかを説明する資料になります。
これからソーシャルゲームに関わる方や既に作っている方、また一般的にも通用する話もありますのでウェブアプリケーションに関わるエンジニアには是非見て頂きたい内容です。
同じくプラットフォーム統括部システムグループの API 担当の xaicron (Yuji Shimada) さんは本編にて2本のセッションを行っています。
Web API のすすめでは Web API のように多くのユーザーが利用する Web Application ではシンプルかつ高速になるように、 余りフルスタックなライブラリやフレームワークを用いるのでなく、Plack や Router::Simple などといった Web Application の glue として使えるシンプルで良質な CPAN モジュールを使い、 またオブジェクトの生成を必要最小限にし、モジュールのロードだけでなくインスタンスも使い回し Copy on Write を効かせ省メモリとする上で簡単に使える薄い CPAN モジュールを紹介しています。
let's database testing!! では Test::mysqld や API の実装の際にスピンアウトして出来た Test::Fixture::DBI を使って、 データベースを利用したテストについて実際のサンプルを交えて解説しています。
DeNA ではほとんど ORM を用いず、DBI をそのまま利用していますが、その際に便利に使える薄いライブラリ (DBIx::DBHResolver, DBHx::Connector, SQL::Abstract) なども紹介しています。
この辺りは日々、改良を加えている所なので別途エンジニアブログの方でもまた紹介出来るかもしれません。
さて、こちらは自分の発表です。前半部分は Shindig (Java版) を使って OpenSocial のコンテナを作る際に何をやったら良いかについて説明しています。
次に API の実装方針について説明しています。アプリケーションのクラス階層を5段階程度に抑えてそれぞれの役割を明確にし、再利用出来る物は再利用すると言った具合で設計の話をしています。 また実装上どんなモジュールをどういう用途で使っているかも説明しています。特にこちらも弊社エンジニアの有澤さんが作った DBIx::DBHResolver は API の歴史とともに機能強化しており、 特に Sharding された環境でスムースに移行出来るような作りになっている事も解説しています。
また API では MySQL Partitionig や Trigger などを多用していますが実際の使い方や、変わった使い方なども合わせて紹介しています。
最後に Q4M の分散の仕方についてトラブルを含め実例を交えて解説しました。
先日のDeNA Technology Seminar #2でお話させていただきました HandlerSocket Plugin for MySQL のソースコードを公開しました。
]]> HandlerSocketとは？簡単に言うと、MySQLデータベースへのアクセスを高速化するためのプラグインです。MySQLのSQLパーザをすっ飛ばし、ネットワーク通信とマルチスレッド処理周辺を置き換えることによって、InnoDB等のデータベースエンジンの性能を限界まで引き出します。
このHandlerSocketですが、すでにモバゲータウンにて実際に運用しています。従来MySQLとmemcachedの構成で運用していた箇所を、HanderSocketを組み込んだMySQLだけの構成に置き換えました。その結果、MySQLサーバの負荷軽減、memcachedの負荷軽減、ネットワークトラフィック減少の効果がありました。また、単純にHandlerSocketに置き換えたことだけによる効果というわけではないのですが、アプリケーションのCPU負荷も大幅に減少しています。
興味のあるかたはソースコードを覗いてみてください。なお、DeNA Technology Seminar #2でのプレゼン資料はこちらです。
株式会社ディー・エヌ・エー（以下、「当社」といいます）は、本ソフトウェアの不稼動、稼動不良を含む瑕疵担保責任、その他本ソフトウェアに関する一切の責任について、当社の過失の有無やその程度に関わらず、ユーザ及び第三者に対して負わないものとします。また、当社は、本ソフトウェアの商品性、有用性、完全性、正確性、確実性、またはユーザもしくは第三者の特定の目的に対する適合性について、いかなる保証も行うものではないものとします。
同意いただける場合はこちらから取得してください。
]]>で、せっかく社内に3Dのデータが沢山あるんだし携帯以外のプラットフォームでも絵を出せないかなということで、最近WebGLでのレンダリングをやってみたので、そのお話でもしてみようかと思います。
WebGLというのは、細かい話は放っておいて超大雑把に言うと、ウェブブラウザで3Dの絵を出せるようにする規格です。今までも、Flash他のプラグインをインストールすることで一部のサイトでは3Dのコンテンツを見ることができました。けど、プラグインとか無しでも3Dコンテンツを楽しめるように標準化していきましょうよ、というのがWebGLです。HTML5を御存知の方なら、Canvas要素で3Dの描画ができるようになりますよ、と言えば分かりやすいでしょうか？
そのWebGLですが、次のような特徴があります。
・図形のデータは保持されないので、手続き的に絵を描く
・描けるものは基本的に三角形だけ
・絵を描く手続きには、JavaScriptを使う
・APIは、OpenGL ES 2.0をJavaScript向けにアレンジしたもの
・まだ使えない
以下、一つずつ解説していきたいと思います。
DOMみたいな、図形や見た目を保持するデータ構造のような仕組みはWebGLにはありません。どのように絵を描くかを、自分でプログラムしないといけません。もともとCanvas要素がそんな感じみたいですから（すみませんCanvas要素をWebGL以外で利用したことが無いので、実はよく知りません・・・）その点では従来のCanvasと利用法が似てるといえば似てるかと思います（APIは全然違いますけど）。複雑なシーンの構造を保持する必要がある場合は、そのためのデータ構造とそれを扱うプログラムを、自分で作らないといけません。
このような、手続きで絵を描いていく方式は、初心者にとっては利用するためのハードルがちょっと高いかもしれません。でもその分柔軟で、用意されたデータ構造に縛られない、自由な絵を描けるという利点があります。ハードルが高いという問題は、親切な誰かさんがきっと作ってくれるであろうライブラリを利用することで緩和することもできます。
Canvas(2D)には円や2次3次のベジエ曲線を描画する機能があるみたいですが、WebGLは三角形だけです（他に一応、点と直線も描けます）。描けるのは三角形だけなんですが、その三角形に色々なバリエーションを作ることができます。色を付けたり、テクスチャを付けたり、陰影を付けたり。まぁそうは言っても結局は三角形なのですが。
曲線や曲面は描画できないので、円とか球とかを描画したい場合は、カクカクに見えない程度まで細かく三角形に分割してやる必要があります。不便といえば不便なんですが、3Dグラフィックスハードウェアの都合でそうなってますので我慢してください。皆さんがお持ちの全てのゲーム機にも同じ制限があります。でもどのゲームも綺麗なグラフィックスを出せてるわけで、要は工夫と努力でなんとかなるってことです。
Web系な皆さんには、JavaScriptでのプログラミングはお馴染みですね。多分。リアルタイム3Dグラフィックス系の方からWebGLに入ってくる人には、JavaScriptって遅いんじゃないの大丈夫なの？と思われるかもしれません。
正直なところ、全然大丈夫じゃないくらい激遅いですJavaScript。覚悟が必要なレベル。
ただWebGL自体は特に遅いわけではないので、JavaScriptはGLコマンドを発行するだけ、みたいに使えば大丈夫です。GPUでできる部分はなるべくGPUにまかせてCPUにはできるだけ仕事をさせない、という基本は、普通にC言語などからOpenGLを使う場合と同じです。その傾向がちょっと極端になった感じだと思えば良いと思います。
とはいえ、OpenGLにはベクトルや行列の計算をおこなうようなAPIが無いので、その辺はJavaScriptで実装してやる必要があります。ベクトルや行列を大量に使うようなプログラムは、結構キツいです。
OpenGLというのは3Dの絵を描くためのAPIの一つなのですが、WebGLはそのなかの、OpenGL ES 2.0というバージョンを元に作られています。OpenGLは歴史が長いこともあって沢山のバージョンがあります。OpenGLを御存知でない方のためにスーパー適当な説明をしますと、以下のような感じになります。
OpenGL 1.0 － 基本的な描画機能だけの元祖OpenGL
↓
OpenGL 1.1～1.5 － OpenGL1.0にどんどん機能を追加していった
↓ → 派生
↓ OpenGL ES 1.0 － OpenGL 1.3 から要らない機能をバッサリ切り落とした
↓ ↓
↓ OpenGL ES 1.1 － 切り落とし過ぎちゃったので機能を追加した
↓
OpenGL 2.0 － OpenGL1.xに「プログラマブルシェーダ」を追加したもの
↓ → 派生
↓ OpenGL ES 2.0 － OpenGL 2.0 から要らない機能をバッサリ切り落とした ←WebGLこれ！
↓
OpenGL 3.x, 4.x, ...
WebGL仕様の元になっているのはOpenGL ES 2.0です。ESというのは for Embedded Systems の略で、メモリや演算能力の足りない組み込み用途向けに、必要最小限に絞った仕様になっています。詳細については、以下のリンクを参考にしてください。
OpenGL ES → http://www.khronos.org/opengles/
WebGL → http://www.khronos.org/webgl/
OpenGLを御存知の方にOpenGL 2.0 ESを簡単に説明すると、
式①― OpenGL ES 2.0 ＝ OpenGL 2.0 － 不必要な機能
式②― OpenGL 2.0 ＝ OpenGL 1.x ＋ プログラマブルシェーダ ＋ VBO他各種オブジェクト
式③― 不必要な機能 ＝ OpenGL 1.x
式①②③より、 OpenGL ES 2.0 ＝ プログラマブルシェーダ ＋ VBO他各種オブジェクト
といった感じになります。OpenGL 1.xが残ってませんが、はい、残ってません。残念ですが固定パイプラインに関する機能はあらかた切り落とされてます。強制的にプログラマブルシェーダ＆各種オブジェクトです。シェーダから組み込みのアトリビュートやステートを参照することもできないです。glTranslatef他、行列系のコマンドすらありません。自前でやることが増えて、けっこう面倒臭いです。
ここまで書いておいて今更ですが、まだ(正式には)WebGLを使えるブラウザがありません。ので、普通の人はWebGLのコンテンツがあっても表示できません。なんだそれ！
・・・ですが今年中のリリースができるよう、Webkitのnightly buildやMinefieldでのWebGL実装の開発は進んでいます。WebGLを試してみたい人はそれらのブラウザをダウンロード（＆ビルド）する必要があります。当然、正式版ではないのでセキュリティの問題なんかもあるかもしれません。それでも人柱erの精神で試してみたい人は、以下の手順でMinefieldを導入してみるのが良いと思います。ビルド済みの実行ファイルがあるので簡単です。
１．Minefieldをダウンロード → http://nightly.mozilla.org/
２．WebGLを有効化する
1)Minefieldを立ち上げる
2)アドレスバーに about:config と入力する
3)"webgl.enabledforall_sites"の項目をtrueにする
３．WebGLコンテンツを見てみる
→ ここのリンク集とか http://learningwebgl.com/blog/?p=1949
→ あるいは 「webgl sample」でぐぐるとか
（8/4追記）
Macでは、この記事の下の方にあるデモをMinefieldで実行するとOSごと落ちてしまう場合があるようです。以下のWebKitの方を使用することをお勧めします。
１．WebKitをダウンロード → http://nightly.webkit.org/
２．ターミナルで次のコマンドを実行（WebGLを有効化する）
defaults write com.apple.Safari WebKitWebGLEnabled -bool YES
３．WebKitを起動する
あと大切なことですが、WebGLは、ブラウザだけでは動きません。グラフィックスハードウェアが、「プログラマブルシェーダ」という機能を持っている必要があります。nVIDIAやATi(AMD)の最近のグラフィックスカードを装備しているPCなら大抵は動きますが、Intelだとかのチップセット組み込みグラフィックスだと動かない可能性が高いです。
まだ結構、不安定だったり、明らかなバグもあったりしますね。今のところMinefieldでしか試していないんですが、長時間WebGLを動かした後にページをリロードすると、WebGLのコンテキストが作成できなくなったりします。ブラウザを再起動すれば直りますが。（と思ってたのですが最近のバージョンでは安定度増してるっぽい？） あと、Minefieldでは、glDepthMaskをいじるとおかしくなるみたいです。単に効果が出ないだけなら大きな問題も無い（？）のですが、後になって表示が崩れたりといった、よく分からない影響が出たりします。（と思ってたのですがこれもいつのまにか直ってた？） 他にも、ある時期からgetUniformLocation()の返り値がintから変更されてたり、Intel系のGPUではフラグメントシェーダ内でgl_FrontFacingが使えなかったり。Intelの方は、WebGL関係無いかもしれませんけど。
で、まぁ色々と地雷を踏みつつも、WebGLでモーションアバタのデータをレンダリングするところまではできたので、それをテキトーにDeNAのトップページと重ねてみました。↓がそのサンプルです。
http://engineer.dena.jp/webgl/sample01/avatar.html
注意！
●上のリンクを見るには、WebGLが動くブラウザが必要です。（WebGLが動かない環境の方はごめんなさい。）
●場合によっては、OSごと固まる可能性もあります。作業中のファイルは保存して、覚悟を決めてから見てください。
左上の方で動いているアバタの周囲512ピクセルが、マウスで操作できる範囲になっています。以下、簡単な操作説明です。
マウスドラッグ： 回転
Shift+ドラッグ： 移動
Ctrl+ドラッグ： 奥行き方向の移動
Shift+Ctrl+ドラッグ： 光源の方向を変える
a： アニメーションon/off
s： 影のon/off
d/D： 陰を濃く/薄く
f/F： 影を濃く/薄く
g/G： 影を柔らかく/くっきりさせる
（8/4追記）
Macでは、Ctrl+クリックで右クリック相当になってしまうことを忘れていました。Ctrlを使わなくて済むよう、以下の操作を追加しました。
z + ドラッグ： 奥行き方向の移動
x + ドラッグ： 光源の方向を変える
こういうデモを作るとすぐ下から覗きこもうとする人がいますけど、ダメですよそういうことしちゃ。えっちなのはいけないと思います！
ちなみにこのデモで使われている3Dデータは、モバゲータウンの「モーションアバタ」サービスで使われているものと全く同一のものです。モバゲータウンの方でこれを表示すると、下のような絵になります。
WebGLが一般化すると、こんな感じで、Webページの上で動きまわる3Dの絵が見られるようになるかもしれません。JavaScriptが流行り始めた頃みたいに、WebGL使い過ぎで超見辛いページが一時的には氾濫しそうな気もしますが、多分そのうちJavaScriptと同じように落ち着いていくのではないかと思います。節度を持ってうまく使えば超coolなページを作れる（かもしれない）WebGLに、皆さんも注目してみませんか。
]]>まず ATND ですが、若干キャンセルが出ております。 ひょっとしたらキャンセル待ちで繰り上がっている場合がありますので今一度チェックしてみて下さい。
次に明日の各種情報です。
当日、残念ながら会場にお越し頂けない方も ust 中継にてお楽しみ下さい。また会場では無線LAN環境を提供致しますのでノートPC等お持ち込み頂き、是非実況中継して下さい。その際にはハッシュタグもお忘れなくお願い致します。
DB Magazine 8月号に DeNA の技術陣による「モバゲータウン」構築/運用のすべてと言う特集記事が掲載されております。
本特集では、モバゲータウンに数多くあるコンテンツとそれらがどのように作られているかと言う概説、今年1月から始まったモバゲーオープンプラットフォームの内側と、AdminTool と言う数千台のサーバーを管理する為の自社ツール及び、監視のノウハウについて解説しております。書店で見かけたら是非、手に取ってご購入頂けると幸いです。
それでは皆様、明日の DeNA Technology Seminar #2 でお会いしましょう。セミナー終了後はちょっとした懇親会もご用意しておりますので、是非ご参加下さい。宜しくお願い致します。