はじめまして、大阪工業大学 情報科学部 情報知能学科 3年 伊地知翔也と申します。
普段は、チームや個人でWEBアプリ開発をしたり画像処理についての研究をしています。
このサマーインターンに参加する前までは、
私のサーバサイドで経験のある言語は、
しかありませんでした。
しかしながら、ゲームのサーバサイドに携わってみたいという想いから経験のないRuby on Railsを使用する本インターンを志望しました。
事前の準備として、Ruby on Railsのチュートリアルを概ね完走しました。
といっても、他の言語でWEB開発の経験あったので、この機能を実現するにはこのメソッドを使えば良いなど、飛ばし飛ばし大まかに学び、準備していました。
続きを読む
はじめまして、7月5日から7月30日までアカツキのサーバーサイドでインターンをさせていただいた光枝と申します。 本記事では私が今回のインターンで取り組んだことについて共有させていただきます。
神戸大学理学部の学部3年生です。 普段は主にWebアプリケーションの開発をやっていて、サーバーは Ruby on Rails、フロントは React/Next (TypeScript) を書くことが多いです。 最近は Go や Kubernetes の勉強などもしています。
今回のインターンで取り組んだ題材は「負荷試験」です。
私が携わらせていただいたサービスはユーザー数が非常に多いゲームでイベントや新しいガチャが実装された際にはサーバーにかなりの負荷がかかります。
そんな中で当ゲームはメジャーバージョンアップを控えています。 その際に
を検証する必要があり、そのタスクにアサインいただきました。
検証にはAWS上に構築した本番環境の数十分の1スケール(以後stress環境と呼びます)を使用しました。 手順は以下の通りです。
負荷試験には LOCUST という負荷試験ツールを使用しました。
LOCUST は locustfile.py というファイルにシナリオを書くことで、その通りに負荷をかけてくれるツールです。
(他にもアクセスするユーザー数や Hatch rate を設定し、結果を確認するためのGUIを提供しています。)
シナリオは例えば
ログイン → お知らせ確認 → ログインボーナス取得 → ...
のようにユーザーの動きを再現するように、各APIを順番に叩く処理を記述します。
バージョンアップに際して今回着目した新APIを叩く処理をシナリオに追記しました。
(ここではそのエンドポイントを POST /hoge として置きます。)
まず新バージョンがすでに動いている環境のデータベースをコピーしてきて、LOCUST をローカルで実行します。 ここで失敗し続けているAPIがないか確認します。
(例えば特定のAPIが失敗していた場合、そこで処理が止まってしまい想定していた負荷をかけることができなくなったり、その後に続く処理が実行されなくなってしまうのでここで確認する必要があります。)
手元で確認が取れたら実際にstress環境で実行します。 stress環境にかかる負荷は
インフラの負荷 → Amazon CloudWatch
アプリケーションの負荷 → New Relic, LOCUST
で確認します。
上記の 1 ~ 3 で負荷試験を実施してデータをみたところ、新APIに問題が見つかりました。
| 平均レスポンスタイム (ms) | |
|---|---|
POST /hoge |
2090 |
| 1リクエストあたりのSQL実行回数 | |
|---|---|
| ActiveRecord Model2 find | 396 |
| ActiveRecord Model3 find | 396 |
| ActiveRecord Model4 find | 18.3 |
これは N + 1 問題が起きていると考えられます。 なのでこれを修正して再度負荷試験を行い、どの程度改善されたかを計測します。
実は負荷試験を実施するまでにもいくつか苦労したところ (e.g. 「外部API のモック。これをやらないと外部サービスに対して負荷をかけてしまう」) がありましたが、今回は負荷試験の結果と改善に焦点を当ててお話させていただきます。
まず 「N + 1 問題とは何か」を簡単に説明します。
例えばユーザー(User)というモデルがあり、ユーザーがユーザーHoge (UserHoge)というモデルと関連があるとします。 また1ユーザーにつき、通常複数の UserHoge が関連しているとすると以下の図のような関係になります。
これらのデータが全て必要な場合にUserHoge が N 個あるとすると、このデータを取得するためにデータベースに N + 1 回 (1回は最初に User を取ってくるため) 問い合わせてしまうことを N + 1 問題と呼びます。
これらは本来、工夫することで 2 回の問い合わせですべてのデータを取得することができます。
今回の POST /hoge の問題も N + 1 問題だと予想されます。
まず実際にローカル環境で API を実行して発生したクエリを再現し、該当コード部を読みました。 その結果以下のような構造になっていることが判明しました。
User が複数の Model1 と関連していて、Model1 は複数の Model2 と Model3 と関連があります。Model3 は 1 対 1 で Model4 と関連があります。 またこのサービスはデータベースを水平分散しており、「User, Model1, Model2, Model3」は同一のデータベース(Shard1)にありますが、Model4 だけは別のデータベース(Shard2)に保存されています。
これらのデータをすべて取得してくる必要があったため対策がない場合は
としたとき合計で
N1 × (N2 + N3 + N4) 回
のSQLクエリを発行することになります。(ただし N1 個の Model1 はすでに取得済みとします。)
これが原因で POST /hoge は非常に重くなっていました。
本サービスのサーバーサイドは Ruby on Rails で書かれています。
通常の N + 1 問題であれば includes メソッドを使うなどで解決できますが、今回の Model4 はシャードが異なるためワンライナーで取ってくることはできません。
Model3 から関連する Model4 を取る際にシャードを変更する必要があります。
この部分は以下のようにして解決しました。
Octoball.using(shard1) do ActiveRecord::Associations::Preloader.new.preload(model1s, [:model2s, :model3s]) end model3s = model1s.flat_map(&:model3s) Octoball.using(shard2) do ActiveRecord::Associations::Preloader.new.preload(model3s, :model4) end
まず Octoball の部分でシャードを切り替えています。
以下のように記述することで #block の部分を指定の shard に接続した状態で実行することができます。
Octoball.using(shard) do # block end
そこでまず Model2, Model3 まで shard1 に接続した状態で preload (ActiveRecord::Associations::Preloader.new.preload(model1s, [:model2s, :model3s])) しておきます。
そして preload した model3s だけ変数に参照渡しして、shard2 に切り替えてから残りの Model4 も ActiveRecord::Associations::Preloader.new.preload(model3s, :model4) で読みます。
このように記述することでシャードを跨いだ関連に対しても N + 1 を回避させることができます。
全データの取得はこれで問題ありませんでしたが、それでも model4 だけ N + 1 問題が解決しませんでした。
理由としては、その後の model4 を使用する箇所で model3 のアソシエーションを使用していなかったためです。
実装は model4_id を用いて model4 を find_by するコードになっていました。
class Model3 < ApplicationRecord
belongs_to :model4
.
.
.
def model4
unless defined? @model4
@model4 =
if model4_id
Model4.using(shard2).find_by(id: model4_id)
end
end
end
end
なお model4 の関連付けがあるのに model4 メソッドが用意されているのは、毎回シャードを指定しなくてもよくするためです。
(また shard2 は動的に決まっています。shard2 は master/slave 構造を取っており、環境変数のAZを見て最適な slave を返すようになっています。)
上記の記述だとアソーシエーションを利用せずに model4 を取得するため preload したデータを使いません。
そこで以下のように条件を書き加えました。
class Model3 < ApplicationRecord
belongs_to :model4
.
.
.
def model4
unless defined? @model4
@model4 =
if model4_id
if association(:model4).loaded?
association(:model4).target
else
Model4.using(shard2).find_by(id: model4_id)
end
end
end
end
end
association(:model4).loaded? ですでに読み込まれているか確認して、true だった場合はその中身 association(:model4).target を返すようにしました。
上記の改善を入れて、再度負荷試験を実施したところ以下のようになりました。
| 改善前の平均レスポンスタイム (ms) | 改善後の平均レスポンスタイム (ms) | |
|---|---|---|
POST /hoge |
2090 | 296 |
| 改善前の1リクエストあたりのSQL実行回数 | 改善後の1リクエストあたりのSQL実行回数 | |
|---|---|---|
| ActiveRecord Model2 find | 396 | 1 |
| ActiveRecord Model3 find | 396 | 1 |
| ActiveRecord Model4 find | 18.3 | 1 |
完全に N + 1 が消えて、各 Model がそれぞれ1クエリで取れるようになったのがわかります。
また POST /hoge 自体もかなり高速化されました。
インターンに参加する前は負荷試験について言葉だけ知っている状態でした。
しかし実際に
負荷試験の準備(シナリオ作成、APIの失敗がないかのチェック及び修正、ローカル実行で確認)
↓
stress環境で負荷試験実施
↓
CloudWatch, New Relic, LOCUST でメトリクスなどを確認
↓
問題があった場合は改善
↓
再度負荷試験を実施して改善効果を検証
という一連の流れを体感することができました。
またシャードを跨いだ関連付けの取得やActiveRecord 内部の仕様についても理解を深めることができました。
実は事前面談で「インフラ系のタスクをやってみたい」とお話していてこのタスクを用意していただきました。
なので私がやりたいと言ったことをやらせていただき、また手厚いサポートのもとたくさんのことを学ばせていただきました。
約3週間本当にお世話になりました。ありがとうございました！！！
こんにちは。 7/5〜7/27までの3週間、アカツキのサマーインターンに参加させていただきました、あおやまと申します。 このインターンでは、「八月のシンデレラナイン」のサーバーサイドの機能改修・運用改善などの業務に携わりました。
ここでは、このインターンで取り組んだこと、学んだことについてまとめていこうと思います。
通信制の大学に通う学部3年生です。 大学ではCS系のことを学んでいます。 普段はWebの開発をしており、インターン参加前はサーバーサイドというよりはフロントエンドよりのことをやっていました。
Ruby/Ruby on Railsは3週間ほどしか経験がなく、超基本的なことしか理解していない状態でした。（普段はPHPやTypeScriptを書いています）
自己紹介でも書きましたが、普段はWebの開発ばかりやっているので、ゲーム開発は初めてでした。
雑談で上がっていた新規機能が面白そうだったので、ディレクターさんやプランナーさんにその機能を開発したいと相談しました。 その話し合いの中で、その機能を作る目的について聞かれました。 しかしながら、私はユーザーに対する目的しか浮かびませんでした。そこで、他にどのような目的が考えられるかを尋ねたところ以下のような回答をいただきました。
「ほぇ〜〜」
実装に対するコスパ、マーケティング、チームの育成など今まで考えたことがないばかりだったのでとても学びになりました。
これを元にプランナーさんと話し合いをした結果、現状はこの機能は現実的ではないということで断念しました。
上記の新規機能開発は早い段階で断念する決断ができたため、その後は作戦を変更することにしました。
その作戦名は、
運用改善タスクを数こなしてみんなに感謝されよう作戦
です。
私が配属されたチームでは、手のつけられていない運用改善タスクが山ほどありました。そこで、それらを1つずつ片付けていきました。
運用改善タスクは、仕様が決まっているものもあれば、あやふやなものもありました。仕様があやふやな場合は依頼者に、「なぜこの機能が必要か」「この機能で検証したい部分はどこか」などの聞き込みが必要でした。そのような聞き込みをするのが初めてだったので、最初は何を聞いたら良いか分かりませんでしたが、複数タスクをこなすうちに、依頼者はどのような機能が欲しいかなどを感じたり、うまく聞き込みをしたりすることができるようになりました。（成長！）
結果、サーバーサイドの運用改善タスクはほぼやり切ることができ、数としては6つこなすことができました。
新規機能開発の一部を体験できたこと
断念してしまいましたが、話し合いを通じてたくさんの学びがありました。
運用改善でチームに貢献できたこと
運用改善チームの方から感謝されました^^
ゲームのサーバーサイドの中身を知ることができた
機能改修タスクや一部の運用改善タスクはゲームのロジックの理解が必要だったので、そこを理解しレビュアーとしっかり議論することができました。
エンジニアとして技術以外のことをたくさん学ぶことができた
ただ作るだけでなくなぜ作るかやどう作るかという考えや、エンジニア以外の方とのコミュニケーションなど個人では体験できないことを実際に体験し、そこからたくさんのことを学ぶことができた。
自走力が成長した
いい意味でメンターさんが私を放置してくれたので、自分からエンジニアやディレクター、プランナーさんたちにコミュニケーションを仕掛けたりと自走する力が成長しました。
オーナーシップを育てる
今回のインターンでは、自分がタスクのオーナー（それについて一番詳しい）になることが多々ありました。しかし、まだまだ自分がオーナーだという自覚が足りない場面がありました。これからたくさんの経験を積んで1つのプロジェクトを見れるくらいのオーナーシップを育てていきたいと思います。
リアルタイムのゲーム開発
参加前はゲームはするのは好きだけど、自分で開発するということは考えていませんでした。しかし、自分の好きなもの（ゲーム）を開発することはとても楽しかったので、もっとゲーム開発をしたいと思うようになりました。次はリアルタイムでやりとりが行われるようなゲームの開発もしてみたいです。
参加前はフルリモートで若干不安でしたが、参加してみると毎日メンターさんが1on1を開いてくれたり、朝会・夕会があったり、定期的に社内の方とランチ会があったりととても楽しくインターンを過ごすことができました。
とても充実した3週間を過ごすことができました！！
はじめまして！ハチナイのサーバーサイドエンジニアとしてインターンを体験させていただきました、堀崎と申します。7/5〜7/27の15日間お世話になりました。
今回のインターンで開発したものとそこから得た学びを書いていこうと思います。
名古屋大学に通う学部3年生です。
アプリ開発サークルに所属しており、普段はWebアプリを開発しています。サーバーサイドとしてRails、フロントエンドとしてVueを主に使っています。
今回はRailsでの開発がメインでしたが、普段使っていることもあり技術に対する不安はそこまでなかったです。
最初は簡単なタスクとして、管理画面の機能追加を行いました。管理画面はActive AdminというGemを利用して作られており、初めて触りましたがすでにあるコードを参考にして難なく実装が出来ました。
管理画面のタスクを終えてコードの全容が見えてきたところで、ゲームAPIの速度改善のタスクを引き受けました。改善点が明らかになっていなかったため、まずはログの調査から始めて改善策を練ることにしました。
以下の問題が判明しました。
N+1問題に対する対策としてeager_loadすることにしました。そしてdeleteクエリに関しては一括で削除するメソッドを自前で用意することになりました。
改善前はレスポンスを返すまでに約5.5秒かかっていた処理を約1秒まで短縮することができ、約80%の速度改善に成功しました。
最後のタスクとしてプルリク作成時にファイル名をチェックするCIを追加しました。こちらはGithub Actionsに新たにjobを追加するだけだったので比較的速くこなすことができました。
3週間という短い期間でしたが、色々なことを学ばさせていただきました。
今回のインターンでは、調査タスクを多く経験させていただきました。その中で公式のドキュメントを読み込んだり、GithubのIssueを探索したりとコードを深く追っていく力を養うことができました。
また、これまでに触れたことのないGemやCI/CD関連のツールにも触れることができ、保守性の高いシステムに関しても新たに学びを得ることができました。
このインターンで一番苦しんだのがコミュニケーションだと言ってしまっても過言ではありません。これまで小規模の開発しか経験してこなかった僕にとって、自分の思っている実装方法を人に伝えることは非常に困難に感じました。言葉足らずで自分の意思が正確に伝わらず、メンターさんを困惑させてしまうことが何度かありました。自分で改善することが難しかったコミュニケーション能力に関して、ご指導してくださったメンターさんにはとても感謝しています。まさかエンジニアインターンでコミュニケーション能力が養われるとは思ってもいませんでした。
15日間あっという間に過ぎてしまいましたが、非常に有意義な時間を過ごすことができました。メンターさんをはじめ、たくさんのサポートを本当にありがとうございました。
アカツキ社内の雰囲気について、皆さんが楽しそうに話されている姿からアカツキという会社がより一層魅力的に見えました！
短い期間でしたが、本当にお世話になりました！
初めまして、アカツキのクライアントサイドのインターンに参加させて頂いた植村と申します。
今回、7/12〜7/30の13日間、開発に参加させていただいたので、取り組んだことや思ったことについて書いていこうと思います。
自己紹介をします。
私は今、早稲田大学修士１年でVRについて研究しています。
趣味はゲームをプレイすること、制作すること、それからロボットです。
将来はゲーム開発に関わる仕事を志望しており、今回はUnityエンジニアとして参加させていただきました。
僕が参加したのは、「八月のシンデレラナイン」（以下ハチナイ）の現場でした。
そこでメンターの方と話し合い、主に選手交流周りの改修を任せてもらえることになりました。
それぞれタスクについて書いていきます。
インターンで初めて取り組んだタスクです。この悩み解消前テキストというのは、選手育成から解消してしまうとゲーム内で見る手段がなくなってしまうものでした。それに対し、選手交流における悩み解消時再生エピソードに付随させられるようにするというタスクです。
まず最初に行ったのはデザイナーさんとプランナーさんとの会議です。そこで仕様を決め、実装に移りました。
実装をする中で現場で作られてきたコードに触れながら、理解を深めました。
コードの意味や実行速度について、ここまで深くやったことはなかったのでとても良い経験になりました。
この機能の中で特に苦労したのは、ストーリーのエピソードのIDから悩み解消前テキストをマスターデータから検索してもってくるところでした。
結果としては
エピソードのIDに一致する悩み解消時エピソードを持つシーンのスキルを検索
→そのシーンのスキルを持つ悩みを検索する
→悩みが持つテキストを取得
という流れだったのですが、マスターデータの関係が複雑で、どこにどの情報が入っているのかを理解するのに時間がかかりました。
ここで思ったのは、自分が欲しい情報、データがどこにあるのかをコードから予想して見つけてくる力がとても重要なんだな、ということでした。
他の人が書いたコードを読むときの考え方というものをこのインターンを通じて知ることができました。
その後も一度会議をして、アイコンの追加などが決まりました。
自分からは表示するダイアログのタイトルを悩み解消前のスキル名にすることを提案し、実装することになりました。
実装してPR→レビューの流れを何度か繰り返し、実機確認もしてなんとか終えることができました。
最後に検証さんの方に機能の検証依頼を出して終了です。
仕様決定から検証依頼までの流れを一通り体験できてよかったと思います。
次のタスクは、選手交流の各選手に遷移した時、そのまま別の選手に移動したいというものでした。
プランナーさん、デザイナーさんと会議をした結果、ボタンとスワイプで移動すること、選手の並びは選手交流トップに倣う形にすることが決まりました。
まず最初にやったのは、隣の選手へのスワイプ機能、ボタンの機能の実装です。
ハチナイにおいて、似た形のスクロール処理はいくつかあり、今回はその中からデレストのオーダー選択と選手交流トップのスクロールを参考に作ることにしました。
機能について理解しながら、基本となる部分は実装できました。
が、気になる問題点がいくつか見えてきました
もともと動かすことを優先してシーンが開始する時の処理を毎回呼び出していたが、必要なものだけに絞って、メニューが消えるのを阻止しました。
スクロール完了と共に、スクロールを中心に戻しつつ、選手を表示するGameObjectの位置を交換することで更新時、選手の読み込みを新たに増えた一人分だけにするようにしました。
これにより、選手の更新は画面外のみで起こるようになったので、選手が消える問題も解決しました。
もともと参考にしていたスクロール処理では隣の選手との距離の半分を超えてドラッグしていたら移動という感じだったのを、距離に対するスワイプの移動量の割合を、あらかじめ設定した閾値を超えるかどうかで判定するようにしました。調整をできるようにするとともに、閾値を大幅に下げました。
選手交流トップにおいて、本校では有原と草刈がつながる形の円環のリストとなっています。対して、コラボ選手、ライバル校は手に入れない限り人数が少ないので、その場合同じ選手が画面に並んでしまう事になります。
それを避けるため、本校以外のカテゴリーには端があります。
このようにカテゴリーから対応を変える処理をするためにプレイヤーが所持しているカテゴリー別の選手のリストを作る必要がありました。
選手リストはマスターデータから持ってくることになりますが、コラボとライバル校のどの選手を表示出来るかを知るには、APIを叩く必要がありました。
選手交流トップの方でこの処理をしてカテゴリー別所持選手リストは生成されている上に、選手交流詳細では選手交流トップで使うリストと同じ選手の並びを使いたいということもありました。なので、もうあるのならばそれを使わせてもらおうということで、円環リストは選手交流からシーンの遷移時に渡してもらうことにしました。
スワイプでの移動は関係なく、選手交流詳細のページに入った時の選手になるので、戻るボタンに選手交流詳細から来た時のみ、どの選手に帰るか指定する関数を渡しました。
円環リストを生成する中で、リストも渡さなくてはいけなくなりましたので、シーン遷移時にリストを持っていない場合、APIを叩いてリストを生成するようにしました。
その他にも作業する中で、確認していると、気になる点や機能の追加によって動かなくなる点をいくつか見つけました。ページのスワイプがボイスや課題メニューの時に出来てしまうことや、スワイプ後に表情がリセットされていないことを発見し、メンターの方に報告して修正を行なっていきました
この機能では、機能実装→レビューなどで問題点を発見→修正を多く繰り返しました。
最初はコードを見て、仕様通りになるように実装するのが精一杯といった感じでしたが、繰り返すうちにだんだん自分で問題点を見つけて、共有し、修正するということが出来る様になって成長を感じることが出来ました。
インターン中に思ったことや感想について書いていきたいと思います。
朝会、夕会は雑談から入るのですが、毎回様々な話題で盛り上がっていて雰囲気が良いな、と思いました。その後は、共有事項などについてしっかりと話し合っていてメリハリがあるなと感じました。和気藹々としながらもやるべきことはちゃんとやって、全員がゲーム開発チームの一員だと思って仕事をしているのを見て、こういう風に働きたいなぁと思ったりしました。
Gitの使い方（PRの出し方やブランチの分け方など）やリポジトリの使い方など小規模開発では、意識しない所で数多くの工夫が見られ、驚きました。
他者が書いたコードを読み込むという経験をあまりしてこなかったのですが、他者のコードを読む際には、ただ漠然と理解しようとするのではなく、自分が今何を知りたくて、その情報はどこにあるのかを考えながらコードを読むことが、大事なのだと気づかされました。
現場の雰囲気や大規模開発のコードの読み方は、このインターンに参加しなければ得られなかった貴重な学びとなりました。
ゲーム開発においては、各職種が連携して作り上げて行くというのはもちろん知っていましたが、どのようにそれを成すのかは、あまりイメージができていませんでした。
今回インターンに参加してみて、そのことについて実感が湧きました。これも参加してみないと分からない点だと思うので実感できたのはとても良い経験になりました。
私のゲーム開発の経験は大体が半年後に向けて動くゲームを作るといった短いスパンのものでした。そうした場合まずは最低限動くものを目指すこととなり、小さな、完成度を高めるための開発の経験が積めていませんでした。
こういう経験を積めるのは、もう既に動き出しているプロジェクトに参加したからこそなので、知ることが出来て良かったです。
大きな一つのゲームの中で、自分の実装した機能が動いているという喜びは初体験でしたが、とても良いものでした。
もともと用意されていた課題のうち一つを達成できなかったことです。これの原因は、必要な情報がどこにあるのかを予測し、調べるのに手間取ったことと自分が今何で詰まっているのかをメンターさんに上手く共有できなかったことだと思っています。
自分で調べることはとても重要なのですが、実はちょっとしたことで詰まっているということがインターン中に結構ありました。
悩んでいることをただ書いておいて、手が空いている人が見てアドバイスをする、という場所がちゃんと用意されていたのに上手く使えていなかったなという反省点があります。
これからは作業に没頭するのではなくて考えをアウトプットするのをもっと意識して開発したいと思います。
反省点はあるものの、ゲーム開発の現場についてよく知ることができ、チームで一つのゲームを作るとはどういうことかを知ることができました。
現場で使われているコードに触れたおかげで、コードを読む力、書く力共に大きく成長できたと思います。
やはりゲーム開発は楽しいです！
たくさんの収穫を得られた良いインターンでした、３週間受け入れてくださりありがとうございました！
