【TECH BLOG #37】『EXTASY VISUAL SHOCK』におけるサーバーサイド技術について

グリーエンターテインメント株式会社 技術戦略チーム のTAです。今回は、グリーエンターテインメントが3月31日より配信開始したヴィジュアル系音楽リズムゲーム『EXTASY VISUAL SHOCK』におけるサーバーサイド技術について書こうと思います。
主にコンテナ技術の話です。

これまでの運営タイトル

『EXTASY VISUAL SHOCK』の話の前に、まずはこれまでの運営タイトルについて簡単にご説明させていただきます。

グリーエンターテインメント株式会社は2021年7月1日よりファンプレックス株式会社から商号変更しました。
そのため、『EXTASY VISUAL SHOCK』配信以前からファンプレックスとして移管・運営しているタイトルが数多くあります。これらは開発元・運営元が様々ということもあり、使用されている技術も多種多様です。

運営タイトルでは大きな構成の変更や入れ替えは少なく、どちらかというと効率化や改善などに注力する傾向にあります。もちろんそれが運営の面白いところではあるのですが、別の視点で見ると「基本的には開発当時の技術を踏襲している」ことが多いです。

開発タイトルでこれまでと違うこと

運営タイトルでも言語のバージョンアップやデータベースの統合など、作業として大掛かりなものもあります。ただ前述の通り、大きな構成変更が少ないです。

つまり、サーバーサイドの構成としては…

こうです。
細かい部分は省略していますしタイトルごとに差異もあるのですが、イメージとしてはおおよそこんな感じだと思っていただければよいかと思います。

対して『EXTASY VISUAL SHOCK』では…

こうなっています。
こちらも詳細は省略しているのですが、1つ前の図と見比べていただくとわかりやすいと思います。

大きく違うのは、Amazon Elastic Kubernetes Service (EKS) を使用している点です。

どう変わったのか？

EKS…つまりKubernetesの導入により、これまでの運営タイトルでの開発・運用から変わったことがいくつかあります。

環境ごとの差が少ない

本番環境以外の開発環境などでも、スペックや台数の差はありますが同様の構成となっています。そのため環境差分についてはあまり気にする必要がありません。

構成が明確

KubernetesおよびDockerで管理されているため、構成はマニフェストやDockerfileなどを見ればわかります。ドキュメントが更新されていなくて、そこに書かれているものと実際導入されているものが違う、ということは起きにくいです。テスト的に導入してみたものがそのまま適用されていて、後から参画した人がその調査で苦労するということも少ないのではないでしょうか。

環境による差分に対応できる

1つ目に挙げた点とは反するように見えるかもしれませんが、これも重要なポイントです。
環境差分を気にする必要はないと言っても、やはり環境ごとに変更したい点は存在します。なるべく共通にしておきたいが、必要な部分は分けたい。ありますよね。
これについてはKustomizeによって解決しています。ベースとなるマニフェストを作っておき、環境差分についてはKustomizeで上書きする構成です。どこが差分になっているかもファイルを見れば分かりやすいです。

デプロイがシンプル

誤解のないように先に言っておくと、仕組みが簡単というわけではないです。ただ考え方としては比較的シンプルになったのではないかと思います。

これまでの運営タイトルの場合、複雑なコマンドがまとめられたデプロイスクリプトを用意したり、デプロイツールを導入して実行したり…というものが大半でした。タイトルごとにバラバラであり、インフラに絡むこともあって比較的難易度が高い部分です。トラブルが発生した場合の調査やデプロイに絡む改修が発生すると大変です。

対してKubernetesの環境では
1.コンテナイメージビルド
2.kustomization.yaml更新
3.kubectl apply
で、更新されるのを待つだけです。

学習コストはかかる

良くなったことばかり挙げるのも公平じゃないので、ややネガティブな部分も。
これまでKubernetes、特にコンテナ技術そのものに触れていなかった人にとっては、学習コストがそれなりに高いです。コマンドやマニフェストなど覚えることもたくさんありますし、コンテナやボリュームのライフサイクルを意識することも必要です。トラブルシューティングをするにしても、これまでの経験が通用しなくて思ったより時間がかかるなんてこともあります。
ただ、一度覚えたことはKubernetesを使用する他の環境でも応用できるので、マイナス部分だけではないと思います。

まとめ

サーバーサイド技術の流れとして、コンテナは避けて通れないところです。それに伴い、Kubernetesに関してもやはり重要な技術になっています。

さらに言えば、これまで領域が別れていたサーバーサイド(アプリ)とインフラの境目も曖昧になっていると思います。私はサーバーサイドエンジニアという立場ですが、やはりインフラチームとの連携がこれまで以上に重要になっていると感じています。

コンテナの導入により複雑化しやすいというのも、否定できないところではあります。しかし使用例が増えているのは確かで、メリットがあるというのもまた否定できないところでしょう。

ここまで色々書いてきましたが、私自身もまだ学ぶことが多いなと思っています。それだけ機能が豊富であり、複雑であり、使い方次第では便利なものです。まだDockerやKubernetesにあまり触れていないという方、あまり詳しくないという方は、これを機に修得してみるのはいかがでしょうか。