Яндекс, как и любая другая большая интернет-компания, хранит много, а точнее очень много данных. Это и пользовательские данные из разных сервисов, и намайненные сайты, и промежуточные данные для расчёта погоды, и резервные копии баз данных. Стоимость хранения ($/ГБ) — один из важных показателей системы. В этой статье я хочу рассказать вам про один из методов, который позволил нам серьезно удешевить хранилище.

В 2015 году, как вы все помните, сильно вырос курс доллара. Точнее, расти-то он начал в конце 2014-го, но новые партии железа мы заказывали уже в 2015-м. Яндекс зарабатывает в рублях, и поэтому вместе с курсом выросла и стоимость железа для нас. Это заставило нас в очередной раз подумать о том, как сделать, чтобы в текущий кластер можно было положить больше данных. Мы такое, конечно, делаем регулярно, но в этот раз мотивация была особенно сильной.

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

Небольшое предисловие от команды ОК: Последний пост на Хабре от Одноклассников был написан ещё в декабре прошлого года. Мы пропали отсюда на 8 месяцев, но это не означает, что за это время с Одноклассниками ничего не происходило. Нами по-прежнему пользуется несколько десятков миллионов человек ежемесячно, мы по-прежнему один из самых высоконагруженных сервисов на Java в мире. Мы обновили позиционирование, отсняли десятки эпизодов собственных шоу, отказались от оценок под фото :)

Мы решили вернуться на Хабр после долгого отсутствия и сразу с рассказом о своем проекте, который назвали Tracer. О том, что это, рассказывает руководитель направления Android-разработки в проекте ОК Кирилл Попов.

Ошибки и сбои в работе мобильного приложения — беда для любого разработчика, которая непременно тянет за собой ворох проблем в виде ухудшения UI, потери лояльности и оттока аудитории, а также смещения фокуса с написания продуктового кода на исправление багов. Вместе с тем, часто полностью исключить проблемы невозможно. Поэтому, чтобы обеспечить предсказуемую работу прода и свести ущерб от сбоев к минимуму, важно своевременно проводить аналитику ошибок. Но есть кейсы, когда классических решений со стектрейсами ошибок не достаточно, чтобы понять что и, главное, почему идет не так. В таких и многих других сценариях поможет Tracer — модульный инструмент для аналитики ошибок в мобильных приложениях от OK.Tech, технической команды ОК, который можно настроить под определенную задачу и который может решать конкретные проблемы.

Практически каждый бэкенд разработчик, начиная с определенного уровня, на интервью сталкивается с необходимостью продемонстрировать свои навыки проектирования распределенных приложений. Под это может быть выделено 15 минут во время единственной секции с тимлидом, а может, предложат пройти две независимые секции по 45-60 минут, если вы претендуете на относительно высокую позицию в западной интернет-компании.

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

Меня зовут Леонид Талалаев, я занимаюсь разработкой внутреннего облака Одноклассников one-cloud, про которое уже рассказывали на Хабре. 

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

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

Для управления сетевым трафиком до недавнего времени мы использовали решение на основе дисциплины Hierarchical Fair Service Queue из Linux Traffic Control. Сегодня пойдет речь про проблему масштабирования в Linux Traffic Control, известную как root qdisc locking. И про то, как нам удалось ее решить, переделав управление сетевым трафиком с использованием eBPF.

Всем привет! Меня зовут Леонид Талалаев, я работаю в Одноклассниках в команде Платформы. Более 3-х лет назад мы запустили внутреннее облако one-cloud. Сейчас под его управлением находятся тысячи серверов в 4 дата-центрах, сотни сервисов и более десятка тысяч контейнеров.

Наше облако – это технология, проверенная временем и инцидентами — вплоть до пожара в одном из наших дата-центров. По мере роста числа сервисов росла и сложность управления. Задачи, которые раньше выполнялись вручную, начинали отнимать слишком много времени и сил.

В серии статей «Восстание машин» я расскажу, как автоматизация в one-cloud помогает экономить не только время, но и деньги. Сегодня пойдет речь о том, как мы реализовали процесс непрерывной доставки изменений базовых Docker образов.

Графовые рекомендательные системы показывают state of the art результаты, но про них редко пишут и еще реже используют в продакшене. В этой статье мы расскажем про опыт Одноклассников в применении графового подхода для задачи рекомендации групп, разберем причем тут нейросети и что делать, если не все рекомендации одинаково полезны для пользователей и портала.

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

Какие преимущества появляются при совмещении бизнес-логики и БД? Какие нюансы надо учесть, прибегая к такому подходу? Что с надёжностью и доступностью сервисов? Расскажем подробно об этом всём.

1. создание stack frame;
2. перекладывание аргументов в соответствии с ABI;
3. оборачивание ссылок в JNI хендлы (jobject);
4. передачу дополнительных аргументов JNIEnv* и jclass;
5. захват и освобождение монитора, если метод synchronized;
6. «ленивую» линковку нативной функции;
7. трассировку входа и выхода из метода;
8. перевод потока из состояния in_Java в in_native и обратно;
9. проверку необходимости safepoint;
10. обработку возможных исключений.

Совсем недавно, с 8 по 12 июля, одновременно проходило два знаковых события — конференция Hydra и школа SPTDC. В этом посте хочется отметить несколько особенностей, которые мы заметили по ходу проведения конференции.

Самая большая гордость Гидры и Школы — это докладчики.

• Три лауреата премии Дейкстры: Leslie Lamport, Maurice Herlihy и Michael Scott. Причём Морис получил её целых два раза. Лесли Лэмпорт получил еще и премию Тьюринга — самую престижную премию ACM в информатике;
• Создатель JIT-компилятора Java — Cliff Click;
• Разработчики корутин — Роман Елизаров (elizarov) и Никита Коваль (ndkoval) для Kotlin, и Дмитрий Вьюков для Go;
• Контрибьюторы в Cassandra (Алекс Петров), CosmosDB (Денис Рысцов), Yandex Database (Семен Чечеринда и Владислав Кузнецов);
• И множество других известных людей: Martin Kleppmann (CRDT), Heidi Howard (Paxos), Ori Lahav (C++ memory model), Pedro Ramalhete (wait-free data structures), Алексей Зиновьев (ML), Дмитрий Бугайченко (анализ графов).

Морис Херлихи — обладатель целых двух премий Дейкстры. Первая — за работу по «Wait-Free Synchronization» (Brown University) и вторая, более свежая, — «Transactional Memory: Architectural Support for Lock-Free Data Structures» (Virginia Tech University). Премию Дейкстры дают за работы, значимость и влияние которых были заметны на протяжении не менее десяти лет и, очевидно, Морис — один из самых известных специалистов в области. На данный момент он работает профессором в Брауновском университете и имеет множество достижений на целый абзац длиной. Сейчас он занимается исследованиями блокчейна в контексте классических распределенных вычислений.

Ранее Морис уже приезжал в Россию на SPTCC (видеозапись) и cделал отличную встречу сообщества Java-разработчиков JUG.ru в Питере (видеозапись).

Этот хабрапост  — большое интервью с Морисом Херлихи. В нем обсуждаются следующие темы:

• Взаимодействие академической сферы и индустрии;
• Фундамент для исследований блокчейна;
• Откуда берутся прорывные идеи. Влияние популярности;
• PhD под руководством Барбары Лисков;
• Мир в ожидании многоядерности;
• Новому миру – новые проблемы. NVM, NUMA и взлом архитектуры;
• Компиляторы против процессоров, RISC vs CISC, shared memory vs message passing;
• Искусство написания хрупкого многопоточного кода;
• Как обучить студентов написанию сложного многопоточного кода;
• Новое издание книги «The Art of Multiprocessor Programming»;
• Как изобреталась транзакционная память;   
• Почему стоит проводить исследования в области распределенных вычислений;
• Остановилось ли развитие алгоритмов, и как жить дальше;
• Работа в Брауновском Университете;
• Разница между исследованиями в университете и внутри корпорации;
• Hydra и SPTDC.

Клифф Клик — CTO компании Cratus (IoT сенсоры для улучшения процессов), основатель и сооснователь нескольких стартапов (включая Rocket Realtime School, Neurensic и H2O.ai) с несколькими успешными экзитами. Клифф написал свой первый компилятор в 15 лет (Pascal для TRS Z-80)! Наиболее известен за работу над С2 в Java (the Sea of Nodes IR). Этот компилятор показал миру, что JIT может производить качественный код, что стало одним из факторов становления Java как одной из основных современных программных платформ. Потом Клифф помог компании Azul Systems построить 864-ядерный мейнфрейм с софтом на чистой Java, который поддерживал паузы GC на 500-гигабайтной куче в пределах 10 миллисекунд. Вообще, Клифф успел поработать над всеми аспектами JVM.
 
Этот хабрапост — большое интервью с Клиффом. Мы поговорим на следующие темы:

• Переход к низкоуровневым оптимизациям
• Как делать большой рефакторинг
• Модель стоимости
• Обучение низкоуровневым оптимизациям
• Практические примеры улучшения производительности
• Зачем создавать свой язык программирования
• Карьера перформанс-инженера
• Технические челленжи
• Немного про аллокацию регистров и многоядерность
• Самый большой челленж в жизни

Интервью ведут:

• Андрей Сатарин из Amazon Web Services. В своей карьере успел поработать в совершенно разных проектах: тестировал распределенную базу данных NewSQL в Яндексе, систему облачного детектирования в Лаборатории Касперского, многопользовательскую игру в Mail.ru и сервис расчёта валютных цен в Deutsche Bank. Интересуется тестированием крупномасштабных backend- и распределённых систем.
• Владимир Ситников из Netcracker. Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере.

Contents:

• Moving from business to academic research;
  
• Discussion of «Designing Data-Intensive Applications»;
  
• Common sense against artificial hype and aggressive marketing;
  
• Pitfalls of CAP theorem and other industry mistakes;
  
• Benefits of decentralization;
  
• Blockchains, Dat, IPFS, Filecoin, WebRTC;
  
• New CRDTs. Formal verification with Isabelle;
  
• Event sourcing. Low level approach. XA transactions; 
  
• Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  
• How to apply all that tools to real life;
  
• Expected target audience of Martin’s talks and the Hydra conference.
  

• Переход от бизнеса к академическим исследованиям;
  
• Предпосылки написания Designing Data-Intensive Applications;
  
• Здравый смысл против искусственного ажиотажа и рекламы инструментов;
  
• Ненужность теоремы CAP и другие ошибки индустрии;
  
• Полезность децентрализации;
  
• Блокчейны, Dat, IPFS, Filecoin, WebRTC;
  
• Новые CRDT. Формальная верификация на Isabelle;
  
• Дискуссия про event sourcing. Низкоуровневый подход. XA-транзакции; 
  
• Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  
• Использование всего этого в реальной жизни;
  
• Порог входа в доклады Мартина и конференция Hydra.
  

Работаете с NoSQL-хранилищем Apache Cassandra?