Хотелось бы заявить, что Stack Overflow — масштабный проект, но это не верно. Я имею ввиду мы добились многого, но я не могу назвать отечественный проект “громадным”, ещё рано. Давайте я приведу в пример кое-какие цифры — с какой нагрузкой мы имеем дело на данный момент.

Срез статистики за 24 часа от 12 ноября 2013 года. Это простой будний сутки. Отмечу, что тут представлена информация лишь по отечественным собственным вычислительным мощностям, без CDN.
Смотрите кроме этого: Ветхая печатная машинка c Arduino и Raspberry Pi в роли принтера

Не обращая внимания на то, что выпуск печатных машинок прекратили во всех государствах мира (имеются в виду печатные машинки старого типа, без электронных компонентов), кое-какие умельцы еще применяют эти «устройства» в собственных проектах. Так, пару дней назад был представлен проект, сущность которого — превращение печатной машинки, причем древней, в принтер, что употребляется для распечатки твиттер-сообщений интересных пользователей Сети.Само собой, простое «железо» требует некоей доработки, дабы план стал действительностью.

Статистика

• 148,084,883 HTTP запросов к нашему балансировщику нагрузки
• 36,095,312 из них — настоящие загрузки страниц
• 833,992,982,627 байт (776 ГБ) HTTP трафика послано
• 286,574,644,032 байт (267 ГБ) трафика получено
• 1,125,992,557,312 байт (1,048 ГБ) трафика послано
• 334,572,103 SQL запроса по HTTP запросам
• 412,865,051 запрос до Redis серверов
• 3,603,418 запросов до обработчика тэгов (отдельный сервис)
• 558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
• 99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
• 132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
• 2,728,177,045 мс (757 часов) трудились скрипты ASP.Net

Мне в обязательном порядке необходимо будет написать пост о том, как мы эти цифры приобретаем, но эта статистика (не считая трафика) вычислена лишь благодаря HTTP логам. Как оказалось так много часов за сутки? Мы именуем это волшебством.

Большая часть людей именуют это “пара серверов с многоядерными процессорами”, но мы всё списываем на волшебство. Stack Exchange трудится на следующем оборудовании:

• 4 MS SQL сервера
• 11 IIS Веб-серверов
• 2 сервера Redis
• 3 сервера, занимающиеся обработкой тэгов (полностью всё, что касается тегов, к примеру запрос /questions/tagged/c++)
• 3 сервера ElasticSearch
• 2 балансировщика нагрузки (реализация HAProxy)
• 2 свитча (любой на базе Nexus 5596 + Fabric Extenders)
• 2 Файервол Cisco 5525-X ASAs
• 2 Маршрутизатора Cisco 3945

Как вся эта красота выглядит возможно взглянуть на первой фотографии (выше).Мы не просто занимаемся хостингом собственных сайтов. Ближайшая стойка — это сервера для виртулизации (vmware) и запасного инфраструктуры, которая не оказывает влияние на работу сервиса конкретно, к примеру машинки для деплоя, контроллеры домена, мониторинг, дополнительная база данных для администраторов и другое. 2 SQL сервера из перечня выше были резервными серверами до недавнего времени — на данный момент они употребляются для read-only запросов, так что мы можем продолжать масштабироваться, не вспоминая о нагрузке на базы данных еще долго. 2 веб-сервера из того перечня предназначены для разработки и перифирийных задач, по-этому они потребляют мало трафика.Об оборудованииЕсли мы на момент представим, что что-то случилось и вся избыточность инфраструктуры пропала, то целый Stack Exchange может трудиться на следующем оборудовании без утраты в производительности:

• 2 SQL сервера (Stack Overflow на одной машинке, всё другое на другой, не смотря на то, что мы уверены, что они смогут трудиться на одном сервере)
• 2 Веб-сервера (вероятно три, но я верю, что хватит и двух)
• 1 сервер Redis
• 1 сервер для обработки тэгов
• 1 сервер ElasticSearch
• 1 балансировщик нагрузки
• 1 свитч
• 1 ASA брендмауэр
• 1 Маршрутизатор

Нам нужно будет попытаться отключить часть серверов намерено дабы проверить на деле. :)Ниже — средняя конфигурация оборудования:

• SQL сервера трудятся на 384 ГБ ОЗУ с файловым хранилищем в 1.8ТераБайт (SSD)
• Сервера Redis запускаются на машинках с 96 ГБ ОЗУ
• Сервера ElasticSearch — 196 ГБ ОЗУ
• Сервера для обработки тегов требуют самых стремительных процессоров, что мы можем купить.
• Свитчи — 10 ГБит на любой порт.
• Веб-сервера ничем особенным не отличаются — 32 ГБ ОЗУ, 2 четырёхъядерных процессора и 300 ГБ SSD хранилища на любой.
• Сервера, у которых нет сети 2х10Гбит/с (к примеру SQL) подключаются четырьмя соединениями по 1 Гбит/с.

Думается, что 20Гбит/с — через чур много? Да, к примеру SQL сервера в пик не загружают сеть больше, чем на 100-200 Мбит/с, но помните про резервное копирование, перестроение топологии — это пожет пригодиться в любую секунду и тогда сеть будет использована на полную. Такое количество памяти и SSD смогут загрузить данный канал всецело.ХранилищеВ даннй момент у нас приблизительно 2 ТераБайт данных в SQL (1.06/1.16 ТераБайт на первом кластере из 18 SSD и 0.889/1.45 ТераБайт на втором, складывающемся из 4 SSD).

Быть может, необходимо задуматься об тучах, но на данный момент мы используем SSD и время записи в базу равняется практически 0 миллисекундам. С БД в памяти и двумя уровнями кеша перед ней, Stack Overflow имеет соотношение чтения к записи 40 к 60. Да, всё правильно, 60% времени работы базы данных она пишет.На веб-серверах употребляются SSD диски на 320 ГБ в RAID1.Сервера ElasticSearch также снабжаются SSD дисками на 300 ГБ. Это принципиально важно, поскольку в том месте довольно часто выполняется индексация и перезапись.Мы так же не упомянули о SAN.

Это DELL Equal Logic PS6110X с 24 SAS 10K подключением и дисками 2х10 Гбит/с. Употребляется он как хранилище для виртуальных серверов VmWare как облако и не связан с самим сайтом. В случае если данный сервер упадёт, сайты некое время кроме того не будут знать об этом.Что дальше?Что мы будем с этим делать? Мы желаем большей производительности — это крайне важно для нас. 12-го ноября страница загружалась в среднем 28 миллисекунд.

Мы стараемся поддерживать скорость загрузки не продолжительнее 50 миллисекунд. Вот средняя статистика загрузки популярных страниц в данный сутки:

• Страницы вопросов с ответами — 28 миллисекунд (29.7 млн. запросов)
• Профили пользователей — 39 миллисекунд (1.7 мил. запросов)
• Перечень вопросов — 78 миллисекунд (1.1 млн. запросов)
• Домашняя страница — 65 миллисекунд (1 млн. запросов), что весьма медлительно. Мы исправим это в скором будущем.

Мы мониторим скорость загрузки путём записи таймингов. Именно поэтому, мы можем составить весьма наглядный график:Масштабируемость в будущемОчевидно, что все сервисы на данный момент трудятся на низкой нагрузке. Веб-сервера потребляют в среднем 5-15% процессора, 15,5 ГБ ОЗУ, и 20-40 МБит/c полосы сети. Средняя загрузка процессора сервера базы данных — 5-10%, 365 ГБ ОЗУ и 100-200 МБит/с полосы сети.

Именно поэтому мы можем полноценно развиваться и, что крайне важно, мы страхуемся от падения на случай увеличения нагрузки — неточность в коде либо каждый сбой. Вот скриншот из Opserver:Основная обстоятельство того, что нагрузка такая низкая, содержится в эффективности кода. Пускай пост и посвящен второму, но действенный код — критическое место для масштабирования вашего железа в будущем.

Все, что вы сделали, но не должны были делать, будет вам стоить дороже, чем если бы вы этого не сделали вовсе — подобное правило касается и неэффективного кода. Под ценой понимается следующее: энергопотребление, цена железа (по причине того, что вам необходимо больше серверов, либо они должны быть замечательнее), разработчики, занятые попытками понять более сложный код (не смотря на то, что, честно говоря, оптимизированный код не обязательно делается несложнее) и вероятнее медленный рендер страниц — что выражается в реакции пользователя, что не начнёт ждать загрузки еще одной страницы… в противном случае и вовсе больше не зайдет к вам.

Цена неэффективного кода может оказаться значительно выше, чем вам думается.Итак, сейчас мы познакомились с тем, как трудится Stack Overflow на нынешнем железе. В следующий раз мы определим о том, из-за чего мы не торопимся переезжать в тучи.

Случайная статья:

• «Киев-20» — флагман украинской фототехники
• Лучшие визуализации научных данных 2014 года

smle — Overflow (feat. Helen Tess) [Official Lyric Video]

Похожие статьи:

• Программно-конфигурируемые сети — как это работает?

  — Мы принесли вам подключение к современному миру. — Через месяц мы возвратимся с антидепресантами.Пост «какое количество стоит SDN» собрал собственную…

• Летающий динамик с прошедшего ces: как работает aswy

  Чем оптимален CES? — Тем, что в том месте (наподобие как) определяется отечественное технологии и ближайшее будущее, каковые на него повлияют. Чем…

• Квантовый компьютер google работает

  Поисковик уверен в том, что машина D-Wave подтвердила собственные правила работыКвантовые компьютеры — это счётные автомобили, каковые трудятся на базе…