В настоящее время я кэширую ответы с помощью nginx + fastcgi. Я занимаюсь переносом своего приложения на AWS. Я разрабатываю подход с горизонтальным масштабированием, но пытаюсь определить, где лучше всего разместить кеш nginx + fastcgi.
Я нашел несколько решений на основе собственного исследования, оба со значительными недостатками.
Буду признателен за любые предложения общих архитектур, которые преодолевают указанные выше недостатки.
Я много раз настраивал этот стек на AWS. Вариант №1 всегда мне нравился, и я обычно его выбираю, потому что он самый простой. Мне любопытно узнать, с каким объемом трафика вы имеете дело, когда неидеальные начальные попадания в кеш являются проблемой? Я обслуживаю несколько миллионов просмотров страниц в месяц на паре экземпляров m1.small, и они почти не поцарапаны.
Другие мысли:
Nginx может использовать memcached в качестве хранилища кеширования. Подключите его к кластеру ElasticCache. Это даст вам очень быстрое централизованное хранилище данных для нескольких экземпляров, к которому можно будет подключаться для получения содержимого кеша. (Я никогда не делал этого, но похоже, что это выполнимо. Пожалуйста, опубликуйте результаты, если вы попытаетесь это сделать.)
Проблема SPoF, упомянутая в Варианте № 2, может быть уменьшена путем настройки группы автомасштабирования, содержащей один экземпляр. Если он умирает, он должен вернуться в сеть через пару минут. Однако вам нужно будет поиграть с загрузочным скриптом, который автоматически захватывает эластичный IP-адрес.
Имейте в виду, что для размещения чего-либо перед ELB потребуется использовать VPC. В любом случае это, как правило, хорошая практика, но она может потребовать значительного обучения.
Действия с тревогой CloudWatch были объявлены только сегодня. Вы можете сделать с этим кое-что интересное, чтобы минимизировать проблему SPoF.
Похоже, вы думаете о той же архитектуре, которую я планирую реализовать.
Я продумал оба сценария и один и тот же подход, а затем остановился на этом решении.
Я буду использовать второй вариант, настроив решение для кэширования перед Load Balancer. Я собираюсь решить проблему единой точки отказа, добавив еще один узел, имеющий резервный, и используя что-то вроде HAProxy, чтобы продолжать проверять работоспособность машины. Если первая кэширующая машина выйдет из строя, то HAProxy автоматически переместит IP-адрес и переместит трафик на другую кэширующую резервную машину, и, следовательно, будет обработана единая точка отказа.
Кроме того, в моем сценарии я буду использовать что-то вроде Varnish вместо Nginx + php, что я предлагаю и вам, если ваше приложение не зависит от Nginx. Varnish будет иметь собственный встроенный Load Balancer, поэтому вы также пропустите AWS Load Balancer.
Надеюсь, это поможет вам построить надежную и масштабируемую инфраструктуру.