負荷の高いシステム：主な問題の解決

こんにちは、Habr！



今日は、負荷の高いシステムの使用中に発生する問題の解決策についてお話したいと思います。 この資料で説明することはすべて、私自身の経験でテストされています。私は、ソーシャル、モバイル、ブラウザーゲームを開発するPlariumのソーシャルゲームサーバーチームリードです。



まず、いくつかの統計。 Plariumは2009年からゲームを開発しています。 現在、私たちのプロジェクトは最も人気のあるすべてのソーシャルネットワーク（Vkontakte、My World、Odnoklassniki、Facebook）で開始されており、いくつかのゲームが主要なゲームポータル（games.mail.ru、Kabam）に統合されています。 別に、ブラウザとモバイル（iOS）バージョンの「ルールオブウォー」戦略があります。 データベースには8000万人を超えるユーザー（5ゲーム、7言語でのローカライズ、1日あたり300万のユニークプレイヤー）が含まれているため、すべてのサーバーが1秒あたり平均約6,500リクエストと1日あたり5億6100万リクエストを受信します。



戦闘サーバーのハードウェアプラットフォームとして、4コア（x2 HT）、32〜64 GB RAM、1〜2 TB HDDの2つのサーバーCPUが主に使用されます。 サーバーはWindows Server 2008 R2を実行しています。 コンテンツは、最大5 Gbpsの帯域幅でCDNを介して配信されます。

開発は、C＃プログラミング言語の.NET Framework 4.5に基づいています。



私たちの仕事の詳細を考えると、システムの安定した機能を確保するだけでなく、システムが負荷の大きなジャンプに耐えることができるようにする必要もあります。 残念ながら、多くの一般的なアプローチと技術​​は高負荷のテストに耐えられず、すぐにシステムのボトルネックになります。 したがって、多くの問題を分析した結果、それらを解決する最適な（私にとっての）方法が見つかりました。 どのテクノロジーを選択し、どのテクノロジーを放棄したかを説明し、その理由を説明します。





NoSQLと リレーショナル



この戦いで、純粋なNoSQLは弱い戦闘機であることが判明しました。当時存在していたソリューションは、健全なデータの一貫性をサポートせず、転倒に対して十分な抵抗力がなかったため、プロセスで感じられました。 結局、選択はリレーショナルDBMSにかかったため、必要な場所でトランザクション性を使用できるようになりましたが、一般的には、NoSQLが主なアプローチとして使用されます。 特に、テーブルは非常に単純なキーと値の構造を持っていることが多く、データはJSONの形式で提示され、BLOB列にパック形式で格納されます。 結果として、スキームはシンプルで安定したままですが、データフィールドの構造は簡単に拡張および変更できます。 奇妙なことに、これは非常に良い結果をもたらします-私たちのソリューションでは、両方の世界の利点を組み合わせました。



ORM vs. ADO.NET



純粋なADO.NETのオーバーヘッドは最小限であり、すべてのリクエストは手動で作成され、使い慣れており、魂を温めるという事実を考慮して、ORMはディープノックアウトに送信されます。 そして、すべての理由は、オブジェクトリレーショナルマッピングには、低パフォーマンスや低クエリ制御（またはその欠如）など、多くのマイナスがあるためです。 多くのORMソリューションを使用する場合は、ライブラリを長時間頻繁に使用する必要があり、主なものである速度が失われます。 また、クライアントライブラリのタイムアウトなどを正しく処理するためのトリッキーなフラグについては、ORMを使用してこのようなフラグを設定することを想像しようとすると、完全にイライラします。



分散トランザクションと 最終的な一貫性



トランザクションの主な目的は、操作の完了後にデータの一貫性を確保することです。 変更は正常に保存されるか、何か問題が発生した場合は完全にロールバックされます。 そして、もし1つの基地の場合に、これが間違いなく重要なメカニズムであることを喜んで使用した場合、高負荷での分散トランザクションは最高ではないことがわかりました。 使用の結果、待機時間が長くなり、ロジックが複雑になります（ここでは、アプリケーションインスタンスのメモリ内のキャッシュを更新する必要性、デッドロックの可能性、物理的な障害に対する耐性が低いことを思い出します）。

その結果、メッセージキュー上に構築された独自のバージョンの結果整合性を提供するメカニズムを開発しました。 その結果、スケーラビリティ、障害に対する回復力、一貫性の適切な開始時間、デッドロックの欠如が得られました。



SOAP、WCFなど 対 JSON over HTTP



既製のSOAPスタイルのソリューション（標準の.NET、WCF、Web APIなどのWebサービス）を使用すると、不十分な柔軟性が検出され、さまざまなクライアントテクノロジの構成とサポートで問題が発生し、追加のインフラストラクチャ仲介者が登場しました。 データを処理するために、JSONをHTTP経由で送信することを選択しました。これは、その最大の単純さだけでなく、そのようなプロトコルを使用して問題を診断および修正するのが非常に簡単だったからです。 また、この単純な組み合わせは、クライアントテクノロジーを最も広くカバーしています。



MVC.NET、Spring.NET vs. 裸のASP.NET



私の経験に基づいて、MVC.NET、Spring.NET、および類似のフレームワークは、最大のパフォーマンスの圧縮を妨げる不必要な中間構造を作成すると言うことができます。 私たちのソリューションは、ASP.NETが提供する最も基本的な機能の上に構築されています。 実際、エントリポイントはいくつかの一般的なハンドラです。 単一の標準モジュールは使用せず、アプリケーションにアクティブなASP.NETセッションは1つありません。 すべてが明確でシンプルです。



自転車について少し



問題を解決するための既存の方法がどれも適切でない場合は、少し発明者になり、質問への回答を再検索する必要があります。 そして、たとえあなたが時々車輪を再発明したとしても、この自転車がプロジェクトにとって重要であれば、それは価値があります。

JSONシリアル化



CPUを使用する時間の3分の1以上がJSON形式の大量のデータのシリアル化/非シリアル化に費やされているため、このタスクの有効性の問題は、システムパフォーマンス全体のコンテキストで非常に重要です。

当初、作業ではNewtonsoft JSON.NETを使用しましたが、特定の時点で、その速度が十分ではなく、必要なサブ機能の機能をより高速に実装できるという結論に達しました。 JSONスキーマ、JObjectでの逆シリアル化など。



したがって、データの詳細を考慮して、シリアル化を独自に作成しました。 同時に、テストで得られたソリューションは、JSON.Netの10倍、fastJSONの3倍の速度でした。



私たちにとって重要なのは、Newtonsoftを使用してシリアル化された既存のデータとの互換性でした。 互換性を確保するために、本番環境にシリアル化を含める前に、いくつかの大規模なデータベースでテストしました：JSON形式でデータを読み取り、ライブラリを使用して逆シリアル化し、再びシリアル化してソースと最終JSONの等価性を確認しました。



記憶



データを整理するためのアプローチのため、大きなオブジェクトの大きすぎるヒープ（大きなオブジェクトヒープ）という形でマイナスの影響がありました。 比較のために、そのサイズは、第2世代のオブジェクトの400〜500メガバイトに対して平均約8ギガバイトでした。 その結果、以前に割り当てられたブロックのプールを使用して、大きなデータブロックを小さなブロックに分割することで、この問題を解決しました。 このスキームのおかげで、多くの大きなオブジェクトが大幅に削減され、ガベージコレクションの発生頻度が低くなり、簡単になりました。 ユーザーは満足しており、これは重要です。



メモリを使用する場合、異なるサイズの複数のキャッシュを異なるエージングおよび更新ポリシーで使用しますが、一部のキャッシュの設計は非常にシンプルで、飾り気のないものです。 その結果、すべてのキャッシュの効率指標は90〜95％以上です。



Memcachedをテストした後、私たちは将来のために延期することにしました。 まだ必要ありません。 一般に、結果は悪くありませんが、全体的なパフォーマンスの向上は、キャッシュにデータを配置する際の追加のシリアル化/逆シリアル化のコストを超えませんでした。



追加のツール



•プロファイラー

使い慣れたプロファイラーは、アプリケーションに接続するとアプリケーションの速度を大幅に低下させ、実際に十分にロードされたアプリケーションのプロファイリングを不可能にするため、パフォーマンスカウンターのシステムを使用します。







このテストケースは、名前付きのカウンターで基本操作をラップすることを示しています。 統計はメモリに蓄積され、他の有用な情報とともにサーバーから収集されます。 コールチェーン分析のカウンター階層がサポートされています。 その結果、同様のレポートを取得できます。







肯定的な側面の中で：



-カウンターは常にオンです。

-最小コスト（CPUが使用するリソースの0.5％未満）;

-プロファイルされたセクションの識別へのシンプルで柔軟なアプローチ。

-エントリポイント（ネットワーク要求、メソッド）のカウンターの自動生成。

-親-子に基づいて表示および集計する機能。

-リアルタイムデータを評価できるだけでなく、メーターの測定値を経時的に保存して、さらに表示および分析することもできます。



•ロギング

多くの場合、これがエラーを診断する唯一の方法です。 作業では、人間が読み取れる形式とJSONの2つの形式を使用しますが、十分なディスク容量があるときに書き込み可能なすべてを書き込みます。 サーバーからログを収集し、分析に使用します。 すべてがlog4netに基づいて行われるため、余分なものは一切使用されず、ソリューションは可能な限りシンプルです。



•管理

管理パネルの豊富なグラフィカルWebインターフェイスに加えて、管理パネルに変更を加えることなく、ゲームサーバーに直接コマンドを追加できるWebコンソールを開発しました。 また、コンソールを使用して、診断用の新しいコマンドを非常に簡単かつ迅速に追加し、オンラインで技術データを取得したり、再起動せずにシステムを調整したりできます。



•展開

サーバーの数の増加に伴い、手動で何かを注ぐことは不可能になりました。 そのため、1人のプログラマの作業のたった1週間で、自動サーバー更新用の最もシンプルなシステムを開発しました。 スクリプトはC＃で記述されていたため、展開ロジックを変更および保守するのに十分な柔軟性がありました。 その結果、非常に信頼性が高くシンプルなツールを入手しました。これにより、重大な状況では数分ですべての運用サーバー（約50）を更新できます。



結論



サーバーに高い負荷をかけながら速度を達成するには、よりシンプルで薄いテクノロジースタックを使用する必要があります。すべてのツールは使い慣れた予測可能なものでなければなりません。 設計は、同時にシンプルで、現在の問題を解決するのに十分で、安全性のマージンがある必要があります。 パフォーマンス制御をキャッシュするには、水平スケーリングを使用するのが最適です。 システムの状態の記録と監視-深刻なプロジェクトの生命維持のために必要です。 また、展開システムは人生を大幅に簡素化し、あなたの神経と時間を節約します。