А вы верно подметили по поводу космического корабля. Правда для меня, космический корабль Хабра уже создан и запущен. Своей задачей вижу тут наладку процесса безболезненного обслуживания и модернизации этого корабля еще в течение хотя бы лет 20-30. =)
Спасибо за замечание. Про "эйджизм" согласен — убрал из заголовка путающее уточнение. Дополнительно во вступлении уточнил что именно имелось ввиду под этими более чем 10 годами жизни кода.
Действительно вначале была идея с иллюстрацией кодом. Даже, вроде, получилось раскопать пару примеров, которые не требовали бы копания в git-истории. Но после вставки этих примеров в текст они выглядели скорее какой-то вкусовщиной, нежели иллюстрацией моих слов. А что бы они приобрели действительно иллюстрирующую функцию пришлось бы выгружать много контекста, что уже сильно размывало бы смысл самой статьи (IMO).
По поводу "было/стало" могу сказать что удалось уменьшить сложность (cyclomatic complexity) с ~18 (для старого) до ~3.5 (для нового). А добились этого при помощи следующих шагов:
с пристрастием подошли к разделению зон ответственности нашего текущего MVC-паттерна
для уровня M (model) применили луковую архитектуру (onion architecture)
внедрили в разработку принципы DDD (в том или ином виде)
Обычно в таких системах кто-то должен стать первым и запустить процесс =ъ Само собой, магическим образом, оно никогда не начнётся. Вообще формулировки про "если всем..., по почему мне..." способствуют именно тому положению дел, которое так всех раздражает. Да и странная это "команда" получается. Поэтому что бы разорвать эту порочную связь лучше думать на тему "а что я могу сделать, что бы...". И не всегда это могут быть прямые действия в один ход.
Например для начала можно:
общаться в команде на тему качества кода, создавая общий вектор
выделять и фиксировать самые раздражающие места и доносить до всех
договариваться и фиксировать планы по рефакторингу
регулярно подсвечивать проблему качества кода на ретро и общих встречах с управлением и при планировании
время от времени самом вносить минорные правки по качеству
Так причина боязни "трогания" не в отсутствие тестов, а в отсутствие понимания как это все работает.
Грубо говоря тесты даже если и есть, но ты не понимаешь как оно работает внутри, то и решения будут приниматься соответствующие: тяп-ляп сбоку или дублирующая функциональность или "нам срочно только тут". В итоге и тесты есть и код работает, а все вместе начинает пованивать (code smell) со временем все больше и больше.
Владение в данном случае призвано блюсти чистоту и своевременную передачу знаний касательно кода, что бы с ним было удобно и приятно работать.
Аха, всё верно на счёт формального владения. В статье как раз говорится о том, как владение в полном смысле этого слова вырождается в формальное и приводит к печальным последствиям.
Для меня интересным и близким к моей реальности тут было то, что показан процесс деградации ответственности и озвучены причины. Как говорится "предупреждён, значит вооружён". )
Моя боль сейчас сосредоточена именно на максимальном возможном упрощении передачи знаний и устранения единоличного владения внутренними проектами компании.
В интервью говорится о дельте новых данных в сутки, а не общей нагрузке. Если говорить о сопоставимых цифрах, то у нас запросов (в сутки) к БД сейчас ~25-30M.
0. Не очень ясно почему многих волнуют вопросы связанные именно с БД, т.к. нигде не говорится о том, что у нас это узкое место. Упираемся мы в настоящее другом месте, а именно забивание app-слоя и media-хранилища по CPU. Вопрос на который я пока, к сожалению, не могу дать ясного ответа. Итак.
1. Всегда начинаем с нормальной формы, а затем исходя из необходимости делаем денормализацию.
1. Индексы стараемся делать своевременно и по запросам. «Старые» таблицы уже точно полностью покрыты необходимыми индексами. Проверяем по explain и не стесняемся использовать force index.
2. Проблема размера заключается в том, что архивные данные (более полугода) также являются актуальными и могут быть использованы наравне с горячими (до полугода). Все проблемы, с которыми мы сталкивались касательно БД заключались именно в том, что она переставала помещаться в памяти и тогда начинали случаться дикие тормоза, особенно в те моменты, когда кто-то из пользователей решает внимательно полазить по архивам или профилям.
3. Схему данных выдать не смогу, долго рисовать. Могу сказать, что у нас сейчас используется более 100 таблиц. Практически не пользуемся left/inner join. Что касается логирования запросов, то есть возможность включить «дебаг-режим» для каждой страницы и увидеть лог её «сборки» (включая выполняемые на странице запросы, время их исполнения и общее время генерации). В настоящее момент среднее время генерации страниц 0.1-0.3 с. Время sql запросов исчисляется тысячными долями (исключение составляют фоновые неоптимизированные статистические методы). Для наиболее частых выборках реализовано кеширование.
4. Запросов с полным сканированием данных почти нет. Стараемся не допускать такие моменты или терпим до тех пор пока в таблице мало данных. Для полнотекстового поиска везде в проекте используется sphinx.
5. Расскажу как было. Когда переехали и всё настроили, протестировали — открылись. И тут же повисли. Начали разбираться в чём дело и увидели, что iostat показал загрузку системного диска в 100%. Притом, что нагрузка была такая же как и раньше или даже меньше, а «железо» вроде даже с небольшим запасом. Начали исследовать и получили следующие данные: системный диск ~3 Мб/c, «временный» ~300-400 Мб/c, подключаемый blob-storage ~50-100 Мб/c. Оговорюсь сразу, что это замеры 2-3 летней давности, сейчас может быть что-то поменялось. Когда разнесли всё на «временный» и подключаемый blob-storage — всё начало работать.
6. Не факт что БД на Win будет работать резвее, потому как вроде как системный и временные диски там используются те же. Плюс поддержка, настройка под продакшн: никогда с этим не сталкивался, только в локальных dev средах.
7. Делать репликацию на временный диск нецелесообразно, так как велика вероятность не восстановить slave после ребута/ресайза инстанса. Но как решение для экономии допустимо, если научиться slave плодить как кроликов с актуальными данными. Правда в таком случае всё равно, мне кажется, экономия скорее будет касаться blob-хранилища, а не размера инстанса.
Спасибо за понимание. Вы всё верно говорите. Да, действительно колокейшен будет выходить дешевле, но в итоге на его полноценное обслуживание потребуется отдельный человек со своей стоимостью и итоговые цены на поддержку инфраструктуры окажутся сопоставимыми. Например текущую конфигурацию можно собрать и за половину цены, но тогда ещё же должен появиться человек, который всё это правильно соберёт, настроит и будет поддерживать.
По поводу возникающего недопонимания касательно стоимости и запросов (sic!): статистика запросов, которая приведена в статье, — это не общая статистика проекта, а кол-во прироста новых данных в сутки. Видимо это не так очевидно оказалось?
Повторюсь, статистика приведённая в статье — это примерная статистика ежедневного добавления записей в базу, а не суммарная нагрузка. Когда отвечал в этом интервью думал какие дать показатели для иллюстрации и решил для наглядности ограничиться дельтой прироста данных в сутки (к тому же это даёт ещё и представление об активности самого сервиса).
Если рассчитывать коллокейшн с необходимым железом, то получается (рассчитывал в своё время) примерно 1/3 стоимости — это если брать всё впритык, если с запасом — уже ~1/2. И это только само железо, а ещё его настройка и конфигурация потребуют специалиста, которого у нас просто нет, а собственных знаний в этом деле, увы, недостаточно.
Это конечно вопрос холиварный: collocation vs cloud. =) Правда издержки на самом деле распределяются по разному. В одной песочнице они идут на специалиста(ов), который всё это поднимает, настраивает, обслуживает. А в другой на стоимость услуги. В итоге оно выходит примерно эквивалентно.
Что касается предложенной конфигурации, то сказать сходу не могу (в виртуализации не силён): тут наверное надо смотреть и сравнивать конкретные показатели. Что-то мне подсказывает, что может не хватить.
Надеюсь что не придётся. В целом сейчас добываемых денег почти хватит, как раз чтобы там остаться (за вычетом некоторых фич сервиса) + мы активно работаем в этом направлении.
Про медленные диски согласен — говорил об этом, — но в целом это решаемо.
В нашем случае ещё стоит помнить о том, что с Azure сейчас мы не тратимся на специалиста по обслуживанию и поддержке инфраструктуры (увы у нас не хватает собственных компетенций в этом). А если переезжать, то такой человек по-любому понадобится, а это получатся сопоставимые средства.
Сорри, что ввёл в заблуждение по поводу кол-ва A7 и БД.
A7 у нас только один. Такой размер вынужденный из-за размера базы. Общий размер БД сейчас наверное уже >60Gb, а шаг доступной памяти в инстансах 14-28-52. Два других инстанса под БД на A5 и A3 соответственно. CPU нагрузка на них сейчас ~5-7%. Очевидно что это с явным запасом.
Но замечу, что даже если сразу размазывать данные равномерно и постепенно, то по себестоимости будет это равноценно, например, 1xA7 = 2xA6 = 4xA5 и т.д.
Про ресурсы, которые тратятся на обслуживание не понял, уточните пожалуйста.
Не перепутали, всё верно. И да, стоит признать, что некоторые ресурсы могут использоваться не на все 100%, об этом чуть ниже. Но я нигде не говорил, что узкое место в проекте — это БД и что упираемся мы именно в неё? Почему вдруг только это обсуждается в данном случае? Да и примеры о кол-ве запросов на хост хотелось бы видеть с учётом некоторых дополнительных данных: хотя бы общий размер БД и примерная стоимость такого решения (с учётом всех издержек). =\
Хинт: Все проблемы, которые возникали с БД были связаны только с тем, что размер базы переставал помещаться в память, а так как диски очень медленные для подобного рода задач, то приходилось вертикально масштабировать инстанс, чтобы решать эту проблему.
Чтобы не быть голословным вот стоимость Azure VM (https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux) в пересчёте на текущую архитектуру проекта (без учёта стоимости трафика ~15-20 тыс. руб. и стоимость использования хранилищ ~2-5 тыс. руб.):
a7 — 46.5 тыс. руб.
a5 — 11.6 тыс. руб
a3x4 — 44,8 тыс. руб
a2x5 — 28 тыс. руб
Средняя загрузка CPU от 5 до 60%
PS: Да согласен, что можно сэкономить довольно приличную сумму (думаю до 20 тыс. рублей), если перевести инстансы на D-серию, но они появились уже после того как проект был развёрнут и почему-то когда смотрел цены (в своё время!) — они были дороже A-серии. Как только дойдут руки до оптимизации инфраструктуры, обязательно подробно изучу этот момент.
В настоящий момент используется грант BizSpark.
Что касается модели монетизации, то активно работаем в этом направлении. В настоящий момент есть:
— контекст (~75%)
— меценатские взносы (~20%)
— платные услуги (~5%)
Про конфигурацию сказал чуть выше в комментарии. Если нужно детальнее, то могу ответить в личке.
Текущая архитектура представлена в статье (на схеме). Всего в продакшене используется 11 инстансов (без тестовыx).
Самые толстые — под БД (3 шт), самые дешёвые — под почтой и кешем. Максимальная конфигуация — Standard_A7, минимальная — Standard_A2.
Примерно 15% стоимости уходит на оплату трафика.
Про CDN знаю и согласен, что можно при помощи него сэкнонмить и получить прирост по скорости загрузки статики, но пока голова и руки не дошли.
Признаться неясно что такое «средний сервер» и как он должен «справляться» в предлагаемой вами конфигурации. Есть ли какие-либо более явные примеры того, о чём вы говорите? Буду признателен.
Про «порядки» цен не согласен. Пересчитывали цены на collocation в Hetzner (правда в конце прошлого года) — получалось впритык (без запаса) примерно 1/3 текущей стоимости. И это только голое железо без какой-либо настройки. И как правильно заметили в комментарии, что грамотный специалист сейчас будет стоить прилично (сопоставимо с обсуждаемой конечной стоимостью).
PS: Вдруг подумал о том, чтобы в обозначенной цитате возможны разночтения. Тут речь идёт о кол-ве ежедневном приросте данных в сутки, а не общем их объёме. Верно?
Чувствительные данные храним на подключаемых blob-storage дисках — там скорость выше. Если данные не критичные — то используем локальный диск. Кстати где-то на хабре недавно читал про use-case одного из проектов, где им удалось повысить производительность дисковой подсистемы путём «правильного» подбора параметров форматирования дисков. Это может быть интересно.
1. Это будет скорее «коленочным» решением ad hoc. Не хочется заниматься таким, потому что в последствии поддержка такой структуры может быть очень утомительной. Мне кажется куда легче и полезнее разработать хотя бы начальный API и на базе него начинать уже строить внешние приложения и в том числе и мобильную версию (для совместимости).
2. А для чего структура базы, если доступ к ней в любом случае напрямую не будет доступен (в целях безопасности, сохранения целостности). Ведь структура базы лишь опосредованно связана со логикой приложения.
А вы верно подметили по поводу космического корабля. Правда для меня, космический корабль Хабра уже создан и запущен. Своей задачей вижу тут наладку процесса безболезненного обслуживания и модернизации этого корабля еще в течение хотя бы лет 20-30. =)
Спасибо за замечание. Про "эйджизм" согласен — убрал из заголовка путающее уточнение. Дополнительно во вступлении уточнил что именно имелось ввиду под этими более чем 10 годами жизни кода.
Действительно вначале была идея с иллюстрацией кодом. Даже, вроде, получилось раскопать пару примеров, которые не требовали бы копания в git-истории. Но после вставки этих примеров в текст они выглядели скорее какой-то вкусовщиной, нежели иллюстрацией моих слов. А что бы они приобрели действительно иллюстрирующую функцию пришлось бы выгружать много контекста, что уже сильно размывало бы смысл самой статьи (IMO).
По поводу "было/стало" могу сказать что удалось уменьшить сложность (cyclomatic complexity) с ~18 (для старого) до ~3.5 (для нового). А добились этого при помощи следующих шагов:
Обычно в таких системах кто-то должен стать первым и запустить процесс =ъ
Само собой, магическим образом, оно никогда не начнётся. Вообще формулировки про "если всем..., по почему мне..." способствуют именно тому положению дел, которое так всех раздражает. Да и странная это "команда" получается. Поэтому что бы разорвать эту порочную связь лучше думать на тему "а что я могу сделать, что бы...". И не всегда это могут быть прямые действия в один ход.
Например для начала можно:
общаться в команде на тему качества кода, создавая общий вектор
выделять и фиксировать самые раздражающие места и доносить до всех
договариваться и фиксировать планы по рефакторингу
регулярно подсвечивать проблему качества кода на ретро и общих встречах с управлением и при планировании
время от времени самом вносить минорные правки по качеству
Так причина боязни "трогания" не в отсутствие тестов, а в отсутствие понимания как это все работает.
Грубо говоря тесты даже если и есть, но ты не понимаешь как оно работает внутри, то и решения будут приниматься соответствующие: тяп-ляп сбоку или дублирующая функциональность или "нам срочно только тут". В итоге и тесты есть и код работает, а все вместе начинает пованивать (code smell) со временем все больше и больше.
Владение в данном случае призвано блюсти чистоту и своевременную передачу знаний касательно кода, что бы с ним было удобно и приятно работать.
Аха, всё верно на счёт формального владения. В статье как раз говорится о том, как владение в полном смысле этого слова вырождается в формальное и приводит к печальным последствиям.
Для меня интересным и близким к моей реальности тут было то, что показан процесс деградации ответственности и озвучены причины. Как говорится "предупреждён, значит вооружён". )
Моя боль сейчас сосредоточена именно на максимальном возможном упрощении передачи знаний и устранения единоличного владения внутренними проектами компании.
0. Не очень ясно почему многих волнуют вопросы связанные именно с БД, т.к. нигде не говорится о том, что у нас это узкое место. Упираемся мы в настоящее другом месте, а именно забивание app-слоя и media-хранилища по CPU. Вопрос на который я пока, к сожалению, не могу дать ясного ответа. Итак.
1. Всегда начинаем с нормальной формы, а затем исходя из необходимости делаем денормализацию.
1. Индексы стараемся делать своевременно и по запросам. «Старые» таблицы уже точно полностью покрыты необходимыми индексами. Проверяем по explain и не стесняемся использовать force index.
2. Проблема размера заключается в том, что архивные данные (более полугода) также являются актуальными и могут быть использованы наравне с горячими (до полугода). Все проблемы, с которыми мы сталкивались касательно БД заключались именно в том, что она переставала помещаться в памяти и тогда начинали случаться дикие тормоза, особенно в те моменты, когда кто-то из пользователей решает внимательно полазить по архивам или профилям.
3. Схему данных выдать не смогу, долго рисовать. Могу сказать, что у нас сейчас используется более 100 таблиц. Практически не пользуемся left/inner join. Что касается логирования запросов, то есть возможность включить «дебаг-режим» для каждой страницы и увидеть лог её «сборки» (включая выполняемые на странице запросы, время их исполнения и общее время генерации). В настоящее момент среднее время генерации страниц 0.1-0.3 с. Время sql запросов исчисляется тысячными долями (исключение составляют фоновые неоптимизированные статистические методы). Для наиболее частых выборках реализовано кеширование.
4. Запросов с полным сканированием данных почти нет. Стараемся не допускать такие моменты или терпим до тех пор пока в таблице мало данных. Для полнотекстового поиска везде в проекте используется sphinx.
5. Расскажу как было. Когда переехали и всё настроили, протестировали — открылись. И тут же повисли. Начали разбираться в чём дело и увидели, что iostat показал загрузку системного диска в 100%. Притом, что нагрузка была такая же как и раньше или даже меньше, а «железо» вроде даже с небольшим запасом. Начали исследовать и получили следующие данные: системный диск ~3 Мб/c, «временный» ~300-400 Мб/c, подключаемый blob-storage ~50-100 Мб/c. Оговорюсь сразу, что это замеры 2-3 летней давности, сейчас может быть что-то поменялось. Когда разнесли всё на «временный» и подключаемый blob-storage — всё начало работать.
6. Не факт что БД на Win будет работать резвее, потому как вроде как системный и временные диски там используются те же. Плюс поддержка, настройка под продакшн: никогда с этим не сталкивался, только в локальных dev средах.
7. Делать репликацию на временный диск нецелесообразно, так как велика вероятность не восстановить slave после ребута/ресайза инстанса. Но как решение для экономии допустимо, если научиться slave плодить как кроликов с актуальными данными. Правда в таком случае всё равно, мне кажется, экономия скорее будет касаться blob-хранилища, а не размера инстанса.
По поводу возникающего недопонимания касательно стоимости и запросов (sic!): статистика запросов, которая приведена в статье, — это не общая статистика проекта, а кол-во прироста новых данных в сутки. Видимо это не так очевидно оказалось?
Это конечно вопрос холиварный: collocation vs cloud. =) Правда издержки на самом деле распределяются по разному. В одной песочнице они идут на специалиста(ов), который всё это поднимает, настраивает, обслуживает. А в другой на стоимость услуги. В итоге оно выходит примерно эквивалентно.
Что касается предложенной конфигурации, то сказать сходу не могу (в виртуализации не силён): тут наверное надо смотреть и сравнивать конкретные показатели. Что-то мне подсказывает, что может не хватить.
Про медленные диски согласен — говорил об этом, — но в целом это решаемо.
В нашем случае ещё стоит помнить о том, что с Azure сейчас мы не тратимся на специалиста по обслуживанию и поддержке инфраструктуры (увы у нас не хватает собственных компетенций в этом). А если переезжать, то такой человек по-любому понадобится, а это получатся сопоставимые средства.
A7 у нас только один. Такой размер вынужденный из-за размера базы. Общий размер БД сейчас наверное уже >60Gb, а шаг доступной памяти в инстансах 14-28-52. Два других инстанса под БД на A5 и A3 соответственно. CPU нагрузка на них сейчас ~5-7%. Очевидно что это с явным запасом.
Но замечу, что даже если сразу размазывать данные равномерно и постепенно, то по себестоимости будет это равноценно, например, 1xA7 = 2xA6 = 4xA5 и т.д.
Про ресурсы, которые тратятся на обслуживание не понял, уточните пожалуйста.
Хинт: Все проблемы, которые возникали с БД были связаны только с тем, что размер базы переставал помещаться в память, а так как диски очень медленные для подобного рода задач, то приходилось вертикально масштабировать инстанс, чтобы решать эту проблему.
Чтобы не быть голословным вот стоимость Azure VM (https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux) в пересчёте на текущую архитектуру проекта (без учёта стоимости трафика ~15-20 тыс. руб. и стоимость использования хранилищ ~2-5 тыс. руб.):
a7 — 46.5 тыс. руб.
a5 — 11.6 тыс. руб
a3x4 — 44,8 тыс. руб
a2x5 — 28 тыс. руб
Средняя загрузка CPU от 5 до 60%
PS: Да согласен, что можно сэкономить довольно приличную сумму (думаю до 20 тыс. рублей), если перевести инстансы на D-серию, но они появились уже после того как проект был развёрнут и почему-то когда смотрел цены (в своё время!) — они были дороже A-серии. Как только дойдут руки до оптимизации инфраструктуры, обязательно подробно изучу этот момент.
Что касается модели монетизации, то активно работаем в этом направлении. В настоящий момент есть:
— контекст (~75%)
— меценатские взносы (~20%)
— платные услуги (~5%)
Про конфигурацию сказал чуть выше в комментарии. Если нужно детальнее, то могу ответить в личке.
Самые толстые — под БД (3 шт), самые дешёвые — под почтой и кешем. Максимальная конфигуация — Standard_A7, минимальная — Standard_A2.
Примерно 15% стоимости уходит на оплату трафика.
Про CDN знаю и согласен, что можно при помощи него сэкнонмить и получить прирост по скорости загрузки статики, но пока голова и руки не дошли.
Признаться неясно что такое «средний сервер» и как он должен «справляться» в предлагаемой вами конфигурации. Есть ли какие-либо более явные примеры того, о чём вы говорите? Буду признателен.
Про «порядки» цен не согласен. Пересчитывали цены на collocation в Hetzner (правда в конце прошлого года) — получалось впритык (без запаса) примерно 1/3 текущей стоимости. И это только голое железо без какой-либо настройки. И как правильно заметили в комментарии, что грамотный специалист сейчас будет стоить прилично (сопоставимо с обсуждаемой конечной стоимостью).
PS: Вдруг подумал о том, чтобы в обозначенной цитате возможны разночтения. Тут речь идёт о кол-ве ежедневном приросте данных в сутки, а не общем их объёме. Верно?
2. А для чего структура базы, если доступ к ней в любом случае напрямую не будет доступен (в целях безопасности, сохранения целостности). Ведь структура базы лишь опосредованно связана со логикой приложения.