Instagram - всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

Начало:

• 1 сервер слабее Macbook Pro
• 25к регистраций в первый день
• 2 разработчика

Сегодня:

• 40+ миллионов пользователей
• 100+ виртуальных серверов в EC2, в том числе:
• Проект куплен Facebook за 1 млрд. долл
• 1 миллион регистраций за 12 часов после запуска Android-версии
• 5 разработчиков

Технологии

• UbuntuLinux 11.04 - основная операционная система
• Python - основной язык программирования серверной части
• Django - фреймворк
• Amazon:
  • EC2 - хостинг
  • ELB - балансировка входящих HTTP-запросов
  • Route53 - DNS
  • S3 - хранение фотографий
  • CloudFront - CDN
• nginx - второй уровень балансировки входящихHTTP-запросов
• gunicorn - WSGI-сервер
• HAProxy - балансировка нагрузки внутри системы
• PostgreSQL - основное хранилище данных
• postgis - поддержка гео-запросов
• pgfouine - отчеты на основе логов
• pgbouncer - создание пула соединений
• Redis - дополнительное хранилище данных
• Memcached - кэширование
• Gearman - очередь задач
• Solr - гео-поиск
• munin, statsd, pingdom - мониторинг
• Fabric - управление кластером
• xfs - файловая система

Философия

1. Простота
2. Минимизация операционных издержек
3. Использование подходящих инструментов

История

• Забыли сделать favicon.ico до запуска - в первый же день логи пестрили ошибками 404
• Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
• Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
• Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
• Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
• Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
• Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
• Следующим шагом стало горизонтальное разбиение данных (sharding):
• Создали несколько тысяч логических баз данных.
• Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
• Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
• По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
• С некоторыми задачами лучше справляется Redis:
• Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
• При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
• Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
• В Redis также хранится информация о сессиях.
• Несколько фактов о Redis:
  • Так как все находится в памяти - очень быстрые операции записи и работы с множествами.
  • Является не заменой, а дополнением к основному хранилищу данных.
  • Redis хорош для структур данных, которые относительно ограничены.
  • Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например - счетчики, подмножества, проверка вхождения в множества).
  • Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
• Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
  • Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
  • Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
• Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
• С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
• избежать необходимости дешифровки SSL посредством nginx;
• ускорить исключение из балансировки проблемных серверов.
• Благодаря использованию xfs есть возможность "замораживать" и "размораживать" дисковые массивы при резервном копировании.

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

• Многие проблемы с масштабируемостью - результат банальных человеческих ошибок.
• Масштабирование = замена всех деталей в машине на скорости 150 км/ч.
• Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
• В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
• Дополните свое основное хранилище более гибким компонентом, вроде Redis.
• Постарайтесь не использовать два инструмента для решения одной и той же задачи.
• Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
• Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
• Активное юнит- и функциональное тестирование стоят потраченного на них времени.
• DRY: не делайте одну и ту же работу несколько раз.
• Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
• Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
• Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
• Короткий цикл разработки - залог быстрого развития.
• Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
• Не изобретайте велосипед.
• Окружите себя с толковыми консультантами.
• Культура открытости вокруг разработки.
• Делитесь с opensource сообществом.
• Фокусируйтесь на том, что вы делаете лучше всего.
• Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
• Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
• Не рассчитывайте, что "кто-то еще присоединится к команде и разберется с этим".
• Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

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

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.