Insight IT

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

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

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

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

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

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

Иван Блинков — Wed, 15 Aug 2012 22:26:00 +0400

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

Платформа

Amazon AWS - хостинг и вспомогательные сервисы
nginx - вторичная балансировка нагрузки, отдача статики
Python - язык программирования
Django - фреймворк
MySQL - основная СУБД
memcached - кэширование объектов
Redis - кэширование коллекций объектов
Solr - поиск
Hadoop - анализ данных

Статистика

3 миллиона уникальных посетителей в день
18 миллионов уникальных посетителей в месяц
4-я по популярности социальная сеть в США после Facebook, Twitter и LinkedIn
Порядка 500 виртуальных машин в EC2
80 миллионов объектов в S3
410Тб пользовательских данных

Развитие

Март 2010

1 маленький виртуальный веб-сервер
1 маленький виртуальный сервер MySQL
Все это в Rackspace, 1 разработчик

Январь 2011

1 сервер nginx для балансировки нагрузки, 4 веб-сервера
2 сервера MySQL с master/slave репликацией
3 сервера для отложенного выполнения задач
1 сервер MongoDB
Переехали на Amazon EC2 + S3 + CloudFront

Осень 2011

2 сервера nginx, 16 веб-серверов, 2 сервера для API
5 функционально разделенных серверов MySQL с 9 read slave
Кластер из 4 узлов Cassandra
15 серверов Membase в 3 отдельных кластерах
8 серверов memcached
10 серверов Redis
7 серверов для отложенной обработки задач
4 сервера Elastic Search
3 кластера MongoDB
3 разработчика
Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.

Зима 2011-2012

Заменили CloudFront на Akamai - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный CDN для сайта с большим количеством изображений - чуть ли не залог успеха.
90 веб серверов и 50 серверов для API
66 + 66 MySQL серверов на m1.xlarge инстансах EC2
59 серверов Redis
51 серверов memcached
25+1 сервер для отложенной обработки задач на основе Redis
Кластеризованный Solr
6 разработчиков

Весна-лето 2012

Снова сменили CDN, на этот раз в пользу ранее неизвестного мне Edge Cast. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.
135 веб серверов и 75 серверов для API
80 + 80 серверов MySQL
110 серверов Redis
60 серверов memcached
60 + 2 сервера для отложенной обработки задач на основе Redis
25 разработчиков

Выбор

Почему Amazon Ec2/S3?

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

Почему MySQL?

Очень "зрелая", хорошо известная и любимая многими
Редки катастрофичные потери данных
Линейная зависимость времени отклика от частоты запросов
Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)
Надежное активное сообщество
Отличная поддержка от Percona
Бесплатна

Почему memcached?

Очень "зрелый", отличная производительность, хорошо известный и любимый многими
Никогда не ломается
Бесплатен

Почему Redis?

Много удобных структур данных
Поддержка персистентности и репликации
Также многим известен и нравится
Стабильно хорошая производительность и надежность
Также бесплатен

Архитектура

Сlustering vs Sharding

Большую часть презентации, на основе которой написана данная статья (ссылка, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.
Вообще есть два фундаментальных способа распределить данные между несколькими серверами:
- Вертикально: разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.
- Горизонтально: каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.
С первого взгляда казалось, что они пытаются вертикальное разбиение назвать sharding, а горизонтальное - clustering. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.
По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду Cassandra, Membase, HBase и Riak, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.
За словом sharding в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством ~~физических серверов~~ виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в Facebook.
От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:
- Vitess от Google / YouTube
- FlockDB от Twitter
В их проекте данная подсистема развивалась следующим образом:
- 1 БД + внешние ключи + join'ы →
- 1 БД + денормализация + кэш →
- 1 БД + master/slave + кэш →
- несколько функциональных разделенных БД + master/slave + кэш →
- вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш
При использовании аналогичного решения остерегайтесь:
- Невозможности выполнять большинство запросов с join
- Отсутствия транзакций
- Дополнительных манипуляций для поддержания ограничений уникальности
- Необходимости тщательного планирования для изменений схемы
- Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов

Остальные моменты

Кэширование многоуровневое:
- Коллекции объектов хранятся в списках Redis
- Сами объекты - в memcached
- На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL
- Кэш файловой системы - само собой
Еще пара фактов про кэширование в Pinterest:
- Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования
- В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен
Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.
Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.
Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц
Текущие проблемы:
- Масштабирование команды
- Основанная на сервисах архитектура:
  - Ограничения соединений
  - Изоляция функционала
  - Изоляция доступа (безопасность)

Уроки от команды Pinterest

"Оно сломается. Все должно быть просто." - столько раз уже слышу это наставление, но ни разу не видел разработчиков, которые реально к нему прислушивались.
"Кластеризация - страшная штука." - конечно страшная, большая и сложная. Но кому сейчас легко?
"Продолжайте получать удовольствие." - с этим не могу не согласиться, без удовольствия работать совершенно невозможно в любой сфере.

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

Scaling Pinterest @ MySQL Meetup
- В презентации можно посмотреть примеры кода и SQL-запросов
- Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста
Pinterest Architecture Update
Вакансии в Pinterest

Архитектура YouTube 2012

Иван Блинков — Sat, 24 Mar 2012 16:50:00 +0400

Выбирайте самое простое решение с наиболее общими гарантиями, которые практически полезны.

- Дао YouTube

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

Статистика

4 млрд. просмотров страниц в день
60 часов видео загружается каждую минуту
350 миллионов устройств подключено к YouTube
На февраль 2012 года в США по данным comScore:
- 147,4 млн. уникальных зрителей
- 16,7 млрд. просмотров видео (в октябре 2011 было больше 20 млрд.)
- Каждый зритель посмотрел в среднем 7 часов видео за месяц
- 1.1 млрд. просмотров видео рекламы, суммарной длительностью в 10.8 млн. часов

Технологии

Linux - операционная система
Apache - основной HTTP-сервер
lighttpd - отдача видео из YouTube CDN
Zookeeper - распределенные блокировки, хранение конфигураций
Python:
- wiseguy - FastCGI-прослойка между Apache и Python
- pycurl - лучшая доступная реализация HTTP-клиента, но в итоге все равно заменили на самописное низкоуровневое решение, выиграв 8% в потреблении вычислительных ресурсов.
- spitfire - высокопроизводительный шаблонизатор на основе абстрактного синтаксического дерева с регулируемым уровнем оптимизации (как в gcc)
- bson в качестве формата сериализации
BigTable - хранение изображений
MySQL - используется просто как хранилище данных, версия 5.1.52 с InnoDB
Vitess - система для масштабирования MySQL-кластера

Vitess

Основная цель проекта - предоставление всех необходимых инструментов и серверов для горизонтального масштабирования баз данных на основе MySQL, с учетом потребностей современных интернет-проектов.
Реализован на Go - все еще экзотическом языке программирования, также родившемся в стенах Google. Сравним по производительности с C++ и Java, но несколько более "выразителен".
Опубликован в opensource 24 февраля 2012 года, совсем недавно, так что YouTube - по-прежнему единственный пример его использования на практике в крупном проекте.
Готовые клиентские библиотеки пока только для Python и Go, что не удивительно, но есть и универсальные интерфейсы на основе HTTP и просто TCP-сокетов.
Основной формат данных - bson, как и в MongoDB, но по словам разработчиков Vitess их реализация выполняет (де)сериализацию в 10-15 раз быстрее.
Ядром проекта выступает Vtocc, SQL-прокси с RPC интерфейсом, позволяющий перераспределять запросы от большого количества (более 10 тыс.) одновременно подключенных клиентов в сравнительно небольшое количество соединений с базами данных. Пропускная способность порядка 10 тыс. запросов в секунду.
Встроенные возможности Vtocc:
- парсер и анализатор SQL-запросов для оптимизации их выполнения;
- заполнение типичных запросов переменными с поддержкой кэширования результатов;
- управление транзакциями и сроками их выполнения ("убивает" затянувшиеся);
- для каждого пространства ключей (логической таблицы) можно указать фактор репликации, что создаст необходимое количество второстепенных баз данных в дополнение к мастеру;
- можно явно указать, что чтение необходимо произвести с мастера (важно когда пользователь только что выполнил какое-то действие и должен сразу же увидеть его результат);
- отдельные пулы соединений для выполнения операций чтения и записи;
- исключение "зависших" соединений из пулов;
- перезапуск без простоя системы;
- поддержка DML.

Партиционирование

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

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

YouTube - еще один проект мирового масштаба, который с самого начала использовал MySQL и оказался не в силах от него отказаться, не смотря на трудности с горизонтальным масштабированием.
По аналогичному пути пошли и другие проекты, схожие с Vitess надстройки над MySQL используются в Facebook и Twitter:
- В Facebook она дополнена сильной интеграцией с memcached и сильно ограниченным интерфейсом, не имеющим практически ничего общего с SQL. Планы о публикации в opensource, кажется, были, но я не слышал чтобы они воплотились в жизнь. // Уже почти дописав статью случайно заметил в коде, а потом и мелким шрифтом в документации, что в Vitess тоже используется memcached для кэширования из-за проблем со сборщиком мусора Go.
- Twitter по-прежнему использует свою связку FlockDB + Gizzard на Scala, которые уже пару лет публично доступны. В отличии от Vitess она заточена на хранение информации о социальных графах, по-этому сфера её применения как в Twitter, так и за его пределами ограничена.
Vitess - пожалуй первая относительно успешная попытка построить распределенную горизонтально масштабируемую СУБД на основе реляционной базы данных, сохранив при этом SQL-интерфейс, пускай и с некоторыми ограничениями.
Выбирайте подходящее хранилище для каждого типа данных в системе - если Vitess стал подходящим решением для структурированных данных вроде информации о пользователях, метаданных видео и комментариев, это не значит, что он хорошо (или плохо) справится, например, с медиа-файлами вроде изображений и видео (для них в YouTube по-прежнему используют стек технологий Google, подробности не публикуются).
Python - вполне пригодный инструмент для реализации бизнес-логики интернет-проектов, свет клином на PHP не сошелся. Python предлагает широкий ассортимент инструментов для решения любых типичных для интернет-проектов задач, хотя субъективно выбор некоторых из них разработчиками YouTube мне кажется странным.

В комментариях предлагаю обсудить слабые и сильные стороны использования надстроек над реляционными базами данных, скажем по сравнению с использованием изначально-распределенных СУБД, таких как Riak, Cassandra и многих других. Может быть кто-то уже успел прикрутить к своему проекту Vitess или хотя бы FlockDB и готов поделиться впечатлениями?

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

Mike Solomon на PyCon'12 (один из первых разработчиков проекта)
О проекте Vitess
Статистика comScore на февраль '12

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

Иван Блинков — Tue, 21 Feb 2012 16:29:00 +0400

Tumblr - одна из самых популярных в мире платформ для блоггинга, которая делает ставку на привлекательный внешний вид, юзабилити и дружелюбное сообщество. Хоть проект и не особо на слуху в России, цифры говорят сами за себя: 24й по посещаемости сайт в США с 15 миллиардами просмотров страниц в месяц. Хотите познакомиться с историей этого проекта, выросшего из простого стартапа?

Введение

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

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

Платформа

CentOS на серверах, Mac OS X для разработки
Apache - основной веб-сервер
PHP, Scala, Ruby - языки программирования
Finagle - асинхронный RPC сервер и клиент
MySQL, HBase - СУБД
memcached, Redis - кэширование
Varnish, nginx - отдача статики
HAProxy - балансировка нагрузки
kestrel, gearman - очередь задач
Thrift - сериализация
Kafka - распределенная шина сообщений
Hadoop - обработка статистики
ZooKeeper - хранение конфигурации и состояний системы
git - система контроля версий
Jenkins - непрерывное тестирование

Статистика

Около 500 миллионов просмотров страниц в день
Более 15 миллиардов просмотров страниц в месяц
Посещаемость растет примерно на 30% в месяц
Пиковые нагрузки порядка 40 тысяч запросов в секунду
Около 20 технических специалистов в команде
Каждый день создается около 50Гб новых постов и 2.7Тб обновлений списков последователей
Более 1Тб статистики обрабатывается в Hadoop ежедневно
Используется порядка 1000 серверов:
- 500 веб-серверов c Apache и PHP-приложением
- 200 серверов баз данных (существенная их часть - резервные)
  - 47 пулов
  - 30 партиций (шардов)
- 30 серверов memcached
- 25 серверов Redis
- 15 серверов Varnish
- 25 серверов HAProxy
- 8 серверов nginx
- 14 серверов для очередей задач

Типичное использование

Tumblr используется несколько по-другому, чем другие социальные сети:
- При более чем 50 миллионах постов в день, каждый из них попадает в среднем к нескольким сотням читателей. Это и не несколько пользователей с миллионами читателей (например, популярные личности в Twitter) и не миллиарды личных сообщений.
- Ориентированность на длинные публичные сообщения, полные интересной информацией и картинками/видео, заставляет пользователей проводить долгие часы каждый день за чтением Tumblr.
- Большинство активных пользователей подписывается на сотни других блоггеров, что практически гарантирует много страниц нового контента при каждом заходе на сайт. В других социальных сетях поток новых сообщений переполнен ненужным контентом и толком не читается.
- Как следствие, при сложившемся количестве пользователей, средней аудиторией каждого и высокой активностью написания постов, системе приходится обрабатывать и доставлять огромное количество информации.
Публичные блоги называют Tumblelog'ами, они не так динамичны и легко кэшируются.
Сложнее всего масштабировать Dashboard, страницу, где пользователи в реальном времени читают что нового у блоггеров, на которых они подписаны:
- Кэширование практически бесполезно, так как для активных пользователей запросы редко повторяются.
- Информация должна отображаться в реальном времени, быть целостной и не "задерживаться".
- Около 70% просмотров страниц приходится именно на Dashboard, почти все пользователи им пользуются.

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

Когда проект только начинался, Tumblr размещался в Rackspace и последние выдавали каждому блогу с собственным доменом A-запись. Когда они переросли Rackspace, они не смогли полноценно мигрировать в новый датацентр, в том числе из-за количества пользователей. Это было в 2007 году, но у них по-прежнему часть доменов ведут на Rackspace и перенаправляются в новый датацентр с помощью HAProxy и Varnish. Подобных "унаследованных" проблем у проекта очень много.
С технической точки зрения проект прошел по пути типичной эволюции LAMP:
- Исторически разработан на PHP, все началось с веб-сервера, сервера баз данных и начало потихоньку развиваться.
- Чтобы справляться с нагрузкой они начали использовать memcache, затем добавили кэширование целых страниц и статических файлов, потом поставили HAProxy перед кэшами, после чего сделали партиционирование на уровне MySQL, что сильно облегчило им жизнь.
- Они делали все, чтобы выжать максимум из каждого сервера.
- Было разработано два сервиса на C: генератор уникальных идентификаторов на основе HTTP и libevent, а также Staircar, использующий Redis для обеспечения уведомлений в реальном времени на Dashboard.
Dashboard использует подход "разбрасывать-собирать", так как из-за отсортировонности данных по времени традиционные схемы партиционирования работали не очень хорошо. По их прогнозам текущая реализация позволит им рости еще в течении полугода.

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

Приоритетным направлением стали технологии, основанные на JVM, по причине более быстрой разработки и доступности квалифицированных кадров. Мотивация несколько спорная, особенно если учесть, что речь идет в первую очередь о Scala, а не о Java.
Основная цель - вынести все из PHP приложения в отдельные сервисы, что сделает его лишь тонким клиентом к внутреннему API.
Почему выбор пал именно на Scala и Finagle?
- Многие разработчики имели опыт с Ruby и PHP, так что Scala был привлекательным (цитата, логики мало)
- Finagle был одним из основных факторов в пользу JVM: это библиотека, разработанная в Twitter, которая решает большинство распределенных задач вроде маршрутизации запросов и обнаружение/регистрацию сервисов - не пришлось реализовывать это все с нуля.
- В Scala не принято использовать общие состояния, что избавляет разработчиков от забот с потоками выполнения и блокировками.
- Им очень нравится Thrift в роли программного интерфейса из-за его высокой производительности (он кроссплатформенный и к JVM никак не относится)
- Нравится Netty, но не хочется связываться с Java, еще один аргумент в пользу Scala.
- Рассматривали Node.js, но отказались так как под JVM проще найти разработчиков, а также из-за отсутствия стандартов, "лучших практик" и большого количества качественно протестированного кода.
Старые внутренние сервисы также переписываются с C + libevent на Scala + Fingle.
Был создан общий каркас для построения внутренних сервисов:
- Много усилий было приложено для автоматизации управления распределенной системой.
- Создан аналог скаффолдинга - используется некий шаблон для создания каждого нового сервиса.
- Все сервисы выглядят одинаково с точки зрения системного администратора: получение статистики, мониторинг, запуск и остановка реализованы одинаково для всех сервисов.
- Созданы простые инструменты для сборки сервисов без вникания в детали используемых стандартных решений.
Используется 6 внутренних сервисов, над которыми работает отдельная команд. На запуск сервиса с нуля уходит около 2-3 недель.
Новые, нереляционные СУБД, такие как HBase и Redis, вводятся в эксплуатацию, но основным хранилищем по-прежнему остается сильно партиционированный MySQL.
HBase используется для сервиса сокращенных ссылок для постов, а также всех исторических данных и аналитики. HBase хорошо справляется с ситуациями, где необходимы миллионы операций записи в секунду, но он не достаточно стабилен, чтобы полностью заменить проверенное временем решение на MySQL в критичных для бизнеса задачах.
Партиционированный MySQL плохо справляется с отсортированными по времени данными, так как один из серверов всегда оказывается существенно более "горячим", чем остальными. Также сталкивались с значительными задержками в репликации из-за большого количества параллельных операций добавления данных.
Используется 25 серверов Redis с 8-32 процессами на каждом, что означает порядка 300-400 экземпляров Redis в сумме.
- Используется для уведомлений в реальном времени на Dashboard (о событиях вроде "кому-то понравился Ваш пост").
- Высокое соотношений операций записи к операциям чтения сделало MySQL не очень подходящим кандидатом.
- Уведомления не так критичны, их потеря допустима, что позволило отключить персистентность Redis.
- Был создан интерфейс между Redis и отложенными задачами в Finagle.
- Сервис коротких ссылок также использует Redis как кэш, а HBase для постоянного хранения.
- Вторичный индекс Dashboard также построен вокруг Redis.
- Redis также используется для хранения задач Gearman, для чего был написан memcache proxy на основе Finale.
- Постепенно отказываются от memcached в пользу Redis в роли основного кэша. Производительность у них сопоставима.
Внутренним сервисам необходим доступ к потоку всех событий в системе (создание, редактирование и удаление постов, нравится или не нравится и т.п.), для чего была созданна внутренняя шина сообщений (англ. firehose, пожарный шланг):
- Пробовали использовать в этой роли Scribe, но так как оно по сути свелось к пропусканию логов через grep в реальном времени - нагрузки оно не выдержало.
- Текущая реализация основана на Kafka, решению аналогичной задачи от LinkedIn на Scala.
- MySQL также не рассматривался из-за большой доли операций записи.
- Внутри сервисы используют HTTP потоки для чтения данных, хотя Thrift интерфейс также используется.
- Поток сообщений хранит события за последнюю неделю с возможностью указать момент времени с которого считывать данные при открытии соединения.
- Поддерживается абстракция "группы потребителей", которая позволяет группе клиентов вместе обрабатывать один поток данных вместе и независимо, то есть одно и то же сообщение не попадет дважды к клиентам из одной группы.
- ZooKeeper используется для периодического сохранения текущей позиции каждого клиента в потоке.
Новая архитектура Dashboard основана на принципе ячеек или ящиков входящих сообщений:
- Каждая "ячейка" отвечает за группу пользователей и читает новые события с шины сообщений, если один из её пользователей-подопечных подписан на автора только что опубликованного поста, то пост добавляется в "почтовый ящик" подписанного пользователя.
- Когда пользователь заходит в Dashboard его запрос попадает в его ячейку, которая возвращает ему нужную часть непрочитанных постов.
- Каждая ячейка состоит из трех групп серверов:
  - HBase для постоянного хранения копий постов и почтовых ящиков;
  - Redis для кэширование свежих данных;
  - Сервис, читающий данные из шины и предоставляющий доступ к ящикам посредством Thrift.
- В HBase используется две таблицы:
  - Отсортированный список идентификаторов постов для каждого пользователя в ячейке, именно в том виде, как они будут отображены в итоге.
  - Копии всех постов по идентификаторам, что позволяет выдать все данные для отрисовки Dashboard без обращений к серверам вне одной ячейки.
- Ячейки представляют собой независимые единицы, что позволяет легко масштабировать систему при росте числа пользователей.
- Платой за относительно безболезненность масштабирования является чрезвычайная избыточность данных: при том что ежедневно создается лишь 50Гб постов, суммарный объем данных в ячейках растет на 2.7Тб в день.
- Альтернативой было бы использование общего кластера со всеми постами, но тогда он бы стал единственной точкой отказа и потребовалось бы делать дополнительные удаленные запросы. Помимо этого выигрыш по объему был бы не велик - списки идентификаторов занимают значительно больше места, чем сами посты.
- Пользователи, которые подписаны или на которых подписаны миллионы других пользователей, обрабатываются отдельно - страницы с их постами генерируются не заранее (как описывалось выше), а при поступлении запроса - это позволяет не тратить впустую много ресурсов (этот подход называется выборочная материализация).
- Количество пользователей в одной ячейке позволяет управлять балансом между уровнем надежности и стоимостью содержания этой подсистемы.
- Параллельное чтение их шины сообщений оказывает серьезную нагрузку на сеть, в дальнейшем из ячеек можно будет составить иерархию: только часть будет читать напрямую из шины сообщений, а остальным сообщения будут ретранслироваться.
Tumblr географически по-прежнему находится в одном датацентре (если не считать незначительное присутствие в Rackspace), распределение по нескольким лишь в планах.

Развертывание

Начиналось как несколько rsync-скриптов для распространения PHP-приложения. Как только машин стало больше 200 такой подход стал занимать слишком много времени.
Следующий вариант был основан на Capistrano: были созданы три стадии процесса развертывания (разработка, тестирование, боевой). Неплохо справлялся с десятками серверов, но на сотнях также был слишком медленным, так как основывался на SSH.
Итоговый вариант основан на Func, решении от RedHat, позволившим заменить SSH на более легковесный протокол.

Разработка

Поначалу философия была такова, что каждый мог использовать любые технологии, которые считал уместным. Но довольно скоро пришлось стандартизировать стек технологий, чтобы было легче нанимать и вводить в работу новых сотрудников, а также для более оперативного решения технических проблем.
Каждый разработчик имеет одинаковую заранее настроенную рабочую станцию, которая обновляется посредством Puppet:
- Настроена публикация изменений, тестирование и развертывание новых версий.
- Разработчики используют vim и Textmate.
Новый PHP код систематически инспектируется другими разработчиками.
Внутренние сервисы подвергаются непрерывному тестированию посредством Jenkins.

Структура команд

Проект разбит на 6 команд:

Инфраструктура: все, что ниже 5 уровня по модели OSI - маршрутизация, TCP/IP, DNS, оборудование и.т.п.
Платформа: разработка основного приложения, партиционирование SQL, взаимодействие сервисов.
Надежность (SRE): сфокусирована на текущие потребности с точки зрения надежности и масштабируемости.
Сервисы: занимается более стратегической разработкой того, что понадобится через один-два месяца.
Эксплуатация: отвечает за обнаружение и реагирование на проблемы, плюс тонкая настройка.

Найм

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

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

Автоматизация - ключ к успеху крупного проекта.
При партиционировании MySQL может масштабироваться, но лишь при преобладании операций чтения.
Redis с отключенной персистентностью легко может заменить memcached.
Scala достойно себя проявляет в роли языка программирования для внутренних сервисов, во многом благодаря обширной Java-экосистеме.
Внедряйте новые технологии постепенно, поначалу работать с HBase и Redis было очень болезненно, они были включены в основной стек технологий только после испытаний в некритичных сервисах и подпроектах, где цена ошибки не так велика.
Проект должен строиться вокруг навыков его команды, а не наоборот.
Нужно нанимать людей только если они вписываются в команду и в состоянии довести работу до результата.
При выборе технологического стека одну из ключевых ролей играет доступность соответствующих специалистов на кадровом рынке.
Читайте публикации и статьи в блогах. Ключевые аспекты архитектуры, включая "ячейки" и частичную материализацию были позаимствованы из внешних источников.
Поспрашивайте своих коллег, кто-то из них мог общаться с специалистами из Facebook, Twitter, Google или LinkedIn - если нет прямого доступа, всегда можно получить нужную информацию через одно-два "рукопожатия".

Статья написана на основе интервью Blake Matheny, директора по разработке платформы Tumblr.

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

Иван Блинков — Fri, 18 Mar 2011 18:57:00 +0300

Dropbox - это самый простой способ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура Twitter. Два года спустя.

Иван Блинков — Sat, 05 Mar 2011 20:47:00 +0300

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

Статистика

3 год, 2 месяца и 1 день потребовалось Twitter, чтобы набрать 1 миллиард твитов
На сегодняшний день, чтобы отправить миллиард твитов пользователям нужна всего одна неделя
752% рост аудитории за 2008 год
1358% рост аудитории за 2009 год (без учета API, по данным comScore)
175 миллионов зарегистрированных пользователей на сентябрь 2010 года
460 тысяч регистраций пользователей в день
9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
50 миллионов твитов в день год назад, 140 миллионов твитов в день месяц назад, 177 миллионов твитов в день на 11 марта 2011г.
Рекорд по количеству твитов за секунду 6939, установлен через минуту после того, как Новый Год 2011 наступил в Японии
600 миллионов поисков в день
Лишь 25% трафика приходится на веб сайт, остальное идет через API
Росто числа мобильных пользователей за последний год 182%
6 миллиардов запросов к API в день, около 70 тысяч в секунду
8, 29, 130, 350, 400 - это количество сотрудников Twitter на январь 2008, январь 2009, январь 2010, январь и март 2011, соответственно

Самая свежая статистика про Twitter.

Платформа

Сравните с аналогичным разделом предыдущей статьи о Twitter - увидите много новых лиц, подробнее ниже.

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

Сервера расположены в NTT America
Никаких облаков и виртуализации, существующие решения страдают слишком высокими задержками
Более тысячи серверов
Планируется переезд в собственный датацентр

Что такое твит?

Сообщение длиной до 140 символов + метаданные
Типичные запросы:
- по идентификатору
- по автору
- по @упоминаниям пользователей

Архитектура

Unicorn

Сервер приложений для Rails:

Развертывание новых версий кода без простоя
На 30% меньше расход вычислительных ресурсов и оперативной памяти, по сравнению с другими решениями
Перешли с mod_proxy_balancer на mod_proxy_pass

Rails

Используется в основном для генерации страниц, работа за сценой реализована на чистом Ruby или Scala.

Столкнулись со следующими проблемами:

Проблемы с кэшированием, особенно по части инвалидации
ActiveRecord генерирует не самые удачные SQL-запросы, что замедляло время отклика
Высокие задержки в очереди и при репликации

memcached

memcached не идеален. Twitter начал сталкиваться с Segmentation Fault в нем очень рано.
Большинство стратегий кэширования основываются на длинных TTL (более минуты).
Вытеснение данных делает его непригодным для важных конфигурационных данных (например флагов "темного режима", о котором пойдет речь ниже).
Разбивается на несколько пулов для улучшения производительности и снижения риска вытеснения.
Оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached + FNV hash, вместо чистого Ruby и md5.
Twitter является одним их наиболее активных проектов, участвующих в разработке libmemcached.

MySQL

Разбиение больших объемов данных является тяжелой задачей.
Задержки в репликации и вытеснение данных из кэша является причиной нарушения целостности данных с точки зрения конечного пользователя.
Блокировки создают борьбу за ресурсы для популярных данных.
Репликация однопоточна и происходит недостаточно быстро.
Данные социальных сетей плохо подходят для реляционных СУБД:
- NxN отношения, социальный граф и обход деревьев - не самые подходящие задачи для таких баз данных
- Проблемы с дисковой подсистемой (выбор файловой системы, noatime, алгоритм планирования)
- ACID практически не требуется
- Для очередей также практически непригодны
Twitter сталкивался с большими проблемами касательно таблиц пользователей и их статусов
Читать данные с мастера при Master/Slave репликации = медленная смерть

FlockDB

Масштабируемое хранилище для данных социального графа:

Разбиение данных через Gizzard
Множество серверов MySQL в качестве низлежащей системы хранения
В Twitter содержит 13 миллиардов ребер графа и обеспечивает 20 тысяч операций записи и 100 тысяч операций чтения в секунду
Грани хранятся и индексируются в обоих направлениях
Поддерживает распределенный подсчет количества строк
Open source!

Среднее время на выполнение операций:

Подсчет количества строк: 1мс
Временные запросы: 2мс
Запись: 1мс для журнала, 16мс для надежной записи
Обход дерева: 100 граней/мс

Подробнее про эволюцию систем хранения данных в Twitter в презентации Nick Kallen.

Cassandra

Распределенная система хранения данных, ориентированная на работу в реальном времени:

Изначально разработана в Facebook
Очень высокая производительность на запись
Из слабых сторон: высокая задержка при случайном доступе
Децентрализованная, способна переносить сбои оборудования
Гибкая схема данных
~~Планируется полный переход на нее по следующему алгоритму:~~
- ~~Все твиты пишутся и в Cassandra и в MySQL~~
- ~~Динамически часть операций чтения переводится на Cassandra~~
- ~~Анализируется реакция системы, что сломалось~~
- ~~Полностью отключаем чтение из Cassandra, чиним неисправности~~
- ~~Начинаем сначала~~
Обновление: стратегия по поводу использования Cassandra изменилась, попытки использовать её в роли основного хранилища для твитов прекратились, но она продолжает использоваться для аналитики и географической информации.

Подробнее почему Twitter пришел к решению использовать Cassandra можно прочитать в отдельной презентации.

Помимо всего прочего Cassandra ~~планируется использовать~~ используется для аналитики в реальном времени.

Scribe

Пользователи Twitter генерируют огромное количество данных, около 15-25 Гб в минуту, более 12 Тб в день, и эта цифра удваивается несколько раз в год.

Изначально для сбора логов использовали syslog-ng, но он очень быстро перестал справляться с нагрузкой.

Решение нашлось очень просто: Facebook столкнулся с аналогичной проблемой и разработал проект Scribe, который был опубликован в opensource.

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

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

Поддерживаются различные системы для записи в данным, в том числе обычные файлы и HDFS (о ней ниже).

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

Hadoop

Как Вы обычно сохраняете 12Тб новых данных, поступающих каждый день?

Если считать, что средняя скорость записи современного жесткого диска составляет 80Мбайт в секунду, запись 12Тб данных заняла бы почти 48 часов.

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

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

Hadoop Distributed File System (HDFS) предоставляет возможность автоматической репликации и помогает справляться со сбоями оборудования.

MapReduce framework позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение.

Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter:

Вычисление связей дружбы в социальном графе (grep и awk не справились бы, self join в MySQL на таблицах с миллиардами строк - тоже)
Подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 миллиардах записей)
Подсчет PageRank между пользователями для вычисления репутации.

В твиттер используется бесплатный дистрибутив от Cloudera, версия Hadoop 0.20.1, данные храняться в сжатом по алгоритму LZO виде, библиотеки для работы с данными опубликованы под названием elephant-bird.

Pig

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

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

Немного напоминает SQL, но намного проще. Это позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce работ. Большая часть работы по анализу данных в Twitter осуществляется с помощью Pig.

Данные

Полу-структурированные данные:

логи Apache, RoR, MySQL, A/B тестирования, процесса регистрации
поисковые запросы

Структурированные данные:

Твиты
Пользователи
Блок-листы
Номера телефонов
Любимые твиты
Сохраненные поиски
Ретвиты
Авторизации
Подписки
Сторонние клиенты
География

Запутанные данные:

Социальный граф

Что же они делают с этим всем?

Подсчет математического ожидания, минимума, максимума и дисперсии следующих показателей:
- Количество запросов за сутки
- Средняя задержка, 95% задержка
- Распределение кодов HTTP-ответов (по часам)
- Количество поисков осуществляется каждый день
- Количество уникальных запросов и пользователей
- Географическое распределение запросов и пользователей
Подсчет вероятности, ковариации, влияния:
- Как отличается использование через мобильные устройства?
- Как влияет использование клиентов сторонних разработчиков?
- Когортный анализ
- Проблемы с сайтом (киты и роботы, подробнее ниже)
- Какие функциональные возможности цепляют пользователей?
- Какие функциональные возможности чаще используются популярными пользователями?
- Корректировка и предложение поисковых запросов
- A/B тестирование
Предсказания, анализ графов, естественные языки:
- Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
- Какая структура графа ведет к успешным популярным сетям
- Пользовательская репутация
- Анализ эмоциональной окраски
- Какие особенности заставляют людей ретвитнуть твит?
- Что влияет на глубину дерева ретвитов ?
- Долгосрочное обнаружение дубликатов
- Машинное обучение
- Обнаружения языка

Подробнее про обработку данных в презентации Kevin Weil.

HBase

Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:

HBase используется как изменяемая прослойка над HDFS
Данные экспортируются из HBase c помощью периодической MapReduce работы:
- На этапе Map используются также данные из FlockDB и нескольких внутренних сервисов
- Собственная схема разбиения данных
- Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala (подробнее о построении распределенных сервисов на Scala)

На основе HBase разрабатываются и другие продукты внутри Twitter.

Основными её достоинствами являются гибкость и легкая интеграция с Hadoop и Pig.

По сравнению с Cassandra:

"Их происхождение объясняет их сильные и слабые стороны"
HBase построен на основе системы по пакетной обработке данных, высокие задержки, работает далеко не в реальном времени
Cassandra построена с нуля для работы с низкими задержками
HBase легко использовать при анализе данных как источник или место сохранения результатов, Cassandra для этого подходит меньше, но они работают над этим
HBase на данный момент единственную точку отказа в виде мастер-узла
В твиттере HBase используется для аналитики, анализа и создания наборов данных, а Cassandra - для онлайн систем

Loony

Централизованная система управления оборудованием.

Реализована с использованием:

Python
Django
MySQL
Paraminko (реализация протокола SSH на Python, разработана и опубликована в opensource в Twitter)

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

Murder

Система развертывания кода и ПО, основанная на протоколе BitTorrent.

Благодаря своей P2P природе позволяет обновить более тысячи серверов за 30-60 секунд.

Kestrel

Распределенная очередь, работающая по протоколу memcache:

set - поставить в очередь
get - взять из очереди

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

Отсутствие строгого порядка выполнения заданий
Отсутствие общего состояния между серверами
Разработана на Scala

Daemon'ы

Каждый твит обрабатывается с помощью daemon'ов.

В unicorn обрабатываются только HTTP запросы, вся работа за сценой реализована в виде отдельных daemon'ов.

Раньше использовалось много разных демонов, по одному на каждую задачу (Rails), но перешли к меньшему их количеству, способному решать несколько задач одновременно.

Как они справляются с такими темпами роста?

Рецепт прост, но эффективен, подходит практически для любого интернет-проекта:

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

На словах звучит и правда примитивно, но на практике нужно предпринять ряд мер, чтобы такой подход был бы реализуем:

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

Примерами агрегированных метрик в Twitter являются "киты" и "роботы", вернее их количество в единицу времени.

Что такое "робот"?

Ошибка внутри Rails (HTTP 500)
Непойманное исключение
Проблема в коде или нулевой результат

Что такое "кит"?

HTTP ошибка 502 или 503
В твиттер используется фиксированный таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах)
Убитый слишком длинный запрос к базе данных (mkill)

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

Реализован этот механизм простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения. Подробнее про работу команды оперативного реагирования в презентации John Adams.

"Темный режим"

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

Имеется около 60 выключателей, в том числе и полный режим "только для чтения".

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

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

Не бросайте систему на самотек, начинайте собирать метрики и их визуализировать как можно раньше
Заранее планируйте рост требуемых ресурсов и свои действия в случае экстренных ситуаций
Кэшируйте по максимуму все, что возможно
Все инженерные решения не вечны, ни одно из решений не идеально, но многие будут нормально работать в течение какого-то периода времени
Заранее начинайте задумываться о плане масштабирования
Не полагайтесь полностью на memcached и базу данных - они могут Вас подвести в самый неподходящий момент
Все данные для запросов в реальном времени должны находиться в памяти, диски в основном для записи
Убивайте медленные запросы (mkill) прежде, чем они убьют всю систему
Некоторые задачи могут решаться путем предварительного подсчета и анализа, но далеко не все
Приближайте вычисления к данным по возможности
Используйте не mongrel, а unicorn для RoR

Спасибо за внимание, жду Вас снова! Буду рад, если Вы подпишитесь на меня в Twitter, с удовольствием пообщаюсь со всеми читателями :)

Архитектура 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.

Архитектура Вконтакте

Иван Блинков — Thu, 28 Oct 2010 21:12:00 +0400

Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте, в том числе и техническим. Спешу поделиться своим взглядом на архитектуру проекта по результатам данного выступления.

Платформа

Debian Linux - основная операционная система
nginx - балансировка нагрузки
PHP + XCache
Apache + mod_php
memcached
MySQL
Собственная СУБД на C, созданная "лучшими умами" России
node.js - прослойка для реализации XMPP, живет за HAProxy
Изображения отдаются просто с файловой системы xfs
ffmpeg - конвертирование видео

Статистика

95 миллионов учетных записей
40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
11 миллиардов запросов в день
200 миллионов личных сообщений в день
Видеопоток достигает 160Гбит/с
Более 10 тысяч серверов, из которых только 32 - фронтенды на nginx (количество серверов с Apache неизвестно)
30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
Каждый день выходит из строя около 10 жестких дисков

Архитектура

Общие принципы

Cервера многофункциональны и используются одновременно в нескольких ролях:
- Перебрасывание полуавтоматическое
- Требуется перезапускать daemon'ы
Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие - использование собственной СУБД вместо MySQL
При балансировке нагрузки используются:
- Взвешенный round robin внутри системы
- Разные сервера для разных типов запросов
- Балансировка на уровне ДНС на 32 IP-адреса
Большая часть внутреннего софта написано самостоятельно, в том числе:
- Собственная СУБД (см. ниже)
- Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс :) )
- Автоматическая система тестирования кода
- Анализаторы статистики и логов
Мощные сервера:
- 8-ядерные процессоры Intel (по два на сервер, видимо)
- 64Гб оперативной памяти
- 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
- RAID не используется
- Не брендированные
Вычислительные мощности серверов используются менее, чем на 20%
Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
- Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
- В Московских датацентрах только аудио и видео
- В планах сделать репликацию базы данных в другой датацентр в ленинградской области
CDN на данный момент не используется, но в планах есть
Резервное копирование данных происходит ежедневно и инкрементально

Волшебная база данных на C

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

Разработана "лучшими умами" России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих "героев" Вконтакте (писал на слух и возможно не всех успел, так что извиняйте):
- Андрей Лопатин
- Николай Дуров
- Арсений Смирнов
- Алексей Левин
Используется в огромном количестве сервисов:
- Личные сообщения
- Сообщения на стенах
- Статусы
- Поиск
- Приватность
- Списки друзей
Нереляционная модель данных
Большинство операций осуществляется в оперативной памяти
Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
Кластеризация осуществляется легко
Есть репликация
Если честно, я так и не понял зачем им MySQL с такой штукой - возможно просто как legacy живет со старых времен

Аудио и видео

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

1000-1500 серверов используется для перекодирования видео, на них же оно и хранится.

XMPP

Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.

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

Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
Работа с большими контакт-листами - у многих пользователей количество друзей на Вконтакте измеряется сотнями и тысячами
Высокая активность смены статусов - люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
Аватарки передаются в base64
Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
60-80 тысяч человек онлайн, в пике - 150 тысяч
HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
Данные хранятся в MySQL (думали о MongoDB, но передумали)
Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код наnode.js (по 4 процесса на сервер), а на трех самых мощных - еще и MySQL
В node.js большие проблемы с использованием OpenSSL, а также течет память
Группы друзей в XMPP не связаны с группами друзей на сайте - сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся

Интеграция со внешними ресурсами

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

Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
Кнопка "поделиться с друзьями", поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

Интересные факты не по теме

Процесс разработки близок к Agile, с недельными итерациями
Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian
Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
Есть много доработок над memcached, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия
Фотографии не удаляются для минимизации фрагментации
Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на них и на реализовавшем его разработчике
Павел Дуров откладывал деньги на хостинг с 1 курса :)

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

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, например, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта "круглого стола Вконтакте", так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.

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

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

Иван Блинков — Wed, 20 Oct 2010 13:02:00 +0400

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

Платформа

Linux - операционная система
PHP с HipHop - код на PHP компилируется в C++
memcached - агрессивное кэширование объектов
MySQL - используется как хранилище пар ключ-значение, никаких join'ов
Thrift - интерфейс взаимодействия между сервисами, написанными на разных языках программирования
Scribe - универсальная система сбора и агрегации данных с рабочих серверов

Статистика

Более 500 миллионов активных пользователей (месячная аудитория)
Более миллиарда социальных связей
Более 200 миллиардов просмотров страниц в месяц
Более 4 триллионов действий попадает в новостные ленты каждый день
Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше
Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно
Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду
20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых
О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно
Более миллиарда сообщений в чате каждый день
Более ста миллионов поисковых запросов в день
Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect
Более 400 тысяч разработчиков сторонних приложений
Менее 500 разработчиков и системных администраторов в штате
Более миллиона активных пользователей на одного инженера
Десятки тысяч серверов, десятки гигабит трафика

Архитектура

Общие принципы

Балансировщик нагрузки выбирает веб-сервер для обработки запроса
PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:
- MySQL
- memcached
- Специализированные сервисы
Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
- Вер-приложение
- Распределенный индекс
- Постоянное хранилище
Использование открытых технологий там, где это возможно
Поиск возможностей оптимизации используемых продуктов
Философия Unix:
- Старайтесь делать каждый компонент системы простым и производительным
- Комбинируйте компоненты для решения задач
- Концентрируйте внимание на хорошо обозначенных точках взаимодействия
Все усилия направлены на масштабируемость
Попытки минимизации количества точек отказа
Простота, простота, простота!

PHP

Почему PHP?

Во многом "так исторически сложилось"
Хорошо подходит для веб-разработки
Легок в изучении: небольшой набор выражений и языковых конструкций
Легок в написании: нестрогая типизация и универсальный "массив"
Легок в чтении: синтаксис похож на C++ и Java
Прост в дебаггинге: нет необходимости в перекомпиляции
Большой ассортимент библиотек, актуальных для веб-проектов
Подходит для процесса разработки с короткими итерациями
Активное сообщество разработчиков по всему миру
Динамическая типизация, интерпретируемый язык для скриптов

Как оказалось на самом деле?

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

Доработки:

Оптимизация байт-кода
Улучшения в APC (ленивая загрузка, оптимизация блокировок, "подогрев" кэша)
Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)
HipHop - трансформатор исходных кодов:
- Разработчики пишут на PHP, который конвертируется в оптимизированный C++
- Статический анализ, определение типов данных, генерация кода, и.т.д.
- Облегчает разработку расширений
- Существенно сокращает расходы оперативной памяти и вычислительных ресурсов
- У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка
- Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля

MySQL

Как используется MySQL?

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

Как оказалось на самом деле?

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

Доработки:

Практически никаких модификаций исходного кода MySQL
Своя схема партиционирования с глобально-уникальными идентификаторами
Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя
Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша
Библиотеки для доступа к данным на основе графа:
- Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)
- Реплицированные связи (ребра графа)
- Аналоги распределенных внешних ключей (foreign keys)
- Большинство данных распределено случайно

Memcache

Как используется memcached?

Высокопроизводительная распределенная хэш-таблица
Содержит "горячие" данные из MySQL
Снижает нагрузку на уровень баз данных
Основная форма кэширования
Используется более 25TB памяти на нескольких тысячах серверов
Среднее время отклика менее 250 микро-секунд
Кэшируются сериализованные структуры данных PHP
Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL - приходится делать это на уровне программного кода
Множество multi-get запросов для получения данных на другом конце ребер графа
Ограниченная модель данных, неэффективен для маленьких объектов

Доработки:

Порт на 64-битную архитектуру
Более эффективная сериализация
Многопоточность
Улучшенный протокол
Компрессия
Проксирование запросов
Доступ к memcache через UDP:
- уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений
- управление ходом исполнения приложение (оптимизация для multi-get)
Статистика о работе потоков по запросу - уменьшает блокировки
Ряд изменений в ядре Linux для оптимизации работы memcache:
- распределение управления сетевыми прерывания по всем ядрам
- оппортунистический опрос сетевых интерфейсов
После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений

Thrift

Что это?

Легкий механизм построения приложений с использованием нескольких языков программирования
Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.
Предоставляет язык описания интерфейсов, статический генератор кода
Поддерживаемые языки: C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell и многие другие
Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)
Протоколы: стандарты сериализации (бинарный, JSON)
Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные

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

Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers - но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию
Он быстрый, очень быстрый
Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы
Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями
Общий инструментарий, знакомый всем разработчикам

Scribe

Что это?

Масштабированный распределенный механизм ведения логов
Перемещает данные с серверов в центральный репозиторий
Широкая сфера применения:
- Логи поисковых запросов
- Публикации в новостных лентах
- Данные по A/B тестированиям
Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных
Простая модель данных
Построен на основе Thrift

Хранение фотографий

Сначала сделали это просто:

Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
Загрузка с сервера: изображения отдаются из NFS через HTTP
NFS построена на коммерческих продуктах
Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
На самом деле оказалось, что:
- Файловые системы непригодны для работы с большим количеством небольших файлов
- Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
- Ограничивающим фактором является ввод-вывод, а не плотность хранения

Потом начали оптимизировать:

Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
Распределение их по CDN для уменьшения сетевых задержек
Возможно сделать еще лучше:
- Хранение изображений в больших бинарных файлах (blob)
- Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
- Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее "простого" подхода и в 3 раза эффективнее "оптимизированного"

Другие сервисы

SMC: консоль управления сервисами - централизованная конфигурация, определение на какой физической машине работает логический сервис
ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
И еще около 50 других сервисов...

Как это работает все вместе?

Новые альбомы друзей

Получаем профиль по идентификатору пользователя (скорее всего из кэша, но потенциально возможно обращение к базе данных)
Получаем список друзей (опять же на основе идентификатора пользователя из кэша или из базы данных в случае промаха)
Параллельно запрашиваем идентификаторы последних 10 альбомов для каждого из друзей (multi-get, каждый промах мимо кэша индивидуально вытаскивается из MySQL)
Параллельно получаем данные о всех альбомах (на основе идентификаторов альбомов из предыдущего шага)
Все данные получены, выполняем логику отрисовки конкретной страницы на PHP
Отправляем HTML в браузер, пользователь счастлив :)

Новостная лента

Поиск

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

LAMP не идеален

PHP+MySQL+Memcache решает большинство задач, но не может решить совсем все:
- PHP не может хранить состояния
- PHP не самый производительный язык
- Все данные находятся удаленно
Facebook разрабатывает собственные внутренние сервисы, чтобы:
- Располагать исполняемый код ближе к данным
- Скомпилированное окружение более эффективно
- Некоторая функциональность присутствует только в других языках программирования
Философия сервисов:
- Создание сервисов только при необходимости (минимизация издержек по развертке, поддержке и ведению отдельной кодовой базы; потенциальная дополнительная точка сбоя)
- Создание общего набора инструментов для создания сервисов (Thrift, Scribe, ODS, средства мониторинга и уведомлений)
- Использование правильных языка программирования, библиотек и инструментов для решения задачи
Возвращение инноваций общественности - важный аспект разработки в Facebook:
- Опубликованные свои проекты:
  - Thrift
  - Scribe
  - Tornado
  - Cassandra
  - Varnish
  - Hive
  - xhprof
- Доработки популярных решений:
  - PHP
  - MySQL
  - memcached
- Информация о взаимодействии Facebook с opensource-сообществом, этих и других проектах расположена на странице, посвященной opensource.
Ключевые моменты культуры разработки в Facebook:
- Двигайся быстро и не бойся ломать некоторые вещи
- Большое влияние маленьких команд
- Будь откровенным и инновационным

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

Данная статья не является переводом готовой статьи, в качестве источников информации послужили записи выступлений сотрудников Facebook на конференциях:

Очень рекомендую посмотреть материалы в оригинале, так как естественно я осветил в статье далеко не все, да и неточности какие-либо неисключены. Помимо этого возможно многим будет интересно мероприятие "Facebook: how we scaled to 500 000 000 users ", где Robert Johnson выступает 22 октября в Москве. Еще он числится в списке докладчиков Highload++ с аналогичным выступлением. Дополнительную информацию можно почерпнуть в блоге инженеров Facebook.

UPD: Обновил некоторые моменты после посещения вышеупомянутого выступления Роберта.

И по традиции напоминаю, что так как я пишу довольно редко - читать мой блог намного удобнее по RSS. Спасибо за внимание :)

Как проект Ravelry дорос до 10 миллионов запросов с помощью Rails

Иван Блинков — Thu, 24 Sep 2009 11:31:00 +0400

Данная статься основана на замечательном интервью, взятом Tim Bray у Casey Forbes, создателя Ravelry, сайта на Ruby on Rails, поддерживаемое сообществом вязальщиц и специалистов по вышивке крючком численностью более 400000 человек.

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

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

Сейчас Casey и еще несколько сотрудников живут за счет Ravelry. Не это ли является мечтой любого предприятия малого бизнеса? Хотите узнать как и Вы могли бы достичь подобных успехов? Данный текст является переводом статьи How Ravelry Scales to 10 Million Requests Using Rails, автор оригинала - Todd Hoff.

Статистика

10 миллионов запросов ежедневно обрабатывается Rails (AJAX + RSS + API)
3.6 миллиона просмотров страниц ежедневно
430,000 зарегистрированных пользователей. 70,000 активно пользуются сайтом ежедневно. 900 новых пользователей регистрируется ежедневно.
2.3 миллиона проектов по вязанию, 50000 новых сообщений на форуме ежедневно, всего 19 миллионов сообщений на форуме, 13 миллионов сообщений, 8 миллионов фотографий (большая часть размещена на Flickr).
Проект начинался на небольшом VPS, но потребности в ресурсах очень быстро вышли за его возможности.
Монетизация: рекламодатели + магазин соответствующей продукции + продажа узоров

Platform

Ruby on Rails (1.8.6, Ruby GC патчи)
Percona сборка MySQL
Gentoo Linux
Servers: Silicon Mechanics (не арендуемые, в их собственности)
Хостинг: Colocation от Hosted Solutions
Интернет-канал: Cogent (очень дешево)
Capistrano для развертывания
Nginx существенно более быстрый и менее требовательный к оперативной памяти по сравнению с Apache
Xen для виртуализации
HAproxy для балансировки нагрузки
Munin для мониторинга
Tokyo Cabinet / Tokyo Tyrant для кеширования больших объектов
Nagios для предупреждений
HopToad для уведомлений об исключительных ситуациях.
NewRelic для тонкой настройки
Syslog-ng для агрегации логов
S3 для хранения данных
Cloudfront в роли CDN
Sphinx для текстового поиска
Memcached для кеширования маленьких объектов

Архитектура

7 серверов (Gentoo Linux). Средствами виртуализации (Xen) создано 13 виртуальных серверов:
- Для обработки пользовательских запросов используются Nginx и Haproxy. Запросы проходят следущую цепочку: nginx -> haproxy -> apache + mod_passenger.
- Один небольшой сервер для резервного копирования данных.
- Один небольшой вспомогательный сервер для некритичных процессов и тестирования новых версий.
- 2 сервера с 32 GB оперативной памяти для master+slave баз данных, а также поисковой системы Sphinx.
- 3 сервера приложений, состоящих из 6 Apache Passenger и запущенных экземпляров Ruby, каждый ограничен 20-ю потоками. Суммарно 6 четырехядерных процессоров и 40 GB оперативной памяти. Часть оперативной памяти большую часть времени простаивает.
5 терабайт данных располагается в Amazon S3. Cloudfront используется как CDN.
Tokyo Cabinet/Tyrant используется вместо memcached в некоторых местах для кеширования более крупных объектов, в частности уже размеченного текста в HTML.
HAproxy и Capistrano используются для вывода новых версий сайта без негативного влияния на производительность и работу пользователей.

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

Позвольте своим пользователям работать над Вашим сайтом за Вас. Проводите итерации и развивайтесь. Начните с чего-то, что просто работает, и позвольте людям начать пользоваться продуктом, развивать проект совместно с пользователями намного проще. Не торопясь развивайте бета-версию своего проекта. Также медленно приглашайте новых людей. Старайтесь ежедневно обсуждать с пользователями что бы они хотели увидеть нового в проекте. Разрешите им оказывать помощь в развитии проекта и результат станет существенно более обнадеживающим, утешительным, интуитивно-понятным и эффективным.
Позвольте пользователям спонсировать Ваш проект. Ravelry частично был создан за счет его пользователей, которые пожертвовали в пользу проекта более 71 тысячи долларов. Эти средства были переданы проекту просто как дар, а не в обмен на акции. Не недооценивайте значимость капитала компании. Ravelry потребовалось 6 месяцев непрерывной работы и экономии на издержках, связанных с серверным оборудованием и каналами связи, чтобы наконец-то начать получать прибыль, и полученные от пользователей средства оказались основным фактором, позволившим проекту пережить этот тяжелый период. Залогом их успеха является поддержание интереса и искры в глазах своих пользователей, подталкивание пользователей к оказанию помощи и поддержки проекту. Для этого требуется любовь к своему делу и самоотдача.
Станьте центром выбранной ниши. Найдите нишу на рынке с недостаточным предложением. Не стремитесь к массовым рынкам. Совсем не обязательно делать что-то для многих миллионов людей. Миллионы скорее всего просто зевнут от скуки и в скором времени о Вас забудут. Лучше создайте что-нибудь очень полезное для небольшой заинтересованной группы лиц и их страсть к их интересам перейдет и к Вам.
Успех не обязательно должен быть связан с масштабностью проекта, намного большее значение имеет стабильная и качественная реализация © Jeff Putz.
Основная проблема в базе данных. Практически вся работа, относящаяся к масштабируемости/настройке/производительности, так или иначе связана с базой данных. Например, изменение схемы данных для больших таблиц в MySQL всегда связано с рядом проблем, особенно если простой сервиса неприемлем. Еще один аргумент в пользу баз данных, не имеющих схем данных.
Продолжайте получать удовольствие. Casey перешел на Ruby on Rails так как ему хотелось снова заняться программированием с энтузиазмом. Этот факт стал одним из основных факторов, которые помогли сделать проект успешным.
Придумывайте новые вещи, которые будут приводить в восторг Ваших пользователей. Воспользуйтесь магией, людям это нравится. Это тоже один из принципов данного проекта. Например по этой ссылке, можно почитать об использовании очень инновационных подходов к управлению форумами.
Ruby — это круто. Он представляет собой интересный язык программирования, позволивший Ravelry быстро пройти стадию изначальной разработки и выпускать новые версии дважды в день в период бета-тестирования.
Получайте большую прибыль за счет минимизации издержек. У Ravelry есть свой магазин с соответствующей тематике продукцией, оптовые счета, принтеры и реализующая компания. Это позволяет им поддерживать издержки на низком уровне, таким образом их прибыль не уходит сторонним компаниям вроде CafePress.
Наиболее сложный переход заключается в переходе от одного сервера к нескольким. В этом процессе все меняется и становится более сложным и комплексным. Всегда имейте этот переход ввиду, когда планируете архитектуру веб-приложения.
В сегодняшней экосистеме имеется возможность делать массу различных вещей даже обладая минимумом ресурсов. Для создания комплексного сайта вроде Ravelry больше не нужно много людей или финансов. Взгляните на список различных программ, используемых в Ravelry, а также на небольшое количество людей, работающих над поддержанием работы проекта.

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

Архитектура 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 - сейчас самое время!

Архитектура 37signals

Иван Блинков — Thu, 05 Jun 2008 18:49:00 +0400

37signals больше всего известны благодаря выпуску в свет Ruby on Rails грамотному его использованию для запуска их очень популярных продуктов: Basecamp, Highrise, Backpack и Campfire. RoR как обычно пытаются винить во всех проблемах с производительностью, но 37signals казалось бы справляется с большой нагрузкой, используя вполне разумное количество вычислительных ресурсов.

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

Этот текст является переводом статьи, автор - Todd Hoff. Извиняюсь за не сильно оригинальный контент (да и, как выяснилось, практически не технической направленности), но на написание своих полноценных текстов у меня последнее время все никак не хватает то креатива, то времени :( .

Платформа

Ruby on Rails
Memcached
Xen
MySQL
Amazon S3 для хранения изображений

Статистика

30 серверов: от простых однопроцессорных файловых серверов до восьмипроцессорных серверов приложений, в сумме около 100 процессоров и 200 GB оперативной памяти.
В планах диагональное масштабирование: уменьшение количества серверов до 16, но более производительных - в сумме 92 процессоров и 230 GB RAM.
Виртуализация средствами Xen для более гибкого управления системой.
Basecamp (управление проектами):
- 2000000 пользователей с учетными записями
- 13200000 задач
- 9200000 сообщений
- 12200000 комментариев
- 5500000 записей о распределении времени
Backpack (управление информацией для личного использования и малого бизнеса):
- Около миллиона страниц
- 6800000 задач
- 1500000 записей
- 829000 фотографий
- 370000 файлов
Общая статистика проектов (на ноябрь 2007 г.):
- 5.9 TB загруженных пользователями данных
- 888 GB загружено (upload)
- 2 TB скачано (download)

Архитектура

Кэширование средствами memcached уже используется, но они ищут способы более активно его применять. Позволяет достичь впечатляющих результатов в плане производительности.
Методы для составления URL используются вместо ручного их составления.
Используются стандартные ActiveRecord запросы, но при необходимости они используют и ручную настройку.
Иногда они дорабатывают Rails, если сталкиваются с проблемами с производительностью.
Amazon S3 используется для хранения данных, загруженных пользователями. Разработчики очень довольны результатами.

Работа с кредитными картами

Ежемесячное выписывание счетов. Это позволяет компаниям, занимающимся кредитными картами, чувствовать себя более комфортно, так как им не придется столкнуться с огромным количеством работы, если ваша фирма вдруг выйдет из бизнеса. Пользователям такой подход также по душе, так как издержки в итоге оказываются относительно невелики, а также не требуется подписание контракта, имеется возможность пользоваться сервисами необходимый промежуток времени и оплачивать именно ту сумму, которую потратили.
Получение учетной записи продавца услуг. Кто-то определенно должен обрабатывать операции с кредитными картами. Они используют Chase Bank. Воспользуйтесь услугами кого-нибудь, кому вы доверяете, а когда масштаб ваших сделок станет существенным - будет возможность получить более выгодные условия контракта.
Они используют authorize.net в роли шлюза для процессинга операций с кредитными картами.
Ежемесячным выписыванием счетов занимается специально написанная для этого проекта система. Она запускается каждую ночь, отправляет счета нужным людям и записывает результаты выполненных операций.
В случае успеха счет-фактура высылается по электронной почте.
В случае каких-либо сбоев - пользователю отправляется объяснение причин.
Если три раза с помощью кредитной карты не удается оплатить счет - учетная запись замораживается до тех пор, пока не будет предоставлен платежеспособный номер кредитной карты.
Обработка ошибок является критичным моментом, так как проблемы с оплатой возникают достаточно часто.
Все продукты конвертируются для использования централизованным биллинговым сервисом.
Необходимо быть совместимыми с PCI DSS (Payment Card Industry Data Security Standard).
Пользуйтесь услугами шлюзов, это позволит не хранить номера кредитных карт на своем сайте, что сильно упрощает жизнь в плане безопасности. Некоторые из них предоставляют и биллинговые услуги, что позволяет также не заниматься этим самостоятельно.

Поддержка пользователей

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

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

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

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

Иван Блинков — Sat, 10 May 2008 12:36:00 +0400

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

Поначалу все винили Ruby on Rails во всех проблемах с масштабированием, но Blaine Cook, главный архитектор Twitter, встал на его защиту:

Основной для нас на самом деле является проблема горизонтального масштабирования, с этой точки зрения Ruby on Rails ничем не хуже других языков программирования или framework'ов: переход на "более быстрый" язык программирования дал бы нам 10-20% прирост производительности, в то время архитектурные преобразования, легко реализованные средствами Ruby on Rails, сделали Twitter быстрее на 10000%.

Даже если Ruby on Rails оказался невиновен, как же тогда Twitter научился с его помощью рости до все больших и больших высот?

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

Этот текст является продолжением серии переводов, автор оригинала - Todd Hoff. На этот раз написать что-либо своими силами у меня не сложилось, все мысли ушли на другой пост, который я скоро опубликую, а перевод этот получился несколько менее строгим, чем обычно, но я думаю ничего страшного.

Scaling Twitter Video от Blaine Cook.
Scaling Twitter Slides
Good News блог пост от Rick Denatale
Scaling Twitter блог пост от Patrick Joyce
Twitter API Traffic is 10x Twitter’s Site
A Small Talk on Getting Big. Scaling a Rails App & all that Jazz

Платформа

Статистика

Более 350000 пользователей. Точная цифра, как обычно, держится в секрете.
Около 600 запросов в секунду.
В среднем система поддерживает 200-300 соединений в секунду. Максимум обычно достигается при значении 800.
MySQL обрабатывает примерно 2400 запросов в секунду.
180 экземпляров приложений на Rails, использующих Mongrel как веб-сервер.
1 MySQL сервер (одна большая машина с 8 ядрами) и 1 slave, используемый лишь для статистики и отчетов.
30+ процессов для выполнения произвольных работ.
8 Sun X4100
Обработка запроса обычно занимает у Rails 200 миллисекунд.
В среднем ответ на запрос к базе данных занимает 50-100 миллисекунд.
Более 16 GB выделено под memcached.

Архитектура

Проект столкнулся с массой проблем, связанных с масштабируемостью. Маленькая птичка частенько давала сбои.
Изначально не было реализовано никаких форм мониторинга, графиков или статистики, это очень затрудняло обнаружение м решение возникающих проблем. Впоследствии были внедрены Munin и Nagios. Разработчики столкнулись с некоторыми трудностями при использовании этих продуктов в Solaris. Помимо этого был использован сервис Google Analytics, но от него обычно мало толку, особенно когда страницы даже не загружаются.
Активное использование кэширования средствами memcached:
- Например, если подсчет количества чего-либо выполняется медленно, намного эффективнее один раз запомнить результат в memcached, чем каждый раз считать его заново.
- Получение информации о статусе своих друзей - непростая задача. Вместо использования запросов информация о статусе друзей обновляется в кэше. База данных совсем не используется. Такой подход позволяет получить предсказуемое время отклика (ограниченное сверху примерно 20 миллисекундами).
- Объекты ActiveRecord настолько велики, что кэширование их нецелесообразно. Критичные атрибуты хранятся в хэше, а остальная их часть подвергается "ленивой загрузке" в момент запроса на доступ.
- 90% запросов являются запросами к API. Таким образом кэширование страниц или их фрагментов становится бессмысленным, зато никто не мешает им кэшировать сами API запросы.
Внутренняя организация работы с сообщениями:
- Сообщения очень активно используются: производители генерируют сообщения, они образуются в очереди, а затем распространяются по потребителем.
- Основная функция Twitter заключается в реализации своеобразного моста между различными форматами электронных сообщений (SMS, электронная почта, сервисы мгновенного обмена сообщениями и так далее).
- Чтобы инвалидировать в кэше информацию можно просто отправить внутреннее сообщение, зачем выполнять все действия синхронно?
- Изначально этот механизм основывался на DRb (distributed Ruby) - библиотека, позволяющая отправлять и принимать сообщения сообщения между удаленными Ruby-объектами по TCP/IP. Но она была несколько странноватой, да и являлось потенциально слабым местом с точки зрения стабильности.
- Со временем сервис перевели на Rinda, представляющую собой набор общих для всей системы очередей. Но и у нее были недостатки: все очереди были постоянными, а данные терялись при сбоях.
- Следующей попыткой был Erlang. Но однажды возникла проблема: каким образом сломавшийся сервер может продолжать работать, но при этом в очереди откуда-то возникли целых 20000 ожидающих пользователей? Разработчики не знали. На лицо явный недостаток документации...
- В конце концов решение было разработано своими силами: Twitter выпустил Starling, распределенный легковесный сервер очередей, написанный на Ruby и поддерживающий протокол memcache. Сейчас серверная часть Twitter управляется именно им.
- Распределенные очереди позволяют переживать сбои путем записи их на диск в критических ситуациях. Другие крупные интернет-проекты также часто пользуются таким подходом.
Работа с SMS осуществляется с помощью сторонних сервисов и предоставляемых ими шлюзов. Достаточно дорогое удовольствие.
Развертывание:
- Просто запускаются дополнительные сервера с mongrel, более элегантного решения пока нет.
- Все внутренние ошибки выдаются пользователям, если обслуживающий их mongrel сервер на данный момент заменяется.
- Все сервера останавливаются одновременно. Отключение их по одному по определенным причинам не используется.
Неправильное использование сервиса:
- Много времени сервис был не доступен, так как люди проходились специальными программами по сайту с целью добавить всех кто попадался под руку в друзья. 9000 друзей за 24 часа. Это просто-напросто останавливало работу сайта.
- Были разработаны средства для своевременного обнаружения таких ситуаций.
- Будте беспощадными, таких пользователей нужно просто удалять.
Сегментирование:
- Пока оно только в планах, сейчас оно не используется.
- В будущем оно будет основываться на времени, а не на пользователях, так как запросы обычно очень локальны по времени.
- Сегментирование будет не так просто реализовать благодаря автоматическому запоминанию результатов выполнения функций для последующего повторного их использования. Никто не даст гарантии, что операции "только для чтения" на самом деле будут таковыми являться. Запись в slave, работающий в режиме read-only, - не самая лучшая идея.
API Twitter генерирует в 10 раз больше трафика, чем сам сайт.
- Их API - самая важная вещь из всех, что они разработали.
- Простота сервиса позволила разработчикам строить свои приложения поверх инфраструктуры Twitter, привнося все новые и новые идеи. Например, Twitterrific - красивый способ использовать Twitter в небольшой команде.
Мониторинг используется для остановки слишком больших процессов.

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

Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) - они сыграют свою роль и спасут работоспособность системы.
Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
Оптимизируйте базу данных:
- Индексируйте все таблицы, Rails не будет делать это за Вас.
- Используйте "explain" для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.
- Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.
- Избегайте комплексного объединения данных из нескольких таблиц.
- Избегайте сканирования больших наборов данных.
Кэшируйте все, что только можно.
Тестируйте все максимально тщательно:
- Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.
- Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.
Длительно функционирующие процессы стоит оформить в виде daemon'ов.
Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
Не делайте глупостей!
- Масштаб проект несколько меняет понятие "глупость".
- Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 - этот механизм прекрасно работал.
Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!

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

Иван Блинков — Thu, 10 Apr 2008 00:24:00 +0400

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

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

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

Linux (Debian Sarge)
Perl
Apache
MySQL 4.0/4.1 в основном с InnoDB
Perlbal, веб-сервер и балансировщик нагрузки
memcached для распределенного кэширования
MogileFS, распределенная файловая система
Gearman
TheShwartz
djabberd

Статистика

на данный момент 15320315 учетных записей; (10.04.08)
из них активно используется 551589;
наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей - девушки и женщины;
более 15 миллионов новых записей в блогах за месяц;
более 50 миллионов просмотров страниц в день, при пиковой нагрузке - несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

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

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

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

При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

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

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

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
достигать превосходной производительности при формировании HTML-кода страниц;
в разы снизить нагрузку на базы данных в проекте любого масштаба.

Этот продукт на практике оказался более чем эффективен, о чем свидетельствует его более чем успешное использование во многих крупнейших веб-проектах.

Perlbal

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

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

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

Идея распределенных файловых систем далеко не нова, достаточно вспомнить лишь GFS или любой ее opensource аналог. Сам факт создания такой системы был очень легок, изначальная версия была написана за одни выходные, но при доведении ее до требуемого уровня качества пришлось попотеть. Решение о ее создании было развитием идеи распределения операций записи. Общая принцип хранения файлов прост: каждый файл в ФС относится к определенному классу файлов, который определяет все правила работы с файлом, в основном механизм его реплицирования, об остальном заботится сама система.

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных - в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal - сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

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

В рамках LiveJournal Gearman применяется в основном для:

обработка изображений средствами Image::Magick вне perl-приложений;
создание pool'а DBI соединений (DBD::Gofer + Gearman);
уменьшением нагрузки, создаваемой отдельными компонентами системы;
улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

В качестве альтернативы gearman'у для работ, для выполнения которых необходимы некоторые гарантии успешности, а также некоторая стабильность, была разработана эта библиотека. Общая схема работы осталась та же: клиент-серверная, но за стабильность приходится платить - производительность существенно ниже, возможно возникновение задержек.

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

Основными сферами применения TheShwartz в LJ являются:

отправка электронной почты (SMTP клиент);
LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
отправка RPC сообщений внешним сервисам;
внедрение Atom потоков;

djabberd

Как всегда следуя принципу "чем проще - тем лучше", разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

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

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

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

Иван Блинков — Tue, 01 Apr 2008 20:49:00 +0400

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

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

Этот текст - перевод статьи, автор - Todd Hoff.

Платформа

Статистика

Проект стартовал в конце 2004 года на одном сервере под управлением Linux с использованием Apache 1.3, PHP 4 и MySQL 4.0 (со стандартной системой хранения данных - MyISAM).
Более 1.2 миллиона пользователей.
Более 200 миллионов просмотров страниц в месяц.
100 серверов расположены в нескольких датацентрах, из них: – 20 серверов баз данных; – 30 веб-серверов; – несколько поисковых серверов, использующих Lucene; – остальные используются для обеспечения избыточности.
30 GB данных.
Ни одна из проблем, с которыми пришлось столкнуться проекту не была связана с PHP, в основном они касались базы данных.
Легковесная природа PHP позволила переместить вычислительные работы из базы данных в приложение для улучшения производительности.

Что внутри?

Балансировщик нагрузки равномерно распределяет запросы между PHP серверами.
MySQL используется по принципу master-slave: - Сервера, обрабатывающие большое количество транзакций, используют движок InnoDB. - Сервера, выполняющие аналитическую обработку данных в реальном времени, используют MyISAM. - Снижения производительности при переходе с MySQL 4.1 на версию 5 замечено не было.
Для кэширования используется Memcached.
Используется сегментирование баз данных.
Особенности использования Digg существенно облегчают процесс масштабирования. Большинство посетителей просто просматривают главную страницу и уходят. Это приводит к тому, что 98% запросов к базе данных являются операциями чтения. Такое соотношение операций чтения и записи позволяет не беспокоиться о комплексной работе по проектированию операций записи, что позволяет намного проще масштабировать проект.
Возникали проблемы, связанные с системой хранения данных, которые сообщали, что данные уже записаны на диск, когда на самом деле это было не так. Контроллеры делали это для создания впечатления более высокой производительности. Но на практике это приводило лишь к проблемам с целостностью данных. Это достаточно распространенная проблема, которую порой не так уж просто решить, правда все зависит от используемого оборудования.
Для облегчения нагрузки на базы данных используется кэширование и APC PHP Accelerator.
С использованием рабочих потоков Apache2, FastCGI и PHP акселератора возможно избежать необходимости каждый раз заново интерпретировать и компилировать PHP скрипты: скрипт компилируется только при первом обращении, что существенно ускоряет скорость его выполнения при последующих обращениях.

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

Используйте возможность выбора движка для MySQL. Если Вам нужны транзакции - используйте InnoDB, если нет - MyISAM. Например, если на master сервере расположены транзакционные таблицы, то для slave серверов можно использовать и MyISAM.
В определенный момент рост стал невозможен путем добавления дополнительной оперативной памяти, пришлось продолжать рост путем изменения архитектуры.
Люди часто жалуются, что Digg медлителен. Скорее это вызвано их огромными JavaScript библиотеками, чем работой их серверной системы.
Стоит тщательно выбирать какие именно приложения развертывать. Они приложили все усилия, чтобы не использовать приложения, требующие больших вычислительных мощностей. Очевидно, что Digg работает на совершенно стандартной LAMP архитектуре, но тем не менее реализована она достаточно интересно. У инженеров часто возникает желание реализовать какой-либо дополнительный функционал, но всегда стоит иметь ввиду, что они могут разрушить инфраструктуру, если она не сможет расти теми же темпами. Так что с этим стоит повременить до тех пор пока система сможет выдерживать все необходимые нагрузки. Это приводит к планированию ресурсов, особенно большое внимание этому аспекту уделяет Flickr.
Вам остается лишь догадываться, сможет ли Digg удержать свои позиции, если и дальше будет ограничивать добавление новых возможностей, или уступит более активно развивающимся сервисам социальных закладок? Возможно если бы была возможность увеличивать масштабы более простыми методами, более быстрое добавление новых функций и возможностей позволило бы более эффективно конкурировать на этом рынке? С другой стороны, просто добавление новых возможностей может и не поменять ситуацию кардинальным образом.
Основные проблемы с масштабируемостью и производительностью связаны с обработкой данных и в большинстве случаев они не зависят от используемого языка программирования. Вы столкнетесь с ними при работе с Java, PHP, Ruby, или подставьте сюда Ваш любимый язык программирования.

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

Иван Блинков — Fri, 28 Mar 2008 15:32:00 +0300

Wikimedia является платформой для Wikipedia, Wiktionary и еще семи менее крупных wiki-проектов. Этот документ очень пригодится новичкам, пытающимся довести свои проекты до масштабов гигантских вебсайтов. Здесь можно найти множество интересных деталей и инновационных идей, которые уже успели доказать свою работоспособность на самых посещаемых сайтах всего Интернета.

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

Перевод статьи. Автор - Todd Hoff.

Архитектура Wikimedia
Серверы Wikimedia
scale-out vs scale-up из блога "Oracle to MySQL"

Платформа

Apache
Linux
MySQL
PHP
Squid
LVS
Lucene для поиска
Memcached для распределенного кэширования объектов
lighttpd для работы с изображениями

Статитстика

8 миллионов статей распределены по сотням языковых подпроектов (английские, голландские, ...)
В десятке самых высоконагруженных проектов по данным Alexa
Экспоненциальный рост: в терминах посетителей, трафика и серверов удвоение происходит каждые 4-6 месяцев
30000 HTTP запросов в секунду в периоды пиковой нагрузки
3 GBps трафик данных
3 датацентра: Тампа, Амстердам, Сеул
350 серверов, конфигурации варьируются от однопроцессорных Pentium 4 с 512 MB оперативной памяти до двухпроцессорных Xeon Quad-Core с 16 GB RAM.
Управляется ~6 людьми
Три кластера на трех разных континентах

Архитектура

Географическая балансировка нагрузки, основываясь на IP клиента, перенаправляет их на ближайший кластер. Происходит статическое отображение множества IP адресов на множество стран, а затем и на множество кластеров.
Кэширование с помощью Squid группируется по типу контента: текст для wiki отдельно от изображений и больших статических файлов.
На данный момент функционирует 55 Squid серверов, плюс еще 20 подготавливается к запуску.
1000 HTTP запросов в секунду на каждый сервер, в периоды повышенной нагрузки эта цифра может достигать 2500.
~ 100-250 MBps на сервер.
~ 14000-32000 открытых соединений на каждом сервере.
До 40 GB дискового кэша на каждом Squid сервере.
До 4 дисков в каждом сервере (1U серверы).
8 GB оперативной памяти, половину использует Squid.
PowerDNS предоставляет геораспределение.
В основном и региональных датацентрах текстовые и медиа кластеры построены на LVS, CARP Squid, кэш Squid. В основном датацентре также находится хранилище медиа-данных.
Для того, чтобы обеспечить предоставление только последних версий страниц, всем Squid-серверам отправляются инвалидационные запросы.
Централизованно управляемая и синхронизированная установка программного обеспечения для сотен серверов.
MediaWiki отлично масштабируется с несколькими процессорами, так что закупаются двухпроцессорный четырех ядерные серверы (8 ядер на сервер).
Одно и то же оборудование выполняет как задачи внешнего хранения данных, так и кэширования Memcached.
Memcached используется для кэширования метаданных изображений, данных парсера, различий между ревизиями, пользователей, сессий. Метаданные, такие как история ревизий, отношений статей (ссылки, категории и так далее), учетные записи пользователей хранятся в основных базах данных
Сам текст находится во внешних хранилищах данных.
Статические (загруженные пользователями) файлы, например изображения, хранятся отдельно на сервере изображений, а метаданные (размер, тип и так далее) кэшируются в основной базе данных и объектном кэше.
Отдельная база данных для каждой вики (не отдельный сервер!).
Один master и много реплицированных slave серверов.
Операции чтения равномерно распределяются по slave серверам, операции записи направляются на master.
Иногда master используется и для операция чтения, когда репликация на slave еще не завершена.
Внешнее хранение данных:
- Текст статей хранится на отдельных кластерах, которые представляют собой простой средство хранения данных с возможностью только дописывания новых данных. Такой подход позволяет сохранить дорогостоящее место в высоконагруженных основных базах данных от редко используемой информации.
- Благодаря этому появляются дополнительные неиспользованные ресурсы на серверах приложений (порой 250-500 GB на сервер).
- На данной момент используются реплицируемые кластеры из 3 MySQL серверов, но в будущем это может измениться, так как требуется более удобное управление ими.

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

Сфокусируйтесь на архитектуре, а не на операциях или чем-то другом.
Иногда кэширование обходится дороже, чем повторные вычисление или поиск данных в исходном источнике.
Старайтесь избегать сложных алгоритмов, запросов к базе данных и тому подобного.
Кэшируйте каждый результат, который дорого вам обошелся и является относительно локальным.
Сфокусируйтесь на "горячих точках" в коде.
Масштабируйтесь разделением:
- операций чтения и записи (master/slave);
- сложных операций и более частых и простых (группы запросов);
- больших, популярных вики и более мелких.
Улучшайте кэширование: временная и пространственная локализация данных, а также уменьшение набора данных на каждом сервере.
Выполняйте компрессию текстовых данных, храните только изменения в статьях.
Казалось бы простые вызовы библиотечных функций порой на практике могут занимать слишком много времени.
Скорость поиска данных на диске ограничена, так что чем больше дисков - тем лучше!
Масштабирование с использованием обычного оборудование не означает использование самых дешевых вещей, которые удастся найти. Серверы баз данных Wikipedia сегодня представляют собой 16GB RAM, двух- или четырех-ядерные серверы с 6 15000 rpm SCSI дисками, организованными в RAID 0. Возможно они бы и использовали более дешевые системы, но 16 GB как раз хватает для размещения основного объема данных, а остальное берут на себя жесткие диски, это вполне соответствует потребностям системы, которую они построили. Примерно по таким же причинам их веб-сервера имеют 8 ядер, так как это позволяет достичь неплохой производительности PHP при достаточно простой организации балансировки нагрузки.
Для масштабирования требуется выполнение массы работы, но если заранее этого не предусмотреть - понадобится сделать еще больше. MediaWiki изначально была написана для одного master сервера баз данных. Затем добавилась поддержка slave. Затем добавилось распределение по языкам и проектам. Дизайн системы с тех пор прекрасно выдерживает все нагрузки, но без очистки от новых узких мест системы не обошлось.
Каждый, кто хочет разработать свою базу данных таким образом, чтобы она позволила недорого масштабироваться с уровня одного сервера до уровня десятки лучших сайтов Интернета, должен начать с обработки слегка устаревших данных на реплицированных slave серверах, при этом не забывать балансировать нагрузку операций чтения между slave серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.

Архитектура Friends for Sale

Иван Блинков — Mon, 17 Mar 2008 21:44:00 +0300

За три коротких месяца Friend for Sale (рейтинговая система в условиях рыночной экономики) попала в десятку лучших приложений Facebook, непринужденно обрабатывая 200 запросов в секунду и демонстрируя шокирующее количество просмотров страниц, за месяц достигающее 300 миллионов просмотров. Все это дело рук двух разработчиков, работающих не полный рабочий день, которые смогли создать успешное веб-приложение, имея в своем распоряжении лишь кластер из дюжины серверов и Ruby on Rails.

Как Friends for Sale масштабируется для того, чтобы обеспечить торговлю всеми этими красивыми людьми? Как Вы думаете, сколько стоят Ваши друзья на открытом рынке?

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

Традиционная пара фраз, чтобы отдать должное оригиналу и его автору. Продолжаем:

Ответы на стандартный набор вопросов от Siqi Chen и Alexander Le, создателей Friends for Sale;
Virality on Facebook.

Платформа

Ruby on Rails
CentOS (64 bit)
Capistrano - для обновлений и перезапусков серверов
Memcached
MySQL
nginx
Starling - распределенный сервер очередей
Softlayer - хостинг
Pingdom - мониторинг
LVM - Magic Multi-Connections Gem - разделение операций чтения и записи между серверами

Статистика

Это Facebook приложение находится в десятке наиболее популярных;
Около 600 тысяч активных пользователей;
Полмиллиона уникальных посетителей ежедневно, и эта цифра неуклонно растет;
Темпы роста проекта достигают 300% в месяц;
200 запросов в секунду;
5 TB трафика в месяц;
Над проектом работают 2 разработчика и 1 админимтратор баз данных.
4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки:
- Каждый из серверов приложений содержит 4 ядра и 8 GB оперативной памяти.
- На каждом из них работает 16 сервисов mongrel (в сумме - 96).
- 4 GB оперативной памяти на каждом из них отведено под memcached.
- Сервера баз данных имеют более серьезное оборудование: при тех же 4-х ядрах, они имеют 32 GB оперативной памяти и RAID 10 массив из четырех 15000rpm SCSI дисков, работающих в режиме "master/slave".

Давайте знакомиться

Для чего нужна ваша система?

Наша система разработана в качестве платформы для нашего Facebook приложения, Friends for Sale. В целом оно представляет собой аналог рейтинговой системы Hot-or-Not с некоторым добавлением рыночной экономики. В момент проведения интервью это приложение было на 10-м месте по популярности среди приложений Facebook.

Описание этого приложения на самом Facebook гласит:

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

Почему вы решили построить эту систему?

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

С какими конкретными сложными задачами, связанными с дизайном, архитектурой или реализацией системы, вам пришлось столкнуться при построении системы?

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

Каковы были ваши

действия, направленные для решения этих задач?

С самого начала мы активно использовали memcached - для перезагрузки страницы совсем не требуется выполнение SQL запросов. В основном мы использовали кэширование фрагментов Rails с индивидуальной логикой актуальности.

Как вы оцениваете размеры вашей системы?

Вчера статистика показала более полумиллиона уникальных посетителей, и эта цифра неуклонно растет. За этот месяц было зарегистрировано более 300 миллионов просмотров страниц.

Каковы показатели использования пропускной способности интернет-канала?

В прошлом месяце было потрачено 3 терабайта трафика, но в этом месяце ожидается цифра не меньше 5 терабайт. Эти цифры состоят по большей части из XHTML / CSS и нескольких небольших иконок.

Как много документов используется в системе? Сколько изображений? Какой объем данных?

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

Как вы оцениваете темпы роста вашей системы?

Месяц назад за сутки просматривалось около трех миллионов страниц, на данный момент эта цифра достигла 10 миллионов в сутки. Из чего можно сделать вывод, что ориентировочные темпы роста проекта составляют 300% в месяц. Если говорить о ежесекундной нагрузке, то на данный момент она составляет около 200 запросов в секунду.

Какая часть посетителей платит вам за участие в вашем проекте?

Он абсолютно бесплатен для пользователей.

Каковы показатели "текучести" пользователей?

В среднем около 1% в сутки, с ежедневным ростом в 3% от этой цифры, если говорить в терминах новых установок .

Как много учетных записей активно принимали участие в проекте за последний месяц?

По данным Google за последний месяц проект посетил 2.1 миллион уникальных пользоывтелей.

Какова архитектура вашей системы?

Она представляет собой относительно стандартный Rails кластер. В качестве интерфейса между запросами пользователей и серверами приложений используется proxy балансировщик нагрузки, который перенаправляет запросы напрямую шести четырехядерным серверам приложений. На каждом сервере приложений запущено 16 mongrel'ов, что в сумме дает 96. Балансировщик нагрузки перенаправляет запросы напрямую на порты серверов mongrel. В дополнение к этому на каждом сервере приложений выделено 4 GB оперативной памяти под memcached, а также работает локальный сервер распределенного менеджера очередей Starling и несколько менее важных фоновых процессов.

СУБД работает на двух серверах (четыре ядра, 32 GB оперативной памяти, четыре 15000rpm SCSI диска в RAID 10) в режиме "master/slave". Для организации распределения операций чтения и записи между серверами используется Magic Multi-Connections Gem от Dr Nic.

На данный момент ведется работа над добавлением дополнительных серверов, работающих в роли "slave", для обеспечения более эффективного распределения нагрузки, избыточности и политик хранения запасных копий данных. Помимо этого нам помогают Percona (ребята из mysqlperformanceblog) с удаленной работой над архитектурой базы данных.

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

Каким образом планируется масштабировать архитектуру вашего проекта?

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

Назовите самые интересные уникальные факты о вашем проекте?

Я могу назвать:

Ни один из двух разработчиков ранее не имел опыта в крупномасштабных разработках на основе Rails.
Наша траектория роста проекта достаточно редка в истории разработок с использованием Rails.
У нас практически не было возможностей для кэширования статических страниц - каждый запрос страницы приходилось обрабатывать Rails.

Чему вам удалось научиться? Каков залог вашего успеха? Чего бы вам хотелось сделать по-другому в прошлом, если бы была такая возможность? Что бы вы оставили как есть?

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

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

Определенно нам нужен был более качественный хостинг намного раньше.

Мы определенно не сменим наш framework - Rails был незаменим при быстрой разработке приложения, нам удалось доказать, что для масштабирования проекта на RoR достаточно двух парней, абсолютно не имеющих опыта в этом.

Кто входит в состав вашей команды?

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

Сколько всего людей участвует в проекте?

В технической части - два разработчика и один администратор баз данных, работающий на контрактной основе.

Где они расположены с географической точки зрения?

Все участники проекта живут в районе SOMA, San Francisco.

Каковы обязанности каждого из участников проекта?

Оба разработчика проекта по совместительству являются и его создателями. Поначалу я (Siqi) был ответственным за дизайн и разработку пользовательского интерфейса, но так как у меня был некоторый опыт с развертыванием систем я взял на себя и разработку управления сетевыми операциями и развертывания. Мой коллега Alex был ответственным за большую часть Rails кода, вся логика приложения - его рук дело.

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

У вас есть какая-то определенная философия менеджмента?

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

Если ваша команда работает раздельно, как вам удается координировать свою работу?

Нам стоило бы задуматься об использования каких-либо эффективных средств общения. Мне кажется, что использование удаленной работа / outsourcing'а является по-настоящему сложной задачей - я предпочитаю обходиться без этого в разработке основы системы. Для системного администрирования или разработки архитектуры БД это было бы более оправданно.

Что вы используете для разработки?

Мы используем Rails с несколькими plug-in'ами, самыми важными являются cache-fu от Cris Wanstrath и magic multi connections от Dr Nic. В качестве текстового редактора я предпочитаю vim с плагином rails.vim.

Какие языки программирования используются?

Ruby on Rails

Сколько используется серверов?

На данный момент используется кластер из 12 серверов.

Как они используются?

4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки.

Кто их предоставляет?

Мы заказываем их у Softlayer - до подключения их к системе проходит порой менее четырех часов, что очень неплохо.

Какая операционная система используется?

CentOS 5 (64 бит)

Какой http сервер используется?

nginx

Какая СУБД используется?

MySQL 5.1

Вы используете обратную proxy?

Мы просто используем встроенный в nginx proxy балансировщик нагрузки.

Как вы развертываете вышу систему в датацентре?

Мы используем хостинг выделенных серверов, Softlayer.

Какова ваша стратегия хранения данных?

Мы используем резервное копирование NAS помимо внутренних SCSI RAID массивов.

Какой объем дискового пространства вам доступен?

На всех серверах в сумме около 5 TB.

Как вы наращиваете объем дискового пространства?

Спонтанно. Мы еще не выполнили каких-либо исследований в планировании дискового пространство, но это было явно зря не сделано.

Вы используйте какой-либо сервис хранения информации?

Нет.

Вы используете виртуализацию хранимых данных?

Нет.

Как организована работа с сессиями?

На данный момент она поручена СУБД, но передача их обслуживания напрямую memcached - достаточно несложная задача.

Как организована архитектура вашей БД?

На данный момент - "master/slave". Мы осуществляем переход к нескольким "slave" с proxy балансировщиком нагрузки для режима "только для чтения".

Как организована балансировка нагрузки?

На программном уровне средствами nginx.

Какой framework / AJAX библиотеку вы используете?

Rails.

Какие средства распределенного управления задачами вы используете?

Starling

Как вы управляете рекламой в проекте?

Мы участвуем в нескольких рекламных сетях. Мы оцениваем эффективность каждой рекламной сети с помощью eCPM на уровне приложения.

Имеете ли вы стандартную API на вашем сайте?

Нет.

Сколько человек в вашей команде?

2 разработчика.

Какими наборами способностей обладают участники вашей команды?

Я: дизайн пользовательского интерфейса, разработка, ограниченные знания в Rails, оптимизация MySQL, развертывание Rails.

Alex: разработка логики приложения, дизайн пользовательского интерфейса, программная инженерия в целом.

Какие средства разработки вы используете?

Alex работает в OS X, а я предпочитаю Ubuntu. Для контроля за версиями используется SVN. В качестве текстового редактора я использую VIM, а Alex - TextMate.

Как проходит процесс разработки?

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

Какова ваша стратегия кэширования объектов и контента?

Мы используем memcached без TTL и просто вручную очищаем кэш при необходимости.

Как происходит кэширование на клиентской стороне?

Никак.

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

Мы используем Pingdom для внешнего мониторинга за сайтом - они отлично справляются.

Как вы проверяете работоспособность ваших серверов и сетей?

На данный момент мы полагаемся на внешний мониторинг и ping мониторинг от Softlayer. В перспективе мы рассматриваем FiveRuns как возможное решение для мониторинга серверов.

Как вы строите на графиках или диаграммах сетевую и серверную статистику, а также тенденции?

Мы не занимаемся этим.

Как вы тестируете систему?

Сначала мы разворачиваем ее на тестовом сервере и проводим несколько тестов, после чего разворачиваем систему уже на серверах приложений.

Как вы анализируете производительность?

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

Как вы обеспечиваете безопасность?

Тщательно.

Как вы решаете какие возможности добавить или оставить?

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

Как вы реализуете веб-аналитику?

Мы используем собственную систему оценок для оптимизации вирусного эффекта, но помимо этого пользуемся и услугами Google Analytics.

Используете ли вы A/B тестирование?

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

Как вы выполняете резервное копирование и восстановление?

Мы используем LVM для создания ежедневных и еженедельных инкрементальных резервных копий.

Как выполняются обновления оборудования и программного обеспечения?

На данный момент мы делаем это вручную, за исключением развертывания Rails приложения. Для обновления и перезапуска серверов приложений мы используем Capistrano.

Как вы выполняете глобальные изменения в структуре базы данных при обновлениях?

Обычно мы начинаем переход с второстепенных серверах баз данных, а затем просто переключаем основные.

Каковы ваши планы насчет защиты от сбоев и развития бизнеса?

Не самым лучшим образом...

Есть ли у вас отдельная операционная команда, работающая над сайтом?

Было бы неплохо, но нет :)

Используете ли вы CDN? Если да, то какую и для каких целей?

Нет.

Как выглядит модель ваших доходов?

CPM: больше просмотров страниц - больше денег. Помимо этого у нас бывают прямые поощрительные предложения через нашу виртуальную валюту.

Как вы продвигаете ваш продукт?

Это же социальная сеть. Мы просто используем вирусный эффект для поддержания роста проекта.

Используете ли вы какие-либо особенно интересные технологии или алгоритмы?

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

Храните ли вы изображения в базе данных?

Нет, это бы была не самая лучшая идея.

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

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

Приходилось ли вам сталкиваться с какими-либо сюрпризами, положительными или отрицательными?

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

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

Как ваша система эволюционирует для соответствия новым требованиям к масштабируемости?

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

Кем вы восхищаетесь?

Brad Fitzpatrick за изобретение memcache, а также каждым, кому успешно удалось горизонтально масштабировать свой проект.

Каковы ваши планы по изменению архитектуры в будущем?

Скоро предется переходить к сегментированной по пользователям базе данных, так как скоро мы достигнем пределов базы данных по операциям записи и размерам.

Их мысли о вирусном эффекте Facebook

Facebook моделирует социальную сеть в цифровой форме максимально точно и полно, по крайней мере насколько это возможно.
Построение социальной сети более важно, чем возможности, предоставляемые пользователям.
Facebook позволяет быстро распространять новые приложения через социальную сеть.
Идея вашего приложения должна быть социальной, затягивающей и универсальной.
Социальный аспект является основой вирусного эффекта.
"Затягивание" пользователей позволяет зарабатывать на нем.
Универсальность дает необходимый потенциал.
Friends for Sale - социальный проект, так как предоставляет возможность торговать своей частью социального графа.
Он затягивает, так как в основе лежит в какой-то степени сумасшедшая идея, ненавязчивая, слегка флиртующая, и немного циничная.
Он универсальный, так как все люди в какой-то степени самовлюбленны, знают себе цену, и хотят флиртовать с "горячими" людьми.
Каждая часть приложения является потенциальной для вовлечения новых пользователей.
Каждый пользователь в среднем приводит 1.4 новых, что является залогом экспонентациального роста.
Для каждого нового пользователя отслеживается количество приглашений, нотификаций, записей на "стене", кликов в профиле и других факторов.
Для каждого канала поступления новых пользователей вычисляются проценты нажавших, успешно вовлеченных и выходов из проекта.

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

На Facebook требуется масштабирование с самого начала. Дорога до миллиона просмотров страниц в сутки заняла 4 недели.
Ruby on Rails может масштабироваться.
При правильном подходе к архитектуре может масштабироваться практически все что угодно, сосредоточтесь на этом.
Вам определенно нужна продуманная архитектура базы данных, качественный хостинг, а также правильно настроенное оборудование.
С использованием кэширования и современных серверов, может пройти достаточно длительный период времени до тех пор, пока понадобится использование баз данных с более сложной структурой, такой как сегментирование.
Социальная сеть - это реальность. Количество новых пользователей в хорошо реализованном Facebook приложении на самом деле ошеломляет.
Большая часть проблем с производительностью в итоге сводится к базе данных. Лишний раз обратите внимание на конфигурацию СУБД, запросы и использование индексов.
Люди до сих пор пользуются Vi!

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

Иван Блинков — Sat, 01 Mar 2008 16:07:00 +0300

Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

Платформа

Apache
Python
Linux (SuSe)
MySQL
psyco, динамический компилятор Python → C
lighttpd для видео

Что внутри?

Статистика

Поддержка обработки более 100 миллионов видеороликов в сутки
Сервис был запущен в феврале 2005 года
В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных

Рецепт управления огромными темпами роста

while (true)
{
   identify_and_fix_bottlenecks();
   drink();
   sleep();
   notice_new_bottleneck();
}

Этот цикл проходит далеко не одну итерацию ежедневно.

Веб-серверы

NetScalar используется для балансировки нагрузки и кэширования статического контента.
Apache работает с включенным mod_fast_cgi
Запросы отправляются на обработку с помощью серверного приложения на Python.
Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
На формирование страницы обычно уходит не более 100 миллисекунд.
psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
Какая-то часть заранее сгенерированного HTML хранится в кэше.
Кэширование данных в СУБД на уровне строк.
Кэшируются полностью сформированные объекты Python.
Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

Управление видео

Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
Использование кластеров влечет за собой: – увеличение производительности пропорционально количеству дисков, на которых расположен контент; – возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров; – возможность организации создания резервных копий online.
В роли HTTP-сервера для работы с видео используется lighttpd: – Он способен дать фору Apache в плане производительности предоставления статического контента; – Для работы с событиями ввода-вывода используется epoll; – Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
Самая популярная часть контента размещается в CDN – CDN реплицирует весь контент в разных частях системы; – Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation: – Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках; – В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств; – Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность; – Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Ключевые моменты

Чем проще - тем лучше;
Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.

Управление миниатюрами видео

На удивление сложно решаемая задача, особенно если необходима эффективность;
Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
Миниатюры хранятся всего на нескольких компьютерах;
Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов: – Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode'ов файловой системы; – Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея; – Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов; – В условиях таких нагрузок Apache показывает плохую производительность; – Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20; – Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность; – С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов; – Перезагрузка занимала 6-10 часов, так как кэш должен был "разогреться" прежде чем перестать использовать данные с жестких дисков.
Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google: – Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе. – Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети. – Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Базы данных

Раньше: – MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
Сейчас: – Используются распределенные базы данных; – Сегментированная система (прим.: по аналогии с Flickr); – Распределенные чтение и запись; – Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками; – Такая архитектура привела к 30%-й экономии на оборудовании; – Задержки в реплицировании сведены к нулю; – Размеры базы данных могут расти практически неограниченно

Стратегия размещения в датацентрах

Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
Было использовано 5 или 6 разных датацентров в дополнение к CDN.
Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

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

Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
Постоянная работа над поиском и устранением узких мест в системе: – на программном уровне это чаще всего бывает кэширование и работа с СУБД; – на уровне операционной системы - операции ввода-вывода; – на уровне оборудования - оперативная память и RAID массивы.
Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.

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

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

Google Video

Архитектура 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% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.

Общаемся с базой данных

Иван Блинков — Wed, 16 Jan 2008 22:04:00 +0300

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

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

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

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

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

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

<?php
class SQL
{
}
?>

В зависимости от предпочитаемой Вами СУБД набор конкретных функций, используемых в реализации нашего класса, будет вариироваться. В большинстве случаев предпочитаю пользоваться PostgreSQL, на это причин у меня несколько, но это тема для отдельного разговора. Благодаря этому факту приводимый в качестве примера код будет использовать функции для работы именно с этой СУБД. Для поклонников же других этот систем вопрос в подавляющем большинстве случаев заключается лишь в замене этих функций на аналогичные из других модулей PHP, например для популярной и широкораспространенной MySQL достаточно будет всеголишь пройтись автозаменой pg_ => mysql_ и слегка подредактировать параметры некоторых функций.

Перейдем к реализации установления соединения с СУБД, не стоит ожидать увидеть здесь ничего необычного:

<?php
static function connect()  // установка соединения
{
  self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
  // не забываем менять указанные данные для авторизации на правильные
  if(!isset(self::$connection))
  {
    echo "Сайт не работает по техническим причинам.
Просим прощения за доставленные неудобства.";
    exit;   // ни в коем случае не выводим более информативных сообщений об ошибке, чем это
  }
}
?>

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

<?php
static function query($str,$bool=false) // произвольный запрос
{
  //echo $str."
"; // очень удобно на стадии разработки в процессе поиска ошибок
  $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
  // or die('Query failed: '.pg_last_error());
  // не забываем убирать в комментарий в финальном варианте проекта
  // или совсем удалять
  if($result)  // Если получен результат, отличный от false
  {
    if($bool)  // Если выбран результат в виде boolean
    {
      return true;
    }
    else  // Если выбран результат в виде массива
    {
      $n=pg_num_rows($result);  // для создания универсального формата массива
      if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
      else  // даже когда результат содержит только одну строку
      {
        $j=pg_num_rows($result);
        $list=array();
        for($i=0;$i<$j;$i++)
        $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
        return $list;
      }
    }
  }else return false;
}
?>

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

<?php
static function selectAll($table)
{ // пример метода отправки чаcтоиспользуемых запросов
  return self::query("select * from ".$table.";");
}
?>

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

Что ж, осталось лишь собрать весь код в единый листинг:

<?php
class SQL
{
  private static $connection; // соединение с СУБД
  static function connect()  // установка соединения
  {
    self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
    // не забываем менять указанные данные для авторизации на правильные
    if(!isset(self::$connection))
    {
      echo "Сайт не работает по техническим причинам.<br />Просим прощения за доставленные неудобства.";
      exit; // ни в коем случае не выводим более информативных сообщений об ошибке, чем это
    }
  }
  static function query($str,$bool=false) // произвольный запрос
  {
    //echo $str."<br>"; // очень удобно на стадии разработки в процессе поиска ошибок
    $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
    // or die('Query failed: '.pg_last_error());
    // не забываем убирать в комментарий в финальном варианте проекта
    // или совсем удалять
    if($result)  // Если получен результат, отличный от false
    {
      if($bool)  // Если выбран результат в виде boolean
      {
        return true;
      }
      else  // Если выбран результат в виде массива
      {
        $n=pg_num_rows($result);  // для создания универсального формата массива
        if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
        else  // даже когда результат содержит только одну строку
        {
          $j=pg_num_rows($result);
          $list=array();
          for($i=0;$i<$j;$i++)
          $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
          return $list;
        }
      }
    }else return false;

  }
  static function selectAll($table)
  { // пример метода отправки чаcтоиспользуемых запросов
    return self::query("select * from ".$table.";");
  }
}
?>

```

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

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

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