Что может побудить нас переехать из железа в облако? А обратно? Иногда за этим стоит желание повысить отказоустойчивость, в других случаях — снизить затраты или вернуть контроль. Но достаточно ли хорошо мы понимаем, во что на самом деле ввязываемся? И какие подводные камни ждут на этом пути?

В этой статье по мотивам доклада с DevOpsConf затрону тему не самых очевидных нюансов, с которыми столкнётся инженерная команда, мигрируя инфраструктуру на облака или в on-prem. У каждого решения есть причины, но прежде покажу на основе опыта и кейсов, какие неочевидные факторы следует учесть, чтобы миграция прошла хорошо. Не только в инженерном смысле, но и в соответствии с возможностями бизнеса.

Прим. переводчика: автор статьи рассказывает, как его команда убедилась, что новый кластер Elasticsearch работает в соответствии с ожиданиями и полностью готов к production-нагрузкам. Также подводит итоги всего процесса и анализирует получившуюся архитектуру нового кластера в целом.

Прим. переводчика: автор статьи рассказывает, как его команде удалось запустить два клиента Elasticsearch разных версий на одной JVM путем написания специальной библиотеки-обертки для работы с нужной версией.

Это пятая часть серии статей об обновлении кластера Elasticsearch без простоев и с минимальным воздействием на пользователей.

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

Прим. переводчика: автор статьи рассказывает, как его команде удалось оптимизировать временные и ресурсные затраты при токенизации текстов в Elasticsearch путем внедрения нормализации похожих символов.

Это четвертая часть серии статей об обновлении кластера Elasticsearch без простоев и с минимальным воздействием на пользователей.

Во второй части было рассказано о решении провести полную переиндексацию всего датасета в процессе обновления Elasticsearch. В этой части пойдет речь о некоторых изменениях, которые были внесены в документы во время переиндексации.

Прим. переводчика: автор статьи рассказывает, с какими трудностями его команда столкнулась при настройке нового кластера. Среди них — проблема с низкой производительностью поиска по подстановочным знакам.

Это третья часть серии статей об обновлении кластера Elasticsearch без простоев и с минимальным воздействием на пользователей. В рамках проекта по обновлению Elasticsearch было необходимо определить, насколько улучшилась производительность поиска в новой версии по сравнению со старой. Использование старой версии Elasticsearch было сопряжено со множеством проблем с производительностью, и была надежда, что переход на новую версию поможет с ними разобраться.

Прим. переводчика: автор статьи рассказывает о процессе обновления кластера Elasticsearch размером более 3 петабайт методом последовательного включения двух кластеров, а также о том, как решались проблемы согласованности индексирования и миграции данных.

Это вторая часть из серии статей об обновлении кластера Elasticsearch без простоев и с минимальным воздействием на пользователей. Как упоминалось в первой части, необходимо было обеспечить плавный переход между двумя версиями системы, при этом сохраняя возможность отката.

Прим. переводчика: автор статьи рассказывает о причинах, побудивших его команду обновить кластер Elasticsearch размером более 3 петабайт, и приводит результаты замеров работоспособности нового кластера в сравнении со старым.

Еще в 2018 году, то есть пять лет назад, в нашем блоге был опубликован пост с описанием нашего кластера Elasticsearch на 400+ узлов. Тогда была затронута важная тема:

Мы решили не обновлять кластер. Хотелось бы, но пока есть более срочные задачи. Да и как именно будет происходить обновление, пока не решено. Один из вариантов — создать новый кластер, а не обновлять старый.

Что ж, долгожданный день обновления, наконец, наступил.

Наш клиент cybersport.ru — один из самых популярных информационно-новостных порталов про киберспорт в СНГ. По данным Similarweb, в октябре 2021 года у сайта было 16,5 млн посещений.

Обычно нагрузка на cybersport.ru даже во время значимых событий не превышает 400 RPS (requests per second). Так было до недавнего времени, точнее — до The International 10. Турнир вернулся после годичного перерыва из-за пандемии, что подогрело интерес к нему. Ажиотажа добавило и успешное выступление российских команд. В итоге во время турнира нагрузка достигала небывалых для сайта 2300 RPS.

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

Про некоторые свои failure stories мы уже писали и раньше, но теперь мне выпала честь формально открыть специальный цикл из таких статей. Ведь аварии, их причины и последствия — это тоже часть нашей жизни, и исследовать эту «тёмную сторону» не менее интересно, чем всё остальное. Тем более, что они всё больше влияют даже на повседневный быт, так что из любой аварии можно и нужно извлекать уроки. Да и читатели не раз просили нас рассказывать о таком почаще — давайте попробуем!

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

Перейдем к технической стороне…