ゲームクライアントのダウンロード追跡システム

ゲームのダウンロードはかなり複雑なメカニズムであり、いくつかの段階で行われます。各段階では、切断、ハードウェア障害、通常のファイアウォール、プロバイダー側​​の制限など、何らかの理由で障害が発生する可能性があります。

このような多様な環境でのゲームクライアントのロード中に発生するエラーの診断は、完全に重要なタスクになります。 また、Googleアナリティクスなどの高度なソリューションを使用しても、問題が完全に解決されるわけではありません。 そのため、独自のゲームクライアントダウンロード追跡システムを設計および作成する必要がありました。

まず、ゲームクライアントのダウンロードプロセスを詳しく見てみましょう。 ソーシャルネットワークでは、アプリケーションはHTMLページ（以降、単にキャンバス）を持つiframe要素であり、サーバー上に物理的に配置されています。 キャンバスをロードした後、ゲームクライアントが初期化され、同じ段階でフラッシュプレーヤーとそのバージョンの可用性が決定されます。 次に、ゲームクライアントがオブジェクトタグの形式でページに埋め込まれます。 その後、私たちにとって最も興味深い3つの主要な段階があります。

1. 実際にCDNからファイルをダウンロードする（約3 MB）。
2. ソーシャルネットワークのAPIに接続し、必要なデータを受信します。
3. ゲームサーバーでの承認とリソースの読み込み。

不可抗力の状況はあらゆる段階で発生する可能性があるため、それらを監視します。 外部インターフェイスを使用するゲームクライアントは、各ステップの結果（成功と失敗の両方）についてキャンバスに通知します。 キャンバスには、送信された情報が保存される小さなjavascript-libraryが含まれています。 すべてのロード手順が完了すると、データがサーバーに送信されます。

これに基づいて、システムの設計における主要なタスクを簡単に説明し、そのための以下の要件を強調できます。

• 多数の同時リクエストの処理-リクエストへの通知と最速の応答。
• IPアドレスによるユーザーの国および地域のリアルタイムの決定。
• 時間の経過とともに拡大または補足される可能性のあるさまざまなデータのロギング、およびリアルタイムを含む集約された統計の提供。
• 同時に接続された多くのクライアントにリアルタイムで統計情報を提供します。

明らかに、オンライン監視のための情報を迅速に提供し、動的に拡張するには、システムがデータをキャッシュできる必要があります。 データは継続的に受信され、国や地域に関する統計はいつでも必要になる可能性があるため、通知が到着したときに地理情報を判断する必要があります。

また、クライアント側でデータを更新し、同時リクエストでサーバーの負荷を更新するという問題もありました。 サーバーから統計を表示するには、何らかの方法でデータを取得する必要があります。そのために、通常、いわゆるロングポーリングテクノロジーを使用します。

ロングポーリングテクノロジーを使用する場合、クライアントはサーバーにAjaxリクエストを送信し、サーバーに新しいデータが表示されるのを待ちます。 データを受信すると、サーバーはそのデータをクライアントに送信し、その後クライアントは新しいリクエストを送信して再び待機します。 問題が発生します：複数のクライアントがそのようなリクエストを同時に処理し、それらのクライアントで処理されるデータの量が膨大になるとどうなりますか 明らかに、サーバーの負荷は劇的に増加します。 ほとんどの場合、同じリクエストがサーバーに送信されることを知っているため、サーバーが一意のリクエストを一度処理して、データをユーザーに送信することを望みました。 つまり、プッシュ通知メカニズムが使用されました。

ツールとテクノロジーの選択

ゲームクライアントからの着信要求に対して、従来のASHXハンドラーを使用して、アプリケーションのサーバー部分を.netアーキテクチャに実装することが決定されました。 このようなハンドラーは、.netアーキテクチャーでWeb要求を処理するための基本的なソリューションであり、要求がWebサーバーのIISパイプラインをすばやく通過するという事実により、長い間使用され、迅速に機能していました。 「ピクセル」を介して送信されたクライアントからのリクエストを処理するハンドラーが1つだけ必要です。 これは、1x1イメージがクライアントに挿入され、URLがサーバーに必要なデータを転送するように構成されている場合のアプローチを指します。 したがって、通常のGET要求が行われます。 サーバー側では、そのようなリクエストごとに、IPアドレスで地理情報を特定し、キャッシュとデータベースにデータを保存する必要があります。 これらの操作は「高価」です。つまり、一定の時間が必要です。 したがって、非同期ハンドラーを使用します。要求に応じて、データ検証のみが期待され（高速）、その後、非同期処理のためにデータがキューに入れられ、応答がクライアントにすぐに生成されます。

データストレージには、NoSQLデータベース（MongoDB）を選択しました。これにより、Code Firstの原則に基づいてエンティティを格納できます。つまり、データベース構造はコード内のエンティティによって決定されます。 さらに、データベース構造を毎回変更することなく、エンティティを動的に変更できます。これにより、クライアントから送信された任意のオブジェクトをJSON形式で保存し、それらからさまざまな選択を行うことができます。 さらに、新しいデータ型の新しいコレクションを動的に作成できます。これは、水平スケーリングに最適です。 実際、一意の追跡オブジェクトはそれぞれそのコレクションに保存されます。

クライアントからのリクエストを分析した結果、異なるクライアントからの同じリクエストの大多数がサーバーに送信され、特定の場合にのみ異なることがわかりました（たとえば、リクエスト基準を変更する場合）。 lond pollingに代わるものとして、 Webソケット （WebSocket）を使用することを決定しました。これにより、双方向のクライアントとサーバーの対話を編成し、チャネルを開いたり閉じたり状態を変更する要求のみを送信できます。 したがって、クライアント-サーバー要求の数が削減されます。 このアプローチにより、サーバー上のデータを一度更新し、すべてのサブスクライバーにプッシュ通知を送信できます。 その結果、サーバー側でイベントがトリガーされると、データが即座に更新され、サーバーで処理されるリクエストの数が削減されます。
さらに、Webサーバーを直接使用せずに（たとえば、サービス内で）作業を整理できます。また、クロスドメインリクエストとセキュリティに関する些細な問題もなくなります。

通知処理

非同期ハンドラーはボックス化されたソリューションです。非同期ハンドラーを作成するには、IHttpAsyncHandlerからクラスを継承し、必要なメソッドとプロパティを実装するだけで十分です。 ラッパーは、IHttpAsyncHandlerを実装する抽象クラス（HttpTaskAsyncHandler）として実装しました。 IAsyncResultはタスクを介して実装されました。 その結果、HttpTaskAsyncHandlerには、HttpContextを取得してタスクを返す必要な実装メソッドが1つ含まれています。

public abstract Task ProcessRequestAsync(HttpContext context); 

非同期ASHXハンドラーを実装するには、HttpTaskAsyncHandlerから継承し、ProcessRequestAsyncを実装するだけで十分です。

  public class YourAsyncHandler : HttpTaskAsyncHandler { public override Task ProcessRequestAsync(HttpContext context) { return new Task(() => { //  }); } } 

実際、タスク自体は、次のコンテキストでオーバーライドされたProcessRequestAsyncを介して作成されます。

  public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback callback, object extraData) { Task task = ProcessRequestAsync(context); if (task == null) return null; var returnValue = new TaskWrapperAsyncResult(task, extraData); if (callback != null) task.ContinueWith(_ => callback(returnValue )); //  . return retVal; } 

TaskWrapperAsyncResultは、IAsyncResultを実装するラッパークラスです。

  public object AsyncState { get; private set; } public WaitHandle AsyncWaitHandle { get { return ((IAsyncResult)Task).AsyncWaitHandle; } } public bool CompletedSynchronously { get { return ((IAsyncResult)Task).CompletedSynchronously; } } public bool IsCompleted { get { return ((IAsyncResult)Task).IsCompleted; } } 

EndProcessRequestメソッドは、タスクが完了したことを確認します。

 public void EndProcessRequest(IAsyncResult result) { if (result == null) { throw new ArgumentNullException(); } var castResult = (TaskWrapperAsyncResult)result; castResult.Task.Wait(); } 

非同期処理自体は、ラッパーのContinueWithの呼び出しを通じて発生します。 ASHXハンドラーは新しいものとはほど遠いため、標準的な呼び出しは見苦しくなります：../handlerName.ashx。 その結果、IHttpHandlerFactoryを実装してHandlerFactoryを記述したり、IRouteHandlerを実装してルーティングを記述したりできます。

 public class HttpHandlerRoute<T> : IRouteHandler { private readonly String _virtualPath; public HttpHandlerRoute(String virtualPath) { _virtualPath = virtualPath; } public IHttpHandler GetHttpHandler(RequestContext requestContext) { var httpHandler = (IHttpHandler)BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(T)); return httpHandler; } } 

その後、初期化中に、ハンドラーのルートを設定する必要があります。

 RouteTable.Routes.Add(new Route("notify", new HttpHandlerRoute<IHttpAsyncHandler>("~/Notify.ashx"))); 

通知を受信すると、ジオデータはIPアドレスによって決定され（決定プロセスについては後述します）、情報はキャッシュとデータベースに格納されます。

データキャッシング

キャッシュはMemoryCacheに基づいて実装されます。 周期的であり、インスタンスの存続期間の指定された期間の後、またはメモリ内の指定された量を超えたときに、古いデータを自動的に削除します。 たとえば、.configを使用して、キャッシュを操作および構成すると便利です。

 <system.runtime.caching> <memoryCache> <namedCaches> <add name="NotificationsCache" cacheMemoryLimitMegabytes="3000" physicalMemoryLimitPercentage="95" pollingInterval="00:05:00" /> </namedCaches> </memoryCache> </system.runtime.caching> 

キャッシュ内のデータストレージは分散形式で構成されていたため、一定期間データをすばやく受信できました。 以下はキャッシュ図です：



本質的に、キャッシュはキーと値のコレクションです。 ここで、キーはタイムスタンプ（String）であり、値はイベントのキュー（Queue）です。

キャッシュ内のイベントはキューに入れられます。 各キューには独自の一時キーがあり、この場合は1分です。 その結果、キーは[year_month_day_hour_minute]のようになります。 形式の例：「ntnKey_ {0：y_MM_dd_HH_mm}」。

新しいイベント（通知）をキャッシュに追加すると、一時キーが決定され、キューが検出され、そこに通知が追加されます。 キューが存在しない場合、現在のキーに対して新しいキューが作成されます。 したがって、特定の期間のデータを取得するには、一時キーを決定し、イベントでキューを取得するだけで十分です。 必要に応じて、さらにデータを変換できます。

MongoDBデータベースのデータストレージ

キャッシングと並行して、通知はMongoDBに保存されます。 このデータベースのすべての機能と利点については、公式Webサイトをご覧ください。 現在、さまざまなNoSQLデータベースが存在するため、個人の好みやタスクに基づいて選択する必要があります。 私からは、Mongoとの連携が簡単で快適であり、動的に開発されていること（バージョン3.0が新しいWiredTigerエンジンと共に最近リリースされた）、それを操作するための.netプロバイダーがあり、最適化および更新されていると言いたいと思います。 ただし、NoSQLデータベースの使用は特定の問題を解決するのに適していること、および詳細な分析を行った後にのみリレーショナルデータベースの代わりとして使用することは価値があることは注目に値します。 今日では、大規模アプリケーションでの2つのタイプの使用という、統合されたアプローチがますます登場しています。 典型的なアプリケーション：ロギングメカニズムの置き換え、バックエンドなしでNodeJSと連動、動的に変化するデータとコレクションの保存、CQRS +イベントソーシングアーキテクチャを使用したプロジェクトなど。 複数のコレクションからデータを選択したり、サンプルでさまざまな操作を実行したりする必要がある場合は、リレーショナルデータベースを使用することをお勧めします。



特定のケースでは、MongoDBはうまく機能し、統計のグループ化、循環ストレージ（特別なインデックスを使用してレコードのライフタイムを設定する機能）、およびジオサービス（後述）を使用した高速アップロードに使用されました。

データベースを操作するために、MongoDB C＃/。NETドライバーが使用されました（執筆時点-バージョン1.1、最近リリースされたバージョン2.0）。 一般に、ドライバーは正常に機能しますが、クエリを作成するときにBsonDocumentなどのオブジェクトの面倒な使用を混乱させます。
フラグメント：

  var countryCodeExistsMatch = new BsonDocument { { "$match", new BsonDocument { { "CountryCode", new BsonDocument { {"$exists", true}, {"$ne", BsonNull.Value} } } } } }; 

バージョン1.1は、すでにLINQクエリをサポートしています。

 Collection.AsQueryable().Where(s => s.Date > DateTime.UtcNow.AddMinutes(-1 * 10) .OrderBy(d => d.Date); 

しかし、プロファイラーで分析するときに実際に判明したように、そのような要求はネイティブ（BsonDocument）要求に変換されません。 その結果、コレクション全体がメモリにロードされ、繰り返し処理されますが、パフォーマンスにはあまり適していません。 したがって、BsonDocumentおよびデータベースディレクティブを使用してクエリを記述する必要がありました。 最近リリースされた.NET 2.0ドライバーで状況が修正されることを期待しましょう。

Mongoは一括操作 （複数のインスタンスの挿入/変更/削除）をサポートしています。これは非常に便利で、ピーク負荷にうまく対処できます。 イベントをキューに保存するだけで、N個の通知を定期的に取得し、データベースへの一括挿入を介して保存する作業バックグラウンドプロセスがあります。 必要なのは、スレッドを同期するか、並行コレクションを使用することだけです。

ベースは読み取りモードでは十分に高速ですが、速度を上げるためにインデックスをお勧めします 。 適切なインデックス付けの結果、サンプリングレートが約10倍に増加する可能性があります。 したがって、インデックスを作成すると、データベースのサイズも増加します。

Mongoのもう1つの機能は、可能な限りRAMにロードされることです。つまり、要求された場合、データはRAMに残り、必要に応じてアンロードされます。 データベースで使用可能なRAMの最大値を設定することもできます。
Aggregation Pipelineと呼ばれる興味深いメカニズムもあります。 要求に応じて複数のデータ操作を実行できます。 結果はそのまま伝えられ、各段階で変換されます。
例としては、データを選択してグループ化し、結果を何らかの形式で表示する必要がある場合のタスクがあります。 この問題は次のように表現できます。

選択グループ化規定（$一致、$グループ、$プロジェクト、$ソート）。

以下は、国コードでグループ化されたイベントを選択するためのコードの例です。

 var countryCodeExistsMatch = new BsonDocument { { "$match", new BsonDocument { { "CountryCode", new BsonDocument { {"$exists", true}, {"$ne", BsonNull.Value} } } } } }; var groupping = new BsonDocument { { "$group", new BsonDocument { { "_id", new BsonDocument {{"CountryCode", "$CountryCode"}} }, { "value", new BsonDocument {{"$sum", 1}} } } } }; var project = new BsonDocument { { "$project", new BsonDocument { {"_id", 0}, {"hc-key","$_id.CountryCode"}, {"value", 1}, } } }; var sort = new BsonDocument { { "$sort", new BsonDocument { { "value", -1 } } } }; var pipelineMathces = requestData.GetPipelineMathchesFromRequest(); //   var pipeline = new List<BsonDocument>(pipelineMathces) { countryCodeExistsMatch, groupping, project, sort }; var aggrArgs = new AggregateArgs { Pipeline = pipeline, OutputMode = AggregateOutputMode.Inline }; 

選択の結果はIEnumerableになり、必要に応じてjsonに簡単に変換できます。

  var result = Notifications.Aggregate(aggrArgs).ToJson(JsonWriterSettings); 

データベースを操作する興味深い機能は、JSONオブジェクトをBSONドキュメントに直接保存できることです。 したがって、クライアントからデータベースへのデータの保存を整理することができ、.net環境は、処理するオブジェクトを知る必要さえありません。 同様に、クライアント側からデータベースへのクエリを作成できます。 すべての機能と機能の詳細については、公式ドキュメントをご覧ください。

この記事の次の部分では、リクエストのIPアドレス、Webソケット、ポーリングサーバーの実装、AngularJS、Highchartsによってジオデータを決定し、システムの簡単な分析を行うGeoIPサービスについて説明します。