Insight IT

Вакансии: разработчики облачной IaaS платформы в Крок

Иван Блинков — Thu, 19 Sep 2013 19:40:00 +0400

Вакансии более не актуальны

Ведущая российская ИТ-компания ищет талантливых, креативных и энергичных инженеров и разработчиков для развития коммерческой облачной платформы КРОК, предоставляющей услугу типа «Инфраструктура как сервис» (IaaS). В современном высокотехнологичном офисе Вас ждет дружная сплоченная команда профессионалов, занимающаяся разработкой передовой «облачной» платформы, у которой всегда найдется для Вас множество интересных, сложных и разнообразных задач, способных удовлетворить даже самые заоблачные амбиции!

Разработчик на платформе Linux

Обязанности

Проектирование архитектуры компонентов «облачного» решения;
Разработка и интеграция модулей облачной платформы;
Исследования в области распределенных высоконагруженных систем.

Требования

Опыт в области shell-программирования;
Уверенное знание Python, приветствуется знание С++ или Java;
Владение средствами разработки (autotools, git, svn и др.);
Опыт администрирования ОС Linux от 1 года (преимущественно RHEL, CentOS, Debian или SLES);
Опыт работы с технологиями виртуализации (Qemu/KVM, XEN, Hyper-V или VMware);
Знание «облачных» технологий особенно приветствуется.

Инженер по облачным решениям

Обязанности

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

Требования

Навыки администрирования современных ОС GNU/Linux и Windows;
Понимание принципов виртуализации вычислительных ресурсов;
Приветствуется опыт написания сценариев на языках shell и Python;
Личные качества: коммуникабельность, общительность, активная жизненная позиция.

Условия

Конкурентная заработная плата по результатам собеседования;
Возможность профессионального и карьерного роста;
Компания оплачивает обучение и сертификацию;
Социальный пакет (медицинская страховка, бесплатное питание в офисе, спортивные программы и компенсация фитнеса, английский язык);
Компания оказывает помощь при переезде в Москву (оплата стоимости проезда для прохождения собеседований, «подъемные» при выходе на работу).

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

Вакансии более не актуальны

Вакансия: Java-разработчик

Иван Блинков — Mon, 14 Jan 2013 12:53:00 +0400

Вакансия более не актуальна

В крупный тур-оператор Библио-Глобус нужен ответственный порядочный человек, умеющий работать в команде. Крупная компания, динамичный бизнес, постоянно меняющиеся задачи.

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

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

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

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

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

Зарплата - 150000 рублей в месяц
Полный рабочий день
Офис в Москве

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

Вакансия более не актуальна

Вакансии: развитие поведенческих технологий в рунете (СПб)

Иван Блинков — Mon, 04 Jun 2012 13:35:00 +0400

Вакансии более не актуальны

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

Если Вы способный IT-специалист из Санкт-Петербурга, всегда мечтали написать систему уровня Facebook или Twitter, на одном дыхании читаете статьи о Google Big Table и хотели бы участвовать в создании полезной системы, возможно, одна из этих вакансий будет Вам интересна:

Системный архитектор
Старший разработчик
Младший разработчик

Система RuTarget использует Real Time Bidding API - аукцион показов рекламы в режиме реального времени. За последние три года эта технология совершила революцию в рекламе на Западе. RuTarget - одни из первых, кто внедряет ее в России. Математический алгоритм принимает 170 миллионов решений о показах в день, за доли секунды распознает посетителя и подбирает полезные для него предложения, используя знания о предыдущих его действиях в сети.

Работа в компании RuTarget - это:

Работа над высоконагруженным рекламным проектом, способным выдерживать в штатном режиме 500 миллионов запросов в день с уровнем доступности 99.9%.
Новейшие технологии и компоненты: Apache Hadoop (+Pig, Hive и Mahout), Map-Reduce, Membase, Memcached, Redis.
Отсутствие legacy-кода и необходимости его поддержки.
Работа в режиме Scrum, TDD.
В коллективе только разработчики. У нас нет менеджеров, которые плохо понимают в программировании, но любят навязывать свое мнение.
Интересные технические и алгоритмические задачи для любого уровня квалификации.

От системного архитектора и старшего разработчика мы ожидаем:

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

Senior Developer / System Architect (Java)

Необходимые навыки:

Опыт программирования на Java в коммерческих проектах не менее 3-х лет
Глубокое понимание OOP, опыт многопоточного программирования
Опыт разработки высоконагруженных сервисов. Глубокое понимание принципов масштабирования и отказоустойчивости.
Знание английского языка на уровне, достаточном для чтения и ведения документации.
Опыт разработки на нескольких языках (желательно C/C++ или JavaScript).
Опыт администрирования Linux-систем.

Дополнительными преимуществами будут:

Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, машинного обучения, data mining.
Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.

Senior Software Developer / Data Mining (Java)

Необходимые навыки:

Опыт программирования на Java в коммерческих проектах не менее 3-х лет.
Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, статистики, машинного обучения, data mining.
Опыт работы с частью из следующих алгоритмов: K-Means Clustering, Principal Components Analysis, Decision Trees, Random Forests, Expectation Maximization, Support Vector Machines, Nonlinear Regression And Correlation.
Знакомство с пакетами математического и статистического анализа.
Знание английского языка на уровне, достаточном для чтения и ведения документации.

Дополнительными преимуществами будут:

Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.
Опыт создания клиент-серверных или распределенных приложений.
Опыт администрирования Linux-систем.

Junior Developer / Intern (Java)

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

От Вас ожидается:

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

Необходимые навыки:

Опыт программирования на Java не менее 1 года.
Понимание принципов OOP.
Знание английского языка на уровне, достаточном для чтения и ведения документации.
Опыт администрирования Linux-систем.

Дополнительными преимуществами будут:

Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, машинного обучения, data mining.
Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.
Опыт создания клиент-серверных или распределенных приложений.
Опыт разработки на нескольких языках (C/C++ или JavaScript).

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

Зарплата по результатам собеседования:
- System Architect от 90 тыс. рублей
- Senior Software Developer от 70 тыс. рублей
- Junior Developer от 30 тыс. рублей
Гибкий график работы.
Комфортные рабочие места, быстрые компьютеры, большие мониторы.
Бесплатные горячие обеды.
Круглосуточный доступ в офис.
Возможность удаленной работы из дома при необходимости.
Полная рабочая неделя в офисе в Санкт-Петербурге.

После собеседования Вас могут попросить выполнить тестовое задание.

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

Вакансии более не актуальны

Java-программист (вакансия закрыта)

Иван Блинков — Tue, 07 Jun 2011 18:33:00 +0400

Вакансия более не актуальна

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

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

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

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

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

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

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

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

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

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

Архитектура Одноклассников

Иван Блинков — Tue, 22 Mar 2011 00:17:00 +0300

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

Платформа

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х недельный цикл:

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

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

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

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

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

Архитектура Mollom

Иван Блинков — Tue, 15 Feb 2011 19:19:00 +0300

Mollom - это прибыльный SaaS сервис по фильтрации различных форм спама из контента, сгенерированного пользователями: комментариев, постов на форумах и блогах, опросов, контактных и регистрационных форм. Определение спама основано не только на контенте, но и репутации и прошлой активности разместившего его пользователя. Алгоритм машинного обучения Mollom выполняет роль цифрового модератора 24х7 для более 40 тысяч сайтов, в том числе и очень крупных компаний.

С того момента, как Mollom запустили систему анализа цифрового контента, они выявили более 373 миллионов спам сообщений, обнаружив в процессе что впечатляющие 90% всех прошедших через них сообщений оказались спамом. Весь этот поток спама в 100 сообщений в секунду обрабатывается всего двумя географически распределенными серверами. На каждом из них работает сервер Java-приложений и Cassandra. Так мало ресурсов требуется лишь из-за того, что они создали очень эффективную систему машинного обучения. Разве не круто? Так как же они это делают?

Статистика

Обслуживаются 40000 активных веб-сайтов, многие их которых принадлежат крупным клиентам, таким как Adobe, Sony BMG, Warner Brothers, Fox News и The Economist. Много крупных брендов, с крупными сайтами, масса комментариев.
Обнаруживают пол-миллиона спам-сообщений ежедневно.
Обрабатывается около 100 запросов к API в секунду.
Проверка сообщения на спам занимает очень мало времени, обычно около 30-50 миллисекунд, 95% запросов укладывается в 250 миллисекунд, когда самые медленные обрабатываются пол секунды.
Эффективность определения спама составляет 99.95%. Это означает, что из 10000 спам-сообщений Mollom пропустит только 5.
Netlog, европейская социальная сеть, имеет отдельный Mollom-сервер в своем датацентре. Netlog проверяют на спам около 4 миллионов сообщений каждый день на классификаторах, специально натренированных на их данных.

Платформа

Java - исторически сложилось, что Mollom был с самого начала был разработан на Java.
Два сервера обслуживают основную часть клиентов:
- Один сервер на восточном побережье США, другой - на западном
- В случае сбоя один сервер может полностью подменить другой
- Конфигурация обоих: Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 диска по 300 GB, RAID 10.
SoftLayer - хостинг-провайдер.
Cassandra - NoSQL база данных, выбранная из-за высокой производительности на запись и способности работать на серверах, располагающихся в разных датацентрах (была разработана в Facebook, но там практически не используется).
MySQL - Java Persistence API используется для обычных наборов данных, когда Cassandra используется для больших объемов данных.
Glassfish - open source сервер приложений для платформы Java EE. Они выбрали именно Glassfish за его возможности корпоративного уровня, такие как репликация и обработка сбоев.
Hudson - предоставляет непрерывное тестирование и развертывание кода серверной части на всех используемых машинах.
Munin - измерение и построение графиков, касающихся здоровья серверов.
Pingdom - внешний мониторинг.
Zendesk - используется для оказания поддержки клиентам.
Drupal - используется для основного сайта со специализированным модулем интернет-магазина.
Unfuddle - хостинг Subversion для взаимодействия удаленной команды разработчиков.

Как это работает?

Процесс выглядит следующим образом:

Когда пользователь отправляет комментарий на сайт, происходит запрос к API Mollom.
Контент анализируется, если он оказывается спамом, то сайту сообщается, что необходимо его заблокировать, если же алгоритм не уверен на 100% - сайту советуют показать CAPTCHA, которую сервис также предоставляет.
После того, как CAPTCHA будет успешно заполнена, контент принимается. В большинстве случаев пользователи не будут ее видеть и контент будет приниматься сразу же.

Обнаружение спама является сложным балансом между отказом нормальному контенту и принятию спама.

Бизнес-модель

Основным залогом популярности Mollom является бесплатная возможность попробовать сервис, ограничение составляет 100 нормальных (не спам) сообщений в день. Небольшие сайты могут никогда и не достичь этого ограничения.
Далее есть два тарифа: 1 евро в день и 3600 евро с возможностями вполне соответствующими этим суммам
Сайты, использующие бесплатный тариф, вовсе не зря тратят ресурсы системы, как кажется на первый взгляд, а являются жизненно-важным источником данных для тренировки системы. Без этих данных алгоритмы были бы существенно менее точны.

Архитектура

Разработчики Mollom уделяют максимум внимания времени отклика, эффективности кода и использования серверных ресурсов.
Физически каждый сервер может справиться со всеми запросами, два сервера нужны для избежания перерывов в работе системы. Когда оба сервера в строю - работа распределяется между ними, когда один падает - второй перехватывает его запросы.
Mollom прошел через несколько этапов развития:
1. Изначально маленькая команда из двух человек работала вечерами над основными алгоритмами, классификаторами и реальными бизнес-задачами, которые они пытались решить. Для построения инфраструктуры серверной части они использовали свои реализации базовых механизмов по управлению ресурсами, соединениями и потоками. В итоге они обнаружили, что тратят слишком много времени на эти вещи. После этого они переключились на Glassfish, что позволило им намного меньше беспокоится об управлении памятью, REST-запросах, парсинге XML и поддержании пула соединений с базой данных.
2. В прошлом основной проблемой была пропускная способность дисковой подсистемы. Они должны хранить информацию о репутации всех IP-адресов и URL по всему Интернету, что привело к массивному набору данных с большим количеством случайных обращений.
3. Поначалу они использовали MySQL на недорогой виртуальной машине, что в итоге не смогло масштабироваться.
4. Они перенесли данные на твердотельные жесткие диски (SSD) и стали все хранить в файлах. Этот шаг решил проблемы с записью, но возникли новые проблемы:
  1. Это правда дорого.
  2. Очень чувствительно к типу используемой файловой системы
  3. Запись стала происходить быстрой, но итерация по большим наборам данным (что они делали довольно часто для очистки данных и обучения классификаторов) по-прежнему была очень медленным процессом.
5. В итоге они отказались от твердотельных накопителей и стали использовать Cassandra.
Cassandra сейчас используется для обработки интенсивного потока запросов на запись и в роли кэша:
- Работает на RAID10, что хорошо подходит для высоких смешанных нагрузок на запись/чтение.
- Cassandra оптимизирована для записи, а в Mollom запись как раз происходит намного чаще, чем чтение.
- Разработана для распределенной работы как внутри датацентра, так и между датацентрами.
- Обратной стороной медали является отсутствие стандартного NoSQL интерфейса, что усложняет реализацию приложений.
- Механизм кэширования строк в Cassandra позволяет им не использовать отдельную систему для кэширования, что существенно упростило код приложения.
- Cassandra имеет функцию удаления устаревшей информации после определенного периода времени. В Европе существуют строгие законы о приватности личных данных, согласно которым они должны храниться не более определенного срока (штаб-квартира Mollom находится в Бельгии). В этом плане эта функция очень удобна. Эта функция опять же избавляет от необходимости реализовывать данный функционал вручную.
Типичный путь одного комментария внутри системы:
- Балансировка нагрузки между серверами лежит на клиентской библиотеке, в роли типичного клиента может выступать сайт на Drupal, осуществляющий запрос к API через XML-RPC или REST.
- Запросы обрабатываются сервером приложений Glassfish и проходят стандартный процесс обработки с помощью сервлетов и специфичных классов.
- Платящие клиенты обслуживаются в первую очередь, что приводит к тому, что клиенты на бесплатном тарифе могут ожидать результата несколько дольше.
- Запрос анализируется и оценка вероятности спама возвращается пользователю. Помимо этого отдельная часть кода Mollom отвечает за генерацию, выдачу и проверку CAPTCHA.
- Классификаторы полностью располагаются в оперативной памяти. Небольшой кусок контента разбивается на тысячи и тысячи крошечных частей, которые могут быть идентифицированы как спам. Такие классификаторы хранят в памяти до нескольких миллионов признаков, характерных для спама. Анализ должен выполняться очень быстро, так что никаких других вариантов кроме расположения всех требуемых данных в оперативной памяти просто не было.
- В Cassandra хранятся очки репутации, частоты, URL и IP-адреса.
- Струтуры данных в памяти не реплицируются напрямую. Они записываются в Cassandra, которая и передает их на второй сервер. Промежуток времени, когда данные не консистентны, очень невелик, так что это не сказывается негативно на алгоритмах.
Балансировка нагрузки с помощью клиента:
- Mollom использует такой подход к балансировке, так как стартап не может себе позволить дорогой железный балансировщик нагрузки. Если учесть, что им нужна балансировка между датацентрами, решение от любого из вендоров было бы комплексным и дорогим.
- У каждого клиента есть индивидуальный список серверов, которыми он может воспользоваться. Этот список изменяется через API.
- Каждый клиент может использовать разный список, платящим клиентам могут предоставлять отдельные сервера для уменьшения задержек.
- Если сервер упал - клиент пытается подключиться к следующему серверу в списке.
- С другой стороны такой подход усложняет разработку неофициальных клиентов: авторам проекта приходится тесно работать с разработчиками сторонних клиентов для обеспечения правильной реализации в них балансировки нагрузки.
Машинное обучение:
- Mollom - это набор самообучающихся систем. Отдельные CAPTCHA-решения, не учитывают ни пользовательское поведение, ни источник контента, заставляя каждого пользователя вводить проверочный код при каждом сообщении. В случае с Mollom это происходит только когда система анализа контента не уверена в конкретном решении.
- Средняя длина сообщения - 500 символов, обычно оно разбивается на 3000 характеристик. Принадлежность контента к спаму определяется путем оценки репутации IP адреса или Open ID, пользовательского идентификатора, эмоциональной окраски, языка, профанации, проверки на наличие специфичных слов и фраз, также учитывается качество написания текста и многие другие факторы. Все эти данные основываются на классификаторах. Некоторые из них статистические по природе, так что обучение происходит автоматически. Другие же основываются на правилах для того, чтобы быть уверенными, что они никогда не могут быть настроены неверно. Комбинация результатов всех тестов после нормализации и образует финальный рейтинг принадлежности к спаму каждого конкретного сообщения.
- Классификаторы и внутренние метрики обучаются с каждым новым сообщением и обновляются в реальном времени.
Glassfish берет на себя планировку нагрузки, учитывая многоядерность системы:
- Ключ к дизайну системы в многопроцессорном окружении заключается в максимальном параллелизации работы при минимальном простое из-за блокировок.
- Они используют 16 thread'ов на сервер.
- Большинство запросов обрабатываются сессионными объектами (Java Bean), не имеющими состояний. Они хорошо подходят для управления параллельными запросами.
- Они держат пул из нескольких сессионных объектов, но определение их количества делегируется Glassfish. В пиковую нагрузку это число увеличивается для более эффективной обработки запросов, порой оно достигает 32.
- Все классификаторы реализованы как раз как такие объекты, повторно использующиеся различными thread'ами.
- У каждого объекта есть свое клиентское соединение с Cassandra, чтобы гарантировать отсутствие блокировок.
- Когда пользователь не отвечает на CAPTCHA сессия очищается и Mollom узнает что это скорее всего был спам.
- На каждом сервере запущено по одной копии каждого классификатора.
- В момент очистки сессии происходит небольшая блокировка, когда происходит обновление классификаторов.
- Обновленные классификаторы записываются в Cassandra каждые пол часа.
Интеграция приложений:
- Mollom использует открытый API, который может быть интегрирован в любую систему.
- Библиотеки: Java, PHP, Ruby и другие.
- Готовые модули: Drupal, Joomla, Wordpress и прочие системы управления контентом.
- Решения от сторонних разработчиков, основанные на примерах кода от Mollom.
Для мониторинга здоровья серверов они используют Munin:
- Каков размер heap памяти после сбора мусора?
- Каково количество доступных соединений?
- Каково количество thread'ов в пуле?
- Оценка времени блокировок в каждом thread'е.
Если взглянуть в целом на архитектуру Mollom, можно увидеть, что они стараются построить систему, способную прозрачно работать в нескольких датацентрах, чтобы позволить горизонтально расширить систему, когда они перерастут текущую двухсерверную конфигурацию:
- Балансировка нагрузки на клиенте позволяет выбирать оптимальный сервер и справляться со сбоями одного из них.
- Кластеризация Glassfish облегчает добавление/удаление новых машин и позволяет перехватывать запросы, когда один из серверов выходит из строя.
- Cassandra используется для управления данными между серверами в нескольких датацентрах.
Инсталляция Mollom в Netlog обладает некоторыми интересными характеристиками. Она обрабатывает больше сообщений, чем основные сервера Mollom, но распределение спама в ней совершенно другое, так как люди в ней общаются в рамках социальной сети. Внутри Netlog лишь 10% сообщений является спамом, когда в суровом мире информационных порталов распределение обратно. Интересным следствием является тот факт, что обработка нормальных сообщений требует меньше вычислительных ресурсов, так что на аналогичном оборудовании удается обрабатывать больший поток сообщений.
Изначально они думали о виртуализированных серверах, в частности об Amazon EC2, но в итоге обнаружилось, что наиболее узким местом являются операции ввода-вывода - низкая производительность дисковой подсистемы в виртуальных машинах создавали реальные проблемы, так что они решили воспользоваться вертикальным масштабированием и переехали на более дорогие физические машины с большим объемом дискового пространства:
- На удивление они не упираются в вычислительные ресурсы: лишь два ядра из 8 занимаются вычислениями, когда остальные же работают над операциями ввода-вывода.
- Трафик Mollom практически постоянен, так что физические сервера более эффективны с финансовой точки зрения. Они рассматривают Amazon лишь как запасной вариант для обработки непредвиденных пиков нагрузки.
Процесс разработки:
- Команда распределена: трое в Бельгии, остальные в Техасе, Бостоне и Германии.
- Scrum используется в процессе разработки и они довольны этой методологией. Scrum-собрание проходит через Skype в два часа дня по Бельгии.
- Разработчики работают локально и отправляют код на Unfuddle.
- Hudson используется для непрерывного интеграционного тестирования. Hudson позволил облегчить миграцию, так как перед развертыванием все тесты должны быть пройдены. Они не теряли лишнего времени на проблемах, обнаруженных уже в развернутом приложении.
- Они активно используют автоматическое тестирование: юнит-тесты, системные тесты, тесты Drupal.
- Развертывание по-прежнему делается вручную для минимизации риска простоя (что правда спорный момент).
- Для обнаружения утечек памяти они используют анализ дампов оперативной памяти. Анализ дампа сервера с 16Гб памяти - дело непростое, практически невозможное на обычном компьютере, так что они арендуют большую виртуальную машину на Amazon для проведения анализа. Весь процесс занимает всего около 2 часов. Они сравнивают два дампа: через 10 и 20 часов после запуска сервера. Если обнаруживаются значительные отличия, то скорее всего дело в утечке памяти.

Пути развития

Mollom API основано на XML-RPC, REST-интерфейс находится на стадии тестирования для облегчения интеграции других сервисов.
Они мигрировали на Cassandra, чтобы облегчить процесс горизонтального масштабирования, когда нагрузка достигнет соответствующего уровня.
Скоро будут выпущены корпоративные возможности, которые позволят работать с сотнями сайтов как с единым целым. Появится возможность легко модерировать несколько сайтов одновременно по эмоциональной окраске сообщений, рейтингу спама или удалить все сообщения с определенного IP-адреса.
Они думали над участием в бизнесе потоковых данных вроде Twitter, но они сильно ограничены европейскими более строгими требованиями по приватности.
Планируются эксперименты по использованию Glassfish для балансировки нагрузки в рамках каждого датацентра.
Если нагрузка увеличится десятикратно им придется добавить больше серверов в Cassandra. Дисковый ввод-вывод является узким местом. Дополнительные сервера приложения понадобятся только если нагрузка вырастет более, чем на порядок.

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

Mollom очень серьезно относится к разработке высокопроизводительной системы. Они гордятся тем, что Mollom очень эффективно использует вычислительные и финансовые ресурсы. Множество запросов может обрабатываться одним сервером с низкой задержкой, что очень радует как клиентов, так и владельцев проекта, так как издержки очень низки. Этот вопрос был выбран приоритетным с самого начала и они выбрали подходящие технологии для реализации своих целей. Это позволило им вкладывать средства в маркетинг, построить базу клиентов и создавать новые продукты на основе Mollom.
Машинное обучение требует много исходных данных для успешного обнаружение спама. Для сбора этих данных предлагает бесплатные услуги. Крупные клиенты обеспечивают доход и получают выгоду от данных, полученных от более мелких клиентов. Эта модель очень хорошо себя проявила в машинном обучении, за которым как известно будущее.
Старайтесь избавиться от проблем, не связанных напрямую с продуктом. Большие системы требуют серьезных усилий на разработку инфраструктуры. Можно убить все время на построение инфраструктуры, вместо создания по-настоящему ценного продукта (классификаторов, системы репутации, клиентских библиотек). Mollom постоянно пытались максимально избавляться от лишних проблем, именно по-этому они выбрали Cassandra и Glassfish.
Будьте осторожны с клиентским кодом. Выполнение кода на клиентской части привлекательно тем, что он тратит чужие ресурсы, а не серверные. Проблемы начинаются когда сторонние библиотеки разрабатываются некачественно, что заставляет систему в целом работать плохо. Плотно работайте с разработчиками клиентских библиотек для повышения качества их продукции.
Отдавайте приоритет платящим клиентам. Платящие клиенты получают более высокое качество услуг, обрабатываются вне очереди, получают меньше задержек и получают доступ к запасному серверу когда основной дал сбой. Этого вполне достаточно, чтобы подтолкнуть клиентов платить.
Уменьшайте объем кода, позволяя используемым сторонним продуктам брать на себя грязную работу. Поначалу код Mollom был существенно большим по объему, чем сейчас. Использование Cassandra и Glassfish позволило убрать массу кода, связанного с кэшированием, кластеризацией, репликацией и обработкой сбоев. Упрощайте систему со временем.
Минимизируйте блокировки. Mollom потратили много времени на устранение блокировок внутри Glassfish, так как это начинало становиться узким местом. Минимизируйте простой от блокировок для достижения полного параллелизма.

Источники информации и дополнительные материалы

Mollom Architecture - Killing Over 373 Million Spams At 100 Request Per Second (основной источник информации)
Mollom Technical Whitepaper
Episode #072 - Mollom.com's GlassFish backend with Dries and Johan
Mollom gets a new backend
Fighting spam with Mollom on Glassfish
Mollom API

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

Архитектура LinkedIn

Иван Блинков — Thu, 11 Sep 2008 04:00:00 +0400

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

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

22 миллиона пользователей;
4+ миллиона уникальных посетителей в день;
40 миллионов просмотров страниц в день;
2 миллиона поисковых запросов в день;
ежедневно отправляются 250 тысяч приглашений;
1 миллион ответов в день;
2 миллиона электронных сообщений ежедневно.

Платформа

Solaris (как x86, так и SPARC)
Tomcat и Jetty
Oracle и MySQL
Никакого ORM
ActiveMQ для JMS
Lucene в качестве основы для поиска
Spring в роли "клея"

Серверная архитектура

2003-2005

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

2006

Добавлена репликация для уменьшения нагрузки на основную базу данных. Реплики предоставляют данные в режиме "только для чтения", а репликация ведется в асинхронном режиме с помощью дополнительного компонента под названием Databus, с его появлением обновление данных стало выглядеть следующим образом:
- сначала какие-либо изменения происходят в веб-приложении;
- веб-приложение обновляет основную базу данных;
- она, в свою очередь, отправляет обновления на Databus;
- далее уже Databus обновляет: реплики, Облако и поисковый индекс.
Поиск был вынесен на отдельный сервер.

2008

веб-приложение само по себе практически ничего не делает: бизнес логика распределена по отдельным сервисам;
веб-приложение все так же предоставляет пользователям графический интерфейс, но для его генерации она теперь вызывает сервисы;
каждый сервис имеет свою специфическую базу данных (т.е. вертикальное сегментирование);
такой подход позволяет другим приложениям (помимо основного) получать доступ к LinkedIn, такие приложения были созданы для работодателей, рекламных служб, и так далее.

Облако

"Облаком" в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
его размеры: 22 миллиона вершин и 120 миллионов ребер;
занимает 12GB оперативной памяти;
одновременно держится в памяти в 40 экземплярах;
построение Облака из данных, в дисковой системе, занимает 8 часов;
обновления происходят в режиме реального времени с помощью Databus;
во время остановки данные записываются на диск;
кэш реализован с помощью C++, а доступ предоставляется по JNI;
они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части - не самая тривиальная задача.

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

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

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

Сервис постоянных сообщений

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

вся система работает асинхронно и активно использует JMS;
клиенты отправляют сообщения так же через JMS;
далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

Функциональное сегментирование: отправленные, полученные, архивные сообщения. (т.е. вертикальное сегментирование)
Классовое сегментирование: пользовательские, гостевые, корпоративные почтовые ящики.
Сегментирование по диапазонам: по идентификаторам пользователей или по лексикографическим диапазонам самих сообщений. (т.е. горизонтальное сегментирование)
Асинхронное выполнение операций.

Сервис сетевых обновлений

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

Изначальная архитектура (до 2007 года)

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

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

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

Вторая итерация

стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский "почтовый ящик", в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом "ящике";
такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);
сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
вместо CLOB'ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

Цель: повысить производительность путем сокращения количества обновлений CLOB'ов, так как они требуют много вычислительных ресурсов.
Был добавлен буфер: колонки в таблицах типа varchar(4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

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

P.S.

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

Кстати если Вы еще не успели подписаться на RSS - сейчас самое время!

Архитектура Mailinator

Иван Блинков — Tue, 24 Jun 2008 18:17:00 +0400

Ваш пьяный друг когда-либо вдохновлял Вас на создание первого в своем роде интернет-сервиса, который пришелся бы по вкусу миллионам пользователей и при этом неприхотливо обрабатывал миллиарды электронных писем ежегодно? Именно так Paul Tyma и создал Mailinator.

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

Как же Mailinator справляется со своей ролью анти-спам супергероя?

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

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

Платформа

Статистика

Сервис обработал: 1.29 миллиардов электронных писем за 2007 год. 450.74 миллионов за 2006. 280.68 миллионов за 2005.
В период пиковых нагрузок обрабатывается 6.5 миллионов электронных писем в сутки или 4513 сообщений в минуту или 75 в секунду.
Mailinator работает на всего одном весьма средненьком компьютере с AMD Athlon 2GHz процессором, 1 GB оперативной памяти (которая используется не целиком) и низкопроизводительным IDE жестким диском объемом 80 GB. И она в общем-то загружена далеко не полностью.
Mailinator работает месяцами без присмотра и теряется очень небольшое количество сообщений, даже при постоянных спам-атаках и высоких пиковых нагрузках.

Архитектура

Так как система бесплатна, она не должна быть идеальной. Таким образом основные цели:
- Создание системы, которая ценит выживание превыше всего, даже пользователей. Основным ключом является именно выживание, так как Mailinator вынужден ежедневно отражать спам-атаки.
- Предоставить пользователям 99,99% доступность и точность данных. Более высокие гарантии будут существенно менее практичными и приведут к большим затратам. И так как сервис бесплатен, этот небольшой риск для пользователей становится просто частью правил игры.
- Поддержка следующей модели сервиса: пользователь регистрируется где-то, заходит в Mailinator, жмет на пришедшую ссылку и забывает об этом. Это означает, что письма не должны храниться постоянно. Они могут размещаться в оперативной памяти, так как являются временными (живут три-четыре часа). Если Вам нужен обычный настоящий почтовый ящик - воспользуйтесь любым другим соответствующим сервисом.
Изначально письма обрабатывались следующим образом:
- Sendmail получал письмо в общий ящик на диске.
- Java-приложение доставало сообщение используя IMAP и/или POP (с течением времени это менялось) и удаляло их.
- Система загружала все письма в память и оставляла их там.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Данный принцип работал вполне неплохо:
- Он стабилен и работал месяцами без каких-либо проблем.
- Использовался практически весь гигабайт оперативной памяти.
- Проблемы начались, когда количество сообщений в сутки начало превышать 800000. Система начала давать сбои из-за использования жесткого диска между Mailinator и email подсистемой.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Новая архитектура:
- Идея заключалась в отказе от временного хранения данных на жестком диске путем полного переписывания всей системы с нуля.
- Веб-приложение, почтовый сервер и все хранилище писем функционируют в рамках одной JVM.
- Sendmail был заменен на специально написанный для этого проекта SMTP сервер. Так как природа Mailinator не требовала полноценного SMTP сервера. Mailinator не отправляет писем, основная цель - принимать или отвергать входящие письма. Это является недостатком многоуровневой архитектуры. Она часто является залогом успеха в процессе масштабирования веб-приложения, но порой она может и наоборот полностью убить всю производительность благодаря неверному принятию ответственных решений. Решение о создании собственного SMTP сервера было достаточно интересным и смелым, многие другие руководители проектов вместо этого просто добавили бы дополнительное оборудование в систему. Это не было бы ошибкой, но, согласитесь, создание своего собственного решения задачи - намного более интересный подход.
- Сейчас Mailinator получает почту напрямую, обрабатывает ее и хранит в оперативной памяти. Жесткие диски полностью обходятся и практически не используются.
- Основное их применение - хранение сообщений в случае остановки сервиса для того, чтобы они могли быть восстановлены при запуске.
- Ведение логов было отключено.
- Система использует менее 300 потоков. Это оказалось вполне достаточно.
- При принятии сообщения, система пропускает его через набор фильтров и хранит его в памяти только в том случае, если все фильтры были успешно пройдены.
- Каждый почтовый адрес ограничен только 10 письмами, так что популярные адреса вроде joe@mailinator.com не могут "взорвать" систему.
- Письма не могут превышать 100 kb, а все приложения автоматически уничтожаются. Это позволяет существенно сэкономить в плане используемой оперативной памяти..
Электронные письма сжимаются в оперативной памяти:
- 99% писем никто даже не открывает, компрессия позволяет сэкономить место в оперативной памяти. Письмо разжимается в исходное состояние только если кто-то решает его открыть.
- Mailinator может хранить около 80000 писем в оперативной памяти, используя лишь 300 MB памяти, по сравнению с 20000 писем, занимающих 1 GB без использования компрессии.
- С таким подходом к хранению писем, они живут в среднем 3-4 часа.
- В память поместится и 200000 писем, но на практике это и не требуется.
- Оперативная память ценна, а процессорное время - вовсе нет. Именно из-за этого используется компрессия для экономии памяти и использования излишков вычислительных мощностей.
Mailinator не гарантирует анонимность или приватность:
- Любой пользователь может получить доступ к любому почтовому ящику.
- Отказ от ограничений доступа делает схему работы системы намного более простой.
- Со стороны пользователя такой подход очень прост, так как не требуется абсолютно никакой регистрации. Когда сайт требует ввести почтовый адрес достаточно лишь просто ввести любой адрес Mailinator. Вам не нужно создавать отдельный аккаунт. Банальный ввод адреса создает почтовый ящик. Все просто.
- На практике же, не смотря на вышесказанное, пользователи все же получают изрядную степень приватности.
Стремление к выживанию требует агрессивной борьбы со спамом:
- Mailinator не имеет ничего против спама, но так как спама приходит нереально много, когда он подвергает риску работоспособность сервиса приходится его фильтровать.
- Этот факт привел к правилу: если Вы делаете что-то (получаете спам или что-то еще), что мешает работе системы - Ваши письма не будут приниматься и Вы можете быть временно заблокированы.
Для успешного приема письмо должно пройти следующую цепочку фильтров:
- Все письма, которые не смогли быть доставлены, отклоняются.
- При слишком большом количестве писем с одного IP они перестают приниматься.
- Слишком много писем с одинаковой темой не принимаются.
- Письма, содержащие в заголовках запрещенные сервисом слова, также не попадают в почтовые ящики.
Выживание в условиях наплыва писем с одного IP адреса:
- Для этого типа фильтрации используется AgingHashMap. Когда сервис получает очередное письмо, IP помещается в массив и счетчик, соответствующий этому ключу, увеличивается на единицу в момент получения каждого последующего письма с этого IP.
- Спустя определенное время без получения писем с IP, соответствующие ему счетчик обнуляется.
- Когда счетчик достигает определенного порога, IP блокируется, предотвращая поток сообщений.
- Этим простым методом пользуются многие интернет-ресурсы для защиты различных своих компонентов, например комментариев. В роли хранилища для такого массива при распределенном функционировании системы часто используют memcached.
Защита от "зомби" атак:
- Спам может приходить и с больших координированных сетей с разными IP адресами, как раз участников таких сетей и называют "зомби". Одинаковые письма приходят со множества разных адресов, так что защита по IP адресам становится бессильна.
- Этот фильтр несколько более сложный, чем блокировка по IP, так как требуется достать из письма строку с заголовком, да и их сравнение - несколько ресурсоемкая задача.
- Когда около 20 писем с одинаковыми темами приходят в течении 2 минут, этот заголовок блокируется на час.
- Что интересно, Mailinator не хранит заблокированные темы вечно, так как это значило бы, что этот список неуклонно рос и приходилось бы вечно отслеживать соответствия с ним. Это никак не приемлемо для мимолетной природы Mailinator. Более комплексные алгоритмы защиты от спама нужны лишь только если ставятся цели с более жесткой борьбой со спама, для Mailinator же данный вариант - наиболее эффективный.
- Этим фильтром блокируется около 9% писем.
- Mailinator фильтрует сообщения только по теме и IP, так что системе не приходится прочитывать и анализировать все письмо целиком. Это позволяет неплохо сэкономить на вычислительных ресурсах при достаточно эффективной итоговой фильтрации.
Для уменьшения угрозы DDoS атак:
- Все соединения, неактивные какое-то время обрываются.
- Mailinator отвечает отправителям писем очень медленно, 10, 20 или даже 30 секунд, даже для небольших объемов данных. Это замедляет работу спаммеров, пытающихся отправлять спам как можно быстрее, и заставляет их лишний раз задуматься о целесообразности отправки снова спама на этот адрес. Период ожидания уменьшается во время повышенных нагрузок на сервис, так что письма не теряются из-за этого.

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

Идеальность - всего лишь ловушка. Как много систем были кардинально усложнены лишь для того, чтобы достичь 100%-го результата во всех аспектах. Если Вы участвовали в подобных совещаниях, Вы понимаете о чем идет речь. О нет, мы не можем сделать этого, так как есть 0,01% шанс, что что-то пойдет не так. Лучше спросите себя: насколько неидеальными можно позволить себе быть, чтобы все равно оставаться достаточно неплохим сервисом?
То, что Вы отвергаете, ничуть не менее важно, чем то, что Вы оставляете в системе. Существует масса концепций по построению архитектуры системы. Нужно не только выбрать подходящие, но и отказаться от тех, которые излишни.
Знайте предназначение своей системы и разрабатывайте ее в соответствии с этим. Быть всем для всех значит быть ничем для никого. Временное хранение электронных писем, позволяя небольшой части спама пробиться через фильтры, в совокупности с не 100% временем работы системы производят достаточно хорошее впечатление на пользователей. Построение собственного SMTP-сервера необходимо лишь в случае, если у Вас есть весомые аргументы в пользу того, что он Вам необходим. Далеко не факт, что такая идея придет в голову, возможно выбор пал бы и на более тривиальное решение, связанное просто с добавлением дополнительного оборудования.
Постарайтесь как можно быстрее свести механизм работы системы к наиболее общему случаю. Очень большой процент писем отвергается, так что это оправданно сделать это как можно раньше, чтобы минимизировать ресурсы, требуемые для их обработки. Найдите способ сделать это как можно быстрее в отношении наиболее частых случаев. то очень часто становится важным компонентом стратегии масштабирования.
Эффективность часто означает "постройте это самостоятельно". Готовые решения обычно решают большой спектр задач, но на практике часто нужна лишь небольшая часть функционала, в таких случаях можно написать небольшой компонент с нуля самостоятельно, чтобы он мог выполнять только нужные функции, но более эффективно.
Небольшое количество сбоев - вполне допустимо. Все заблокированные адреса не должны быть запомнены навечно. Позвольте этим спискам генерироваться на основе локальных данных, а не глобального состояния. Это очень простая и эффективная архитектура.
Java совсем не обязательно должна быть медленной. На эту тему сказано уже достаточно.
Избегайте работы с жесткими дисками. Многие приложения требуют работы с дисковой системой, но очень часто именно она оказывается узким местом в системе. Можете ли Вы обойтись без него, используя более креативные подходы к архитектуре системы?
Ограничте использование ресурсов. Задайте рамки для размеров почтовых ящиков и других подобных элементов системы, это позволит избежать неконтролируемых скачков нагрузок. Неограниченное использование ресурсов недопустимо при ограниченности ресурсов.
Сжимайте данные. Компрессия данных может стать неплохим достижением в попытках сэкономить оперативную память. Можно сократить использование памяти вдвое с лишь небольшой дополнительной нагрузкой, связанной с компрессией и декомпрессией информации. Если обмен данными происходит локально, достаточно лишь закодировать данные и предоставить API для доступа к данным без полной декомпрессии.
Используйте фиксированные объемы ресурсов для обработки запросов. Многие приложения не могут контролировать используемые ресурсы, в частности - оперативную память, таким образом они могут порой давать сбой при использовании излишне больших ее объемов. Для более стабильной работы стоит ограничить используемые ресурсы и откладывать выполнение новых задач пока они используются полностью. Для управление доступом к ресурсам можно использовать определенную логику в зависимости от ситуации: по времени, по приоритету, "честный" доступ, но так как ресурсы ограничены, система несколько ослабнет под серьезной нагрузкой.
Если данные не хранятся длительное время, они не могут стать причиной возбуждения судебного дела о нарушении чьих-либо прав.
Пользуйтесь тем, что знаете лучше всего. Этот урок не раз оправдывал себя. Paul знал Java лучше, чем что-либо еще, именно по-этому он заставил приложение на этом языке работать и выполнить все поставленные задачи.
Найдите свои собственные Mailinator'ы. Конечно, Mailinator является очень небольшой системой. В более крупной системе этот проект был бы лишь небольшой дополнительной возможностью, но такие системы обычно состоят просто из нескольких подпроектов размером с Mailinator. А что если подойти к разработке некоторых из них так же как и к Mailinator?
KISS работает, правда довольно редко. Простота систем часто обсуждается, но практические примеры появляются достаточно редко. Чаще всего разговор остается на уровне: твоя система сложная, а моя - простая, просто так как она моя. Mailinator является хорошим примером простой архитектуры системы.
Надежность является функцией архитектуры системы. Для построения системы, эффективно использующей память и выживающей серьезные атаки спаммеров, потребовалось серьезно подойти к каждому уровню ее архитектуры.

Архитектура Google Talk

Иван Блинков — Thu, 22 May 2008 16:39:00 +0400

Google Talk представляет собой сервис мгновенного обмена сообщениями от Google. В основе этого сервиса лежит XMPP протокол, более известный как Jabber. В России среди IM-сервисов несомненно наиболее широко распространен ICQ, но количество русских пользователей Jabber тоже неуклонно растет.

Вам когда-нибудь доводилось задумываться какое количество сообщений приходится обрабатывать такого рода сервисам? Допустим есть абстрактный IM-сервис, которым пользуется миллион пользователей, в среднем каждый из них отправляет сто текстовых сообщений. Сколько всего сообщений обработал и доставил сервис? Сто миллионов? Наивно!

Введение

Сервисы мгновенного обмена на самом деле подвергаются существенно большей нагрузке, чем это может показаться на первый взгляд. Давайте взглянем на расшифровку аббревиатуры XMPP: eXtensible Messaging and Presence Protocol. Обмен сообщениями - лишь одна из его функций, наиболее важная же его часть остается "за сценой" - отображение присутствия пользователей online.

Давайте посмотрим на наш абстрактный пример с точки зрения присутствия: пускай им пользуется все тот же миллион пользователей, когда один из них включил компьютер и появился online - он должен уведомить весь свой список контактов об этом событии, а также узнать кто из них находится online. Если этот список велик, то такое элементарное событие может обернуться для сервиса далеко не одной сотней обработанных и доставленных сообщений. Помимо простого изменения статуса online/offline подобную цепочку сообщений может генерировать и любое другое изменение статуса: связанное с отсутствием пользователя около компьютера или с изменением небольшого текстового сообщения, которое обычно отображается в контакт листе рядом с ником пользователя и призвано отображать текущее его состояние, занятие или чего там только не пишут (эта функция не всегда предоставляется IM-сервисами, но наверняка многим знакома по ICQ, если не по Jabber). Все эти сообщения как раз и стоят за "presence" в аббревиатуре XMPP, суммарный траффик, ими генерируемый, может в несколько раз превышать траффик от собственно самих текстовых сообщений.

Если учесть факты, описанные в предыдущем абзаце, не трудно догадаться, что зависимость суммарного количества presence-сообщений от количества пользователей IM-сервиса далеко не линейна. Их количество за какой-то период времени можно очень приблизительно посчитать как произведение трех параметров: количества пользователей online, средней длины списка контактов среди них и количества изменений статуса каждым пользователем. А каждый дополнительный пользователь в системе так или иначе увеличивает как минимум два из этих трех параметров.

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

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

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

Архитектура

Со стороны Google (о котором я, кстати говоря, уже писал) было бы глупо строить сервис мгновенного обмена сообщениями в стороне от остальных коммуникационных сервисов, предоставляемых этой компанией. Еще до своего публичного старта Google Talk был интегрирован в почтовый сервис GMail и социальную сеть Orkut: эти сервисы просто запрашивали у Google Talk присутствие online пользователей из своего списка контактов при возникновении соответствующих событий, но при этом не отображали результаты в своих страницах. Таким образом разработчики получили возможность оценить предстоящие нагрузки и готовность сервиса к публичному запуску намного более точно, чем они могли бы это сделать средствами синтетических тестов.

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

С точки зрения интеграции сервиса с другими проектами Google, очень важно было предоставить определенный уровень абстракции для взаимодействия в виде API и набора адресов, по которым необходимо обращаться к сервису. Придерживаясь одного API можно производить практически любые архитектурные или программные изменения в рамках проекта таким образом, что все его пользователи и проекты, в которые он интегрирован, просто не заметят что что-то изменилось. Адреса, к которым происходит обращение при обмене данных, так же являются своеобразной абстракцией - можно переместить сервис в новый датацентр и благодаря DNS трафик будет направляться в нужное место.

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

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

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

Заключение

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

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

Интерфейс

Иван Блинков — Sun, 04 May 2008 13:41:00 +0400

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

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

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

Уже догадались? Да, это я так неспеша плавно подводил разговор к объектно-ориентированному программированию. Термин интерфейс широко применяется и в нем. Как не трудно предположить, в роли объектов в этом случае выступают как сами классы, так и их экземпляры (которые, впрочем, тоже принято называть словом объект).

В общем случае интерфейсом класса выступает совокупность его public методов и переменных, то есть доступных для обращения из других частей приложения. Этот факт вполне логичен - именно благодаря им и осуществляется взаимодействие класса (или его объекта) с "внешним миром". Но не все так просто, особенно с точки зрения шаблонов проектирования, немаловажную роль в взаимодействии классов и объектов играет абстракция. Хочется обратить внимание, что формально имеется ввиду даже не сами методы, а их заголовки, то есть название, набор получаемых переменных и тип возвращаемого значения (этот набор данных принято также принято называть интерфейсом методов или функций), само тело метода (реализация) в данном случае не важно.

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

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

Самым наглядным языком программирования для демонстрации описания интерфейсов я считаю Java (хотя можно было бы выбрать и C#, PHP или практически любой другой по вкусу). В теории все просто:

Ключевое слово interface обозначает описание интерфейса;
За ним следует название конкретного интерфейса, которое впоследствии можно будет использовать в коде при его упоминании (некоторые программисты на правах традиции начинают названия интерфейсов с заглавной буквы I, мне в свое время даже пытались объяснить зачем так надо делать, но аргументы не показались мне достаточно весомыми);
Далее идет тело интерфейса, в котором перечисляются все заголовки методов, которые должны быть в классе, реализующем данный интерфейс (никакой реализации!);
Впоследствии приписав к заголовку любого класса ключевое слово implements с последующим указанием названия интерфейса, можно обязать этот класс реализовать указанные в описания интерфейса методы. Существует небольшое исключение для абстрактных классов (то есть классов,для которых не может быть создан объект, обозначаются ключевым словом abstract), они могут и не реализовать все методы интерфейса, но тогда эта обязанность будет переложена на их наследников.

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

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

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

// описание интерфейса
interface Renderable
{
    // обязуем реализовать метод draw
    public void draw();
}

// конкретная реализация интерфейса
class SomeText implements Renderable
{
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // вынуждены подчиниться и реализовать
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
         в качестве альтернативы можно было бы написать как-то так:
         if(obj instanceof Renderable)obj.draw();
         то есть проверить реализован ли интерфейс
         вместо использования его названия в роли типа данных
     */
  }

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

Как я уже упоминал: альтернативой такому подходу является использование полиморфизма и наследования. Такой подход более распространен в других языках программирования, например C++, но пример я приведу все равно на Java, основываясь на предыдущем примере, чтобы читателям было проще сравнивать.

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

// теперь используем абстрактный класс
abstract class Renderable
{
    // реализуем метод draw
    public void draw()
    {
       System.out.println("Вывод на экран недоступен!");
    }
}

// реализация интерфейса (на этот раз неформального)
class SomeText extends Renderable
{
   // на этот раз используем extends (наследование)
   // вместо implements
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // переопределяем метод draw
       // но могли этого и не делать, тогда
       // использовался бы метод из Renderable
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
        на этот раз так как в крайнем случае
        в крайнем случае вызовется хотябы
        метод из класса Renderable
     */
  }

Минимальные изменения - суть та же. Сразу хочу отметить, что этот процесс так прост только в Java, в других языках программирования понадобилось бы использование дополнительных модификаторов для метода draw (например в C#: virtual или abstract в классе-потомке и override в классе-наследнике, это необходимо для обеспечения возможности их переопределения).

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

Hadoop

Иван Блинков — Fri, 22 Feb 2008 22:41:00 +0300

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

Масштабируемость: с помощью Hadoop возможно надежное хранение и обработка огромных объемов данных, которые могут измеряться петабайтами;
Экономичность: информация и вычисления распределяются по кластеру, построенному на самом обыкновенном оборудовании. Такой кластер может состоять из тысяч узлов;
Эффективность: распределение данных позволяет выполнять их обработку параллельно на множестве компьютеров, что существенно ускоряет этот процесс;
Надежность: при хранении данных возможно предоставление избыточности, благодаря хранению нескольких копий. Такой подход позволяет гарантировать отсутствие потерь информации в случае сбоев в работе системы;
Кроссплатформенность: так как основным языком программирования, используемым в этой системе является Java, развернуть ее можно на базе любой операционной системы, имеющей JVM.

HDFS

В основе всей системы лежит распределенная файловая система под незамысловатым названием Hadoop Distributed File System. Представляет она собой вполне стандартную распределенную файловую систему, но все же она обладает рядом особенностей:

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

Архитектура HDFS

Проще всего ее демонстрирует схема, позаимствованная с официального сайта проекта и переведенная мной на руский:

Действующие лица:

Namenode: Этот компонент системы осуществляет всю работу с метаданными. Он должен быть запущен только на одном компьютере в кластере. Именно он управляет размещением информации и доступом ко всем данным, расположенным на ресурсах кластера. Сами данные проходят с остальных машин кластера к клиенту мимо него.
Datanode: На всех остальных компьютерах системы работает именно этот компонент. Он располагает сами блоки данных в локальной файловой системе для последующей передачи или обработки их по запросу клиента. Группы узлов данных принято называть Rack, они используются, например, в схемах репликации данных.
Клиент: Просто приложение или пользователь, работающий с файловой системой. В его роли может выступать практически что угодно.

Пространство имен HDFS имеет классическую иерархическую структуру: пользователи и приложения имеют возможность создавать директории и файлы. Файлы хранятся в виде блоков данных произвольной (но одинаковой, за исключением последнего; по-умолчанию 64 mb) длины, размещенных на Datanode'ах. Для обеспечения отказоустойчивости блоки хранятся в нескольких экземплярах на разных узлах, имеется возможность настройки количества копий и алгоритма их распределения по системе. Удаление файлов происходит не сразу, а через какое-то время после соответствующего запроса, так как после получения запроса файл перемещается в директорию /trash и хранится там определенный период времени на случай если пользователь или приложение передумают о своем решении. В этом случае информацию можно будет восстановить, в противном случае - физически удалить.

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

Все коммуникации между компонентами файловой системы проходят по специальным протоколам, основывающимся на стандартном TCP/IP. Клиенты работают с Namenode с помощью так называемого ClientProtocol, а передача данных происходит по DatanodeProtocol, оба они обернуты в Remote Procedure Call (RPC).

Система предоставляет несколько интерфейсов, среди которых командная оболочка DFSShell, набор ПО для администрирования DFSAdmin, а также простой, но эффективный веб-интерфейс. Помимо этого существуют несколько API для языков программирования: Java API, C pipeline, WebDAV и так далее.

MapReduce

Помимо файловой системы, Hadoop включает в себя framework для проведения масштабных вычислений, обрабатывающих огромные объемы данных. Каждое такое вычисление называется Job (задание) и состоит оно, как видно из названия, из двух этапов:

Map: Целью этого этапа является представление произвольных данных (на практике чаще всего просто пары ключ-значение) в виде промежуточных пар ключ-значение. Результаты сортируются и групируются по ключу и передаются на следующий этап.
Reduce: Полученные после map значения используются для финального вычисления требуемых данных. Практические любые данные могут быть получены таким образом, все зависит от требований и функционала приложения.

Задания выполняются, подобно файловой системе, на всех машинах в кластере (чаще всего одних и тех же). Одна из них выполняет роль управления работой остальных - JobTracker, остальные же ее бесприкословно слушаются - TaskTracker. В задачи JobTracker'а входит составление расписания выполняемых работ, наблюдение за ходом выполнения, и перераспределение в случае возникновения сбоев.

В общем случае каждое приложение, работающее с этим framework'ом, предоставляет методы для осуществления этапов map и reduce, а также указывает расположения входных и выходных данных. После получения этих данных JobTracker распределяет задание между остальными машинами и предоставляет клиенту полную информацию о ходе работ.

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

HBase

В рамках Hadoop доступна еще и система хранения данных, которую правда сложно назвать СУБД в традиционном смысле этого слова. Чаще проводят аналогии с проприетарной системой этого же плана от Google - BigTable.

HBase представляет собой распределенную систему хранения больших объемов данных. Подобно реляционным СУБД данные хранятся в виде таблиц, состоящих из строк и столбцов. И даже для доступа к ним предоставляется язык запросов HQL (как ни странно - Hadoop Query Language), отдаленно напоминающий более распространенный SQL. Помимо этого предоставляется итерирующмй интерфейс для сканирования наборов строк.

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

HQL очень прост по своей сути, если Вы уже знаете SQL, то для изучения его Вам понадобится лишь просмотреть по диагонали коротенький вывод команды help;, занимающий всего пару экранов в консоли. Все те же SELECT, INSERT, UPDATE, DROP и так далее, лишь со слегка измененным синтаксисом.

Помимо обычно командной оболочки HBase Shell, для работы с HBase также предоставлено несколько API для различных языков программирования:

Заключение

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

Архитектура Amazon

Иван Блинков — Sun, 17 Feb 2008 21:47:00 +0300

Amazon вырос из крошечной книжной лавки в один из крупнейших магазинов вселенной. Они добились этого благодаря их инновационному подходу к обзорам, рекомендациям и оценке продукции.-more-->

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

Как и многие статьи об архитектурах высоконагруженных систем на этом блоге, эта запись представляет собой перевод статьи, автором которой является Todd Hoff. Источниками информации для оригинала послужили:

Ранний Amazon от Greg Linden
Как Linux позволил Amazon сэкономить миллионы
Интервью с Werner Vogels'ом - техническим директором Amazon
Асинхронные архитектуры - краткий пересказ речи Werner Vogels'а от Cris Loosley
Познание технологической платформы Amazon - диалог с Werner Vogels
Блог Werner Vogels'а - построение масштабируемых распределенных систем

Платформа

Статистика

Более чем 55 миллионов учетных записей активных покупателей.
Более миллиона активных розничных партнеров по всему Миру.
Для построения страницы осуществляется доступ к 100-150 сервисам.

Архитектура

Что мы на самом деле подразумеваем под словом "масштабируемость"? Обычно говорят, что сервис является масштабируемым, если в случае расширения ресурсов системы производительность растет пропорционально. Рост производительности обычно означает увеличение количества выполняемых в единицу времени работ, но с другой стороны он может означать и рост объемов выполняемых работ, например размер обрабатываемых наборов данных.
Amazon пришлось претерпеть большое архитектурное преобразование в процессе перехода от двух-уровневой монолитной системы к полностью распределенной децентрализованной платформе для сервисов и приложений.
Все началось с одного приложения, обменивающегося данными с внутренним интерфейсом, написанного на C++.
Оно росло. За годы усилий, направленных на масштабирование, Amazon сфокусировался на масштабировании баз данных для хранения постоянно растущего объема информации о предметах, покупателях, заказах, для поддержки нескольких интернациональных сайтов. В 2001 году стало ясно, что исходное веб-приложение больше не в состоянии масштабироваться такими темпами. Базы данных были разбиты на маленькие части и для каждой их них был построен отдельный интерфейс, выполненный в виде сервиса, который являлся единственным способом получить доступ к данным.
Базы данных стали общим ресурсом, что затрудняло рост бизнеса в целом. Интерфейсы, связанные с пользователями и базами данных, были сильно ограничены в своей эволюции, так как они одновременно использовались множеством разных команд разработчиков и процессов.
Их архитектура тесно связана и построена вокруг сервисов. Ориентированная на сервисы архитектура дала им необходимый уровень изоляции для построения множества программных компонентов быстро и независимо.
Система выросла до сотен сервисов и не меньшего количества серверов приложений, агрегирующих информацию, полученную от сервисов. Приложение, генерирующее страницы для Amazon.com, является одним из таких серверов. То же самое можно сказать и про приложения, служащие в роли интерфейса для Веб-сервисов, сервиса, обслуживающего покупателя, интерфейса для продавцов.
Многие другие технологии очень трудно масштабировать до размеров Amazon, особенно технологии коммуникационной инфраструктуры. Они отлично работают до какого-то предела в размерах системы, а после перестают справляться с выполнения своих обязанностей. Именно это подтолкнуло Amazon на создание своих технологий в этой области.
Не ограничиваясь одним конкретным подходом, некоторые части системы используют Java/Jboss, но они являются всего лишь сервлетами.
C++ используется для обработки запросов, в то время как Perl и Mason - для составления контента.
Amazon предпочитает не пользоваться промежуточным программным обеспечением, так как оно в большинстве случаев является каркасом, а не средством разработки. Если используется промежуточное программное обеспечение, то разработчик становится заперт в использование тех принципов разработки, которые выбрал разработчик промежуточного ПО. Если появится необходимость использовать какие-либо другие решения, ничего не выйдет - вы заперты. Один и тот же цикл используется для обработки всех типов событий: сообщений, задержек в передаче данных, AJAX, и так далее. Слишком громоздко. Если бы промежуточное программное обеспечение было бы доступно в виде более мелких компонентов, скорее на правах средства разработки, чем каркаса для системы, тогда Amazon был бы более заинтересован в нем.
Кажется, что SOAP веб стек собирается заново решать все те же проблемы распределенных систем.
Если предложить разработчиком на выбор работу над SOAP и REST веб-сервисами, то только 30% выберут SOAP, это скорее всего будут разработчики на .NET и Java, привыкшие использовать WSDL файлы для генерации интерфейсов удаленных объектов. Оставшиеся 70% выберут REST - это будут пользователи PHP и Perl.
Обе категории разработчиков имеют возможность получить интерфейс к объектам Amazon. Разработчики заинтересованы просто выполнить свою работу, не заботясь о том, что происходит на другом конце провода.
Идея Amazon заключалась в построении открытого сообщества вокруг своих сервисов. Веб-сервисы были выбраны благодаря своей простоте. Но так это выглядит только снаружи. Внутри же находится архитектура, ориентированная на сервисы. Доступ к данным может быть получен только через соответстыующий интерфейс. Этот процесс описан в WSDL, но они используют свои собственные механизмы транспортировки и инкапсуляции данных.
Команды разработчиков очень небольшие и организуются вокруг сервисов
- Сервисы являются независимыми единицами предоставления функционала в рамках Amazon
- Если у разработчика возникает новая бизнес-идея или проблема, которую ему хотелось бы решить, он собирает команду для ее решения или реализации. Количество участников ограничено 8-10 людьми. Команды из такого количества человек обычно называют пиццерийными, так как для того, чтобы ее накормить достаточно двух пицц.
- Команды очень небольшие, но они уполномочены решать поставленную задачу любыми доступными способами, именно так, как они считают нужным. – В качестве примера задачи, поставленной перед такой командой, может служить поиск фраз в рамках книги, уникальных для конкретного текста. – Экстенсивное A/B тестирование используется для интеграции новых сервисов. Они смотрят на произведенное влияние на систему и выполняют экстенсивные измерения.
Развертывание
- Они создают специальную инфраструктуру для управления зависимостями и развертывания.
- Цель состоит в том, чтобы иметь все необходимые сервисы развернутыми на новом оборудовании, в том числе код приложений, системы мониторинга и лицензирования и так далее.
- Результатом развертывания является виртуальная машина, которая запускается с помощью EC2.
Работа с покупателями для того, чтобы убедиться, что внедрение нового сервиса того стоит
- Фокусировка на конкретно на тех возможностях, которые планируется предоставить покупателям
- Разработчики принуждаются работать в первую очередь с упором на предоставление пользователям новых возможностей, а не на внедрение новых технологий и уже после этого осознавание того, зачем это делалось
- Все начинается с пресс-релиза о новых возможностях, предоставляемых пользователям, а после чего ведется работа по определению того факта, планировалось ли все же что-то значимое для пользователей или нет?
- Дизайн должен быть минимален. Простота - залог успеха, когда речь идет о больших распределенных системах
Управление состояниями, как основная проблема крупномасштабных систем
- Изнутри они теоретически могут предоставить практически бесконечный объем дискового пространства.
- Не все, но многие операции имеют состояния. Например, оформление покупки продукта.
- Сервис отслеживания последних открытых страниц использует рекомендации, базирующиеся на идентификационных номерах сессий.
- Они следят за всем, так что в любом случае цель вовсе не в поддержании состояний. Достаточно небольшой набор состояний требует поддержания с помощью сессий. Сервисы уже хранят всю необходимую информацию, остается лишь ими воспользоваться.
Три свойства системы или теорема Eric Brewer'а:
- Три свойства системы: стабильность, доступность, переносимость возможных распадений сети
- В большинстве случаев для любой системы с общими данными выполняются два свойства из трех
- Возможность разделения: распределение узлов по небольшим группам, которые могут иметь доступ к другим группам, но не могут получить доступ к конкретному произвольному узлу системы
- Стабильность: запишите какие-либо данные, а затем прочитайте их же - получите те же самые данные обратно. Для распределенных систем это далеко не всегда так.
- Доступность: не всегда имеется возможность произвести чтение или запись каких-либо данных. Система иногда сообщает, что она не может произвести запись, так как она хочет остаться целостной.
  - Для масштабирования системы необходимо разбиение ее на части, что приводит к выбору между стабильностью и доступностью. Необходимо найти некий баланс между ними.
  - Выберите определенный подход в соответствии с нуждами сервиса.
  - В процессе выбора продуктов приоритет предоставляется доступности: все запросы на добавление товаров в корзину учитываются, так как именно они приносят прибыль. Даже если возникают какие-либо ошибки, они скрываются от покупателя, и разработчики разбираются с ним позже.
  - В процессе подтверждения заказа покупателем важна надежность, так как сразу несколько сервисов одновременно используют одни и те же данные: работа с кредитными картами, доставка, составление отчетов.

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

Для того, чтобы строить реально масштабируемые системы, Вам необходимо изменить свой склад ума. Вероятностный подход к хаосу может принести неплохие результаты. В традиционных системах мы представляем себе идеальный мир, где не происходит никаких чрезвычайных ситуаций, а затем мы в этом же мире пытаемся построить реализацию по-настоящему сложных алгоритмов. При первом же удобном случае вся система гарантированно рушится, это реальность, пора бы уже к этому привыкнуть. Например, неплохим решением мог бы стать подход, использующий быструю перезагрузку и тем самым быстрое восстановление работоспособности. При достаточной избыточности данных и сервисов этот подход может дать практически 100% отказоустойчивость. Необходимо создание самовосстанавливающихся и самоорганизующихся операций.
Создание инфраструктуры, в которой компоненты ничего друг с другом не разделяют. Сама инфраструктура может стать общим ресурсом для разработки и развертывания с теми же недостатками, что и совместные ресурсы в логике и на уровне данных. Это может вызвать запирание и блокировку данных. Архитектура, ориентированная на сервисы, позволяет создание параллельных изолированных процессов разработки, позволяющих масштабировать будущие разработки для соответствия темпам роста.
Откройте систему с помощью собственной API для создания экосистемы вокруг Ваших приложений.
Единственный способ управлять большой распределенной системой - разрабатывать ее как можно более простой. Это достигается благодаря отсутствию скрытых требований и зависимостей в ее структуре. Минимизируйте использование технологий до того уровня, который Вам необходим для решения конкретно Ваших проблем и задач. Создание дополнительных искуственных и ненужных уровней в системе никогда не пойдет ей на пользу.
Организация вокруг сервисов дает гибкость. Параллельная работа возможна, так как на выходе получается сервис. Этот факт резко сокращает время, необходимое для выхода на рынок. Построение инфраструктуры позволяет сервисам реализовываться очень быстро.
Определенно будут возникать проблемы со всем, что пускает пыль в глаза еще до реальной реализации.
Для внутреннего управления сервисами стоит использовать SLA.
Кто угодно может быстро добавлять веб-сервисы к их продукту. Достаточно лишь реализовать часть продукта в виде сервиса и начать его использовать.
Построение инфраструктуры производится для обеспечения производительности, надежности и контролирования издержек. После ее построения Вы никогда не сможете сказать после очередной неудачи, что в этом виновата компания Х. Ваше программное обеспечение не всегда является более надежным, чем любой другой, но зато у Вас появляется возможность быстро устранять неполадки и развертывать ее, в отличии от продуктов других компаний.
Используйте систему оценивания и целенаправленные обсуждения для отделения "хорошего" от "плохого". Бывшие сотрудники Amazon в своих презентациях неоднократно демонстрировали свою глубоко засевшую привычку ставить покупателей перед выбором и смотреть какой из вариантов сработает лучшим образом, и уже на результатах такого рода тестов строить свои решения.
Avinash Kaushik называет это избавлением от "гиппопотамов", наиболее высоко оплачиваемых людей. Осуществляется оно с помощью A/B тестирований и веб-аналитиков. Если у вас есть выбор пути развития, реализуйте оба, позвольте людям ими пользоваться, и посмотрите какой из альтернативных результатов приведет в лучшим результатам.
Создайте экономичную культуру. Amazon использовал двери в роли столов, например.
Знайте, что Вам необходимо. Amazon имеет печальный опыт с ранней системой рекомендаций, которая не сработала: "Это было не то, что требовалось Amazon. Рекомендации книг в Amazon требовали работы с разбросанными данными, всего лишь несколько рейтингов или покупок. Она должна работать быстро. Система должна иметь необходимый масштаб для работы с массивным количеством клиентов и огромным каталогом. Все, что было необходимо: лишь усовершенствовать обнаружение книг из глубин каталога, откуда читатели не могли достать из самостоятельно."
Работа в сторонних проектах, просто так как Вы в них заинтересованы, часто является намного более продуктивной и инновационной, чем просто работа за деньги. Никогда не недооценивайте мощь блуждания в той сфере, которая Вам интересна.
Вовлеките всех в производство еды для собак. Пойдите на склад и упаковывайте книги во время рождественской суеты. Это называется командной работой.
Создайте специальный сайт для тестирования нововведений перед выпуском их в вольное плавание.
Непоколебимая, кластеризованная, реплицирующая, распределенная файловая система является идеальным решением для хранения данных, доступных только для чтения, используемых веб-серверами.
Предусмотрите способы отменить изменения, если обновление не удалось. Если нужно, напишите соответствующие программные средства.
Переключитесь на глубоко сервис-ориентированную архитектуру.
Во время интервью обращайте внимание на три критерия: энтузиазм, креативность, компетентность. Самым крупным залогом успеха Amazon.com был энтузиазм.
Наймите Боба, кого-то кто знает свое дело, обладает невероятными способностями и знанием системы, и что самое важное, умеет решать даже самые невообразимые проблемы просто нырнув в них с головой.
Инновация может прийти только снизу. Те, кто находится ближе всего к проблеме, являются наиболее вероятными людьми, кто смог бы ее решить. Любая организация, зависящая от инноваций, должна уметь пользоваться хаосом. Лояльность и подчинение - не наш метод.
Креативность должна лезть из всех щелей.
У всех должна быть возможность эксперементировать и учиться. Позиции, подчинение и традиции не должны играть какой-либо роли. Для процветания инновации балом должен править точный расчет.
Выберите путь инноваций. Перед лицом всей компании, Jeff Bezos может дать старый кроссовок Nike в роли награды "Просто сделай это" тому, кто привнес инновацию.
Не платите за производительность. Предоставьте хороший повод задрать нос и высокую оплату труда, но оставляйте это простым. Распознать выдающуюся работу можно и другими методами. Оплата по заслугам звучит неплохо, но в условиях большой организации это практически невозможно. Используйте не-денежные награды, такие как тот старый кроссовок. Если преподнести это как способ сказать спасибо, кто-то оценит.
Вырастайте быстро. Большие парни вроде Barnes и Nobel у Вас на хвосте. Amazon не был ни первым, ни вторым, ни даже третим книжным магазинам в Сети, но их взгляд на работу и драйв в итоге позволили им вырваться вперед.
В дата-центрах персонал проводит только 30% времени в работе над вопросами создания инфраструктуры, остальные 70% они проводят за размещения поставок тяжелого оборудования, управлением программным обеспечением, балансировкой нагрузок, техническими работами, изменениями в масштабе и так далее.
Запретите клиентам прямой доступ к базе данных. Это значит появление возможность масштабировать сервис и делать его более надежным не вовлекая при этом клиентов. Это очень похоже на возможность Google независимо вносить улучшения в части системы, что приводит к улучшениям в работе всех остальных ее компонентов.
Создайте единый универсальный механизм получения доступа к сервисам. Это позволяет более легко агрегировать информацию, полученную от сервисов, децентрализованно прокладывать маршруты передачи запросов, распределенно следить за ними, а также получать доступ к другим инфраструктурным механизмам.
Предоставление свободного доступа ко всем сервисам Amazon.com разработчикам со всех уголков Мира также было достаточно значимым компонентом успеха, так как это привлекло на порядок больше инноваций, чем они могли надеяться построить самостоятельно.
Разработчики сами знают какими инструментами они владеют лучше всего, какие из них делают их наиболее продуктивными.
Не накладывайте слишком много ограничений на инженеров. Предоставляйте стимулы для использования некоторых вещей, например интеграцию с системами мониторинга и другими инструментами инфраструктуры. Для всего остального старайтесь предоставлять возможность командам функционировать максимально независимо.
Разработчики, они как художники; они делают свою работу лучше всего только тогда, когда им предоставляют свободу это делать, но в любом случае им требуются качественные инструменты. Имейте много вспомогательных инструментов, имеющих само-помогающую природу. Поддерживайте окружение вокруг разработки сервисов, которое никогда не будет вмешиваться в сам процесс разработки.
Вы построили это, вы и поддерживаете. Это позволяет разработчикам почувствовать повседневную работу их приложения, а также предоставляет им постоянный контакт с покупателями.
Раз в пару лет разработчики должны проводить некоторое время в отделе по работе с клиентами. Это позволит им выслушать покупателей, ответить на электронные письма, и реально осознать влияние тех вещей, которые они реализовали с помощью как технологи.
Пользуйтесь "голосом покупателя", который являлся бы реалистичной историей от покупателя о какой-то конкретной части сайта. Это поможет менеджерам и инженерам осознать тот факт, что все эти технологии построены для реальных людей. Статистика отдела по работе с клиентами является ранним индикатором того, что вы делаете что-то не так, а также указывает на то, что реально является болевыми точками для ваших покупателей.
Инфраструктура Amazon, подобно Google, является огромным конкурентным преимуществом. Они могут строить комплексные приложения на основе примитивных сервисов, которые сами по себе просты до безобразия. Они могут независимо масштабировать свою работу, поддерживать доступность не распараллеленной системы, быстро реализовывать новые сервисы без необходимости массивных изменений в конфигурации.

Архитектура Flickr

Иван Блинков — Fri, 08 Feb 2008 22:41:00 +0300

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

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

Как и предыдущий пост "Архитектура Google", этот тоже является переводом статьи от Todd'а Hoff'а. Возможно читателям Google был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:

Flickr и PHP (ранний документ)
Планирование нагрузок на LAMP
Федерация Flickr: Тур по архитектуре Flickr
Построение масштабируемых веб-сайтов от Call Handerson'а из Flickr
История войн баз данных #3: Tim O'Reilly о Flickr
Cal Henderson's Talks - много полезных презентаций

Платформа

PHP
MySQL
Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")
Memcached для кэширования
Squid в качестве обратной-прокси для html и изображений
Linux (RedHat)
Smarty в роли шаблонизатора
Perl
PEAR для парсинга e-mail и XML
ImageMagick для обработки изображений
Java для узлового сервиса
Apache
SystemImager для развертывания систем
Ganglia для мониторинга распределенных систем
Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
Cvsup для распространения и обновления коллекций файлов по сети

Статистика

Более четырех миллиардов запросов в день
Примерно 35 миллионов фотографий в кэше Squid
Около двух миллионов фотографий в оперативной памяти Squid
Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
38 тысяч запросов к memcached (12 миллионов объектов)
2 петабайта дискового пространства
Более 400000 фотографий добавляются ежедневно

Архитектура

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

Два ServerIron
Squid кэши
Системы хранения NetApp
Серверы PHP приложений
Менеджер хранения данных
Master-master сегменты
Центральная база данных, структурированная по принципу Dual Tree
Memcached кластер
Поисковая система

Хранение данных

Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.
Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.
Использование выделенных серверов для статического контента
Все, за исключением фотографий, хранится в базе данных
Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API
В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".
Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:
- Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.
- Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.
- Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)
Сегменты:
- Срез основной базы данных
- Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре
- Привязывание новых учетных записей к сегментам системы происходит случайным образом
- Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.
Нажатие на Favorite:
- Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)
- Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)
- Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?
Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.
Для избавления от задержек, связанных с репликацией...
- при каждой загрузке страницы, пользователю предоставляется список серверов
- если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.
Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
Каждый сегмент содержит данные о более чем 400 тысячах пользователей.
Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

Поиск

Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!
В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.
Эту систему стоит рассматривать как аналог Lucene.

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

EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.
6 жестких дисков с 15000rpm, объединены в RAID-10.
Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).
Используются 2U корпуса.

Резервное копирование данных

ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.
Каждую ночь делается снимок со всего кластера баз данных.
Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.
Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.
Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.

Тэги

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

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

Ускорение работы с помощью создания организационного плана для непрерывной работы всей системы на уровне нескольких датацентров, таким образом чтобы все датацентры имели возможность получать запросы на общий уровень данных (как сами БД, так и memcache и прочее) все вместе одновременно. Если все части системы постоянно активны - время простоя оборудования будет сведено к минимуму.

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

Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.
Реструктуризация базы данных - не самое лучшее занятие.
Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
Кэширование и оперативная память может стать ответом на все вопросы.
Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
Найдите максимальное значения для всех показателей:
- Какой максимум чего-то, что может выполнять каждый сервер?
- Как близко параметр находится к максимуму и каковы тенденции?
- MySQL (дисковый ввод/вывод?)
- Squid (дисковый ввод/вывод? или процессорное время?)
- Memcached (процессорное время? или пропускная способность?)
Старайтесь учесть особенности использования Вашего приложения.
- Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?
- Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.
- По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.