• HOME
  • ブログ
  • サーバー , Kotlin
  • 【海外版リリース記念】サーバーサイドKotlin、gRPCを中心とした「SEVEN’s CODE-セブンスコード-」のバックエンド技術

【海外版リリース記念】サーバーサイドKotlin、gRPCを中心とした「SEVEN’s CODE-セブンスコード-」のバックエンド技術

こんにちは、バックエンドエンジニアの竹端です。

去る2020年1月23日、弊社のゲームタイトルSEVEN’s CODE-セブンスコード-が全世界に向けて配信されました。

こちらのタイトルは昨年10月に日本では既にリリースされており、ここ数年アプリボットで取り組んできたサーバーサイドKotlin、gRPCを中心とした技術基盤で作られたタイトルです。

昨年開催されたCEDEC 2019のセッションでも、事例としてお話しさせていただきました。

https://speakerdeck.com/n_takehata/kuraiantotong-xin-haipahuomansunatong-xin-ji-pan-falsekai-fa-tomagiconionniyoruriarutaimutong-xin-falseshi-xian

リリース後も、バックエンドでは大きな問題もなく、ここまで約3ヶ月運用しています。

そこで今回はセブンスコードで使用しているバックエンドの技術セットについて、改めて紹介したいと思います。

サーバーサイドKotlin

まずはKotlin。サーバーサイドプログラムの言語として選択しました。
約2年前にJavaからの移行という形で導入を始め、このてっくぼっとでも何度も紹介されています。

なぜサーバーサイドKotlinを導入するのか?

1年半開発してきて実感したサーバーサイドKotlinのメリット

上記の記事にもあるように、

  • モダンな書き方ができる
  • 安全な言語仕様
  • Javaの資産を使える(移行コストが低く抑えられる)
  • 新しい技術的なチャレンジ

といったことを理由に導入し、考えていた通りの成果を得られたと思っています。

特に「安全な言語仕様」の効果は絶大で、実装時に防げた細かなバグは多く、テスト時のバグ修正やリリース時のサーバープログラムの不具合も、かなり少なく抑えられました。
セブンスコードはサーバーサイドエンジニアは1人という体制で開発しているため、ここの工数を減らすことができたのはかなり大きかったです。

gRPC

サーバーサイドKotlinと併せて力を入れてきたgRPC。

こちらはHTTP/2、Protocol Bufferesを使用しており、これまで使っていたREST(HTTP/1.1、JSON)とは通信プロトコルもデータフォーマットも変更になり、さらにクライアント側の実装も変わります。

通信フレームワークというクライアント/サーバー方式の肝となる部分の変更でもあり、サーバーサイドの言語をJavaからKotlinへ変える以上に影響の大きい変更でした。

前述のCEDEC 2019の発表資料でも書いていますが、下記のようにクライアントとインフラも含め様々な問題にぶつかりました。

  • Unity側の対応がExperimental
  • AWSのロードバランサとの組み合わせ(後述)
  • 対応の負荷試験ツールがない
  • データ容量が増えた時のデシリアライズのパフォーマンス劣化
  • Body、メタデータの容量制限

それでも、各種ライブラリやプラグインを自前で実装したり、インフラ構成を調整するなどしてなんとか実運用で使えるレベルまで持ってこれました。
負荷試験の結果や実プロダクトでのレイテンシなどを見てもパフォーマンスはかなり高く、安定しています。

さらにProtcol Buffersを使うことでサーバー、クライアント双方の通信インターフェースの実装もスムーズになり、開発効率の向上にもつながりました。

AWS(アプリケーションのサーバーインフラ)

インフラにはAWSを採用しています。

  • Amazon EC2
  • Amazon Aurora
  • Amazon ElastiCache(Redis、Memcached)

を使った基本的な構成で、構成管理にはTerraformAnsibleを使用しています。

構成管理に関しては、下記の記事でも紹介しています。

Applibotでのサーバイメージ作成 – Packer+Ansible -(AWS AMI編)

DevOpsを支える今話題のHashiCorpツール群についてに登壇してきました

ロードバランサの問題

gRPCのところでも少し書きましたが、ロードバランサでいくつか問題がありました。
内容は下記になります。

  • ALBがL4ロードバランシングのためgRPCに非対応
  • NLBはL7ロードバランシングで対応できるが、ALPN非対応のためSSL終端にできない

なのでgRPCを使う際のインフラ構成は少し工夫が必要になります。

最終的にはNLBでロードバランシングし、各EC2サーバーに配置しているNginxをSSL終端とするという形で対応しました。
(こちらも詳しくは資料をご覧ください)
各EC2のインスタンスにSSL証明書をインストールする必要があるため、ロードバランサを終端とするより少しコストがかかります。

AWS(フルサーバーレスのデータ分析基盤)

こちらは下記の記事で紹介しているデータ分析基盤です。

ソーシャルゲームの運用に欠かせないデータ分析基盤の作り方

アプリケーション側ではデータベースの更新ログや、各種必要な分析用のログをフォーマットに則ってJSON形式で出力するだけで、Amazon Kinesis、S3、Lambdaを介してAmazon Athenaへ集約されます。

そして集約したAthenaをデータソースとして、Re:dashでクエリの実行やダッシュボードの作成をし、分析に使います。

Photon Cloud

セブンスコードではオンライン対戦の機能があるため、こちらでPhoton Cloudを使用しています。

ルームの作成、参加、バトル中のスコアやスキルの同期といった基本的なリアルタイム通信の実装で使用し、安定したパフォーマンスを発揮しています。

いずれもカスタマイズは必要なく、UnityからPUNで通信してPhotonのベースの機能を使用することで実装できています。

セブンスコードは近年のアプリボットのバックエンド技術の結晶

ここまで紹介してきた通り、サーバーサイドKotlinやgRPCをはじめとして、ここ数年アプリボットで力を入れて取り組んできた技術を使い、初めてリリースされたプロダクトがセブンスコードです。
新しい技術へのチャレンジも色々とありましたが、無事リリースしてバックエンドに関しては安定稼働できているので嬉しく思います。

今回海外へ向けてリリースされたことで、より多くのセブンスコードで遊んでいただけること、また今回紹介した技術セットの事例としてより多くの人に知っていただければと願っています。


関連記事一覧

  1. この記事へのコメントはありません。