目次
アピリッツ コンテンツデザイン部の金井と申します。今回はソーシャルゲームサーバーエンジニアの業務内容を紹介していきます。
端的に言えば？
ゲームを作っているエンジニアなのに、グラフィックやサウンドを作る事も、それを動かすようにプログラムを組む事もなく、かと言ってそれを生かしてユーザーを楽しませるような企画を考える事もせず、ひたすらに文字だけと睨めっこしている悲しい部門です。
はい。そうです。
ゲーム制作をしているのに、その面白さを作り上げる事には余り関わらない部門です。
自主ゲーム制作をした事があるならば、
ベジエ曲線だとか三角関数だとかを使って弾幕を生成したり、
四元数を使って三次元空間で回転操作をしたり、
円と円の距離を計算して当たり判定を実装したり、
60fpsで都度画面をクリアして描写しなおしたり、
だとかあると思いますが、そういう事も全くしません。高校以降の数学を使う事もほぼほぼ無いかと思います。
しかしながら、ソーシャルゲームの世界をsocial……社会的な、他者と競いあったりコミュニケーションをしたりするゲームとして成り立たせるのには必須の部門であり、
また、その世界を(きっと後に来る億単位の損害賠償の請求と共に)終わらせる力と権限を持っている唯一の部門でもあります。
TRPGのゲームマスターと言ったら多少語弊があるでしょうが、それに近いところに属する業務を行なっていると言って良いと思います。
具体的に言えば？
ソーシャルゲームのサーバーアプリケーションの開発、運用とそれを構築するインフラストラクチャーを構築、運用しています。
……。これだけ言われても良く分からないと思いますので、もう少し詳しく。
サーバーとは？
ユーザーデータを一括管理したり、ユーザー間のマルチプレイの同期などをしているものです。
ソーシャルゲームはインターネットに繋がっていなければプレイ出来ませんし、そうでなくても電波の悪い状況にいると一々通信に何秒も掛かったりして、快適にプレイ出来なくなったりしますが、そもそも何故そうする必要があるのかと問われれば、例を挙げると以下のようになります。
- スマホの機種変更をした際にソーシャルゲームのユーザーを引き継げるのは、スマホそのものにこれまでガチャでウン万円を掛けて獲得したカードや装備が保存されているのではなく、サーバーでそのユーザーを構成するデータを一括管理しているからです(この機能を悪用してアカウント売買とかする輩も居るけれど……)。
- ランキングイベントなどで他人のスコアを参照したり、競い合えるのは、サーバーで全ユーザーのスコアを管理しているからです。
また、チート対策が出来ていなければ、チート野郎による不正なスコアに誰も追いつけなくなってしまいます。 - ランキング機能の他にも、ギルド機能やマルチ機能もサーバーがなければできません。
要するにサーバーは、
- 見知らぬ誰かと競ったり、共に遊んだりするsocialな機能の為に必要不可欠なものであり
- 時にユーザーの不正を暴いてゲームの健全さを担保し、スマホを機種変更した時にも続きからプレイ出来るようにしたりもする
為のものです。
かなりざっくりとですが。
世界を終わらせる権限と力を持っているというのも、ゲームを構成するマスタデータ、ユーザーデータを一元管理しているサーバーにアクセスする権限を持ち、且つそれを好き放題弄ったり消し去ったり出来る技能を持っている、という事だったりします。
サーバーを構築するインフラストラクチャーとは？
サーバーもコンピュータです。それもキーボードやマウス、ディスプレイなんてものがついていない、所謂パソコンとは別ものを使って、全ユーザーのデータを管理します(小さいアプリケーションなら、パソコンでも十分だったりするけど)。
しかし、サーバーも一台だけで全てのユーザーを捌ける訳じゃありません。ユーザーからのアクセスに応じて不正をチェックしたり、ガチャの結果を返したり、それをデータとして保存するのにも、そんな全てに対して時間が僅かずつ掛かりますし、そうして遊ぶユーザーは1日に10万人以上にも及ぶ事があります。
サーバー1台でどれだけのユーザーを捌けるのか。想定する同時接続数はどれだけなのか。
また、ユーザーデータはどれだけの規模になるのか。
その想定の分だけの各種サーバーを用意して処理の負荷を適切に分散させ、その全てでユーザーに快適で健全なプレイを邪魔しないように、正しいデータを迅速に返さなければいけません。
そこあたりの管理は、サーバーエンジニアとは別にインフラエンジニアと分けて担当する事も多いと思いますが、サーバーとインフラはとにかく密接に紐付いていますので、分けないところも結構あるのではないかと思います。
実際、自分もサーバーとインフラの両方の開発、運用を担当していますし(サーバー寄りではありますが)。
因みに、こちらでも世界を終わらせる権限と力を持っています。
サーバーを構成するインフラストラクチャーそのものを好きに操作する権限を持ち、それを好き放題弄ったり消し去ったり出来る技能を持っている、という事です。
サーバーを好き放題する力が、建物の中でバットを振り回すのに比べたら、インフラストラクチャーそのものを好き放題する力は、建物そのものを重機でぶち壊す力に等しいです。
まあ、もし本当にやったら、生涯掛けても払いきれないレベルの損害賠償を突きつけられると思いますし、そんな力を持てるからこそ、人としての信用がより一層必要である部門であるとも言えます。
纏めると
ソーシャルゲームのサーバーアプリケーションの開発、運用とそれを構築するインフラストラクチャーを構築、運用しています。
と言うのは、
ソーシャルゲームのsocialな部分を開発、運用しています。
と、言い換えられるのではないでしょうか。
それでどういう業務？
大まかに分けてしまえば、
- サーバーアプリケーションの開発、運用
- サーバーアプリケーションを構成するインフラストラクチャーの構築、運用
になってきます。
それぞれの開発、運用に対して説明していこうと思います。
サーバーアプリケーション開発、運用
端的に言えば、プログラムを書いて、ゲームアプリケーションとの意思疎通をし、ユーザーデータの管理をするアプリケーションを作成します。
そして冒頭にも書いた通り、ひたすらに文字だけと睨めっこしています。
ガチャで最高レアのキャラが出てきた時のようなド派手な演出が出てきたり、
様々な種類のノーツが秒間10を超えるペースで降ってきたり、
ギルドで格好良いデザインで動きまくるレイドボスに複数人で討伐しにいったり、
箱庭でキャラを好き勝手に弄ったりしている間も、
そんなクライアントがサーバーと通信するのは文字だけです。
ゲーム内で使う為のアセット(要するに絵とか3Dモデルとか全部ひっくるめた素材)もサーバーには置いてあったりしますが、サーバーとしてそれを使うのはゲームアプリケーションに送るだけで、それをサーバーの中で見たりする事は基本ありません。
強いてQAチェックの為に管理画面で別に確認出来るようにするくらいで。
基本的にやる事は、ゲームアプリケーションからこういう事したい、と通信が飛んできた時に、
- 通信してきたユーザーを特定し
- その要求が正しいものかを確認し
- 必要なデータを更新し
- クライアントにデータを返す
という事です。
そしてそれら全ては文字…プログラムで完結します。
ゲームアプリケーションを開発する場合には、概ね入力はユーザーの操作で、そこからプログラムを書く事によって演出という出力を達成していく、という形が多いでしょうが、
サーバーアプリケーションを開発する場合には、入力はゲームアプリケーションからの通信(文字)で、そこからプログラムを書く事によって達成される出力もゲームアプリケーションへの通信(文字)になります。
サーバー内では絵的な演出など何一つとして必要ないのです。
ゲーム作ってるのにつまらない現場だなあ、とか思うかもしれませんが、しかし。
サーバーは、全てのユーザーデータを管理している事や、それを操作出来る唯一の場所です。
ゲームアプリケーションはこうしたいと要求を飛ばしてくるだけで、実際のデータを操作する事も出来ません。
なのでここが疎かになると、ゲームアプリケーションが疎かになるよりもかなり悲惨な事が起きます。
例えば、
- 育成をする際に素材が減らず、無限に育成出来てしまう
- クエスト終了時に二重にリクエストを送る事で報酬を倍獲得する事が出来る
- レイドボスのHPを不正に0まで持っていけてしまう
- ゲームが正常に進行出来なくなる
- 新たに機能を拡張しようとした時に強い制限が生じてしまう
等々……。
そして、実際に書くプログラムに関してですが、
高校以降の数学を使う事も殆ど無いと前述しましたが、その代わりに他の部門よりもスマートさが強く要求されます。
数学で例えて言うと、問題自体の難易度はそう高くないが、綺麗に解く事を要求される、と言ったような感じでしょうか。
例を挙げると、
- 正常に動作する事は勿論の事、
- 起こり得る全ての状況に想定が出来ているか、
- 新しく機能を追加したいとなった時に問題が発生しないか、拡張性は十分に取れているか
- 万一何か起きた時にそのバグを追いやすい形になっているか
と言うような多岐に渡る事柄を考慮出来ていなければいけません。
再三書きますが、ユーザーの実データを取り扱う唯一の部門となりますので、かなーり慎重になる必要があります(まあ、それでも本番まで行ったミスは結構あるんですけどね！)。
舞台裏で大道具を管理している、と言うのとも似ているかもしれません。
そしてまた、上記の為には仕様に噛み付く事もあったりします。
ユーザーを楽しませるような企画を考える事はありませんが、その企画に異議を唱える事はあると言う事ですね。なんて嫌味な部門なんだ……。
まあ、言ってしまえば、ランダムな要因が多過ぎてQA(品質保証……本番リリースする前にテストする事と思って貰えれば大体合ってる)するのに莫大な時間が掛かりそうな仕様だとか、既存の実装を大きく揺るがすような仕様だとか、そう言うものに対して必要な期間が取れない場合はNOを突きつけたり、可能な代替案をこちらから示すべきだという事です。
十分に考慮、QAされずにリリースされた機能っていうのは大概後から色々厄介な問題を引き起こすものですから。
そしてその問題の原因がどこにあろうとも。
ユーザーデータを操作出来るのはサーバーエンジニアだけ…原因究明から補填対応までの後始末をするのはサーバーエンジニアなのですから。
サーバーアプリケーションを構成するインフラストラクチャーの構築、運用
良くあるサーバールームの絵としては、24時間エアコンで空調管理された部屋の中で、ラックに数多に配置されている機器に、沢山のコードが繋がっている、というのがあると思いますが、ぶっちゃけると自分はそんな部屋に入った事すらありません。
クラウドで管理された実体がどこにあるのかも分からないインフラストラクチャーを入社当初からずーっと弄ってます。
そしてこちらに関しても、正直なところ高校数学とかも大して必要ないのですが、その代わりに要求される知識がかなり多くなります。
クラウドサービスの一つであるAWSでサーバーを構築するに当たってやる事としては、
Route53で各種ドメイン登録を行い、ALBでそれをロードバランシングし、S3とCloudFrontでCDNサーバーを構築し、Elasticacheでキャッシュサーバーを構築し、ECSでECRに登録されたDockerイメージを反映するEC2インスタンス群を管理させてAPIサーバーを構築し、AutoScalingで負荷に応じてサーバー数を上下させるようにし、それぞれSecurityGroupを用いて外部からの不正アクセスを弾き、CloudWatchを使ってS3に各種ログを管理し、時にはAthenaでログ追跡を出来るようにし、各種負荷を可視化し、デプロイはCodeBuildを使って各種段階を自動的に踏むようにし……。
みたいに、専門用語のオンパレードになります。
そのAWSには、専門の資格も10を超えるくらいにあったりしますし。
まあ、そんな複雑な事柄も一回構築を終わらせて正常に動く事まで確認出来たら、運用としてはそう大してやる事はない……と言いたいところですが、開発環境なんて良く増やしてくれなんて言われますし、本番環境もユーザー規模に応じてスペックを落としてコスト削減を図る事も時折やったりしますので、ちゃんとマニュアルを書いておいたり、AWSではCloudFormationという機能でインフラをコード化までしておいたりだとか、そういう事までしっかりとやる必要があります。
そして本番環境を作るに当たっては、想定される最大ユーザー数がプレイしても耐えられるか？ という事をきちんと示しておかないといけません。
それに関しては過去に別に書いた事があるのでここで細かくは書きませんが、サーバーアプリケーションとインフラストラクチャーの両方に精通していないと、問題が発覚した時の原因究明すらままならない事もあります。
そういう点もあって、サーバーエンジニアとインフラエンジニアは兼業になる事が多いのではないかと思います。
何が面白いの？
冒頭でも書いた通り、ゲームを作るのに対してグラフィックもサウンドも何も関わってこない、更にゲームの面白さを構想する事もしません。
完成品も派手にキャラが動き回ったり、スタイリッシュなUIが機能する事もなく、はたまた絢爛豪華なサウンドが流れる事もなく。どこにあるか分からないサーバーから正常な通信が返ってくるだけ。
他の部門が面白さを0から1にしたり、1を5にも10にもするようなところであれば、サーバーは減算式。何も起きなければ100ではあるが、何か起きたら一気に落ちていく。正常に稼働していてもユーザーから称賛がかかる事は基本なく、何かあったら文句を言われるばかり。
けれど、誰が何をしようとも根本的な対応が出来るのはサーバーエンジニアだけです。
ユーザーがチートをして来ようが、それに対する最終的な防衛を行えるのも、自身を含んだ運営の誰がミスをしようとも、迅速に対応出来るのも、サーバーエンジニアだけ。
そして、その為の武器として手に持つのは純粋にロジックのみです。
そういう点では、ユーザーに喜ばれる仕事というよりは、同じゲームを開発、運営しているチーム内から頼られる仕事をする、と言う方が合っているかもしれません(漫画で例えるとフラジャイルの病理医みたいな立場かも。時々仕様にケチ付けるのも含めて)。
また、負荷というものへの考慮もクライアントとサーバーでは大きく変わってきます。
クライアントはマルチプレイなどが無い限りは基本ユーザー1人との対面を考えれば良いのですが、サーバーは今遊んでいる全てのユーザーとの対面を考える必要があります。
特にリリース時なんかは、想定されるユーザー数……時には数万人が同時に遊んだしても大丈夫な仕組みになっているか？ という事までも考える必要が出て来たりします。
その為にも、プログラムはクライアントよりも効率化の必要性が高いです。
無駄を徹底的に省き、時にはデータをキャッシュして参照効率を更に向上させる。
どれだけアクセスが来ようとも、変わらず迅速なロジックと堅牢且つ柔軟なインフラを組み上げて、リリースと同時に雪崩れ込むユーザーを捌き切る。
また、リリースされてからアクセスが落ち着いて来た後に新しい機能が追加されたり、時が経ってユーザー1人辺りの資産が莫大になっていこうとも、サーバーはいつもと変わらない顔をしてレスポンスを正常に、迅速に返し続ける必要がある。
それは機能美を追求し続けるようなストイックさが強く必要で、そういうのが好きな人にはがっちり合うと思います。
最後に
自身を含んだ運営の誰がミスをしようとも、迅速に対応出来るのも、サーバーエンジニアだけ。
これが何を意味するか分かりますか？
ゲームを運営しているサーバーエンジニアが行き着く先は、休暇中であろうとも仕事用のパソコンを持ち運び、何か起きたらすぐにパソコンを開いて原因究明、緊急性が高かったならば不具合対応から補填まで行う必要があるという事です。
……まあ、そこまで責任を負うようになったら、それなりのお金も貰えていると思いますし、ウチのチームはここからここまで電波の繋がらない場所に行ってしまいますと事前に伝えておけば、他の方々でサポート出来る体制です。
要するに、自分しか出来ない仕事なんて持たない方が良いって事です。あったらさっさとマニュアル化したりして、ノウハウを共有しましょう。
自分が好きな時に会社からの通知も気にせず好きに休める為には、それが必要です。
