Переход с серверного решения на статический веб-сайт S3 привел к повышению производительности и снижению затрат.
Последние несколько лет я создавал веб-сайт для размещения бесплатных руководств по программированию. Этот сайт был запущен в 2014 году как увлеченный проект и представляет тысячи часов крови, пота и слез - это моя гордость и радость.
Теперь я понимаю, что это не идеально, но это бесплатно и дает мне возможность отточить свои навыки, одновременно побуждая других изучать программирование. Мой увлеченный проект превратился в успешный и развивающийся побочный проект, который нужно было масштабировать, не обойдясь мне в целое состояние.
Вначале - был сервер
Сайт возник в 2014 году как не более чем набор руководств по разработке игр, которые отражали мои интересы. К январю 2016 года сайт достигал 150–200 пользователей в день.
С годами этот трафик продолжал расти, и спрос на мой единственный сервер продолжал расти. Дополнительный трафик потребовал обновления моих экземпляров сервера Linode - это позволило веб-сайту на основе Laravel продолжить работу без сбоев в краткосрочной перспективе.
После очень долгого создания своего сайта на Laravel и экспериментов, чтобы определить, что работает, я в конечном итоге перешел на Hugo - конструктор статических сайтов, не требующий PHP или модного фреймворка.
В то время переход на Hugo в значительной степени повысил скорость работы сайта. Это также снизило затраты на сервер, поскольку я больше не полагался на базу данных MySQL для размещения контента. Я также выпил AWS kool-aid и перенес свой сайт на микро-экземпляр T2.
Схема архитектуры сайта выглядела примерно так:
Некоторое время все было тихо.
Мой конвейер сборки был отсортирован. Я писал новый контент и пытался улучшить сайт. И трафик рос. Было мирное время.
Задача - производительность
Через некоторое время я начал замечать, что сайт стал тормозить. Производительность веб-сайта стала заметно ухудшаться, и я догадывался, почему это происходит.
При использовании популярного инструмента проверки скорости веб-сайта Pingdom в часы пик я наблюдал огромное время ожидания около 0,8 с в среднем, прежде чем все остальные запросы начали обрабатываться. Окончательное время загрузки составило примерно 1,5–2,5 секунды.
Обратите внимание, что в этом примере наблюдается большое время ожидания второго запроса после разрешения DNS. Эти метрики были получены в период довольно минимального трафика, но они дают некоторое представление о снижении производительности.
План - рассматривая мои варианты
Забегая вперед, я решил, что есть два варианта:
- Разверните балансировщик нагрузки и группу автоматического масштабирования и разверните мое приложение на любом количестве экземпляров T2, которые потребовались.
- Переходите с T2 на S3 с CloudFront.
Вариант 1
Мне очень понравился первый вариант. Недавно я изучал Terraform и создавал устойчивые API Go и уже настроил свой сайт на использование LetsEncrypt только для трафика HTTPS.
Однако этот вариант стоил бы недешево. Такой подход означал увеличение затрат и простаивающую емкость ЦП, требующую большего управления. Мой счет AWS уже постепенно увеличивался каждый месяц, так как я работал с большим количеством сервисов и создавал больше руководств, поэтому я опасался добавлять больше экземпляров в свой счет.
Вариант 2
Я думал, что второй вариант будет гораздо более рискованным. Мне нужно было найти способ перенести мой действующий сайт из экземпляра T2 в корзину S3 с помощью CloudFront и Route53 на интерфейсе для управления трафиком.
Я являюсь активным сторонником шифрования всего, поэтому было жестким требованием, чтобы сайт продолжал обслуживаться через HTTPS. К счастью, этого можно было легко достичь, используя службу Amazon ACM и запросив сертификат с помощью проверки электронной почты.
Решение - мигрировать на статический сайт на S3
Когда дело дошло до миграции моего сайта, первым делом обратился к конвейеру CI / CD. Это было невероятно просто с TravisCI и выглядит так:
language: python install: - wget https://github.com/gohugoio/hugo/releases/download/v0.34/hugo_0.34_Linux-64bit.deb - sudo dpkg -i hugo*.deb script: - hugo --buildDrafts - cp -r scripts public/ deploy: provider: s3 ... all my S3 creds
Каждый раз, когда кто-то фиксирует основную ветку моего репо, это запускает сборку и загружает ее в мое производственное ведро S3.
После того, как конвейер CI / CD был на месте, я внес простое изменение и убедился, что конфигурация корзины правильная.
И вуаля! - все статические файлы, которые я собирался обслуживать, были готовы к работе.
После того, как я был уверен в остальной части моей конфигурации CloudFlare и настройке Route 53, я перенес серверы имен своего сайта, чтобы они указывали на Amazon. Через 24 часа я был готов к работе и успешно завершил миграцию. Теперь я мог списать исходный экземпляр T2.micro.
При настройке распространения CloudFront я выбрал кэширование и обслуживание моего сайта из всех возможных периферийных местоположений.
Это означает, что всякий раз, когда кто-то из Австралии приходит и запрашивает мой сайт, поиск в кеше будет сначала выполняться на периферии - и если это попадание в кеш, время загрузки сайта будет невероятно низким. В противном случае он будет обслуживаться из исходного сегмента S3 и кэшироваться для любых последующих запросов.
Хотя этот вариант стоит дороже, повышение производительности определенно того стоит, и общая стоимость все равно будет намного меньше моих предыдущих ежемесячных затрат.
Особая благодарность Алану Рейду, который помог мне с конфигурацией S3, CloudFront и Route 53.
Результат - быстрее, дешевле, лучше!
После завершения миграции результаты были ошеломляющими. Я снизил время загрузки с 1,5–2,5 до чертовых 234 мс, как показано на скриншоте ниже. Это безумное улучшение производительности.
Посмотрите на время запросов: большая часть времени уходит на разрешение DNS, и даже тогда это чуть более 0,1 секунды.
Согласно Pingdom, мой сайт теперь работает быстрее, чем 99% всех других протестированных сайтов. И, как видите, есть еще несколько вещей, которые я могу улучшить!
Но самое поразительное в этой миграции то, что она не только резко повысила производительность моего сайта, но и повысила отказоустойчивость, поскольку я больше не полагаюсь на один экземпляр T2, поддерживающий меня.
Что касается экономики, то стоимость хостинга сайта была снижена с примерно 20 долларов в месяц до примерно 7 долларов в месяц:
- Route53 стоит около 0,50 доллара в месяц.
- CloudFront стоит около 6,50 долларов США в месяц.
- И небольшая сумма тратится на хранилище ведра S3.
Это невероятная экономия, которая успокаивает меня. Если когда-нибудь звезды сойдутся, и мой сайт увидит огромный всплеск трафика, он будет устойчивым, не обойдясь мне в целое состояние!
Заключение
Мы опробовали множество различных способов развертывания и размещения статического сайта, и это, без сомнения, один из лучших подходов.
Это идеальное сочетание производительности и стоимости. Простота делает его доступным выбором для всех, кто хочет разместить свои собственные сайты, обладающие высокой устойчивостью и масштабируемостью.
Надеюсь, вам понравилась эта захватывающая история о турбулентности и триумфе! Если вы поддержали и хотите меня поддержать, то, пожалуйста, посетите мой канал на YouTube или добавьте меня в LinkedIn!
