アカツキのサーバーサイドインターンに参加しました

初めまして、2021年の9/6 ~ 9/24の3週間、アカツキのサーバーサイドインターンに参加させていただきました、竹下といいます。この記事では、私が取りくんだこと、学んだことについて書かせていただきたいと思います。

自己紹介

慶應義塾大学 総合政策学部の学部3年生で、普段は個人や仲間内、アルバイトなどでWebサービス開発を行っています。使う言語などに強いこだわりがあるわけではないですが、Rustで開発をすることがひそかなマイブームです。 過去には趣味でオレオレWAFを実装したりしていました。

今回取り組んだこと

今回のインターンで私が配属させていただいたプロジェクトは、Ruby on Railsによるゲームのサーバーチームでした。その中で、アップデート後に処理が重くなってしまったエンドポイントについて、速度改善をするというタスクにチャレンジしました。

エンドポイントの役割としては、スマホゲームではおなじみの「ミッション機能(一定の条件をクリアすると報酬が貰える)」の一部です。デイリーミッションやコンプリート系のミッションなどといった、いつのまにか達成しているようなミッションを含めてミッション進捗を確認するために叩かれます。

課題だった点

まず、実際に稼働中のサーバーを監視しているNew Relicのダッシュボードから発生しているトランザクションを見てみました。すると、他がリクエスト当り平均1 ~ 10回程度だったのに対し、一箇所だけ平均90回近く発生しているところがあり、このボトルネックを解消することにしました。

該当部分のソースコードを確認したところ、以下のようなモデルの構成になっていました。

クラス図

該当部分で行っていたこととしては、ユーザーのミッションデータごとに対象クエストを完了した数をカウントして更新するという処理でした。この際にRailsのActive Recordのcountメソッドを使用していたため、ミッションのユーザーデータの数だけカウントクエリが呼びだされてDBアクセスが増えていました。

やったこと

毎度クエリすることを防いであげたかったので、事前に必要なデータをすべて取得しておき、カウントはRubyのEnumerable#countメソッドを使って行う方針で改善を行うことにしました。

元々パラメータをHashで渡してあげるインターフェースが進捗を進めるメソッドに用意されていたので、共通部分で事前取得を実行し、パラメータに事前に取得したデータを流してあげることにしました。

結果

ある手順でAPIを叩き、該当する箇所でレスポンス全体にかかった時間と、DBアクセスにかかった時間を計測し、比較しました。また、ユーザーがミッションをすべて達成した状態についても計測しました。(ユーザーの状態を初期状態から破壊的に遷移させていくため、対象となるミッションの数が変動してしまうことから、前提をそろえるために手順を決めています)

結果は以下の表のようになりました。

計測結果表

苦労した点・学んだこと

ソースコードの読み込み

僕はそんなに多くのゲームを遊ぶ方ではないので、ゲームのデータ処理の内、どんなところをサーバーでやっているのかといったことはあまり想像したことがありませんでしたが、実際に見てみると、特にミッション部分では「クエストを○個クリアしたら〜」「フレンドが○人になったら〜」「他のミッションを○個クリアしたら〜」などのように複雑なデータ処理がされています。更に、ゲームを運用していくにつれてミッションは多様になっていきますから、それにあわせてモデルが増えていくことになります。

関わらせていただいたプロダクトは長年運用されているものでしたので、コード量も多く、把握するので一苦労でした。さらに、一通り実装しきれたと思っていても把握していなかった部分のテストに落ちてしまうということもありました(T_T)

コード量が多く複雑なシステムになっていけばいくほど、そのコードの正常系、異常系の動作を保証するためのテストの役割は大きいなと感じました。大きな価値を提供するプロダクトを作る上では、テストコードをしっかり書けるように勉強しないといけないなと感じました。

高速化と可読性の両立

無駄な処理を省くために処理を共通化させる一方、共通部分にクラス特有の処理がある状態は避けてクラスにさせるようにするということを同時にやらなければなりませんでした。普段の小さなアプリケーションの開発では当り前のようにクラスの処理の責任範囲を意識していましたが、同時に共通化、高速化といった観点が加わるだけでこんなにも難しくなるんだなと感じました。

ユーザー数が多くなるにつれて小さな確率で発生するエラーも広範囲に作用するようになったり、小さな速度の低下が機会損失につながっていくというお話しを伺いました。やはり開発規模が大きくなるとそれだけ同時に考えるべきことが増えるのだなと感じました。

高速化と可読性を両立するのは難しい作業でしたが、決して相反するものではなく、ロジックを整理しながら順序立てて作業することが大事だと感じました。また、意外と解決策はシンプルな方法だったりするので、日々触れている技術は深く知る努力をしたいなと思いました。（特に今回はRubyのビルドイン関数にお世話になりました）

その他、インターンで経験したこと

社員の方とのオンラインランチ・面談

人事の方々やサーバーチームの方々、それから僕の希望で運用の方とオンラインランチの時間をとらせていただきました。趣味の話やチームの過去の話で盛りあがったのは勿論、運用の方とは今まで知らなかった運用の仕事の内容などを中心に、普段は聞けない貴重な話を聞かせていただきました。

また、VP of Engineeringの湯前さんと面談のお時間を頂き、エンジニア組織の改善を通してプロダクトの質を引き上げた過去や、ユーザーを獲得したプロダクトが次に追求するべき価値はなにかといったことを聞かせていただきました。僕自身Webサービスを運営した経験から、成熟したプロダクトが次にどうするべきなのかという問いを持っていたのですが、大きなユーザーを抱えるということは、それだけ小さな取りこぼしもないシステム開発・運用が求められるという考え方を伺い、サービスを運営する上での価値観として大切にしたいなと感じました。

ちなみにですが、しっかり朝から働いたこともあり、お昼にこのような時間を設けていただいたおかげで、久しぶりに一日三食摂りましたw

スクラム開発

スクラム開発という体制では何をするのか、何がいいのかといったことは知識としては知っていましたが、余り規模の大きいプロジェクトに関わった経験がありませんでした。今回は初めてスクラムに入らせていただき、3週間の中でスクラムイベントにも色々と参加させていただきました。

実際にやってみて知識から実践に変った経験がとても学びになりました。また、上述の湯前さんとの面談の際にも、スクラムによってメンバー同士のコミュニケーション量をデザインすることで、エンジニアが開発に集中し、アウトプットを増やすことができたという経験談ベースでのお話を伺い、とても理解が深まりました。

最後に

メンターの方、プロジェクトやチームの皆さん、一緒にお話頂いた方、人事の方々、アカツキのみなさんのお陰で大変多くの学びを得ることができました。 3週間という短い時間ではありましたが、本当にありがとうございました！

Akatsuki Summer Internship 2021 の Go/GCP コースで運用改善を行いました

はじめに

はじめまして、otofune と申します。

9/6 から 9/24 の3週間、株式会社アカツキでプラットフォームエンジニアリングを行うチームでのインターンシップに参加させて頂きました。

aktsk.jp

といっても祝日が2日あり、新型コロナワクチンの摂取が被って副反応で1日休み、さらに社内イベントもあり、実質2週間でした。

その中で、私は GAE/Go 上で動作するサービスについて、運用に関わる以下の成果を出すことができました。

1. API レスポンスのリファクタリング
2. 蓄積されたアクセスログを解析し利用状況を可視化

この記事では関わったサービスについて軽く説明したあと、行った改善について紹介し、終わりに全体を通した感想を書きます。

もくじ

インターンに参加する動機と方針

メンターだった id:takanakahiko と以前からの知り合いで会社の良いところを聞いたことがきっかけに、会社の雰囲気を体験したくなり応募していました。

そのため顔合わせの 1on1 で「レールを敷いてもらうか、自分でやること決めるかだったらどっちがいい?」と聞かれた際に、メンバーにより近い後者にすることを決め、なるべく自発的に動くようにしていました。

ゲーム内仮想通貨管理サービス

ざっくりしたサービス構成

モバイルゲーム開発では決済・石*1管理機能がタイトルに関わらず必要となります。実装するには法的要件を理解し、チート対策やプラットフォームの API 変更についていかなければならないなど大変であるにも関わらず、ゲームの楽しさにはあまり影響しません。

このゲーム開発者からしてみると“面倒くさい”と感じる機能を代わりに提供し、集中してゲーム開発を行えるようにするサービスが「ゲーム内仮想通貨管理サービス」です。

1. API レスポンスのリファクタリング

オンボーディングの一環としてリファクタリングを行いました。緊急ではないが影響範囲の広い変更を行うことでコードベースに慣れるためです。

task4233.hatenablog.com

具体的には7月にインターンしていた id:task4233 さんが作ったキーローテーション API と重複する機能を削除しました。鍵のデータを個別に返せる API が追加されており、これまで関連リソースのレスポンスに同時に含めていた鍵を削除するという内容でした。

レイヤードアーキテクチャでわかりやすく、API の実装を見つけ削除するまでは簡単でした。しかしテストコードに大きく修正が必要で、かつエラーが見つけにくく難航しました。*2

といっても粛々と原因特定を進め、3日ほどでマージまで持っていくことができました。

2. 蓄積されたアクセスログを解析し利用状況を可視化

このサービスはゲームサーバーから使われる関係上、レスポンス速度は速ければ速いほどよく、待たせることはゲームユーザーにとって明確なマイナスになります。
このため利用者であるゲームサーバーの中には、レスポンス速度を問題にしてキャッシュを持っているものもあります。

そういうこともあり遅いらしいことは肌感としてありつつ、現状を把握できておらず実際に問題が存在するのか知る必要がありました。

初日の躓き

先ほどは問題が存在するか知ることを目的と書きましたが、当初は「パフォーマンスに課題感がある、蓄積されているトレースをうまく活用できないか」程度にしかまとまっていませんでした。そこで初日はヒアリングをした後、パフォーマンスを高めることを目的としてトレースの活用法を調べていました。

ただ調べていても納得感がなく、これでいいのか自信が持てませんでした。
知識不足が原因で正しい判断ができていないのではないかと考え、『入門 監視』を読むことを許してもらい、一日インプットに充てることとしました。

当該日の日報 (一部)

『入門 監視』を読んで

この本は具体的なツールには言及しないことで厚くならないようにしながら、原則や考え方を示してくれます。そのときの自分に適した内容でした。

"監視は、質問を投げかけるためにある" （P28）

 "「銀の弾丸はない」この本からこれだけは覚えていてください"（P4）

"計測する必要がありそうな箇所はたくさんありますが … まず監視を追加すべきなのは、ユーザーがあなたのアプリケーションとやり取りをするところです。… アプリケーションの詳細をユーザーは気にしません。" （P29）

これを踏まえて「実際にどう使われていてなにが遅いのか見ることができるようにしてからチューニングしたほうがよい」と目的を考え直すことができました。

方法についても「全体を通してのトレースをまとめる」という方法ではユーザーにとっての問題を知ることができるかは怪しいだろう*3と判断し、ユーザーにとって重要な API を特定しそれに絞ってトレースを見る必要があるのではと考え直しました。
現状のモニタリングダッシュボードでは全体を通したアクセス回数、エラーレートやレイテンシしかわからなかったため、まずはアクセスログを用いて API 毎にそういった指標を取れるようにして実際にどの API が使われていて遅いのか気付けるようにすることを目標にしました。

できたもの

将来のため、加工しやすいフォーマットで統計を出力するシンプルな CLI を作りました。BigQuery に sink された App Engine のログをルート定義ごとにうまく纏め、アクセスカウント、エラーレートやレイテンシ (%tile) を吐くだけの機能を持った CLI です。

appengine-access-log-analyzer

この実装は https://github.com/aktsk/aealanlys で公開しています。

難所

方針が決まってからは、ほとんどパスをルート定義ごとにうまく纏める方法だけが問題でした。
ログの量が少なければローカルで処理してもよかったのですが、本番環境では 20GB を越えていて、なんとかして BigQuery に処理させる必要がありました。

ゲーム内仮想通貨管理サービスは RESTful API になっていて、すなわちパス内にパラメータを持つことがあります。これをまとめるには複雑なマッチングを行わなければいけません。

ただ、BigQuery はコンピューティングが無料なのでいくらめちゃくちゃな処理をしても制約にひっかからない限りは料金に違いはありません。これに注目し RegExp を処理できることを考えたところ「フレームワークのパスマッチに使われる RegExp を転送して文字列置換すればよいのでは?」という発想が思いつき、うまく実装することができました。

よかったこと

まず、感覚に依らず問題が存在するのかをわかるようにすると軌道修正でき、そのためのツールを実装することができたこと。そして実際にアクセスログを解析してみたらそこまで悪くない*4という結果が出たこと。目的を意識して軌道修正を行なったことがよい結果を導いてくれました。

また、自らタスクを決めて遂行できたこと、補助は受けつつ自走して調査を行い方法の提案ができたこと、チームへ逐次進捗を共有し議論しながら進められたこともよかったと感じています。

インターンに参加して

運用改善という、個人では課題になりにくくアルバイトやインターンでは触れにくい領域に触ることができ、非常によい経験になりました。

決済基盤チームでは毎日昼に進捗を共有する会議があり、時間が余れば雑談をする習慣がありました。リモート下で孤独を感じずに要られたこと、受け入れられていることを実感できたのはこのためです。

また、社員の方を指名して話せる機会があったり、丁度 Akatsuki Dev Meetup という社内技術イベントがあったりと、会社の雰囲気であったりオープンな文化を感じることもできました。短期間しかいないインターンという立場からイベントがあるのはどうなんだろう? とすこし思っていましたが、幅広い業務があることや多種多様なバックグラウンドを感じることができ、このタイミングでよかったと今では思っています。

終わりに

総じて楽しく、学びを得ることもできたインターンでした。関わって頂いた皆様には大変お世話になりました。短い間ではありましたが、本当にありがとうございました。

*1:ゲーム内通貨のこと

*2:例えば t.Error が多用されており panic する、$register に入れ子アクセスする際に変換できなかったときのエラーをわかりやすくしたい · Issue #28 · aktsk/atgen · GitHub など

*3:あまり Span を生成しておらずライブラリ、特に google-cloud-go による情報がほぼであったことなどによる

*4:よく使われている API のレイテンシが想像していたより遅くなかった

株式会社アカツキのインターンでお世話になった話

こんにちは。 東京工科大学のコンピュータサイエンス学部というところの3年生をやっております（就職するなら23卒ということになります）。 宮川です。

この度、アカツキのインターンを受けましたのでその記録を残します。 ブログ執筆経験が浅くつたない文章になると思いますがご容赦下さい。

エントリーと選考

アカツキのインターンを知ったのは就活サイトがきっかけです。

プログラミングのインターンを受けたい。でも1day仕事体験とかではなく数週間にわたってやりたい。あとお給料出ると嬉しい。そんな欲張りな条件で探した結果アカツキのインターンに出会いました。 ゲーム開発のインターンということで、私はゲーム開発に興味があるので良さげと思いました。

でもUnityなんだろうな...。私はゲーム制作に興味はあるもののUnityはあまり得意ではないのです。 ですが募集要項を見てみると..... Cocos2d-x & C++！？ 私はそれに一目惚れして、アカツキのインターン選考が非常に厳しいらしいことも知らず、募集人数1人程度の「ヤバいインターン」にダメ元でエントリーしました。

────そして何故か選考に合格してしまったのです。（めちゃくちゃ嬉しかったです。）

やったこと

9月。ついに始まった人生初のインターン。 様々なオリエンテーションに出席しつつ、メンターさんと今後やることを相談しました。 そして最初に出された課題がオンボーディングも兼ねた練習問題です。

練習問題

私の配属されたプロジェクトには、開発者用メニューというものがあります。 各々の開発者の名前が登録されており、開発者が試したい機能を自分の開発者用メニューで試すことができるというものです。 ...言葉で説明するのは難しいですが、開発者の名前が書かれた「扉」がズラっと並んでいて、それぞれの「部屋」で好き勝手に機能を試せるといった感じです。

そこに自分の「扉」と「部屋」を作り、その中に「メインメニューに戻るボタン」を作るというのが今回の練習問題です。

コードを見てみると「アカツキ太郎」さんの部屋がいかにもテンプレートっぽく置いてあったので、安直にコピペして必要な箇所を変更して....。 最初は当たり前のようにやってしまいましたが、これでは駄目ですね。

今回のように簡単な問題ならまだしも、こうやってコピペする癖がついてしまうのは良くない。既存のコードをコピーする時は１行１行理解しながら写す必要があるのです。

じゃあそうしないとどうなるか？コピペして表面上問題なく動作したからといって、別の箇所に影響範囲が出ないとも限らないのです。そして、ただコピペしたコードについて「この関数はなんですか？」と聞かれても答えられないといよいよまずいのです。「おまじないです」なんて言うわけには行きません。

だからコードをちゃんと理解しながら書くことが大事なんですね。至極当然のことですが、私はこんな基礎のことまでできていなかったということです...。 巨大なプロジェクトにcommitするというのはこういうことです。

さて、何だかんだコードが完成し動作確認も済んだのでPRを発行する時が来ました。 git statusしてみると色々なファイルが変更されている。これはIDEのプロジェクトファイルっぽいし必要なんだろう。とりあえず git add -A。 結果は...当然駄目です。addする必要のあるファイルもありますが、ほとんどはaddする必要の無いファイルでした。 そう、大規模なプロジェクトにおいてはどのファイルをサーバーにアップロードするかも見極める必要があるのです。

このように、個人開発では適当にやっていたことでも、細かな配慮をもってやらなければならないので中々大変な作業でした。 ただ、やっとのことでPRが承認されたときの達成感は大きかったです。

クライアント改善課題

ここからがインターンの本番です。 私のインターン課題は「開発メンバーが喜ぶデバッグ機能を開発する」です。 これを開発者用機能の改修というタスクをもって達成します。 クライアント改善というと顧客満足度向上のような響きですが、「サーバークライアントモデル」における「クライアント」というニュアンスです。

メンターさんが事前に改善依頼を集めてくださったので、そこから1つ選び、依頼者にヒアリングを行い、そして実装するという流れです。 私が取り組んだのは、ゲームを効率的にすすめるデバッグ機能の改修でした。 デバッグ機能をONにしてもアプリ再起動によってOFFに戻ってしまうのが不便なので、最初からONにしてほしいという依頼内容です。

まずは依頼者にヒアリングを行い、依頼者の目的（なぜその機能が欲しいのか）を聞き出しました。 これは非常に重要な工程で、依頼者と実装者の間に認識のズレがあると良くない結果を招いてしまいます。 例えば、完成したものを依頼者に見せても「なんかこれじゃない...」といった反応をされてしまったり、「そういう目的なら別のアプローチがあったのに」と後から気づいてしまったり...。 このようなトラブルで手戻りをしないようにするため、依頼者から目的を聞き出すことが重要なのです。

ヒアリングの結果、他の開発メンバー（検証・運用さん等）にも確認を取る必要が出てきました。 そこで、我々のプロジェクトメンバー全員が入っているSlackチャンネルに文章を送ることになりました。 この時はまだ文章作成に2営業日費やすとは思ってもみなかったのです...。

Slackに投稿する前にメンターさんにFBをもらうことになっていたのですが、最初に作成した文章は

• 文字がびっしり
• 用語の表記ゆれがある
• 参考図が無い

という中々ひどい有様でした。 言ってしまえば見るだけで億劫になる活字の塊です。 これでも不足なく、分かりやすく説明しようと頑張ったんですけどね...。

数回のFBを受けてようやく文章と3つの参考図が完成しました。 ここで如何に最初の文章が酷かったのかを認識することになりました。 そして、自分の書く文章の悪い癖も知ることができました。

そう、私は分かりやすくて不足なく書こうとして長ったらしい文章を作ってしまいましたが、真に分かりやすい文章とは「簡潔で」「視覚的に整理されていて」「必要に応じて図で補足する」ようなものだったのです。

そしてついに300人以上のチャンネルにメッセージを投下し、なんとすぐにFBが届きました。 インターン生の私を相手にして下さったことが嬉しかったし、何よりメンターさんでも気づけなかった意見を得ることができて驚きでした。 依頼者のみが得をするのではなく、他のメンバーが損をしてしまうことも考える。 つまり、一人の主観で決めるのではなく他者の意見も取り入れる必要があるということですね。 考えてみればこれも至極当然のことですが、実際一人の意見だけ過信するとかやってしまいそうなので肝に命じておきたいです。

ヒアリング、全体への確認も終わりいよいよ方向性が決まりました。 あとは実装するだけです。

実装は割と簡単でした。 C++の専門知識がある程度要求されたので楽しかったですが、基本的には既存の仕組みを利用するものでした。 あっさりと実装も終わり、PR発行。 一回目のようなトラブルも起きず、素直に承認されました。 大分ここでのGitHubの扱いについても慣れてきていたと思います。

新規機能実装

インターンのメイン課題が終わった後は、一週間ほど別のインターンに行っていました。 祝日というのもあり、アカツキに来るのは久々でした。

メインの課題は達成しましたが、成果発表会の準備をするにはまだ時間が余っていたので、新機能の実装を体験させて頂くことになりました。

当たり前ですが、私はインターン生でプロジェクトに関する知識が浅い為、新しいことをするには多くのキャッチアップが必要になります。 しかし、インターンが始まってからずっとそうでしたが、アカツキの構造化されたドキュメントは非常に便利です。 検索機能を使えば欲しい情報は割とすぐ見つかるし、ビルド待ちの時間などには階層構造をなす項目から興味深い記事を見つけることができます。 このきっちりしたドキュメントは素晴らしいですし、今後の企業研究の際にも基準の一つとして考えたいと思いました。

新規機能の実装はモブプログラミングによって行いました。 これは、調べごとをしながら指示を出す「ナビゲーター」とナビゲーターに従ってコードを打つ「ドライバー」に分かれて共同作業をする手法です。 これは1~複数人のナビゲーターと1人のドライバーで構成されます。

一般的には一定時間でドライバーとナビゲーターを交代するようですが、インターンということでずっと私がドライバーを務めました。 Zoomの画面共有を使用しているとはいえ、ずっと誰かに見られながら作業していることになるので、始終落ち着けませんでした。 しかしモブプログラミングにはその弱点を超える数々の利点がありました。

まず、分からなかったらすぐナビゲーターに聞ける事。これによって、コーディング中にブラウザを開いて検索して...という手間がなくなります。 今回はかなり前からこのプロジェクトにいるベテランの方がナビゲーターをして下さったので、調べるどころか大体即答です。効率がえぐいです。 そしてプログラミング以外のスキルも継承できること。 例えばIDEの知らなかった機能や会社の知識など。 コーディングの片手間に知識が共有できるので便利です。

このように、モブプログラミングにはたくさんの利点がある為、いい加減誰かに見られながらの作業も克服したいなと思いました...。

モブプログラミングはPRの作成においても威力を発揮します。 （この場合はモブワークに該当しそうですね。） PRを作成している最中にコードレビューが大体できてしまうようなものですから、非常に合理的です。 また、大きな事故になりかねないような誤操作も起きにくいので安全とも言えます。

安全に作業できる環境、素晴らしいですよね。

何を得たか

今回のインターンを通して学んだこと、つまりどのようなスキルを入手したかについてまとめさせて頂きます。

コミュニケーションスキル

ヒアリングやSlackでの文章作成、そしてモブプログラミング...。 日常的な会話などに加えて上記を含め様々なコミュニケーションが要求される職業。それがエンジニアでした。 コーディングと同じくらい、もしかしたらコーディング以上に開発現場のコミュニケーションについて知ることができました。

作業を管理するスキル

インターン中は常に別画面でGoogleカレンダーを開きながら作業をしていました。 「〇〇時までにこの作業を終わらせる必要がある」という都合や、そもそも定時というものが存在するので、しっかりと作業を管理する必要がありました。 というかそうしないとやっていけません。

あとこれは私が勝手に始めたことですが行動ログというものを付けてみました。 何時にアレを初めて、何時にコレが終わったという記録を延々付けるだけのものです。 これを作ると何が良いかというと、後々振り返りをする時に役に立ちます。 また副次的にですが、「14:03 〇〇を開始」と打った後は脱線せず作業を遂行できることが多いです。

行動ログを付けていることをメンターさんに言ってみたところ、なんとメンターさんも同じようなものを作っていました。 行動ログと違うところは、一日の始まりにざっくりとした予定を考え、それを遵守できたかどうかも含めて後々振り返りをしているところでした。 私も真似しようとしましたが、如何せんインターンでやることは初めてのことだらけなので作業時間の目処がつかない...。 なので一日の始めにTODOリストを作るに留まりましたが、今後は作業時間の目処を立てることを意識していきたいです。

目的を意識するということ

これは今回のインターンにおいて最も重要な教訓です。 目的を意識することは、あらゆる仕事・作業において役に立ちます。

例えば今回私も行ったヒアリングについて。 ヒアリングで「依頼者は何故これを実現して欲しいのか？」つまり「依頼者の目的は何か？」を追求することで、課題解決に向けて共通の認識を持つことができます。

逆に依頼者の目的をよく聞かずに実装を進めてしまうとどうなってしまうか。 実装した結果「欲しかったのはこれじゃない」と言われてしまい、実装をやり直すという手戻りのコストが掛かってしまう可能性があります。

目的を意識することは最適解に近づく為の非常に有効な手段といえます。

また、目的を考えることは「あれ？今何やってるんだっけ？」と道に迷ってしまった場合にも有効です。 何の目的でこの仕事をしているのかを考えることで、目的が見つかれば作業に集中できますし、あるいは別の方法を検討することも可能です。

このように、「目的を意識すること」は私にとって万能な教訓となりました。 今後も日常的に意識していきたいと思います。

感想

今回のインターンが人生上初となりましたが、アカツキでのインターンが初で本当に良かったです。 エンジニアのインターンということで、プログラミングのスキルも当然身につきましたが、それ以上に身についたのは上に挙げたような「エンジニアに必要なスキル」の数々です。 そしてこれらのスキルの多くはポータブルスキルであり、今後の他のインターンや就活、実際に就職した後でさえ約に立ちます。

昨日メンターさんに「この枠にどのくらいエントリーがあったんですか？」と勇気を出して聞いてみたところ、腰を抜かしました（メンターさんも具体的な数は把握していませんでしたが、恐らく私にとっては信じられない数です）。 私は悪魔のような技術力をもった人材ではありません。 では何故採用してくれたのか聞いたところ、採用側とエントリーした側の「こうなりたい」というビジョンが一致したからと教えて下さいました。

このような理由で採用して下さったことがとても嬉しかったです。 同時に、今後就活をする上でも「私が将来どうなりたいか」というビジョンを大切にしたいと思いました。 これも「目的」ですね。

まとめると、非常に実践的なスキルも身につく、かつ将来を見据えたものの考え方まで身についてしまう、やはり「ヤバいインターン」でした。 毎(営業)日新しい発見ばかりでとっても楽しかったです。

メンターの伊藤さん、そしてインターン生の私を暖かく受け入れて下さったアカツキの皆様、本当に有り難うございました！！

初めてのRuby on Railsでユーザ数が大規模なゲームのAPIを高速化した話

自己紹介

はじめまして、大阪工業大学 情報科学部  情報知能学科  3年 伊地知翔也と申します。  
普段は、チームや個人でWEBアプリ開発をしたり画像処理についての研究をしています。  
このサマーインターンに参加する前までは、
私のサーバサイドで経験のある言語は、

• Golang
• Python(Flask)

しかありませんでした。
しかしながら、ゲームのサーバサイドに携わってみたいという想いから経験のないRuby on Railsを使用する本インターンを志望しました。

事前準備

事前の準備として、Ruby on Railsのチュートリアルを概ね完走しました。

といっても、他の言語でWEB開発の経験あったので、この機能を実現するにはこのメソッドを使えば良いなど、飛ばし飛ばし大まかに学び、準備していました。

インターンの内容

今回、高速化に取り組んだゲームは八月のシンデレラナインというゲームです。

今回取り組んだのは主に２つで、

• ゲームクライアント側でとある情報の表示、非表示を制御できるようにする

• とあるAPIの高速化

を行いました。

今回は、高速化の方を取り上げたいと思います。

高速化前の状況把握

ハチナイのイベントやストーリ選択する際に叩かれる重要なエンドポイントが遅いので高速化しましょうというのが課題です。

前任者の調査結果と私の調査により以下２つの問題があることが判明しました。

1. とあるデータの参照において、N＋1問題が発生している。
2. キャッシュサーバとの通信回数が多すぎる。

まず、N＋1の解決だ！

高速化前では、N＋1問題という、Ruby on Railsでやってしまいがちな問題が発生していました。しかしながら、どうやら、何かミスでN＋1が起きないように処理できる機構はありましたが、それを利用せずに逐次処理で実装されていました。よって、その機構を利用するよう修正することでこの問題は解消しました。

結果、

N＋1の解消結果

こんな感じで、1.1倍の高速化を達成しました。

表の結果は私の開発環境の値であり、本番サーバの速度ではありません。ただし、計算量の評価を行うためには有用です。（倍率で見れば良い）

ところで N+1問題って何？

N+1問題は単純で、とあるユーザIDがあったとして、ユーザに関するデータを

A,B,C,Dというデータの集団（テーブル）に格納するデータベースがあったとします。

各データの集団は

Aのデータの集団では、{ユーザID,何かの情報}が複数格納されています。

B,C,Dも同じように、{ユーザID,何かの情報}が複数格納されていて、

A,B,C,Dには各々別々のデータが入っています。

データベースは一般にアプリケーションサーバからは独立した別のコンピュータで動作しているので、アプリケーションサーバからデータベースに対して検索命令を行う必要があります。

そうしたときに、ユーザIDだけで、ABCDの各データの集団をまとめ、情報を処理したいときが多々あります。

普通、こうした時は、AのユーザID、BのユーザID、CのユーザID、DのユーザIDで情報を結合して、一挙にして結果を得ますが、高速化前ではこういう仕様にはなっておらず、AからとあるユーザIDの検索を行って、結果を処理し、BからとあるユーザIDの検索、結果の処理....という逐次処理が行われていました。

この逐次処理方式では、一回ごとにデータベースサーバに検索するよう命令するため、

• データベースとの通信処理
• データベースの内部処理（SQL命令解釈処理など）

がA,B,C,Dなどのデータ集団の数回=N回行われることとなり、低速の原因となります。

また、逆の場合（ユーザIDがたくさんあって、Aというデータ集団に対してユーザIDごとに検索命令することなど）もあります。

この問題を一般にN＋1問題と呼んでいます。

インターン選考ではここが主に聞かれるので注意してください、、、これから受ける方。

これらをA,B ,C,Dに対して、一括で検索するように処理を変えることで対策できます。

また、A,B,C,Dの全データを取得し、データベースサーバではなくて、アプリケーションサーバ側で検索することでも解決できます。（メモリを圧迫する問題がありますが）

キャッシュサーバへの問い合わせが多い問題を解消

これはストーリごとの情報をキャッシュサーバに格納していたためです。

ストーリは何十個もあるので、ストーリごとにキャッシュサーバへの問い合わせを行い、逐次処理を行うため、上記のN＋1問題に似ている状況が発生します。

解決は簡単で、

1. 一気に複数のストーリ情報を受け取るよう問い合わせ行う
2. ストーリを複数に束ねて、情報の格納、問い合わせを行う

方法は２つありますが、結果的に実験してよかった後者を選択し、実装を行いました。

後者の実装方法のイメージ

最終的な速度の計測結果

上のN＋1問題の解決とキャッシュサーバ問い合わせ問題の解決を行った実験結果を下記に示します。

最終的な高速化の成果

最終的に1.3倍の高速化を達成しました。

この実装を適用することにより、

• 各アプリケーションサーバ、データベースサーバ、キャッシュサーバの負荷が減少しレスポンスタイムが高速になる
• さまざまなリソース消費量（メモリ、ネットワーク、CPUなど）が減少する。

ことが期待されます。

インターンの感想など

私は今まで趣味でサーバを勉強していたので、業務に携わるのは初めてで、少々不安もあったのですが、メンターの方にどうしてもわからないところがあればビデオ通話で質問するなど親切にしていただき、なんとかこれらの成果を出すことができました。

圧倒的成長...!!!

このゲームの開発プロジェクトのチームの方々にも暖かく見守っていただき、コードのチェック（レビュー）していただくことで、圧倒的成長することができました。

そして、レビューに対して、自分の意見を述べて、レビューした方とコードに関する議論を交わせたことは生涯の糧になると考えています。

人生観を変えてくれたサマーインターン

業務でプログラムを書きチームに貢献するという貴重な体験は非常に面白くキャリア観、人生観を揺るがすほどでした。

最後に

メンターさん並びにハチナイ開発プロジェクトの皆様、人事の方々、そのほか私に関わってくださった皆様、誠に感謝申し上げます。

まだインターンに参加していない方は、ぜひインターンに参加してみてください！

きっと人生を変える経験ができると思います。

ユーザー数が大規模なゲームで負荷試験と改善をした話

はじめまして、7月5日から7月30日までアカツキのサーバーサイドでインターンをさせていただいた光枝と申します。 本記事では私が今回のインターンで取り組んだことについて共有させていただきます。

自己紹介

神戸大学理学部の学部3年生です。 普段は主にWebアプリケーションの開発をやっていて、サーバーは Ruby on Rails、フロントは React/Next (TypeScript) を書くことが多いです。 最近は Go や Kubernetes の勉強などもしています。

インターンの題材

今回のインターンで取り組んだ題材は「負荷試験」です。

私が携わらせていただいたサービスはユーザー数が非常に多いゲームでイベントや新しいガチャが実装された際にはサーバーにかなりの負荷がかかります。

そんな中で当ゲームはメジャーバージョンアップを控えています。 その際に

• 今までの機能が重くなっていないか
• 新機能が重くないか

を検証する必要があり、そのタスクにアサインいただきました。

検証方法

検証にはAWS上に構築した本番環境の数十分の1スケール(以後stress環境と呼びます)を使用しました。 手順は以下の通りです。

1. シナリオの準備

負荷試験には LOCUST という負荷試験ツールを使用しました。 LOCUST は locustfile.py というファイルにシナリオを書くことで、その通りに負荷をかけてくれるツールです。 (他にもアクセスするユーザー数や Hatch rate を設定し、結果を確認するためのGUIを提供しています。)

シナリオは例えば

ログイン → お知らせ確認 → ログインボーナス取得 → ...

のようにユーザーの動きを再現するように、各APIを順番に叩く処理を記述します。

バージョンアップに際して今回着目した新APIを叩く処理をシナリオに追記しました。 (ここではそのエンドポイントを POST /hoge として置きます。)

2. ローカル環境での実行

まず新バージョンがすでに動いている環境のデータベースをコピーしてきて、LOCUST をローカルで実行します。 ここで失敗し続けているAPIがないか確認します。

(例えば特定のAPIが失敗していた場合、そこで処理が止まってしまい想定していた負荷をかけることができなくなったり、その後に続く処理が実行されなくなってしまうのでここで確認する必要があります。)

3. AWS の stress環境に反映して実行

手元で確認が取れたら実際に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)に保存されています。

これらのデータをすべて取得してくる必要があったため対策がない場合は

• 1 ユーザーあたり N1 個の Model1 と関連
• Model1 は N2 個の Model2・N3 個の Model3 と関連
• Model3 は N4 個の Model4 と関連

としたとき合計で

N1 × (N2 + N3 + N4) 回

のSQLクエリを発行することになります。(ただし N1 個の Model1 はすでに取得済みとします。)

これが原因で POST /hoge は非常に重くなっていました。

修正に当たっての問題 その1

本サービスのサーバーサイドは 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 を回避させることができます。

修正に当たっての問題 その2

全データの取得はこれで問題ありませんでしたが、それでも 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週間本当にお世話になりました。ありがとうございました！！！