【デブサミ福岡 2018】Developer Summit FUKUOKAに今年も参加して来たよ！

福岡だより

#Node.js

#イベントレポート

2018.09.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも、福岡のmeです。毎年開催されるDeveloper Summit FUKUOKAに今年も運よく参加することができたので、印象に残ったセッション内容や会場の雰囲気をまとめてみました。

福岡発Node.jsで支える大規模システム！〜「誰ガ為のアルケミスト」と歩んだ三年〜

スピーカー：株式会社gumi　Entertainment Engineering Technical Manager　的野礼峰(Yoshitaka Matono)さん

セッションサマリー

gumi福岡スタジオでは、「誰ガ為のアルケミスト」の開発、運用を一拠点でほぼ全て行っています。その福岡で貯えられた三年間の開発技術、ノウハウを紹介して行きます。もちろんNode.jsの事例だけでは無く、ゲームの基盤、運用時の問題に直面した部分まで公開可能な限り共有し今後の開発に役立てて貰えればと思います。

株式会社gumiについて

・アジア：シンガポール、ヨーロッパに拠点あり、国内には３つの拠点がある
・福岡1拠点でモバイルブラウザゲーム「誰ガ為のアルケミスト」（タガタメ）の開発を行なっている

「誰ガ為のアルケミスト」タガタメとは？

誰ガ為のアルケミスト　公式ウェブサイト

当時まだ成熟していなかったNode.jsを採用

・当時Node.jsはまだまだ発展途上で、Promiseも実装されておらず、ネスト地獄を味わったりなど、たくさんの苦悩があった

しかし、”First to Try. First to Fail, First to Recover”という社の行動指針に基づき、 ”イケてそう”という理由で採用した。

なかなか実装が進まなかった理由

・XAトランザクション、マイグレーション、Log管理システムが未実装だった
・Node.jsのデーモン化
・デプロイ環境が整っていなかった

どのように対応したか

・デプロイ環境が整っていなかった→Pythonで使っていたFabricを拡張し実装
・Node.jsのデーモン化→ツールとしてForeverを採用
・Logの管理→Fluentdを利用したログ収容機能

Asset パック問題

全てのアセットをユーザーに送信するのではなく、必要なもののみをパックして送信しようと試みた
→結果サーバーが高負荷状態になり、ダウンロードにとても時間がかかるようになってしまった。

原因はCDNキャッシュがきちんと動いていなかったことと、負荷試験の想定を上回る組み合わせが来てしまったため。
→処置として９台だったAssetServerを400台にまで増やした。

その後Assetserverを廃止し、CDN S3 Originへ切り替えた。（400台のインスタンスは一週間後には廃止したそう）

サーバーダウンと負荷テスト

コラボ企画や一周年記念イベントなどを行ったことにより、通常とは異なる負荷のかかり方をした。結果、サーバーが足りなくなりログインできない障害が発生してしまったがスケールアウトすることで解決することができた。

その後の一周年記念イベントに備えサーバーの増強を行い、負荷テストを念入りに行ったが、障害が発生してしまった。
原因はアップサーバーを増やしすぎてAuroraとのやりとりがうまくできていなかったため。サーバーを減らすと動くようになった。

＊Togetter

The Amazon Way～Amazonのソフトウェア開発～

スピーカー：AWSJ シニアソリューションアーキテクト西谷圭介(Keisuke Nishitani) さん

セッションサマリー

AmazonおよびAmazon Web Servicesの開発において、その哲学やイノベーションに対する姿勢について、実際に社内で用いられている考え方ややり方、行動指針を例にお話します。

アマゾンの成長の根本にあるもの

"お客様を起点に”

Amazonはライバル企業と比べても桁違いの費用を研究費に当てていることで有名ですが、売り上げのほとんどを研究に投資するのも、”お客様の必要としているものをいち早く実現したいから”という理由からだそう。

また、長期的な目標を掲げることで
品揃えをよくする
→顧客満足
→顧客数の増加
→売り手の数の増加
→価格競争による低価格の実現

という成長サイクルを実現することに成功。

モノシリックな開発プロセス

モノシリックな開発プロセスとは？
→お互いをブラックボックス化することで不具合や変更があった際の影響範囲を制限した
→具体的には、それぞれの機能をAPIで利用できるようにした

Amazon流プレゼン

Amazon社内ではプレゼンツールの利用は推奨されておらず、会議などは６pagerと呼ばれる紙の資料と話者の話術に依存する。

これはプレゼンの資料に目を通して理解したつもりになることを防ぐのが目的だそう。

６Pagerはレポート形式ではなく、ナラティブ形式で書かれビジネスレポートなどもこの形式で書かれるのだという。

Two Pizza Team

よく知られている”Two Pizza Team”も健在
２つのピザで賄うことができる人数、すなわち８−１６くらい人数で構成されるチームが素早く柔軟に開発を行う上で望ましいというAmazon独自のルール。

このチームは手がけるものに対する全ての責任を負い、QAや障害が発生した場合もチーム内で対応するそう。

チーム内での開発方法は自由で、スクラムとカンバンでやることが多く waterfallはあまり採用されていない。

また、人が足りなくなった際の採用も各チームで行う。
これはどんな人材が必要か一番理解しているのはチームのメンバーだからという理由からだが、とても人材が必要な時、メンバーだけでは採用のハードルを下げてしまいがちなため、別の部署やチームのメンバーに採用プロセスに入ってもらうことでハードルが下がるのを解消しているそう。

チームには権限が与えられ、多くの自由が認められているがその裏返しは責任である。