読者です 読者をやめる 読者になる 読者になる

tom__bo’s Blog

情報系学生がプログラミングしたり、ボルダリングしたりボルダリングしたことを書くブログ。もはやダイアリー

【ヒカ✩ラボ】スマホゲーム開発最前線を支える技術! に行ってきた

IT event

上記のイベントに行ってきた!

イベント系はその日中にブログにしようと思っていたのに結局何日か立ってしまった。。。(||´ロ`)o

 

と、言ってもしょうがないので、気を取り直して、、、

まずは会場から↓

 

f:id:tom__bo:20150522022939j:plain

ヒカリエのLeveragesが会場で、【ヒカ✩ラボ】というのもレバレジーズのテクノロジ部門らしきところが開催しているようです。

 

f:id:tom__bo:20150522023303j:plain

開催前の様子。

 

このイベントでは株式会社アカツキのエンジニアの方が、何かしらのLTをするというものでした。それぞれについて自分が理解できた興味をもったところを中心に書いてみたいと思います。

 

 

① RailsAWSを使って超えた1分間で10万リクエスト処理するインフラ基盤構築の壁 失敗談も含めご紹介します!

田中 勇輔氏(@csouls)さんのLT。(資料:http://www.slideshare.net/aktsk/hikarabo?ref=https://teratail.com/presentations/10060

 

AWS上にRailsでRestなAPIサーバを作った時のお話。

・ rails5からはリアルタイム更新制の強化が進められたりと、多機能化して使いやすくなっていく一方で、学習初期コストも増加しているらしい。

 フルスタックフレームワークって、アプリ作るまでの学習コストはフレームワークの書き方さえ覚えればいいから、低いってイメージだったんだけど、メンテナンスとか内部のコードを書き換える必要があるって場合は高いってことかな。。。なんて思ったりした。

学習コストの話だとSQLは学習曲線が低い(簡単に使えるようになる)っていう表現を聞いたことがあったりして、チームでどの技術(言語とかフレームワーク)を採用するかって議論の尺度として重要そうだからいずれ調べてみたい。

 

・ インフラ基盤を構築する際に重要なこと

 スケールアウト戦略を取るっていうことと、負荷テストをきちんとすること。

スケールアウト戦略かスケールアップ戦略を取るかはボトルネックを特定してその対応として適切な方を選択するのは当然何だけど、スケールアウトのほうが急激な負荷の増加に対応しやすいし、一般的らしい。AWS使っているところとか、クラウド基盤であればスケールアップの難易度はほとんどないっていう現状なのかもなと思った。

 負荷テストはボトルネックの特定を確実にするためにもやっておくべきらしい。実際にテストした際はAWSの4xlarge30台の構成のほうが、8xlarge15台よりも安定してテストを実施できたらしい。原因は特定できてないらしいけど、ISUCONとかに出るときに参考になるかもなーと思った。(メンバー集められて、今年あれば出場したいと思ってます)

 「パレートの法則」って有名だけど、実際にボトルネックになって処理の90%くらいのコストを生み出すのは1%くらいのミスだったらしい。例として、ユーザの情報を分散保持してキャッシュしているRedisサーバ群で、O(N)オーダーのコマンドを使ってしまっていて失敗した話をされていた。

Redisはコンシステントハッシュ法を使って障害時の影響を狭めたり、データの偏りを減らしているらしい。あとで調べてみる。

 

② 知っていると苦労しない、ネイティブアプリ開発でコケるポイント対策

宮島 亮(@sergeant-wizard)さんのLT。(資料:https://s3-ap-northeast-1.amazonaws.com/hikalabo-miyajima/introduction/index.html#title-slide

 

f:id:tom__bo:20150523223739p:plain

(上記資料URLより)

 上のサイクルに沿って開発運用をされたお話。

基本的にはどんなサービスにも応用できるスキルだと思うけど、特にゲーム開発がメインであることで、

・ ステートが多い

・ ビルドが難しい

・ 自動テストがしにくい

・  プラットフォーム依存性

 といった要因が運用を難しくしているそうだ。

どちらかと言うとこれらにどう対応していってるのか聞いてみたかったけど、LTではそれらはおいといて、まずは上の運用サイクルをコーディング部分・レビュー部分・ビルド部分と言った風に分けてそれぞれで使っているサービスやアプリを紹介されていた。

正直そういったツールはどんどん出てくるし、所属するチームとか開発するものの声質によって、いろいろ変わると思うので、省略。

TravisCI, CircleCIの説明が一番熱くされていた気がして、

「大事なのは個人のビルド環境は信用しない」とか「デバッガとか企画の人が最新のアプリを使えることが大事」といった格言が面白かった。CI使うような環境で開発したことはないので分からないが、デバッガからのバグレポートで、コミット単位でバグの発生、解決がわかったり色々と便利らしい。

 

 

③マルチバトルを支えるNode.jsの非同期処理手法

谷口 大樹氏(@kidach1)さんのLT。(資料:http://www.slideshare.net/kidach1/nodejs-48309905?ref=https://teratail.com/presentations/10058

 

タイトル通り、Node.jsでの非同期処理をどうやって綺麗に書くかというがっつりソースコードのお話。

4人同時対戦のゲームでユーザの座標を同期するだけでも、ネストはどんどん深くなっていく。こういったコールバック地獄から抜け出すためにPromiseとGeneratorを共存させたという内容。

Node.jsの話ってことで一番興味があった内容だったんだけど、前にNode触ってた時あkら1年近く立ってたし、その頃は深い話は何も意識してなかったしで全然ついていけなかった(泣)

 

話としてはES6の機能で、現状だとharmonyオプションが必要だけど、then chainableなPromiceといわゆるco-routineのGeneratorを使って、非同期処理をネストではなくて、縦に並べて書いていくというのを具体例を交えてかなりわかりやすく話してくれていた。

qiita.com

発表された@kidach1さんが書かれた記事で今回の話もほぼこれのよりわかりやすい話でした。

github.com

上のtj/coを使うことで綺麗にコードが書ける例もあって、早いうちに試してみた記事を書けるようにしたい。

 

最後に。。。

参考までに

・ コンシステントハッシュ法

 分散されたDB(主にオンメモリDB上で、キャッシュの保存先をどこにするか、どう変更するかを決定するためのアルゴリズム
通常は全てのkeyのハッシュ値を再計算する必要があるが、リング上にハッシュ値を配分していると考えて、分配することで、少ない操作でハッシュ値を計算できる。
(参考 ↓)

http://www.hyuki.com/yukiwiki/wiki.cgi?ConsistentHashing

http://www.slideshare.net/paulowniaceae/consistent-hash

http://ameblo.jp/principia-ca/entry-10758837376.html