ソーシャルゲーム開発の高負荷対策

http://ke-tai.org/blog/2011/01/28/snsgamesslidematome/
ここのスライドの内容から負荷対策に関して少しまとめてみた。

LAMP環境を想定
+memcachedとか

・DBへの接続切断は明示的に行う

・更新系、参照系でDBを分ける
但し、レプリケーション遅延なんて発生して当たり前。重要な参照は結局更新系から取得。

・KVSを利用する（ログイン時間管理とか結構どうでもいいような情報の負荷が糞高かったりするのに丁度いいらしい）

・キャッシュサーバーを効率的に利用する（使える所は使いまくれ。特に時間のかかるAPIのレスポンスなんか最適）

・Apache,MySQLのチューニングは必須（とにかくボトルネックとなりうる所は全てカリカリにするのだ）

・必ず負荷テスト及び過負荷テストを行う（公開3ヶ月後のユーザーデータを予測してDBに突っ込んでみる。もち本番環境で）

・ツールは大事。テストするにも監視するにも開発するにも。

・会員数数万程度を見越して作ったPGはNG

・スロースタートなんてありえない。最初から全力。でなきゃ、ずっと上には上がらない。

・WebサーバーやスレーブDBサーバーの複数台構成は当たり前。

・マスターDBの分散は難しいよねー。出来ない事無いけどとりあえずはスペックアップで耐える。
でも、最悪分散化する時の為に、テーブル構成は最初から分散を意識して構築

・レスポンスに5秒掛かった時点でアウト！プラットフォームから強制メンテモード突入のお知らせが

・サイト落ちた瞬間にユーザーは次のアプリへGo!二度と戻ってきません。

・DBの正規化はする。だけど場合によっては冗長化する。それが高負荷クオリティ。

・不要なカラムは持たない。どこかで使うかも～なんて設計の段階でちゃんと詰めとけ。

・保持するデータ量は最小限にする。（1日10GB単位でデータが増加するなんて普通という世界）

・期限が過ぎて必要なくなったデータは、さっさと削除
そして削除時のコストも考えておく（1000万レコード削除とか普通）

・インデックスは超重要！でも張りすぎたら超危険。

・LIKE検索とか馬鹿！っていうレベル

・SLOW QUERYは毎日チェック。即修正

・DBの負荷管理をどのように行うか考えておく。危険水域突破からの対策案も併せて

・トランザクションを開始したら、如何に早くコミット出来るかを考え抜く
トランザクション中に外部API呼ぶとか自殺行為

・APC(Alternative PHP cache)を利用する。むしろ使わないと馬鹿

・負荷対策は終わりなき戦い

・ユーザー数2000万超のプラットフォーム舐めんな

結構あったな。
もちろん、スライドショー内で全く言ってない事もチラホラ。
まぁそこは心の声という事で。

いやぁしかしほんとにネットワークエンジニアは尊敬するわ。
数十万の会員でもヒイヒイいうのに、facebookのネットワークエンジニアとかどうなってんだろ？

Read More

携帯コミュニティ事情

日本の３大コミュニティといえば、やっぱりmixi,モバゲー,GREEですが、
今まで色々と槍玉に挙げられてきました。

コミュニティといえば、人と人が出会う所。
人と人が出会えばそこにはいろんな軋轢が生じるのが世の常。
別に大人同士でイザコザが発生する分にはほっとけばいいんですが、
子供が絡むとそうもいきませんからね。

いい大人が年端もいかない子供相手に何してんだってなもんですが、
倫理観に訴えた所で、無くなるわけもなく。。

そこで出てきたのが携帯会社からの情報公開。
現在は携帯の契約での本人確認は厳しくなっており、その際には
勿論生年月日などの情報を記入する事になります。

今回の情報公開というのはSNS側に対してキャリア側から
未成年かどうかの情報を判断するAPIを提供するというもの。
（実際は指定年齢以上か未満かを返す）
これは、あくまでフィルター的な役割をするもので
誕生日などの情報は渡されません。

これによって、子供のふりして紛れ込むような輩を排除できるでしょう。
今はauのみですが、今後docomoやSoftBankも続くのは確実で、
コミュニティサイトが必要以上に悪とみなされる事も少なくなるかも。
（まぁ、いまだに無料！って謳ってるのはどうなのかなぁとか思いますが。）

非常に便利で、今となっては無くてはならないインターネット。
大金持ちを生んだり、自由主義を呼び込んだり、
たまには革命を起こしたりとしておりますが、
これからも、良いニュース悪いニュース出てくるでしょうね。

良いニュースが少しでも増やせるよう
私も力になれればいーなーと思います。

Read More