У нас несколько ДЦ и три тысячи серверов. Того, что вы спрашиваете, для нас просто не нужно, выгоднее иметь свой мини-дц. в котором повторен продакшен в миниатюре.
У нас есть продукт называется jinba — это клиент-сайд агент для pinba (сервер статистики), который собирает client-side статистику. Мониторим всё — в каких странах, какие страницы/сервисы. У Паши Довбуша есть доклады, например вот совсем старенький www.slideshare.net/dppsu/pavel-dovbush-toster. Сеть небольших сайтов — со стороны сервера мониторинг понятно как, а клиента — да так же ониторил бы либо готовые стат-счетчики либо через что-то подобное своё с аггрегацией.
Денвер не используется. Виртуализация используется (docker), но не для девелоперского окружения. Девелоперы работают на специализированной прощадке, где вся инфраструктура продакшена повторена в миниатюре (включая и шардированные базы, и несколько виртуальных датацентров). Касательно отправки контейнера прям с машины девелопера последовательно на стейджинг, а потом в прод — этот проект для нас не актуален, посколько даже при двух релизах в день в релизную ветку попадает код от очень многих девелоперов.
Этот класс продуктов называется «сервера очередей».
В badoo традиционно для transaction-based событий используются mysql-based очереди, потому что они очень просты в отладке и заворачиваются в транзакцию на шардах, т.е. событие или несколько событий либо проходят вместе с изменениями, либо так же вместе откатываются — то есть никогда не происходит не-целостных состояний. В противном случае куча граблей. Если кролик слишком сложен, вы можете использовать очереди через списки в Redis.
Если говорить о системах Business Intelligence, то у них есть грубо три компонента: (1) собственно сбор данных и ETL (extract-transform-load), (2) хранилища данных и (3) аналитические инструменты и отчеты. Какие-то области перекрываются, но по сути, это три разных сегмента со своей жизнью, своими продуктами и рынками. У нас есть свои разработки, недавно мы внедрили собственный ETL-фреймворк, который позволил значительно упростить разработку рутинных компонент (фактически, язык сценариев). Но стратегически мы выступаем как пользователи, которые хотят построить систему и хотя бы года три ничего не менять, на наших объёмах это правда очень затратно по всем статьям. Могу сказать, что в Badoo сейчас второе поколение BI-системы за 4 года, сейчас: транспорт построен через Scribe + множественные утилиты собственного производства для (1), Hadoop и колоночная база Exasol для (2), MicroStrategy для (3). Где-то используется не MicroStrategy, а собственная визуализация поверх D3 (и производных от D3).
Zabbix, Pinba, сбор разных метрик и анализ аномалий поверх. Проблема «кто должен чинить» как правило из-за того, что у нас недостаточно данных, чтобы определить точно, в каком компоненте проблема и привлечь к работе конкретных людей. У нас почти никогда такой проблемы не стоит — этим и отличается хороший мониторинг от плохого. Хуже, когда замечена аномалия в продуктовых показателях — но тут всегда копает команда, которая отвечает за соответствующий продуктовый компонент.
Нагрузочное тестирование — это миф. Лучше выкатывать на части аудитории и использовать мониторинг, чтобы обнаружить проблемы — latency на серверной или клиентской стороне, slow queries, запросы не по индексам и тд. А кривая архитектура не должна проходить ревью.
Плавающая нагрузка в смысле новостной сайт и выборы президента США? Это единственный сегмент, где вопрос действительно стоит остро, причем здесь весь выбор идет между стоимостью владения своей инфраструктурой и удобством аренды чужого облака: чем сложнее приложение тем выгоднее иметь его на своем кластере с точки зрения operations. Простой формулы нет, надо просто садиться и считать, что выгоднее по деньгам.
Вопрос по адресу, но не до конца понятно, в чём конкретно у вас проблема: не влезают данные? Это странно — одного терабайта (стандартный диск) должно хватить на годы. Не нравится делать специальные аналитические таблички? Не бойтесь, это нормально. Короче, поясните, пожалуйста, вопрос.
Если объект изменяется часто — кеш неэффективен независимо от того, как вы сделали кеширование. Если нужна псевдо-консистентность, есть достаточно стандартные паттерны — через тот же cas, блокировки на базах, как Вы написали выше. Не уверен, что есть какой-то стандартный «метод», но таких паттернов всего ничего.
да, реализован через gitphp, со своими доработками и оптимизациями habrahabr.ru/company/badoo/blog/200946/, организован через кастомный jira-flow.
картинка выше — толстенный троллинг для тех, кто в танке.
Мы считаем, что лучше что-то сделать руками, но полностью прогнозируемо, чем автоматически, но хз как. В самой автоматизации нет ценности, вопрос в том, какие риски и трудности она снимает. Нужно ли вам уходить от ручных перераспределений — решать вам, я вашего процесса и характера годовой нагрузки не знаю. Мы в какой-то момент всё-таки решили, что нам ужно перераспределение нагрузки для оффлайн-скриптов — мы сделали облачное решеное (потратили кучу времени, к сожалению, но получилось вроде бы полезно и удобно). Каждая группа разработки получает часть облака в пользование (чтобы не мешать другим группам), внутри рапределение нагрузки и «перетекание» скриптов с ноды на ноду при отказах происходит автоматически.
Упираемся в проц и кое-где в память, реже в диск. Отсюда требования по железу — зависит от того, в какой кластер оно пападает, но если грубо, то обычные тачки делятся на «база» и «не-база». Базам просто идут в нагрузку хорошие диски. Ядро, кажется, патчили патчами от гугла (сетевой стек, лучше сишники ответят). Бесполезна рекомендация использовать одинарные кавычки вместо двойных (простите, какой вопрос — такой и ответ).
Процесс разработки и подходы давно устоялись, нужды описывать архитектуру именно с точки зрения реализации до начала работ по самой реализации часто просто нет, это адовые затраты. Перед передачей задачи в разработку пишется только PRD — как всё должно работать с продуктовой точки зрения, с макетами и тд — это позволяет не только убрать проблемы при переключении ответственности на разработку, но пораньше подключать фронтенд, BI, тестирование, переводчиков. Для внутренних и инфраструктурных задач часто даже PRD не пишется, таким образом программист становится продуктовым совладельцем (в этом есть и плюсы и минусы, но надо понимать что здесь продукт — это не сайт, а наши инструменты по мониторингу, анализу проблем, веб-интерфейсы к облачной инфраструктуре и тд). Go в продакшене есть, причем уже в некоторых очень важных местах, с GC у него всё так же («нам норм»), но тут наверное лучше ответят сишники.
Все проблемы решаются удалением кеша при любом изменении в базе + в ряде случаев нужны-таки блокировки или операции, содержащие блокировку неявно, или lock-free подходы, но таких ситуаций вообще меньшинство, поэтому делать эти операции по умолчанию — зло, так как этот метод по-моему «заумен» и чреват ошибками, тяжелой отладкой, делает каждую транзакцию более «тяжелой». Ещё здесь есть ньюансы для нескольких ДЦ (инвалидация закешированных данных со слейвов в «чужом» дц), но это уже такие частности, на которые наступает 0%. Спасибо за вопрос!
вот тут мини-дц за ресепшеном img-fotki.yandex.ru/get/6511/2438272.13/0_7a2c2_d052677f_XL
чтобы рассказать про процесс коммнтария мало, да и очень много уже рассказывали — смотрите посты в корпоративном блоге и доклады с sqadays, рит, loveQA
например
habrahabr.ru/company/badoo/blog/190572/
или тут profyclub.ru/docs/220
В badoo традиционно для transaction-based событий используются mysql-based очереди, потому что они очень просты в отладке и заворачиваются в транзакцию на шардах, т.е. событие или несколько событий либо проходят вместе с изменениями, либо так же вместе откатываются — то есть никогда не происходит не-целостных состояний. В противном случае куча граблей. Если кролик слишком сложен, вы можете использовать очереди через списки в Redis.
картинка выше — толстенный троллинг для тех, кто в танке.