Примечание переводчика

Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:

• использовать язык Protocol Buffers для описания взаимодействия сервисов;
  
• генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
  
• реализовать авторизацию между взаимодействующими компонентами;
  
• использовать как синхронное, так и асинхронное взаимодействие.
  

gRPC показался мне довольно интересным фреймворком, и мне было интересно узнать про реальный опыт компании Dropbox по построению системы на его основе. В статье есть масса деталей, связанных с использованием шифрования, построением надёжной, наблюдаемой и производительной системы, процессом миграции со старого RPC-решения на новое.

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

Компания Check Point довольно резво начала 2019 год сделав сразу несколько анонсов. Рассказать обо всем в одной статье не получится, поэтому начнем с самого главного — Check Point Maestro Hyperscale Network Security. Maestro это новая масштабируемая платформа, которая позволяет наращивать «мощность» шлюза безопасности до «неприличных» цифр и практически линейно. Достигается это естественно за счет балансировки нагрузки между отдельными шлюзами, которые работают в кластере, как единая сущность. Кто-то может сказать — "Было! Уже есть блейд-платформы 44000/64000". Однако Maestro это совсем другое дело. В рамках этой статьи я вкратце постараюсь объяснить что это, как это работает и как эта технология поможет сэкономить на защите периметра сети.

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

Такую программу для своего SQL Server разработал Microsoft — SQL Server Fast Track (DWFT). По ней сертифицируются конфигурации хранилищ данных — те, которые соответствуют требованиям рабочей нагрузки и могут быть внедрены с меньшим риском, стоимостью и сложностью. Звучит прекрасно, но интересно все-таки оценить эти критерии на практике. Для этого мы подробно разберем одну из конфигураций, имеющих сертификацию SQL Server Data Warehouse Fast Track.

В этой статье я хочу в научно-популярной форме рассказать об оптимизации времени отклика в торговых платформах бирж и банков (HFT). Для справки речь идет о временах от сотен наносекунд до сотен микросекунд. Для большинства других приложений многие приведенные ниже методы оптимизации неактуальны просто в силу отсутствия столь жестких требований.

Обычно мы рассматриваем производительность в единицах пропускной способности. Например в Гигафлопах. Задача оптимизации в таких случаях сводится к выполнению максимального количества вычислений за единицу времени или решение задачи за минимальное время. Дизайн процессора рассчитан в первую очередь на достижение максимального количества вычислений за единицу времени и стандартные техники оптимизации на то же самое.

Однако существуют приложения где важнее время отклика, например торговые платформы в компьютерном трейдинге (HFT), поисковики, робототехника и телеком. Время отклика – это время выполнения «единичной» операции данного типа, например от получения пакета с текущими котировками с биржи до посылки заказа на биржевую операцию. На самом деле время отклика и пропускная способность (количество операций данного типа в единицу времени) тесно связаны, но разница – принципиальна. Увеличить пропускную способность часто можно просто добавив железа (больше серверов), но улучшить время отклика подобным образом проблематично (кроме случаев пиковых нагрузок).

Здравствуйте! Меня зовут Иван Давыдов, я занимаюсь исследованиями производительности в Яндекс.Деньгах.

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

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

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

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

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

В условиях highload сложность оптимизации реляционных баз данных возрастает на порядок, так как покупка ещё более мощного железа обходится дорого а также уже нет возможности просто выключить приложение ночью для долгого процесса альтера БД и миграции данных.

Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.

Если вы занимаетесь выращиванием больших баз данных и вдруг упираетесь в потолок производительности — пришло время расширяться. Со scale-out расширением понятно: серверы добавляете и горя не знаете. Со scale-up все не так весело. Согласно стандартной glueless-архитектуре, мы берем два процессора, потом добавляем к ним еще два… так доходим до восьми и все. Больше Intel не предусмотрел, копите на новый сервер.



Но есть и альтернатива — glued-архитектура. В ней двухпроцессорные вычислительные блоки соединяются между собой через нод-контроллеры. С их помощью верхний порог на один сервер поднимается до 16 и более процессоров. В этом посте подробней расскажем о glued-архитектуре вообще и о том, как она реализована в наших серверах.