Подбор решения для сервера мобильного приложения

Масштабирование на арендованных серверах по времени не отличается от масштабирования в облаке. И там и там время на создание доп "ноды" считанные секунды (у многих ДЦ готовые конфигурации инсталлируются сразу же)

единственное что в "облачке" можно расширятся мелкими шагами а с бареметал (выделенные сервера) шаги уже большие.

Но бареметал это ГАРАНТИРОВАННЫЕ ресурсы, вы всегда знаете что весь объем ресурсов всегда доступен только вам. А вот облачные.... не стоит забывать что вы там не один живете и под этим самым облаком живет обыкновенное железо с СХД на фибре.

ps в тему дублирования облаков https://habr.com/post/250097/

только бекапы, бекапы и еще раз бекапы спасут отца мировой демократии от длительных простоев.

имея качественный легко доступный бекап (например бекапы от селектел просто находка, быстро не дорого и апи хорошее), а так же нормальный ДЦ с быстрым инсталом серверов. Развернуть на новом железе информацию из бекапов не займет много времени. (это на случай выхода из строя железа)

team-voice, я не агитирую, я базируюсь на нашей практике. На выделенных, конечно, тоже можно делать, без проблем. Тут у каждого свой способ решения. И то и то имеет место быть, есть как плюсы так и минусы в обоих вариантах. Кто-то их вообще гибридно использует, объединяя в единую сеть.

Про сравнение выделенного и облака - тут именно про один сервер и кластер. Понятное дело, что можно самому купить 3 машинки, скоммутировать на нужных скоростях и так далее. Один сервер всегда единая точка отказа и должен быть дублирован в критичных проектах. Ну бекап, тут безусловно. В независимости от решения.

Переписываете скрипт под PHP7 если там есть такие несовместимости от 5й версии.

Покупаете сервер с Е5, в OVH например (самое дешевое из всех ДЦ, сэкономите и качество железа норм).

Проводите на нём стресс-тестирование, путем администрирования тюнингуете MySQL (да таким занимаются), делаете все так чтобы Ваш запрос отрабатывался как можно быстро с наименьшим ответом для клиента.

Если у Вас запрос однотипный, например он не динамический (не зависит от времени суток\настроек юзера\погоды и тд тп) то надо ОБЯЗАТЕЛЬНО кэшировать.

Только учтите, что кэш надо сбрасывать как только ответ из БД уже будет отличительный от того что в кэше сейчас иначе клиенты будут получать старую инфу (из кэша)

Если ответ это JSON и в принципе много ячеек не нужно, поиска по кэшу не надо и все такое, то используйте memcache, быстро, ЦП не грузит, мало оперативки кушает (если кэш мизерный).

Это то что я Вам могу посоветовать как разработчик и понимающий хоть чуть-чуть как надо строить такие проекты и на чём их хостить ))

А так если нужна бесперебойность, то облако создаете сами типа через балансировщик либо покупаете готовое решение ))

Маштабировать на уровне приложения(балансировка веба, шардинг/слейв баз данных) на мой взгляд более перспективно, чем просто засовывать в облако и делать автоскалинг от нагрузки.

Облака - это такой себе маркетинговый трюк для продажи ВДСок :).

Безусловно, если нет времени и желания разбираться с кодом и оптимизировать его и бюджет позволяет не заморачиваться с ценой облаков, то лучше сразу двигаться в сторону облака.

А если заранее сохранить JSON ответ в текстовый файл до следующего пуша?

Ну так запрос же в PHP в любом случае поступит, по этому тут и нужен кэш. В этом кэше и хранится инфа которая не меняется каждую секунду ))

Клуб любителей вредных советов.

1) OVH не самые дешевые (есть дешевле, есть лучше по cost-efficency; OVH неплохи для ассиметричных нагрузок и когда нужна гомогенная инфраструктура с гео-распределением)

2) E5 не всегда лучше E3 (single thread performance у е5 откровенно слабее; иногда дешевле быстро отстреляться процом, чем тащить десятки процессов/ниток)

3) Внезапно иногда десктопные процы и железо подходят лучше чем всякое e5 (см stateless node и пункт 2)

(там ещё были ребята с советами про aws - убейте себя)

Построить решение можно, заложить расширяемость - тоже.

Чтобы ответить на вопрос "что именно делать" надо профилировать приложение, смотреть мониторинг (вы же собираете munin/zabbix/grafana стату? хотя бы за 3-4 месяца есть что посмотреть?) и много думать.

Но это время и деньги.

И ещё надо обязательно понимать какой вы планируете рост в процентах, какой суточный разброс по нагрузке и какой - связанный с сезонностью.

Без глубокого понимания текущей ситуации и планов развития все советы здесь - это тыканье пальцем в небо.

Bananzz

1) В OVH я как минимум не замечаю проблем с сетью таких чтобы задевали большое кол-во серверов, ценник там низкий.

2) Про процессоры можно спорить бесконечно :)

3) И такое бывает, согласен

1) OVH, последняя неделя, то что цепляло нас по сети:

20.08 - проблемы со связностью DATA-IX, MSK-IX (высокий входящий трафик) - длилось почти 20 часов; перерулили трафик внутрь сети OVH через DE-CIX; проблемы были с регионами WAV, FRA;

20.08 с примерно 22:45 MSK - 21.08 до примерно 01:30 MSK проблемы были в Варшаве (свежеобновленный маршрутизатор начал терять пакеты);

21.08 - в течение дня - всплесковые потери пакетов через DATA-IX, SPB-IX, MSK-IX до GRA и SBG.

22 и 23 ничего военного не было

за Азию и США не скажу - у нас там в OVH ничего нет, но в Европе регулярно что-то происходит; в Канаде всё спокойно (на HOST-H линейке проблемы с питанием, поэтому мы от них отказались; а вот EG работают стабильно и долго)

В OVH у нас порядка десятка дедиков и штук 15 виртуалок.

Есть ещё Soyoustart, но их я не включал в статистику.

2) Неа, тут не надо спорить. Надо понимать что и зачем использовать и какие цели и бюджеты.

Один из проектов мы целенаправленно собирали на малоядерных платформах и с небольшим количеством памяти - скоростные e3 5-6 поколений и по 32гб памяти; ставили быстрые диски (NVMe) и крутили там шарды БД.

Под апп-сервера (php7) отлично туда встали i7-6700k - быстрые ядра и быстрая же обработка.

Среднее ответа вышло в пределах 160ms на выходе из кластера.

Ещё хорошо себя показывают e3-32gb-nvme ноды для шардов Greenplum (только сеть надо к ним ХОРОШУЮ). Тут правда есть вопросы о стоимости поддержки на будущее, но сами ноды стоят недорого и MPP отрабатывают на все 100 - e3 высокочастотных как раз хватает чтобы смолотить поток от пары nvme-дисков.

Сейчас внимательно смотрим на Xeon W, но их пока на тест хрен где достанешь - дорогие заразы. Разве что хецнер.

На другом проекте время ответа было чуть менее критично (400-450 было допустимо) и ещё и шардить базу не получалось - под БД брали двухпроцессорные системы на базе E5-26xx v4 с горой памяти, а на дисках получилось сэкономить - база ложилась в кеш ОС, записей мало - хорошо видно по всплескам иопсов. Cache hit rate у БД - 96-98%. Для мемкеша не считали, но там тоже всё хорошо.

В БД там (несмотря на достаточно агрессивное кеширование) пролетало по 200М селектов в сутки в пиках.

Такие сервера в OVH выходят подороже чем в каком-нибудь online.net (а у них DC3 сертицифирован под Tier3).

Короче - сначала задача и аналитика, потом выбор процессоров.

Ещё бы Scalable пощупать наживую :)

У OVH сейчас шикарная по цене-производительности линейка - DO-32, конкретно в FRA. Там стоят v6 процы и P3520 nvme диски и есть гигабитный vRack.

В Польше же v5 и S3510 без vRack. Пинг тоже не скажу что сильно приятный при таргете на Россию.

Также более-менее интересно выглядят Pro-4-S от Online.net, но там скорее всего будут стоят 850-860 EVO самсунги. Они не для всех задач себя хорошо показывают. И адреса online.net прямые к серверам часто в бане у РКН.

А что скажите на счет маршрутизаторов Cisco http://linkas.ru/catalog/marshrutizatory/cisco/ Из тех предложений, что выдвигает начальство мне кажется это оптимальный вариант. Еще рассматривают huawei и palo-alto.