Требования

• 5+ лет опыта работы в технологических компаниях, предпочтительно интернет-проекты и/или разработка под мобильные платформы
• Высшее управленческое или техническое образование
• Навыки проектирования архитектуры комплексных программно-аппаратных решений, обладающих свойствами горизонтальной масштабируемости, отказоустойчивости и информационной безопасности
• Способность организовать и стандартизировать процессы разработки серверной и клиентской частей проектов, а также функционального, интеграционного и нагрузочного тестирования
• Умение координировать работу команды технических специалистов; транслировать бизнес-задачи в конкретные технологические подпроекты/решения и делегировать их реализацию подчиненным; формулировка и контроль исполнения технических задач
• Умение адекватно оценивать текущие и возможные технические риски и вовремя (заранее) информировать о них других топ-менеджеров проекта, а также о текущих достижениях и проблемах технической команды
• Способность принимать взвешенные и обоснованные технические решения с учетом текущих потребностей бизнеса и аудитории, финансовой эффективности, а также уровня способностей и загруженности команды
• Стремление делиться опытом с коллегами, помогать в решении нетривиальных задач, возможно проводить небольшие тренинги
• Опыт разработки серверных приложений на одном из следующих языков программирования от 2 лет: C/C++, Python, Java, JavaScript; участие в разработке opensource проектов — большой плюс
• Представление об основных принципах работы и особенностях современных мобильных платформ, в первую очередь iOS, Android, J2ME, Symbian, WP7; опыт разработки под одну или некоторые — большой плюс
• Навыки системного администрирования Linux, настройка основных компонентов, оптимизация производительности (в первую очередь сетевого стека, файловых систем и баз данных)

Условия

• Заработная плата от 200000 рублей в месяц + бонусы
• Полный рабочий день, офис в районе метро Полежаевская

Резюме присылать на grishin@citypatrol.ru

Статистика

• Общее
  • Ежедневная аудитория Google составляет около 1 миллиарда человек
    • По данным Alexa больше половины каждый день Google пользуются более половины аудитории интернета
    • По данным IWS аудитория интернета составляет 2.1 миллиарда человек
  • Используется более 900 тысяч серверов
    • Планируется расширение до 10 миллионов серверов в обозримом будущем
  • 12 основных датацентров в США, присутствие в большом количестве точек по всему миру (более 38)
  • Около 32 тысяч сотрудников в 76 офисах по всему миру
• Поиск
  • За последние 14 лет среднее время обработки одного поискового запроса уменьшилось с 3 секунд до менее 100 миллисекунд, то есть в 30 раз
  • Более 40 миллиардов страниц в индексе, если приравнять каждую к листу А4 они бы покрыли территорию США в 5 слоев
  • Более 1 квинтиллиона уникальных URL (10 в 18 степени); если распечатать их в одну строку, её длина составит 51 миллион километров, треть расстояния от Земли до Солнца
  • В интернете встречается примерно 100 квинтиллионов слов, чтобы набрать их на клавиатуре одному человеку потребовалось бы примерно 5 миллионов лет
  • Проиндексировано более 1.5 миллиардов изображений, чтобы их сохранить потребовалось бы 112 миллионов дискет, которые можно сложить в стопку высотой 391 километр
• Gmail
  • Активных пользователей более 170 миллионов
  • Второй по популярности почтовый сервис в США, третий в мире (по данным comScore)
  • При текущем темпе роста аудтории GMail и конкурентов, он станет лидером рынка через 2-3 года
• Google+
  • Более 40 миллионов пользователей на октябрь 2011, при запуске в июне 2011
  • 25 миллионов пользователей за первый месяц
  • 70:30 примерное соотношение мужчин и женщин
  • Себестоимость разработки больше полумиллиарда долларов
• YouTube
  • Загружается более 13 миллионов часов видео в год
  • Каждую минуту загружается 48 часов видео, что соответствует почти 8 годам контента или 52 тысячам полнометражных фильмов в день
  • Более 700 миллиардов просмотров видео в год
  • Месячная аудитория составляет 800 миллионов уникальных посетителей
  • Несколько тысяч полнометражных фильмов в YouTube Movies
  • Более 10% всех видео в формате HD
  • 13% просмотров (400 миллионов в день) происходит с мобильных устройств
  • До сих пор работает в убыток, лишь 14% просмотров видео приносят выручку с рекламы
• Финансы
  • Выручка порядка 36 миллиардов долларов в год
  • Прибыль после налогов порядка 10 миллиардов долларов в год
  • Капитализация порядка 55 миллиардов долларов

Архитектура

Google — огромная интернет-компания, неоспоримый лидер на рынке поиска в Интернет и владелец большого количества продуктов, многие из которых также добились определенного успеха в своей нише.

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

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

Оборудование

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

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

• Точное измерение потребления электроэнергии всеми компонентами позволяет определить возможности по его уменьшению;
• В датацентрах Google тепло, что позволяет экономить на охлаждении;
• При проектировании датацентра уделяется внимание даже незначительным деталям, позволяющим сэкономить даже немного — при таком масштабе это окупается;
• Google умеет охлаждать датацентры практически без кондиционеров, с использованием воды и её испарения (см. как это реализовано в Финляндии).

В Google активно пропагандируют максимальное использование возобновляемой энергии. Для этогоe заключаются долгосрочные соглашения с её поставщиками (на 20 и более лет), что позволяет отрасли активно развиваться и наращивать мощности. Проекты по генерации возобновляемой энергии, спонсируемые Google, имеют суммарную мощность более 1.7 гигаватт, что существенно больше, чем используется для работы Google. Этой мощности хватило бы для обеспечения электричеством 350 тысяч домов.

Если говорить о жизненном цикле оборудования, то используются следующие принципы:

• Уменьшение транспортировки: там, где это возможно, тяжелые компоненты (вроде серверных стоек) закупаются у местных поставщиков, даже если в других местах аналогичный товар можно было бы купить дешевле.
• Повторное использование: прежде, чем покупать новое оборудование и материалы, рассматриваются возможности по использованию уже имеющихся. Этот принцип помог избежать покупки более 90 тысяч новых серверов.
• Утилизация: в тех случаях, когда повторное использование невозможно, оборудование полностью очищается от данных и продается на вторичном рынке. То, что не удается продать, разбирается на материалы (медь, сталь, алюминий, пластик и.т.п.) для последующей правильной утилизации специализированными компаниями.

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

• Резервное питание, интегрированное в блок питания сервера, обеспеченное стандартными 12V батарейками;
• «Серверный сендвич», где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;
• Датацентр из контейнеров.

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

Платформа

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

Основными задачами в ранние годы была минимизация точек отказа и обработка больших объемов слабоструктурированных данных. Решением этих задач стали три основных слоя платформы Google, работающие один поверх другого:

• Google File System: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера.
• BigTable: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность).
• MapReduce: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации.

Такая комбинация, дополненная другими технологиями, довольно долгое время позволяла справляться с индексацией Интернета, пока… скорость появления информации в Интернете не начала расти огромными темпами из-за «бума социальных сетей». Информация, добавленная в индекс даже через полчаса, уже зачастую становилась устаревшей. В дополнение к этому в рамках самого Google стало появляться все больше продуктов, предназначенных для работы в реальном времени.

Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который около года назад был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых «слоев» также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии.

Google Colossus

Новая архитектура GFS была спроектирована для минимизации задержек при доступе к данным (что критично для приложений вроде GMail и YouTube), не в ущерб основным свойствам старой версии: отказоустойчивости и прозрачной масштабируемости.

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

Основным нововведением в Colossus стали распределенные мастер-сервера, что позволило избавиться не только от единственной точки отказа, но и существенно уменьшить размер одного блока с данными (с 64 до 1 мегабайта), что в целом очень положительно сказалось на работе с небольшими объемами данных. В качестве бонуса исчез теоретический предел количества файлов в одной системе.

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

По прогнозам Google текущий вариант реализации распределенной файловой системы «уйдет на пенсию» в 2014 году из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).

Google Percolator

MapReduce отлично справлялся с задачей полной перестройки поискового индекса, но не предусматривал небольшие изменения, затрагивающие лишь часть страниц. Из-за потоковой, последовательной природы MapReduce для внесения изменений в небольшую часть документов все равно пришлось бы обновлять весь индекс, так как новые страницы непременно будут каким-то образом связаны со старыми. Таким образом задержка между появлением страницы в Интернете и в поисковом индексе при использовании MapReduce была пропорциональна общему размеру индекса (а значит и Интернета, который постоянно растет), а не размеру набора измененных документов.

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

Новая система получила довольно своеобразное название Percolator, попытки узнать что оно значит приводит к различным устройствам по фильтрации дыма, кофеваркам и непойми чему еще. Но наиболее адекватное объяснение мне пришло в голову, когда я прочитал его по слогам: per col — по колонкам.

Percolator представляет собой надстройку над BigTable, позволяющую выполнять комплексные вычисления на основе имеющихся данных, затрагивающие много строк и даже таблиц одновременно (в стандартном API BigTable это не предусмотрено).

Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения  в остальной базе осуществляются посредством механизма »обозревателей». Если говорить в терминах реляционных СУБД, то обозреватели — что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++), который исполняется в случае возникновении изменений в определенных колонках BigTable (откуда, видимо, и пошло название). Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.

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

В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:

• Проблемы «отстающих»: когда один из серверов (или одна из конкретных подзадач) оказывался существенно медленнее остальных, что также значительно задерживало общее время завершения работы кластера.
• Пиковая нагрузка: MapReduce не является непрерывным процессом, а разделяется на работы с ограниченной целью и временем исполнения. Таким образом помимо необходимости ручной настройки работ и их типов, кластер имеет очевидные периоды простоя и пиковой нагрузки, что ведет к неэффективному использованию вычислительных ресурсов.

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

Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.

Google Spanner

Spanner представляет собой единую систему автоматического управления ресурсами всего парка серверов Google.

Основные особенности:

• Единое пространство имен:
  • Иерархия каталогов
  • Независимость от физического расположения данных
• Поддержка слабой и сильной целостности данных между датацентрами
• Автоматизация:
  • Перемещение и добавление реплик данных
  • Выполнение вычислений с учетом ограничений и способов использования
  • Выделение ресурсов на всех доступных серверах
• Зоны полу-автономного управления
• Восстановление целостности после потерь соединения между датацентрами
• Возможность указания пользователями высокоуровневых требований, например:
  • 99% задержек при доступе к этим данным должны быть до 50 мс
  • Расположи эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии
• Интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах

Проектировалась из расчета на:

• 1-10 миллионов серверов
• ~10 триллионов директорий
• ~1000 петабайт данных
• 100-1000 датацентров по всему миру
• ~1 миллиард клиентских машин

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

Прочие компоненты платформы

Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++, Java, Python и Perl). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.

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

• GWT для реализации пользовательских интерфейсов на Java;
• Closure — набор инструментов для работы с JavaScript;
• Protocol Buffers — не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;
• Snappy — быстрая компрессия данных, используется при хранении данных в GFS.

Подводим итоги

• Стабильные, проработанные и повторно используемые базовые компоненты проекта — залог её стремительного развития, а также создания новых проектов на той же кодовой базе.
• Если задачи и обстоятельства, с учетом которых проектировалась система, существенно изменились - не бойтесь вернуться на стадию проектирования и реализовать новое решение.
• Используйте инструменты, подходящие для решения каждой конкретной задачи, а не те, которые навязывает мода или привычки участников команды.
• Даже, казалось бы, незначительные недоработки и допущения на большом масштабе могут вылиться в огромные потери - уделяйте максимум внимания деталям при реализации проекта.
• Нельзя полагаться даже на очень дорогое оборудование - все ключевые сервисы должны работать минимум на двух серверах, в том числе и базы данных.
• Распределенная платформа, общая для всех проектов, позволит новым разработчикам легко вливаться в работу над конкретными продуктами, с минимумом представления о внутренней архитектуре компонентов платформы.
• Прозрачная работа приложений в нескольких датацентрах — одна из самых тяжелых задач, с которыми сталкиваются интернет-компании. Сегодня каждая из них решает её по-своему и держит подробности в секрете, что сильно замедляет развитие opensource решений.

Источники информации

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

Поправки и уточнения приветствуются

• Official Google Data Centers Site
• Challenges in Building Large-Scale Information Retrieval Systems (Jeff Dean, WCDMA ’09)
• Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, Ladis ’09)
• Google Percolator official paper
• Google Megastore official paper
• Google Percolator
• Google Caffeine Explained
• Google Spanner
• Google Software Infrastructure Dubbed Obsolete by ex-Employee
• Google Moves Off the Google File System
• Google Internet Stats
• Google Statistics
• Google Plus — Killer Facts and Statistics
• YouTube statistics
• Alexa on Google
• Internet World Stats
• Google Inc. financials
• Hotmail still on top worldwide; Gmail gets bigger
• Google Server Count
• Google Envisions 10 Million Servers
• Google Data Center FAQ

Бонус: типичный первый год кластера в Google

• ~1/2 перегрева (большинство серверов выключаются в течении 5 минут, 1-2 дня на восстановление)
• ~1 отказ распределителя питания (~500-1000 резко пропадают, ~6 часов на восстановление)
• ~1 передвижение стойки (много передвижений, 500-100 машин, 6 часов)
• ~1 перепрокладка сети (последовательной отключение ~5% серверов на протяжении 2 дней)
• ~20 отказов стоек (40-80 машин мгновенно исчезают, 1-6 часов на восстановление)
• ~5 стоек становится нестабильными (40-80 машин сталкиваются с 50% потерей пакетов)
• ~8 запланированных технических работ с сетью (при четырех могут случаться случайные получасовые потери соединения)
• ~12 перезагрузок маршрутизаторов (потеря DNS и внешних виртуальных IP на несколько минут)
• ~3 сбоя маршрутизаторов (восстановление в течении часа)
• Десятки небольших 30-секундных пропаданий DNS
• ~1000 сбоев конкретных серверов (~3 в день)
• Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.

Недавно несколько человек довольно независимо друг от друга подтолкнули меня к новой странице-рубрике на Insight IT. Как не трудно догадаться по заголовку, это F.A.Q. по высоконагруженным проектам и связанным темам.

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

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

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

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

1. Балансировщики нагрузки + не имеющие ничего общего исполнители: в данной модели существует некий входящий поток запросов или заявок, которые поступают через балансировщик(и) нагрузки на один из ряда равноправных узлов-исполнителей, которые каким-то образом генерируют результат запроса и отправляют обратно через балансировщик нагрузки или напрямую. В роли балансировщика нагрузки может использоваться DNS round-robin, различные программные или аппаратные решения, а также их комбинации (иерархии).
2. Балансировщики нагрузки + узлы без состояний + масштабируемое хранилище: для большинства веб-приложений необходимо сохранять некое состояние, и тогда по сравнению с предыдущей моделью вводят в действие систему хранения данных, также приспособленную для горизонтального масштабирования, зачастую ценой отказа от реляционных и прочих комплексных операций, что сводит её интерфейс к простому взять-положить.
3. Принцип «равный-равному» (P2P): заключается в самостоятельном распределении данных и/или задач между равнозначными узлами на основе заранее определенного алгоритма; причем клиент зачастую сам является узлом системы (BitTorrent), либо обращается к произвольному узлу, который становится «агентом» для поиска и делегации конкретного запроса исполнителю (Cassandra).
4. Распределенные очереди: эта модель основывается на выделении очередей, как отдельных сетевых сервисов; используются либо для передачи произвольных данных между компонентами системы, либо для создания очереди выполнения длительных операций (например конвертации фото/видео/аудио).
5. Парадигма подписка/публикация: в системе определяется набор типов событий, одни компоненты системы создают эти события (публикуют сообщения), а другие — хотят узнавать когда произошло событие определенного типа (подписка на сообщения) и каким-то образом реагировать; реализуется обычно в виде отдельного сетевого сервиса, иногда совмещенного с распределенными очередями.
6. «Молва» и прочие похожие на жизнь архитектуры: основная идея заключается в том, что компонентам системы не нужно знать об общей структуре всей сети; узлу достаточно лишь знать о нескольких «соседях», с которыми он будет напрямую взаимодействовать, а распространение информации внутри системы возможно по принципу «молвы», то есть цепного распространения через «соседей»; используется, например, для развертывания кода или упрощения конфигурации в больших кластерах.
7. MapReduce и потоки данных: изначально MapReduce был предложен Google для обработки огромных массивов данных, с которыми они сталкиваются, алгоритм вкратце следующий:
   • Каждый узел в системе считывает с дисков свою часть данных и образует из них пары «ключ-значение»;
   • Эти пары преобразуются в новые промежуточные пары «ключ-значение» по определенному алгоритму (стадия Map);
   • Промежуточные пары сортируются и группируются по ключу и для каждого ключа вычисляется новое значение на основе группы промежуточных значений (стадия Reduce);
   • Результат стадии Reduce обычно и является желаемой информацией, полученной из массива данных, и обычно сохраняется в распределенную файловую систему, либо каким-то образом импортируется в другое хранилище.

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

8. Дерево ответственности: заключается в разложение общей задачи на подзадачи и рекурсивной делегации их выполнения другим узлам системы, что в итоге и образует дерево; используется как часть некоторых других моделей.
9. Обработка входящих потоков: скорее класс задач, чем шаблон, но тем не менее… есть некие внешние события (например сбои в клиентском ПО), обладающие какими-то характеристиками, информация о которых постоянно и непрерывно поступает в систему, которая должна в реальном времени обрабатывать события и получать на основе этих данных требуемую информацию. Реализуется посредством сети обрабатывающих узлов с общем хранилищем информации.
10. Масштабируемое хранилище: их можно рассматривать как отдельный субъект, обладающий свойством масштабируемости; по типам можно выделить базы данных (зачастую не структурированных) и файловые системы.
11. Разделение ответственности запросов на чтение и на запись (СQRS): звучит страшно, на деле еще страшнее, если по-простому, то… модель основывается на обмене сообщениями между равноправными компонентами, хранении, обработке данных в оперативной памяти, асинхронном масштабируемом хранилище данных для их сохранности и репликации компонент для надежности и отказоустойчивости.

Хотелось бы обсудить в комментариях какие из перечисленных моделей Вы чаще всего используете на практике и почему? В чем видите перспективы, преимущества и недостатки каждого? Может быть вспомните еще шаблоны, которые не попали в список?

P.S.: Я недавно участвовал в сессии вопросов-ответов про высоконагруженные и не очень интернет проекты, возможно Вам будет интересно почитать.

Хоть сезон конференций в Москве и подходит к своему завершению, на около-ИТ мероприятия я все еще продолжаю заглядывать. В этом «выпуске» моих отчетов по конференции я пробегусь сразу по двум мероприятиям, обозначенным в заголовке. Не так уж и много у меня нашлось что сказать о каждом, чтобы выделять под каждое отдельный пост. Итак…

Google Developer Day

Для интернет-гиганта формат, размах и уровень мероприятия были на стандартном уровне: большой павильон в Крокус Экспо, много обслуживающего персонала, почти 2000 участников и 6 параллельных секций. Практически не работающим WiFi и некоторым дефицитом еды сегодня никого не удивишь, а вот необычным моментом оказались раскиданные по павильону холодильники с газировкой на подобии безалкогольного мохито и холодным чаем, вместо традиционной простой воды. Доступ к сидениям-грушам — отличное решение для создания «нулевого» ряда в переполненных залах, активно пользовался.

Открытие было традиционной цепочкой рассуждений об истории и судьбе индустрии, как все здорово растет и развивается. Запомнилось, что привели какие-то фантастические цифры по соотношению использования браузеров в России, невероятно низкая доля использования IE (жаль не помню точно, кажется меньше 20%) — судя по всему собирали с google.ru, когда все, для кого IE и Интернет являются синонимами, поголовно пользуются Яндексом Помимо прочего на вступлении показывали трейлер четвертого Ледникового Периода в анаглифе (как демонстрацию тега <video />) и выступали Zeptolab на правах авторов самой популярной Android-игры.

Секции были разделены по тематикам: HTML5/Chrome, Android, AppEngine, Google+ и Tech Talks. Самый большой зал, одновременно являющийся холлом, довольно неудачно отдали в распоряжение GTUG’ов — тусовки проектов, основанных на технологиях Google, практически пустовал все время, кроме кофе-брейков и обеда.

Выбрать секцию для посещения было непросто: заранее было ясно, что все будет довольно поверхностно, да и технологиями Google как разработчик я пользуюсь довольно условно, максимум иногда Closure Compiler для минимизации JS, CDN для jQuery, как-то пару раз с почтой ленился возиться — у них хостил и.т.п. Как я уже часто последнее время делаю — пошел туда, где меньше всего актуально, чтобы хотя бы кругозор расширить.

В конечном итоге большую часть дня провел в зале с HTML5. Sam Dutton, пожалуй, больше коллег рассказал толковых вещей, в частности довольно интересно было послушать про создание веб-приложний, пригодных для использования людьми с ограниченными физическими возможности, которых по их данным порядка 5% от пользователей Интернета. Много внимания было уделено читалкам текста (на примере их решения ChromeVox) и навигации по DOM без мыши. Еще он показал как решать основные задачи по дебаггингу веб-приложений с помощью Chrome Developer Tools — я как-то по старинке привык Firebug для этого пользоваться, а после того доклада вроде даже как-будто и почти полностью пересел на решение от Google, функционал на самом деле не уступает, просто с юзабилити у них не очень гладко, да и дело привычки.

Остальные доклады были о HTML5 в различных его проявлениях: работа с сайтами при отсутствии доступа к Интернет, отрисовка всего что только можно в canvas, разные совсем не поддерживаемые браузерами штуки и прочее. Интересно послушать, но по сути далеко не в каждом проекте хоть как-либо применимо, хотя за History API и хранением данных на клиенте, определенно, будущее.

С последнего доклада секции о повышении быстродействия сайтов пришлось сбежать из-за перспективы простоять часа 2 в традиционных московских вечерних пробках, но судя по всему не много потерял — речь шла просто об их продукте Google PageSpeed, о котором и так полно информации на официальном сайте.

Oracle Day

В то время как GDD для меня является традиционным мероприятием, вылазка на Oracle Day оказалась довольно спонтанным экспериментом. Не смотря на то, что Oracle считают себя королями баз данных, прецедентов применения их в успешных интернет-проектах практически нет. Собственно, так как в традиционных компаниях я никогда не работал и пока не планирую, то и мои пути с продукцией известного ИТ-гиганта толком и не пересекались, так что меня давненько интересовал вопрос чем обусловлен ценник с невообразимым количеством нулей на практически весь ассортимент их продукции.

С точки зрения организации от интернет-конференций все отличалось слабо: довольно пафосное место (Редиссонс Славянская), много участников, мини-выставка и пр. Из откровенных промахов: полное отсутствие WiFi в залах — хоть в отеле и есть своя качественная сеть, но доступа к ней не дали, а единственная точка от организаторов была в холле и естественно была ни к селу ни к городу. Плюс странно что воду раздавали в здоровенных полуторалитровых бутылках — иметь доступ к воде во время секций было проблематично.

Повода самостоятельно поизучать данный вопрос у меня как-то не было, а вот анонс мероприятия под руку подвернулся вовремя — и вот я там

Любопытство я свое удовлетворил сполна: мероприятие было на 100% посвящено саморекламе, еще более открыто, чем на бесплатных конференциях от интернет-компаний — сотрудники активно пытались продавать со сцены. Как и предполагалось, вопрос о ценах полностью оставался «за кадром», а речь шла о сравнении различных технических параметров с «конкурентами», причем конкуренты подбирались специально чтобы представить все в лучшем свете, а тот факт, что за решение от «конкурентов» придется выложить намного меньше, а то и вообще ничего (opensource), и вовсе умалчивался.

Из практически полезных докладов для меня оказалось выступление об Oracle Firewall о безопасности в разрезе СУБД. Ничего кардинально нового, но докладчик толково разложил по полочкам основные риски (человеческий фактор, SQL-инъекции, кейлоггеры на компьютерах администраторов, уязвимости в ПО и.т.п.) и способы их уменьшения.

Наглядным примером (по крайней мере для меня) оказался Oracle Big Data Appliance, который, как оказалось, является просто Apache Hadoop с блекджеком и прочими плюшками от Oracle — каков ценник на эти самые «плюшки» можно лишь догадываться.

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

Финальная черта

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

Сейчас вроде по-свободнее стало с временем, в связи с закрытием одного из проектов, так что постараюсь вновь вернуться к написанию постов «по делу», так что очень рекомендую подписываться на RSS, если еще не успели До новых встреч!

В этом году я почти до последнего момента не знал попаду ли на HighLoad++, но благодаря поговорке «не имей сто рублей, а имей сто друзей» все же попал в список участников (огромное спасибо Аксане и ВШБИ). По ходу мероприятия написать традиционный отчет не получилось, но лучше поздно, чем никогда

Начну, как обычно, с организационных моментов и прочих вещей не по делу. Регистрация заняла ровно 30 секунд, никаких очередей. Удивило, что поленились хоть капельку поменять раздаточные материалы и их дизайн с прошлого года — выдали абсолютно идентичные прошлогодним пакетик, блокнот и ручку. На входе стоял стенд с ходящей по беговой дорожке топлесс девушкой с бодиартом, которую потом все кому не лень выкладывали в твиттер с соответствующим хэштегом. На том же стенде разыгрывали Mac Pro между теми, кто оставит контакты. К слову, владельцы стенда оказались разработчиками ужасно работающего под Android 3.1 покерного сервиса, ничего более примечательного о них сказать не могу. Стендов, как обычно, было по пальцам пересчитать: пару хостинг-провайдеров и Битрикс ничем особым не выделались, а в Google тоже разыгрывали технику, один из последних смартфонов Samsung, а еще за прохождение теста в Google Docs дарили футболки с надписью «I’m feeling lucky» на спине — очень актуально на экзаменах и в казино

С WiFi традиционные проблемы почти весь первый день, планшет с 3G спасал ситуацию. Кормили вполне приемлемо, правда ассортимент скудный — я, наверное, за весь год меньше жареной рыбы съел, чем за эти два дня. Первые три ряда мест в залах были «только для VIP», которые, как я понял, включали в себя докладчиков и возможно личных знакомых организаторов, причем таких человек было на вскидку меньше 5% участников и в итоге 95% мест пустовали до тех пор, пока все не забили на эту схему. Определенно не самый удачный ход, если уж и бронировать места, то не в таком количестве. Трансляция одного из залов в коридоре — спорное решение, с одной стороны можно послушать пока ешь, с другой — общаться мешает капитально, особенно когда собираются «тусовки» вокруг докладчика, например во второй день нужно было сильно напрягаться, чтобы услышать Олега Илларионова в кулуарах.

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

Швейцарец Alvaro Videla делился своим опытом работы с RabbitMQ, я, признаюсь, не особо следил за этим проектом, но подал он его достаточно вкусно и судя по обозначенным векторам развития внимания RabbitMQ все же стоит.

Второй докладчик, Buddy Brewer, повествовал о тестировании скорости отрисовки страниц в браузерах как искусственно (посредством диаграммы загрузки компонентов страницы в виде водопада), так и вживую на пользователях (посредством window.performance.timing, о котором я почему-то раньше не слышал, и различных Javascript-библиотек).

Robert Treat из OmniTI выступил намного хуже, чем в прошлом году, довольно скучно рассказывал про PostgreSQL и мало кому нужные ньюансы работы с ним, хотя доклад назывался совсем по-другому.

После обеда шел доклад Domas Mituzas, простого DBA из Facebook, хотя в прошлом году выступал более высокопоставленный представитель. Речь шла на этот раз про MySQL, в частности про основные проблемы и доработки, сделанные в форке от Facebook, также затрагивался вопрос грядущего в следующем году MySQL 5.6.

Josh Berkus в этом году выступил более удачно, не зря ему дали выступить дважды. Первый был довольно специфичным, но от этого не менее интересным, основной темой был довольно узкий класс приложений, который он называл firehose applications (пожарный шланг). Они представляют собой сборщики данных в реальном времени для последующей аналитики, было два примера: обработчик отчетов о критических сбоях в Mozilla Firefox и анализ работы ферм ветряных мельниц. Забавно оказалось их сравнение с традиционными сайтами:

• в сайтах главное, чтобы данные из базы всегда можно было хотя бы прочитать, и в случае сбоев или плановых работ её делают доступной только для чтения;
• в обсуждаемых же приложениех главное записать все поступающие данные, а пользовательский интерфейс в целом можно запланированно и не очень отключать — кому какое дело, если интерфейс для аналитических отчетов не работал 8 часов в ночь с субботы на воскресенье?

В его решениях обычно использовался та или иная форма NoSQL хранилищ, для сбора текущих данных и PostgreSQL для хранения уже обработанных отчетов и предоставления их пользователям. Второй доклад Josh’а был менее формальным и был посвящен вопросам SQL vs NoSQL, что по сути свелось к тому, что наличие SQL-интерфейса — дело десятое при выборе СУБД для конкретного проекта, важнее понимать другие особенности каждого конкретного хранилища данных.

Mi***ft в этом году, как и Facebook, сменил докладчика, но это не уберегло их от очередного провала. Хоть и после доклада появилось-таки несколько вопросов от аудитории, но разработчиков по-прежнему в целом мало интересует тематика проприетарного ПО, даже при поддержке PHP и Hyper-V. Продавать простым смертным у них получается намного лучше, чем продавать специалистам.

Robert Virding был, пожалуй, одним из лучших докладчиков первого дня. Хоть я и неплохо знаком с Erlang, но послушать о нем из уст одного из создателей — невероятно увлекательно, как-будто переживаешь на своей шкуре историю целого языка программирования. Robert очень подробно объяснил чуть ли не каждое ключевое решение, принятое при проектировании и разработке Beam, основной реализации виртуальной машины Erlang, а также освятил несколько альтернативных воплощений этого языка в жизнь.

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

Второй день был полностью «на русском». Первый зал на 100% состоял из размусоливаний различных систем хранения данных — не знаю хорошо это или плоха, вопрос актуальный, но то что очень однообразно и об одном и том же — факт. Второй зал был по-разнообразнее, но я там был всего на двух с половиной докладах.

Я немного опоздал на первый доклад от mail.ru, но, судя по всему, не много потерял — они снова пропагандировали свое детище, Tarantool, на этот раз в сравнении с Redis. Штука довольно интересная, но каких-то особых преимуществ перед последним я так и не увидел или, может быть, не хотел увидеть.

Представители Skype рассказывали о своем опыте работы с Redis и, в частности, о конкретном кейсе с решардингом «на живую» — довольно увлекательно, красивое решение с фильтрующим replication proxy, которое правда скорее всего скоро потеряет актуальность при текущем направлении развития проекта Redis. Сам активно им пользуюсь, но что-то подобное проделывать пока не приходилось.

Владимир Климонтович рассказал довольно подробно о проекте Apache Cassandra, правда ничего нового я не услышал — все что было сказано легко можно найти на официальном сайте проекта, что я в свое время и сделал.

На докладе OpenStat я тупо сидел в Интернете, особо не вслушиваясь — после их же доклада в прошлом году слушать еще раз примерно о тех же заморочках с Apache Hadoop было не особо интересно, особенно если учесть, что я в 2008-м с ним очень плотно работал.

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

• кроссбраузерное сохранение работы кнопок вперед/назад/перезагрузить без полной перезагрузки страниц,
• кроссбраузерное же постоянное соединение браузера с сервером (используют long polling, websocket по очевидным причинам пока практически не применим),
• сохранение корректной работы с выключенным JavaScript и в «необычных» браузерах,
• выдача нового контента частями через скрытый iframe для улучшения визуальной скорости загрузки страницы,
• эмуляция процесса загрузки страницы через динамический favicon,
• очистка памяти при переходах между страницами,
• использование одного постоянного соединения для нескольких вкладок посредством локального хранилища из HTML5

…и многие другие проблемы и задачи — все это довольно подробно Олег разложил по полочкам. Помимо этого он рассказал как реализован поиск по друзьям внутри браузера через выгрузку списка друзей в JSON, а также целая куча вопросов о том о сем, например про почту и все ту же «волшебную» базу данных на C. Новую статью про Вконтакте я в этом году не планировал, так что особо не записывал, хотя возможно и зря. Выступление Олега слегка продлили, так как следующий докладчик куда-то пропал, но по факту когда он нашелся выступление про новомодный Node.js оказалось не очень и большая часть зала перекочевала «в кулуары» дальше слушать Олега и задавать ему вопросы.

После кофе-брейка я вернулся в первый зал, где продолжалась эпопея с хранением данных. Одноклассники наконец-то поняли, что их старинное решение на BerkleyDB + Java RMI — не панацея от всех болезней, и перешли на другое решение для одной из задач, хранения изображений, не менее самопальное. Задумка была в основном в замене BerkleyDB на традиционные блобы фиксированного размера, аналогично решению в Facebook, при этом остальная схема работы изменилась не сильно — доступ к системе через HTTP посредствам Tomcat, внутри правда отказались от RMI в пользу сокетов и собственного протокола, для хранения конфигурации — Apache Zookeper, типичный для Java-мира наборчик. Из интересных решений — использование JBOD с созданием уникального идентификатора винчестера и возможностью переткнуть любой из них в другой сервер. В остальном ничего особенного: лог транзакций, репликация, индекс в памяти посредством собственной реализации HashMap и т.п.

Последний доклад, который я послушал, был слегка похож на предыдущий, с той лишь разницей, что хостинг-провайдер Clodo не стал изобретать велосипед и воспользовался «полуфабрикатом» под названием Openstack Swift — хранилище бинарных объектов с HTTP интерфейсом, которыми вполне могут быть и изображения. Доклад был о том как они его допиливали, в основном посредством использования nginx и его модулей. К слову, посмотрел их цены (возможно скоро Insight IT придется снова переезжать, приглядываюсь к вариантам) и был разочарован, очень существенно выше рынка не смотря на неизвестность компании, в такой ситуации наоборот логичнее было бы демпинговать…

В целом впечатления от конференции положительные, процент стоящих докладов близок к 20-30%, что для технических конференций очень прилично. Организация и контингент тоже на уровне. Но нельзя не сказать про ценник (21к за живое участие и 11к за онлайн-трансляцию) — он явно рассчитан на оплату работодателями и посещение конференции за собственный счет определенно того не стоит. Альтернативные варианты попасть на мероприятие хоть и есть, но довольно ограничены — каждый раз приходится изворачиваться, чтобы попасть бесплатно при отсутствии работодателя. Хотя может быть надо было просто заморочиться и попасть в список «информационной поддержки»…

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

До встречи на GDD через пару дней!

Пишу прямо из WTC, где проходит это мероприятие, благо обзавелся-таки недавно планшетом на Android 3.1.

На входе вручили забавный сворачивающийся браслетик с написанным IP-адресом Яндекса и пакет с сувениркой, причем размер футболки угадали не спрашивая, что радует. Здоровенный принтер, превращающий QR-код с хэшем в пластиковый бейдж — как минимум необычное решение). Это первая на моей памяти бесплатная конференция, где в обед было адекватное количество еды, но промах все же допустили — на этот раз это был дефицит вилок, сплошные ножи на столах, искал минут 20, наверное, если не считать многочисленные встречи и общение с знакомыми и не очень людьми на территорией столовой А еще на воде сэкономили — подмосковного производства, видимо из-под крана, на вкус ужас и кончилась к середине дня. Вай-фай приемлимо работал тоже только до обеда. А в остальном организация конференции — на достойном уровне.

В холле помимо самого Яндекса, который проводил различные конкурсы для сисадминов (например, конфигурирование nginx за 10 минут для достижения обработки максимального количества запросов в секунду), были представлены HTC и Samsung. У HTC снова какой-то конкурс, телефон в Твиттере разыгрывали, кажется он как-то связан с роботом, который тусовался около их стенда. А Samsung притащили два здоровенных телевизора, которые наверняка стоят в магазинах под 200к каждый. И помимо этого, естественно, у обоих были представлены линейка последних телефонов и планшетов, HTC Flyer правда скорее большой КПК напоминает, чем планшет, но не суть. Необычно было, что техника вся без «привязи» была — неужели там все настолько хорошо с охраной и адекватностью публики? Еще писали, что где-то показывают планшет с Wi***ows 8, но я не наткнулся.

По поводу, собственно, самих докладов и выступлений, постараюсь быть краток, не хочу все пересказывать — видео и презентации организаторы обещали опубликовать. Сегодня я решил не бегать по залам и 90% времени провел во втором зале. Оставшиеся 10% пришлись на первое выступление о текущих проблемах, задачах и решениях в поисковых алгоритмах Яндекса и перед уходом заглянул на доклад русскоговорящего сотрудника Facebook об их опыте использования Hadoop. История о том, с какими проблемами сталкивается Яндекс, была любознательной, но не несла особой практической ценности даже SEO-специалистам. Пару лет уже практически не работал с Hadoop, но текущая ситуация с ним меня нисколько не удивила: проект успешно растет и развивается, активно решаются основные проблемы с надежностью (децентрализация мастер-узлов, failover в диапазоне 5-10 секунд), стабильностью, потреблением ресурсов (дополнительный узел — менеджер ресурсов), производительностью и эффективностью использования дискового пространства (за счет техник, схожих с RAID: XOR и Reed-Solomon, позволяющих восстанавливать утерянные реплики при экономии дискового пространства до 50% по сравнению со стандартной тройной репликацией). На другой доклад по Hadoop, от Cloudera, я не пошел, так как подумал что врядли что-то новое на нем услышу.

Во втором зале было аж четыре секции, обо всем по-порядку:

• Мобильная разработка — если в двух словах, то в этой области сейчас основной проблемой является гетерогенность устройств, что делает кроссплатформенность очень желательной, но практически недостижимой в боевых условиях. Все доклады были исключительно про C++ под тем или иным соусом: в Яндекс.Панорамах используют OpenKode с кучей своих костылей, а навигаторы Shturmann под Android пишут с использованием NDK. Для тех, кто занимается подобными извращениями, возможно актуально, да и для общего развития полезно.
• Веб-разработка — секция началась печально, с очередного само-рекламного выступления одного стартапа, получившего приличные инвестиции — Cloud9. Если закрыть глаза на попытки докладчика «впарить» аудитории свой сервис, то у них классная задумка — написать на чистом JavaScript (V8+NodeJS) IDE для разработки на JavaScript, что судя по слайду с архитектурой и демками у них вполне получилось. После обеда секцию продолжили истории про клиентскую разработку в Yandex — душещипательные истории о стратегии использования селекторов, конвертации статического HTML в шаблоны, повторном использовании кода (блоков) и прочих прелестей жизни команды верстальщиков в большом проекте. Закрывал секцию обаятельный гость по имени Chaals из компании Opera Software, ранее работавший в W3C, который на хорошем английском повествовал о веб-стандартах, о том что же такое на самом деле HTML5 и многих других аспектах морали ведения веб-бизнеса; в итоге правда доклад получился сильно философским (по образованию он оказался историком ), да и видно было, что далеко не все его адекватно понимали.
• Администрирование — по большей части секция сводилась к мониторингу и реакцию на ЧП в Яндекс, причем первым докладчиком был рядовой сисадмин, а второй — руководителем группы системных администраторов ряда сервисов, что очень сильно повлияло на их точку зрения на в целом одну и ту же ситуацию в одной и той же компании. Алексей явно весь на нервах и акцентировал внимание на фишках системы мониторинга, чтобы она работала «как часы», а Роман обращал внимание на то, что залог успеха — унификация, автоматизация и отсутствие лишних тревог по ночам, а что собственно и как делается и чинится — дело десятое, да и вещал он спокойным и размеренным голосом, почти как у диктора.
• Тестирование — эта секция состояла из двух докладов, но я, каюсь, сбежал через 10 минут после начала первого. Выступал солидный мужчина сильно пожилого возраста и выступал он от имени Российской Академии Наук, начал он свое повествование с истории тестирования, на первом же слайде значились года что-то в районе 1974, сопровождавшиеся историями о тестировании каких-то секретных систем для Советского Союза и так и не понял какого компилятора. Сначала я подумал, что это он так представляется, но когда стало понятно, что в целом это и есть основная тема доклада — я решил, что с меня хватит, так как мой мозг подобные истории практически не воспринимает…

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

До новых встреч! Как оффлайн, так и онлайн

Что надо будет делать?

• Надо будет писать на Java сервлеты и просто программы.
• Есть собственное API доступа к данным, через которые надо работать.
• В компании используются: Linux (RHEL6/CentOS5), nginx, Java, Oracle

Требования к кандидату

• Опыт программирования от 3-х лет. На чем — не важно.
• Порядочность
• Ответственность
• Заинтересованность в результате

Условия работы

• Зарплата: 90000р. в месяц
• Москва, офис
• Полный рабочий день

Куда отправлять резюме?

• Антонов Игорь Константинович, IT Директор

Вы опоздали, вакансия закрыта!

Недавно наткнулся на полу-поучительный и полу-юмористический материал по масштабируемости интернет-проектов. Кому-то он может показаться, как и мне, забавным, а кому-то — в таком формате может оказаться легче воспринимать информацию. Надеюсь тебе тоже понравится, так что спешу поделиться как переводом, так и оригинальным видео =)

На конференции O’Reilly MySQL CE 2011 выступил Josh Berkus c пламенной речью о том, как быть уважаемым и известным, при этом не уделяя ни капли внимания масштабируемости. Его очень сильно удивляет, почему самыми популярными, известными и инвестиционно-привлекательными интернет-компаниями становятся именно те, чей интерфейс неработающего состояния (в частности «киты» и «роботы» у Twitter), известен больше, чем когда они работают. Так что Josh предлагает всем придерживаться следующей стратегии:

• Всегда следуй трендам: используй только те технологии, которые навели больше всего шумихи в Интернете: NoSQL, «облака», MapReduce,Rails,RabbitMQ. Основным инструментом для выбора технологий должен быть Reddit (или Хабр, если адаптировать к российским реалиям). За что больше голосуют — то и используйте.
• Не следите за текущей ситуацией: математика и статистика — абсолютно бесполезны. Мониторинг использования ресурсов, нагрузочное тестирование, отслеживание трафика, тестирование производительности и тонкая настройка — да кому оно надо? Лучше доверять интуиции — с какими проблемами мы сталкивались на предыдущей работе, с такими же столкнемся и в этот раз
• Ни о чем не беспокойтесь: параллельное программирование не в моде, даже не смотря на то, что Erlang позволяет приложениям работать на кластере из тысяч серверов. Крутые ребята не заботятся об оперативной памяти и управлении потоками. Нужно не париться и использовать однопоточные приложения с кучей блокировок, игнорируя области видимости и контексты памяти. Часто обновляющиеся таблицы из одной строки и мастер-очередь, в которую попадают все задания — лучшие паттерны из всех существующих.
• Каждый запрос должен попадать напрямик в базу данных: кэширование — твой смертный враг. Каждый запрос должен идти напрямую к СУБД, ни шага в сторону!
• Масштабировать нужно невозможные вещи: масштабирование простых и очевидных вещей — для слабаков! Это совершенно не круто заниматься масштабированием веб-серверов, кэшей (хотя ими пользоваться и так категорически запрещено) и серверов предложений.
• Создавайте точки отказа: вне зависимости от того, насколько большой ваш проект, в нем обязательно должно быть место, при отказе которого перестанет работать вся система. Лучшие кандидаты на эту роль: балансировщик нагрузки, очередь задач и мастер база данных.

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

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

Если вы еще не читаете Insight IT регулярно, настоятельно рекомендую подписаться на RSS.

Как известно, MySpace появилась на рынке даже несколько раньше, чем Facebook, с практически аналогичным продуктом. Но при этом на сегодняшний день Facebook — общепризнанный лидер рынка социальных сетей, а MySpace даже далеко не все слышали название. С технической точки зрения у проектов совершенно разные подходы: Facebook построен на opensource технологиях, типичный LAMP, MySpace же полностью использует стек от Microsoft. Некоторое время назад в зарубежной блогосфере зародилась оживленная дискуссия на тему: а не выбор ли закрытых технологий стал основной причиной проигранной MySpace «гонки»  социальных сетей?

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

• MySpace’s Death Spiral
• Did The Microsoft Stack Kill MySpace?
• 8 Lessons We Can Learn From The MySpace Incident — Balance, Vision, Fearlessness
• Why Facebook is succeeding where Myspace has failed
• HackerNews: раз и два

Некоторые ключевые точки зрения:

• Все интернет-компании в первую очередь технологические. Даже если основной тематикой является развлечение,  все равно оно предоставляются посредством технологий.
• Все неудачи в бизнесе не связаны с технологиями. Если менеджмент не понимает ценность каждого разработчика и не может делегировать полномочия и ответственность — проект не станет успешным. С другой стороны если разработчики не знают какие вещи являются важными для бизнеса, так как их просто не держат в курсе — это так же ничем хорошим не заканчивается.
• Нельзя мотивировать разрушение инновации. В MySpace основным источником дохода являлась рекламе Google, доход с которой напрямую зависел от количества просмотров страниц и кликов, что в результате подтолкнуло MySpace добавить дополнительные не нужные страницы ко всем действиям пользователей, что абсолютно уничтожило все юзабилити.
• Корпоративная разработка и веб-разработка — совершенно разные вещи. Не смотря на тот факт, что большинство сошлось во мнении, что ни продукция Microsoft, ни разработчики MySpace не виноваты в провале проекта,  тот факт, что между инструментами, подходами и технологиями для разработки масштабируемых интернет-проектов и корпоративных приложений имеется очень большой разрыв, очевиден. Технологии, разработанные для корпоративного рынка, не могут быть без серьезной настройки и доработки использованы в мире крупных интернет-проектов.
• Нельзя позволять обратной совместимости останавливать развитие. В MySpace этот вопрос касается в большей степени пользовательского интерфейса: пользователи сами могут его настраивать. В итоге при введении каждой новой кнопочки или технологии типа AJAX им приходилось задумываться: «а не сломает ли это страницу при настройках какого-нибудь пользователя?»
• Успех не вечен. Изменения нужно вводить в эксплуатацию без страха ошибиться.
• Не полагайтесь на единственного клиента. Нужно иметь набор различных источников дохода, чтобы быть от них независимыми и продолжать развиваться даже  если один из них иссяк.
• Определитесь кем вы являетесь. Когда битва проиграна, можно переключить фокус на другую нишу, где меньше конкуренции — так новый генеральный директор MySpace переориентировал проект с социальной сети на сервис по открытию для себя новой музыки. Такие решения могут сработать, а могут и нет — но в любом случае это лучше, чем просто закрыть проект.

С моей точки зрения основной минус закрытых технологий — отсутствие полного контроля над всем кодом проекта, если проблемы начинаются в «закрытых» компонентах, то их исправление занимает нереальное количество времени, так как требует взаимодействия со сторонней компанией, которая? скорее всего? не будет торопиться решать каждую конкретную проблему и в лучшем случае её исправление будет доступно лишь в следующем релизе используемого продукта. Помимо этого, при использовании проприетарных технологий у разработчиков меньше понимания того, как работают внутри используемые технологии — никакая документация не заменит возможность «залезть под капот». В случае же с Microsoft проект совсем связывает себя по рукам и ногам, так как воспользовавшись монолитным стеком чаще всего нельзя постепенно перейти на другую технологическую базу, так как это по сути сводится к полному переписыванию кода проекта, что на подобном уровне очень затруднительно. Эти и подобные вещи замедляют процесс разработки, а значит и развитие проекта — этот фактор очень важен в современном интернет-сообществе, так как, если не двигаться вперед, конкуренты догонят и перегонят очень стремительно, как в целом и случилось с MySpace.

А какова твоя точка зрения на данную ситуацию? Может ли неудачное технологическое решение столь кардинально повлиять на успех бизнеса?

Новая архитектура поиска твитов

Backend

Поиск осуществляется теперь не с помощью MySQL-кластера, а посредством версии Lucene, адаптированной для работы в реальном времени.  Разработка этой подсистемы началась весной прошлого года, но полноценно использоваться она начала лишь недавно.

Так как поиск в Twitter является одной из самых часто используемых поисковых систем в мире (более миллиарда поисковых запросов в день), то требования к новой системе поиска были сопоставимо строгими:

• Обработка более 12000 запросов в секунду
• Индексация потока в 1000 новых твитов в секунду
• Задержка между написанием твита и его появлением в индексе должна быть менее 10 секунд

Lucene была взята за основу, так как на сегодняшний день это одно из лучших решений для реализации поиска в мире opensource. Но в текущей ее реализации она не была приспособлена к поиску в реальном времени. Команде Twitter пришлось переписать существенную часть основных структур в памяти, особенно списки записей. При этом внешний API Lucene остался неизменным, что позволило использовать поисковые алгоритмы в практически неизменном виде. Среди основных изменений в Lucene можно выделить:

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

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

После внедрения этой системы поиск стал потреблять лишь 5% доступных ему ресурсов, что оставило приличный запас для роста даже по меркам невероятно быстро развивающегося Twitter. Новая подсистема индексации способна обрабатывать в 50 раз больше твитов в секунду, чем они получали на момент запуска, что также является очень позитивным показателем. Помимо улучшения производительности, Lucene повысила и качество поиска,  а также открыла простор для новых улучшений в этом направлении.

Frontend

Кардинальный переворот в этой части системы можно описать одной фразой: Ruby on Rails заменен на Java-сервер, который они назвали Blender.

За неделю до развертывания Blender, количество поисков по твитам существенно возрасло из-за #tsunami в Японии. Среднее время поиска достигало 800-900мс.

После введения Blender в эксплуатацию среднее время отклика 95% запросов упало втрое: до 250мс, при этом уровень использования вычислительных ресурсов на frontend серверах упал вдвое. Тот же поток запросов стало возможным обрабатывать меньшим количеством серверов.

Чтобы понять, откуда взялся такой прирост производительности, необходимо показать в чем были слабые стороны старого поиска на Ruby on Rails. На каждом frontend сервере было запущено фиксированное количество однопоточных Rails процессов, каждый из которых занимался следующим:

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

Что же, собственно, представляет собой Blender? Это HTTP и Thrift сервер, разработанный на основе Netty, масштабируемой неблокирующей клиент-серверной библиотеки на Java, позволяющей легко и быстро разрабатывать клиенты и серверы для различных протоколов. Выбор пал именно на неё, а не на аналоги (например Jetty или Mina) из-за более чистого API, детальной документации и, что более важно, так как некоторые другие сервисы в Twitter уже используют её. Интеграции с Thrift у нее не было, но этот вопрос решился написанием простого кодека, обрабатывающего сообщения на низком уровне.

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

Заключение

На моей памяти эти нововведения в Twitter — практически единственный случай, когда крупный успешный проект настолько кардинально поменял основную часть стека используемых технологий. Да, они получили существенный выигрыш в производительности не в ущерб масштабируемости, но не поменяли же они большую часть команды разработчиков с Ruby-программистов на Java-программистов… Понятно, что это лишь инструменты, но довольно приличная часть людей, особенно те, кто в возрасте, не способны резко переключиться с привычных технологий на что-то совершенно новое. Хотя, скорее всего, в команде Twitter особо не было разработчиков «за 40″, так что для них это не было особой проблемой.

Источник информации

• Twitter Search 3x Faster (cпасибо Сергею Гуляеву за предоставленную ссылку)
• Twitter’s New Search Architecture

Скачать в оригинальном формате можно здесь: highload.mp4 или http://bit.ly/highload-video.

Приятного просмотра! Если есть какие вопросы или замечания — с удовольствием готов пообщаться в комментариях к посту

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

Оригинал

Не забываем подписываться на RSS

Статистика

• 95 миллионов просмотров страниц в месяц
• 800 HTTP запросов в секунду
• 180 DNS запросов в секунду
• Загруженность интернет-канала в 55 Мбит/с
• 16 миллионов уникальных пользователей в месяц

Технологии

Разработка

• C# — основной язык программирования
• Visual Studio 2010 Team Suite - IDE
• Microsoft ASP.NET 4.0 — framework
• ASP.NET MVC 3 - web Framework
• Razor — генератор шаблонов
• jQuery 1.4.2 — JavaScript framework
• LINQ to SQL и немного чистого SQL — доступ к данным
• Mercurial и Kiln — контроль версий исходного кода
• Beyond Compare 3 — инструмент для сравнения

Программное обеспечение

• WISC стек получен условно-бесплатно с помощью BizSpark
• Windows Server2008 R2 x64 — основная операционная система
• MS SQL Server 2008 R2 на Windows Server 2008 Enterprise Edition x64 — база данных
• Ubuntu Server
• CentOS
• IIS 7.0 — веб-сервер
• HAProxy — балансировка нагрузки
• Redis — используется как распределенная система кэширования
• CruiseControl.NET — сборки и автоматическая система развертывания кода
• Lucene.NET — полнотекстный поиск
• Bacula — резервное копирование
• Nagios (с плагинами n2rrd и drraw) для мониторинга
• Splunk — сбор и агрегация логов
• SQL Monitor от Red Gate — мониторинг SQL Server
• Bind - DNS
• DotNetOpenId — реализация OpenID на .NET
• WMD — текстовый редактор
• Prettify — подсветка синтаксиса
• MarkdownSharp — обработчик разметки Markdown на C#
• Flot — построение графиков на JavaScript

Внешние сервисы

• reCAPTCHA — защита от спама
• Google Analytics — веб-аналитика
• Kiln — Mercurial хостинг
• Pingdom — внешний мониторинг и уведомления
• CDN не используется, его роль выполняет sstatic.net, отдельный домен для статичных файлов SEN без cookie

Оборудование

Датацентры

• 1 стойка в Peak Internet, штат Орегон (чат и обнаружение данных)
• 2 стойки в Peer 1, Нью-Йорк (остальная часть SEN)

Серверы

• 10 веб-серверов:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • Windows Server 2008 R2
  • IIS
• 2 сервера баз данных:
  • Dell R710
  • 2x Intel Xeon Processor X5680 @ 3.33 GHz
  • 64 GB RAM
  • 8 жестких дисков
  • MS SQL Server 2008 R2
• 2 виртуальных сервера для балансировки нагрузки:
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 4 GB RAM
  • Ubuntu Server
  • HAProxy
• 2 сервера для кэша:
  • Dell R610
  • 2x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • CentOS
  • Redis
• 1 сервер для резервного копирования:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 32 GB RAM
  • Linux
  • Bacula
• 1 сервер для мониторинга, управления и сбора логов:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 32 GB RAM
  • Linux
  • Nagios
• 2 сервера для виртуализации:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • VMWare ESXi

Сетевое оборудование

• 2 маршрутизатора на Linux
• 5 свитчей  Dell PowerConnect

Прочее

• Rovio — маленький робот, позволяющий удаленным разработчиком посетить офис «виртуально»

Команда

• 14 разработчиков
• 2 системных администратора

Что нового?

• HAProxy стал использоваться вместо Windows NLB так как HAProxy является быстрым, нересурсоемким, бесплатным решением, которое работает. Полностью прозрачен для серверов, легче обслуживать по сравнению со старым решением, располагается на виртуальных машинах.
• CDN не используется, так как даже «недорогие» решения обходятся в очень приличную сумму по сравнению с тем трафиком, который входит в тарифный план хостинг-провайдера. Самое дешевой решение CDN от Amazon обошлось бы как минимум на тысячу долларов в месяц дороже при текущем уровне использования трафика.
• Резервное копирование на диски для быстрого восстановления и на кассеты для «истории».
• Полнотекстный поиск в SQL Server плохо интегрируется, нестабилен и обладает низким качеством результатов, так что они перешли на Lucene.
• Все сайты в SEN теперь работают на общей платформе: используется общее оборудование и программное обеспечение.
• Проект разделен на разные сайты для разных ниш, чтобы полностью изолировать группы аудитории, специализирующиеся в каждой конкретной области.
• Используется агрессивное кэширование, большинство страниц кэшируются в виде HTML для анонимных пользователей средствами IIS.
• Используется три уровня кэширования: локальный, относящийся к каждому сайту и глобальный.
• Локальный кэш доступен только для каждой пары сайт/сервер:
  • Используется для уменьшения сетевых задержек, по сути просто через HttpRuntime.Cache.
  • Содержит такие вещи как пользовательские сессии, будущие обновления счетчиков просмотров страниц.
  • Располагается полностью в оперативной памяти веб-сервера.
• Кэш сайта доступен для каждого сервера, обрабатывающий запрос к конкретному сайту:
  • Большинство кэшируемых данных располагаются здесь.
  • Располагается в Redis.
  • Redis настолько быстр, что большую часть времени доступа к кэшу занимает передача данных по сети.
  • Данные сжимаются перед отправкой в Redis, так как большинство данных являются строками и у них есть масса свободных вычислительных ресурсов.
  • Использование процессорных ресурсов на серверах с Redis стремится к нулю.
• Глобальный кэш является общим для всех серверов и сайтов:
  • Личные сообщения, квоты по API и несколько других по-настоящему глобальных вещей располагаются здесь.
  • Также используется Redis.
• Большинство данных в кэше удаляются через заданный период времени (обычно в районе нескольких минут) и практически никогда явно не удаляются.
• Когда требуется инвалидация кэша на уровне готовых страниц, используется система подписки внутри Redis для отправки сообщений в соответствующую часть системы кэширования.
• Для системы ввода-вывода они выбрали Intel X25 SSD в RAID10. RAID решил многие вопросы с надежностью, а SSD показывают отличную производительностью по сравнению с FusionIO при существенно более низкой цене.
• Стоимость лицензий используемых продуктов Microsoft составила бы 242 тысячи долларов. Но так как они используют программу BizSpark, им не пришлось платить большую часть этой суммы.
• Сетевые карты от Broadcom заменяются на сетевые карты от Intel на основных production серверах. Это решило большинство проблем с потерями соединений, пакетов и таблицами ARP.

Источники информации

• Stack Overflow Architecture Update — Now At 95 Million Page Views A Month
• Stack Overflow Blog
• Stack Overflow’s New York Data Center
• Designing For Scalability of Management and Fault Tolerance
• Stack Overflow Search — Now 81% Less Crappy
• State of the Stack 2010 (a message from your CEO)
• Stack Overflow Network Configuration
• Does StackOverflow use caching and if so, how?
• How does StackOverflow handle cache invalidation?
• Which tools and technologies build the Stack Exchange Network?
• How does Stack Overflow handle spam?
• Our Storage Decision
• How are “Hot” Questions Selected?
• Stack Overflow and DVCS
• Server Fault Chat Room

Спасибо за внимание! Для оперативного получения свежей информации о высоконагруженных интернет-проектах рекомендую подписаться на RSS.

Буду рассказывать об общих подходах к построению крупных проектов с примерами из накопившейся у меня информации.

Среди запланированных моментов:

• Балансировка нагрузки
• Масштабирование: горизонтальное vs вертикальное
• Разбиение и целостность данных
• Репликация и резервное копирование
• Кэширование

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

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

Регистрация закрыта

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

Лекция будет проходить 29 марта, в 18:30 в Лабораторном корпусе МФТИ, как добраться, можно узнать здесь. Внутри здания: Актовый зал, второй этаж и прямо.

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

Цели сервиса

• Дать пользователям надежные счетчики в реальном времени по ряду метрик
• Предоставлять анонимные данных — нельзя узнать кто конкретно были эти люди
• Продемонстрировать ценность социальных плагинов и виджетов. Что они дают сайту или бизнесу?
• Концепция воронки: сколько людей увидело плагин, сколько совершило действие, сколько было привлечено пользователей обратно на интернет-ресурс
• Сделать данные более оперативными: сокращение частоты обновлений с 48 часов до 30 секунд

Задачи

• Множество типов метрик, более 100: показы, лайки, просмотры и клики в новостной ленте, демография и.т.д.
• Большой поток данных: 20 миллиардов событий в день
• Неравномерное распределение данных: за большинство контента практически не голосуют, но некоторые материалы набирают просто невероятное количество лайков

Неудавшиеся попытки

MySQL

• В каждой строке идентификатор и значение счетчика
• Привело к очень высокой активности в СУБД
• Статистика считается за каждые сутки, создание новых счетчиков в полночь приводило к большому скачку операций записи
• Пришлось пробовать искать способы решать проблему распределения счетчиков, пробовали учитывать временные зоны пользователей
• Пики операций записи неминуемо вели к блокировкам
• Решение оказалось не очень хорошо подходящим для данной конкретной задачи

Счетчики в памяти

• Казалось бы: если столкнулись с проблемами ввода-вывода — надо перенести все в память
• Никаких проблем с масштабируемостью — счетчики находятся в памяти, обновление практически мгновенно, легко распределить по серверам
• Но на практике оказалось, что при таком подходе теряется точность, видимо из-за неатомарности операций или других последствий столь прямолинейной реализации, подробностей нет
• Погрешность даже в 1% посчитали неприемлемой и от данного варианта отказались

MapReduce

• Предыдущий вариант реализации был создан с помощью Hadoop + Hive
• Подход гибкий, легко справляется с большим входящим потоком информации и объемами данным
• Основной минус: даже близко не в реальном времени, слишком комплексная система

Cassandra

• Вариант с Cassandra рассматривался, но так и не был реализован
• Причины были опубликованы достаточно сомнительные: высокие требования к доступности данных и производительности записи
• По всем данным у Cassandra нет абсолютно никаких проблем ни с одним, ни с другим

Победитель: HBase + Scribe + Ptail + Puma

В целом система, на которой остановился выбор, выглядит следующим образом:

• HBase хранит все данные на распределенном кластере
• Используется система логов, новые данные дописываются в конец
• Система обрабатывает события и записывает результат в хранилище
• Пользовательский интерфейс забирает данные из хранилища и отображает пользователям

Как обрабатывается один запрос:

• Пользователь жмет на кнопку Like
• Браузер инициирует AJAX запрос к серверу Facebook
• Запрос записывается в лог в HDFS с помощью Scribe
• Ptail — внутренний инструмент для чтения данных из нескольких Scribe-логов, на выходе данные разделяются на три потока, которые отправляются в разные кластеры в разных датацетрах:
  • Просмотры плагинов и виджетов
  • Просмотры в новостной ленте
  • Действия (плагины + новостная лента)
• Puma — механизм для пакетной записи данных в HBase для снижения влияния «горячих» материалов:
  • HBase может справиться с очень большим потоком операций записи, но популярные материалы могут заставить упереться во ввод-вывод даже её
  • В среднем пакет запросов собирается в течении 1.5 секунд, хотелось бы больше — но из-за огромного количества URL очень быстро заканчивается оперативная память
• Отображение данных пользователю:
  • Сам код для отображения написан на PHP
  • Работа с HBase осуществляется из Java
  • Для взаимодействия по традиции используется Thrift
• Система кэширования используется для ускорения отображения страниц:
  • Чем более старые данные запрашиваются, тем реже они пересчитываются
  • Многое зависит от типа запрашиваемой статистики
• MapReduce:
  • Данные передаются для дальнейшего анализа с помощью Hive
  • Сами логи удаляются через какой-то период времени
  • Помимо этого старая система анализа статистики все еще в действии, она используется для регулярных проверок результатов новой системы, а также в роли запасного плана, если что-то пойдет не так

О проекте

• Продолжительность 5 месяцев
• 2 с половиной разработчика самой системы
• 2 разработчика пользовательского интерфейса
• Всего было задействовано около 14 человек, включая менеджмент, дизайнера и системных администраторов

Направления развития

• Списки популярных материалов: при текущем подходе их составление является сложной задачей
• Отдельные пользовательские счетчики
• Обобщение приложения для использования с другими сервисами, а не только с социальными плагинами
• Распределение системы на несколько датацентров

Подводим итоги

У новых систем аналитики и сообщений много общего: большой поток входящих данных для записи, HBase и требование работы в реальном времени. Facebook делает ставку на HBase, Hadoop и HDFS, не смотря на громоздкость системы, когда другие предпочитают Cassandra из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным — покажет время.

Источники информации

• Facebook’s New Realtime Analytics System: HBase To Process 20 Billion Events Per Day
• Building Realtime Insights (видео)

Платформа

• Windows и openSUSE — основные операционные системы
• Java — основной язык программирования
• С/С++ — для некоторых модулей
• GWT — реализация динамического веб-интерфейса
• Apache Tomcat — сервера приложений
• JBoss 4 — сервера бизнес-логики
• LVS и IPVS — балансировка нагрузки
• MS SQL 2005 и 2008 — основная СУБД
• BerkleyDB — дополнительная СУБД
• Apache Lucene — индексация и поиск текстовой информации

Статистика

• До 2.8 млн. пользователей онлайн в часы пик
• 7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
• 2 400 серверов и систем хранения данных, из которых 150 являются веб-серверами
• Сетевой трафик в час пик: 32 Gb/s

Оборудование

Сервера используются двухпроцессорные с 4 ядрами, объемом памяти от 4 до 48 Гб. В зависимости от роли сервера данные хранятся либо в памяти, либо на дисках, либо на внешних системах хранения данных.

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

Сеть физически разделена на внутреннюю и внешнюю, разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети HTTP сервера, общаются с Интернетом, по внутренней сети все сервера общаются между собой. Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches), которые, в свою очередь, подключены как минимум двумя гигабитными линками к aggregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке. Для того, чтобы эта схема работала, используеться протокол RSTP. При необходимости, подключения access коммутаторов к agregation стеку осуществляются более чем двумя линками с использованием link aggregation портов. Aggregation коммутаторы подключены 10Гб линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром. Используются коммутаторы и маршрутизаторы от компании Cisco.

Для связи с внешним миром используются прямые подключения с несколькими крупнейшими операторами связи, общий сетевой трафик в часы пик доходит до 32Гбит/с.

Архитектура

Архитектура проекта имеет традиционную многоуровневую структуру:

• презентационный уровень;
• уровень бизнес-логики;
• уровень кэширования;
• уровень баз данных;
• уровень инфраструктуры (логирование, конфигурация и мониторинг).

Код проекта в целом написан на Java, но есть исключения в виде модулей для кэширования на C и C++.
Java был выбран так как он является удобным языком для разработки, доступно множество наработок в различных сферах, библиотек и opensource проектов.

Презентационный уровень

• Используем собственный фреймворк, позволяющий строить композицию страниц на языке Jаvа, с использованием собственные GUI фабрик (для оформления текста, списков, таблиц и портлетов).
• Страницы состоят из независимых блоков (обычно портлетов), что позволяет обновлять информацию на них частями с помощью AJAX запросов.
• При данном подходе одновременно обеспечивается минимум перезагрузок страниц для пользователей с включенным JavaScript, так и полная работоспособность сайта для пользователей, у которых он отключен.
• Google Web Toolkit используется для реальзации функциональные компонент, таких как Сообщения, Обсуждения и Оповещения, а также все динамических элементов (меню шорткатов, метки на фотографиях, сортировка фотографий, ротация подарков и.т.д.). В GWT используются UIBinder и HTMLPanel для создания интерфейсов.
• Кешируются все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируются и сжимаются (gzip).
• Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты.
• При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы.
• Никаких универсальных CSS селекторов. Стараются не использовать типовые селекторы (по имени тэга), что повышает скорость отрисовки страниц внутри браузера.
• Если необходимы CSS expressions, то пишутся «одноразовые». По возможности избегаются фильтры.
• Кешируется обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляется DOM дерево в «оффлайне».

Уровень бизнес-логики

На уровне бизнес логики располагаются около 25 типов серверов и компонентов, общающихся между собой через удаленные интерфейсы. Каждую секунду происходит около 3 миллионов удаленных запросов между этими модулями.
Сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, то есть любое событие или группу событий можно выделить и направить на обработку на определенную группу серверов. При общении серверов между собой используется свое решение, основанное на JBoss Remoting.

Уровень кэширования

Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кэшируются все данные, к которым происходит частое обращение, например: профили пользователей, списки участников сообществ, информация о самих сообществах, граф связей пользователей и групп, праздники, мета информация о фотографиях и многое другое.Для хранения больших объемов данных в памяти используется память Java off heap memory для снятия ненужной нагрузки с сборщика мусора. Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД. Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу данных по сети. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность.

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

Для примера, один сервер, кэширующий граф связей пользователей, в час пик может обработать около 16 600 запросов в секунду. Процессоры при этом заняты до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа — более 85 миллионов, связей 2.5 миллиарда. В памяти граф занимает 30 GB.

Уровень баз данных

Суммарный объем данных без резервирования составляет 160Тб. Используются два решения для хранения данных: MS SQL и BerkeleyDB. Данные хранятся в нескольких копиях, в зависимости от их типа от двух до четырех. Полное резервное копирование всех данных осуществляется раз в сутки, плюс каждые 15 минут делаются резервные копии новых данных. В результате максимально возможная потеря данных составляет 15 минут.

Сервера с MS SQL объединены в failover кластера, при выходе из строя одного из серверов, находящийся в режиме ожидания сервер берет на себя его функции. Общение с MS SQL происходит посредством JDBC драйверов.

Используются как вертикальное, так и горизонтальное разбиение данных, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — весь процесс реализован на уровне бизнес-логики. Распределенные транзакции не используются — всё только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на один сервер или, если это невозможно, дополнительно разработывается логика обеспечения целостности данных. В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов, что позволяет осуществлять JOIN как с данными из баз данных, так и с данными из кэша. При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения потребления вычислительных ресурсов на серверах баз данных.
SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция. Данные удаляются чаще всего через маркер: запись сначала отмечается как удаленная, а потом удаляется окончательно с помощью фонового процесса. Широко используются индексы, как обычные, так и кластерные. Последние для оптимизации наиболее высокочастотных запросов в таблицу.

Используется C реализация BerkleyDB версии 4.5. Для работы с BerkleydDB используется своя библиотека, позволяющая организовывать двухнодовые master-slave кластера с использованием родной BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные хранятся в tmpfs, transaction логи сохраняются на дисках. Резервная копия логов делается каждые 15 минут. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии одновременно. Помимо прочего, BerkleyDB используется и в роли очереди заданий.

Внутри системы используется взвешенный round robin, а также вертикальное и горизонтальное разбиение данных как на уровне СУБД, так и на уровне кэширования.

В разработке новое решение для хранения данных, так как необходим еще более быстрый и надежный доступ к данным.

Уровень инфраструктуры

Для агрегации статистики используется собственная библиотека, основанная на log4j. Сохраняется такая информация, как количество вызовов, среднее, максимальное и минимальное время выполнения, количество ошибок. Данные сохраняются во временные базы, но раз в минуту данные переносятся из них в общий склад данных (data warehouse), а временные базы очищаются. Сам склад реализован на базе решений от Microsoft: MS SQL 2008 и сиситема генерации отчетов Reporting Services. Он расположен на 13 серверах, находящихся в отдельной от production среде. Некоторые из них отвечают за статистику в реальном времени, а некоторые за ведение и предоставление доступа к архиву. Общий объем статистических данных составляет 13Тб. Планируется внедрение многомерного анализа статистики на основе OLAP.

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

Мониторинг логически разделен на две части:

• Мониторинг сервисов и компонентов
• Мониторинг ресурсов, оборудования и сети

Система мониторинга сервисов также самописная и основывается на оперативных данных с упомянутого выше склада. Мониторинг ресурсов и здоровья оборудования же онован на Zabbix, а статстистика по использованию ресурсов серверов и сети накапливаетя в Cacti. Для предпринятия мер по устранению чрезвычайных ситуаций работают дежурные, которые следят за всеми основными параметрами. Оповещения о наиболее критичных аномалиях приходят по смс, остальные оповещения отсылаются по емейлу.

Команда

Над проектом работают около 70 технических специалистов:

• 40 разработчиков;
• 20 системных администраторов и инженеров;
• 8 тестеров.

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

Разработка ведется итерациями в несколько недель. Как пример жизненного цикла разработки можно привести 3х недельный цикл:

1. определение архитектуры;
2. разработка, тестирование на компьютерах разработчиков;
3. тестирование на pre-production среде, релиз на production среду.

Практически весь новый функционал делается «отключаемым», типичный процесс запуска новой функциональной возможности:

• Функционал разрабатывается и попадает в production релиз;
• Через централизованную систему конфигурации функционал включается для небольшой части пользователей;
• Анализируется статистика активности пользователей, нагрузка на инфраструктуру;
• Если предыдущий этап прошел успешно, функционал включается постепенно для все большей аудитории;
• Если в процессе запуска собранная статистика выглядет неудовлетворительно, либо непозволительно вырастает нагрузка на инфраструктуру, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с начала.

Подводим итоги

• В отличии от остальных популярных социальных сетей в Одноклассниках используются технологии, рассчитанные в первую очередь на корпоративный рынок, начиная от обоих СУБД и заканчивая операционными системами.
• Во многом этот факт обсулавливает комплексный подход к генерации пользовательского интерфейса, не слишком высокую производительность и многие другие особенности этой социальной сети.
• Использование «тяжелых» технологий с самого начала оставило Одноклассники с большим количеством доставшегося по наследству от ранних версий устаревшего кода и купленных давно лицензий на проприетарный софт, которые выступают в роли оков, от которых довольно сложно избавиться.
• Возможно эти факторы и являются одними из основных препятствий на пути к завоеванию большей доли рынка и быстрому развитию платформы как в функциональном, так и техническом плане.

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

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

Dropbox — это самый простой способ…

• Хранить файлы в безопасном месте
• Делиться файлами с другими людьми
• Постоянно иметь к ним доступ вне зависимости от своего месторасположения

Взрывной рост

• 1 миллион файлов сохраняются в Dropbox каждые 15 минут (по презентации это больше, чем твитов в Twitter за тот же период времени, но это несколько преувеличено)
• Одно из самых скачиваемых приложений, уступает лишь Skype
• Важная часть жизни многих пользователей: «не могу жить без этого»
• Рост обеспечен «сарафанным радио», практически без рекламы

Команда в начале проекта

• Все хорошие друзья
• Самые умные, голодные и страстные, которых они знали
• Для каждого это была первая реальная работа, очень ограниченный опыт в данной индустрии
• Эти качества хорошо сочетаются с итеративной методологией разработки на Python

Ранние достижения

• Reverse engineering приложения Finder для Mac OSX 10.4/5 для отображения иконок статуса синхронизации («в процессе», «все готово»)
• Сложная инфраструктура HTTP нотификаций для избежания регулярного опроса серверов на каждом клиенте, основанная на Twisted
• Общая кодовая база, работающая на всех основных операционных системах: Windows, Mac OS, Linux (на основе PyObjC, wxPython, ctypes, py2exe, py2app, PyWin32)
• Горизонтально масштабируемое хранилище для информации о файлах на основе MySQL
• Собственная инфраструктура для аналитики в реальном времени
• Собственный механизм выделения памяти для Python, позволивший сократить её потребление на 90%

Сферы применения Python

По сути он используется во всех частях проекта:

• логика backend синхронизации;
• клиенты для основных ОС (Windows, Mac, Linux);
• контроллер основного сайта;
• обработка API запросов;
• аналитика.

Исключения из-за ограничений по доступной оперативной памяти:

• Android (мог бы быть Jython)
• iPhone (мог бы быть Cpython)

Почему именно Python?

• Легок в изучении и понимании:
  • новые люди легко втягиваются в процесс;
  • позволяет людям переключаться с проекта на проект.
• Легок в написании: важно для быстрой реализации функционала и выпуска новых версий.
• Легок в изменении:
  • нет необходимости в перекомпиляции;
  • высокая скорость итерации;
  • динамическая типизация:
    • рефакторинг очень прост;
    • уменьшение прямых зависимостей модулей;
    • динамические инструменты.
• Позволяет обеспечивать качество путем создания более-менее работающей версии продукта и доведения её до качественного уровня путем быстрых итераций.

Не без трудностей

Аргх!!! Python потребляет слишком много оперативной памяти и о-о-очень медленный!

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

Как с этим бороться?

• Убедитесь, что все длинные внутренние циклы выполняются в C (может сэкономить до 44% процессорного времени)
• С оптимизацией потребления вычислительных ресурсов все просто:
  • есть много готовых решений для профайлинга;
  • проблемный код чаще всего не раскидан по всей кодовой базе.
• С оптимизацией потребляемой памяти все сложнее:
  • нет готовых решений для профайлинга память (одновременно в Python и C);
  • много потенциальных причин для повышенного потребления памяти:
    • утечки в Python и C;
    • фрагментация памяти;
    • неэффективное её использование.
  • Как исправить? Однозначного решения нет — чаще всего приходится перерывать всю кодовую базу в поисках неоптимальных мест и источников утечек.
  • Почему память фрагментируется?
    • Большинство объектов расположены в heap памяти (большой последовательный кусок, выделенный приложению);
    • Много маленьких объектов вперемешку с большими;
    • Много временных объектов вперемешку с постоянными;
    • В CPython нет сборщика мусора, позволяющего собрать объекты компактно в одной части heap’а.
  • Решением проблемы с фрагментацией стал собственный аллокатор памяти (механизм её выделения под определенные типы объектов):
    • В Dropbox обнаружили, что большая часть heap-памяти захламляется контейнерами с метаданными файлов, которые синхронизируется;
    • Было решено вынести их куда-нибудь еще;
    • CPython позволяет управлять процессом выделения памяти для типов данных расширений;
    • Делается это с помощью простых структур на C;
    • «Not Rocket Science, just C code»;
    • Выделяются области памяти по 4Мб, состоящие из заголовка и буфферов фиксированной длины.
    • Что насчет внутренней фрагментации?
      • по идее же даже в одном буффере останутся данные, весь блок нельзя будет освободить…
      • потенциально этот факт может привести к еще большему расходу оперативной памяти;
      • но это оказывается не так, если учесть, что все объекты являются временными, то есть живут не долго!
      • в результате Dropbox редко использует более 100Мб памяти для больших синхронизаций (раньше эта цифра могла достигать 1.5Гб)
    • Но писать C расширение для каждой структуры данных, которую может понадобиться вынести в отдельный аллокатор — дело неблагодарное: в результате эта история закончилась изменением type_new() в Objects/typeobject.c для того, чтобы можно было указывать __use_region_allocator__ = True для тех классов, которым требуется такой механизм выделения памяти.

Подводим итоги

• Python стал ключом к технической реализации обоих сторон Dropbox: серверной и клиентской.
• Залогом успеха является максимальная простота с пользовательской точки зрения: «положил файл в папку и он становится доступен отовсюду»
• Dropbox не брали на себя реализацию стороннего функционала, вроде собственно создания хранилища файлов — используется Amazon S3, что позволило им запуститься очень быстро и стремительно.
• Лучше решать одну задачу, но качественно, чем много, но так себе!

Пользуясь случаем

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

Источники информации

• Видео
• Презентация

О проекте

Проект «Королевство» состоит из 2-х частей:

• непосредственно игра (сервер – C+Python, клиент – Flash)
• социальная сеть – веб-часть проекта, содержащая все полагающиеся атрибуты соцсетей в реалиях игры (nginx, Python, Twisted, XSLT, memcached, PostgreSQL)

Обязанности

• Полная самостоятельная поддержка и разработка всех проектов компании со стороны веба
• Оптимизация существующего кода для увеличения производительности и уменьшения нагрузок
• Разработка модулей для существующего проекта
• Доработка функционала, фикс багов
• Интергация проектов с российскими и зарубежными соцсетями

Требования к кандидату

• Уверенное знание Python
• Уверенное знание JavaScript
• Знание XSLT
• Умение разбираться в чужом коде
• Умение объективно оценивать собственные трудозатраты по той или иной задаче и укладываться в поставленные сроки
• Английский язык на уровне чтения технической документации
• Коммуникабельность, дисциплинированность и ответственность
• Приветствуется опыт работы над сложными/высоконагруженными web-проектами

Условия работы

• Полный рабочий день в офисе в Москве (пять минут пешком от метро Третьяковская)
• Работа над интересными, перспективными проектами
• Отличная команда единомышленников, каждый из которых является профессионалом в своей области
• Начало рабочего дня: с 10.00 до 12.00 (по желанию)
• Зарплата: 50-100 тыс. руб. в месяц

Куда писать?

Вопросы и резюме отправлять на da.public@skzk.ru.
К резюме приложите, пожалуйста, написанный Вами код на питоне.

P.S.: Если Вы не дотягиваете до требований, но в Сказку хочется — все равно пишите, еще есть вакансия джуниора.