Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Опыт построения СХД на базе Windows Server для использования в публичном обла...Ontico
В докладе мы поделимся опытом, полученным в ходе создания публичного облака, построенного на базе продуктов Microsoft. В частности, речь пойдет о построении программно-определяемой системы хранения данных на основе технологии Storage Spaces. Основное предназначение полученной СХД объемом около 80ТБ - использование в кластере Hyper-V для запуска порядка 5000 ВМ.
Мы рассмотрим архитектуру хранилища, проблемы снижения latency сетевого трафика, а также подходы повышения производительности при создании пулов и использовании кэша. Кроме того, буду затронуты вопросы тестирования производительности и сценарии миграции на Storage Spaces Direct.
Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Опыт построения СХД на базе Windows Server для использования в публичном обла...Ontico
В докладе мы поделимся опытом, полученным в ходе создания публичного облака, построенного на базе продуктов Microsoft. В частности, речь пойдет о построении программно-определяемой системы хранения данных на основе технологии Storage Spaces. Основное предназначение полученной СХД объемом около 80ТБ - использование в кластере Hyper-V для запуска порядка 5000 ВМ.
Мы рассмотрим архитектуру хранилища, проблемы снижения latency сетевого трафика, а также подходы повышения производительности при создании пулов и использовании кэша. Кроме того, буду затронуты вопросы тестирования производительности и сценарии миграции на Storage Spaces Direct.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)Ontico
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
AWS и GCP: трудная жизнь в облаках / Максим Пугачев (IPONWEB)Ontico
Разница между “несколько серверов в облаках” и “вся инфраструктура в облаках“ огромна. С одной стороны, мы перекладываем миллион забот на гигантские плечи Amazon и Google. С другой стороны, к сожалению, обретаем много новых и порой необычных проблем.
Как жить в облаках двух самых популярных провайдеров? Что это за проблемы и как их решать? В чем особенности облаков, если вы живете в мире highload? Как выжимать максимум из того, что предоставляют провайдеры?
Я попытаюсь рассказать о наиболее важных, на мой взгляд, особенностях:
- Почему не стоит полагаться на заявленные характеристики виртуальных машин.
- Почему нет разницы между загрузкой CPU в 85% и 100%.
- Всевозможные аномалии и неожиданные "спайки" в метриках.
- "Облачные" диски и их особенности.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)Ontico
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
AWS и GCP: трудная жизнь в облаках / Максим Пугачев (IPONWEB)Ontico
Разница между “несколько серверов в облаках” и “вся инфраструктура в облаках“ огромна. С одной стороны, мы перекладываем миллион забот на гигантские плечи Amazon и Google. С другой стороны, к сожалению, обретаем много новых и порой необычных проблем.
Как жить в облаках двух самых популярных провайдеров? Что это за проблемы и как их решать? В чем особенности облаков, если вы живете в мире highload? Как выжимать максимум из того, что предоставляют провайдеры?
Я попытаюсь рассказать о наиболее важных, на мой взгляд, особенностях:
- Почему не стоит полагаться на заявленные характеристики виртуальных машин.
- Почему нет разницы между загрузкой CPU в 85% и 100%.
- Всевозможные аномалии и неожиданные "спайки" в метриках.
- "Облачные" диски и их особенности.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Badoo в облаках. Решение для запуска cli-скриптов в облаке собственной разраб...Badoo Development
Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми. У нас тысячи серверов в двух дата-центрах, и какие-то из них постоянно выходят из строя. Наш кластер машин состоит из различных групп: машины для обслуживания веб-запросов, серверы баз данных, хранилище фотографий, серверы для выполнения cron-заданий, машины для C/C++ сервисов и некоторые другие. Для обработки заданий по расписанию мы используем так называемые «скриптовые» машины, на которых запускаются PHP-скрипты в CLI, которые выполняют нужные действия. До недавнего момента мы использовали обычный cron для запуска скриптов по расписанию, а также самописную утилиту для того, чтобы автоматизировать процесс прописывания нужных строчек в cron. Тем не менее, разработчикам приходилось по каким-то критериям выбирать одну или несколько машин, на которых будут запускаться эти скрипты, и они жестко «привязывались» к конкретным серверам. Если какая-то из машин «падала», мы должны были вручную переносить с неё скрипты на другие машины. Чтобы равномерно распределять нагрузку по серверам, а также обеспечивать автоматическое восстановление в случае отказа (failover), мы решили сделать свое «облако», которое призвано решить эти проблемы. Доклад посвящен процессу создания «облака», а также первым результатам, которые мы получили в связи с его использованием.
Краткий план доклада:
- Требования к «облаку».
- Существующие решения.
- Распределение нагрузки по машинам.
- Обработка сбоев оборудования.
- Мониторинг «облака».
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jokerconf.com/#sitnikov
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
PHP libevent Daemons. A high performance and reliable solution. Practical exp...Arvids Godjuks
It is considered (rigthly in most cases) that it's a bad manner to implement a daemon using PHP. It's OK for prototyping but no-no for production. That were our thoughts when we've started to implement a new version of browser game. It was planned to describe an interface to communicate with daemon that will be then rewritten in pure C.
However, fist libevent PHP daemon performance tests forced us to think if we really need to rewrite it in C. What was the performance? Are there memory leaks? All these will be covered in the speech.
You will also learn about problems, features and how a real project results.
Эксплуатация container-based-инфраструктур / Николай Сивко (okmeter.io)Ontico
HighLoad++ 2017
Зал «Мумбай», 7 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2899.html
На каждой конференции мы слушаем интереснейшие доклады про CI/CD, service discovery, docker, kubernetes и т.д. Практически все эти доклады рассказывают нам о "разработческой" стороне проблемы: как собрать образ контейнера, быстро его протестировать и задеплоить, как контейнеры друг о друге узнают, как добавится новый upstream в конфиг nginx и т.д.
Но никто нам не рассказал, как потом с этим "облачным" счастьем жить (тем более под нагрузкой).
...
Доклад "Remote Highload" c Highload++-2016
Созданием еще одной высоконагруженной системы сегодня уже сложно кого-то удивить. Как насчет высоконагруженной системы, которая была создана и эксплуатируется 100% удаленной командой, работающей в 5 часовых поясах?
В докладе пойдет речь о команде Virtustream (Dell Technologies), которая отвечает за Virtustream Storage Cloud.
Экзабайты данных, десятки тысяч серверов, сотни гигабит в секунду, сотни тысяч и миллионы запросов в секунду, 20 датацентров по всему миру и, при этом, команда разработчиков из 15 человек, это возможно?
В докладе мы поговорим о разных аспектах - от культуры разработки и процесса найма до контейнерной платформы запуска микросервисов и выбора языка программирования.
Почему не работает Scrum, и плохо работает парное программирование? Как Mesos, Marathon, Consul и Calico делают возможным выкладывание нового сервиса за 5 минут? Почему каждый разработчик должен иметь доступ в production?
aptly is a swiss army knife for Debian repository management: it allows to mirror remote repositories, take snapshots, pull new versions of packages along with dependencies, publish snapshots.
http://www.aptly.info/
aptly - система управления Debian-репозиториями пакетовAndrey Smirnov
aptly is a swiss army knife for Debian repository management: it allows to mirror remote repositories, take snapshots, pull new versions of packages along with dependencies, publish snapshots.