今週、12/5(水)に研究会合同説明会があります
増井研も参加します
SFC全ての研究会がまとめて説明してくれるイベントで、18:30からオメガ館で開始です
20時までやってる。
1分プレゼン用のスライドを作った。
Web公開制限が無いらしいので、殴り書いたメモを貼り付けておく。
謎のアルゴリズムで集められたはてなユーザーに、モバゲーの運用技術を惜しげもなく教える勉強会に行ってきた。
インフラもPerlも全然わかんないんだけど何故誘われたのか謎。
モバゲーすごい・・・台風激しかったけど行ってきて良かった。特にモニタリング手法が面白くて、一瞬だけ全プロセスにデバッガをアタッチして待機状態のプロセス数を調べるとか、DBバックアップサーバーの遅延を監視してるとSlaveへの遅延発生が予測できるとか。頭いい。
たぶんMobageを支える技術に書いてある内容の一部だと思われるので、本も買ってみる。
あと社食で閉店前に「モバゲ〜」って歌が流れててわかめ高校みたいで面白かった。
2012年6月19日 @ DeNA
- 渋谷ヒカリエの21階
- 台風きてるからヤバかったらすぐ帰りましょう
インフラ部門紹介(小野氏)
- 世界展開
- mobage(アメリカ)
- mobage(日本)
- Daum mobage(韓国)
- mobage なんとか宝谷(中国)(読めない)
- Rackspace、AmazonEC2を使用
- インフラも運用だけじゃなく開発する
- Handler socket plugin
- MySQL-MHA
- 非富豪的感覚
- 古株が多いのでこだわる
- サーバー台数少ない
- G社の半分ぐらい
運用技術 Web編(樋口氏)
- ケチなのでサーバー台数少ない
- webサーバーの資源管理
- FastCGI
- デバッガ
- 障害調査
- 全体構成
- 基本的にLAMP
- FW/LB
- Webサーバ・DBに大別
- Apache+FastCGI
- 一枚岩アプリ
- ゲーム・掲示板・コミュニティ全て同じアプリとして動作
- ゲームごとに別ではない
- メリット
- ゲーム間の連携が容易
- サードパーティのOpenPlatform使ったゲームはMobageと呼んでない
- Webサーバ機はCPUやメモリがネック
- Mobageの全機能をloadするとメモリ1GB使う
- 全pmファイル読むだけで1GB
- メモリ使用量を抑えてワーカープロセス数を増やしたい
- 工夫する
- サーバー1台あたり100プロセスぐらい動いている
- FastCGIワーカー数
- IO待ちでsleepしているのでCPU数の2,3倍起動する
- プロセス数が多いほど耐障害性高い
- バックエンドDBが詰まった時に影響が少なくなるので
- ワーカープロセス数の空きを調べる
- あと何%空いてるか?
- 走っているプロセスにデバッガをアタッチ、スタックトレース取ってすぐデタッチ
- リクエスト受付状態にあるプロセス数を数えればわかる
- bulkdbg
- 複数プロセスのスタックトレースを高速に取得
- gdbより速い
- シンボル解決のタイミングがgdbと違うらしい
- 複数プロセスなのでライブラリ同じ、無駄なので読まない
- 5秒ごとに実行している
- オーバーヘッドほとんど無い
- gdbperl.pl
- Perlのスタックトレースをとる
- 内部でgdbを使ってPerlインタプリタの内部変数を読む
- どっちも実サービスで使っている
- 問題起きたこと無し
- 障害調査の手法
- gdbperl.plをアタッチ
- straceをアタッチ
- bulkdbgでモニタリング
- NYTProfでプロファイルデータ取得
- DBのログ
- メモリ利用効率化
- メモリに全部読むと1GB
- 特定のゲームだけならそんなに行かない
- サーバをグループにわける
- Perlモジュールプリロード
- OSページキャッシュ
- 昔のMobage
- ワーカーをforkさせておく、それぞれPerlをexec、モジュール読み込みリクエスト処理
- 最近のMobage
- fork前にモジュール読み込む、その後ワーカーをfork
- メモリ節約できる
- Linuxだと、forkしたプロセスのメモリ領域は書き込まない限り同じ場所を参照する
- 慎重に移行した
- socketを開いた状態でforkすると問題が起こる事がある
- 移行後、メモリ使用量半分になった
- ページキャッシュの効率化
- アプリのログがキャッシュされる
- swapする
- posix_fadvise(POSIX_FADV_DONTNEED)
- ファイルをページキャッシュに載せなくする
- 10秒ごとにログファイルをページキャッシュから追い出す
運用技術 DB編(岩永氏)
- サーバー多い
- データでかい
- トラフィック多い
- DB
- Master/Slaveレプリケーション
- 更新系クエリはMasterに
- それ以外はSlaveへ
- Masterへの書き込みがSlaveに即コピーされるわけではない
- 課金系とかはMasterへ
- 最初
- 1データベースに全テーブル入れてた
- 即あふれた
- テーブル分割
- JOIN基本的に使わない方針
- レコード単位のsharding
- 分散方法
- consistent hashingみたいにクライアントサイドで参照先を計算
- mapping table
- 参照先が別のところに書いてある
- mapping tableの方が最近はよく使っている
- consistent hashingだと2→4→8→16..としか増やせないから無駄が多い
- map先はmemcachedやアプリ内にキャッシュしておく
- 両方使っている
- 全shardを見ないとならないような機能は、基本的にゲームに付けないようにしてもらう
- auto increment
- MyISAMのDBを使う
- SELECT LAST_INSERT_ID()
- scale back
- スケールアウトの逆
- DBをわけちゃったのを集約したい
- 1台でmysqldを複数起動
- 1台に仮想IPを複数ふる
- my.cnfのbind-addressでmysqld複数に振り分ける
- アプリ側からは今までどおり、複数台のサーバーに分散されているように見える
- バックアップ
- サービスに入っていないslaveがいる
- Master障害時にMasterになる
- 朝3時にmysqldumpで論理バックアップ
- バックアップがあると、slaveの追加が容易
- MHA
- MySQL Master High Availability
- バックアップ等の自動化ツール
- Masterのスキーマの更新にも使える
- 先にSlaveのスキーマ更新しておいて、最後にMHAでMasterを切り替えるらしい
- Purge
- MySQL5.1以前
- DELETE使うしかない
- 5.1以降
- パーティショニングが使える
- droptable並の速度で消える
- RANGEパーティションで日付で消せる
- トラフィック多い
- indexはった順番を意識してSQL書け
- 全スキャンしないでほしい
- ほとんどはプライマリキーで読むことが多い
- Handler Socket Pluginを使う
- Memcachedよりも速いというベンチマークもある
- 元々はMemcachedでやってた
- MySQLとMemcachedのデータの一貫性を確保するのが面倒だった
- Handler Socketに一本化
- updateクエリが多い時
- SINが落ちる
- デッドロック
- DB lockすると他リクエストが困る
- まず先にアプリからDBにつないで、lockする時間を最小限にするようにコード書く
- デッドロックしないようにクエリの順番を工夫する
- 楽観的ロック
- モニタリング
- バックアップサーバーの遅延を見る
- 近いうちにSlaveにも遅延が来る、と予想できる
- 先読みしてチューニングする
- SSD使う
- HDDだと間に合わない時はSSD
- PCI ExpressのSSDは速いけど高い、まだあまりつかってない
- SATA SSDを使っている
イエーイ
GoldFish
畑山さんがキャプチャしてくれた授賞式のようす
GoldFishという、Android NFCとJavaScriptで実世界GUIを作れるフレームワークを作っています。
- 橋本商会 » Interface(雑誌)に記事を書いた
- 橋本商会 » ORF2011で実世界コピペ、実世界ユーザインタフェース等を展示した
- 橋本商会 » AndroidとNFCで研究室の鍵を開けるシステムができた
- AndroidでNFCタグに触るとアプリが起動する
- アプリはJavaScriptで書く
- JSだけどAndroidの各種センサー使える(ネイティブとのブリッジがある)
- アプリはタグタッチ時にロードされるので、Marketでインストールしてない人もすぐ使える
最近よく作っているPhidgetsやプリンタや赤外線リモコンやシリアルポートやNFCタグリーダやらをHTTPサーバ化するのも、GoldFishの部品的な位置づけです。
目の前にある物を操作するなら直接操作でできるべきだし、そのためには物理的に存在する全てがHTTPでアクセスできた方がいい。
当日使ったスライド(pdf)
どうやらslide shareが容量のリミットに達したらしくアップロードできない・・
最近作ったものを、去年の先月ニコニコ学会で発表した。緊張した。
http://live.nicovideo.jp/watch/lv72478844#6:27:05
スライドはこれ。動画がけっこう使われているので↑のニコ生から見たほうが良い。
あとSFC-LTで増井研について発表した。はじめてLTというものをした。がんばった。
すごいウケてたんだけど、動画がなかなか公開されないので俺が「すごいウケてた」って研究室で言うたびにハイハイみたいな目で見られるので早く公開してほしい。
http://www.ustream.tv/channel/sfc-lt
来週16日(火)に、日吉でシンポジウムがあります。事前予約の受付がはじまりました
本人そっくりのロボットの石黒先生や、Leading Edge Designの山中俊治先生が来ます。参加費無料。
以下リリース文引用
2010年2月16日、「ユビキタスコンテンツ製作支援システムの研究」は、神奈川県横浜市港北区日吉・藤原記念ホールにて、「ユビキタスコンテンツシンポジウム2010」を開催致します。
本プロジェクトは、JSTの戦略的創造研究推進事業CRESTによって支援を受けたプロジェクトで、平成16年度から5年間の研究プロジェクトとして「ユビキタスコンテンツ」という新しいコンテンツジャンルを提案し、基盤技術開発、デザイン理論構築、コンテンツ制作の3軸から研究を実施してまいりました。
ユビキタスコンテンツは、私たちの衣食住遊に新たな経験と感動をもたらすコンテンツです。それらはモノや環境に溶け込み、ヒトや状況によってダイミックに変化します。また、ネットワークと接続されることにより各々のコンテンツのユーザ経験が蓄積され、蓄積されたデータをもとにコンテンツ同士の連動が可能となります。
このようなユビキタスコンテンツを制作するためのプラットフォームとしてわれわれが開発したxtelは、近距離無線通信が可能な小型基板moxa、 MCUボードのためのprogramming・runtime環境Talktic、動画、音声などの連続情報を扱うことが可能なP2Pネットワークライブラリ EntityCollaborator、コンテンツ経験の連動と蓄積を可能にするwebサービスLifeの4つのツールで構成されています。
さらに、本プロジェクトの成果であるユビキタスコンテンツのためのデザイン理論は、デザイン思考とティンカリングと呼ばれるプロセスを通して、効率よく良質なユビキタスコンテンツを創出することを支援します。このデザイン理論は、xtelの開発環境にも生かされており、デザイン思考とティンカリングを実行しやすくなるように、xtelの開発環境が設計・構築されています。
本プロジェクトを締めくくる今回のシンポジウムでは、ロボット研究者の石黒 浩 大阪大学大学院教授、プロダクトデザイナーの山中 俊治 慶應義塾大学環境情報学部教授をゲストスピーカとしてお招きし、トークセッションを行います。また、シンポジウムでは、5年間の活動内容をまとめた書籍「xtel: 生活を豊かにするインタラクションデザイン」をお配りする予定です。
日時・場所:
2010年2月16日(火) 10:30-15:30 (開場 10:00)
慶應義塾大学日吉キャンパス 藤原記念ホール
プログラム:
10:30 – 10:40 代表挨拶
10:40 – 12:10 「親しみのデザイン」
石黒 浩 大阪大学大学院 基礎工学研究科 教授
奥出 直人 慶應義塾大学 メディアデザイン研究科 教授
12:10 – 13:30 休憩
13:30 – 15:00 「美しさのデザイン」
山中 俊治 慶應義塾大学 環境情報学部 教授
稲蔭 正彦 慶應義塾大学 メディアデザイン研究科 教授
15:00 閉会挨拶
事前登録方法:
シンポジウムへのご来場をお考えの方は、
・お名前
・所属
・電話番号
・メールアドレス
を添えて、office [at] dlb.sfc.keio.ac.jpまでメールをお送りください。
なおシンポジウムの詳細は随時 webにてご連絡差し上げます。
http://xtel.sfc.keio.ac.jp/
本件に関するお問い合わせ先
〒223-8526 神奈川県横浜市港北区日吉4-1-1
慶應義塾大学日吉キャンパス 協生館C6S04
CREST ユビキタスコンテンツプロジェクト
Tel. 045-564-2483
Fax. 045-564-2540
E-mail: office [at] dlb.sfc.keio.ac.jp