こんにちは。この度、2021/8/23~2021/9/3の２週間、アカツキゲームスの就業型インターンに参加しました。
このインターンでは、『八月のシンデレラナイン』のサーバーサイドでの業務に携わりました。
自己紹介
地方国立大学の修士2年生です。
普段は文字列を研究しており、C++やRustと戯れています。
インターンで取り組んだこと
今回のインターンでは、サーバーサイドエンジニアとして、以下のタスクに取り組みました。
管理サイトの機能追加
不具合の調査対応でユーザの情報を閲覧したり編集したりする場合は、エンジニアが作業をする必要がありました。そこで、管理サイトでできるようにしました。これにより、エンジニアでなくても対応できるようになりました。
AWSのメンテナンス情報をSlackで通知
AWSでは、稀にメンテナンスにより、インスタンスの再起動などが起こります。このようなイベントは、以下の方法で連絡がきます。
- メンテナンスが予定されたよ！と、イベントが発行される
- メールによって通知される
しかし、メールでの通知は、必ず行われる保証はありません。
そこで、メンテナンスに関するイベントがきた場合にSlackで通知することで、メンテナンス情報を把握しやすくしました。
構造としては、EC2やRDSなどのリソースについて、CloudWatch Events でメンテナンス情報に関するイベントをキャッチし、LambdaからそれらのイベントをSlackへ通知するようにしました。
NewRelicの導入
NewRelicとは、サーバーやインフラのパフォーマンスを分析するためのツールです。以前は導入をしていたのですが、一時的に動作が止まっていたので、開発環境で動作するようにしました。NewRelicではAPIのレスポンスタイムや、CPUの使用率、メモリの使用量などパフォーマンスを分析するためのデータを確認することができます。これにより、どのAPIが遅いのかを調査することができました。
API 高速化
NewRelic導入により、レスポンスが遅いAPIが見つかりました。そこで、高速化できないか調査を進めていきました。NewRelicではtransaction毎に、どのようなリソースへのアクセスがあったのか、また、そのリソースからのレスポンスタイムなどの詳細を確認することができます。この中で、クライアントへ返すjsonのレンダリング処理を行なっている、jbuilderが遅いことが判明しました。
jbuilderでの処理を高速化することを大まかな方針とし、どの処理がボトルネックとなっているかを確認していきました。
partialの改善
jbuilderでは、jsonでのレンダリング処理を外部ファイルから呼び出すpartialという機能があります。本APIではこのpartialを利用していたのですが、こちらは、レコードが大規模である場合に低速になります。そこで、partialの利用を回避し、実装してみました。
結果として、効果がみられませんでした。
N+1の改善
NewRelicでさらに調査を進めていくと、レンダリング処理の中で、DBへのアクセスが頻繁に行われていることが判明しました。これは、N+1であるような挙動をしていたので、テーブルを直接参照している処理がないか調査をしました。
すると、preloadされたテーブルではなく、直接テーブルを参照している箇所を発見したので、この処理を改善しました。
しかし、この改善においても、全体のレスポンスタイムは大きな改善とはなりませんでした。
時間切れ
ここまで調査した段階で、インターン期間の終了が近づいてきました。そのため、このタスクについては、サーバエンジニアチームに引き継いで調査を続けていただくことにしました。情報の引き継ぎを円滑にするために、今まで調査した内容をまとめて、Issueとして残すことにしました。APIが遅い原因は、さまざまな要素が絡まり、一筋縄ではいかないことを改めて認識しました。
まとめ
今回のインターンでは、サーバーのタスクだけでなく、AWSでのインフラに関するタスクも行うことができました。また、実際に稼働しているゲームの開発に関わることができて、とても刺激的でした。
また、アカツキゲームスの文化として発言の心理的障壁がとても小さいことを実感しました。メンターの方々のサポートも手厚く、質問に対する答えも、その答えへの辿り着く方法を教えてくださるので、課題の解決方法として学んでいくことができました。
2週間という短い期間でしたが、濃厚な時間を過ごすことができました。ありがとうございました！
