J3qx

information archive

Posts Tagged ‘highload’

Автоматизация нагрузочного тестирования банковского ПО для терминалов

Posted by j3qx на Июнь 10, 2017

В этом посте речь пойдет о тестировании серверного ПО, которое обслуживает огромную сеть банковских терминалов в России и за рубежом. Название банка мы раскрыть не можем, некоторые строчки конфигов скрыты.

Итак, мы занимаемся разработкой данного ПО, используя современный CI/CD подход, чем обеспечивается высокая скорость поставки фич, хотфиксов и релизов в продакшн. В начале года нам была предложена задача обеспечить нагрузочным тестированием разрабатываемое решение и продемонстрировать заказчику способность встраивать в CI/CD любые подзадачи и шаги.

Помимо общих слов, хотелки сводились к следующему: необходимо обеспечить автоматический деплой ПО на нагрузочный стенд, придумать легкий способ генерации данных, внедрить автоматический и полуавтоматический способ запуска тестов, снабдить тесты автоматическим триггером старта и остановки по событию, подключить механику НТ к трекеру задач для короткого репортинга, подключить систему тестирования к доступной системе аналитики НТ, создать возможность “покраски” плохих и хороших релизов для дальнейших действий в workflow (выкатить или отправить репорт). Требования, надо признать, абсолютно адекватные и понятные.

 

Читать далее…

Posted in IT expert | Отмечено: , | Leave a Comment »

Масштабируя TLS

Posted by j3qx на Июнь 4, 2017

Хабр, это доклад с одного из «не главных» залов Highload++ 2016. Артём ximaera Гавриченков, технический директор Qrator Labs, рассказывает про прикладное шифрование, в том числе, в высоконагруженных проектах. Видео и презентация в конце поста — спасибо Олегу Бунину.

Приветствую! Мы продолжаем находиться на сессии про HTTPS, TLS, SSL и всё такое.
То, о чём я сейчас буду говорить — не какой-то туториал. Как говорил мой преподаватель в университете по базам данных, Сергей Дмитриевич Кузнецов: «Я не буду учить вас настраивать Microsoft SQL сервер — пусть это делает Microsoft; не буду учить вас настраивать Oracle — пусть это делает Oracle; не буду учить вас настраивать MySQL — делайте это сами».

Точно так же и я не буду учить вас настраивать NGINX — это всё есть на сайте у Игоря Сысоева. Что мы обсудим, так это некий общий взгляд на проблематику и на возможности для решения проблем, которые возникают при внедрении шифрования на публичных сервисах.

Небольшой экскурс в совсем новейшую историю: как известно, в последнее время тема шифрования публичных сервисов поднялась на какой-то новый уровень — она на слуху и слайд выше отображает, как примерно это происходило.

Читать далее…

Posted in highload | Отмечено: , , , | Leave a Comment »

Uber — причины перехода с Postgres на MySQL перевод

Posted by j3qx на Май 21, 2017

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.
Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Введение

На ранней стадии развития архитектура Uber состояла из монолитного серверного приложения на Python, которое использовало Postgres для хранения данных. С тех пор многое изменилось: была применена модель микросервисов, а также новые платформы обработки и хранения данных. В частности, раньше во многих случаях мы использовали Postgres, а теперь перешли на Schemaless — новую распределенную систему хранения данных, работающую поверх MySQL. В этой статье мы поговорим о некоторых недостатках Postgres и объясним, почему мы решили построить Schemaless и другие сервисы на базе MySQL.

Читать далее…

Posted in highload | Отмечено: , , , | Leave a Comment »

Принципы и приёмы обработки очередей

Posted by j3qx на Май 21, 2017

Принципы и приёмы обработки очередей

Константин Осипов (Mail.ru)

Как вы считаете, какова стоимость очередей с приоритетами? То есть если кто-то лезет вне очереди, то как посчитать стоимость для всей системы в этой ситуации, чему она пропорциональна? Времени обслуживания клиента — например, 5 минут стоит его обслужить? Она пропорциональна количеству ожидающих, потому что время ожидания для каждого из них увеличится.
Для начала о себе — я занимаюсь разработкой СУБД Tarantool в Mail.ru. Этот доклад будет об обработке очередей. У нас много очередей внутри системы, фактически вся база данных построена как система массового обслуживания.
В основном речь будет идти о проблемах балансировки нагрузки, но перед этим я хотел бы поговорить о том, зачем нужны очереди и как они появились именно в компьютерных системах, чего они позволяют добиться.

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

Читать далее…

Posted in highload | Отмечено: , | Leave a Comment »

Почему мы уверены в том, что развернули

Posted by j3qx на Май 21, 2017

image
Часто бывает, когда что-то не работает. И никто не хочет, чтобы что-то не работало по его вине. В контексте больших инфраструктур и распределенных приложений ошибка конфигурации может быть фатальной.

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

Читать далее…

Posted in highload | Отмечено: , | Leave a Comment »

Что нужно учесть при проектировании системы, чтобы не было мучительно больно?

Posted by j3qx на Май 21, 2017

В статье описаны проблемы при проектировании баз данных и немного всего приложения, которые потом с ростом проекта все сложнее и сложнее решить. Моменты, которые важно учесть на этапе дизайна, и не задумываться о них в последствии. Ну или задумываться за чашкой чая и фразой «А помнишь, как мы решили это сделать сразу? Сколько времени мы этим себе сэкономили!», а не с ощущением зубной боли и болезненном вздрагивании при каждом воспоминании. По мере роста системы и числа пользователей, дизайн базы все сложнее и сложнее изменить, и масштаб изменений становится все более глобальным и трудоемким.

Сейчас многие успешные проекты выросли из небольших стартапов, которые потом получили коммерческий успех и стали большими международными компаниями. Такая возможность роста появилась в последние 20 лет, в основном благодаря интернету и эффекту «стирания границ». Появились глобальные интернет-приложения и мобильные приложения, которые могут быть использованы в любой стране. Ранее, чаще всего, если приложение должно было быть международным проектом, оно и проектировалось уже сразу с учетом такого требования. Конечно, можно воспользоваться эволюционным подходом, и по мере роста проекта добавлять в него необходимые функции и масшатибирование. Но для облегчения внедрения дальнейших изменений, необходимо сразу учитывать масштаб некоторых базовых функций, изменить которые в дальнейшем сложно.

Читать далее…

Posted in highload | Отмечено: , , | Leave a Comment »

Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженном проекте

Posted by j3qx на Май 20, 2017

Аникин Денис ( danikin, Mail.Ru)

Денис Аникин

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

Базы данных – это хранилище, более структурированное, чем файл, и обладающее рядом некоторых фич, которых у файла нет.

Там можно делать запросы, там есть транзакции, индексирование, таблицы, устойчивые, более-менее надежные хранилища. На самом деле, базы данных – это более удобно, чем файлы.

 

Читать далее…

Posted in highload | Отмечено: , , | Leave a Comment »

Экстремальная миграция на PostgreSQL: без остановки, потерь и тестирования

Posted by j3qx на Май 20, 2017

 

Буквально месяц назад в Яндекс.Деньгах завершился переезд сервиса профилей пользователей с Oracle на PostgreSQL. Так что теперь у нас есть опробованное решение по миграции больших объемов данных без потерь и остановки использующего их сервиса.

 

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

 

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

 

Итак, через 3 месяца профили пользователей должны работать без Oracle

 

Читать далее…

Posted in highload | Отмечено: , , | Leave a Comment »

101 способ приготовления RabbitMQ и немного о pipeline архитектуре

Posted by j3qx на Май 20, 2017

Павел Филонов (во время выступления работал в Positive Technologies)

Павел Филонов

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

Сначала немного в качестве пролога. Это приятная часть.

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

Вместе с такой задачей приходит и целая серия проблем.

Проблема №1. Продолжаем сценку.

Вам приносят вот это:

Вы смотрите, спрашиваете: «А где требования?».

Вам показывают: «Ну, вот же они!» (см. на слайде).

 

Читать далее…

Posted in highload | Отмечено: , | Leave a Comment »

Выбор самой быстрой SHA-2 хэш-функции – SHA-512

Posted by j3qx на Май 12, 2017

Длиннее = медленнее? Для хэш-функции — необязательно.

На недавнем вебинаре по TLS 1.3 была вскользь затронута одна неочевидная тема – вопрос выбора самой быстрой хэш-функции для работы TLS.

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

3DES безопаснее DES, “длиннее в битах” и дольше считается. SHA-1 безопаснее MD5, “длиннее в битах” и дольше считается. RC4-128 безопаснее RC2-40, “длиннее в битах” и… ну, этот пример можно считать исключением.

Читать далее…

Posted in highload, ITSecurity | Отмечено: , , , | Leave a Comment »