Quake Championsのバックエンドプラットフォームでアクターモデルを使用する練習

9月の高負荷システムの開発者向けミーティングであるPixonic DevGAMM Talksでレポートをアップロードし続けます。 彼らは多くの経験と事例を共有し、本日、Sabre Interactive Roman Rogozinのバックエンド開発者のスピーチのトランスクリプトを公開します。 彼は、プレーヤーとその状態を管理する例を使用して、アクターモデルを適用する方法について話しました（他のレポートについては、記事の最後を参照してください、リストは補足されます）。





私たちのチームは、ゲームQuake Championsのバックエンドに取り組んでいます。俳優モデルとは何か、プロジェクトでどのように使用されるかについてお話します。



技術スタックについて少し。 それぞれC＃でコードを記述しますが、すべてのテクノロジーはそれに関連付けられています。 この言語の例で示す特定の事柄がありますが、一般的な原則は変わりません。







現時点では、Azureでサービスをホストしています。 Table StorageやCosmos DBなど、拒否したくない非常に興味深いプリミティブがいくつかあります（ただし、クロスプラットフォームプロジェクトのためにそれらに縛られすぎないようにしています）。



次に、俳優モデルとは何かについて少しお話ししたいと思います。 そもそも、それは原則として40年以上前に登場しました。







アクターとは、独自の内部状態とこの状態を変更するための排他的アクセス権を持つ特定の孤立オブジェクトがあることを示す並列コンピューティングのモデルです。 アクターは、メッセージを読み取り、さらに、内部状態を変更する場合は何らかのビジネスロジックを実行し、他のアクターを含む外部サービスにメッセージを送信できます。 そして、彼は他の俳優を作成する方法を知っています。



アクターは互いに非同期で通信するため、負荷の高い分散クラウドシステムを作成できます。 この点で、アクターモデルは最近広く使用されています。



上記を要約すると、ある種のサーバークラスターがあるクラウドがあり、アクターがこのクラスター上で回転していると想像してみましょう。







アクターは互いに分離されており、非同期呼び出しを介して通信します。また、アクターは内部でスレッドセーフです。



どのように見えるか。 数人のユーザー（非常に大きな負荷ではない）がいて、ある時点でプレーヤーが流入していることを理解し、早急にアップスケールを行う必要があるとします。







サーバーをクラウドに追加し、アクターモデルを使用して、個々のユーザーをプッシュし、個々のアクターを割り当て、クラウド内のこのアクターにメモリとプロセッサ時間を割り当てます。



したがって、アクターは、まずキャッシュの役割を果たし、次に、「スマートキャッシュ」であり、一部のメッセージを処理してビジネスロジックを実行できます。 繰り返しますが、ダウンスケールを行う必要がある場合（たとえば、プレイヤーが残っている場合）-これらのアクターをシステムから削除しても問題はありません。



バックエンドの私たちは、古典的なアクターモデルを使用せず、Orleansフレームワークに基づいています。 違いは何ですか-今すぐお話しします。







まず、オルレアンは仮想俳優の概念を導入します。これは、グレインとも呼ばれます。 サービスがこのアクターを作成し、いくつかのサーバーに配置する責任を負う従来のアクターモデルとは異なり、Orleansは作業を引き継ぎます。 つまり 特定のユーザーサービスが特定の粒度を要求した場合、Orleansはどのサーバーの負荷が軽減されたかを理解し、そこにアクターを配置してユーザーサービスに結果を返します。



例。 穀物の場合、ユーザーの状態やIDなど、アクターのタイプのみを知ることが重要です。 ユーザーID 777の場合、このユーザーの粒度を取得し、この粒度の保存方法については考えず、粒度のライフサイクルを制御しません。 しかし、オルレアンはそれ自体の中に、すべての俳優の道を非常にunningな方法で保存しています。 俳優がいない場合、彼はそれらを作成し、俳優が生きている場合、彼はそれを返し、ユーザーサービスのためにすべてが見えるので、すべての俳優は常に生きています。







これにはどのような利点がありますか？ 第一に、プログラマーがアクター自身の位置を管理する必要がないという事実による透過的な負荷分散。 彼は単に、複数のサーバーに展開されているOrleansを言う：あなたのサーバーからそのような俳優をください。







必要に応じて、プロセッサとメモリの負荷が小さい場合はダウンスケールできます。 繰り返しますが、逆のアップスケールを行うことができます。 しかし、サービスはこれについて何も知りません、彼は穀物を要求します、そして、オルレアンは彼にその穀物を与えます。 したがって、オルレアンは穀物のライフサイクルのインフラストラクチャケアを行います。



第二に、Orleansはサーバーのクラッシュを処理します。







これは、古典的なモデルでは、プログラマーがそのようなケースを自分で処理する責任がある場合（つまり、サーバーにアクターを配置し、このサーバーがクラッシュし、ライブサーバーの1つでこのアクターを上げる必要がある）、より機械的なまたはプログラマーのための複雑なネットワーク作業、そしてオルレアンではそれは透明に見えます。 グレインを要求すると、Orleansはそれが利用できないことを確認し、それをピックアップして（ライブサーバーの一部に配置し）サービスに返します。



もう少し明確にするために、ユーザーが自分の状態の一部を読み取る方法の小さな例を分析してみましょう。







状態は、そのユーザーの鎧、武器、通貨、またはチャンピオンを保存する彼の経済状況である場合があります。 これらの状態を取得するために、彼はPublicUserServiceを呼び出し、州のOrleansに切り替えます。 何が起こっているのか：Orleansは、そのようなアクター（つまり、グレイン）がまだないことに気付き、無料のサーバー上で作成し、グレインは永続ストアからその状態を読み取ります。



したがって、スライドに示されているように、次回クラウドからリソースを読み取るときに、すべての読み取りはキャッシュキャッシュから行われます。 ユーザーがゲームを離れた場合、リソースの読み取りは行われないため、Orleansは穀物が誰にも使用されなくなり、非アクティブ化できることを理解します。



複数のクライアント（ゲームクライアント、ゲームサーバー）がある場合、それらはユーザー状態を要求でき、そのうちの1つがこの粒度を上げます。 より正確には、Orleansがそれを取得し、既にわかっているように、すべての呼び出しがスレッドセーフで順番に発生します。 最初に、クライアントは状態を受信し、次にゲームサーバーを受信します。







更新の同じフロー。 クライアントが状態を更新したいとき、彼はこの責任を穀物に移します。 「このユーザーに10ゴールドを与える」とグレインが上昇すると、グレイン内の何らかのビジネスロジックでこの状態を処理します。 そして、キャッシュキャッシュの更新が行われ、必要に応じて永続化に保存されます。







ここで永続性が必要なのはなぜですか？ これは別のトピックであり、グレインが永続性の状態を常に維持することは、私たちにとって特に重要でない場合があるという事実にあります。 これがオンラインのプレイヤーの状態である場合、生産性のためにそれを失うリスクがあります。それが経済に関係する場合、その状態が保持されることを確認する必要があります。



最も単純なケース：状態の保存呼び出しごとに、この更新をPersistenceに書き込みます。 したがって、grayが突然突然落ちた場合、他のサーバーのいくつかで次に粒度を上げると、現在のデータでキャッシュが更新されます。



どのように見えるかの小さな例。







既に述べたように、グレインはタイプといくつかのキーで構成されています（この場合、タイプはIPlayerState、キーはIGrainWithGuidKeyです。つまり、Guidです）。 そして、私たちが実装するインターフェース、すなわち GetStatesは、状態のリストとApplyStateを返します。これらの状態は適用されます。 OrleansメソッドはTaskを返します。 これが何を意味するのか：タスクは、状態が戻ったときにプロミスが解決された状態になることを伝えるプロミスです。 GrainFactoryで取得するPlayerStateもあります。 つまり ここでリンクを取得しますが、この穀物の物理的な場所については何も知りません。 GetStatesを呼び出すと、Orleansはグレーンを上げ、Persistenceストアから状態をメモリに読み取り、ApplyStateが新しい状態を適用すると、メモリと永続性の両方でこの状態も更新します。



UserStatesサービスの高レベルアーキテクチャに関するもう少し複雑な例を作成したいと思います。







OfferSeviceを通じて状態を取得する何らかの種類のゲームクライアントがあります。 ユーザーのグループ（この場合はユーザー）の経済モデルを担当するGameConfigurationServiceがあります。 そして、この経済モデルを変えようとしているオペレーターがいます。 それに応じて、ユーザーはOfferSeviceに状態の受信を要求します。 また、OfferSeviceはこれらのグレインで構成されるUserOrleansサービスに既にアクセスしており、メモリ内でユーザーのこの状態を発生させ、何らかのビジネスロジックを実行し、OfferServiceを介してユーザーにデータを返します。



一般的に、グレインは互いに独立しているため、オルレアンはその高い並列処理能力に優れているという事実に注目したいと思います。 一方、グレインの内部では、同期プリミティブを使用する必要はありません。このグレインへの各呼び出しが何らかの形で一貫していることがわかっているからです。



ここで、このモデルの落とし穴のいくつかを明らかにしたいと思います。







1つ目は粒度が粗すぎます。 グレイン内のすべての呼び出しはスレッドセーフであるため、グレインに大胆なロジックがある場合は、長時間待つ必要があります。 繰り返しますが、このような1つのグレインに割り当てられるメモリが多すぎます。 粒が小さすぎると悪いので、粒のサイズがどうあるべきかについての正確なアルゴリズムはありません。 ここでは、最適値から進める必要があります。 どちらを正確に言うかは決めません。決めるのはプログラマ次第です。



2番目の問題はそれほど明白ではありません-これはいわゆる連鎖反応です。 ユーザーがいくつかの穀物を上げると、ユーザーはシステム内の他の穀物を暗黙的に上げることができます。 これがどのように起こるか：ユーザーは自分のステータスを受け取り、ユーザーには友達がいて、友達のステータスを受け取ります。 したがって、システム全体がすべてのグレインをメモリに保持し、1000人のユーザーがいて、それぞれに100人の友人がいる場合、100,000のグレインをそのようにアクティブにできます。 このケースも回避する必要があります-何らかの方法で友人の状態を何らかの共有メモリに保存します。







さて、アクターモデルを実装するために存在する技術は何ですか。 おそらく最も有名なのはAkkaで、Javaを使って私たちのところに来ました。 Akka.NET for .NETと呼ばれるフォークがあります。 実装として、他の言語のオープンソースであるOrleansがあります。 Service Fabric ActorなどのAzureプリミティブがあります-多くのテクノロジーがあります。

聴衆からの質問

-CICDのような古典的な問題を解決する方法、これらのアクターを更新する方法、Dockerを使用する方法はありますか？



-まだdockerを使用していません。 一般的に、DevOpsは展開に従事しており、Azureクラウドサービスにサービスを展開します。



-ダウンタイムなしの継続的な更新、どのように発生しますか？ Orleans自身が、サーバーのアクセス先サーバー、要求の送信先サーバー、およびこのサービスの更新方法を決定します。 つまり 新しいビジネスロジックが登場し、同じアクターのアップデートが登場しました-これらのアップデートはどのように展開されますか？



-サービス全体の更新について話している場合、および何らかのアクターのビジネスロジックを更新した場合、そのための新しいOrleansサービスを展開できます。 通常、これはトポロジと呼ばれるプリミティブで解決されます。 いくつかの新しいOrleansサービスを展開しました。これは、今のところ、空で、アクターなしで、古いサービスを表示し、新しいサービスに置き換えます。 システムにはアクターはまったくありませんが、次のユーザーリクエストでこれらのアクターは既に作成されています。 おそらく最初に何らかのスパイクが発生するでしょう。 このような場合、更新は通常午前中に行われます。午前中はプレイヤーの数が最も少ないからです。



「サーバーがクラッシュしたことをOrleansはどのように理解しますか？」 あなたは彼がすぐに別のサーバーに俳優を投げると言った...



-彼は、どのサーバーが生きているかを定期的に理解するpingatorを持っています。



-彼は特にアクターまたはサーバーにpingを実行しますか？



-具体的には、サーバー。



-そのような質問：俳優の内部でエラーが発生しました、あなたは彼がステップごとに、各命令で行くと言います。 しかし、エラーが発生し、アクターはどうなりますか？ 処理されないエラーがあるとします。 俳優は死にかけているだけですか？



-いいえ、Orleansは標準の.NETスキーマで例外をスローします。



-見て、私たちは例外を処理しなかった、俳優は明らかに死んだ。 プレーヤーはどのように見えるかわかりませんが、その後どうなりますか？ どういうわけかこのアクターを再起動しようとしているか、そのような何かをしようとしていますか？



-ケースに応じて、動作に依存します。 たとえば、再試行可能または再試行不可。



-つまり これはすべて設定可能ですか？



-むしろ、プログラムされています。 いくつかの例外を処理しています。 つまり このようなエラーコード、および未処理の例外などの一部は既にさらにプッシュされていることが明確にわかります。



-いくつかの永続性がありますか？データベースのようなものですか？



-永続性、はい、永続ストレージを備えたデータベース。



-データベースが（条件付きで）ゲームマネーを定めたとしましょう。 俳優が彼女に到達できない場合はどうなりますか？ どのように処理しますか？



-まず第一に、それはストレージです。 現時点では、Azure Table Storageを使用していますが、そのような問題は実際に発生します-ストレージがクラッシュします。 通常、この場合、再構成する必要があります。



-アクターがストレージで何かを取得できなかった場合、プレーヤーはどのように見えますか？ 彼は単にこのお金を持っていないのですか、それともすぐにゲームを閉じますか？



-これらはユーザーにとって重要な変更です。 各サービスには独自の重大度があるため、この場合、ユーザーサービスは端末状態であり、クライアントはクラッシュします。



-アクターのメッセージは非同期キューを介して発生するように思えました。 この最適化されたソリューションはどうですか？ 膨らみませんか、プレーヤーがハングアップしませんか？ リアクティブなアプローチを使用する方が良いとは思いませんか？



-アクターのキューの問題はかなりよく知られています。キューのサイズを明確に制御できないためです。あなたは正しいです。 しかし、オルレアンは、第一に、ある種の管理作業を引き受け、第二に、単にタイムアウトによってアクタへのアクセスが落ちる、つまり たとえば、俳優に連絡することはできません。



-そして、これはプレーヤーにどのように影響しますか？



-ユーザーサービスはアクターに対処するため、例外タイムアウト例外をスローし、それが「クリティカル」サービスである場合、クライアントはエラーをスローして終了します。 それほど重要でない場合は、待機します。



-つまり DDoSの脅威はありますか？ 多数の小さなアクションでプレーヤーを配置できますか？ 誰かがすぐに友人の招待などを開始するとします。



-いいえ、あまり頻繁にサービスにアクセスできないようにするリクエストリミッターがあります。



-データの一貫性をどのように扱いますか？ 2人のユーザーがいて、一方から何かを取得し、もう一方に何かを請求する必要があるとします。



-いい質問です。 まず、Orleans 2.0は分散アクタトランザクションをサポートしています-これが最初のリリースです。 より正確には、経済について話す必要があります。 そして最も簡単な方法として-最後のオーリンズでは、アクター間のトランザクションは問題なく実装されています。



-つまり データの整合性を維持する方法をすでに知っていますか？



-はい。

Pixonic DevGAMM Talksとのさらなる講演

• Consulを使用したステートフルサービスのスケーリング （Ivan Bubnov、DevOps at BIT.GAMES）;
• CICD：ダウンタイムなしの分散クラスターシステムへのシームレスな展開 （Egor Panov、Pixonicシステム管理者）;
• Tacticoolモバイルオンラインシューターメタサーバーアーキテクチャ （Pavel Platto、PanzerDogのリードソフトウェアエンジニア）;
• ECS、C＃ジョブシステム、SRPがアーキテクチャへのアプローチをどのように変えるか （Valentin Simonov、Unityのフィールドエンジニア）;
• 開発におけるKISS原則 （Konstantin Gladyshev、1C Game Studiosのリードゲームプログラマー）;
• クライアントとサーバーの一般的なゲームロジック （Pixonicの副技術責任者、Anton Grigoriev）。
• Cucumber in the Cloud：製品ストレステストにBDDスクリプトを使用 （ALICE Platformのテクニカルプロダクトマネージャー、Anton Kosyakin）。