Insight IT

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

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

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

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

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

Обязанности

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

Требования

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

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

Обязанности

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

Требования

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

Условия

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

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

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

Серверная часть интерактивного сайта и потоки сообщений

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

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

Приступим!

Внутренние сервисы

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

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

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

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

Функциональные языки программирования, в Erlang и Scala модель акторов является практически "сердцем" всего языка и связанной платформы; у обоих есть библиотеки для реализации надежных, высокопроизводительных и масштабируемых акторов (OTP и Akka, соответственно). Если не боитесь кардинально отличающейся от нынче модного ООП парадигмы разработки, этот вариант наиболее жизнеспособный, рекомендую.
Асинхронный HTTP-сервер, в частности Tornado и node.js - они основаны на epoll и помимо эффективной обработки HTTP-запросов умеют и эффективно их отправлять посредством идущего в комплекте асинхронного же клиента. При таком подходе по сути получается несколько "уровней" HTTP-серверов, первый из которых публично доступен для общения с внешним миром и в ответ на каждый входящий запрос обращается сразу к нескольким внутренним HTTP-сервисам (вероятно параллельно) и на их основе составляет ответ пользователю. Этот подход одно время активно пропагандировали на конференциях ребята из одного крупного отечественного сайта с вакансиями. Особенным бонусом этого варианта является возможность использовать в роли внутреннего сервиса какую-то старую, доставшуюся по наследству (legacy), систему, которая с одной стороны по-прежнему нужна, а с другой - человек, который в ней разбирался уже давно уволился.
С++ и Thrift - хоть одного из участников этой пары можно легко заменить на альтернативу, вместе они смотрятся наиболее органично: потенциально высокопроизводительная реализация бизнес-логики на С++ плюс проверенная в деле многими крупными и очень крупными проектами обертка для создания серверов и клиентов, легко общающихся из разных языков программирования (речь о Thrift, если не очевидно). Если в команде проекта есть гуру C++ - этот вариант Ваш, в противном случае не рекомендую, т.к. очень легко накосячить.

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

База данных и кэширование

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

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

В соответствии с этим стоит выбирать хранилище данных и политику кэширования:

Стабильная информация, которая редко обновляется и в тысячи раз чаще читается, прекрасно поддается кэшированию и возможно даже прекрасно будет себя чувствовать в реляционной СУБД.
Свежую информацию вероятно вообще важнее доставить в кратчайшие сроки получателю, а сохранять в персистентном виде можно вообще постфактум для архива, на маловероятный случай когда она повторно понадобится. Про кэширование лучше вообще забыть. Для этого самого "архива" часто используют нереляционные распределенные базы данных вроде HBase, Cassandra или Riak. А про оперативную доставку получателю поговорим в следующем разделе.
Хранилища данных в памяти вроде memcached или Redis с отключенной персистентностью можно использовать независимо для временного хранения каких-то побочных данных (восстановимых производных данных или просто чего-то не особо важного, вроде счетчиков пользователей онлайн).

Потоки сообщений

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

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

Предлагаю рассмотреть типичные сценарии маршрутизации сообщений, они довольно просты:

Конкретный получатель, к сообщению (которое обычно никак не анализируется брокером) прикрепляется метка-идентификатор, обозначающий кому именно оно предназначено. Такое сообщение получит только процесс, зарегистрировавшийся с аналогичным идентификатором. Типичный пример использования - личные сообщения от пользователя к пользователю.
Группа получателей, актуально для проектов, где пользователи взаимодействуют не на глобальном пространстве, а разбиты на части по какому-то признаку. Скажем это может быть какой-то B2B сервис и сообщения ходят только между сотрудниками одной компании-клиента. Обычно используется такие же метки, как и при конкретном получателе, только с одной из сторон (обычно принимающей) вместо конкретного идентификатора указывается какой-то паттерн, вроде CompanyA.*.
Публичные сообщения - получают все пользователи, метки не используются. Обычно это уведомления о глобальных для сайта событиях или публикации каких-то материалов.

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

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

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

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

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

Заключение

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

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

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

Эта статья - пятая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Архитектура Stack Exchange Network

Иван Блинков — Thu, 31 Mar 2011 16:05:00 +0400

Stack Exchange Network представляет собой сеть из 46 сайтов вопросов-ответов на совершенно разные темы от программирования до кулинарии. Проект вырос из известной в узких кругах тусовки программистов Stack Overflow, об архитектуре которой я уже рассказывал чуть больше года назад. Проект активно развивается и уже появилось приличное количество новой информации, которой я и спешу с Вами поделиться.

Статистика

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

Технологии

Разработка

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

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

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

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

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

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

Датацентры

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

Серверы

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

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

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

Прочее

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

Команда

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

Что нового?

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

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

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

Piccolo - построение распределенных систем в 11 раз быстрее Hadoop

Иван Блинков — Sat, 12 Feb 2011 23:49:00 +0300

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

Использование хранилища, позволяющего хранить в памяти пары "ключ-значение", сильно отличается от канонического подхода map-reduce, который основан на распределенных файловых системах. Результаты впечатляют:

Эксперименты показали, что Piccolo очень быстр и отличные возможности по масштабируемости для многих прикладных задач. Производительность вычисления PageRank и k-средних выросла в 11 и 4 раза, соответственно, по сравнению с Hadoop. Вычисление PageRank для связанного графа из 1 миллиарда страниц заняло лишь 70 секунд на 100 машинах в Amazon EC2. Распределенная система по скачиванию веб-страниц легко может полностью загрузить 100Мбит интернет-канал при работе на 12 машинах.

При разработке на Piccolo программисты создают наборы прикладных функций, которые принято называть ядром. Функции ядра запускаются параллельно на нескольких вычислительных узлах, при этом у них есть доступ к общему изменяемому состоянию, которое реализовано в виде набора таблиц, располагающихся в оперативной памяти различных узлов системы. Для доступа к этому состоянию используется примитивный интерфейс, позволяющий узнать (get) и изменить (put) то или иное состояние. Процесс отправки сообщений удаленным узлам, непосредственно имеющим в памяти требуемые данные, полностью берет на себя сам код Piccolo.

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

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

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

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

Проект реализован в виде библиотеки для Python и C++. Более детально примеры использования и принципы работы системы разбираются в источниках информации (правда на английском), не поленитесь - загляните. Вместо заключения хотелось бы по традиции порекомендовать подписаться на RSS блога, если Вы еще этого не сделали.

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

Russell Power - автор проекта Piccolo
Piccolo: Building Fast, Distributed Programs with Partitioned Tables
Проект был презентован на OSDI10: презентация и видео

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

Иван Блинков — 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.

Архитектура Stack Overflow

Иван Блинков — Fri, 08 Jan 2010 00:31:00 +0300

Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel'а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.

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

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

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

Перевод статьи, автор оригинала - Todd Hoff. Возможно будет еще один пост с менее формальной информацией на ту же тему.

Статистика

16 миллионов просмотров страниц в месяц
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
6 миллионов посещений в месяц
86% трафика приходит с Google
9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Более дешевые лицензии были получены через программу Microsoft BizSpark. Скорее всего они заплатили около 11000\$ за лицензии на ОС и MSSQL.

Стратегия монетизации: ненавязчивая реклама, вакансии, конференции DevDays, достижения других смежных ниш (Server Fault, Super User), разработка StackExchange и возможно каких-то других систем рейтингов для программистов.

Платформа

Microsoft ASP.NET MVC
SQL Server 2008
C#
Visual Studio 2008 Team Suite
jQuery
LINQ to SQL
Subversion
Beyond Compare 3
VisualSVN 1.5
Веб уровень:
- 2 x Lenovo ThinkServer RS110 1U
- 4 ядра, 2.83 Ghz, 12 MB L2 cache
- 500 GB жесткие диски, зеркалирование RAID1
- 8 GB RAM
Уровень базы данных:
- 1 x Lenovo ThinkServer RD120 2U
- 8 ядер, 2.5 Ghz, 24 MB L2 cache
- 48 GB RAM
Четвертый сервер был добавлен для запуска superuser.com. Все сервера вместе обеспечивают работу Stack Overflow, Server Fault, и Super User.
QNAP TS-409U NAS для резервного копирования данных. Было принято решение не использовать "облачные" решения, так как вызванные ими дополнительные 5GB трафика ежедневно были бы накладными.
Сервера располагаются у Peak Internet. В основном из-за впечатляющей детализации технических ответов и разумных расценок.
Полнотекстный поиск в SQL Server активно используется для реализации поиска по сайту и выявления повторных вопросов. Lucene .NET рассматривается как достаточно заманчивая альтернатива.

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

Данный список является сборником уроков от Jeff и Joel, а также из комментариев к их записям:

Если Вы комфортно себя чувствуете в деле управления серверами - не бойтесь покупать их. Две основных проблемы с издержками аренды оборудования:
1. невероятные цены на дополнительную оперативную память и жесткие диски;
2. хостинг-провайдеры на самом деле не могут управлять чем-либо за Вас.
Делайте одноразовые более крупные инвестиции в оборудование, чтобы избежать быстро растущих ежемесячных издержек по аренде, которые окажутся более высокими в долгосрочном периоде.
Обновляйте сетевые драйвера. Производительность запросто может удвоиться.
Использование 48GB RAM требует обновления до MS Enterprise edition.
Оперативная память невероятно дешевая. Используйте возможности по её расширению по максимуму для получения практически бесплатной производительности. У Dell, например, переход от 4GB памяти до 128GB стоит всего 4378\$.
Stack Overflow скопировали ключевую часть структуры базы данных у Wikipedia. Это обернулось огромной ошибкой, для исправления которой потребуется большой и болезненный рефакторинг базы данных. Основным направлением изменений будет избавление от излишних операций по объединению данных в большом количестве ключевых запросов. Это ключевой урок, который стоит усвоить у гигантских много-терабайтных схем (вроде Google BigTable), которые полностью избавлены от операций объединения данных. Этот вопрос был достаточно важен для Stack Overflow, так как их база данных практически полностью располагается в оперативной памяти и операции join по прежнему требуют относительно много вычислительных ресурсов.
Производительность CPU оказывается на удивление важным фактором для серверов баз данных. Переход от 1.86 GHz, к 2.5 GHz, и к 3.5 GHz процессорам дает практически линейный прирост к времени выполнения типичных запросов. Исключение: запросы, которые затрагивают не только оперативную память.
Когда оборудование арендуется, обычно никто не платит за дополнительную оперативную память, если только вы не на помесячном контракте.
В 90% случаев наиболее узким местом является база данных.
При небольшом количестве серверов, ключевым компонентом издержек становится не место в стойках, электроэнергия, интернет-канал, сервера или программное обеспечение, а СЕТЕВОЕ ОБОРУДОВАНИЕ. Вам потребуется как минимум гигабитное соединение между уровнями веб-серверов и баз данных. Между интернетом и веб-серверами потребуется firewall, маршрутизатор и VPN. К моменту добавления второго веб-сервера понадобится решение для балансировки нагрузки. Суммарная стоимость такого оборудования может запросто вдвое превосходить стоимость пяти серверов.
EC2 предназначен для горизонтального масштабирования, для того чтобы нагрузка могла быть распределена между большим количеством машин (достаточно хорошая идея, если Вы планируете расширяться). Еще больше смысла в таком подходе появляется, если вы планируете масштабироваться по необходимости (то есть добавлять и убирать машины в зависимости от уровня нагрузки).
Горизонтальное масштабирование может проходить относительно безболезненно только при использовании open source программного обеспечения. В противном случае вертикальное масштабирование значит сокращение издержек, связанных с лицензиями, в ущерб стоимости оборудования, а горизонтальное масштабирование - наоборот: экономия на оборудовании, но требуется существенно больше лицензий на программное обеспечение.
RAID-10 отлично работает для баз данных с высокой нагрузкой операций чтения и записи.
Разделяйте работу приложений и баз данных таким образом, чтобы они могли масштабироваться независимо друг от друга. Например, базы данных могут масштабироваться вертикально, а сервера приложений - горизонтально.
Приложения должны хранить все информацию о своем состоянии в базе данных для обеспечения возможности роста путем простого добавления серверов приложений в кластер.
Одна из основных проблем со стратегией вертикального масштабирования - недостаток избыточности. Кластеризация добавляет надежности, но когда стоимость каждого сервера высока - это не так просто реализовать.
Некоторые приложения могут масштабироваться линейно относительно числа процессоров. Но зачастую будут использоваться механизмы блокировки, что приведет к сериализации вычислений и в итоге к существенному уменьшению эффективности приложения.
С более крупными серверами, занимающими от 7U в стойке, электроэнергия и охлаждение становятся критичными вопросами. Возможно использование чего-то среднего между 1U и 7U может облегчить Ваши взаимоотношения с датацентром.
С добавлением все новых и новых серверов баз данных издержки на лицензии SQL Server могут стать очень существенными. Если Вы начнете с вертикального масштабирования и постепенно начнете переходить к горизонтальному с использованием не open source продуктов, возможно это сильно ударит по Вашему финансовому состоянию. Это справедливо, что в этой заметке речь идет не совсем об архитектуре проекта. Мы знаем об их серверах, об используемом наборе инструментов, об их двухуровневой схеме, где база данных используется напрямую из кода веб-серверов. Но мы не знаем практически ничего о самой реализации, например таких мелочей как теги. Если Вам интересен этот вопрос, возможно Вам удастся получить интересующую Вас информацию из описания их схемы базы данных.

memcached на пальцах

Владислав Клименко — Wed, 15 Jul 2009 15:09:00 +0400

Ранее уже была сделана публикация с обзором memcached. Давайте вернемся к данной теме и рассмотрим практику работы с memcached на примерах.

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

С уважением,
Иван Блинков

Итак, пара слов о предмете разговора. memcached - это распределенная система кэширования объектов в оперативной памяти. Разрабатывается фирмой Danga Interactive (кстати, они являются авторами не только memcached, но и других интересных проектов). Но о них, возможно, в следующий раз. Обычно memcached используется приложениями для временного хранения данных, которые надо часто читать. Приложения не взаимодействуют (обычно) напрямую с сервером memcached, а работают при помощи клиентских библиотек. На настоящее время созданы библиотеки для многих языков программирования (а для некоторых еще и по нескольку альтернативных) - полный список клиентских библиотек доступен на wiki проекта. В целом, данная схема похожа на работу с БД, знакомую многим разработчикам.

Будем рассматривать установку и использование memcached для Linux. Так же при рассмотрении примеров на PHP и обзоре кэширования сессий потребуются PHP и Apache. Возможно, их придется установить, но мы не будем заострять внимание на вопросах установки.

Сервер memcached

Давайте приступим к установке memcached. Практически во всех дистрибутивах Linux memcached можно установить из репозитариев. Если есть желание собрать самую свежую версию, то можно заглянуть на сайт разработчика (на момент написания этих строк последняя версия - 1.4.0). Также, возможно, понадобится установить libevent. Последняя стабильная версия - 1.4.11

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

memcached -vv

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

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

Клиенты memcached

Из всего многообразия клиентских библиотек рассмотрим две:

libmemcached (для Си);
PECL extension для PHP (построенный на базе предыдущей библиотеки).

Си

Библиотека libmemcached на данный момент активно развивается и представляется наиболее подходящим выбором при работе с Си и PHP. Также, в комплекте с самой клиентской библиотекой поставляются дополнительные утилиты для работы с memcached, позволяющие просматривать, устанавливать, удалять значения в кэше memcached. Кстати, удивляет, что набор утилит идет не с серверной частью, а с клиентской библиотекой.

Итак, приступим к установке libmemcached. На момент написания этих строк текущая версия libmemcached - 0.31. Компилируем, устанавливаем. Для начала, наслаждаемся чтением страниц man:

man libmemcached
man libmemcached_examples

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

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

memstat - выдает информацию о сервере memcached
memcat - выдает значение по ключу
memrm - удаляет значение по ключу
memdump - выдает список ключей

Для начала посмотрим, что скажет сервер memcached, запущенный нами немного ранее в режиме выдачи сообщений. Запросим статистику сервера при помощи утилиты memstat:

memstat --servers localhost

 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
  uptime: 1950
 time: 1247390264
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 0
 total_items: 0
 bytes: 0
 curr_connections: 10
 total_connections: 11
 connection_structures: 11
 cmd_get: 0
 cmd_set: 0
 get_hits: 0
 get_misses: 0
 evictions: 0
 bytes_read: 0
 bytes_written: 0
 limit_maxbytes: 67108864
 threads: 5

Получили статистику - следовательно memcached функционирует и откликается на запросы.

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

memcached предоставляет следующий набор основных функций (их, конечно, больше, но здесь приведены основные):

set - занести в кэш пару ключ-значение
add - занести в кэш значение при условии, что значения с таким ключом в кэше еще нет
replace - обновляет кэш при условии, что значение с таким ключом в кэше уже есть
get - получает значение из кэша по указанному ключу

Пример программы на C

Файл mc.c:

#include "stdio.h"
#include "string.h"
#include "memcached.h"

int main( void )
{
    char *key = "key";
    char *value = "value";
    uint32_t flags = 0;
    size_t length = 0;
    char *value2 = NULL;
    memcached_return rc;

    // 1. создать структуру для работы с кэшем
    memcached_st *memc = memcached_create(NULL);

    // 2. указать сервер с которым будем работать
    memcached_server_add(memc,"localhost",11211);

    // 3. занести пару ключ-значение в кэш
    rc = memcached_set(memc, key, strlen(key), value, strlen(value)+1, (time_t)0, flags);

    if (rc == MEMCACHED_SUCCESS) {
    } else {
        // обработать ошибку
    }

    // 4. получить значение
    value2 = memcached_get (memc, key, strlen(key),     & length, & flags, & rc);
    if (rc == MEMCACHED_SUCCESS) {
        printf("%s\n", value2);
        free(value2);
    } else {
        // обработать ошибку
    }

    // 5. высвободить структуру
    memcached_free(memc);
    return 0;
}

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

Компилируем, возможно придется явно указать пути к библиотекам:

gcc -Wall -o mc mc.c -I/usr/local/include/libmemcached/ -lmemcached

Запускаем:

./mc
 value

Видим требуемое значение - должно быть, заработало!

Для уточнения деталей, смотрим сообщения на сервере memcached:

<32 new auto-negotiating client connection
32: Client using the ascii protocol
32 STORED
32 sending key key
>32 END
<32 quit
<32 connection closed.

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

Посмотрим статистику на сервере:

memstat --servers localhost
 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
 uptime: 4659
 time: 1247392973
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 1
 total_items: 1
 bytes: 58
 curr_connections: 10
 total_connections: 13
 connection_structures: 11
 cmd_get: 1
 cmd_set: 1
 get_hits: 1
 get_misses: 0
 evictions: 0
 bytes_read: 58
 bytes_written: 58
 limit_maxbytes: 67108864
 threads: 5

Следующие две строчки показывают, что в кэше появилось значение:

curr_items: 1
total_items: 1

Посмотрим на данное значение:

memcat --servers localhost key
 value

Итак, приложение, использующее memcached - готово.

PHP

Для начала установим PECL extension для PHP - memcached

pecl install memcached

На этом этапе возможно появление сообщения об ошибке вида:

ERROR: 'phpize' failed

Это означает, что не установлен пакет php-dev или его аналог. Устанавливаем его и можно пробовать снова:

pecl install memcached
 install ok: channel://pecl.php.net/memcached-1.0.0
 You should add "extension=memcached.so" to php.ini

Как нам и советуют, дописываем extension=memcached.so в php.ini и перезапускаем Apache.

Смотрим информацию об используемом PHP:

memcached support  enabled
Version  1.0.0
libmemcached version    0.31
Session support    yes
igbinary support   no

Пример программы на PHP

Можно смело использовать обращения к memcached из PHP. Как обычно, рассмотрим пример:

<?php
$m = new Memcached();

$m->addServer('localhost', 11211);
$m->set('phpkey', 'phpvalue');
var_dump( $m->get('phpkey'));
?>

Результат работы данного скрипта:

string(8)  "phpvalue"

Итак, PHP-приложение, использующее memcached - готово.

Кэширование данных сессий

Memcached можно использовать и как хранилище данных сессий для PHP. Такой подход часто используется в реальных приложениях. Давайте рассмотрим, что для этого надо сделать.

Вносим изменения в php.ini

;session.save_handler = files
session.save_handler = memcached

;session.save_path = /var/lib/php5
session.save_path = localhost:11211

Параметр session.save_handler указывает, что теперь данные будут храниться в memcached. Второй параметр - session.save_path указывает сервер memcached (их может быть указано несколько, через запятую) на котором будут сохранятся данные.

Перезапускаем Apache - и готово!

Теперь надо проверить, что теперь данные сессии реально хранятся не на диске, а в memcached.

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

<?php
session_start();
$_SESSION['intval'] = 123;
$_SESSION['strval'] = "qwe";
?>

Запускаем скрипт, он заносит данные в сессию, после чего смотрим на кэш

memdump --servers localhost
 key
 keyphp
 memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f

Итак - к нашим знакомым по предыдущим примерам ключам, добавился ключ с характерным именем memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f.

Хранение данных сессии перенесено в систему кэширования. Более подробную информацию по работе с memcached из PHP можно почитать на сайте PHP.

Заключение

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

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

Hypertable

Иван Блинков — Sat, 05 Apr 2008 20:27:00 +0400

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

Принцип работы Hypertable прост до безобразия:

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

Master Server

– как и во многих других подобных системах мастер-сервер выполняет обязанности скорее административного характера: он управляет работой Range серверов, работает с метаданными (которые хранятся просто в отдельной таблице, наравне с остальными).

Range Server

– их задача стоит в собственно в хранении диапазонов строк из различных таблиц. Каждый сервер может хранить несколько несмежных диапазонов строк, если диапазон превышает по объему определенный лимит (по-умолчанию - 200 MB), то он разбивается на пополам и одна половина обычно перемещяется на другой сервер. Если же на одном из серверов подходит к концу дисковое пространство, то под руководством мастер-сервера часть диапазонов с него перераспределяется на менее загруженные Range серверы.
Еще одним компонентом системы является Hyperspace, этот сервер предоставляет указатель на основную таблицу с метаданными, а также пространство имен. Помимо этого этот сервис выступает в роли lock-механизма для клиентов системы.

В качестве основы для этой системы может использоваться как входящая в состав Hadoop файловая система HDFS, так и KosmosFS, о которой я недавно рассказывал. Это позволяет Hypertable выступать в роли конкурента для HBase в рамках проекта Hadoop.

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

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

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

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

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

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

Файлы в космосе

Иван Блинков — Sun, 30 Mar 2008 23:06:00 +0400

...или Kosmos Distributed File System

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

Инкрементальная масштабируемость. При добавлении дополнительных узлов в кластер, система сама адаптируется для вовлечения их в полноценную работу.
Стабильный доступ. Реплицируемость данных (по-умолчанию в трех экземплярах) позволяет гарантировать доступность данных вне зависимости от сбоев в работе отдельных узлов.
Балансировка блоков данных. Периодически сервер метаданных перераспределяет данные с целью более оптимального использования дискового пространства.
Целостность данных. Для обеспечения целостности данных вычисляются и сравниваются контрольные суммы блоков данных.
Кэширование. Для увеличения производительности используется кэширования на уровне клиентской библиотеки.
Прозрачная работа с недоступными узлами. Клиентская библиотека прозрачно для приложения переключается на альтернативный сервер с данными, если обнаруживает что один из них недоступен.
Поддержка языков программирования: C++, Java, Python.
Скрипты. С системой предоставляется набор скриптов для развертывания, запуска и остановки узлов.

Но написать этот пост меня подтолкнул вовсе не этот список. В комментариях к одной из предыдущих моих записей читатели подняли тему о целесообразности использования Java для реализации HDFS в частности и Hadoop в целом. В качестве альтернативы был предложен C++ (только на словах конечно же), аргументируя это тем, что такая реализация была бы эффективнее. KFS же как раз и является той самой альтернативой HDFS, написанной на C++. KFS тесно интегрируется с Hadoop с помощью его интерфейсов для файловой системы. Это позволяет Hadoop-приложениям незаметно работать с KFS точно так же, как если бы на ее месте была бы HDFS. Код для интеграции с Hadoop был выпущен в виде патча к Hadoop-JIRA-1963, а начиная с Hadoop версии 0.15 этот код входит в стандартный дистрибутив, ровно как и детальная инструкция по интеграции.

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

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

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

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

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

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

Платформа

Статистика

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

Архитектура

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

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

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