This is the final part of the series describing how we’re increasing our service availability in Citymobil (you can read the previous part here). Now I’m going to talk about one more type of outages and the conclusions we made about them, how we modified the development process, what automation we introduced.

This is the next article of the series describing how we’re increasing our service availability in Citymobil (you can read the previous parts here: part 1, part 2, part 3). In further parts, I’ll talk about the accidents and outages in detail.

1. Bad release: database overload

Let me begin with a specific example of this type of outage. We deployed an optimization: added USE INDEX in an SQL query; during testing as well as in production, it sped up short queries, but the long ones — slowed down. The long queries slowdown was only noticed in production. As a result, a lot of long parallel queries caused the database to be down for an hour. We thoroughly studied the way USE INDEX worked; we described it in the Do’s and Dont’s file and warned the engineers against the incorrect usage. We also analyzed the query and realized that it retrieves mostly historical data and, therefore, can be run on a separate replica for historical requests. Even if this replica goes down due to an overload, the business will keep running.

This is the next article of the series describing how we’re increasing our service availability in Citymobil (you can read the previous parts here and here). In further parts, I’ll talk about the accidents and outages in detail. But first let me highlight something I should’ve talked about in the first article but didn’t. I found out about it from my readers’ feedback. This article gives me a chance to fix this annoying shortcoming.

This is a second article out of a series «Citymobil — a manual for improving availability amid business growth for startups». You can read the first part here. Let’s continue to talk about the way we managed to improve the availability of Citymobil services. In the first article, we learned how to count the lost trips. Ok, we are counting them. What now? Now that we are equipped with an understandable tool to measure the lost trips, we can move to the most interesting part — how do we decrease losses? Without slowing down our current growth! Since it seemed to us that the lion’s share of technical problems causing the trips loss had something to do with the backend, we decided to turn our attention to the backend development process first. Jumping ahead of myself, I’m going to say that we were right — the backend became the main site of the battle for the lost trips.

In this first part of an article series «Citymobil — a manual for improving availability amid business growth for startups» I’m going to break down the way we managed to dramatically scale up the availability of Citymobil services. The article opens with the story about our business, our task, the reason for this task to increase the availability emerged and limitations. Citymobil is a rapid-growing taxi aggregator. In 2018, it increased by more than 15 times in terms of number of successfully completed trips. Some months showed 50% increase compared with the previous month.

The business grew like a weed in every direction (it still does): there was an increase in server load, team size and number of deployments. At the same time the new threats to service availability emerged. The company faced a task of the most importance — how to increase availability without compromising company growth. In this article, I’ll talk about the way we managed to solve this task in a relatively short time.

Это вторая статья из цикла про то, как мы в Citymobil увеличивали стабильность сервиса (первую можете почитать здесь). В этой статье я углублюсь в конкретику разбора аварий. Но перед этим я освещу один момент, о котором я должен был подумать заранее и осветить в первой статье, но не подумал. И о котором узнал по фидбеку читателей. Вторая статья дает мне шанс устранить этот досадный недочет.

Этой статьей я открываю короткий цикл из двух статей, в которых подробно расскажу, как нам удалось за несколько месяцев в разы увеличить стабильность сервисов Citymobil. Статья начинается с рассказа про наш бизнес, про задачу, про причину появления самой задачи повышения стабильности и про ограничения. Citymobil — это быстрорастущий агрегатор такси. За 2018 год он вырос более чем в 15 раз по количеству успешно совершенных поездок. В некоторые месяцы рост превышал 50 % по сравнению с предыдущим месяцем.

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

Выбираете между Tarantool и Redis или между Tarantool и Memcached? Давайте рассмотрим основные различия, чтобы вам легче было определиться.

Перевод статьи с DZone. Оригинал.

Я хочу поделиться своим опытом создания приложений для Tarantool, и сегодня мы поговорим об установке этой СУБД, о хранении данных и об обращении к ним, а также о записи хранимых процедур.

Недавно в пресс-релизе мы рассказали о том, что запустили Tarantool IIoT — платформу для промышленного интернета вещей. Новость облетела многие электронные издания. Но что такое Tarantool IIoT и как он работает — тема оставалась не до конца раскрытой. Мы решили это исправить. Подробности под катом.

В первый четверг марта в нашем московском офисе состоится Tarantool Meetup 2017. Пользователи Tarantool расскажут про их опыт его внедрения и использования, о его плюсах и минусах и дальнейших планах использования. Это уникальная возможность услышать коллег и пообщаться с разработчиками нашей СУБД. Расписание мероприятия уже готово, подробнее смотрите под катом.

Многие из вас уже слышали о нашем проекте Tarantool. Это СУБД, или, попросту говоря, база данных с сервером приложений внутри. Tarantool — проект с открытым исходным кодом, и с ним может работать кто угодно. Развивается этот проект уже больше восьми лет. В Mail.Ru Group Tarantool активно используется более чем в половине продуктов: в Почте, Облаке, Моём Мире, Агенте и др. Все сделанные нами доработки этой БД мы коммитим обратно на GitHub, и сообществу доступна та же самая версия БД, что и нам. Сейчас у нас есть клиентские библиотеки почти ко всем языкам, мы сильно прибавили в этом направлении за последний год. Часть из них написана сообществом, часть — нами. Если появляется какая-то более эффективная библиотека, то мы просто делаем её официальной. Мы стараемся, чтобы всё было прямо из коробки — и БД, и библиотеки.

Одна из главных особенностей Tarantool заключается в объединении свойств БД и кэша. БД — это нечто надёжное, с транзакциями, серверным языком запросов. А кэш быстрый. И оба этих мира органично сливаются воедино в Tarantool. Эта БД предназначена для использования в высоконагруженных проектах и для работы с горячими данными.

28 января 2016 года в московском офисе Mail.Ru Group пройдёт вторая встреча Tarantool meetup. Если кто-то ещё не знает: Tarantool — это NoSQL In-Memory СУБД с открытым исходным кодом, создающаяся для обеспечения максимально возможной производительности. На втором митапе мы рассмотрим главные преимущества и особенности Tarantool, расскажем о своём опыте использования этого продукта и планах на будущее. В первую очередь эта встреча будет интересна разработчикам, Unix-сисадминам и прочим специалистам, так или иначе работающим с базами данных. Программу встречи смотрите под катом.

Для чего используются базы данных, ведь есть старые добрые файлы? Чем они хуже базы данных или чем база данных лучше файлов? БД — более структурированное хранилище. Она позволяет делать транзакции, запросы и так далее. Самый простой случай: есть сервер с базой данных и несколько приложений, которые делают запросы к серверу. База данных отвечает, меняет что-то внутри себя, и всё хорошо ровно до того момента, пока нагрузка на неё не вырастает настолько, что база данных перестаёт справляться.

Если допустить, что это только нагрузка на чтение, то проблема решается репликацией. Вы можете ставить к базе данных столько реплик, сколько нужно, и все чтения пускать на реплику, а все записи — на мастер. Если же на базу данных идёт нагрузка на запись, то репликация эту проблему не решает, ведь запись должна осуществляться на все реплики. Таким образом, сколько бы вы их ни ставили, вы не уменьшите нагрузку на запись из расчёта на одну машину. Тут на помощь приходит шардинг.

Если база не держит нагрузку на запись, то шарды можно добавлять до бесконечности. Шард устроен сложнее, чем реплика, потому что нужно как-то распределить данные по таблицам или внутри таблицы, по хэшу, по range — есть множество разных вариантов. Таким образом, добавляя реплики и шарды, вы можете делить любую нагрузку на базу данных. Казалось бы, больше желать нечего, о чём дальше говорить?

Мы в Почте Mail.Ru постоянно сталкиваемся с необходимостью работать с историей пользователей. Учитывая, что ежемесячная аудитория проекта составляет более 40 миллионов человек, история всех их действий – это порядка петабайта данных. Потребность в поиске по логам у нас возникает сотни раз в день, а на получение нужной информации в среднем уходило несколько часов. При этом, по нашим предположениям, извлечение информации из логов можно было ускорить до нескольких секунд.

Чтобы оценить целесообразность разработки системы для оптимизации поиска по логам, мы воспользовались вот этой таблицей с XKCD:



(на самом деле нет, но нам она все равно нравится).

Итак, мы всерьез взялись за оптимизацию. Итогом нашей работы стала разработка системы, благодаря которой мы можем поднять историю действий примерно в 100 000 (сто тысяч, это не опечатка) раз быстрее. Мы разработали big-data сервис, который позволяет хранить петабайты информации в структурированном виде: каждому ключу у нас соответствует лог каких-то событий. Хранилище устроено так, что оно способно работать и на самых дешевых SATA-дисках, и на больших многодисковых хранилищах с минимальным количеством процессорного времени, при этом оно полностью fault-толерантно — если вдруг какая-то машина выйдет из строя, это ни на что не влияет. Если в системе заканчивается место, в нее просто добавляется сервер или несколько: система автоматически увидит их и начнет записывать данные. Чтение данных происходит почти моментально.

Рассмотрим следующую ситуацию: вы — проджект-менеджер, и на вашем проекте возникла проблема. О том, как поэтапно добраться до источника проблемы и ликвидировать ее, я подробно расскажу в сегодняшней статье.



У меня все работает!

Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.

Сталкивались ли вы с проблемой, что письма от вашего сервиса подделываются с целью вымогательства пароля или других конфиденциальных данных? Ежедневно к пользователям пытаются пробиться тысячи спамерских, фишинговых и мошеннических писем, которые злоумышленники маскируют под сообщения от известных сервисов.

Такие письма причиняют ущерб адресатам, что, в конечном счете, сказывается на репутации как самих добропорядочных сервисов, так и почтовых провайдеров.

Теперь мы даем сервисам, которые ведут свои рассылки, возможность защититься от такого рода подделок с помощью технологии DMARC (dmarc.org), которую мы поддержали первыми среди крупных почтовых сервисов в рунете.

В начале декабря в Санкт-Петербурге при партнерстве Mail.Ru Group прошел полуфинал чемпионата мира по программированию ACM ICPC. В рамках чемпионата я встречался с участниками и рассказывал о том, как сделать веб-сервис системой реального времени; а сейчас хочу поделиться своим докладом на Хабре.

Говоря о системе реального времени, мы представляем атомную станцию, самолет или нечто подобное, где от скорости реакции информационной системы зависит жизнь людей. Если в системе реального времени команда будет тормозить 10 секунд из-за сборки мусора, последствия могут быть более чем плачевными. Реакция должна быть моментальной, причем за гарантированное время.

При работе веб-сервиса, конечно, жизнь человека не зависит от того, насколько быстро он открыл письмо в почте, но требования к веб-сервису почти такие же. Еще 15 лет назад, когда пользователь кликал на ссылку, он ожидал реакции 10 секунд; для медленного интернета того времени это было нормально. Современный интернет – это широкие каналы, быстрые компьютеры. У пользователей все работает быстро, и они ждут от сервисов того же.

Когда пользователь куда-то кликает, он ожидает моментально получить реакцию на свой клик. Что такое моментально? Для человека комфортной задержкой считается время отклика порядка 200 миллисекунд, хотя на самом деле человеческий глаз различает время около 10 миллисекунд. Веб-сервис должен реагировать на действия пользователя не более чем за 200 миллисекунд — чем меньше, тем лучше.

Итак, современный веб-сервис, по сути, должен быть системой реального времени. Как сделать так, чтобы он отвечал этому требованию, я расскажу на примере Почты Mail.Ru.

В сентябре Почта Mail.Ru включила HTTPS-шифрование для всех пользователей.

Преимущества защищенного соединения очевидны всем разработчикам крупных интернет-проектов. Большинство современных web-серверов (nginx, Apache, etc) и браузеров поддерживают HTTPS. В то же время сайтов, на которых безопасный протокол включен всегда и по умолчанию, не так много. Почему это так? С какими трудностями мы столкнулись при поддержке HTTPS? Читайте под катом.