スタックオーバーフローアーキテクチャ

これがどのように機能するかを理解するために、スタックオーバーフローメトリックから始めましょう。 したがって、以下は2013年11月12日と2016年2月9 日の統計です 。





1日あたり6,100万件のリクエストが追加されたにもかかわらず、ASP.Netでの処理時間が2013年（757時間）に比べて大幅に短縮された理由を尋ねることができます。 これは、2015年初頭の機器の近代化と、アプリケーション自体のパラメーターの一部の変更の両方が原因で発生しました。 パフォーマンスが私たちの特徴であることを忘れないでください。 機器の特性について詳しく話してほしいなら、問題ありません。 次の投稿では、サイトを提供するすべてのサーバーの鉄の詳細な仕様があります。



では、過去2年間で何が変わったのでしょうか？ 一部のサーバーとネットワーク機器の交換に加えて、それほど多くはありません。 以下は、リソースを提供するハードウェア部品の拡大リストです（2013年と比較して違いが強調されています）。

• 4つのMicrosoft SQL Server（2つの新しいハードウェア）;
• 11 IIS Webサーバー（新しい機器）;
• 2台のRedisサーバー（新しい機器）;
• 3台のTag Engineサーバー（3台中2台の新しい機器）;
• 3つのElasticsearchサーバー（古いもの）。
• 4 HAProxyロードバランサー（CloudFlareをサポートするために2つ追加）;
• 2つのFortinet 800Cファイアウォール（Cisco 5525-X ASAの代わり）。
• 2台のCisco ASR-1001ルータ（Cisco 3945ルータの代わり）。
• 2台のCisco ASR-1001-xルーター（新規！）。

Stack Overflowを実行するには何が必要ですか？ このプロセスは2013年以降あまり変更されていませんが、最適化と新しいハードウェアにより、必要なWebサーバーは1つだけです。 これは望ましくありませんでしたが、何度か正常にチェックされました。 私はそれを明確にします：私はそれが機能すると宣言します。 毎回かなりおかしいように見えますが、これ（単一のWebサーバーでSOを実行する）が良いアイデアだと言っているのではありません。



スケールの概念に関するいくつかの数字が得られたので、それをどのように行うか見てみましょう。 完全に分離して動作するシステムはほとんどないため（また、私たちのシステムも例外ではないため）、特定のアーキテクチャソリューションは、これらのパーツが相互にどのように相互作用するかの一般的なイメージがなければほとんど意味がないことがよくあります。 この記事の目的は、この全体像をカバーすることです。 その後の多数の投稿で、個々の領域の詳細が示されます。 これは、当社の「ハードウェア」の主要な機能のみのロジスティックレビューであり、その場合にのみ、次の投稿で詳細に検討されます。



今日の機器の外観を理解していただくために、2015年2月の変換中に撮影されたラックAの写真（彼女の「姉妹」ラックBと比較して）の一部をお持ちします。







そして、逆説的に、その週以来、私のアルバムにはさらに255枚の写真があります（合計256枚、はい-これは乱数ではありません）。 それでは、機器を見てみましょう。 メインシステムの相互作用の論理図を次に示します。

基本的なルール

普遍的に適用可能ないくつかのルールがあるので、システムごとに繰り返しはしません。

• すべてが予約されています。
• すべてのサーバーとネットワークデバイスは、少なくとも2 x 10 GB /秒のチャネルで相互接続されています。
• すべてのサーバーには、2つの発電機と2つのネットワーク回線に接続された2つのUPSからの2つの電源入力と2つの電源があります。
• ラックAとラックBの間のすべてのサーバーには、冗長パートナーがあります。
• すべてのサーバーとサービスは、別のデータセンター（コロラド州）を通じて2回バックアップされますが、ここではニューヨークについて詳しく説明します。
• すべてが予約されています。

インターネットで

最初に私たちを見つける必要があります-これはDNSです。 DNSサーバーは世界中のほぼすべてのDNSに近いため、私たちを見つけるプロセスは迅速でなければなりません。そのため、 CloudFlareにこれを任せています（現在）。 APIを介してDNSレコードを更新し、DNSのホスティングを行います。 しかし、私たちは（他者に対する）根深い信頼の問題を抱えた「ブレーキ」であるため、独自のDNSサーバーも持っています。 黙示録が発生した場合（おそらくGPL、 Punyon、またはキャッシュが原因）、人々はそれを考えないようにプログラムしたい場合は、それらに切り替えます。



「秘密の隠れ家」を見つけると、HTTPトラフィックは4つのインターネットプロバイダー（ニューヨークのレベル3、Zayo、Cogent、Lightower）の1つ、および4つのローカルルーターの1つを通過します。 最大の効率を達成するために、プロバイダーと一緒に、BGP（かなり標準）を使用してトラフィックを管理し、その伝送のいくつかの方法を提供します。 ASR-1001およびASR-1001-Xルーターは2ペアで結合され、それぞれがアクティブ/アクティブモードで2つのプロバイダーにサービスを提供します。 したがって、冗長性を提供します。 それらはすべて同じ10 Gbpsの物理ネットワークに接続されていますが、外部トラフィックは、ロードバランサーにも接続されている独立した外部VLANを経由します。 ルーターを通過した後、トラフィックはロードバランサーにルーティングされます。



2つのデータセンター間では10 Gb / s MPLS回線を使用しますが、これはサイトのメンテナンスとは直接関係ありません。 バッチ送信が必要な場合に、データを複製して迅速に復元するのに役立ちます。 「しかし、ニック、これは予約ではありません！」はい、技術的にはあなたは正しい（絶対に正しい）：これは私たちの評判の唯一の「スポット」です。 しかし、ちょっと待ってください！ プロバイダーを通じて、さらに2つのフォールトトレラントOSPFラインがあります（MPLSのコストで-1番、これらは2と3です）。 上記の各デバイスは、コロラド州の対応するデバイスにより速く接続され、障害が発生した場合、バランスの取れたトラフィックをデバイス間で分散します。 4つの方法で両方のデバイスを両方のデバイスに接続することができましたが、それらはすべて同等に優れています。



どうぞ

ロードバランサー（ HAProxy ）

ロードバランサーは、Linuxの推奨バージョンであるCentOS 7の HAProxy 1.5.15で動作します。 HAProxyは、TLS（SSL）トラフィックも制限します。 HTTP / 2をサポートするために、まもなくHAProxy 1.7の注意深い学習を開始します。



10 Gbps LACPを介したデュアルネットワーク接続を備えた他のすべてのサーバーとは異なり、各ロードバランサーには外部ネットワーク用とDMZ用の2組の10 Gbpsチャネルがあります。 より効率的なマネージドSSLネゴシエーションのために、これらのボックスには64 GB以上のメモリがあります。 より多くのTLSセッションをメモリにキャッシュして再利用できる場合、同じクライアントとの新しい接続の作成に費やされる時間が短縮されます。 これは、セッションをより速く、より低いコストで再開できることを意味します。 RAMからドルへの変換はかなり安いので、これは簡単な選択です。



ロードバランサー自体は非常にシンプルなデバイスです。 さまざまなサイトがさまざまなIPに「座って」（主に認証とDNS管理に関して）幻想を作成し、主にホストヘッダーに基づいてさまざまな出力バッファーにルーティングします。 私たちが行う唯一の「有名な」ことは、速度制限とHAProxy syslogメッセージへのヘッダーのキャプチャ（Webサイトレベルから送信）です。 したがって、各リクエストのパフォーマンスメトリックを記録できます。 これについては後で説明します。

Webサイトレベル（IIS 8.5、ASP.Net MVC 5.2.3、および.Net 4.6.1）

ロードバランサーは、「プライマリ」（01〜09）と呼ばれる9台のサーバーと、「Dev / meta」（2〜11個のサイトの環境）と呼ばれる2台のWebサーバーのトラフィックを調整します。 プライマリサーバーは、Stack Overflow、Careers、最後の2台のサーバーでホストされているmeta.stackoverflow.comとmeta.stackexchange.comを除くすべてのStack Exchangeサイトなどを管理します。 メインのQ＆Aアプリケーションは、それ自体がマルチユーザーです。 これは、1つのアプリケーションがすべてのQ＆Aサイトのリクエストを処理することを意味します。 別の言い方をすれば、1つのサーバー上の1つのアプリケーションプールでQ＆Aネットワーク全体を管理できます。 キャリア、API v2、モバイルAPIなどのその他のアプリ 別々に投稿。 これは、IISのメインおよび開発レベルの外観です。







これは、Webサイトレベルでのスタックオーバーフローの分布がOpserver （内部ダッシュボード）のように見える方法です。







...そして、これは負荷に関してWebサーバーがどのように見えるかです：







次の投稿では、なぜ「過剰装備」なのかについて触れますが、最も重要なポイントは、リングビルド（ローリングビルド）、運用リザーブ、冗長性です。

サービスリンク（IIS、ASP.Net MVC 5.2.3、.Net 4.6.1およびHTTP.SYS）

これらのWebサーバーは、非常によく似た「サービスリンク」に基づいています。 また、Windows 2012R2の下のIIS 8.5で実行され、内部サービスを担当し、Webサイトおよびその他の内部システムの計算レベルをサポートします。 2つの主要な「プレーヤー」があります。タグエンジンを実行し、http.sys（IISの下ではない）に基づく「スタックサーバー」と、プロビデンスAPI（IIS上で実行）です。 楽しい事実：Stack Serverは2分ごとに質問のリストを更新するときにL2およびL3キャッシュを「詰まらせる」ため、これら2つのプロセスのそれぞれに一致するマスクを設定して、異なるプロセッサーに登録する必要があります。



これらのサービス「ボックス」は、9倍ではなく冗長性が必要な場合に、タグエンジンと内部APIを上げる責任のある作業を実行します。 たとえば、データベース（現在は2）からすべての投稿とそのタグをダウンロードします。これらはn分ごとに変更されますが、それほど「安く」はありません。 この9回すべてをWebサイトレベルにダウンロードしたくありません。 3回で十分であり、これにより十分な「セキュリティ」が提供されます。 さらに、ハードウェアレベルでは、これらの「ボックス」をさまざまな方法で構成し、タグエンジンの計算負荷と柔軟なインデックス作成のさまざまな特性（ここでも機能します）により最適化されるようにします。 タグエンジン自体は比較的複雑なトピックであり、別の投稿が専用になります。 ハイライト：/質問/タグ付き/ javaに移動すると、タグエンジンをロードして関連クエリを決定します。 検索プロセスの外部ですべてのタグマッチングを行うため、新しいナビゲーションやその他すべてでこれらのサービスを使用してデータを処理します。

キャッシュとパブ/サブ（ Redis ）

ここでは、Redisをいくつかの用途に使用していますが、Redisが大きく変わることはほとんどありません。 1か月あたり約1,600億回の操作にもかかわらず、CPU負荷は常に2％未満です。 通常ずっと低い：







Redisには、L1 / L2キャッシュシステムがあります。 「L1」は、Webサーバーまたは実行中のアプリケーションのHTTPキャッシュです。 「L2」は、値の選択のためのRedisを指します。 値は、Marc Gravellのprotobuf-dot-netを介してProtobuf形式で保存されます。 クライアントには、オープンソースプロジェクトであるStackExchange.Redisを使用します。 1つのWebサーバーがL1またはL2のキャッシュミスを受信すると、ソース（データベースクエリ、APIコールなど）からサンプルを取得し、ローカルキャッシュとRedisの両方に結果を配置します。 サンプリングが必要な次のサーバーは、L1の「キャッシュミス」を受信する可能性がありますが、L2 / Redisで検出され、データベースクエリまたはAPI呼び出しを保存します。



また、多くのQ＆Aサイトがあるため、各サイトには独自のL1 / L2キャッシングがあります。L1のキープレフィックスとL2 / RedisのデータベースIDです。 この問題については、次の投稿で詳しく検討します。



サイトへのすべてのリクエストを管理する2つのメインRedisサーバー（マスター/スレーブ）とともに、2つのより特殊なサーバー（メモリにより）で実行される機械学習システムもあります。 推奨クエリをホームページに表示したり、検索結果を改善したりするために使用されます。 プロビデンスと呼ばれるこのプラットフォームは、ケビンモントローズによって管理されています。



メインのRedisサーバーにはそれぞれ256 GBのRAMがあり（約90 GBが使用されます）、Providenceサーバーには384 GBのRAMがインストールされています（約125 GBが使用されます）。



Redisはキャッシュの操作に使用されるだけでなく、「パブリッシュ＆サブスクライバー」アルゴリズム（パブリッシュおよびサブスクライブ）も備えており、1つのサーバーがメッセージを送信し、他のすべての「サブスクライバー」がメッセージを受信します（Redisスレーブサーバーのダウンストリームクライアントを含む） 。 1つのWebサーバーが一貫性を維持するために削除を行う場合、このアルゴリズムを使用して他のサーバーのL1キャッシュをクリアします。 しかし、別の重要な用途があります：websockets。

Websocket（ NetGain ）

Websocketを使用して、通知、投票数、新しいナビゲーション計算、新しい回答やコメントなど、リアルタイムの更新をユーザーに送信します。



ソケットサーバー自体は、サイトレベルで実行される生のソケットを使用します。 これは、オープンライブラリStackExchange.NetGainの上にある非常に小さなアプリケーションです。 ピーク負荷時には、同時に約500,000の並列Webソケットチャネルが開いています。 これは多数のブラウザーです。 面白い事実：これらのページの一部は18か月以上前に開かれました。 理由はわかりません。 これらの開発者がまだ生きているかどうかを誰かが確認する必要があります。



これは、今週開かれたWebSocketの数が今週どのように変化したかです：







なぜwebsocketなのか？ 私たちの規模では、ポーリングよりもはるかに効果的です。 このようにして、使用するリソースを減らし、より迅速に、より多くのデータをユーザーに転送できます。 しかし、一時的なポートとロードバランサー上のすべてのファイル記述子の完全な列挙は重大な問題ではありませんが、それらにも問題があります。 それらについては後で説明します。

検索（ Elasticsearch ）

ネタバレ：これは夢中になるものではありません。



ウェブ層は、非常に薄く、非常に効率的なStackExchange.Elasticクライアントを使用するElasticsearch 1.4と比較して、確実な検索ジョブを実行します。 他のほとんどのツールとは異なり、使用するAPIの非常に小さなサブセットのみを反映しているという理由だけで、一般公開する予定はありません。 開発者間の混乱のために、一般に公開することは良いことよりも害をもたらすと確信しています。 検索、関連クエリの計算、質問の作成方法に関するヒントにElasticを使用します。



各Elasticクラスター（各データセンターに1つあります）には3つのノードがあり、各サイトには独自のインデックスがあります。 キャリアには、いくつかの追加のインデックスがあります。 これにより、システムが少し非標準になります。3つのサーバークラスターは、これらすべてのSSDストレージ、192 GBのメモリ、チャネルあたり10 Gbit / sのデュアルネットワークでもう少し「ポンプ」されています。



Tag EngineがインストールされているStack Server内の同じアプリケーションドメイン（ここでは.Net Coreに触れます...）もElasticsearchの要素に継続的にインデックスを付けます。 ここでは、Elasticのドキュメント「last position」と比較して、 SQL Server （データソース）のROWVERSIONなどのいくつかのトリックを適用します 。 シーケンスのように動作するため、最後のパス以降に変更された要素を使用してインデックスを作成するだけです。



全文SQL検索に似たものの代わりにElasticsearchに決めた主な理由は、スケーラビリティとお金のより良い分配です。 SQL CPUは非常に高価ですが、Elasticは安価であり、今日でははるかに優れた機能を備えています。 なぜSolrを使わないのですか？ ネットワーク全体（一度に多くのインデックス）を検索したいのですが、決定を下した時点ではこれはSolrによってサポートされていませんでした。 まだ2.xに切り替えていないのは、 「タイプ」の割合が大きいためです。そのため、更新のためにすべてのインデックスを再作成する必要があります。 計画を立て、移行に必要な変更を加えるのに十分な時間がありません。

データベース（SQL Server）

信頼できる情報の唯一のソースとしてSQL Serverを使用しています。 すべてのElasticおよびRedisデータはSQLサーバーから受信されます。 AlwaysOn可用性グループの下にSQLサーバーのクラスターが2つあります。 これらの各クラスターには、1つのマスター（ほぼ全体の負荷を実行）と1つのニューヨークのレプリカがあります。 さらに、コロラド州には別のレプリカがあります（動的コピーを備えたデータセンター）。 すべてのレプリカは非同期です。



最初のクラスターは、それぞれが384 GBのRAM、4 TBのPCIe SSD、2 x 12コアを備えたDell R720xdサーバーのセットです。 スタックオーバーフロー、サイト（悪名高い、後で説明します）、PRIZM、およびモバイルデータベースがあります。



2番目のクラスターは、それぞれが768 GBのRAM、6 TB PCIe SSD、2 x 8コアを備えたDell R730xdサーバーのセットです。 他のすべてはこのクラスター上にあります。 「その他すべて」のリストには、キャリア、オープンID、チャット、例外ログ、およびいくつかのQ＆Aサイト（たとえば、スーパーユーザー、サーバー障害など）が含まれます。



データベースレベルでCPUを使用することは避けることをお勧めしますが、実際には、現在解決しているキャッシュの問題のために、現在わずかに増加しています。 現在、NY-SQL02および04は指定されたマスターであり、01および03は、SSDの更新後に今日リロードしたレプリカです。 過去24時間は次のようになります。







SQLは非常に単純に使用します。 簡単です-高速です。 いくつかのクエリは非常識かもしれませんが、SQLとの対話自体は古典的なものです。 「古代の」 Linq2Sqlが1つありますが、すべての新しい開発では、 POCOを使用するオープンソースのMicro-ORMであるDapperを使用しています。 別の言い方をしましょう。StackOverflowにはデータベースに1つのプロシージャしか格納されておらず、その最後の部分をコードに変換するつもりです。

図書館

さて、あなたを直接助けることができるものに切り替えましょう。 上記のこれらのことのいくつか。 ここでは、世界中で使用できるようにサポートしている最もオープンな.Netライブラリのリストを提供します。 これらはビジネスにとって重要な価値を持たないため、パブリックドメインに配置しますが、開発者の世界を支援することができます。 それらが役に立つことを願っています：

• Dapper （.Net Core）-ADO.Net用の高性能Micro-ORM。
• StackExchange.Redis-高性能のRedisクライアント。
• MiniProfilerは、すべてのページで使用する小さなプロファイラーです（Ruby、Go、およびNodeのみをサポート）。
• 例外的 -SQL、JSON、MySQLなどのエラーロガー
• Jilは高性能（de）JSON シリアライザーです。
• Sigil-.Net CIL生成アシスタント（C＃が十分に高速でない場合）;
• NetGain-高性能websocketサーバー。
• Opserver-ほとんどのシステムを直接ポーリングし、Orion、Bosun、またはWMIからデータを受信するコントロールダッシュボード。
• Bosunは、Goで書かれたサーバー側のデータベース監視システムです。

以下は、当社のソフトウェアが動作する利用可能なハードウェアの詳細なリストです。 それから先に進みます。 私たちと一緒に。