Yandex.Moneyバックエンドの分析部分では、Microsoft IISが積極的に使用されており、共有したい高負荷環境でのアプリケーションに関する知識がすでに蓄積されています。

当社の分析は、Microsoftスタック（ SQL ServerおよびSSIS、SSAS、SSRS製品）で実行されます。これは、市場で最高のBIソリューションの1つです。 BIは単一ベンダーのサービスに基づいているため、WebアプリケーションをホストするためにMicrosoftのIISソリューションを使用することは論理的です。

記事では、負荷の高い環境で一般的なIIS上で実行されるアプリケーションを操作する機能について説明します。

まず、「高負荷」に関するアイデアをあなたと同期させます。 負荷の高いシステムの例として、この記事では主に不正防止保護システム（不正防止）を使用しています。 すべての着信Yandex.Money操作を処理します-これは1秒あたり100操作ではありません。

＃1リクエストごとの最小操作、すべてが難しい-サービスを開始する

ユーザーリクエストの処理から、ロギング、他のサービスへの呼び出し、および応答に不要なその他すべてを除外することが重要です。 マイナーアクションは、メインスレッド外の並列プロセスで実行できます。 サービスに特定のSLA応答がある場合、このルールへの準拠は特に重要です。

「しばらく」初期化されたものはすべて、ユーザーからの最初の要求が到着したときにこれを行うべきではありません。 最も重要な詐欺防止サービスの1つである不正防止-かつて、新しいリクエストハンドラーの開始時にルールセット全体を読み込む必要がありました。

新しいパケットが到着すると、そのコンテンツを長いルールセットで渡す通常のネットワークファイアウォールを想像してください。 不正防止の場合にのみ、それらのルールと条件の数は、サービスの応答性を大幅に低下させることなく、次の処理フローが開始するたびにすべてをロードすることが不可能なボリュームに達しました。 不正防止のピーク負荷では、プロセッサの負荷は数分間で100％に達しました。

さらに、長時間の初期化には、パフォーマンスの連鎖的な低下が伴います。 最初のリクエストが到着すると、不正防止はそれに対する別のハンドラを作成し、そこにセキュリティルールのリスト全体をロードします。ユーザーは少し待つよう申し出を賞賛します。

既製のハンドラーに十分なリソースがない場合にユーザー要求に応答する前のプロセス。

ここで、前のハンドラーのルールのロードが完了していないが、他のユーザーからの翻訳のリクエストが到着したと想像してください。 それぞれに対して同様の操作が開始され、このような重複した初期化が多数発生する可能性があります。 これにより、インターフェイスの定期的な遅延が30秒以上になりました。

したがって、ルールを持つオブジェクトのみが作成され、メインサービスと一緒に起動のためにハングアップしました。 現在、ハンドラーは数ミリ秒で起動し、サーバー全体のパフォーマンスに影響を与えません（10％以内のスパイク）。 当初は、起動を進めることを考えていましたが、各ハンドラーのクイックスタートを考慮すると、これはパフォーマンスに顕著な影響を与えません。

もちろん、これで停止する価値はありません。システムのすべてのレベルで最適化を導入する必要があります。 ちなみに、ルールを処理する際に、基本的なメカニズムを修正し、ロジックとサーバーによってルールをオンラインとオフラインに分割しましたが、この話は将来、別の話に値します。

＃2関連するクエリと異なるノードを忘れないでください

サーバーファームの操作に関しては、ユーザーセッションを特定のノードにバインドするようにアプリケーションに教えるか、異なるノードに来る論理的に接続された要求を正しく処理する必要があります。

フォールトトレランスとユーザーの幸福の観点からセッションを1つのノードに結び付けるのは間違っているため、クラスターノードのいずれかが「同僚」の要求の結果を知るように、すぐに同期システムを構築することをお勧めします。 これは多くの方法で行うことができます。例えば：

1. すべてのクエリの必要な結果が保存されているすべてのノードに共通のデータベースを使用します。 重要な点は、すべての要求がそのようなデータベースに保存されるわけではなく、他のノードで役立つ可能性があるものだけです-アプリケーションの開発時にこれを忘れないでください。 アーキテクチャ上、このようなデータベースは簡単にボトルネックになる可能性があるため、そのパフォーマンスを慎重に監視する必要があります。 たとえば、通常のディスクからSSDディスクに時間を切り替えます。
2. このタスクをクライアントに転送します。 つまり、前の関連リクエストの結果が次のリクエストに含まれるように構築します。
3. 最後に、プロセスごとに2つの要求がないようにアプリケーションアーキテクチャを構築できます。 関連するクエリはありません-問題ありません。

たとえば、ソースアカウントが開かれたときにいつ支払いを行うかを知りたいです。 これを行うには、アカウント自体を開く操作を見つけるか、後で使用するために一部のデータを個別に保存する必要があります。 この例では、オプション1のみが使用されます。

＃3ウォームアップまたはウォームアップしない

アプリケーションは常に起動する必要があり、実際のリクエストが表示される前に、起動自体を事前に行う必要があります。 さらに、受信メッセージを最小限の遅延ですぐに処理するために、サービスはテスト要求で既に「ウォームアップ」されている必要があります。

これは、アンロードされたプロセスが定期的に停止するため、デフォルトのIIS設定によって部分的に防止されます。 外部からの最初の関連するリクエストで自動的に起動される場合でも、アプリケーションには初期初期化、関連するリクエストの処理などの時間が必要になります。

以前は、いずれかのノードで30分ごとに1回Webアプリケーションが再起動されていました。 そのため、バランサーのサービスから負荷を取り除き、アプリケーションをリロードし、数十のリクエストを起動するPowershellスクリプトを作成しました。 その後、スクリプトは初期化を待機しており、アプリケーションが十分迅速に応答し始めると、サーバーに「戦闘」トラフィックを返しました。 ただし、再起動のスケジュールは短縮されますが、アルゴリズムは引き続き適切です。

したがって、プロセスを開始またはWebアプリケーションを再起動する前に、負荷を別のサーバーに切り替え、新しく起動したサーバーがウォームアップするのを待ってから、それを受信処理に含める必要があります。

＃4適切なスレッド数の選択

IISには、ディスク、ネットワークなどを操作するための限られたサービスストリームセットがあります。これらのストリームは、ほとんどのユーザーリクエストの処理に使用され、ある時点でサービスストリームのリソースが不足する場合があります。

IISには、パフォーマンスを制限する可能性がある2つの主要なスレッド設定があります。

• キューの長さ -着信リクエストのキューの長さを調整します。

  
  
  
  
  
  
  
• ワーカープロセス -アプリケーションの独立したコピーの数。 価値についての普遍的なアドバイスはありませんので、あなたの環境で実験的に正しいものを選ぶ必要があります。

さらに、Webアプリケーション側のDBMSクライアントで設定されるデータベース接続プールパラメータがあります。 ここでは、非常に慎重に値を選択する必要があります。そうしないと、データベースへのアイドル接続が多くなり、それぞれがメモリを消費します。

サービスのものに加えて、WorkerThreadsがあります-サーバーアプリケーションが同じ不正防止の新しいハンドラーを開始するために使用するものだけです。 これらのフローは、作業に必要な数だけ正確に配布することが望ましいです。 パラメーターは、次のアルゴリズムを使用して大まかに計算できます。

1. 特定のシステムの特性から、単位時間あたりのクエリ数を取得します。 たとえば、この例では、この値は支払いシステム全体の支払い回数に線形に依存します。
2. 各リクエストの時間単位の数を実験的に調べることをお勧めします-たとえば、アプリケーションのログインを有効にすることによって。 IISログも役立ちます。リクエスト自体とタイムスタンプの両方があります。
3. フロー数の下限は、項目1と項目2を乗算することにより得られます。

計算がうまくいかない場合は、単に最大値を設定するのは得策ではないため、テスト環境で実験を行うことをお勧めします。 サーバーリソースを浪費し、IISの初期化時間を増やします。

もちろん、このアルゴリズムは、アプリケーションを正確に評価するための出発点としてのみ考えることができます。 たとえば、環境内の潜在的なピークは考慮されません。 完全な評価を行うには、この記事の範囲を明らかに超えている他の多くのパラメーターを考慮する必要があります 。

リソースについて言えば、64ビットアプリケーションの安定した動作は、メインアプリケーションの崩壊まで、 32ビット用にコンパイルされた補助ライブラリによって防止できます。 64ビットアプリケーションをデバッグする場合、Microsoft VisualStudio 2012（およびそれ以前）のIISエミュレータは32ビットであり、64ビットモードでのデバッグにはIISインスタンスを使用する必要があるため、適切ではないことを忘れないでください問題。

＃5クラスター全体のアプリケーション割り当て

操作の観点から、Yandex.Money詐欺対策には1 + Nクラスターが必要です。このクラスターでは、ノードの数に関係なく、一度だけ変更を加えることができます。 したがって、適切な「ロールアウト」ロジックを選択する実験により、次のアルゴリズムが作成されました。

1. いずれかのノードから負荷が削除された後、更新プログラムがインストールされます。
2. アプリケーションの健全性チェックが実行されます（システム結果の監視、ログの表示など）。
3. このスクリプトは、近隣の実稼働サーバーからアプリケーションのリモートバックアップを実行し、リリースを他のマシンに配布します。 この場合、負荷は切断されません。

監視といえば。 もちろん、アプリケーションごとにアプローチは異なりますが、ツールの1つとしてIISログ解析を使用します。 1日1回、Microsoft LogParserを使用してログをスキャンするスクリプトが実行され、応答時間の平均時間、数、および比率（500、200など）を含むレポートが生成されます。 システムの現実のためだけにコードが追加されすぎているため、コード自体はアップロードしません。 しかし、記事LogParser、PowerShell、およびIISファイルの高速でダーティな構文解析のアイデアが基礎として使用されました。

事前にディスク上のアプリケーション割り当て構造を統一することが重要です。 つまり、各サーバーの同じフォルダーにサイトを配置すると、さらに自動化が簡単になります。 IISファームを機能させるには 、すべてのノードの単一のIIS構成を保存するための共有構成が必要です。これは、スクリプト同期を使用して各サーバーのローカルドライブに配置するのが最適です。

共有構成をネットワークフォルダーに配置すると、「特殊効果」が発生する可能性があります。たとえば、IISは構成を読み取ってすべてのアプリケーションを消滅させることはできません。

また、一般データのリポジトリ（この場合、不正防止ルール）が必要になる場合があります。 これを行うには、DFS同期を使用すると便利です。アプリケーションはホスト上のローカルフォルダーで動作し、このフォルダーのデータはDFSを使用して残りのマシン上で同期されます。 耐障害性を高め、アップグレードを容易にするために、多対多の同期スキームを使用できます。

バランスについてのもう少しの言葉

分散および高負荷システムの重要な要素は、着信リクエストのバランサーです。 たとえば、ユーザーからフロントエンドシステムへのリクエスト。 このようなバランサーには、次の2つのタイプがあります。

1. 「フィードバック」なし-内部バランサーアルゴリズムは、受信した要求フローをクラスターノード間で単純に分散します。 代表的な例は、Windows Serverに組み込まれたNLBサービスです。 隣接ノードが動作しているかどうかのみをチェックし、アプリケーションの状態については何も知りません。 このサービスは負荷分散に非常に柔軟性があり、コマンドラインから制御できますが、1つのローカルネットワークでのみ機能します。
2. ノードの状態を評価し、逸脱がある場合に要求を再配布する、よりインテリジェントなバランサー。 たとえば、Webサーバーからの送信リクエストには、クラスター内のすべてのノードを定期的にポーリングし、このデータに基づいてリクエストを配布するHaproxyを使用できます。

MicrosoftのWebサーバーを使用すると、同じメーカーのアプリケーションスタックと開発を使用するユーザーにとって便利です。 アプリケーションが大きなデータ構造を必要としない場合、ホストのメモリ消費は最小限になります。 さらに、必要なオプションと機能のほとんどがすぐに使用できるため、オープンソースでアナログを組み立てるよりも明らかに簡単です。

アプリケーションが同じ.Netで記述されている場合-なぜ「外国の」プラットフォームで戦いながらそれを起動するのですか？