Как вы уже могли узнать, Instagram продается Facebook за $1 млрд. У многих возник вопрос: За что такие деньги? Кто-то на хабре сравнил это с бумом доткомов. Да только весь этот бум на одном Facebook и держится.
В течении двух лет CEO Instagram Kevin Systrom думал, как же монетизировать свое быстрорастущее детище, но так и не придумал. При том много раз просказльзывали слухи о его отказе в сделке с Facebook. Автоподсказчик Google уже давно выдавал первым вариантом к запросу «kevin systrom» фразу «Kevin Systrom net worth». Дела шли в гору и без Facebook.
Неделю назад они выпустили приложение на Android и продались Facebook за сумму с 9 нулями в долларах. Владельцы андроидов были рады:
Разработчики же, не очень: «Куда так топят? За что им платят? Я тоже так могу, там же ничего сложного и инновационного!» кричал каждый второй разработчик на Android / iOS.
Лично я ждал падения сервиса в день релиза приложения в магазине Google Play. Но этого не случилось. Количество зарегистрированных пользователей в первые 24 часа составило около миллиона человек. Немалая цифра, я вам скажу.
И как же команде из 9 человек удалось вытерпеть такой наплыв и не сломаться?
Вот как (все данные достоверно взяты из блога разработчиков Instagram):
Дабы следить за всем, что происходить внутри, надо как-то мониторить всю активность. Обычно это два типа активности: какие-то количества (counters, регистраций в секунду, например) и какие-то интервалы времени (timers, сколько по времени занимает лайкнуть винтажное фото, например). Но как быть, когда у тебя не одна машина на балконе, а пара десятков в ДЦ, и нам нужен один общий график, а не пара десятков разных? Решение простое -хранить все в одной базе данных. Но операция эта не столь быстра. На выход приходит UDP! Да-да, вместо того, чтобы пихать все в базу данных, мы просто будем кидать специальные пакетики по UDP с данными на один общий сервер, а сервер будет их принимать, суммировать и репрезентовать графически. Так вот, для этого всего в Instagram используют NodeJS daemon called «statsd». Он все это богатство ловит, а затем отправляет их прямиком в Graphite (штуковина для построения графиков, как вы могли догадаться).
Все это очень масштабируемо (в Instagram интервал поллинга стоит 10 секунд), потому позволяет следить за всем происходящим почти realtime.
Для мониторинга PostgreSQL серверов используется PGFouine. Он на основе логов PG сервера строит аналитику, позволяя выявить тяжелые запросы и закешировать их, либо же неоптимизированные запросы, запросы выдергивающие лишние данные и т.д.
Ужасно грустно, когда клиенту вываливается 500 ошибка по истечению таймаута, не так ли? А кто виноват? Все молчат, а единственного свидетеля уже убили (kill -9). На помощь Instagram приходит Bitbucket с их open-source разработкой для Django под названием dogslow. Этот пёс цепляется к каждому запросу в самом его начале, и, ежели по истечению 25 секунд ответа на запрос не пришло, он сливает трейс вызовов куда-нибудь, например, на почту.
С его помощью ребята выяснили, что узким местом являлся memcached, который подвисал при запросах set() и get_many(), генерируя по 50 000 запросов / с, притом не используя весь процессор и, как следствие, тормозя весь процесс.
Основными бекендами для хранения данных в Instagram, Inc. являются Redis & PostgreSQL. Как известно, оба этих движка думали о масштабируемости, потому позволили ребятам «на ходу» подключать слейвы, как только ресурсов начинало не хватать.
В первые 12 часов частота запросов к БД Redis достигла 40 000, что стало сказываться на производительности. На подключение дополнительных серверов ушло не больше 20 минут. Впечатляет, не правда ли?
Для масштабирования Postgre использовались Amazon EBS Snapshots. Для их подключения тоже потребовалось не больше 20 минут, благодаря легко настраивоему AWS окружению, в котором болтаются их мастер-сервера.
Помимо всего этого, ребята написали утилиту node2dm — сервер node.js для отправки push-уведомлений в андроидный C2DM сервис. По их данным, он обработал около 5 млн. уведомлений в тот день. В честь этого, node2dm был подарен сообществу совершенно open-source-но.
В течении двух лет CEO Instagram Kevin Systrom думал, как же монетизировать свое быстрорастущее детище, но так и не придумал. При том много раз просказльзывали слухи о его отказе в сделке с Facebook. Автоподсказчик Google уже давно выдавал первым вариантом к запросу «kevin systrom» фразу «Kevin Systrom net worth». Дела шли в гору и без Facebook.
Неделю назад они выпустили приложение на Android и продались Facebook за сумму с 9 нулями в долларах. Владельцы андроидов были рады:
Разработчики же, не очень: «Куда так топят? За что им платят? Я тоже так могу, там же ничего сложного и инновационного!» кричал каждый второй разработчик на Android / iOS.
Лично я ждал падения сервиса в день релиза приложения в магазине Google Play. Но этого не случилось. Количество зарегистрированных пользователей в первые 24 часа составило около миллиона человек. Немалая цифра, я вам скажу.
И как же команде из 9 человек удалось вытерпеть такой наплыв и не сломаться?
Вот как (все данные достоверно взяты из блога разработчиков Instagram):
Measurements: счетчики и таймеры
Дабы следить за всем, что происходить внутри, надо как-то мониторить всю активность. Обычно это два типа активности: какие-то количества (counters, регистраций в секунду, например) и какие-то интервалы времени (timers, сколько по времени занимает лайкнуть винтажное фото, например). Но как быть, когда у тебя не одна машина на балконе, а пара десятков в ДЦ, и нам нужен один общий график, а не пара десятков разных? Решение простое -хранить все в одной базе данных. Но операция эта не столь быстра. На выход приходит UDP! Да-да, вместо того, чтобы пихать все в базу данных, мы просто будем кидать специальные пакетики по UDP с данными на один общий сервер, а сервер будет их принимать, суммировать и репрезентовать графически. Так вот, для этого всего в Instagram используют NodeJS daemon called «statsd». Он все это богатство ловит, а затем отправляет их прямиком в Graphite (штуковина для построения графиков, как вы могли догадаться).
Все это очень масштабируемо (в Instagram интервал поллинга стоит 10 секунд), потому позволяет следить за всем происходящим почти realtime.
Для мониторинга PostgreSQL серверов используется PGFouine. Он на основе логов PG сервера строит аналитику, позволяя выявить тяжелые запросы и закешировать их, либо же неоптимизированные запросы, запросы выдергивающие лишние данные и т.д.
Зомби-процессы
Ужасно грустно, когда клиенту вываливается 500 ошибка по истечению таймаута, не так ли? А кто виноват? Все молчат, а единственного свидетеля уже убили (kill -9). На помощь Instagram приходит Bitbucket с их open-source разработкой для Django под названием dogslow. Этот пёс цепляется к каждому запросу в самом его начале, и, ежели по истечению 25 секунд ответа на запрос не пришло, он сливает трейс вызовов куда-нибудь, например, на почту.
С его помощью ребята выяснили, что узким местом являлся memcached, который подвисал при запросах set() и get_many(), генерируя по 50 000 запросов / с, притом не используя весь процессор и, как следствие, тормозя весь процесс.
Репликация и рабовладение
Основными бекендами для хранения данных в Instagram, Inc. являются Redis & PostgreSQL. Как известно, оба этих движка думали о масштабируемости, потому позволили ребятам «на ходу» подключать слейвы, как только ресурсов начинало не хватать.
В первые 12 часов частота запросов к БД Redis достигла 40 000, что стало сказываться на производительности. На подключение дополнительных серверов ушло не больше 20 минут. Впечатляет, не правда ли?
Для масштабирования Postgre использовались Amazon EBS Snapshots. Для их подключения тоже потребовалось не больше 20 минут, благодаря легко настраивоему AWS окружению, в котором болтаются их мастер-сервера.
Android-ные фишки
Помимо всего этого, ребята написали утилиту node2dm — сервер node.js для отправки push-уведомлений в андроидный C2DM сервис. По их данным, он обработал около 5 млн. уведомлений в тот день. В честь этого, node2dm был подарен сообществу совершенно open-source-но.
