How a team of just two engineers tackled real-time persisted events for hundreds of millions of players わずか2人のエンジニアで、スーパーセルは、基本的なアカウントシステムを何億ものプレイヤーを結ぶソーシャルプラットフォームに成長させるという困難な任務に取り組んだ。アカウント管理、友人リクエスト、クロスゲームプロモーション、チャット、プレイヤーの存在追跡、チーム構築 - これらはすべて5つの主要なゲームで動作する必要があり、それらはすべて、1人のエンジニアが維持するのに十分に単純で、リアルタイムで巨大な需要に対処するのに十分に強力な1つのソリューションによってカバーされることを望んだ。 SupercellのサーバーエンジニアであるEdvard Fagerholm氏は最近、2人の強力なチームがこの課題にどのように対処したかを共有しました。 注:あなたがこのようなエンジニアリングのパフォーマンスについて聞くのが好きなら、モンスタースケール・サミット(無料+仮想)に参加してください。ディズニー+/Hulu、Slack、Canva、Uber、Salesforce、Atlassianなどのエンジニアは、戦略やケーススタディを共有します。 注:あなたがこのようなエンジニアリングのパフォーマンスについて聞くのが好きなら、モンスタースケール・サミット(無料+仮想)に参加してください。ディズニー+/Hulu、Slack、Canva、Uber、Salesforce、Atlassianなどのエンジニアは、戦略やケーススタディを共有します。 ノート モンスタースケールサミット タグ:誰のスーパーセル? Supercellはフィンランドに本拠を置くHay Day、Clash of Clans、Boom Beach、Clash Royale、Brawl Starsというヒットゲームの背後にある会社です。 何とか、彼らは非常に小さなスタッフでこれを達成することに成功しました。最近まで、何億もの月間アクティブなユーザーをサービスするゲームのすべてのアカウント管理機能は、2人のエンジニアによって構築され、管理されていました。 スーパーセルIDの起源 Supercell IDは、ユーザーがアカウントを復元し、新しいデバイスに移動するのを助けるための基本的なアカウントシステムとして誕生しました。 Edvard 氏は、「クライアントはアカウント API に HTTP クエリを実行することができ、主にクライアントがゲームサーバーにそのアイデンティティを証明するために提示できる署名されたトークンを返すことができた。友人リクエストを作成するなどのいくつかの操作では、アカウント API が別のプレイヤーに通知を送信する必要がありました。例えば、「あなたはこの友人リクエストを承認しますか?」その目的のために、通知のためのイベント列がありました。 2 コミュニケーションの入り口 エドバードが2020年末にスーパーセルIDプロジェクトに参加した後、彼は通知バックエンドの開発を開始し、主に5つのゲームでクロスプロモーションを開始しました。 クライアントはプロキシサーバーのフロートに接続し、その後、ルーティングメカニズムがイベントをクライアントに直接押し付けた(ゲームを通過することなく)。 彼らは、スーパーセルIDシステムの範囲を大幅に拡大するために、双方向コミュニケーションを使用できることを理解しました. エドバードは「基本的に、これにより、以前はゲームサーバーの一部だった機能を実装することができました. 私たちの目標は、開発中の新しいゲームに必要な機能を採用し、それらを私たちのシステムにパッケージ化することでした。 With that, Supercell ID began transforming into a cross-game social network that supported features like friend graphs, teaming up, chat, and friend state tracking. スーパーセルIDをクロスゲームソーシャルネットワークに進化させる この時点で、バックエンドのソーシャルネットワーク側はまだ一人のプロジェクトだったので、彼らはそれを単純に考えて設計した。 正しい抽象化を見つけること 「我々はすべての用途をサポートする単純な抽象化だけを望んでおり、したがって単一のエンジニアによって設計および実装することができる」とエドバードは説明した。 適切な抽象化を見つけることが鍵となり、Change Data Capture を搭載した階層的なキー値ストアがこの請求書に完璧に適合しました。 Key-value ストアのトップレベルのキーは、サブスクリプトできるトピックです。 各トップレベルのキーの下に2層のマップがあります - map(string, map(string, string)). Any change to the data under a top-level key is broadcast to all that key's subscribers. すべてのトップレベルのキーの下にあるデータの変更は、そのキーのすべてのサブスクリプターに送信されます。 最も内側のマップの値もタイムスタンプされています。各データソースは独自のタイムスタンプを制御し、正しい順序を定義します。クライアントは既に保存しているものよりも古いタイムスタンプの更新を落とします。 マップ(String、String、String) データの典型的な変更は、「レベルは10に等しい」と「レベルは11に等しい」の変更のようなものになります。 正しいデータベースを見つける 彼らは、彼らの技術的要件をサポートし、彼らのミニマリズムのチームを考慮して管理可能なデータベースが必要でした。 低ラテンシーで多くの小さな書き込みを処理する Hierarchical Data Model をサポート サービスとしてのバックアップおよびクラスター操作を管理 ScyllaDB Cloud (ScyllaDB Cloud は ScyllaDB の完全に管理されたバージョンで、スケールで予測可能な低遅延を提供するために知られているデータベースです)。 How it all plays out これがスーパーセルゲームでどのように機能するかについてのアイデアを得るには、二つの例を見ていきましょう。 まず、チャットメッセージを検討してください. A simple chat message could be represented in their data model as follows: エドバード氏は「サブスクリプトされているトップレベルのキーはチャットルームIDです。次のレベルのキーはタイムスタンプ-UIDなので、各メッセージの順序を決め、チャット履歴をクエリできます。 次に、スーパーセルの新しい(そして非常に期待されていた)ゲーム、mo.co. で使用されている「存在」を見てみましょう エドヴァルドによると、存在の目標は、「戦闘のためにチームを作るとき、あなたはリアルタイムでアバターとあなたの友人の現在の構築を見たい - 基本的にあなたの友人の武器と装備、そして彼らが何をしている。 Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: トップレベルはプレイヤーID、第二レベルはタイプ、内部マップにはデータが含まれています。 Supercell ID はデータを理解する必要がなく、ゲームクライアントに転送するだけです。 ゲームクライアントは、ルーティングが Supercell ID によって処理されるため、フレンド グラフを知る必要はありません。 システムアーキテクチャに深く入る エドバードが提供したシステムアーキテクチャのツアーで終わります。 「バックエンドは、API、プロキシ、およびイベントルーティング/ストレージサーバーに分かれています。トピックは、イベントルーティングサーバー上で生存し、それらに分割されます。クライアントは、クライアントのトピックサブスクリプションを処理するプロキシに接続します。プロキシは、これらのサブスクリプションを適切なイベントルーティングサーバーにルーティングします。エンドポイント(例えば、チャットと出席)は、イベントルーティングサーバーにデータを送信し、すべてのイベントはScyllaDB Cloudで持続します。 各トピックにはメインとバックアップシェードがあります。 メインがダウンする場合、メインシェードは各メッセージのメモリセクション番号を保持し、失われたメッセージを検出します。 セクション番号なしでメッセージを転送します。 メインシェードがダウンする場合、メインシェードがクライアントの状態をリフレッシュし、セクション番号をリセットします。 ルーティング レイヤーの API は、トピック、タイプ、キー、値トップのバッチを含むシンプルなイベント後の RPC です。それぞれの API の仕事は、上記のトップレイヤーにデータを書き換えるだけです。すべてのイベントは、サブスクリプトに送信する前に ScyllaDB で書かれています。当社の API は、API 呼び出しが成功した場合、メッセージは ScyllaDB で継続していました。同じイベントを複数回送信することは、クライアントにアップデートを適用することは、同じメッセージに複数のシーケンス番号をマッピングする可能性を除いて、idepotent 操作です。 接続すると、プロキシはあなたのすべての友達を調べ、それらのトピックにサブスクリプトします、あなたが所属するチャットグループにも同じです. We also subscribe to topics for the connecting client. These are used for sending notifications to the client, like friend requests and cross promotions. ルーターの再起動は、プロキシからトピックへの再サブスクリプションを起動します。 私たちはプロトコルバッファーを使用して帯域幅コストを節約します。すべての負荷バランスは、同じ HTTP/2 接続上のリクエストがプロキシ上の同じ TCP ソケットによって処理されることを保証するために TCP レベルで行われます。これは、当初の聴取時にメモリに特定の情報をキャッシュすることを可能にしますので、他のリクエストをリセットする必要はありません。私たちは、個々の HTTP/2 リクエストを別々にロードバランスする必要がなく、単一のリクエストを単一のルーターに数十万のサブスクリプションを簡単に送信することができます。 だが、ゲームが終わらない。 あなたがテクノロジーの完全な会話を見たい場合は、下のプレーを押すだけです。 そして、ゲームの世界におけるScyllaDBの役割についてもっと知りたい場合は、以下も読みたいかもしれません。 Epic Games: How Epic Games uses ScyllaDB as a binary cache in front of NVMe and S3 to accelerate global distribution of large game assets used by Unreal Cloud DDC. エピック・ゲームは、Unreal Cloud DDCが使用する大規模なゲーム資産のグローバルな配布を加速するために、バイナリキャッシュとしてScyllaDBを使用しています。 Tencent Games: How Tencent Games built service architecture based on CQRS and event sourcing patterns with Pulsar and ScyllaDB. Tencent Games: How Tencent Games built service architecture based on CQRS and event sourcing patterns with Pulsar and ScyllaDB. Tencent Games: How Tencent Games built service architecture based on CQRS and event sourcing patterns with Pulsar and ScyllaDB. Discord: How Discord uses ScyllaDB to power their massive growth, moving from a niche gaming platform to one of the world's largest communication platform. Discord: Discordは、世界最大のコミュニケーションプラットフォームの1つに移行するために、ScyllaDBを使用する方法。 エピックゲーム: Tencentゲーム: ディスコード:
