Хотя большинство из нас создали действительно классные сайты, на самом деле, немногим разработчикам приходилось беспокоиться о сложности управления и масштабирования невероятно больших сайтов. Одно дело — создать сайт для небольшой компании, чтобы обеспечить их широкое присутствие, а другое — выяснить, как масштабировать ваш сайт, чтобы он не сгибался под нагрузкой тысяч пользователей.
Мне посчастливилось поболтать с людьми на флеш-сайте Gilt.com, который за последние годы получил немало прессы и увидел огромный рост. Именно такие возможности позволяют нам исследовать команду, которая управляет этими сайтами, и узнавать, как они справляются со своими повседневными делами и технологиями.
В этом интервью Эрик Боумен (Eric Bowman) , вице-президент по архитектуре в Gilt Groupe, расскажет нам об истории сайта и технических решениях, обеспечивающих бесперебойную работу сервиса.
В Не могли бы вы рассказать нам о себе?
Я невероятно горжусь тем, чего достигла команда.
Я работаю в Gilt с августа 2011 года, а в декабре 2011 года стал вице-президентом по архитектуре и проектированию платформ. За это время мы перешли с Java на Scala, приняли Gerrit для проверки кода, внедрили систему непрерывной доставки, которую мы Позвоните Иону Кэннону (Ion Cannon), который представил архитектуру безопасных типов клиентов и микросервисов, развернул Play 2 для нашего интерфейса, создал общедоступный API и развернул разработку платформы в качестве организационной архитектуры. Я невероятно горжусь тем, чего достигла команда. До Gilt я был архитектором в TomTom в Амстердаме и отвечал за их онлайн-карту, API для поиска и трафика и продукты. До этого я был архитектором, работающим над предоставлением услуг для 3-х глобальных предложений по запуску 3G, и давным-давно моей первой «настоящей» работой было создание The Sims 1.0.
В Не могли бы вы рассчитывать на наших читателей о масштабе / размере Gilt.com, чтобы они лучше понимали объем усилий, необходимых для создания крупномасштабного сайта?
Модель флэш-продаж представляет собой уникальную техническую проблему, потому что большая часть трафика приходит в эти невероятные импульсы по мере появления новых продаж. В течение нескольких секунд наш трафик может возрасти в 100 раз, что действительно создает нагрузку на каждую часть системы, причем сразу. По сути, нам нужно иметь инфраструктуру электронной коммерции почти в масштабе Amazon, по крайней мере, 15 минут каждый день. В большинстве случаев это происходит ровно в полдень по восточному поясному времени, и до тех пор, пока пару лет назад полдень не был напряженным временем каждый день. В настоящее время это, как правило, не событие — отчасти потому, что наше программное обеспечение великолепно, а с другой — благодаря лучшему пониманию производительности и поведения системы.
Чтобы учесть импульс, мы склонны к избыточному обеспечению со стороны аппаратного обеспечения. Наша производственная среда, ориентированная на клиента, на данный момент состоит из около 40 физических серверов, на которых работает пара сотен микросервисов и несколько десятков приложений, ориентированных на пользователя. Кроме того, у нас есть еще около 100 серверов для разработки, тестирования, хранения данных, аналитики и инфраструктуры разработки.
В: Когда речь заходит о крупных веб-ресурсах, большинству разработчиков любопытно узнать, какая технология работает под капотом. Не могли бы вы поделиться тем, что вы используете, и что подтолкнуло вас к выбору технологий?
Что касается базы данных, мы сильно зависим от PostgreSQL, MongoDB и Voldemort.
Изначально Gilt был приложением Ruby on Rails с бэкэндом PostgreSQL. У нас были серьезные проблемы с масштабированием Rails для обработки полуденного импульса, и основные системы, ориентированные на клиента, были очень быстро перенесены на Java и грубую, ориентированную на сервисы архитектуру, начиная с 2009 года. Мы сохранили Java на крайне низком уровне технологий: JDBC, хешмапы и JSP.
Производительность и масштабируемость низкотехнологичных инструментов на JVM поражает. Однако по мере развития технической организации в Gilt командам становилось все труднее вносить код. Недостатком низкотехнологичного подхода было то, что контракты между системами не были четко определены, а наиболее важные базы кода со временем становились монолитными. Мы постепенно перешли от чисто сервисной реализации, основанной на сервлетах, к JAX-RS, и параллельно все больше к Scala. Наш сервисный стек похож на Dropwizard, который появился через несколько лет после того, как мы создали нашу внутреннюю платформу, основанную на Джерси и Джексоне 2. Нам нравится Dropwizard, но мы обнаружили, что способ настройки приложений — в частности, во время выполнения — не был » t очень совместим с нашей инфраструктурой, которая использует ZooKeeper для обнаружения и настройки для каждой среды.
Мы также перешли из Ant в sbt за последний год. В TomTom я полюбил Maven и провел некоторое время, пытаясь представить его в Gilt. В тот момент, когда все стало на свои места, я изменил свое мнение и провел несколько экспериментов с sbt. Мы обнаружили, что sbt предоставляет фантастические возможности для разработчиков и обладает невероятно мощной моделью расширения. Переход на sbt позволил до некоторой степени настроить инструментальные средства, которые раньше казались невозможными, и многие из них вышли из-под контроля sbt, такие как глубокая интеграция с нашей системой непрерывной доставки и автоматическое обновление зависимостей — вещи, которые мы даже не могли себе представить с такими инструментами, как Ant или Maven. Это был интересный случай, когда ограничения инструментов ограничивали наше воображение, и важный урок для меня лично в том, как распознать и избежать этого антипаттерна.
Что касается базы данных, мы сильно зависим от PostgreSQL, MongoDB и Voldemort. PostgreSQL был частью стека Gilt с самого начала, и это было потрясающе. Мы были одним из спонсоров, поддерживавших разработку горячего резервирования, ключевой функции PostgreSQL 9.0, которая обеспечивает точную репликацию. Мы запускаем его на картах Fusion-io, и производительность была феноменальной. Наш технический директор Майкл Брайзек (также один из основателей Gilt) недавно выпустил действительно хороший механизм обновления схемы с открытым исходным кодом для PostgreSQL. В целом мы перешли от приложения монолитной базы данных к отдельным частным базам данных для каждой службы. PostgreSQL действительно хорош для этого, и его стабильная, предсказуемая производительность делает его простым для прогнозирования поведения системы и разумного предоставления ресурсов.
И MongoDB, и Voldemort стали играть все более важную роль в последний год или около того. Волдеморт был частью стека Gilt в течение некоторого времени, хотя использование Волдеморта не росло вообще до этого года. Несмотря на меньшую динамику, чем у других NoSQL-решений, мы считаем, что Voldemort невероятно надежен и прост в размышлениях, и постепенно мы внедрили его еще в нескольких местах. Мы завернули его и включили в нашу базовую платформу, что упрощает его использование в новых сервисах; его легко встраивать, что приводит к тому, что для запуска надежного хранилища ключей в стиле «Динамо» почти не требуется дополнительная инфраструктура. Мы также рассмотрели ряд других решений в этой области, в том числе Riak, и мы весьма взволнованы всей активностью в этой области, особенно в отношении баз данных с несколькими хозяевами и строгой семантикой разрешения конфликтов.
MongoDB также становится все более важным в Gilt за последние пару лет. Сегодня мы запускаем наши основные службы пользователей и аутентификации на MongoDB — абсолютно важные данные с очень высокой пропускной способностью и низкими требованиями к задержкам — и они работают уже долгое время и очень гладко. MongoDB иногда испытывает трудности в сообществе, но мы обнаружили, что он работает удивительно быстро при работе на высокопроизводительном оборудовании, и мы неохотно рассматривали другие варианты из-за его необработанной производительности в нашем случае использования.
В Концентрируясь на масштабируемости конкретно, каковы были ваши ожидания при запуске Gilt и как вы готовились к запуску трафика и росту после запуска?
Gilt рос быстрее, чем кто-либо мог себе представить, и все были застигнуты врасплох тем, насколько сложно было масштабировать стек Rails. Как и любой успешный стартап, Gilt был собран точно в срок, и основная часть усилий была потрачена на то, чтобы отреагировать на то, что рынок отозвался, перед лицом такого большого интереса общественности к тому, что Gilt пытается сделать. Стартапы в этой ситуации должны маневрировать острием «достаточно» архитектуры. Если вы слишком много или слишком долго продумываете или слишком сильно задумываетесь, невозможно двигаться достаточно быстро, чтобы захватить рынок, на который вы идете. Но если вы недостаточно разбираетесь в архитектуре, вы не сможете адаптироваться, когда у вас что-то будет работать. Основной технический стек Gilt всегда принимал простоту как ключевую особенность, и поддержание этого в течение долгого времени было достойной задачей.
В: После запуска и, очевидно, используя ретроспективный анализ, какие решения, по вашему мнению, были на месте, и на какие вы хотели бы перейти?
Решение использовать PostgreSQL было точным. Несмотря на проблемы масштабирования с Rails, это удивительная основа для быстрого перемещения — пока вам не понадобится масштабирование. Так что это не обязательно было неправильным решением, и многие внутренние системы Gilt сегодня написаны на Rails. Если бы мы начинали сегодня, мы, вероятно, основывались бы на Play 2.
В Какие технологии вы использовали, которые конкретно помогли с точки зрения масштабируемости?
С точки зрения технологии мы обнаружили, что JVM очень масштабируема. Со временем появился ряд инструментов, облегчающих масштабирование. Scala, ZooKeeper, RabbitMQ, Apache Camel и Kafka приходят на ум как важные для масштабируемости.
Однако масштабируемость в Gilt связана не столько с конкретными технологиями, сколько с архитектурой и подходом. Мы никогда не боялись переосмысливать вещи практически с нуля, а масштабирование — это многоплановая проблема, охватывающая технологии, инфраструктуру, архитектуру и организационную структуру. Мы перебрали все четыре оси.
Q Будучи компанией, ориентированной на коммерцию, защита данных клиентов, я уверен, является приоритетом № 1. С точки зрения безопасности, как вам пришлось адаптировать свою инфраструктуру, чтобы приспособиться к постоянно меняющемуся ландшафту безопасности?
Очевидно, мы очень серьезно относимся к безопасности и конфиденциальности наших клиентов. Я не хочу вдаваться в подробности, но кое-что выделяется. Мы очень серьезно относимся к соблюдению PCI, и каждый участвует на каком-то уровне в процессе проверки PCI. Мы спроектировали наши системы, используя переборочный подход к соответствию PCI, который физически ограничивает то, что должно быть PCI-совместимым, а также снижает риск в случае ряда возможных сценариев нарушения, которые мы моделируем. Мы нашли архитектуру микросервисов, а постоянные поставки делают нас относительно недорогими, чтобы оставаться передовыми с точки зрения передового опыта, связанного с безопасностью, и поэтому мы стараемся это делать.
В соответствии с этим, какой аспект безопасности был наиболее сложным для управления?
Самой большой проблемой на сегодняшний день является создание реалистичной модели того, что на самом деле представляют собой риски, а затем принятие правильных решений для снижения этих рисков. Несмотря на слова о том, что безопасность является проблемой для всех, на практике разработчикам сложно постоянно помнить о безопасности. Мы больше сосредоточились на архитектуре, которая простителен и разделена так, чтобы мы не ставили под угрозу безопасность и уменьшали объем любой конкретной потенциальной ошибки.
Q Как программное обеспечение с открытым исходным кодом сыграло роль в Gilt, как с технологической, так и с финансовой точек зрения?
С финансовой точки зрения, открытый исходный код помог нам снизить наши расходы, а также помог нам двигаться быстрее.
Gilt построен почти полностью с использованием программного обеспечения с открытым исходным кодом. Мы активно поощряем наши инженерные команды использовать и вносить свой вклад в открытый исходный код, и у нас есть действительно практические рекомендации относительно того, как внести свой вклад в открытый исходный код. У нас есть несколько проектов с открытым исходным кодом, которые мы размещаем в нашем репозитории GitHub , и мы постоянно направляем запросы на извлечение исходных данных в некоторые из наиболее важных проектов с открытым исходным кодом, которые мы используем. Мы также активно поддерживаем усилия с открытым исходным кодом, от разработки средств финансирования в PostgreSQL до спонсирования конференций Scala, таких как Scala Days.
С финансовой точки зрения, открытый исходный код помог нам снизить наши расходы, а также помог нам двигаться быстрее. Помимо очевидного преимущества не оплаты лицензионных расходов, открытый исходный код предоставляет более тонкое преимущество, заключающееся в том, что когда вы сталкиваетесь с проблемой, будь то тривиальная или катастрофическая, вы можете как посмотреть исходный код, так и потенциально решить проблему. Я начал разрабатывать в среде с закрытым исходным кодом, и я не пропускаю те дни, когда все было черным ящиком, а лицензии были чрезвычайно ограничены с точки зрения того, что вы можете сделать — или, в некоторых случаях, даже сказать о — коммерческое программное обеспечение.
В Когда вы рассматривали конкретную технологию на основе OSS, каков был ваш процесс принятия решений для определения ее жизнеспособности, применимости к вашим потребностям и долгосрочного управления технологией?
Мы стараемся активно следить за последними разработками в ряде проектов с открытым исходным кодом, читать блоги, и, как правило, все мы любим технологии и склонны волноваться. Поэтому иногда трудно избежать иррационального изобилия, которое может последовать, если вы прочитаете слишком много постов в блоге и поверите всему обману. У нас есть внутренняя система рецензирования, которая поощряет легкую дисциплину планирования и архитектуры, которая работает довольно хорошо. Мы также используем такие вещи, как технический радар ThoughtWorks, чтобы помочь справиться с чрезмерным изобилием, а также получить представление о том, что хорошо работает в отрасли, с помощью другого взгляда.
Наш подход также зависит от того, насколько критичным является программное обеспечение. В Gilt мы много говорим о «Добровольном усыновлении», которое активно поощряет наших разработчиков выбирать лучшие инструменты для работы. На практике это означает, что у отдельных команд есть много возможностей с точки зрения использования любых библиотек с открытым исходным кодом, которые они хотят, и когда это идет хорошо, это помогает сохранять простоту — и также помогает нам двигаться быстрее. Обычно преимущества этих библиотек очевидны; Мы склонны предоставлять отдельным командам возможность правильно анализировать компромиссы и стоимость конкретного решения. Это борьба за то, чтобы избежать слишком большой фрагментации по всей организации, и мы активно работаем над тем, чтобы понять, когда командам необходимо использовать довольно экзотические библиотеки, и включить их в основную платформу таким образом, чтобы минимизировать трудности при обновлении и «адскую зависимость». «
Для более важных совместно используемых компонентов и систем мы склонны использовать сочетание консенсуса, экспертной оценки и стресс-тестирования для принятия решений. Иногда мы смотрим на систему, и она настолько явно превосходит другие варианты, что достичь консенсуса легко, и мы быстро переходим к принятию. ZooKeeper является примером этого. В других случаях, когда выбор менее ясен, мы склонны просто раскручивать различные альтернативы и запускать их до тех пор, пока они не сломаются, и попытаться понять, почему они потерпели неудачу, если они потерпели неудачу. Например, при оценке систем обмена сообщениями мы обнаружили, что прокачка миллиарда сообщений с максимально возможной скоростью через нескольких претендентов — это довольно хороший способ устранить неправильный выбор с помощью критерия «последний стоящий человек».
На данный момент наш подход довольно легкий и гибкий, и мы надеемся сохранить его таким. Микросервисы и уникальный подход к развертыванию позволяют нам опробовать вещи в производстве, чтобы увидеть, как они работают, без особого риска. В конечном счете, как система работает в производстве, является наиболее важным критерием, и вы не можете угадать его с помощью документов и совещаний. Мы пробуем вещи и используем то, что работает.
Q OSS сильно зависит от вклада сообщества. Как Gilt возвращает сообщество OSS?
Что касается JavaScript и Ruby, мы открыли множество библиотек.
Что касается Java и Scala, мы внесли свой вклад не так много и не так быстро, как хотелось бы, из-за некоторых особенностей работы нашей сборки, которые затрудняют создание некоторых из наших основных программных продуктов вне инфраструктуры Gilt. Мы активно работаем над улучшением этого, и у нас есть резервы программного обеспечения Java и Scala, и мы с нетерпением ждем открытия источников в ближайшие полгода или около того.
Что касается JavaScript и Ruby, мы открыли множество библиотек, большинство из которых доступны на нашей странице GitHub.
Например, мы также финансировали определенные функции PostgreSQL и регулярно спонсируем конференции по темам с открытым исходным кодом — в первую очередь, Scala в недавнем прошлом. Мы также являемся крупными сторонниками технологических групп, в которых у нас есть наши основные инженерные центры (Нью-Йорк и Дублин) — открывая наши офисы для проведения местных встреч, собраний технологических групп и даже бесплатных бесплатных курсов в течение всего дня.
Мы также включаем открытый исходный код в наш процесс найма, поскольку мы склонны отдавать предпочтение разработчикам, которые занимаются открытым исходным кодом. В целом мы видим, что это отличный признак того, что разработчик привык к коду, который читается, а также имеет приоритеты, совпадающие с тем, как мы пытаемся развиваться в Gilt.
В заключение
Эрик, я хотел бы поблагодарить вас за то, что вы нашли время поговорить с нами о Гилте. Мы ценим прозрачность и удобство, которыми вы пользуетесь, разделяя многие архитектурные основы такого объекта с высокой посещаемостью. Сложность и разнообразие используемых вами технологий показывает, что для масштабирования сайта требуется нечто большее, чем просто выбор стека и работа с ним. Это также демонстрирует, что важно объективно рассмотреть все доступные варианты и выбрать (иногда адаптировать) другие продукты, которые могут помочь вашему бизнесу добиться успеха.