笠原社長退任にみる、ミクシィの苦悩〜相次ぐ身売り話と人材離脱、ライバルの台頭… | ビジネスジャーナル そして11年11月、ミクシィは事業方針を大きく転換した。SNS上にミクシィゲームを新設してソーシャルゲームに進出。ビジネスモデルを広告モデルから課金モデルに変更した。しかし、ソーシャルゲームに出遅れたことが響き、グリーやDeNAとの業績の格差は広がった。 とあるんだけど、「いや、2010年春に mixi 向けに会社でソーシャルゲーム*1作ってた記憶あるぞオイ…」と思って調べてみたら、「mixiアプリ」からゲーム部分だけを切り取った「mixiゲーム」というサービスが2011年にできていたらしい。 なので「それ以前から mixi は課金モデルのソーシャルプラットフォームを持っていたけど、更にそっち方面へ舵を切ったのが2011年11月」というのが正しい（はず）。 もっと言うと、ソーシャルプラッ

2013年2月15日をもちまして、株式会社ユードーを退職いたしました。 2011年4月に入社し、2年弱勤務させて頂きました。 「そもそもお前はどういう仕事をやってたの？」と思う方もいらっしゃると思いますので、簡単に説明しますと、スマートフォン（iOS、Android向け）アプリのサーバーサイドの開発を全般的にやってました。 たとえば、「斉藤さん」というアプリでは最大2000万弱/日、350アクセス/秒というAPIアクセスをフロント・DBサーバー（スペックもそこまで高くないやつ）それぞれ一台で捌くという結構無茶なことをやったりしてました。 また、最後のプロダクトとなった「プチリッチ」というアプリでは初めてRubyに挑戦してみたり、なんだかよくわからないうちにAPI連携のためにソケットプログラミングとかしてみたりして、思いの外複雑なシステムを作り上げちゃったりもしました。 あと、前述の「斉藤さ

「全部で100万件とか1000万件とかあるような、でっかいテーブル内のデータを全部持ってきて特定の処理を加えた後にどっかに入れる」というような処理をしたいときに注意すること。 通常はLIMITを使ってオフセット/リミットで絞ってちょっとずつやる、みたいなことをやると思いますが*1、これ実はBETWEENしてやるほうがずっと速いです。 -- こっちよりも SELECT id,name,data FROM table_name ORDER BY id ASC LIMIT 100000,1000 SELECT id,name,data FROM table_name ORDER BY id ASC LIMIT 101000,1000 SELECT id,name,data FROM table_name ORDER BY id ASC LIMIT 102000,1000 SELECT id,na

プランが一新され、今借りてるメモリ1.5Gのプランと同じ値段でCPU3コア、メモリ2Gが借りられるということで移行することにした。 その際に、イチから構築したのでその備忘録。 注意 自己流。 とりあえずログイン VPSの作成が終わるとさくらからメールが来るので、所定のIPおよびアカウント情報を用いてssh接続する。 アカウント周り&SSH周りを変更 rootで弄り続けるのは危ない（と言われている）ので、普段使い用のアカウントを作り、sudo経由で弄れるようにする。 併せて、ssh経由でのrootログインを禁止し、パスフレーズでのsshログインも禁止する。 ユーザー追加 # useradd -g users pull # passwd pull # visudo >> 以下の部分を変更。 ## Allow root to run any commands anywhere root ALL=

事の始まり 3月に入ってから「斉藤さん」のWebサーバーのピークタイムでのアクセス数が秒間180アクセスを境に動かなくなり、しまいには一部アクセスが固まって動かなくなるという現象が発生した。 Apacheのエラーログを見ると、データベースサーバーに接続できていない旨が出ていたため、その辺を念頭に置いていろいろと探ってみたのだが・・・。 ソケット数の限界？ 「netstat -ant」と打つと、その時点でのTCPコネクションの一覧が出る。 ピーク時にWebサーバー側は30000前後、DBサーバー側は8000前後。 HandlerSocketのポート（標準では9998と9999）に絞ってみてみると、Webサーバー側は8000前後なのに対し、DBサーバー側は500前後。 明らかにWebサーバーのコネクション数がおかしい。 MySQLのコネクション数は問題なさそうなので、HandlerSocket

考察 同時アクセス数が大きくなると（感覚では秒間150〜160前後）後ろが詰まってアクセスを取りこぼすことがある。下のグラフの0時前後（23時ちょうどと0時過ぎくらい）に注目。グラフが途切れている部分はアクセスが集中し、munin-nodeがステータスページへアクセスしても結果がうまくとってこれなくなっている（という個人的な解釈ですが・・・）。 Apacheでも同様なことがあったものの、（同スペックのサーバー環境下でも）もうちょっと耐えていたはず*1。 あと、Apacheの時に比べてアクセスが集中し始めると途端にloadtimeが長くなりがちになることもちょっと気になる。 メモリ消費はキャッシュが一定量づつたまっていく。実用上問題はなさそうだが、なんとなく気持ち悪い増え方。 PHP-FPMをバカみたいに起動しているせい*2か、メモリのコミット量が半端じゃない。 今後もアクセスが増加していっ

こんにちは。 今回はいよいよ「テガキモンスター」のサーバーサイド（特にDB周り）についてお話しします。 使ってるもの Webサーバ Apache（2.2） PHP（5.3）+APC Memcached MessagePack DBサーバー MySQL（5.5）+HandlerSocket TokyoTyrant 比較的よくあるソーシャルゲームのサーバー構成だと思います。 バージョンはなるべく現段階で出ている安定版の最新のものを選びました。特に、PHPに関してはNamespace（名前空間）などの5.3から入った仕様もバリバリ使っています。 ちなみに余談ですが、弊社の「POMPA」や「斉藤さん」というiPhoneアプリのサーバーサイドも実はほぼ同じ構成*1になっております。 MessagePack このMessagePackというのは、高速・小サイズのシリアライズ形式のことです。 今後、機能