Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

Akatsuki Summer Internship 2020 成果報告

こんにちは、はじめまして!🙋‍♂️

Akatsuki Summer Internship 2020 にサーバーサイドエンジニアとして参加させていただいた kimujun です。この記事ではインターンの活動報告をまとめます。

ちなみに Summer Internship といいつつ、参加したのは 10 月初旬~中旬の三週間でした。ギリ夏ですね (?)

活動内容

アカツキはモバイルゲームの会社として有名です。私も例に漏れずアカツキの提供するモバイルゲームの開発に携わらせていただきました。

いろいろな開発を経験させていただきましたが、主にゲームの新規機能開発とアプリケーションの性能改善の二軸の活動となりました。この記事では以下のような章立てで活動報告をします。

  1. ゲームの新規機能開発
  2. アプリケーションの性能改善 ~ボトルネック発見編~
  3. アプリケーションの性能改善 ~実際の性能改善編~

なお、自分が参加したプロジェクトではサーバーサイドの言語として Ruby on Rails を採用していました。

 1. ゲームの新規機能開発

すでに何年か運用実績があり、アプリケーションコードがかなり大きなプロジェクトに新規参入 & 新規機能を開発していくにあたって、以下のような点が難しいと感じました。

  • ドメイン知識不足により、影響範囲が分からない
  • コードベースに対する理解が乏しく、どこにどのような処理が書いてあるか分からない

1点目について、仕様書を読めばある程度は背景がつかめますが、影響範囲については理解するのが難しいです。例えば新規機能に必要な新しいデータをクライアントに送りたい場合、テーブルにカラムを追加するのはいいですが、それに伴う影響範囲をソースコードから全て洗い出すのは至難の技です。

これを解決するために、テストを修正しながら影響範囲を一つ一つ潰していくという作戦をとりました。

細かく分割されたテストを書いている場合、カラムを追加したことでアプリケーションに影響がでる部分についてはテストがちゃんと落ちてくれます。どのように落ちているかを見ながらアプリケーションを直すことによって影響範囲を洗い出すことができました。

開発に慣れてくれば、メインの変更箇所を見ながら他の修正箇所の当たりをつけて見にいくことができると思いますが、開発初期段階ではかなり有効な手だと思います。変更に強いアプリケーションのためのテストはこういう面でも有用ですね 😉

 

2点目について、幸いにも Rails にはスタンダードなディレクトリ構成があるので、大体どこにどのレイヤーのソースコードがあるかは見れば分かります。一方で、例えばたくさんある Model の中でどのような処理が共通部分として切り出されてるか、といったような処理レベルの分離方針についてはパッと見ただけでは把握が難しいです。

これを解決するために、メインフローの処理について一度隅から隅まで目を通すという作戦をとりました。アプリケーションの核となるメインフローの処理については綺麗な処理が書いてると信じて読んだ結果、コードベースに対する理解がかなり深まりました 😎

 

これらの内容をメンターさんと一緒に進めながら開発をすすめ、無事新規機能を最初から最後まで作りきることができました!ここでその内容を話せないのはちょっと残念ですが、実際にリリースされるまで楽しみに待っていようと思っているところです。

 

2. アプリケーションの性能改善 ~ボトルネック発見編~

Rails の大きな特徴として Active Record があります。Rails では Active Record を用いることによって DB 操作を意識することなく Model レイヤーの処理をサクサク書いていくことができます。

一方で Rails アプリケーションで起こりがちな問題として N+1 問題があります。N+1問題の詳しい解説は他に譲りますが、簡単に言うと不要なクエリが大量に発行されてしまう問題です。

f:id:akatsukijunyakimura:20201107062352p:plain

この問題を放置するとリクエストのレイテンシが大きくなり、性能が悪化していきます。見つけ次第駆除したいです。

参加したプロジェクトでは N+1 問題の発見に New Relic を用いていました。New Relic はアプリケーションやデータベースのトランザクション性能をモニタリングできるツールです。

アプリケーションコードのなかで SDK を読み込めば、リクエストごとにどのような SQL が何回呼ばれているかが手に取るように分かります (これはまじですごい)。N+1 問題が発生している箇所は不自然に大量のクエリが発行されていることが見て取れます。

インターン中に行った N+1 問題改善タスクでもこの New Relic を活用し、どのような内容の N+1 問題が発生しているかを理解することができました ✌

 

3. アプリケーションの性能改善 ~実際の性能改善編~

 Rails において、N+1 問題は事前に必要なデータを読み込んでおくことで解決することが多いです。

前述のような不要なクエリを発生させてしまうコードは以下のようなものです。

f:id:akatsukijunyakimura:20201107064802p:plain

Active Record の preload や eager_load を用いて事前に cats をロードし、N+1 問題の発生を解消することができます。

f:id:akatsukijunyakimura:20201107064814p:plain

実際にアプリケーション内部でこのような実装を行い、N+1 問題を解決することができました ✌

 

インターンの感想

今回のインターンは全てオンラインで活動を行いました。全てリモートの環境でチームの人等と気軽に話せるようになるか心配でしたが、ホストチームのみなさんや人事の方々の (かなり) 手厚いサポートのおかげで、ほとんど不自由を感じずにインターンを終えることができました。ありがとうございました!

開発を通じて、Rails のコードに関する考え方やインフラのリソースに関する考え方から、技術面の細かい Tips やスクラムをうまくやっていくための Tips に至るまで本当に様々なことを学ぶことができました。

夏のインターンに参加することを考えている学生さんにはとてもおすすめです。

 

以上活動報告でした。改めて、アカツキのみなさまありがとうございました!