KLabGames Tech Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。 スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。 このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。

こんにちは、oho-sです。どうにか今回も新刊を出すことができました。

前回の技術書典3技術書典4に続き、技術書典5でもKLabの有志で技術同人誌を頒布します。

KLab株式会社サークル詳細

今回から技術書典の会場が池袋サンシャインシティになります。詳細は技術書典5のサイトをご確認ください。 なお、KLabブースは、「か49」です。

新刊 KLab Tech Book Vol.3 では、以下の内容を収録しています。

  • プロシージャルモデリングを支えるHoudiniの機能紹介
  • 2.5万円で買える3Dプリンタのススメ
  • Airtestを用いたUnityアプリの自動実機テスト
  • Rider+UnityでRoslyn Analyzersを使う
  • バーコードリーダーになろう
  • Unity Timeline Tips集
  • 物理ベースレンダラーをRust実装して、ちょっと高速化した話
  • ヘッドレスChromeでリボ払いを回避している話

KLab Tech Book Vol.3

また、Vol.2も少数部再販いたします。 数が少ないので、Vol.2の物理版が欲しい方はお早めにどうぞ。

どちらも物理版は500円、電子版は無料で以下のリンクからダウンロードしていただけます。

皆様のご来場をお待ちしております。

ダウンロードリンク

これまでのKLab Tech Bookと、新刊Vol.3のダウンロードリンクを以下に掲載します。

※Vol.3については、当日有効になります。

@hasi_t です。 http://klabgames.tech.blog.jp.klab.com/archives/1072352628.html の続きです。

hasi_tがやったことの時系列

  • 10:00-11:30 問題を把握する
  • 11:30-12:30 nginxをインストールする
  • 12:30-13:00 昼食
  • 13:00-14:40 getEventsとgetEventを修正する : getEventsからgetEventを呼ばないようにし、SELECT * FROM sheetsを1回にし、SELECT * FROM reservationsのN+1問題を対処
  • 14:40-15:30 /admin/api/reports/sales, /admin/api/reports/events/:id/sales修正 : order by reserved_at asc を削り、数値比較でソートするように修正、getEvent呼出を削除
  • 15:30-16:00 Failしているのをなんとかしようとする
  • 16:00-16:20 SQLのロックを外して、goでロックを取るように修正
  • 16:20-17:00 /api/users/:id修正 : getEventの結果の使いまわしを実装、getEventNoDetail・getEventNoSheetsを作成
  • 17:00-17:10 reservations.user_idにINDEXを張る
  • 17:10-17:40 オンメモリキャッシュのつなぎ込み
  • 17:40-18:00 おしゃべり

目立った点

nginx化

sudo yum install nginx で適当にインストールして実行ユーザを変えたのですが、
nginxのテンポラリディレクトリの権限を付けておらず、
/admin/api/reports/events/:id/sales/admin/api/reports/sales のようにレスポンスデータが大きい場合のみエラーが発生する、
という問題を起こしてしまいました。

nginxのエラーログを見たら Permission denied が出まくってるのですぐ気づきそうなものだったのですが、
全く見ておらず、それに気づかず16時までfailし続けていました。
動作が遅いからfailしているのでは?とか言っていろいろ修正していたのですが、
ブラウザでダウンロードしようとするとネットワークエラーになり、
ログを見たらエラーが出ているという状況でした。
ベンチマーカのログを見てちゃんと確認したらすぐ分かったことで、深く反省していますorz

野蛮なロック

予約/キャンセルAPI全体のロック を取りました。
これによってSQLのFOR UPDATEは不要になります。
常日頃から並列処理やロックは扱えないと公言して憚らないので、自分としては普段どおりです。(自慢できることではない)
結果的にはダブルブッキングやデッドロックといった様々な問題が未然に防げたようなので良かったです。

感想

反省点は多いですが、結果的には良かったので良かったです。
準備してもらったレポートツールはとても優秀で楽しくチューニングできました。

昨年作問を担当したので運営側の大変さはとてもわかるのですが、 特にベンチマーカがどんな実装だったのかと気になっています。
これを作るのはめちゃくちゃ大変だったのでは…

本選を楽しみにしています!

こんにちは, @mecha_g3 です.

ISUCON8というサーバチューニングコンテストで予選に参加したので, 自分のやった事を書きます.
予選1日目の4位, 全体10位という結果で無事予選通過することができました.

リポジトリとベンチマークの結果を貼っておきます. ベンチマークレポートは最後ログを切ってしまった都合上, 最終の一つ前のベンチマークのものです.

チーム

ISUCON4, ISUCON5 で予選落ちした DiamondPrincess (@hasi_t, @mecha_g3, @pandax381) です.
ISUCON6 は本気で勝ちに行って僕は別チームに. ISUCON7 は問題作ってました.
今年はゆるふわ参加が良いな〜と言いながら, 初期 DiamondPrincess メンバでの参加になりました.

事前練習の予定が合わないのでぶっつけ本番でいくことになり, 予選通過はほぼ無理な雰囲気だったのですが, うっかり予選通過したら考えよう!OpenRestyつかってNginxLuaで遊びたい!とか話してました.

予選3日前

社内のもう1チームが練習しているチャットで Pixiv 社内ISUCON2016 のCentOS版イメージが作成されていたので共有してもらいました.

急にやる気が出てきたのでそのイメージを使って開発環境を整え, 昔作ったプロファイリング系のツールの動かし方を確認し, 軽くチューニングする練習をしたり, スタートダッシュシート(開始直後TODOリスト)を作りました.

予選

開始直前に会社の会議室に集合しコンテスト開始.

以下, 僕のやったことを時系列で

  • 10:00-12:00 ポータルに対してエンキューとスコア取得を行うスクリプトの作成. Puppeteerを作業環境上で動かすのに苦労する.
  • 12:00-13:00 作業環境上で開発できるようにする. デプロイやログ取得周りのスクリプトの整備を手伝い, 開発環境が整備されていく.
  • 13:00-14:00 MariaDB -> MySQLに置き換え. プロファイラの有効化, レポートが見れるようになる.
  • 14:00-17:30 User, Sheet, Reservation, Event, SheetSlice, ReservedTimes, ReservedUserID のオンメモリキャッシュ作成・適用・バグ修正.
  • 17:30-17:40 再起動試験しますと言いながら開発環境を再起動したり, MySQLにつながらなかったら1秒スリープして再接続 しない みたいなコードを書く.
  • 17:40-17:50 pprofを有効化するフラグをfalseにする(ただしそのフラグは使われていない).
  • 17:50-17:55 お祈り

目立った点

コマンドからエンキュー

Puppeteerでポータルに対してエンキューとスコア取得を行うスクリプトを書きました. コマンドでエンキューやスコア取得ができるようになりました.
開発環境上で動かすのに苦労して2時間も使ってしまいました.

nginx化

h2o速そうだけど全く使ったことがなかったので nginx を使うことにしました. これは @hasi_t にお任せしていました.
パーミッションの問題で一部のレスポンスが返せずハマってしまい, 16時までベンチが通りませんでした.

予約とキャンセル排他制御

@hasi_tにより予約/キャンセルAPI全体にMutexでロックを取るロックな実装がなされていました.
他チームはトランザクション絡みでランダムなfailが起こっていたり, スコアが安定しないという話でしたが, これのおかげかうちのチームは変なfailはありませんでした.

MySQL化

myprofilerがmariaDBで動かなかったのでMySQLを使うことにしました.
最初MySQLが起動せず困ったのですが, @pandax381 が my.cnf がmariaDBのものを参照していた事が原因とすぐ特定してくれて助かりました.

オンメモリ化

ベンチマークが通っていない間から作り始め, 最終的に User, Sheet, Reservation, Event, ReservedTimes, ReservedUserID のオンメモリストアができました. Sheet, Reservation, Event あたりはメモリに載せただけで使ってないです. 関数を作って呼び出すの忘れるみたいなことを何度もしてしまいました.

スコアの遷移

16:00過ぎに nginx 後初めてベンチが通り, 6000点台でした. そこから @hasi_t とペアプロしながらオンメモリキャッシュを適用していきました. 改善を入れるたびにぐんぐんスコアが伸びていきました.

17:30あたりで再起動試験をしてみたらdbに接続できずにアプリが立ち上がって来ない問題が起きましたが, @pandax381 が一瞬で原因を見つけてくれてシュッと直してくれました.

次 35,000点 超えたら終わりにましょう, と言いながらログを切ったり再起動したりしてベンチかけると 42,181点 が出たのでここで終わりにしました.

レポート系のAPIのチューニングが手付かずに終わってしまったので, 予選通過できるか不安なスコアでした.

感想

今年はゆるふわ参加とか言っていましたが, いざチューニングし始めると楽しいISUCONを思い出してきて夢中になって, 結果的に予選突破してしまいました.
全くチーム練習していなかった割には 3人とも活躍できました. お互いの得意分野が大体分かっているのと, 準備してきたレポートツールなどが優秀でチューニングポイントを迷わなかったのが勝因だと思います.
本戦の席を奪ったからには, ちゃんと練習して挑みたいと思います!

昨年作問を担当したので運営側の大変さはとてもわかるのですが, このクオリティの問題と安定したインフラを準備してくるの, すごすぎると思いました.
ポータルサイトも超カッコよくなっていて, 昨年導入した負荷レベルの概念とかベンチマーカーからのメッセージとかが継承されていて嬉しくなりました. ベンチマーカー作るの本当に大変なんですよね...
競技中はボリューム大きすぎ, 難易度高過ぎと思いましたが, 終わってみるとボリュームと難易度のバランスの良い良問でした. 本戦で裏話が聞けるのが今から楽しみです.

↑このページのトップヘ