『ポケコロ』サーバー開発はどんな仕事をしているのか
-
2021年11月25日
お疲れ様です。
『ポケコロ』のサーバー開発を担当しているGと申します。
かつて入社する時の面接で
「サーバーの開発がどのような仕事をするか分かりますか？」
という質問を受けた記憶があります。
「クライアントから要請がきた時にデータを返すための実装を行う仕事です」
と答えましたが、その時はサーバー開発の仕事内容をよく理解していませんでした。
昔の私のようにサーバー開発の仕事についてよく知らない、という方も多くいると思うので、今回はサーバー開発は実際にどんな仕事をしているのか紹介してみたいと思います。
その中でも1番開発の比率が高いコンテンツの開発について話したいと思います。
開発全体の流れ
サーバー開発全体の流れはこの図のようになっています。
今回はこの6段階についてお話することで、サーバー開発の仕事について知ってもらえればと思います。
仕様把握&調整
まずは仕様把握と調整の段階です。
主にサーバー開発者がアサインされるこの段階では画面の遷移を示す「遷移図」と、仕様について細かく書かれた「詳細仕様書」が与えられます。
この段階では
- 仕様に不明な点はないか？
- サーバー負荷という点において問題が無い仕様なのか？
- スケジュールに間に合うのか？
を判断します。
仕様に不明な点はないか？
当然のことですが、実装にあたって企画者の意図を把握する事は一番重要です。
例えば材料を3個集めてボタンをタップすると、アイテムが1個完成する仕様があるとします。
この場合材料を6個集めてボタンをタップした場合、1個ずつアイテムが完成するのでしょうか？それとも2個同時にアイテムが完成するのでしょうか？
企画者の意図を十分に反映するには、細かい部分まで仕様を把握する必要があります。
サーバー負荷という点において問題が無い仕様なのか？
ユーザーの進捗によってその場で報酬アイテムを配布する仕様の場合、個人のデータのみを参照すれば良いためサーバーに大きな負荷がかかることはありません。
しかし、もしイベント終了時に進捗に応じて報酬アイテムを配布する仕様がある場合、1つイベントが終わるたびに参照が必要なデータが増えるため、サーバーに負荷がかかります。
このような場合、サーバー開発としては負荷の増加を避けるために
「イベント終了時に進捗具合によって報酬アイテムを配布」
という仕様を
「イベント終了時から2週間以内のログインユーザーに対して、進捗具合に応じた報酬アイテムを配布」
など負荷を避けるために制限を加えるなどの仕様の提案を行います。
スケジュールに間に合うのか？
悲しい事に開発の締め切りが確定している場合に、スケジュールに合わせて仕様を調整してもらう場合があります。
調整する内容は様々ですが、例えば「収集→調合→報酬」という流れの仕様だったものを、「収集→報酬」という流れにしたり、一部の演出をなくすなど、決められた日程に合わせてリリースをするために仕様の調整を行う場合があります。
データ設計
仕様の把握と調整が終わったら、次はデータ設計に移ります。
この段階では、仕様に沿って必要なデータを洗い出し、次にそのデータを「マスターデータ」と「ユーザーデータ」に分けます。
RPC設計
RPCとは”Remote Procedure Call”の略で、簡単に言うとクライアントとサーバーの間で入力とそれに対する出力が決められたルールのようなものです。
例えば自動販売機では人がコーラのボタンを押すと、自動販売機はコーラを出してくれますよね？
同じようにクライアントがイベント情報要請をすると、サーバーはイベント情報を返送する、というルールを作る段階になります。
10周年イベントの場合のRPC定義の例
今回は例として先日行った『ポケコロ』10周年イベントの時に設計したRPC定義を見てみましょう。
--------------------------------------
イベント情報メインRPC
--------------------------------------
-request
イベントNo
-response
イベント名
期間
報酬
進捗情報
......
--------------------------------------
アイテム交換RPC
--------------------------------------
-request
イベントNo
-response
素材アイテム数
完成アイテム数
進捗
......
--------------------------------------
アイテム受け取りRPC
--------------------------------------
-request
イベントNo
報酬No
-response
受け取った報酬情報
......
RPCの設計が終わったらクライアント開発者に情報を共有し、実際の実装に移ります。
実装
実装は主にRPCの入口であるController、ロジックを担当するService、データを担当するRepositoryで分けて実装します。
Controller
/{イベント名}/top
/{イベント名}/reward
のように、url的なパスと受け取るパラメーターの情報をマッピングするところです。
『ポケコロ』ではSpringをそのまま利用するのではなく、独自のシステムでマッピングをしています。
Service
主にRPCのロジックを担当します。
Controllerから受け取ったパラメーラーをもとに、Repositoryから必要なデータを取得し、データの加工などを行い、データを渡せる形にします。
Repository
Repositoryではデータベースにアクセスするためのインターフェースを実装します。
『ポケコロ』では1つのRepositoryは1つのテーブルを担当するように実装しています。
テスト環境反映/QA
実装が終わったらテスト環境へ反映します。
反映後QAチームがQAを行い、バグを発見したら連絡がくるのでバグを修正します。
リリース
QAが終了したらいよいよリリースです。
この段階ではこのような作業を行います。
- データ反映
- 実装反映
- モニタリング
データ反映
『ポケコロ』のデータベースはテスト環境と本番環境で別なので、データを本番環境にも反映する必要があります。
テスト環境で使用したデータについて最終確認を行い、本番環境へ反映します。
実装反映
実装の反映は特定のファイルを入れ替えることで行います。
『ポケコロ』のサーバーは複数台で構成されているので、ファイルを入れ替えたいサーバーのみをサービスから除外して入れ替えを行うことで、サービスを止めずに実装を反映することができます。
反映する際はココネ内部で開発した便利なツールがあるので、ボタンを押すだけで最初から最後までを自動で行ってくれます。
モニタリング
最後はモニタリングです。
リリース後は主にサーバーの負荷、データの不具合、エラーの発生などの監視を行い、そして障害が起こらないように祈ります……。
最後に
今回の記事では説明しきれなかった部分や省略した部分などもありますが、『ポケコロ』におけるサーバーサイドのコンテンツ開発の流れは説明できたと思います。
また次回の機会があればより詳しく説明できればと思います。
開発を家を建てる事に例えると、クライアントは家の外見など見える部分を作る仕事で、サーバーは基礎や設備など見えない部分を作る仕事です。
表からは見えず、地味でつまらないと思うところもありますが、絶対になくてはならないやりがいのある重要な仕事だと思います。
ココネでは一緒に働く仲間を募集中です。
ご興味のある方は、以下の特設サイトをご覧ください。
