サーバーサイドエンジニア 1年目の「サーバー」ってこうなっているのか

はじめに

皆さんこんにちは。
サーバーサイドエンジニアのFです。

自分は20卒として新卒入社し、研修の後、サーバーサイドエンジニアとして配属になりました。

新卒としては1年目ですが、サーバーサイドの業務に実際にあたってからは半年ほどになります。現在は、とあるゲーム開発プロジェクトの一員として働いています。

「ゲームをつくってる」と言えば、イメージするのはキャラを動かすプログラムとか、かっこいいバトルエフェクトを想像する人も多いと思います。

サーバー。。。サーバーサイドね、うんうん。
......サーバーって何？？なんか難しそうなことしてそう.....

......なんて、サーバーサイドエンジニアがアプリゲーム開発する上でどんなことをしているのか、イメージがつかない人も多いのかなと思います。

自分自身、サーバーサイドに未経験で入った身として、「こうなっているのか」と思うことがありました。

ということで今回は、サーバーサイドエンジニア1年目の「サーバー」ってこうなっているのかということについて書いていきたいと思います。

一口にサーバーサイドといっても、開発する内容や会社によっても違う部分はあると思います。今回はどこでも共通していそうな基本的な話を、実際にありそうなゲームの通信を例にして、できるだけ簡単に説明してみようと思います。

業界に興味があるけど、サーバーサイドは何も知らないという人が
「こういうことしてるのね」
と思ってもらえるような話をしていければいいなと思っています。

アプリゲームの開発・運営に興味のある人、サーバーサイドが気になっている人に是非見ていただければなと思います。

こうなっているのか。通信。

みなさんがよくやっているアプリゲームがあれば思い浮かべてみてください。

タイトルを開いてホーム画面に移動、そして所持キャラ一覧を開く。
こういう流れはどのジャンルにもありそうです。

所持キャラ一覧とか眺めたりするの楽しいですよね。

所持キャラ一覧を見る→キャラを選ぶ→（アイテム消費して）育成する

こんな部分で起こる通信を例にしていきたいと思います。

▼所持キャラ一覧をみる

▼キャラを選んで育成する

まずキャラ一覧をみたいときなのですが、

所持キャラのデータってアプリの中には存在しません。

じゃあどこにあるかというと、サーバーにあります。

だから、サーバーからデータをもらってきます。

通信が起こるタイミングはこんな感じです。

▼ 所持キャラ一覧のデータをもらうときの通信

「一覧」ボタンを押して、所持キャラのデータをサーバーと通信してもらってきて、それを表示します。

キャラ育成のほうもみてみましょう。

▼ キャラを育成するときの通信

キャラのデータがアプリの中にはないので、サーバーの中にあるデータを書き換えます。結果もみたいので、結果のデータももらって表示します。

「〇〇したい」（要求） ​
   ↓
「データを探してくる/なにかを書き換える」（処理）
   ↓
「しました（どうぞ）」（応答）

これが通信の基本形です。

この要求と応答のやり取り・そして処理の内容をサーバーエンジニアが設計・実装します。

「よくあるwebページみたいだな」と自分は思いました。

このnoteが開かれているブラウザも、「URLを入力したら」・「アプリの記事をクリックしたら」という要求に対してサーバーが処理をし、求めたデータが返されてページが表示されます。

このnoteに「いいね」したら、いいねの数がカウントされます。（やってみよう！）

このようなweb上のデータのやりとりをする方式はHTTP通信と呼ばれています。IT系の業界に興味がある人は聞いたことがあるのではないでしょうか。

聞く人が聞けば当たり前のことかもしれませんが、「スマホアプリもHTTP通信なんだな〜」ということが最初の発見です。

結構単純な仕組みだと思いませんか？

今後は英語にしてかっこよく呼ばせてください。
要求は「リクエスト」、応答は「レスポンス」って呼んでいきます。

こうなっているのか。API

通信についてもうちょっと深掘りします。(APIはこの後出てきます！)

先ほど、「所持キャラデータをもらってくる」と言いましたが、知らない人のデータをもらってきてもしょうがないので、「自分の」という情報をつけてデータをリクエストします。

あとはユーザーデータのあるサーバーから「自分の」という情報を頼りにデータを探してきて、探してきた情報をレスポンスとして返します。

▼ キャラ一覧取得のリクエスト・レスポンス

キャラの育成はもうちょっと複雑です。

育成する自分のキャラの情報（誰を育成するかわからないので）をリクエストにします。もし、アイテムを消費して育成をするなら、アイテムの情報も必要ですね。自分の持っているアイテムの個数を減らし、自分のキャラの能力をアップして、その結果をレスポンスとして返します。

▼ キャラ育成（アイテムも消費する）のリクエスト・レスポンス

２種類の通信ができました。

それぞれをキャラ取得APIとか、キャラ育成APIとか呼びます。

APIというのは、英語で「Application Programming Interface」の略で、google翻訳で訳すと「アプリケーションプログラミングインターフェイス」です（......あれ？）

英語の意味としては、「Interface」が繋ぎ目という意味なので、「アプリとの繋ぎ目になるプログラム」という意味になるかなと思います。

アプリが欲しい情報をAPIというものが間に入ってサーバーからとってきてくれる、ということです。

先ほど、「知らない人のデータがきてもしょうがない」と述べましたが、それを意味のあるものにするためにリクエストに「自分の」という情報を含めました。

そして、所持キャラの情報が欲しければそれを丸ごともらえるようにリクエストに含めました。

これが育成であれば、「自分の」、「どのキャラ」、「使うアイテム」をリクエストして、そのキャラのレベルやアイテムを持っている数を変えてもらって、新しくなった情報をレスポンスに含めてもらい、アプリで見せます。

こうして、やって欲しい処理ごとにリクエストとレスポンスのルールが決めたり、処理の内容を考えるのがAPIの設計であり、そのルールに沿って決まった処理をしてくれるプログラムがAPIというわけです。

このAPIを実行する場所がAPIサーバーと呼ばれる場所です。

▼ アプリとの繋ぎ目になるAPIとAPIサーバー

※ リアルタイム対戦も？

相手のリアルタイムな反応が反映される対戦などのコンテンツもこうなっているかというと、これはちょっと違って、APIサーバーとは別のサーバーをたてて専用のリアルタイムの処理を扱います。
今回はこれについては話しま（せま）せん！ごめんなさい！

こうなっているのか。サーバー

やっと「サーバー」という単語がでてきました。

サーバーはデータを保存したり、プログラムを実行する場所です。

先ほど紹介したAPIサーバーは「APIを実行する」サーバーです。
皆さんが遊んでいるスマホアプリと直接やりとりをしてくれます。

実は、先ほどの通信に関わっているサーバーはAPIサーバーだけではありません。他にも別の種類のサーバーが関わっています。

キャラ育成APIをみてみましょう。

キャラ育成APIでは「自分の」情報を元にキャラの情報を変更します。

こういった「ユーザーごとのセーブデータを管理する」サーバーがあります。

セーブデータを保持、管理しているものをデータベースというので、これをユーザーデータベース(ユーザーDB)と言い、この機能を備えているサーバーがユーザーデータベースサーバーです（そのまんまですね）

▼ キャラ育成APIのときのユーザーDB

データベースサーバーで、データの保存と、書き換え処理をします。

APIサーバーの中にデータが保存されているわけではなかったんですね。

APIサーバーはデータベースから情報をもらって、それがどうなるか（レベルが上がるとか、アイテムの個数が変わるとか）の結果をユーザーDBに保存してもらうのです。

APIサーバーは計算担当、ユーザーDBは覚えておく/覚え直す専門ということです。

APIに計算してもらうためには、育成に使用したアイテムにどれだけの効果があるか、という情報が必要になります。

ちなみにこのようなルールに関わるデータもアプリには入っていないことが多いです。

このような「ルールのデータを持っている」サーバーがあります。

用語で、ルールのデータことをマスターデータと言うので、こちらはマスターデータベース（マスターDB）と言います。この機能を備えたサーバーはマスターデータベースサーバーと言います（やっぱりまんまですね）

APIが計算をするとき、アイテムAにどれだけの育成効果があるのか、という情報をこの場所にから取得していたわけです。

▼ キャラ育成APIのときのマスターDB

この図をみるに、APIサーバーはマスターDBとユーザーDBを2つに接続しながら、アプリに情報を返している役割をしていますね。

何故サーバーの種類を分けるんでしょうか？

これはそれぞれのサーバーが行うことの特性がちがうので、それぞれの役割に特化させているためです。

データを保存している場所と、APIを実行するサーバーはかなり違いがあるように見えます。

ユーザーDBとマスターDBなんて、データをとってくるという意味では同じかもしれませんが、データの特性が違います。

ユーザーデータは、それぞれのユーザーが持っているセーブデータなので、そのデータ数も膨大で、かつたくさん書き換わる可能性があります。

100万人がこのゲームをやっていたら、キャラAのデータはユーザーごとに100万存在することになります。キャラB,C.....と増えるだけで管理するデータが100万単位で増えるんです。これも当たり前だけど、ちょっとびっくりです。

マスターデータはルールであるため、アプリの操作で書き換えが起きないデータですが、アイテムの効果といった1つデータを、たくさんのユーザーが使うことになります。

ちょっとサーバーの特性ついてまとめておきましょう。

ユーザーDBサーバー
- データ数がものすごく大きくなりやすい
- 頻繁に書き換わるデータ
マスターDBサーバー
- 同じデータに対するアクセスが集中しやすい
-  アプリ側で書き換えが起きることはない
APIサーバー
- アプリ側と他サーバーとの通信・演算処理をする

ここでは話しきれませんが、ユーザーDBもマスターDBもデータの特性にあわせて、データのやりとりの仕方や保存の仕方を変えて特化させています。

そして、APIサーバーは直接データを持っているのではなく、それぞれのデータベースから情報をとってきて、書き換えて保存させたり、アプリと通信する仕事に特化しているのです。

最後に裏キャラ？のキャッシュサーバーを紹介します。

キャッシュサーバーは「データを一時的に保持しておくサーバー」です。

つまりこのサーバーもデータをもっていて、APIサーバーがデータを取りに来るわけなのですが、マスターDBやユーザーDBと何が違うのでしょうか。

マスターDBやユーザーDBは、ゲームのために必要なデータが全て揃っている場所です。なので、漏れなく、大量のデータがおいてあります。

そのため、そのなかのデータを使おうとすると、ものすごくたくさんのデータの中から探す必要があり、これはコンピューターでも大変です。

それに対して、「一時的な」データを保存するキャッシュサーバーは、「一度使ったことのあるデータ」など次も使いたくなりそうなデータを持っておきます。つまり全部持っているというわけではありません。

そして、ちょっとしたデータなら通常のDBを使うより速くデータがとってこれるようになっています。理屈としては、これまでのデータベースが丁寧に種類を分けてある引き出しだとすると、キャッシュにあるデータはよく使うデータだけ箱にほうりこんであるようになっていて、引き出しから探し始めるよりはやいだろう、ということです。

「一時的な」という仕様上、ほかのDBと違って、全部のデータを保持する必要がなかったり、最悪データがなくなっても良いように作られているかわりに、速さに特化できているのです。

▼ キャッシュからデータを取得するAPIサーバー

値が書き換わらないマスターDBと相性がよく、一度マスタからとってきたデータをキャッシュにおいて、次はそこからとってくる、ということができるようになります。（画像の④以降をせずに済みます。）また、「一時的な」データは、ゲームの中断データなどの、データベースで保存しなくてもよいデータを扱う際にも使うことができます。

さらにおまけ話:「APIサーバーはデータ持てないの？」
「APIサーバーではデータは持たずに〜」、という話をしました。
嘘です。APIサーバーでもキャッシュデータを持ったりできます。
APIサーバーはPHPなどのプログラムが動いている場所なので、言語の機能としてキャッシュ機能があればそれを使うことができます。
実は、DBの機能をもたせることもできるけど......それはまた別のお話。
（嘘というより、話がややこしくなるので省略してました。そんな箇所、きっとたくさんあります）

4種類のサーバーについて説明しました。

APIサーバーではアプリ通信と処理をし、ユーザー・マスター・キャッシュとそれぞれの得意なデータの管理に特化したサーバーと連携をしていた、というのがアプリゲームのサーバーでした。

アプリゲームの、なんて言いましたが、ゲームに限らず、サーバーはこのように複数の機能を持つサーバーが連携して成っていると思います。

まとめ

今回はサーバーサイドについてよく知らない方にもサーバーサイドの仕事をイメージしていただくため、サーバーとAPIに絞りつつ、「サーバーとはこうなっているのか。」という自分の納得に沿って説明をしてみました。

APIという通信から始まって、その裏側にある4種類のサーバーの話を扱っていきましたが、それぞれの特性や仕組みについて、なんとなく理解いただけましたでしょうか？

サーバーにデータを保存することで、アプリでデータを持つ必要がなくなっって容量が軽くなったり、アプリがなくなってもサーバーでデータを持っているので引継ぎができたりします。

また、サーバーの通信やデータを監視することで、内部のデータを変えたりズルをしようとするユーザーに対して対策をとったりもできます。（特に課金があるゲームではユーザーが公平でないと成り立たないですよね...!!）

こういったサーバーと、APIの設計と実装を行うのがサーバーサイドエンジニアの主な仕事です。

ユーザーDBやマスターDBのデータの保存の仕方について、今回は詳しく話すことができませんでしたが、どうすれば効率的にデータが取れるか、管理しやすいか、ゲーム内での使われ方を考慮して決めています。

ゲームの目に見える部分を作っているクライアントサイドと違って、サーバーサイドはその裏側のデータ通信の仕組みや、サーバーの構造を作ります。

それはもうたくさんのデータを扱うので、効率化や負荷については人一倍に気をつかっています。もしこれを怠れば、たくさんの人がゲームを遊んだときに、サーバーに負担がかかって、データをとってくることができなくなってしまいます。

ゲームが正常に動いている裏には、サーバーサイドエンジニアの苦労や努力が隠れているのです。

サーバーについても、まだまだ語りたいないこともありますし、サーバーの仕事はまだまだあります。

またいつか記事を書かせていただくことがあれば、そういった話題について触れていければと思っております。

サーバーサイドって関わりがなければどんなことをしているのか、理解をすすめるのもちょっと難しいのでは、と思っています。この記事が誰かのサーバーエンジニアの世界の理解の助けになったら嬉しいです。

とても長い記事になってしまいましたが、最後まで読んでいただき、ありがとうございました。