Спасибо, Сергей, за статью! Да, охота знатная получилась :) Это были интересные и продуктивные 13 лет, уверен у Туту.ру много успехов впереди, классная команда собралась!
Не особо — мы знали, что х2 выдержим, а больше не ожидалось по бизнес показателям. Обычно под ожидаемый рост заранее мощностей добавляем. А тут такой Black Swan очередной прилетел
2010 год появления :) sphinx там был, но не давал реального роста производительности конкретно в этой задаче, а сложности с поддержкой все же были. Поэтому ушли от него на родной полнотекст.
С задачей решение справлялось, поэтому не трогали. Сейчас есть задача изменения логики, делаем по красоте.
1. На SR не обсуждаются конкретные фичи. SR это не планирование, а выравнивание ожиданий. Кроме того, фичи выпускает команда, а не конкретный человек, так что это про другое. Скорее как раз будет строится разговор о подходах, что важнее: проверить гипотезу, или сделать высококачественный продукт. И как в таких условиях научится грамотно оценивать сроки.
2. Еще раз, SR не про планирование, а про выравнивание ожиданий. Ожидания в том числе могут быть в том, чтобы научиться предугадывать такие ситуации или сообщать о них незамедлительно, а не в конце месяца, например. В итоге — это вопрос того, что важно для руководителя. Тут вопрос в не в том, что что-то не сделали, а то, почему так произошло, какой опыт извлекли, как не допустить в будущем.
3. Это всегда диалог. Нет норматива, кто и сколько должен сформулировать. По большому счету, SR — это структурированные встречи один-на-один руководителя и сотрудника, с заданным расписанием, чеклистом и форматом для итоговых решений.
Мы на протяжении 2 лет успешно эксплуатируем бесплатный openshift командой из 4 человек, которые занимаются и разворачиванием кластеров, и разработкой нового функционала на основе шифта под нужды наших продуктовых команд. Последний год все наши новые продукты и сервисы запускаются в шифте. По опыту наши потребности он не ограничивает, а пользу приносит. Разработку своих операторов и CRD шифт никак не ограничивает, а нам нужна гибкость в первую очередь с точки зрения автоматизаций процессов. Про существование VMware Tanzu мы конечно знаем, мы как раз строим из себя ентерпрайз, умеющий считать деньги. Решения vmware бюджетными традиционно не бывают — это комбайны с кучей функционала, часто нами не востребованным. Нам эффективнее использовать бесплатные версии продуктов и небольшую команду экспертов, которая адаптирует их под наши потребности.
Начинали мы с кубера в чистом виде. Но постоянно натыкались на сырость: как установить, как настроить, как заставить работать… в шифте же все эти проблемы решены, там все, что нам надо есть из коробки. Т.е. сэкономили время на старте. Пока используем бесплатную версию.
Риск приемлемый :) кстати, саппорт нам понравился у циски, а вот у делла — нет. На это смотрели, да. В том числе по этой же причине почти сразу отмели Нутаникс.
Во-первых, нужны гарантии по задержкам сети, что с публичными сетями бывает проблемой. А во-вторых, и это важнее, оптика дешевле выходит. У нас в одной из локаций был резерв по VPN (делали временно, пока второе плечо оптики вводили). Так вот в момент той самой аварии из статьи, когда в одном колодце пожар, а во втором «какой интересный коннектор», этот гигабитный канал не вытянул. По факту у нас 3-4 Гбит/с между локациями ходит. А такие аплинки дороже оптики получаются.
Основное: уровень требуемой экспертизы для нормальной и надежной работы этих решений. Мы несколько лет назад игрались с кластеризацией поверх обычных серверов, все время что-то шло не так и не туда. Мы же все таки для себя решение строили, а не для зарабатывания на нем. Поставил, запустил и полетели (не так, конечно, получилось, но близко к этому). От начала проекта до выхода в прод 4-5 месяцев получилось, что очень неплохо.
Но как писал в комменте уже, сейчас в проработке проект OpenShift on Bare Metal. Хотим свое облако с микросервисами на обычном железе попробовать разместить.
Мы проводили тесты, сравнивали. Конкретно здесь у нас такой опыт был (цитата из отчета наших инженеров): «Сетевая инфраструктура не утилизирует пропускную способность сети серверов, используя режимы active-backup, в связи с чем страдает как скорость подключения серверов, так и надежность.»
Наверняка есть способы это побороть, но мы искали решение, которое требует меньше танцев с бубном. Кроме того, мы остались не очень довольны уровнем технической поддержки Dell, а это тоже очень важно, когда покупаешь очень дорогое оборудование.
1. У нас было несколько экспериментов с AWS и Google Cloud — мы там брали PaaS решения для быстрых тестов. Но в массовое решение не пошло. В качестве IaaS не рассматриваем из-за наших требований к связности локаций. ФЗ-152 тут играет малую роль, поскольку он только про персональные данные. А кроме них есть еще очень много элементов системы.
2. К моменту появления Я.Облака у нас уже было два провайдера облаков, третий не нужен. Тратить ресурсы на «давайте еще попробуем вот это», когда с действующими поставщиками все нормально, нецелесообразно. Наш проект на своем HCI окупается примерно за год. Я считал NPV на 4 года, сравнивая одинаковые объемы ресурсов в облаке и у себя. Кстати, сейчас мы работаем над проектом OpenShift on Bare Metal: идея в том, чтобы развернуть OpenShift на самом обычном железе, а не на HCI или облаках. Просчитываем варианты, если получится, поделюсь.
3. Тут скорее вопрос целесообразности и экономики. Можно поднять и три, и четыре копии (на некоторых особо критически важных базах так и делаем). Все-таки вероятность одновременного отказа двух сильно ниже, а деньги на инфраструктуру надо выделять. Изначально так и хотели делать (по копии в каждой локации), однако известные события весны этого года скорректировали аппетиты :)
Именно свое железо это 4 стойки в ЦОДах и в офисе еще есть, но чуть поменьше. В основном пара вендоров, но бывали эксперименты с другими производителями, не зашло нам. В целом, строгих ограничений нет, но плодить зоопарк тоже нет желания — хочется без сюрпризов:)
Первое:
Детали, как это работает, потянет на целую статью. Думаю, напишем и про это.
Если коротко. Есть много (под сотню) различных БД с четко ограниченной предметной областью, там используется с master — standby репликация. Еще есть одна большая БД, которую еще не растащили по небольшим базам. Эта БД собрана в «гирлянду», т.е. ветвистое дерево master-slave-slave… В случае падения мастера github orchestrator промоутит (снимает флаг read-only), на его место или единственный standby инстанс, или одну из реплик гирлянды (по хитрым правилам) и перестраивает остальные, чтобы те тянули данные с нового мастера. Proxysql ориентируются на флаг read-only на mysql и меняют состав своих хостгрупп. Сами proxySQL подняты с одним и тем же IP в разных локациях, поэтому при отказе одного, запросы начинают уходить к соседям.
Второе:
Наверное, правильный ответ “так исторически сложилось”. Когда-то давно выбрали MariaDb, с тех пор парк разросся, внутренняя экспертиза прокачалась, а с postgress практического опыта почти нет. Поэтому пока только аккуратно присматриваемся, но не переезжаем.
В обычное время мы пользуемся платной версией OpenVPN — Access Server. В нем пользователям доступны дистрибутивы для всех платформ, с установкой уровня «Далее, далее». Удобнее он и для админов — тот же переход на 2FA происходит выставлением одной галочки. С переходом на удаленку приняли решение вспомнить про бесплатную версию OpenVPN, т.к. лиценизии на AS покупаются на срок от 1 года, а после выхода из карантина такое количество будет просто лежать мертвым грузом. Пришлось расчехлить старые плейбуки, писать инструкции для пользователей как подкладывать конфиги и т.д.
Мы отрефакторили логику, и это дало кратный прирост. Но go позволяет лучше работать с памятью. Наибольший эффект среди всего прочего дало хранение заранее заготовленных (предобработанных) данных в памяти приложения. Такой роскоши в PHP мы себе позволить не могли.
Спасибо, Сергей, за статью! Да, охота знатная получилась :) Это были интересные и продуктивные 13 лет, уверен у Туту.ру много успехов впереди, классная команда собралась!
Количество запросов
Не особо — мы знали, что х2 выдержим, а больше не ожидалось по бизнес показателям. Обычно под ожидаемый рост заранее мощностей добавляем. А тут такой Black Swan очередной прилетел
2010 год появления :) sphinx там был, но не давал реального роста производительности конкретно в этой задаче, а сложности с поддержкой все же были. Поэтому ушли от него на родной полнотекст.
С задачей решение справлялось, поэтому не трогали. Сейчас есть задача изменения логики, делаем по красоте.
2. Еще раз, SR не про планирование, а про выравнивание ожиданий. Ожидания в том числе могут быть в том, чтобы научиться предугадывать такие ситуации или сообщать о них незамедлительно, а не в конце месяца, например. В итоге — это вопрос того, что важно для руководителя. Тут вопрос в не в том, что что-то не сделали, а то, почему так произошло, какой опыт извлекли, как не допустить в будущем.
3. Это всегда диалог. Нет норматива, кто и сколько должен сформулировать. По большому счету, SR — это структурированные встречи один-на-один руководителя и сотрудника, с заданным расписанием, чеклистом и форматом для итоговых решений.
Риск приемлемый :) кстати, саппорт нам понравился у циски, а вот у делла — нет. На это смотрели, да. В том числе по этой же причине почти сразу отмели Нутаникс.
Во-первых, нужны гарантии по задержкам сети, что с публичными сетями бывает проблемой. А во-вторых, и это важнее, оптика дешевле выходит. У нас в одной из локаций был резерв по VPN (делали временно, пока второе плечо оптики вводили). Так вот в момент той самой аварии из статьи, когда в одном колодце пожар, а во втором «какой интересный коннектор», этот гигабитный канал не вытянул. По факту у нас 3-4 Гбит/с между локациями ходит. А такие аплинки дороже оптики получаются.
Основное: уровень требуемой экспертизы для нормальной и надежной работы этих решений. Мы несколько лет назад игрались с кластеризацией поверх обычных серверов, все время что-то шло не так и не туда. Мы же все таки для себя решение строили, а не для зарабатывания на нем. Поставил, запустил и полетели (не так, конечно, получилось, но близко к этому). От начала проекта до выхода в прод 4-5 месяцев получилось, что очень неплохо.
Но как писал в комменте уже, сейчас в проработке проект OpenShift on Bare Metal. Хотим свое облако с микросервисами на обычном железе попробовать разместить.
Наверняка есть способы это побороть, но мы искали решение, которое требует меньше танцев с бубном. Кроме того, мы остались не очень довольны уровнем технической поддержки Dell, а это тоже очень важно, когда покупаешь очень дорогое оборудование.
2. К моменту появления Я.Облака у нас уже было два провайдера облаков, третий не нужен. Тратить ресурсы на «давайте еще попробуем вот это», когда с действующими поставщиками все нормально, нецелесообразно. Наш проект на своем HCI окупается примерно за год. Я считал NPV на 4 года, сравнивая одинаковые объемы ресурсов в облаке и у себя. Кстати, сейчас мы работаем над проектом OpenShift on Bare Metal: идея в том, чтобы развернуть OpenShift на самом обычном железе, а не на HCI или облаках. Просчитываем варианты, если получится, поделюсь.
3. Тут скорее вопрос целесообразности и экономики. Можно поднять и три, и четыре копии (на некоторых особо критически важных базах так и делаем). Все-таки вероятность одновременного отказа двух сильно ниже, а деньги на инфраструктуру надо выделять. Изначально так и хотели делать (по копии в каждой локации), однако известные события весны этого года скорректировали аппетиты :)
Именно свое железо это 4 стойки в ЦОДах и в офисе еще есть, но чуть поменьше. В основном пара вендоров, но бывали эксперименты с другими производителями, не зашло нам. В целом, строгих ограничений нет, но плодить зоопарк тоже нет желания — хочется без сюрпризов:)
Детали, как это работает, потянет на целую статью. Думаю, напишем и про это.
Если коротко. Есть много (под сотню) различных БД с четко ограниченной предметной областью, там используется с master — standby репликация. Еще есть одна большая БД, которую еще не растащили по небольшим базам. Эта БД собрана в «гирлянду», т.е. ветвистое дерево master-slave-slave… В случае падения мастера github orchestrator промоутит (снимает флаг read-only), на его место или единственный standby инстанс, или одну из реплик гирлянды (по хитрым правилам) и перестраивает остальные, чтобы те тянули данные с нового мастера. Proxysql ориентируются на флаг read-only на mysql и меняют состав своих хостгрупп. Сами proxySQL подняты с одним и тем же IP в разных локациях, поэтому при отказе одного, запросы начинают уходить к соседям.
Второе:
Наверное, правильный ответ “так исторически сложилось”. Когда-то давно выбрали MariaDb, с тех пор парк разросся, внутренняя экспертиза прокачалась, а с postgress практического опыта почти нет. Поэтому пока только аккуратно присматриваемся, но не переезжаем.
Все-таки шаблон зависит от проекта, окружения и т.п. Важнее построить правильную архитектуру. Мы опирались на 12 факторов.
В целом в статье перечислена основаная функциональность. Для k8s cтоит отметить следующие: