ID:15095さん

在職中の会社で現在担当しているプロジェクトです。 サーバサイドのリーダを務めました。 ## 成果 - Goの導入 - 要求されたパフォーマンスの達成と、それ以上にスケールできる余地 - 実装の速度 ### Goの導入について 使用する言語の選定から始め、要件定義、設計、実装、リリース後の対応と幅広く担当しました。 この会社ではサーバサイドの言語は主にRubyを利用していましたが、このプロジェクトでは新たにGoを採用しました。 Rubyを捨てた理由としては、型が欲しかった、リアルタイム(websocketを想定)、早い言語を使いたいなどの理由がありました。 Goの他にElixir, Rustが候補になりました。採用しなかった理由としては、 - ElixirはErlangVMに慣れるのに時間がかかりそうだった - RustとGoはパフォーマンスとリアルタイムという点ではあまり差がなさそうでしたが、Goのほうが文法が好みだった - Goのほうが採用実績が多そう(stackoverflow、Qiitaのタグで検索した結果) でした。 早さについてはRubyよりも早ければいいという程度だったので他にRubyより早い言語(PHP, JVMなど)もありましたが候補にはなりませんでした。 また、Goを採用した副次的な効果として、 - Ruby(capistrano)で苦労したデプロイが非常に楽 - バイナリを1つデプロイするだけで済むため - メモリ消費が少なく、ボトルネックがCPUに絞りやすい - 型があるので関数/メソッドの定義を見るだけで動作が想定しやすい - 型があるのでテストが楽。Rubyでよくあったnilの混入がない - 標準のlintツールが存在しているので、レビューが楽 などがありました。 今後も(Rubyに型が導入されるまでは)Goを採用したいです。 リアルタイムについては、サーバが落ちることを前提とした設計を作っていました（デプロイ時のプロセス再起動でクライアントとの接続が切れる）が、結果的に仕様がなくなったため、不明です。 いずれ機会があったらPaxosを使用した耐障害性の高いリアルタイムサーバを構築してみたいです。 ### パフォーマンスについて 当初、この会社での既存タイトルのDAUなどから500req/secという目標が設定されていました。 負荷試験の結果として1000req/secを達成しました。 負荷試験では実際のユーザが操作するであろうシナリオで試験しました。(アプリをダウンロードしたユーザがユーザ登録をし、チュートリアルを行い、その後パズルをプレイしたりガチャを回したり、など) ボトルネックになっているのはDBのwriteで、RDSインスタンスもまだ上位のものがあり、また垂直分割のしやすいような設計になっているため、これ以上のスケールが望める状態を達成しました。 このプロジェクトの他でもhttpのAPIサーバ、websocketを利用したリアルタイムサーバの負荷試験の経験があります。 ### 実装の速度 テスト(E2E、一部モデルのユニットテスト)をしっかり書いていたため、デグレが少なく、また仕様の変更も容易でした。 ## 至らなかった点 - クライアントサイドの開発遅延に伴うサーバサイド開発の遅延 クライアントの開発が遅延したため、テストではなく実際のクライアントでの動作確認が遅れ、結果としてサーバのバグの発見も遅れました。 その結果、リリースの日付が近づくなかでバグの対応に追われることになりました。 こうすべきだった、というところでは、1つの機能を実装するときクライアントとサーバがそれぞれ実装をするのではなく、1人の人間が両方を担当するべきだったと考えています。 この会社ではクライアントを担当する人間はクライアントだけを、サーバを担当する人間はサーバだけを担当する習慣になっていましたが、垣根なく実装を担当することでバグの発見も早くなると考えています。 今後の転職先はソーシャルゲームの開発か他のアプリの開発かはわかりませんが、サーバとクライアント両方を担当したいです。

リリース前の開発中の時点から参加しました。 ## 成果 - パフォーマンスについての意識 - AWSについて知った - DynamoDBを利用した大規模アプリケーションの開発 ### パフォーマンスについての意識 この会社に転職し、初めてソーシャルゲームの開発に携わりました。 それ以前の会社(IRサイトの構築、通販会社の社内システム開発など)ではあまりパフォーマンスについて要求されることがなかったので、パフォーマンスについて意識する機会を得ました。 ### AWSについて知った 同様、この会社で初めてAWSに触れました。 EC2, DynamoDB, S3, CloudFront, SQS, SNS他さまざまなAWSのサービスの利用について学ぶことができました。 他プロジェクトでもlambda、APIGatewayを利用したサーバレスな実装について学ぶことができました ### DynamoDBを利用した大規模アプリケーションの開発 DBはDynamoDBを主に使用していました。他、複雑なクエリ(ユーザ検索など)にはMySQL。ランキングやキャッシュにredisを使用していました。 同一リージョンにひとつ コストの問題で、本番と開発サーバで異なるリージョンを利用していたため、本番と同一の環境での試験ができませんでした。 ## 至らなかった点 - テストが書けなかった - バッチでユーザのデータを消した - サーバが乱立していた ### テストが書けなかった 既存のコードについて一部テストが存在していましたが、途中からテストが書かれなくなっていました。 テストが書かれなくなった理由は、DynamoDBを利用することでテストのしにくい環境になっていたのが原因でした。 テスト用のドライバを作るなどの対応が必要だったかと思います。 これ以降に参加したプロジェクトでは、以下のようにしました。 - そもそもテストが書きにくい設計にしない - テストが書かれていないコードはマージしない ### バッチでユーザのデータを消した 日次でユーザのデータを書きかえるバッチを作った際、本来変更する必要のないユーザのデータまで変更してしまうバグを発生させました。 これ以降バッチを実行するときには、以下のようにしました。 - よくよく動作確認をする - 小物のバッチでもテストを書く - レビューがされていても、実行する前には自分以外の人間とコードを読みなおしてから実行する ### サーバが乱立していた このプロジェクトには以下のサーバが存在していました。 - httpのAPIサーバ - websocketによるリアルタイム対戦サーバ - websocketによるチャットサーバ - websocketによるルームサーバ（パーティを組むときにユーザが待機するサーバ） - 管理ツール - 日次、週次で実行されるバッチサーバ - お問いあわせサーバ このため、管理しなくてはいけないサーバが多く、またデプロイ先が非常に多く苦労しました。 これ以降は以下のような設計をするようにしました。 - 日次など定期的に実行するバッチが必要にならない設計 - お問いあわせなど、サービスの本体に関わらないものについてはlambda+APIGatewayでサーバレスな構成にする - websocketのサーバはまとめる