У меня большой и загруженный сайт; в настоящее время он полностью работает на выделенном сервере, который я арендую каждый месяц за ~ 700 долларов.
Он состоит из трех частей, которые, я думаю, можно выделить в облачное решение:
Хостинг медиафайлов (изображений / видео). В настоящее время у меня есть около 236 ГБ статических изображений, которые сейчас припаркованы на моем сервере. Если бы я переместил их в облако, я бы, вероятно, объединил их с CDN (чтобы минимизировать стоимость передачи данных из облачной службы для каждого запроса изображения).
База данных. В настоящее время на моем сервере запущен MySQL с объемом данных около 3 ГБ.
Веб сервер. На том же сервере работает nginx, обслуживающий статические файлы и PHP.
Сейчас у меня нет проблем с производством, но я ожидаю, что в следующем году трафик и нагрузка на сервер увеличатся вдвое. Итак, сейчас я хочу подумать о масштабируемости.
Мой вопрос заключается в следующем: как я могу понять, будет ли рентабельно переместить все или все это на облачную платформу вместо того, чтобы хранить их на моем текущем сервере?
(Я уже знаю некоторые другие факторы: было бы проще делать резервные копии с помощью облака, у меня не было бы одной точки отказа, как сейчас, с моим единственным сервером и т. Д. Но я не знаю, сколько больше / меньше стоило бы выделить одну из этих служб. Как я могу это вычислить?)
РЕДАКТИРОВАТЬ - спасибо всем за эти замечательные ответы и комментарии. Несколько человек запросили дополнительную информацию, поэтому я суммирую все ниже и добавляю еще немного данных:
Используемая передача данных («Пропускная способность») - сайт отправляет ~ 17 ТБ исходящих данных в месяц (!), и я планирую удвоить эту цифру в следующем году (!!). Почти весь исходящий трафик - это статические носители (фотографии и видеоклипы), поэтому, возможно, CDN будет хорошей идеей не только для лучшей обнаруживаемости, но и для облегчения передачи всех этих данных в сеть CDN, чтобы сервер хранения мультимедиа не имеет столько передачи данных напрямую. - РЕДАКТИРОВАТЬ: кажется, что CDN чертовски дороги для такой передачи данных. Так что, возможно, статический носитель останется на простом сервере, который дает мне очень высокую пропускную способность (привет, OVH!), И если я смогу найти экономичный способ поставить перед ним CDN, это будет потрясающе.
Трафик не резкий - мой трафик достаточно стабильный; Моя цель при переходе на более облачное решение - иметь возможность легко масштабироваться. Т.е. в моей текущей настройке все находится на одном жестком диске, и он заполнен на 60%; эта инфраструктура буквально не могла справиться с удвоенным объемом данных (и я не уверен, что у нее будет достаточно вычислительной мощности для запуска веб-сервера и сервера БД с удвоенным трафиком).
Статические СМИ - Как я уже упоминал выше, у меня около 236 ГБ статических носителей, в основном все изображения и видеоклипы. Это кажется наиболее очевидным (и, возможно, самым простым?) Фрагментом, который нужно сначала вырезать и поместить в облако.
База данных - хотя сейчас БД работает нормально, скоро у меня появятся более сложные запросы, и мне понравится идея чего-то более мощного. Поэтому, хотя я не думаю, что мои текущие потребности (мощность и объем данных) диктуют необходимость переноса сервера БД в облако, все дело в возможности масштабирования.
Часы пик - Я всегда при наименее 1000 пользователей на сайте 24/7, жадно потребляющих медиа. Сервер никогда не простаивает.
Выделенный сервер в настоящее время - Я оговорился раньше и сказал, что это коло (подразумевая, что оборудование было у меня). Это было неправильно. У меня есть выделенный сервер (принадлежит моей хостинговой компании), который я арендую каждый месяц. Не большая разница, но просто хочу упомянуть.
Обновить
AWS будет взимать 3300 долларов в месяц за 35 ТБ исходящей пропускной способности. Пять самых больших инстансов Lightsail будут стоить чуть более 800 долларов и будут включать в себя 35 ГБ трафика. Я предполагаю, что вы можете использовать пропускную способность экземпляра, если используете балансировщик нагрузки. Их цены на CDN принесут вам 2300 долларов в месяц. Вам, вероятно, понадобится другой сервер в качестве веб-сервера, так что лучшая часть 1000 долларов в месяц.
Учитывая ваши потребности в пропускной способности, я бы исключил EC2 / CloudFront. Вы можете рассмотреть Lightsail и балансировщик нагрузки после того, как убедитесь, что балансировщики нагрузки эффективно используют пропускную способность экземпляра. Однако остаться с другом может быть проще, хотя и менее гибким.
Предыдущий пост
MLu предоставил вам хороший вариант, но изменение архитектуры веб-сайта может оказаться трудным. Просто переместить хостинг изображений на S3 с помощью CloudFront (или CloudFlare) может быть довольно просто и будет дешевле и быстрее, чем хостинг самостоятельно.
Основное предложение
Если вам просто нужен VPS, разработайте спецификации, необходимые с точки зрения ЦП / ОЗУ / диска, и поместите его в Калькулятор AWS. Не обращайте внимания на предупреждение об использовании нового калькулятора, новый калькулятор не очень хорош.
LightSail - дешевый путь в AWS - особенно дешево пропускная способность. Вы можете получить 8 ядер, 32 ГБ ОЗУ и передачу 7 ТБ за 160 долларов в месяц, что будет стоить около 330 долларов за сервер плюс 600 долларов за пропускную способность. Объедините пару из них (или меньших экземпляров) с Балансировщик нагрузки Lightsail вы получаете много энергии за небольшие деньги. Lightsail - это много проще, чем полный AWS.
Предложение по архитектуре
Ваш лучший вариант для вашей архитектуры:
Сложная часть здесь - это определение размера ресурсов. Вы можете сделать предположение, основываясь на использовании ЦП, просматривая "верх", если хотите.
RDS
RDS вам необходимо рассчитать для пиковой нагрузки. Допустим, у вас сейчас 4-ядерный сервер, и MySQL, похоже, использует два ядра на пике, тогда вам, вероятно, понадобится двухъядерный сервер RDS MySQL.
Сопоставление этого с типом экземпляра зависит от вашего непикового использования. Инстансы T2 / T3 дают вам небольшую долю ЦП, а порой можно использовать больше ресурсов. Если у вас много времени, когда веб-сайт не занят, он может накапливать ресурсы ЦП в непиковые часы, используйте их в часы пик. db.t2.medium дает вам два ядра и 4 ГБ ОЗУ, db.t3.medium дает вам 2 ядра, 8 ГБ ОЗУ и больше кредитов ЦП. Если веб-сайт большую часть времени довольно загружен, вам понадобятся выделенные процессоры, db.m5.large предоставит вам два ядра. Вы можете довольно легко изменить тип БД, но будет некоторое время простоя, если у вас нет экземпляра multi-az (погуглите этот термин, чтобы узнать больше).
EC2
EC2 может быть более гибким, поскольку вы можете масштабировать количество экземпляров в зависимости от нагрузки. Вы можете выбрать m5.large (или m5a для AMD, или m6g для ARM) в качестве базового сервера с 2 ядрами и 8 ГБ ОЗУ. При достижении порогового значения, скажем, 60% использования ЦП, AWS может развернуть столько инстансов, сколько требуется, чтобы справиться с нагрузкой, а затем отключать их, когда они не нужны. Обычно экземпляры t2 / t3 не используются в балансировщике нагрузки, так как у них могут закончиться кредиты ЦП, что усложняет задачу.
Размеры и цена
Как только вы определитесь с архитектурой и размером, вы можете подключить это к калькулятору AWS. Вам понадобится экземпляр RDS, экземпляры EC2, учетная запись для исходящей пропускной способности с сервера, учетная запись для хранения образов S3 и пропускная способность образов, дисковое пространство EBS и моментальные снимки для резервного копирования, а также пространство для образа AMI для автоматического масштабирования. Тогда вы, вероятно, захотите, чтобы такие службы, как Guard Duty, контролировали вашу учетную запись (дешево), журналы CloudTrail в качестве журналов аудита, которые являются просто ценой хранения, и другие мелочи. Он может начать складываться.
Пропускная способность AWS может быть очень дорогой. Прежде чем углубляться в детали расчета, сделайте приблизительное предположение, например, о базе данных db.m5.large RDS, паре экземпляров m5.large EC2, 300 ГБ диска EBS и исходящей пропускной способности. Если вы используете большую полосу пропускания, это может стоить больше, чем ваш текущий co-lo. Если большая часть вашей пропускной способности - это статические ресурсы, внешний CDN, такой как CloudFlare, может значительно снизить ваши расходы, если вы правильно настроите заголовки кеширования. Я не знаю, сколько из ваших 236 ГБ они будут кэшировать, но они кешируют все часто используемые файлы. Все их более чем 100 центров обработки данных будут загружать ресурсы с вашего сервера, поэтому вы по-прежнему будете использовать значительную часть пропускной способности.
Я сознательно не объяснил все термины, которые использовал. AWS сложен, и его может быть сложно сделать правильно и безопасно. Вы действительно хотели бы пройти некоторое обучение, чтобы понять AWS, прежде чем начать его использовать. Как только вы поймете, AWS очень мощный, но может потребовать много времени. Или просто используйте Lightsail, как указано выше.
Когда вы думаете о цене, здесь есть только одно беспокойство: Public Cloud продает с точки зрения виртуальный ЦП (в основном гиперпоточность) с несколькими поколениями ЦП.
Итак, не учитывайте: 1 локальное ядро = 1 облачный процессор. Это неправильно!
Максимум рассмотрите: 1 локальный гиперпоток = 1 облачный процессор. Это почти право!
«почти» здесь связано с тем, что разные поколения процессоров имеют разную производительность гиперпотоков.
С другой стороны, учтите, что очень часто локальные спецификации завышены. Так что оцените свои потребности в энергии, прежде чем сравнивать процессоры.
затем онлайн-калькуляторы - ваши друзья для приблизительной оценки.
Как показывает практика, использование облака всегда дороже, чем использование выделенных серверов. Например, для моих частных проектов у меня есть довольно мощный сервер (металлический), который стоит мне 40 евро в месяц, который будет стоить мне более ста евро в месяц на AWS.
Если вы ведете бизнес, это не ваш реальный расчет затрат. Для моего собственного сервера мне нужно сделать:
Для частного лица эти вещи по сути бесплатны. Я занимаюсь ими в свободное время, и выяснять, как это делать, может быть весело. В результате я плачу 40 евро в месяц за свой сервер, и это все мои расходы.
Для компании все это стоит денег. Все это должен делать кто-то, кому, скорее всего, платят. Возможно, вам придется нанять администратора сервера или DevOps, который хочет получать по крайней мере высокую пятизначную сумму в год, может быть, даже шестизначную, в зависимости от местоположения. Если вы делаете это сами, это займет время, которое вы могли бы вместо этого потратить на разработку или продвижение своего приложения. Время - деньги.
Облако может спасти вас от всего этого, особенно если вы используете такие вещи, как контейнеризация, которая устраняет необходимость беспокоиться о фактических серверах и требует только обслуживания фактического программного обеспечения, которое вы используете.
Чтобы сказать, будет ли это рентабельным или нет, необходимо принять во внимание административное время. Скорее всего, вы потратите в 4-5 раз больше денег на облачную инфраструктуру по сравнению с выделенным сервером, и расходы будут расти по мере увеличения количества пользователей. Невозможно сказать, будет ли это больше, чем вы потратите на администрирование своей текущей инфраструктуры самостоятельно или наняв системного администратора.
Как частное лицо, я всегда выбираю выделенный сервер.
Для компании это становится сложным расчетом, часто с тенденцией к облаку.
Наивный способ - сопоставить ваши текущие характеристики сервера с одним из предложений облачного экземпляра примерно 1: 1 и повысить его цену. Например. если ваш сервер имеет 4 ЦП / 16 ГБ ОЗУ, то в AWS вы можете посмотреть m5.xlarge это стоит 0,192 доллара в час, что составляет около 140 долларов в месяц. Если вы уверены, что размер инстанса соответствует вашим потребностям, вы можете взять зарезервированный срок на 1 или 3 года, чтобы сэкономить до 60%. Кроме того, вам понадобится дисковое пространство по цене около 0,10 доллара США за ГБ в месяц и стоимость исходящего трафика. Это простой, но потенциально более дорогой способ.
Другой вариант - изменить архитектуру сайта. Храните изображения, например, в Корзина S3 (гораздо более масштабируемая и дешевле на 1 ГБ), что означает, что вы, вероятно, могли бы использовать меньший и более дешевый экземпляр, поскольку он не будет перегружен обслуживанием статических изображений. Точно так же вы можете выгрузить базу данных в управляемую службу базы данных (например, AWS RDS) или использовать базу данных NoSQL, такую как AWS DynamoDB. Но все это может потребовать изменения кода.
Если вы будете счастливы изменить архитектуру веб-сайта и использовать более дешевые облачные сервисы, вы можете значительно сэкономить. Сколько? Это зависит от обстоятельств, нет простого ответа, пока вы не решите, какими услугами вы собираетесь пользоваться.
С другой стороны, если вы просто хотите перейти со своего сервера Colo, например, на облачный сервер, это очень легко вычислить. См. Выше.
Надеюсь, это поможет :)
По сути, я был в той же ситуации, что и вы, но обнаружил, что все предлагаемые виртуальные услуги чрезвычайно сбивают с толку и совершенно непредсказуемы, когда дело доходит до расчета затрат. Так что я арендовал выделенный сервер, что гарантирует фиксированную ежемесячную стоимость для настоящего ЦП и максимальный объем ОЗУ, диска и пропускную способность. Предсказать вашу конечную стоимость несложно по сравнению с использованием «калькуляторов», предлагаемых виртуальными услугами. Поскольку вы уже используете совместно размещенный сервер, которым, как я полагаю, вы владеете, поиск эквивалентного или более мощного выделенного сервера должен быть простым.
700 долларов звучат очень дорого для ваших нужд, и вы сможете найти необходимую емкость и скорость гораздо дешевле. Ввод-вывод будет вашим узким местом.
Раньше я арендовал выделенные серверы у quickpacket, serverhub и needaserver (поскольку приложение требовало избыточных географически распределенных центров обработки данных). Все три поставщика были более или менее сопоставимы по цене, доступности, производительности, поддержке и т. Д.
Поскольку никто еще не упомянул об Azure, вот мои два цента в этом отношении.
В общем, я бы рекомендовал по возможности разобрать вещи и перенести их в сервисы PaaS. Это подготовит ваше решение к росту и принесет много других преимуществ, например например, встроенное резервное копирование, о котором вы уже упоминали, а также масштабирование и дополнительные функции безопасности.
База данных Azure для MySQL
Это решение DBaaS обойдется вам примерно в 100 долларов США. Хранилище будет дешевым (0,69 доллара США в месяц = 5 ГБ * 0,138 доллара США), и оно будет включать еще 5 ГБ хранилища для резервного копирования. Если требуются более длительные периоды хранения резервных копий, могут потребоваться дополнительные расходы на резервное копирование. Что касается вычислительной части, то зарезервированный на один год экземпляр будет стоить около 99 долларов США (общего назначения, 2 виртуальных ядра Intel E5-2673 v4 2,3 ГГц).
Служба приложений Azure
Это будет стоить от 73 до 292 долларов в зависимости от объема памяти, процессора и оперативной памяти, которые требуются вашему PHP-сайту. Я бы выбрал по крайней мере уровень Standard, так как это позволит автоматизировать масштабирование и подключение к виртуальной сети, чтобы ваше веб-приложение могло напрямую взаимодействовать с базой данных MySQL через конечные точки службы (данные остаются на магистрали Microsoft, что обеспечивает задержку и безопасность).
Azure CDN
Исходящий трафик из зоны 1 (Северная Америка, Европа, Ближний Восток и Африка) будет (10'000 * 0,081 доллара США) + (7'000 * 0,075) = 1'335 долларов США в месяц. Плюс ежемесячная плата в размере около 21 доллара США за хранение 250 ГБ данных в статической зоне CDN 1.
Также потребуется учетная запись хранения (см. Ниже). Однако за передачу данных между учетной записью хранения и Azure CDN (только Microsoft, а не Akamai / Verizon) плата не взимается, если объект не находится на периферии.
Учетная запись хранения Azure
Для оценки этого фактора стоимости требуется дополнительная информация, поскольку ежемесячная цена зависит от а) объема данных, хранимых в месяц, б) количества и типов выполняемых операций (наряду с любыми затратами на передачу данных) в) вариантов избыточности данных.
Таким образом, за объем хранилища горячих блочных BLOB-объектов размером 500 ГБ с минимальной избыточностью (LRS) нам придется платить 10,40 долларов США в месяц. Теперь не хватает ценника, который идет с операциями и передачей данных. Для получения более подробной информации смотрите здесь: https://azure.microsoft.com/en-us/pricing/details/storage/blobs/
Подвести итоги:
Это приведет к общему заряду между 1'579 долларов США и 1'798 долларов США в месяц.
Еще один комментарий ко всем остальным ответам:
При определении емкости / ЦП помните, что одним из преимуществ облачных сервисов является возможность масштабирования по мере роста ваших потребностей. Вы не указываете объем трафика или количество сеансов, и т.д., но вы можете начать с относительно малого и увеличивать емкость по мере необходимости, будь то установка более крупных экземпляров или масштабирование с использованием большего количества экземпляров.
Самой большой переменной затрат будет ваш трафик, т.е. сколько трафика вы обслуживаете со своего сайта.
В целом у вас есть два основных компонента:
Обратите внимание, что я перечисляю здесь как веб-сервер на PHP, так и базу данных как одно целое. Перенос их в отдельные облачные сервисы почти наверняка будет стоить вам довольно дорого в краткосрочной перспективе из-за накладных расходов, связанных с изменением архитектуры значительной части сайта, что вряд ли будет тривиальным.
Для первой части вы ограничены только общим объемом памяти. Для большинства предложений вы рассчитываете либо примерно на 30 долларов в месяц (если вы используете блочное хранилище, к которому имеет доступ ваш сервер), либо менее чем на 10 долларов в месяц на хранилище объектов (не считая затрат на балансировку нагрузки / пограничное кэширование, что является вероятно, это будет в основном фиксированная плата в диапазоне 20-200 долларов США).
Во второй части рассмотрим такой сервис, как Vultr Compute Cloud, Digital Ocean Droplets или AWS Lightsail. Все они предоставляют «традиционный» хостинг VPS, где вы получаете X потоков ЦП, Y объема ОЗУ и Z объема дискового пространства в виде одного пакета по фиксированной цене. С ними вы просто выбираете тот, который соответствует по вычислительной мощности тому, что вы уже используете, и переходите оттуда. Цена на них обычно составляет около 10 долларов США за ядро ЦП в месяц, хотя на малом рынке часто бывают более дешевые предложения с одним процессором, которые имеют меньше ОЗУ / хранилища, чем предложение за 10 долларов.
Однако есть еще одна вещь, которую следует учитывать: использование сети. Почти все облачные провайдеры так или иначе взимают плату за использование сети. Обычно вы увидите один из двух подходов:
У большинства также есть некоторый минимальный объем трафика, за который они не будут взимать плату (например, AWS не взимает плату за первые 5 ГБ / месяц исходящего трафика, или Vultr предоставляет вам несколько ТБ полосы пропускания бесплатно, а затем устанавливает пропорциональную ставку. в среднем каждый месяц на ГБ).
Этот конкретный аспект часто упускается из виду, потому что в локальных и совместных настройках вы обычно платите за любое ограничение пропускной способности, которое у вас есть, в то время как облачные предложения обычно имеют очень высокие ограничения пропускной способности (многие облачные предложения гарантируют скорость 40 Гбит, по крайней мере, в одну сторону), но вы платить за единицу переданных данных. В большинстве случаев я слышал, что люди переходят в облако, а затем вынуждены платить намного больше, чем ожидалось, сводятся к этому, так что это то, что вы должны тщательно изучить, прежде чем переходить.
Слишком рано беспокоиться о масштабировании, потому что у вас есть лучшие варианты емкости за меньшую сумму, чем вы платите сейчас.
Я предполагаю, что ваш процессор, нагрузка на память и входные данные сети не имеют большого значения, и стоимость исходящей пропускной способности - единственная реальная проблема.
Я легко могу арендовать выделенный сервер за 50 долларов в месяц с объемом операций ввода-вывода 50 ТБ в месяц, который, вероятно, легко справится с вашими текущими потребностями. В настоящее время вы платите за эквивалент 14 из этих серверов!
Переключитесь на более дешевый выделенный сервер, забудьте об этих дорогих виртуальных решениях и просто подумайте о балансировке нагрузки, если ваши требования когда-нибудь перерастут в один сервер.
Вы можете получить выгоду от перехода на облачную платформу Google, переместив свои статические данные (которые из вашего описания составляют большинство файлов, хранящихся на вашем сервере) в GCP. ведра и хранить ваши статические данные там.
Если вы хотите рассчитать, сколько это будет стоить, вы можете использовать страница цен и сделай математику. Все зависит от того, сколько данных будет храниться, сколько исходящего трафика вы будете генерировать и сколько операций ввода-вывода потребуется.
Или вы можете просто использовать официальную Калькулятор цен на Google Cloud и введите все возможные данные, чтобы получить оценку.
Вы также можете получить ежемесячные расценки на запуск виртуальных машин GCP при создании новых - после того, как вы введете все детали (сколько ядер, оперативной памяти и т. Д.), Вы увидите ежемесячную стоимость. Но это только для бега и экземпляра.
Вы также можете получить дополнительные скидка за обязательное использование.
Вы говорите, что у вас есть 17 ТБ исходящей пропускной способности в месяц, включенной в ваш размещенный сервер за 700 долларов. На самом деле это самая легкая часть всего процесса для оценки. Предполагая, что почти все 17 ТБ составляют статические файлы, которые вы будете обслуживать через S3 или CloudFront, достаточно просто проверить цены AWS (у Google или Microsoft могут быть разные цены, но я менее знаком с их предложениями). Используя 17 000 ГБ в качестве разумного приближения, просто умножьте стоимость на 1 ГБ. Это около 0,08 доллара в США / Канаде (на самом деле 0,085 доллара за первые 10 ТБ). Или всего 1360 долларов. Таким образом, игнорируя любые другие расходы, простой перенос статических файлов в S3 / CloudFront увеличит ваши расходы как минимум на 660 долларов.
Источник: https://aws.amazon.com/cloudfront/pricing/
Сюда не входят затраты на хранение, базу данных или веб-обслуживание, а только затраты на пропускную способность. Так что это очень низкая оценка.
Обратите внимание, что эта миграция может также улучшить вашу способность обслуживать файлы (скорость, надежность и т. Д.). Так что не однозначно, что этого делать не стоит. Но это подчеркивает, что ваши расходы увеличатся, если вы перейдете в облако.
Я также проделал тот же расчет, предполагая, что вы использовали EC2, как и свой локализованный сервер, просто запустив Nginx и напрямую обслуживая статические файлы. Снова игнорируя все затраты, кроме пропускной способности, Калькулятор AWS дал 1530 долларов за 17 ТБ исходящих из EC2 в Вирджинии.
Я подозреваю, что вы можете значительно снизить другие расходы, если перейдете в облако. Похоже, ваша основная стоимость - это пропускная способность. Таким образом, сервера скромного размера (менее 100 долларов в месяц), вероятно, будет достаточно для запуска вашего PHP / MySQL. Но это не меняет того факта, что AWS будет взимать с вас больше только за пропускную способность, чем вы платите сейчас за все.
Как отмечает @ mark-henderson с 17 голосами «за», «Если я буду откровенен, почти никто не переходит в облако, чтобы сэкономить деньги. Люди переходят на AWS / Azure / GCP, думая, что они сэкономят деньги, но обычно их вводили в заблуждение. Люди переходите в облако ради гибкости, избыточности, масштабирования, быстрого прототипирования и множества других причин. Но вы, вероятно, не сэкономите денег ».
CDN хорош, потому что вы можете щелкнуть выключателем и переложить нагрузку на пропускную способность на другого провайдера. К сожалению, CDN обычно дороже, чем собственный хостинг. Итак, давайте поговорим о том, как получить гибкость без дополнительных затрат.
Во-первых, я бы просто выбрался из-под завышенного хостинга. Существуют преобразователи P2V («физический в виртуальный»), которые помогают виртуализировать, поэтому становится проще перемещать рабочие нагрузки по мере необходимости. https://www.vmware.com/products/converter.html
Тогда ДА разбейте все на более мелкие службы. 90% того, что вам нужно сделать, - это отделить изображения от всего остального. Я бы больше подумал о статике и динамике, чем об отдельных сервисах (apache / mysql), и придумал бы стратегию кеширования. Это позволяет вам изменить потребление ресурсов по желанию в зависимости от того, где вы получаете выгодные предложения по пропускной способности и хостингу, ТАКЖЕ улучшая производительность с контентом, который ближе к пользователям.
Работайте над достижением трех целей: (1) масштабируемая / безопасная / отказоустойчивая основная инфраструктура, а затем (2) иметь «глупые» дешевые распределенные ресурсы для кэширования статических / простых вещей (изображений) рядом с пользователями (возможно, всего 1 кэш-сервер в США и другой в ЕС. Любая потребность в Азии?), а затем (3) подумайте, хотите ли вы лучше понять, как кэшировать / распространять данные PHP и БД рядом с пользователем.
Я был бы склонен сохранить кеширование изображений, содержащееся в одном офигительном решении "сделай это просто" (№2), а затем во всем остальном в пункте №3.
# 1 сначала ЗАЩИЩАЙТЕ ЯДРО..... просто убедитесь, что функциональность вашего основного сайта максимально устойчива к сбоям оборудования, сетевым проблемам, стихийным бедствиям и т. Д. Вот что мне нравится в VMware. О многом позаботятся, даже не задумываясь об этом (распределенное зеркальное отображение данных, переключение на альтернативное оборудование или даже другой центр обработки данных и т. Д.). Но я рекомендую НЕКОТОРЫЕ виртуализированные / контейнерные решения, чтобы вы могли больше беспокоиться о своей физической инфраструктуре. товара и намного более отчетливо от вашего кода. Виртуализированные или нет, вы должны быть уверены, что ваши данные защищены, регулярно выполняются резервное копирование и т. Д., И у вас есть все возможности резервирования и аварийного переключения, которые вам нужны / нужны. Подумайте о нескольких центрах обработки данных и нескольких провайдерах. Azure, EC2 также могут находиться в режиме ожидания для аварийного переключения ... какой-нибудь крошечный экземпляр, который может на лету порождать любое количество ресурсов для аварийного переключения, которое вам нужно. (AWS и т. Д. Могут иметь преимущества быстрого масштабирования и незначительных затрат на резервирование, но могут потребовать больше работы, чем просто добавление большего количества чистого металла в выбранную вами платформу виртуализации / контейнера.)
# 2 «глупое» кэширование / обратный прокси-сервер с собственным хостом, чтобы вы могли перемещать свой контент туда, где низкая пропускная способность.* Здесь не требуется большой отказоустойчивости, если у вас есть способ активировать / деактивировать отдельные кеши. Не беспокойтесь о потере данных, потому что все эти данные защищены выше как часть №1. Единственное, что действительно имеет значение, - это то, как быстро вы можете переключить / переключить / добавить / удалить кеш со своего сайта (даже чтобы отключить кеширование, чтобы некоторые / все / затронутые пользователи попали на основной основной сайт / изображения). Конечно, кеш заполняется автоматически, поэтому вам даже не о чем беспокоиться. И самообрезка, чтобы вы могли минимизировать расходы на хранение, фиксировать (и быстро! Разместить кеш на SSD)
# 3 более интеллектуальное кеширование и распространение контента - переместите PHP и другой код ближе к пользователю, но для всего, что связано с БД, вам реально потребуется также иметь БД там или кешировать. Это совсем другая игра, чем тупой кеш №2, поэтому я бы подумал об этом отдельно и убедился, что ваш тупой кеш не может сломать умный кеш и наоборот. Использует ли ваша текущая архитектура API для экстраполяции динамических пользовательских данных из вашего PHP?
Существует множество вариантов кеширования с открытым исходным кодом или способов, которыми вы даже можете самостоятельно написать простой кеш ... для изображений, просто загрузите их, если они отсутствуют, а затем регулярно очищайте старые файлы. Вот продукт apache для более изощренного "собственного" CDN .... https://trafficcontrol.apache.org/
Единственный трюк с любым из них - это то, как вы будете включать / отключать и динамически назначать пользователей кешу. Простой и грубый способ сделать это - указать местоположение / предпочтения пользователя и просто указать изображения на eu.images.mysite.com, а не на нас или азию и т. Д. Если кеш не работает, просто динамически изменяйте ссылки для этого пользователя в ваш PHP-код. Я считаю, что есть решения DNS, но просто нужно быть осторожным с временем переключения, если кеш должен выйти из строя ... не хочу, чтобы IP-адрес кэшировался в локальном кэше DNS пользователя. Так или иначе, не должно быть сложно определить континент пользователей, если это единственный уровень детализации, который вас волнует.
Кэширование распределенного контента дает так много преимуществ, возможно, даже некоторую защиту от DDOS (возможно, даже в отдельных доменах). Кажется, что это естественно.