Платформа

• Linux — операционная система
• Python — язык программирования
• Django — основной framework
• Apache 2.2 + mod_wsgi — веб-сервер
• PostgreSQL — СУБД
• memcached — кэширование
• HAProxy — балансировка нагрузки
• Slony — репликация данных
• heartbeat — обеспечение доступности

Статистика

• До 17 тысяч запросов в секунду
• 500 000 сайтов
• 15 миллионов зарегистрированных пользователей
• 75 миллионов комментариев
• 250 миллионов посетителей (на август 2010г.)

Основные трудности

• Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)
• Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)
• Нельзя угадать на каком сайте из тысяч возникнет пик трафика
• Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования
• Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)

Архитектура

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

• Оборудование, в сумме около 100 серверов:
  • 30% веб-серверов (Apache + mod_wsgi)
  • 10% серверов баз данных (PostgreSQL)
  • 25% кэш-серверов (memcached)
  • 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
  • 15% прочие сервера (Python скрипты)
• Балансировка нагрузки:
  • HAProxy:
    • Высокая производительность
    • Интеллектуальная проверка доступности
    • Неплохая статистика
• Репликация:
  • Используется Slony-I
  • Основана на триггерах
  • Master/Slave для обеспечения большего объема операций чтения
• Высокая доступность:
  • heartbeat
  • Пассивная копия мастер баз данных на случай сбоя основной
• Партиционирование:
  • Реализовано на уровне кода
  • Простая реализация, быстрые положительные результаты
  • Два метода разделения данных:
    • Вертикальное:
      • Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
      • Позволяет разделять базы данных
      • Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
      • Бартер производительности на масштабируемость
      • Более эффективное кэшировние
      • Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
    • Горизонтальное:
      • Некоторые сайты имеют очень большие массивы данных
      • Партнеры требуют повышенного уровня доступности
      • Помогает снижать загрузку по записи на мастер базе данных
      • В основном используется все же вертикальное партиционирование
• Производительность базы данных:
  • Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
  • Логгирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
  • Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
  • Оптимизация QuerySet’ов:
    • Не используется чистый SQL
    • Встроенный кэш позволяет выделять части выборки
    • Но это не всегда нужно, они убрали этот кэш
  • Атомарные операции:
    • Поддерживают консистентность данных
    • Использование update(), так как save() не является thread-safe
    • Отлично работают для таких вещей, как счетчики
  • Транзакции:
    • TransactionMiddleware поначалу использовалось, но со временем стало обузой
    • В postgrrsql_psycopg2 есть опция autocommit:
      • Это означает что каждый запрос выполняется в отдельной транзакции
      • Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
      • Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в  случае ошибки)
      • В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости  переключаются в транзакционный режим
• Отложенные сигналы:
  • Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
  • Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
  • Модели отправляются в очередь в сериализованном виде
• Кэширование:
  • Используется memcached
  • Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
  • Настраиваемые алгоритмы поведения клиента
  • Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
  • Алгоритм размещения ключей: консистентное хэширование на основе libketama
  • Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
    • Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
    • В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
    • django-newcache и MintCache умеют это делать
    • Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
• Мониторинг:
  • Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
  • Сбор и отображение с помощью Ganglia
• Отключение функционала:
  • Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
  • Система должна срабатывать мгновенно, по всем серверам, без записи на диск
  • Позволяет запускать новые возможности постепенно, лишь для части аудитории
  • Позволяет постоянно использовать основную ветку кода
  • Аналогичная система используется и в Facebook
• Масштабирование команды разработчиков:
  • Небольшая команда
  • Месячная аудитория / количество разработчиков = 40 миллионов
  • Это означает:
    • Автоматическое тестирование
    • И максимально простой процесс разработки
  • Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
    • Установить и настроить PostgreSQL
    • Скачать исходный код из git
    • С помощью pip и virtualenv установить зависимости
    • Изменить настройки в settings.py
    • Выполнить автоматическое создание структуры данных средствами Django
• Непрерывное тестирование:
  • Ежедневное развертывание с помощью Fabric
  • Hudson обеспечивает регулярно осуществляет и тестирует сборки
  • Интегрирован Selenium
  • Быстрое тестирование с помощью Pyflakes и post-commit hooks
  • 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
  • Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
• Отслеживание проблем и задач:
  • Переключились с Trac на Redmine (из-за поддержки под-задач)
  • Отправка исключений на e-mail — плохая идея
  • Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

• Язык программирования, каким бы он ни был, не является проблемой
• Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
• Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
• Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
• Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
• Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

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

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

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

Платформа

• 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.

Платформа

• 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 других сервисов…

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

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

1. Получаем профиль по идентификатору пользователя (скорее всего из кэша, но потенциально возможно обращение к базе данных)
2. Получаем список друзей (опять же на основе идентификатора пользователя из кэша или из базы данных в случае промаха)
3. Параллельно запрашиваем идентификаторы последних 10 альбомов для каждого из друзей (multi-get, каждый промах мимо кэша индивидуально вытаскивается из MySQL)
4. Параллельно получаем данные о всех альбомах (на основе идентификаторов альбомов из предыдущего шага)
5. Все данные получены, выполняем логику отрисовки конкретной страницы на PHP
6. Отправляем 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 Architecture: Science and the Social Graph
• Facebook: Moving Fast at Scale
• Scale at Facebook

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

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

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

Elastic Cloud 2

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

Simple Storage Service

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

SimpleDB

Позиционируется как сервис для предоставления доступа к структурированным данным. С точки зрения разработчика проще охарактеризовать его как нереляционную базу данных. Схема данных генерируется в процессе эксплуатирования сервиса — заранее ее указывать не нужно, а запросы в какой-то степени напоминают сильно ограниченный SQL с возможностью только самых примитивных операций: сравнение, объединение, пересечение и т.п. У этой системы есть несколько аналогов, среди них Apache HBase и Hypertable.

Simple Queue Service

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

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

Знакомство было не долгим — всего пару недель, да и поиграться удалось по большей части лишь с Amazon EC2 и совсем чуть-чуть с S3. Первое впечатление произвел их Getting Started Guide — все просто и лаконично, еще даже до получения доступа к сервису у меня сложилось четкое представление о том, как он работает — несомненный плюс. После получения всех необходимых ключей от аккаунта (их было несколько, запутаться достаточно легко, но документация всегда спасала) можно сразу же приступать к работе с сервисом, скачав набор консольных утилит. Первым делом стоит взглянуть на ассортимент предоставляемых операционных систем для установки на будущие виртуальные машины — на первый взгляд представлены все популярные дистрибутивы Linux, что в общем-то более, чем достаточно (но при более детальном рассмотрении это оказалось далеко не так: различается в них только набор программного обеспечения, а ядро везде одно и то же — от Fedora 8). Так что выбор предстоит хоть и непростой, но скорее его стоит основывать его на личном предпочтении и удобстве, а не на каких-то других соображениях — разница в итоге будет невелика. Я лично остановил свой выбор на Debian Etch — не знаю по каким соображениям, да и не важно это вовсе, как впоследствии оказалось. Сделав свой выбор и подождав буквально несколько секунд можно узнать по какому URL располагается свежесозданная виртуальная машина (хочется отметить, что у утилиты их создания есть параметр «количество», то есть создавать их можно целыми пачками).

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

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

На закуску я оставил ложку дегтя — их ценовую политику. За пару недель достаточно неактивного, «ознакомительного» использования счет легко достиг отметки в пятьсот долларов. EC2 тарифицируется по часам — от 10 до 80 центов в час за виртуальную машину плюс трафик (более детально можно посмотреть на все том же официальном сайте). Там же и указаны гарантируемые вычислительные мощности и объем дискового пространства и оперативной памяти. На практике же все остальные параметры системы (пропускная способность сетевых интерфейсов, скорость чтения/записи на диски и так далее) делятся между всеми виртуальными машинами, располагаемыми на одной физической и по большей части это происходит по принципу «как повезет», хотя наблюдаются и некоторые закономерности: узлам за 40-80 центов/час дается явный приоритет при доступе к дискам (что, впрочем, упоминается в их Developer Guide), но, как оказалось, приоритет этот настолько высок, что скорость записи отличается между ними более чем на порядок — в 15-20 раз, такое вот несколько удивительное наблюдение. Интернет-канал же тоже делится — ограничения сверху достичь не удалось, но есть предположение, что в сумме «на всех» он равен гигабиту на физическую машину.

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

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

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

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

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

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

Платформа

• Linux
• Tomcat
• Java

Статистика

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

Архитектура

• Так как система бесплатна, она не должна быть идеальной. Таким образом основные цели:

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

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

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

• Изначально письма обрабатывались следующим образом:

  - Sendmail получал письмо в общий ящик на диске.

  - Java-приложение доставало сообщение используя IMAP и/или POP (с течением времени это менялось) и удаляло их.

  - Система загружала все письма в память и оставляла их там.

  - Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.

• Данный принцип работал вполне неплохо:

  - Он стабилен и работал месяцами без каких-либо проблем.

  - Использовался практически весь гигабайт оперативной памяти.

  - Проблемы начались, когда количество сообщений в сутки начало превышать 800000. Система начала давать сбои из-за использования жесткого диска между Mailinator и email подсистемой.

  - Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.

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

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

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

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

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

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

  - Ведение логов было отключено.

  - Система использует менее 300 потоков. Это оказалось вполне достаточно.

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

  - Каждый почтовый адрес ограничен только 10 письмами, так что популярные адреса вроде joe@mailinator.com не могут «взорвать» систему.

  - Письма не могут превышать 100 kb, а все приложения автоматически уничтожаются. Это позволяет существенно сэкономить в плане используемой оперативной памяти..

• Электронные письма сжимаются в оперативной памяти:

  - 99% писем никто даже не открывает, компрессия позволяет сэкономить место в оперативной памяти. Письмо разжимается в исходное состояние только если кто-то решает его открыть.

  - Mailinator может хранить около 80000 писем в оперативной памяти, используя лишь 300 MB памяти, по сравнению с 20000 писем, занимающих 1 GB без использования компрессии.

  - С таким подходом к хранению писем, они живут в среднем 3-4 часа.

  - В память поместится и 200000 писем, но на практике это и не требуется.

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

• Mailinator не гарантирует анонимность или приватность:

  - Любой пользователь может получить доступ к любому почтовому ящику.

  - Отказ от ограничений доступа делает схему работы системы намного более простой.

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

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

• Стремление к выживанию требует агрессивной борьбы со спамом:

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

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

• Для успешного приема письмо должно пройти следующую цепочку фильтров:

  - Все письма, которые не смогли быть доставлены, отклоняются.

  - При слишком большом количестве писем с одного IP они перестают приниматься.

  - Слишком много писем с одинаковой темой не принимаются.

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

• Выживание в условиях наплыва писем с одного IP адреса:

  - Для этого типа фильтрации используется AgingHashMap. Когда сервис получает очередное письмо, IP помещается в массив и счетчик, соответствующий этому ключу, увеличивается на единицу в момент получения каждого последующего письма с этого IP.

  - Спустя определенное время без получения писем с IP, соответствующие ему счетчик обнуляется.

  - Когда счетчик достигает определенного порога, IP блокируется, предотвращая поток сообщений.

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

• Защита от «зомби» атак:

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

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

  - Когда около 20 писем с одинаковыми темами приходят в течении 2 минут, этот заголовок блокируется на час.

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

  - Этим фильтром блокируется около 9% писем.

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

• Для уменьшения угрозы DDoS атак:

  - Все соединения, неактивные какое-то время обрываются.

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

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

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

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

Введение

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

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

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

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

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

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

Архитектура

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

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

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

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

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

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

Заключение

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

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

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

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

• Как Digg.com использует LAMP для масштабирования
• Масштабируемость и производительность PHP в Digg

Платформа

• MySQL
• Linux
• PHP
• Lucene
• APC PHP Accelerator
• Memcached

Статистика

• Проект стартовал в конце 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, или подставьте сюда Ваш любимый язык программирования.

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

Перевод статьи. Автор — 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 серверами. Если это возможно — блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще «маленькие». Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.

.

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

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

Изначально архитектура этой файловой системы была разработана просто в рамках исследовательского проекта Петера Браама в 1999, но он решил не останавливаться на достигнутом и основал Cluster File Systems, Inc., в которой уже и велась основная разработка самой файловой системы. Первый релиз Lustre 1.0 был выпущен в 2003 году. Спустя четыре года компания была приобретена Sun Microsystems в октябре 2007 года, но это лишь способствовало дальнейшему развитию проекта. Программное обеспечение, входящее в состав проекта, выпускается под лицензией GPL, что также сыграло немаловажную роль в его жизни.

Архитектура

Каждый компьютер, входящий состав кластера Lustre, выполняет свою четко определенную функцию:

• MDS. Сервер метаданных предназначен для хранения всей служебной информации о системе: названия файлов, директорий, прав доступа и так далее. Достаточно наличие одного такого сервера в системе, но для обеспечения надежности на случай каких-либо сбоев, обычно его дублируют. Возможно использование внешнего хранилища данных (MDT), которое может быть общим для двух дублирующих друг друга MDS.
• OSS. Компьютеры для хранения самих данных. Каждый из них работает с 2-8 OST, в их роли могут выступать практически любые средства хранения данных, начиная от просто жестких дисков или RAID массивов внутри OSS, заканчивая внешними системами хранения данных enterprise-класса. Сумма дискового пространства всех OST и является размером доступного дискового пространства всей файловой системы Lustre.
• Клиент. Компьютеры, непосредственно использующие файловую систему. Им предоставляется полный параллельный доступ, полностью соответствующий стандарту POSIX.

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

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

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

Функционирование

Основным толчком для выполнения каких-либо действий в рамках всей файловой системы обычно является запрос с одного из клиентов. Программное обеспечение для клиентов представляет по сути интерфейс между виртуальной файловой системой Linux и серверами Lustre. Каждому типу серверов соответствует своя часть клиентского ПО: MDC, OSC, MGT. В отличии от Hadoop и GFS файловая система Lustre должна быть примонтирована к локальной системе клиентов для полноценного их функционирования.

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

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

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

Заключение

Эта файловая система нашла свое применение во множестве крупнейших кластеров и суперкомпьютеров по всему миру, но это не мешает ей с тем же успехом демонстрировать и на кластерах существенно меньшего масштаба. Около половины из самых производительных суперкомпьютеров во всем мире используют Lustre в качестве файловой системы. Помимо этого многие компании предоставляют ее в качестве основы для Linux кластеров (например HP StorageWorks SFS, Cray XT3, Cray XD1). Чем не показатель ее конкурентоспособности?

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

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

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

• Google Video

Платформа

• 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. Источниками информации для оригинала послужили:

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

Платформа

• Linux
• Oracle
• C++
• Perl
• Mason
• Java
• Jboss
• Сервлеты

Статистика

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

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

Как и предыдущий пост «Архитектура 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% выше, чем в любой другой день недели.

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

Вчера вечером, решив провести очередное обновление программного обеспечения, я обнаружил в списке замаскированных пакетов внушительное количество заветных цифр 4.0.0. Не долго думая все эти пакеты были отправлены в комментарии с целью разрешить их установку, а на ночь компьютер был оставлен включенным с указанием к утру предоставить мне рабочую версию KDE 4. И, как ни странно, с заданием он справился более чем успешно!

На утро если честно был слегка удивлен. увидев сообщение в консоли о том, что пакет kde-base/kdebase-meta-4.0.0 установлен успешно. Запустив по привычке etc-update и сделав на всякий случай backup настроек третьего KDE, я приступил к запуску свежеустановленного рабочего окружения.

Процесс оказался простым до безобразия, достаточно было лишь сменить тип сессии в kdm, и рабочее окружение успешно загрузилось. Представшее передо мной зрелище меня ничуть не удивило — мне уже доводилось собирать beta-версию KDE 4 из SVN, да и screenshot’ы стандартного рабочего окружения KDE я видел далеко не один раз.

Первым делом я решил запустить Kopete, реально конечно из-за того, что перед завершением сеанса работы с третьим KDE мне кто-то успел написать в ICQ, и меня ждал неоконченный разговор, но посмотреть как он изменился со времен беты тоже хотелось. Попытавшись зайти с его помощью в ICQ, я обнаружил что этого протокола в списке доступных нет, причина нашлась быстро с помощью консоли (которая изменений практически не претерпела) — kopete по-умолчанию был собран без флага oscar. Не долго думая, по-быстрому пересобрал клиент, но в ходе указания настроек account’а он мне заявил, что ему нужен еще и KWallet для хранения пароля. Отправив на сборку и его, я решил временно отложить повторное знакомство с kopete и запустил Pidgin, которым достаточно часто пользуюсь.

После решения вопроса со связью, я отправился на изучения остальных пунктов KMenu, ничего принципиально нового я там не нашел, но решил все же заглянуть в пункт под названием System Settings с целью сделать небольшой обзор доступных настроек и оценить потенциал нового рабочего рабочего окружения в плане «доработки напильником», чем я и планирую в обозримом будущем заняться. Большую часть интересных для меня настроек я нашел прямо в GUI, а если бы не поленился покопаться в конфигурационных файлах — нашел бы и все остальное.

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

Самым большим недостатком доступной на данный момент версии KDE, на мой взгляд, является та самая черная панель внизу экрана, которая используется для размещения любых виджетов наравне с рабочим столом, но имеет один большой недостаток — практически полное отсутствие каких-либо настроек (за исключением непонятно зачем и кому нужного «Show tooltips»), и как следствие, отсутствие элементарных способов ее переместить или изменить в размерах. Именно из-за этого факта я сейчас и пишу снова из KDE 3.5.8, так как я слишком привык получать доступ ко всем функциям рабочего окружения из верхней части экрана, а переучиваться или искать какие-либо нестандартные решения этой небольшой проблемки на данный момент нет ни времени, ни желания.

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

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

Gentoo is all about choices

Абсолютно не важно, держите ли Вы в руках блестящую болванку с надписью «Прощай, предустановленная Vista!» или только подумываете о том, чтобы избавить свой ноутбук от тяжести этой ноши. Прочитав это повествование, Вы сможете представить себе процесс установки альтернативной операционной системы на ноутбук на примере Gentoo Linux и Sony Vaio. Я постараюсь освятить все особенности этого процесса, а также по возможности дать советы по избежанию потенциальных проблем. Не надейтесь найти здесь пересказ Gentoo Handook, ее стоит прочитать в любом случае, если Вы на самом деле задумали установить эту очень серьезную операционную систему.

Сам я занимался этим делом уже более полугода назад на ноутбуке Sony Vaio VGN-FE41ZR, не знаю почему мой выбор в свое время пал именно на эту модель, были доступны и более производительные и «навороченные» — видимо приглянулась она мне чем-то. Далее речь пойдет именно об этой модели ноутбука, но думаю большая часть написанного далее будет справедлива и для других моделей линейки Sony Vaio. Поначалу процесс установки и настройки был очень непрост, ведь часто приходилось пользоваться методом «проб и ошибок», да и достойную документацию найти удавалось далеко не по каждому вопросу. Все про все заняло далеко не один мой летний вечер, терпения потребовалось изрядное количество, но полученный в итоге результат до сих пор не дает повода пожалеть о потраченном свободном времени.

Как я уже успел намекнуть во вступлении, начинается все с болванки на которую записан тот самый волшебный образ. Никто не мешает выбрать любой из доступных вариантов, но предположим, что выбор пал на Gentoo Linux LiveCD 2007.0. Загрузка ноутбука с этого диска проходит плавно и непринужденно, ровно как и сама работа с уже загруженным LiveCD как в консоли, так и в используемом там рабочем окружении — Gnome. Следуя инструкциям из настольной книги начать установку операционной системы очень нетрудно, но если честно у меня прочитав пару раз этот немаленьких размеров текст возникла мысль попытаться сэкономить некоторое количество времени, воспользовавшись услугами двух предложенных автоматических инсталляторов — с графическим и консольным пользовательским интерфейсом — не повторяйте этой ошибки, так как качество реализации обоих вариантов на данный момент оставляет желать лучшего, заставить успешно установить систему один из них может занять ничуть не меньше времени, чем ручная установка. Лично мне приручить ни один из автоматических инсталлятора так и не удалось, но как ни странно тоже не пришлось жалеть об этом факте — как оказалось ручная установка очень качественно позволяет разобраться в структуре операционной системы вцелом, ровно как и в принципе работы отдельных ее компонентов.

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

Ядро

Как известно, для Gentoo доступно несколько вариантов ядер, в процессе установки мой выбор пал на suspend2-sources, но со временем полностью перебрался на gentoo-sources, так как я понял, что сами suspend-to-ram и suspend-to-hdd мне абсолютно не нужны, но suspend2 слегка отстают от gentoo по версиям. Тем более, насколько я знаю, в современных версиях основной ветки ядра suspend тоже поддерживается на достойном уровне (но так как мне он не нужен — пробовать на собственном опыте не доводилось).

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

• Просто скопировать ядро с LiveCD. Этот вариант является самым простым в плане реализации, систему с его помощью запустить вполне реально — пробовал, но в плане производительности ему до идеала о-о-очень далеко.
• Собрать ядро с помощью genkernel и стандартной его конфигурации. Прочитав man genkernel это занятие тоже становится простым и привычным. Именно этот вариант я и выбрал в первый раз, слегка подредактировав конфигурационный файл с помощью ––menuconfig в тех местах, где был точно уверен что это не повлияет на функциональность и положительно повлияет на производительность. Естественно этот вариант тоже годится только на первое время.
• Ручная сборка классическим способом — make, с использованием конфигурационного файла, взятого с LiveCD. Чисто теоретически возможно, но не могу порекомендовать этот способ, при его реализации возникает существенно больше проблем, до конца решить которые мне так и не удалось в процессе установки, а в последующем как-то не возникало желания возвращаться к ручной сборке ядра, так как привык к genkernel — просто и удобно.
• Метод «проб и ошибок». Если есть желание и возможность потратить существенное количество времени на подбор оптимальной конфигурации ядра прямо в процессе установки — почему бы этим и не заняться?

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

Сеть

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

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

• Сетевая карта — Ethernet
• Беспроводная сеть — WiFi
• Старый-добрый модем

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

Ethernet

Воткнув заветный штекер RJ45 в соответствующий разъем, я с удивлением обнаружил с помощью команды ifconfig, что на этом мои телодвижения по получению доступа в Интернет благополучно закончились. Все драйвера оказались на месте, DHCP-клиент без моего вмешательства получил IP-адрес, все необходимые настройки по-умолчанию были выбраны верно — вобщем в этом плане все отлично.

Конечно далеко не у всех локальная сеть организована таким же образом, как и у меня, возможно придется поизучать man ifconfig‘а или повозиться с VPN-соединением.

WiFi

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

Попробовав несколько вариантов, мне удалось-таки установить беспроводное соединение с помощью драйвера под названием ipw3945 и сопутствующего ему daemon’а ipw3945d. Подробно весь процесс описывать не буду, я думаю при необходимости подробную инструкцию найти особого труда не составит.

Я еще не упоминал, что в качестве рабочего окружения предпочитаю использовать KDE, как-то с самого начала к нему привык, как внешне так и внутренне он меня более чем устраивает. Не сочтите предыдущее предложение за отступ от темы, я всеголишь хотел как-то объяснить переход к разговору об утилите, предоставляющей GUI к работе с беспроводными соединениями, — KWifiManager. Утилитка достаточно своеобразная, манера ее поведения поначалу сильно удивляла, но со временем привыкаешь. Особенно странно она производит выбор беспроводной сети, к которой подключаться. Не смотря на установленную в настройках мою домашнюю сеть, как сеть по-умолчанию, она все равно частенько пытается залезть к соседям или еще куда. И что самое интересное — вернуть ее на путь истинный ее же средствами мне обычно так и не удается. Из-за этого пришлось написать bash-скрипт, который помогает укратить эту утилиту. Включать в текст записи его особо желания нету, если кто хочет его заполучить: оставьте соответствующий комментарий — выложу.

Альтернатива консоли

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

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

Одно время конечно возникали некоторые трудности, например в одной из версий X-сервера была неприятная недоработка с LED’ами на клавиатуре — не было видно нажат ли Caps Lock, или при одной конкретной комбинации программного обеспечения и ядра системы по странному стечению обстоятельств частоиспользуемая клавиша F2 приводила к сворачиванию X-сервера и возвращению в консоль, что тоже доставляло массу неудобств. На данный же момент все проблемы такого рода решены руками огромного opensource-сообщества и все снова замечательно работает точно также как и полгода назад сразу после установки системы.

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

Видео

Используемый по-умолчанию видеодрайвер vesa оставляет желать лучшего, этот факт заметен сразу же после первой загрузки рабочего окружения, а значит ничего не остается кроме как искать ему замену. Искать долго не придется — отличный видеодрайвер для присутствующей в внутри этого ноутбука Nvidia GeForce 7600 легко доступен через Portage, называется он, как ни странно, nvidia-drivers.

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

Аудио

С ним все еще проще — достаточно лишь не забыть включить ALSA и Intel HD Audio в конфигурации ядра.

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

Bluetooth

Синий зуб прекрасно чувствует себя под руководством встроенного в ядра драйвера BlueZ, с работой в качестве GUI для работы с этим устройством также неплохо справляются KDE’шные утилиты KBluetooth и компания.

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

Разные мелочи

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

Очень удивил меня тот факт, что для приведения к жизни различных нестандартных кнопок вроде регулировки громкости, S1, S2 и Fn необходима достаточно серьезная «работа напильником»: модули ядра вроде sonypi способны оживить их лишь частично, для полного их функционирования возможно придется изрядно покопаться в конфигурационных файлах, а также написать/найти некоторое количество bash-скриптов. Надеюсь в будущем найду в себе силы довести это дело до конца, правда особого дискомфорта от ненастроенных кнопок я не испытываю — не успел к ним привыкнуть, да и реализованного на уровне оборудования mute sound мне вполне хватает.

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

Встроенная камера заслуживает отдельного разговора. С одной стороны драйвера под нее есть и легко доступны, весь необходимый набор модулей для ядра — v4l, gspcav1, установить абсолютно не проблема. Найдя неплохую статейку в вики я достаточно быстро разобрался с их установкой, но после этого возник вопрос: а зачем оно собственно говоря надо? Как оказалось, камера является абсолютно бесполезным для меня device’ом, и я даже не придумал никакого адекватного способа проверить ее работоспособность. Так эти драйвера и находятся установленными в системе непонятно зачем.

Порт IEEE 1394 aka FireWire опробовать в действии не удалось, так как я не являюсь обладателем устройств, его использующих, но я не вижу каких-либо причин для того, чтобы он не работал: если мне не изменяет память, то он фигурировал в настройках ядра наравне с USB, который замечательно работает.

Cardreader’ов в комплекте было два — один встроенный для MemoryStick, и внешний в 34мм-слот для SD/MMC. Насчет первого не могу ничего сказать, так как карточек таких у меня не нашлось, а второй отлично определился без каких-либо дополнительных действий с моей стороны.

Про DVD-привод, miniJack и прочие стандартные вещи наверное и упоминать смысла нет — с ними все в порядке.

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

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

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

Закончить хотелось бы той же цитатой из Gentoo Handbook, которую я использовал в эпиграфе к этой статье: «Gentoo is all about choices.»

Наконец-то наступил тот самый день, которого так долго ждали многие пользователи различных дистрибутивов Linux и многих других unix-like операционных систем. Да-да, сегодня вышла новая major-версия знаменитого K Desktop Environment под номером 4.0!

Вкратце перескажу оффициальный пресс-релиз:

Набор библиотек, лежащих в основе KDE, был кардинальным образом переделан, изменения произошли в каждой из них. Появилось два новых framework’а: один мультимедийный.- Phonon, а второй — Solid — для интеграции интерфейса для работы с используемым оборудованием в рабочее окружение.

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

Все программное обеспечение, входящее в его состав также не осталось без изменений (немного от себя: лично мне больше всего понравились изменения в Kopete — единственный icq клиент под *nix, в котором появилась возможность использования x-status, которой сильно не хватало, успел заценить его еще некоторое время назад в beta-версии KDE 4). Помимо Konqueror появился новый файловый менеджер под названием Dolphin и просмотрщик документов Okular (основанный на KPDF, но поддерживающий существенно большее количество форматов документов).

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

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

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

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" — Douglas’а Mcllroy’а:

"This is the Unix philosophy:

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface."

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

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

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

Закончив лирическое отступление, хочется взглянуть на нашу философию с точки зрения программиста.

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача — одна программа

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

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

Unix pipes

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

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

Взгляд с точки зрения пользователя

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

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки — stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них — | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

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

• cat — вывод содержимого указанного первым параметром файла в stdout (по умолчанию stdout в большинстве программ направляется в консоль)
• less — постраничный вывод текста, полученного в stdin в stdout (переключение страниц и некоторые другие функции производятся с клавиатуры, возможны и другие варианты использования, но они нам не нужны)
• grep — построчная фильтрация текста, полученного в stdin, вывод только строк, содержащих текст, указанный первым аргументом, и вывод результата в stdout.

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

cat readme.txt | less

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

cat readme.txt | grep unix > readme.txt

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

cat readme.txt | grep unix > meread.txt

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

cat readme.txt | grep unix >> readme.txt

В unix-like системах есть еще одна интересная особенность, косвенно связанная с этим механизмом: все устройства являются файлами и соответственно, прикреплены к файловой системе, для них выделена отдельная директория, по традиции называемая /dev. Работа с ними также ведется на тех же правах что и с обычными файлами, например набрав в консоли:

cat readme.txt > /dev/dsp

в ответ от компьютера Вы услышите некоторый звук, издаваемый из колонок или наушников.

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

С точки зрения простого пользователя использование opensource решений, построенных на базе философии unix, является как минимум нетривиальной задачей — ведь от него требуется как минимум понимание насколько мощная и гибкая система попала ему/ей в руки. Отсутствие единственного верного способа решения той или иной задачи ставит большинство людей попросту в тупик, у них начинают разбегаться глаза от десятков тысяч программ, доступа к которым есть у всех пользователей unix-like операционных систем, с помощью набора простой волшебной команды в консоли, состоящей не более чем из трех-четырех слов.

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