はじめに

こんばんは！ゆうだいです！
あまりにも遅れてしまいすみません

土日とハッカソンのお手伝いに東京まで来ており体力的に全然かけませんでした……。ランニングでもしようかな。

そんなことはさておき、今回の記事は「Streamerioの技術選定どうやってしたの？」です。

ではまず最初にですが、Streamerioってなに？という方は一日目の記事をご覧ください！
Streamerioってどんなゲーム？

また興味を持ってくれた方はこちらも見ていただけると嬉しいです！
同時接続300人に耐える技術！フロント編！

サーバーについてはこちら！
同時接続300人に耐える技術！サーバー編！#1
同時接続300人に耐える技術！サーバー編！#2
DB周りで苦しんだこと！

では今回は短めですが始めていきます！

設計など

今回の開発の流れ(主にサーバ、フロントまわり)を振り返ります。

順番で言うとこうです。

言語決める
kiroに現状想定しているWebフロント、バックエンド、Unityのそれぞれの構成、役割、他に使用するものなどを適当に投げる
でてきた設計書を元にソフト面の開発を進める
今回の要件にあったデプロイ先を検討する
1. お金はかけたくない
2. でもどう考えてもリクエストはだいぶ飛ぶはずなのでそれに耐えるサーバーもしくはスケーリングがしやすいものにする
3. できれば使いやすいもの
完成させる

順に触れます。

言語決める

今回は僕が使いたい & ある程度処理が軽くて早い & 使えそうくらいの観点から偏見で僕がHonoかGoと選択肢を決めました。

そこからメンバーにどれがいい？と聞き、Goに決まった感じです。

こんな感じ

正直どちらも使ったことはなかったのですが、Goは書きやすいと聞いていましたし、HonoもTypeScriptは触ったことあるし、こちらも書きやすいと聞いた気がするから設計さえなんとかすればなんとかなるだろうの気持ちで決めた覚えがあります。

あとハッカソンっていう好きに書いていいイベントで新しい技術に触れなくていつやるんだよみたいな気持ちもありましたし。

今考えると少し無茶だったかなという気持ちもありますが、完成度が高いものができたので問題なかったはずです。

Webフロントに関しては一旦僕しか触らない予定だったので最近触ってたという理由だけでNext.jsに適当に決めました。

kiroに適当に投げる

今回は確かkiroの利用招待が来てすぐのタイミングでこの開発を始めたので使いたい！初っ端の設計はkiroに任せた覚えがあります。

プロンプトが残っていればよかったのですが、消えていたので生まれていたアウトプットだけで振り返っていきます。

出力自体は雑にブランチを切って残してたので見てみてください。

確かゲームの構成、通信フローどうするか、言語どうするか、その他細かいところなどを盛り込んで命令を出した覚えがあります。

調整はそんなにしなかったかな。

個人的にここで使ってみて大分kiroが気に入った覚えがあります。
とくにこのmermaid図がいいですね。

自分の脳内にぼんやりとあったものを形にしてくれたので大分楽でした。

ここから多少ディレクトリ構成あたりの設計を、ガッツリクリーンアーキテクチャは学習コストが高くて嫌だけど債務はきちんと分けつつ使いやすい設計にしたいみたいなことを言った気がします。

こちらを参考に開発を行ってもらったので、最終的なバックエンドの構成もほぼこれと同じようになっています。

でてきた設計書を元にソフト面の開発を進める

ここは特に言うことはないです。

というかGo周りに関してはつよつよの後輩に一旦任せたので話すことがないとも言います。

今回の要件にあったデプロイ先を検討する

はい、ここは大分頭を悩ませました。

自分自身あまりこういうデプロイなどを行った経験が浅かったので何を使えばいいんだとなりながらずっとchatGPTと壁打ちをして決めていきました。

大体作るアプリの具体的な処理は伝えず多少抽象度高めながら以下を伝えて決めた感じです。

コストは抑えたい
Goを使う
HTTPとWebSocket両方使う
スケーリングしたい

ここまでいうとCloud Runかな〜という返答だったので、具体的なやりたいことを伝えつつCloud Runだとどれくらいのリクエストに耐えることができるのかを詳しく聞き出してこれだなとなったので決めた感じです。

またRedis,DBあたりも同じく聞き出して同様に決めました。

完成させる

完成させました。

特にデプロイのタイミングで詰まったところだと、Cloud Runへのデプロイが謎のタイミングで一生止まるせいでできないという部分でした。

これはsupabaseの接続先URLを引っ張ってくるところを間違えていたのが原因でした。

これで動くはずなんだ！といいながらずっと失敗して最終的にメンターさんに助けてもらったので強くならなきゃ……という感じでしたね。

最終的な構成

最終的なサーバー構成はこんな感じになりました。

ハッカソンのときよりも進化してある部分もありますが、だいたいの説明はこちらに書いてあるので興味ある方は覗いてください。

同時接続300人に耐える技術！サーバー編！#1

終わりに

さて、本日は以上となります。

以前の記事でも書いたかもしれませんが、学生の作るプロダクトで秒間◯リクエストに耐えなきゃいけない！なんて考えることはなかなかないのでとても楽しみながら作ることができました。

とてもいい経験だったと思います。

もうすでに遅れているので明日ではなく、本日の記事についてですが、サーバーについて改めて振り返る！という内容だと、既に書いたこと以上の情報がでてこない気がしたのでおやすみにします。

ですので次の記事は「発表を振り返ってみる」になるはずです。

ログなどを分析しつつ技育展のときの記憶を振り返れたなと思っているのでよろしくお願いします。

それでは、いい夜を。