COLOPL Tech Blog

コロプラのエンジニアブログです

「【Go Tech Talk】スケーラビリティのための3社合同LT」を実施しました!

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

2022年11月30日、【Go Tech Talk】スケーラビリティのための3社合同LT  というタイトルで「コロプラ」「Diarkis」「ミラティブ」3社合同でのイベントを実施いたしました。

アーカイブYouTube でご覧いただけます。

www.youtube.com

発表内容

コロプラでは、リアルタイムサーバーの実装やゲームのリリース前に実施する負荷試験用の bot 実装など、いくつかの用途で Go を利用しています。これらの用途では 、HTTP やリアルタイム通信用の内製プロトコルによる通信を Go で実装する必要があるのですが、API の数が多くなるにつれて通信に関するコードを手で記述することが大変になっていくという課題がありました。

今回の勉強会では、この課題に対応するために 、Go でよく取られる手法であるコードの自動生成をコロプラではどう実装しているかについてお話させていただきました。
HTTP と内製プロトコル用の通信で要件が異なってくるため、自動生成の実装も違うアプローチを取っているのですが、発表ではそれぞれの要件や実装のアプローチについてお話させていただいたので 、Go でのコードの自動生成について複数の角度から知ることができるのではないかと思います。

資料はこちらになります。

発表について補足

定義ファイルを置く場所について

発表で HTTP は YAML、リアルタイム通信は Protocol Buffer の .proto ファイルによって API やメッセージのスキーマを定義しているという話をしましたが、これらのファイルの置き場所について補足いたします。

YAML ファイルについては 、API サーバーを実装するリポジトリに置かれるようになっています。これは API サーバーの基盤実装に含まれるものなので、 Go や C# のクライアント実装はそれを参照するようにしています。

.proto ファイルについては、基本的にリアルタイムサーバーのリポジトリに置かれるようになっています。コード生成時に出力されるファイルのパスを Go と C# でそれぞれ指定できるので、サーバーとクライアントのどちらに置いても問題はないようにできています。サーバー側に置かれることが多いのは、リアルタイム通信以外の部分にも関心を持つクライアントのリポジトリよりはリアルタイム通信が関心の中心となるサーバーのリポジトリに置いたほうが分かりやすいと判断しているためです。

HTTP の定義ファイルを内製している理由

発表で HTTP では YAML による定義を内製しているという話がありましたが、こちらについてなぜ内製しているのかという質問をいただきました。今回の発表のテーマとは外れてしまいますが、ここで回答させていただきます。

一番大きな理由としては、 Swagger や OpenAPI が普及する前に既にこの仕組みを作っており、乗り換える理由も特になかったのでそのまま使い続けているということが挙げられます。定義ファイルのディレクトリ構成をアプリ実装のディレクトリ構成と合わせており、直感的に理解でき学習コストが十分に低いために乗り換えずに済んでいるのではないかと思います。

また、もともと自作していたことに付随する理由ではあるのですが、生成されるコードを自前で完全に管理できることも柔軟性・利便性・心理的な面でのメリットが大きいと感じています。

以上の理由からコロプラでは API 定義やコードの自動生成を内製し維持しています。

最後に

多くの方々のご視聴いただき、また質問・コメントも多くいただき大変感謝しております。

そして、この場をお借りして一緒に開催させていただいたDiarkisさん、ミラティブさんに心から感謝いたします。

今後も勉強会や技術ブログを通じて、エンジニアの方々に役立つコロプラの取り組みや技術情報を幅広く発信していきます。
次回イベントについては 【Google Cloud × GAME】ゲーム開発におけるGoogle Cloud活用事例 と題してGCP活用事例を各社から紹介させていただきます。引き続きconnpassおよびtwitterで告知いたしますので、是非メンバー登録とフォローをよろしくお願いいたします。

 

colopl.connpass.com

twitter.com