1年半続く「20卒輪読会」と「GCloud Monday」　初日からリモートワークの社員がコミュニケーションのためにやったこと

ゲームサーバー基盤「Takasho」とは何か

海老沼健一氏（以下、海老沼）：「基盤チームとしての挑戦と社内コミュニティで得た学び」というタイトルで発表いたします。

簡単に自己紹介します。海老沼健一と言います。私は2020年に入社して、現在はゲーム事業本部 ディベロップメント統括部 技術部第6グループに所属しています。趣味はテニスと映画鑑賞で、最近はよく会社の部活でテニスを楽しんでいます。学生時代は、創業期のスタートアップ数社に入っていて、サーバーからフロント、インフラまで幅広く経験を積みました。

今はサーバーサイドエンジニアとして、社内ゲームサーバー基盤「Takasho」の開発と運用を行っています。

今日は、自分が入社してからこれまでに関わったゲームサーバー基盤「Takasho」について、これまで経験したことをお話していきます。また社内の技術コミュニティの運営など、横断的な活動についても紹介したいと思います。

まずは、ゲームサーバー基盤「Takasho」とは何かについて紹介します。Takashoは、DeNA内製のゲームサーバー基盤です。基盤と言うと、大きなサーバー群をイメージする方もいるかもしれませんが、そういったものではなく、複数のゲームタイトルでサーバーを開発・運用しやすくするための、フレームワークやツールセットのことを基盤と呼んでいます。

具体的には、Webサーバーフレームワークやその上で動かせる複数のゲームタイトルに共通で必要な機能セットだったり、コードの自動生成ツールやインフラの構築ツールなどを提供しています。また内製のMBaaS（Mobile Backend as a Service）と連携して動く前提で作っていて、アカウント管理や課金、プッシュ通知などは、そちらを利用して実装できるようになっています。

Takashoでは、これらの技術を採用しています。アプリケーションサーバーは基本的にすべてGoで書いており、クライアントとの通信にはProtocol BuffersとgRPCを利用しています。クラウドにはGoogle Cloudを利用しており、GKE（Google Kubernetes Engine）やCloud Spanner、Cloud Memorystoreといった技術を採用しています。

他にも、Circle CIやTerraform、ArgoCDなどを利用しています。Takashoを支える技術について詳しく知りたい方は、以前Google INSIDE Games & Appsというイベントでも登壇したので、ぜひそちらもご覧ください。

Takashoができた経緯

続いて、簡単にTakashoができた経緯について説明します。以前からゲームサーバー基盤はあったのですが、いくつか課題を抱えていました。1つは全タイトル、ここでのタイトルはゲームのタイトルのことですが、共通のコードを利用していることで、多くのタイトルを抱えて運用の年数が長くなってくると、それぞれのタイトルに特化した仕様の変更が難しい状態になっていました。

2つ目は、全タイトルで1つのサーバー群を利用していたので、あるタイトルに障害が発生するとその影響が他のタイトルにも影響してしまう可能性がありました。ただ、こちらの基盤は現在も安定して稼働しており、一定成功はしていると言えます。

これらの課題に対してTakashoでは、まず複数タイトルで共通のコードベースを利用するのではなく、Webサーバーフレームワークを提供するようにしました。これによって、一定の開発速度を担保しつつ、タイトルごとの独自機能追加が容易になりました。ガチャやお知らせなどといった、複数タイトルで共通で必要になる機能については、フレームワークに簡単に組み込める「機能セット」というかたちで提供しています。

また、サーバーはタイトルごとに運用を行い、インフラの構築を楽に行える仕組みも用意しています。マネージドサービスを駆使することで、金銭的にも運用的にもコストを最適化できるように取り組んでいます。

Takashoチームが普段やっていること

ではここから、Takashoチームが普段どういった仕事をしているのかを紹介していきます。Takashoチームがやっていることは主にこの3つです。

まずは、先ほど紹介したWebサーバーフレームワークの開発です。すでにいくつかのタイトルがTakashoのフレームワークを利用したサーバーで運用されているため、それらのタイトルからの知見を継続的に反映させています。また、開発の効率化や品質向上のため、コードの自動生成やインフラ構築を行うツールの開発やメンテナンスも行っています。

基盤を利用するタイトルのゲームサーバー開発・運用も、Takashoチームで行っているものがいくつかあります。こちらは、タイトルごとに数人ずつ担当者を付けていて、外部のクライアントエンジニアやQAなどといった方々と連携して、ゲームの機能開発やバグの修正・障害対応・運用までを行っています。

他のチームでは、フレームワークを利用してゲームサーバー開発を行っているものもあります。そちらではフレームワークの導入や更新のサポートをしたり、Takashoチームで運用しているタイトルで溜まった知見を共有して、より早くより安定した開発・運用を行えるようにサポートを行っています。

Takashoチームに求められること

またTakashoチームには、以下のようなことが求められます。まずタイトルチームがゲームのおもしろさを作る部分に集中できるようにする必要があります。

どのタイトルにも共通して必要な機能を集約して開発して、運用実績のある安定した機能を複数のタイトルで利用できるようにしています。他にも、スキーマやモックサーバーといったかたちで事前に提供することで、クライアント側の開発をできるだけサーバー側に依存させないように作ることも心がけています。

次に、より多くの人に継続的にゲームを遊んでもらえるようにすることが求められます。大規模リクエストを難なく捌けるサーバーを提供する必要がありますし、瞬間的な負荷に耐えられるだけでなく高い可用性と安定した運用も必要になります。

そして、開発や運用のコストをできる限り下げることも重要です。サーバーやインフラのアーキテクチャを最適化するだけでなく、クライアントチームが適切なリクエストを行えるようにサポートしたり、クライアントチーム、Takashoチームの開発工数の削減についても取り組んでいます。

大きめ機能開発

ここまでで、Takashoチームがやっていることや求められることについて話してきましたが、ここからは実際に自分がこれまでやってきたことについて話します。

自分がTakashoチームでやってきたことは、このような感じです。まず配属されてから1ヶ月半くらい経った頃、あるタイトルで大きめの機能開発を任せてもらえることになりました。具体的な機能についてはお話できないのですが、複数のプレイヤーがコミュニケーションを取るようなもので、だいたい10人月ぐらいの工数がかかるものになります。

設計は自分が行って、実装は他のメンバーにも協力してもらって進めました。最終的に3ヶ月半くらいかけて実装して、リリースしました。この開発を経験したことで、ゲームサーバー独自の設計だったり大規模トラフィックに耐えうる設計に必要な知識といったものをインプットできたと思っています。

Takashoでは、サーバーコードレスアーキテクチャという、できるだけクライアント側にロジックをする方針を取っています。詳しい経緯などはこちらのブログにまとめているので、興味がある方は見ていただければと思いますが、クライアントから自由に整合性を保ちつつ書き込めるKey-Value Storeや、汎用的な報酬管理機能によってこれを実現しています。できるだけクライアントに寄せてはいるのですが、ユーザー同士がコミュニケーションを行う機能や、セキュリティ面などの関係でサーバー側で管理しなければいけないものもあるので、データによってサーバーとクライアントのどちらでスキーマを管理するのが適切なのかを考えながら設計しました。

またゲームサーバーは、リリース時にガチャのリセマラなどによってスパイクが発生するので、最初から大規模なトラフィックを想定した設計を考える必要があります。DBのロック競合や適切なクエリ、インデックスの貼り方、また非同期処理やバッチなどといった比較的難易度の高いシステム設計についても学べたと思っています。

機能実装を進めていく中で、実装が完了して環境SDKをクライアント開発会社に提供したところ、不具合が多く見つかることがありました。これの主な原因は、不十分な動作検証によるものでした。例えば実装者が動作の確認を行う際、正常系の確認のみで終わらせてしまっていたり、動作検証している内容に、人によってバラツキがありました。

これに対して、2つの改善に取り組みました。まずPR（Pull Request）に検証した内容を決まったフォーマットで記載してもらうようにすることで、検証した内容をレビューできるようになりました。また、そもそも機械的に検知して防げる問題も発生していたので、静的解析ツールを導入しました。これらの取り組みによって、検証の不備による不具合をかなり減らすことができました。

本番リリースに向けたデプロイフローの整備

続いて、本番リリースに向けたデプロイフローの整備について担当しました。自分はそのうちの要件定義からツールの調査、導入までを担当しました。TakashoではGKEを利用しているのですが、最終的にはArgoCDというCDツールの導入まで行いました。デプロイフローを整備するには、TakashoのインフラだったりKubernetes、GKE、GitOpsなどの幅広い技術をキャッチアップする必要があるため、もともとこのタスクには興味がありました。

そのため、自分からメンターやLEに、このタスクをやりたいことをちょっと前から伝えていました。当時の自分にとっては、非常にチャレンジングなタスクだったのですが、手を挙げたことがきっかけで、任せてもらえたと思っています。

もちろん、なんでも手を挙げたらやらせてもらえるわけではなく、いろいろとタスクをこなして信頼してもらうことが必要だと思いますが、積極的に手を挙げていくことは、成長を考えると、非常に大事なことだと思っています。

このデプロイフローを整備していく上でやってよかったことをいくつか紹介します。まず、ある程度調査したあとに他のチームにフィードバックをもらいに行きました。社内SlackにはKubernetesチャンネルがあるのですが、そこでKubernetesやGKEに詳しそうな人に声をかけていきました。いろいろインプットをもらって実際に考慮に漏れているところに気づけたり、違う視点も得られました。

もう1つがアウトプットで、社内で100人以上が毎月参加しているTechTalkがあるのですが、こちらで登壇する機会をもらいました。今回のTechConもアウトプットの1つですが、話すためにインプットした知識を改めて整理できますし、さらにフィードバックももらえるので、非常に挑戦してよかったと思っています。

リリースに向けた負荷試験

続いて、自分の担当しているタイトルのリリースに向けて負荷試験を行いました。この負荷試験の目的は、リリース時と運用に入ってからのトラフィック量や必要なサーバーのリソース量を予測すること。そして負荷試験を行って問題があれば、リリースまでに対処することになります。ゲームのクライアントのリクエストを再現したサーバーを大量に立てて、負荷をかけてボトルネックを発見し、さらに修正して再度負荷をかけ直すことを繰り返していきました。

負荷試験を行って実際に見つかった問題をいくつか紹介します。データベースのレイヤーでは適切なインデックスが貼られていない、ロックが競合するなどといったことでレイテンシの悪化やタイムアウトが発生しました。キャッシュが正しく実装されていないことで、DBに過剰に負荷がかかる問題もありました。

他にも外部サービス、MBaaSのレイテンシの悪化だったり、Google CloudのQuotaに引っかかってサービスに影響が出ることもありました。自分はこれらの問題を、負荷試験を通してひととおり見つけて、対処することになりました。

タイトル大臣という役割

ここまでデプロイフローの整備や負荷試験など技術寄りの話をしてきましたが、タイトル大臣という役割も、並行で担っていました。タイトル大臣はTakasho独自の用語なのですが、タイトル側のPMや外部のクライアントエンジニア、QAなどとのやりとりをする窓口のことをそう呼んでいます。

チームの構成図はざっくりこの下の図のようになっていて、やり取りをする担当者が大臣、副大臣をタイトルごとに複数人専属でついています。

具体的な仕事内容としては、ある機能をリリースしたいとなった場合に、まず仕様をベースにAPI設計をして、クライアントの開発会社とすり合わせを行います。そしてその機能を提供するスケジュールをいつにするのか、段階的にリリースするかなどの調整を行い、実際の実装とテストに入っていきます。実装は大臣がすべてやるわけではなく、他のメンバーにお願いすることも多いです。

実装が完了したら、サーバーの更新やSDKをクライアントの開発会社に提供して実装を進めてもらいます。実装が終わったら、定期的にクライアントの実装が適切なものになっているか、例えばAPIを余計に呼んでいないかなどを確認して、リリースしていきます。

実装をチームにお願いしたメンバーのスケジュールやタスクの管理なども、タイトル大臣で行っています。Takashoチームでのゲーム開発は、クライアント側にできるだけロジックを寄せるため、クライアントの実装スケジュールや実装の進捗などは時期によって必要な工数がけっこう変動します。Takasho全体を管理するPMがいるのですが、定期的にPMと各タイトルの大臣や副大臣などを中心に情報共有を行って、タイトルごとに、適切な時期に適切な人数を割り振れるようにしています。

ここまでで、Takashoチームで学んだことをまとめると、まずは大規模ゲームサーバーというところでゲーム独自、Takasho独自のAPI設計だったり大規模トラフィックを捌くためのデータベースの知識などについて、広く触れられました。特に負荷試験を通じてDBからアプリケーション負荷対策、クラウドサービスの制約まで実際に負荷をかけた時にどういった問題が発生するのか、さまざまな経験ができました。

またタイトル大臣として、外部の開発会社やPM、QAなど多くの関係者とやり取りする中で、齟齬や手戻りができるだけ発生しないようにコミュニケーションを取るといったことや、あとはチーム内のタスクといったスケジュール管理などソフトスキルの面でも学べたことも多かったと思っています。

20卒輪読会

ではここから、社内技術コミュニティの運営など横断的な活動についてお話しします。社内には、技術コミュニティが多く存在するのですが、自分が運営ないし参加しているものがこちらです。本日はその中から、20卒輪読会とGCloud Mondayについてピックアップしてお話しします。

まず20卒輪読会について紹介します。2020年に新卒で同期入社したエンジニアの有志で開催しているもので、週1で業務終わりの1時間から2時間ぐらいを使って開催しています。ゆるい雰囲気でやっていて、ご飯を食べながらだったり雑談をしながら進めています。これは自分が興味がありそうな人に声をかけて始まったのですが、今まで1年半近く続いています。これまでは『データ指向アプリケーションデザイン』や『入門監視』『Fundamentals of Software Architecture』という本を読んでいました。

なぜ輪読会を始めたのかというと、まず僕らの代の2020年新卒というのは、入社した最初からリモートでした。そのため、オフィスでばったり会うみたいな偶然に関わる機会がありませんでした。なので、そういった機会を積極的に作っていきたいと考えていました。実際に、輪読会という同期が集まる機会を定期的に作ったことで、来てくれる同期の近況や社内の状況をいろいろ知れるので、非常にありがたいなと思っています。

また1人で本を進めるよりも、複数人で読み進めたほうが学びの効率が良いというのもあります。いろいろな技術的なバックグラウンドを持っていたり、それぞれ違う事業部、チームに所属しているので、本のトピックに関連したさまざまな事例や知見を各方面からたくさん得られます。

最後に、モチベーションの維持というところで、1人ではハードルの高い分厚い本だったり英語の本なども他のメンバーと読み進めることで、一定のプレッシャーがかかり挫折しにくくなるんじゃないかなと思っています。

輪読会の進め方ですが、Scrapboxというサービスを利用していて、毎週担当者が担当する章の内容をまとめてきます。当日はzoomに画面共有しながらまとめを読んでいき、気になったところがあれば、自由にコメントしたり議論したりという感じで進めています。

こんな感じで、これまで読んだ本がまとまっています。気になったところに参加者がコメントをして、担当者が拾っていくかたちで進めていて、実際にいくつかコメントが付いているところをピックアップしてきました。

例えば監視システムの話をした時には、各部署ではどういったモニタリングツールを利用しているのか、さらにそういったそれらのツールのメリデメについて輪読会で議論しました。データベースのインデックスについて話した会では、Bツリーの実装について話したりとか、他のアルゴリズムについていろいろな資料を読んだりしました。

このように話している中でも、特にうちではこんなものをやっていますだったり、こういうものを検討していた、というような実業務に近い話は、毎回非常に勉強になります。実際にここで話したことがきっかけで、本業のシステム構成を見直ししたり困っていた問題を解消したりすることも何度かありました。

たまに、ハンズオンやデモも行っています。輪読会の延長でトランザクションの回ではトランザクション分離レベルの比較表を見ながら、動作を手元で再現したり、レプリケーションの回では、MySQLのレプリケーションを実際に動かしながら確かめたりしました。

他にも、NewSQLという分散リレーショナルデータベースの分野については、輪読会で持ち上がったので、TiDBというサービスを実際にAWS上で動かして、負荷をかけるところまでやってみた時もありました。

1年半続いているというところで、続いている理由だったりコツみたいなものを紹介しようと思います。まず、事前に読んでまとめてくる人がいるので、1人がそのトピックに詳しい状態になります。

新しいトピックについて学ぶ時に、誰も詳しく知らない状態だと理解するまで時間が過ぎてしまうことがあります。なので、議論のファシリテートをできる人がいると進みやすくもなります。

あとはゆるい雰囲気で雑談多めにしていて、気軽に参加しやすいようにしていたり、担当者の負担が大きくなりすぎないように、今は1ヶ月半に1回ぐらい担当が回ってくるようになっています。

GCloud Monday

続いて、GCloud Mondayについても紹介します。Google Cloudに関する勉強会で、隔週の月曜日に1時間開催しています。実際にGoogle Cloudの方にも参加してもらっていて、社内でGoogle Cloudを利用しているチームの知見を共有したり、定期的にGoogle Cloudのアップデートについてキャッチアップしたりなど、社内でも比較的に熱量の高いコミュニティだと思っています。

Takashoチームからも、何度かリリース後に発生した問題や一部システムの再設計について共有したりなど、積極的に参加しています。

その他、社内に多くの技術コミュニティが存在します。Android、Swift、Ruby、Go、Webフロントエンドといったように、各言語や分野の勉強会はもちろん、自分も登壇したテックトークや社内XR事業情報共有会。他にもチームや事業部ごとに多くの勉強会やコミュニティが運営されています。

最後にまとめですが、自分はTakashoチームで技術的な学びや経験はもちろん、さまざまな方とコミュニケーションやマネジメントを経験しました。特にデプロイフロー整備のところでは、チャレンジングなタスクでもどんどん若手に任せてもらえる環境があり、非常にありがたかったなと思っています。

また輪読会やGCloud Mondayといった社内コミュニティにも積極的に参加して、そこでの学びを業務に活かしています。その過程で、同期とのつながりや自分の学びを共有することもできるので、今後も引き続きそういった横断的な取り組みを行っていこうと思っています。

以上になります。ご清聴ありがとうございました。

勉強会で学ぶテーマはどうやって決めているか

司会者：海老沼さんありがとうございました。同期とのコミュニケーションだったりとか、あとは事業でもやっていることみたいなところがお互いシナジーを生み出していてすごいおもしろいなと思いながら聞いていました。それではQ＆Aセッションに移っていきたいと思います。

質問はこちらです。「いろいろな部署の同僚と勉強会を実施されていると思いますが、勉強会で学ぶテーマは、どうやって決めていますか？」ということですね。これに関しては、確かに興味がありますね。

海老沼：そうですね。基本的には参加するメンバーで読みたい本を出してその中から投票してという感じで選んでいます。ただ選ぶ基準として、輪読会で読んだほうがいいか、輪読会で読むことでより効率化できるのかは大事にしています。

その観点で言うと、特定の技術だったり言語の勉強というよりかは、どちらかというとより汎用的な技術の勉強だったり、概念など勉強をするようにしていて、そうすることで、実際にその汎用的な技術についての事業部の知見だったり運用事例だったりを共有しやすいので、大事にしています。

司会者：なるほど。今まで一番よかったテーマはどういったものですか？

海老沼：そうですね。最初に読んだ『データ指向アプリケーションデザイン』という本が個人的にはすごくよかったなと思っていて、トランザクションとかレプリケーションとかは普段あまり強く意識することはないかなと思いますが、ちゃんと裏の仕組みを知っていると、正しいシステム設計ができるので、そこは非常に良かったなと思っています。

司会者：そういうところを、同期とも実際に動かしてみながらやっていたのはいいですね。僕も、そういうのがほしかったなと思いました。ありがとうございます。

海老沼：ありがとうございました。