WEBVTT 00:00:00.000 --> 00:00:03.340 Вы размещаете его в одном месте, скажем, в центре обработки данных в Вирджинии. 00:00:03.440 --> 00:00:05.660 Это подходит для клиентов в Нью-Йорке или Чикаго. 00:00:05.860 --> 00:00:08.260 Но как быть тем, кто в Токио, Лондоне или Сиднее? 00:00:08.420 --> 00:00:10.800 Каждый раз, когда такой пользователь заходит на ваш сайт, 00:00:11.060 --> 00:00:14.300 его запрос должен пересечь океаны и континенты, чтобы достичь сервера. 00:00:14.400 --> 00:00:18.460 Каждое изображение, каждая загрузка страницы, каждый вызов API совершают этот долгий путь, 00:00:18.600 --> 00:00:19.920 и задержка быстро накапливается. 00:00:20.160 --> 00:00:23.480 Исследования показывают, что даже секундная задержка загрузки страницы 00:00:23.480 --> 00:00:26.400 может стоить вам конверсий и отпугнуть разочарованных пользователей. 00:00:26.400 --> 00:00:30.720 Но вот в чем дело, что произойдет, если ваш сайт станет вирусным или подвергнется атаке ботнета. 00:00:30.920 --> 00:00:33.000 Ваш единственный сервер в Вирджинии будет перегружен. 00:00:33.020 --> 00:00:35.000 Он замедлится и может даже полностью выйти из строя. 00:00:35.140 --> 00:00:36.840 Вы окажетесь в тупике без запасного плана. 00:00:37.000 --> 00:00:41.400 Решить проблему доступности можно, создав копии сайта в разных регионах, в Токио, Лондоне, Сан-Паулу. 00:00:41.500 --> 00:00:42.220 Это помогает. 00:00:42.340 --> 00:00:44.060 Но теперь у вас появляется новая проблема. 00:00:44.240 --> 00:00:46.400 Как направлять каждого посетителя в нужную локацию? 00:00:46.560 --> 00:00:49.640 Вы ведь не хотите, чтобы пользователь из Японии случайно попал на ваш американский сервер? 00:00:49.640 --> 00:00:51.580 Вам нужен умный способ маршрутизации трафика. 00:00:51.760 --> 00:00:53.660 И именно здесь на помощь приходит Азур Фронт Даор. 00:00:53.820 --> 00:00:55.680 Познакомьтесь с глобальным регулировщиком движения. 00:00:55.860 --> 00:00:57.140 Это и есть Азур Фронт Даор. 00:00:57.260 --> 00:00:59.740 Представьте Азур Фронт Даор как глобального регулировщика. 00:00:59.980 --> 00:01:03.680 Ни одного на перекрестке, а тысячи расставленных на всех главных развязках мира. 00:01:03.860 --> 00:01:07.940 Когда кто-то заходит на ваш сайт, ближайший регулировщик вмешивается и говорит «Вы в Токио». 00:01:07.940 --> 00:01:09.960 Ближайший к вам магазин находится в Сингапуре. 00:01:10.040 --> 00:01:11.380 Позвольте мне направить вас туда. 00:01:11.540 --> 00:01:13.860 В чем же отличие от обычного балансировщика нагрузки? 00:01:13.860 --> 00:01:18.660 Большинство балансировщиков работают на четвертом уровне, используя IP-адреса и порты для маршрутизации трафика. 00:01:18.820 --> 00:01:20.540 Этого достаточно для простых задач. 00:01:20.720 --> 00:01:25.280 Но Азур Фронт Даор работает на седьмом уровне, понимая трафика HTTP и HTTPS. 00:01:25.460 --> 00:01:29.060 Он может анализировать введенный URL, проверять заголовки браузера, 00:01:29.280 --> 00:01:33.400 определять тип запрашиваемого контента и принимать умные решения о маршрутизации. 00:01:34.240 --> 00:01:37.040 Вместо того, чтобы просто направлять IP на сервер, 00:01:37.040 --> 00:01:40.600 Фронт Даор говорит, запрос Капи идет на бэкенд в США, 00:01:40.900 --> 00:01:44.040 а запрос изображений – на кашерованную копию в Токио. 00:01:45.000 --> 00:01:47.380 А вот что делает это возможным за кулисами. 00:01:47.640 --> 00:01:50.320 Азур Фронт Даор работает в глобальной сети Microsoft, 00:01:50.720 --> 00:01:55.780 насчитывающей более 210 точек присутствия в более чем 130 городах по всему миру. 00:01:55.940 --> 00:01:58.840 Представьте каждую точку присутствия как небольшой пост ДПС – 00:01:58.840 --> 00:02:02.540 локальный офис в каждом крупном городе, который мгновенно обрабатывает начальный запрос. 00:02:02.680 --> 00:02:05.720 Когда пользователь заходит на ваш сайт, он подключается к ближайшему узлу, 00:02:05.720 --> 00:02:08.280 а не идет напрямую к вашему исходному серверу в Вирджинии. 00:02:08.400 --> 00:02:12.600 Этот узел затем направляет запрос через частную магистральную сеть Microsoft к вашей серверной части. 00:02:12.760 --> 00:02:15.480 Это важно, поскольку общедоступный интернет непредсказуем. 00:02:15.640 --> 00:02:18.280 Ваш трафик может совершить десяток переходов через разные сети, 00:02:18.480 --> 00:02:21.380 каждый из которых увеличивает задержку и создает риск потери пакетов. 00:02:21.480 --> 00:02:25.180 Магистральная сеть Microsoft, напротив, представляет собой частную высокоскоростную сеть, 00:02:25.400 --> 00:02:26.960 напрямую соединяющую их дата-центры. 00:02:27.060 --> 00:02:30.020 Поэтому, как только ваш запрос достигает ближайшей точки присутствия, 00:02:30.200 --> 00:02:32.840 остальная часть пути проходит по быстрой и надежной магистрали. 00:02:32.840 --> 00:02:37.760 Вы получаете ускорение загрузки, снижение задержек и лучший пользовательский опыт повсюду, 00:02:37.940 --> 00:02:39.900 в Токио, Лондоне или Сан-Паулу. 00:02:40.000 --> 00:02:43.700 И все это происходит автоматически, без ведома ваших посетителей. 00:02:44.020 --> 00:02:45.640 Три уровня отказоустойчивости. 00:02:45.860 --> 00:02:46.980 Как работает AFD? 00:02:47.140 --> 00:02:50.800 Возможно, вы думаете, идея глобального регулировщика трафика звучит отлично, 00:02:50.980 --> 00:02:53.240 но что будет, если сам регулировщик выйдет из строя? 00:02:53.340 --> 00:02:56.300 Если Azure Front Door — это единственная точка входа для всего вашего приложения, 00:02:56.460 --> 00:02:58.120 значит, это огромная единая точка отказа. 00:02:58.180 --> 00:02:58.420 Верно. 00:02:58.540 --> 00:02:59.620 В Microsoft это учли. 00:02:59.620 --> 00:03:01.500 Они встроили Front Door 3 уровня отказоустойчивости, 00:03:01.640 --> 00:03:03.280 поэтому система практически никогда не отключается. 00:03:03.400 --> 00:03:04.920 Позвольте мне рассказать о них подробнее. 00:03:05.060 --> 00:03:06.680 Первый уровень — внешний интерфейс. 00:03:06.780 --> 00:03:10.040 Помните те более 210 точек присутствия, о которых я упоминал? 00:03:10.140 --> 00:03:13.040 Каждая из них — это полностью независимый узел обработки трафика. 00:03:13.200 --> 00:03:16.420 Эти точки расположены в более чем 130 городах по всему миру, 00:03:16.700 --> 00:03:19.720 работая внутри дата-центров Microsoft и партнерских площадок. 00:03:19.800 --> 00:03:23.220 В каждой точке находится несколько серверных стоек с пограничными контроллерами, 00:03:23.360 --> 00:03:25.520 выполняющими роль встроенного балансировщика нагрузки. 00:03:25.520 --> 00:03:31.280 Если один сервер внутри точки выходит из строя, контроллер перенаправляет трафик на исправный сервер в той же самой точке. 00:03:31.400 --> 00:03:34.940 А если отключается целая точка, в дело вступает IP адресация Anikast. 00:03:35.140 --> 00:03:38.820 Запрос вашего посетителя автоматически перенаправляется на следующую ближайшую точку присутствия. 00:03:38.980 --> 00:03:41.660 Никаких сбоев и ручного вмешательства — это происходит само собой. 00:03:41.820 --> 00:03:43.220 Второй уровень — резервирование. 00:03:43.400 --> 00:03:45.120 Но что, если точка будет перегружена? 00:03:45.280 --> 00:03:48.920 Скажем, произошел резкий скачок трафика или сразу несколько точек в регионе вышли из строя. 00:03:49.100 --> 00:03:51.060 Оставшиеся узлы могут не справиться с нагрузкой. 00:03:51.220 --> 00:03:53.320 Именно здесь на помощь приходит уровень резервирования. 00:03:53.320 --> 00:03:58.020 Это отдельный набор узлов, их десятки, а не сотни, и на них работает точно такое же программное обеспечение и архитектура. 00:03:58.180 --> 00:04:01.260 Они расположены только в дата-центрах Microsoft, а не на партнерских объектах. 00:04:01.380 --> 00:04:05.260 Когда фронтальному узлу нужно сбросить часть трафика, он перенаправляет запросы на этот резервный уровень. 00:04:05.340 --> 00:04:07.780 То же кэширование, та же маршрутизация, та же безопасность. 00:04:07.940 --> 00:04:09.620 Ваши посетители никогда не заметят разницы. 00:04:09.820 --> 00:04:12.700 Возможно, они получат контент немного медленнее, но они все равно его получат. 00:04:12.780 --> 00:04:14.500 Третий уровень — это экран защиты трафика. 00:04:14.620 --> 00:04:15.840 Это своего рода надзиратель. 00:04:16.000 --> 00:04:19.440 Представьте его как глобальный командный центр, наблюдающий за всей сетью FrontDAOR. 00:04:19.440 --> 00:04:23.280 Он отчлеживает модели трафика, уровни нагрузки и работоспособность во всех точках присутствия — POP. 00:04:23.440 --> 00:04:27.860 Когда он обнаруживает, что некоторые POP перегружаны, он не просто ждет включения резервного уровня. 00:04:27.980 --> 00:04:32.680 Он упреждающе перенаправляет трафик, обновляя способ разрешения DNS для вашей конечной точки FrontDAOR. 00:04:32.800 --> 00:04:37.700 Он может переключаться с глобального Anikast IP на региональный, полностью перемещая клиентов на другие наборы POP. 00:04:37.880 --> 00:04:40.100 При необходимости он может даже действовать между континентами. 00:04:40.260 --> 00:04:43.200 Экран защиты трафика — это то, что делает работу FrontDAOR почти волшебной. 00:04:43.320 --> 00:04:47.220 Он постоянно оптимизирует процессы в фоновом режиме, корректируя маршруты еще до возникновения проблем. 00:04:47.220 --> 00:04:49.120 Теперь стоит упомянуть один важный момент. 00:04:49.300 --> 00:04:52.680 В октябре 2025 года в Azure FrontDAOR произошел серьезный сбой. 00:04:52.820 --> 00:04:59.560 Изменение конфигурации пропустило проверки безопасности, что вызвало масштабные проблемы в Microsoft 365, Xbox Live и на тысячах клиентских сайтов. 00:04:59.680 --> 00:05:01.380 Microsoft извлекла из этого уроки. 00:05:01.480 --> 00:05:04.520 Они убрали всю асинхронную обработку из конвейера конфигурации. 00:05:04.660 --> 00:05:07.180 Теперь каждый путь кода тестируется во время развертывания. 00:05:07.380 --> 00:05:12.720 Они сократили время отката с 4 часов до 1 и планируют достичь 10 минут к марту 2026 года. 00:05:12.720 --> 00:05:18.020 Они также вводят микросегментацию, чтобы ограничить любое будущее влияние менее чем 1% арендаторов. 00:05:18.140 --> 00:05:25.860 Суть в том, что идеальных систем нет, но трехуровневая архитектура FrontDAOR разработана так, чтобы пережить региональные сбои, всплески трафика и даже некоторые ошибки конфигурации. 00:05:26.040 --> 00:05:28.320 Для большинства приложений этого более чем достаточно. 00:05:28.540 --> 00:05:35.220 Для критически важных систем можно использовать Azure Traffic Manager перед FrontDAOR в качестве резервного пути, но это продвинутая тема для другого раза. 00:05:35.340 --> 00:05:38.520 Как происходит управление трафиком, маршрутизация и группа источников. 00:05:38.520 --> 00:05:45.240 Итак, у нас есть глобальный регулировщик трафика с более чем 210 упостами и тремя уровнями резервирования, но как он решает, куда отправить каждого посетителя? 00:05:45.440 --> 00:05:47.260 Здесь на помощь приходят группы источников. 00:05:47.480 --> 00:05:50.540 Группа источников – это, по сути, коллекция ваших серверных узлов. 00:05:50.760 --> 00:05:55.000 Думайте о них как о списке ваших филиалов, реальных местах, где работает ваш сайт или приложение. 00:05:55.160 --> 00:05:58.280 У вас может быть один сервер в Северной Америке, один в Европе и один в Азии. 00:05:58.440 --> 00:06:00.320 Все они входят в одну и ту же группу источников. 00:06:00.460 --> 00:06:02.960 При этом FrontDAOR не просто слепо отправляет трафик на все из них. 00:06:02.960 --> 00:06:04.700 Он постоянно проверяет, живы ли они. 00:06:04.860 --> 00:06:07.020 Это называется проверкой работоспособности HealthPro. 00:06:07.140 --> 00:06:15.220 Каждые несколько секунд каждая точка FrontDAOR пингует ваши серверы, обращаясь к определенному пути, обычно к корню сайта или специальной конечной точки проверки, такой как Health. 00:06:15.380 --> 00:06:21.180 Если сервер не отвечает или выдает код ошибки, FrontDAOR помечает его как нерабочий и перестает отправлять туда трафик. 00:06:21.280 --> 00:06:25.760 Это похоже на регулировщика, который проверяет, открыт ли магазин, прежде чем направлять туда покупателей. 00:06:25.920 --> 00:06:30.660 Но когда у вас несколько исправных серверов, возникает вопрос, какой из них должен принять посетителя? 00:06:30.660 --> 00:06:35.180 FrontDAOR использует для принятия решения три фактора – приоритет, задержку и вес. 00:06:35.300 --> 00:06:37.420 И они работают вместе в определенном порядке. 00:06:37.560 --> 00:06:38.700 Первый – это приоритет. 00:06:38.880 --> 00:06:41.860 Вы можете назначить один сервер основным, а другой – резервным. 00:06:42.040 --> 00:06:44.900 Установите для основного приоритет один, а для резервного – два. 00:06:45.060 --> 00:06:47.440 В обычных условиях весь трафик идет на основной сервер. 00:06:47.540 --> 00:06:50.480 Поэтому, если основной сервер выходит из строя, трафик переключается на резервный. 00:06:50.580 --> 00:06:55.600 Просто, правда, это отлично подходит для схем «активный-пассивный», где один регион должен обрабатывать все, пока не произойдет сбой. 00:06:55.720 --> 00:06:58.000 Но что, если вы хотите, чтобы оба сервера были активны? 00:06:58.120 --> 00:06:59.560 Вот здесь вступает в дело задержка. 00:06:59.560 --> 00:07:06.460 Если несколько серверов имеют одинаковый приоритет, FrontDAOR направляет трафик на тот, у которого самая низкая задержка, то есть самое быстрое время отклика из местоположения пользователя. 00:07:06.600 --> 00:07:11.340 Таким образом, пользователь в Лондоне направляется на европейский сервер, а пользователь в Токио – на азиатский. 00:07:11.480 --> 00:07:13.160 Существует также настройка чувствительности. 00:07:13.320 --> 00:07:15.260 По умолчанию она составляет 50 миллисекунд. 00:07:15.400 --> 00:07:19.900 Если разница в задержке между двумя серверами менее 50 миллисекунд, FrontDAOR считает их одинаково быстрыми. 00:07:20.040 --> 00:07:24.020 Это предотвращает постоянное переключение между серверами, работающими практически с одинаковой скоростью. 00:07:24.100 --> 00:07:26.300 А когда задержка одинакова, в игру вступает вес. 00:07:26.300 --> 00:07:29.220 Вы можете назначить веса для распределения трафика между серверами. 00:07:29.320 --> 00:07:31.980 Допустим, вы хотите протестировать новую версию вашего приложения. 00:07:32.120 --> 00:07:35.060 Вы можете присвоить текущему серверу вес 90, а новому – 10. 00:07:35.240 --> 00:07:39.680 Это означает, что примерно 9 из 10 посетителей попадут на старую версию, а один из 10 – на новую. 00:07:39.800 --> 00:07:45.680 Это идеально подходит для постепенного развертывания, A-B-тестирования или просто для балансировки нагрузки между серверами с разной емкостью. 00:07:45.800 --> 00:07:46.480 Вот что важно. 00:07:46.680 --> 00:07:48.300 Все это происходит автоматически. 00:07:48.460 --> 00:07:52.020 Вы настраиваете группу источников один раз, а FrontDAOR берет на себя остальное. 00:07:52.020 --> 00:07:57.060 Он опрашивает ваши серверы, измеряет задержку, учитывает приоритеты и распределяет трафик в зависимости от веса. 00:07:57.140 --> 00:08:00.820 И он делает все это на границе сети, еще до того, как запрос дойдет до вашего бэкенда. 00:08:00.940 --> 00:08:04.980 Это означает, что вашим серверам не нужно определять, откуда пришел трафик или как его маршрутизировать. 00:08:05.120 --> 00:08:08.960 Они просто отдают контент, безопасность на границе сети, WEF и другие возможности. 00:08:09.080 --> 00:08:10.680 Теперь давайте поговорим о безопасности. 00:08:10.800 --> 00:08:16.920 Поскольку FrontDAOR находится на самом краю сети Microsoft, это идеальное место для остановки атак еще до того, как они достигнут ваших серверов. 00:08:16.920 --> 00:08:19.480 Представьте его как пункт досмотра на входе в здание. 00:08:19.680 --> 00:08:22.440 Любой, кто хочет войти, должен сначала пройти через него. 00:08:22.580 --> 00:08:26.020 Этот контрольный пункт называется BrandMauer Web-приложений или WEF. 00:08:26.180 --> 00:08:28.340 Он встроен как в FrontDAOR стандарт, так и в премиум. 00:08:28.480 --> 00:08:31.140 Он автоматически блокирует распространенные веб-атаки. 00:08:31.300 --> 00:08:36.720 Например, SQL-инъекции, когда злоумышленник пытается внедрить вредоносные команды базы данных в поле формы. 00:08:36.860 --> 00:08:42.700 Межсайтовый скриптинг, когда на вашей странице внедряются скрипты или DDoS-атаки, призванные перегрузить серверы трафиком. 00:08:42.700 --> 00:08:47.400 WEF обнаруживает все это на периферии и очекает до того, как ваш исходный сервер вообще что-то увидит. 00:08:47.480 --> 00:08:50.480 Помимо автоматической защиты, вы можете создавать собственные правила. 00:08:50.620 --> 00:08:55.760 Например, если ваш сайт предназначен только для клиентов в Европе, можно полностью заблокировать трафик из других регионов. 00:08:55.820 --> 00:09:00.460 Или, если вы заметили, что определенный диапазон IP-адресов постоянно сканирует ваш сайт, его тоже можно заблокировать. 00:09:00.620 --> 00:09:04.860 Вы также можете фильтровать запросы по заголовкам, шаблонам URL или даже по браузеру, который использует пользователь. 00:09:05.080 --> 00:09:08.320 WEF дает вам полный контроль над тем, кто получает доступ, а кто — нет. 00:09:08.460 --> 00:09:10.040 И здесь важны ценовые категории. 00:09:10.040 --> 00:09:14.680 Уровень стандарт предлагает пользовательские правила WEF, где вы сами определяете, что блокировать и разрешать. 00:09:14.800 --> 00:09:19.540 Уровень премиум идет дальше, добавляя управляемые наборы правил на базе аналитики угроз Microsoft, 00:09:19.880 --> 00:09:24.160 которые постоянно обновляются с учетом реальных атак, фиксируемых Microsoft во всей сети. 00:09:24.320 --> 00:09:30.200 Премиум также включает защиту от ботов, которые автоматически блокируют автоматизированные порсеры, подбор паролей и других ботов. 00:09:30.320 --> 00:09:35.900 Кроме того, добавлена поддержка PrivateLink, позволяющая подключаться к источникам через частное сетевое соединение, а не через общедоступный интернет. 00:09:36.020 --> 00:09:39.460 Это означает, что ваши серверы могут быть полностью скрыты от внешнего мира. 00:09:39.460 --> 00:09:41.520 Только FrontDaur может получить к ним доступ. 00:09:41.620 --> 00:09:43.400 Это критически важно для безопасности. 00:09:43.580 --> 00:09:45.520 Многие атаки нацелены не на FrontDaur. 00:09:45.660 --> 00:09:47.480 Они пытаются найти черный ход. 00:09:47.680 --> 00:09:53.780 Если ваш исходный сервер имеет публичный IP-адрес, злоумышленники могут атаковать его напрямую, минуя все средства защиты FrontDaur. 00:09:53.900 --> 00:09:59.100 С PrivateLink это невозможно, так как у источника нет публичной конечной точки, и доступ к нему возможен только через FrontDaur. 00:09:59.200 --> 00:10:02.240 Поэтому, даже если кто-то узнает IP вашего сервера, он не сможет до него добраться. 00:10:02.400 --> 00:10:04.440 В результате обеспечивается глубоко эшелонированная защита. 00:10:04.640 --> 00:10:06.440 WEF блокирует атаки на уровне приложений. 00:10:06.580 --> 00:10:08.680 Пользовательские правила решают ваши специфические задачи. 00:10:08.680 --> 00:10:10.940 Защита от ботов останавливает автоматизированные угрозы. 00:10:11.020 --> 00:10:13.160 А PrivateLink делает ваши источники невидимыми. 00:10:13.320 --> 00:10:16.860 Все это происходит на периферии, еще до того, как трафик дойдет до вашей инфраструктуры. 00:10:16.980 --> 00:10:19.800 Поэтому серверы заняты обслуживанием контента, а не отражением атак. 00:10:19.980 --> 00:10:20.460 Кэширование. 00:10:20.660 --> 00:10:22.060 Ускоряем работу еще сильнее. 00:10:22.240 --> 00:10:24.060 Итак, мы разобрали маршрутизацию и безопасность. 00:10:24.120 --> 00:10:27.260 Но есть еще одна функция, которая делает FrontDaur по-настоящему полезным — кэширование. 00:10:27.460 --> 00:10:28.800 Идея заключается в следующем. 00:10:28.960 --> 00:10:31.360 Многое из содержимого вашего сайта меняется не очень часто. 00:10:31.560 --> 00:10:34.580 Изображения, CSS-файлы, библиотеки JavaScript, фотографии товаров. 00:10:34.580 --> 00:10:36.580 Возможно, даже некоторые HTML-страницы. 00:10:36.700 --> 00:10:39.640 Если каждый посетитель вынужден загружать данные с вашего исходного сервера, 00:10:39.760 --> 00:10:41.380 вы тратите время и пропускную способность, 00:10:41.500 --> 00:10:44.300 так как серверу приходится снова и снова обрабатывать один и тот же запрос, 00:10:44.440 --> 00:10:46.420 каждый раз отправляя одни и те же байты через интернет. 00:10:46.560 --> 00:10:47.660 Кэширование решает эту проблему, 00:10:47.780 --> 00:10:50.480 сохраняя копию статического контента в пограничной точке присутствия — POP. 00:10:50.640 --> 00:10:52.560 В следующий раз, когда кто-то запросит тот же файл, 00:10:52.580 --> 00:10:55.280 POP выдаст его мгновенно, даже не обращаясь к вашему исходному серверу. 00:10:55.360 --> 00:10:58.060 Это как иметь небольшой склад рядом с каждой точкой обслуживания. 00:10:58.060 --> 00:11:00.540 Вместо того, чтобы отправлять каждого клиента на главный завод, 00:11:00.700 --> 00:11:02.540 вы просто выдаёте им-то, что уже есть на полке. 00:11:02.700 --> 00:11:04.600 Разница в производительности впечатляет. 00:11:04.780 --> 00:11:08.400 Вместо долгого пути через океан ответ приходит с сервера в том же городе. 00:11:08.760 --> 00:11:09.960 Мелисекунды вместо секунд. 00:11:10.060 --> 00:11:11.720 А ваш исходный сервер получает передышку, 00:11:11.840 --> 00:11:13.160 так как обрабатывает меньше запросов 00:11:13.160 --> 00:11:15.880 и может сосредоточиться на динамических задачах, требующих обработки. 00:11:15.980 --> 00:11:18.400 Однако кэширование не происходит автоматически для всего. 00:11:18.580 --> 00:11:21.040 Вы сами контролируете, что и как долго кэшируется. 00:11:21.240 --> 00:11:24.560 FrontDoor учитывает стандартные заголовки управления кэшем вашего сервера, 00:11:24.560 --> 00:11:26.160 такие как MaxH или S-MaxEdge, 00:11:26.160 --> 00:11:28.660 а также позволяет настраивать правила кэширования напрямую, 00:11:28.740 --> 00:11:30.840 при необходимости переопределяя заголовки сервера. 00:11:30.920 --> 00:11:32.920 При обновлении контента вы можете очистить кэш 00:11:32.920 --> 00:11:35.720 и дать команду FrontDoor удалить старые копии и загрузить свежие. 00:11:35.860 --> 00:11:38.660 Это важно для таких случаев, как запуск продуктов или изменение цен, 00:11:38.840 --> 00:11:40.680 когда новая версия должна стать видимой немедленно. 00:11:40.800 --> 00:11:41.580 И вот в чём дело. 00:11:41.760 --> 00:11:44.240 FrontDoor предназначен не только для статического контента. 00:11:44.440 --> 00:11:48.220 Даже динамический контент, такой как API, персонализированные страницы или корзины покупок, 00:11:48.340 --> 00:11:51.640 доставляется быстрее, поскольку после попадания запроса в ближайшую точку присутствия 00:11:51.640 --> 00:11:54.100 он идёт к вашему серверу через частную магистральную сеть Microsoft, 00:11:54.100 --> 00:11:55.480 а не через общедоступный интернет. 00:11:55.560 --> 00:11:58.760 Эта частная магистраль быстрее и надёжнее, чем открытая сеть. 00:11:58.880 --> 00:12:01.740 Так что даже не кэшированные запросы получают прирост скорости. 00:12:01.880 --> 00:12:05.220 Это одно из ключевых различий между FrontDoor и традиционной CDN. 00:12:05.380 --> 00:12:07.960 CDN кэширует статический контент, и на этом всё. 00:12:08.120 --> 00:12:11.220 FrontDoor кэширует статический контент и ускоряет всё остальное. 00:12:11.400 --> 00:12:13.000 Это предложение два в одном. 00:12:13.180 --> 00:12:14.000 Тарифные планы. 00:12:14.240 --> 00:12:14.900 Какое выбрать? 00:12:15.040 --> 00:12:15.320 Хорошо. 00:12:15.680 --> 00:12:17.840 Давайте поговорим о деньгах, ведь это главный вопрос. 00:12:18.060 --> 00:12:20.740 Сколько это стоит и какой уровень на самом деле стоит выбрать? 00:12:20.740 --> 00:12:23.460 Прежде чем переходить к цифрам, важно понять следующее. 00:12:23.460 --> 00:12:27.140 Выбранный уровень влияет не только на цену, но и определяет безопасность и функции, 00:12:27.380 --> 00:12:29.060 доступные для защиты вашего приложения. 00:12:29.240 --> 00:12:31.300 Azure FrontDoor поставляется в трёх версиях. 00:12:31.440 --> 00:12:32.800 Classic — это старая версия. 00:12:33.000 --> 00:12:36.240 Она всё ещё работает, но Microsoft не рекомендует использовать её для новых проектов. 00:12:36.380 --> 00:12:38.220 Classic постепенно выводится из эксплуатации. 00:12:38.420 --> 00:12:40.660 Новые ресурсы нельзя будет создавать после 2025 года, 00:12:40.800 --> 00:12:42.860 а полное отключение произойдёт к 2027 году. 00:12:42.960 --> 00:12:46.480 Поэтому, если вы начинаете с нуля, вам следует рассматривать стандарт или премиум. 00:12:46.660 --> 00:12:47.840 Вот самый простой обзор. 00:12:48.000 --> 00:12:50.800 Базовый тариф стандарт стоит 35 долларов в месяц. 00:12:50.800 --> 00:12:53.420 Тариф премиум стоит 330 долларов в месяц. 00:12:53.500 --> 00:12:56.060 Это значительный скачок, но самое интересное впереди. 00:12:56.260 --> 00:12:59.500 Стоимость передачи данных за гигабайт одинакова для обоих тарифов. 00:12:59.680 --> 00:13:04.740 В Северной Америке и Европе исходящий трафик стоит около 8,25 цента за гигабайт для первых 10 терабайт. 00:13:04.880 --> 00:13:07.580 Передача данных от границы к источнику стоит около 2 центов за гигабайт. 00:13:07.740 --> 00:13:09.220 Цены одинаковы для обоих тарифов. 00:13:09.340 --> 00:13:11.780 Итак, что же вы получаете за эти дополнительные 300 долларов? 00:13:12.040 --> 00:13:13.200 Функциональные возможности. 00:13:13.360 --> 00:13:17.200 Премиум добавляет управляемые правила WF на базе аналитики Угроз Microsoft, 00:13:17.200 --> 00:13:20.100 которые обновляются автоматически на основе реальных схем атак. 00:13:20.220 --> 00:13:22.720 Вы также получаете защиту от ботов, поддержку Private Link, 00:13:22.900 --> 00:13:26.480 чтобы скрыть ваш источник от публичного интернета и более глубокую аналитику безопасности. 00:13:26.660 --> 00:13:28.660 Стандарт предоставляет глобальную балансировку нагрузки, 00:13:28.800 --> 00:13:31.680 кэширование, динамическое ускорение и пользовательские правила WF. 00:13:31.820 --> 00:13:34.900 Вы можете блокировать диапазоны IP-адресов, страны или шаблоны запросов. 00:13:35.000 --> 00:13:37.620 Вы просто не получаете управляемые наборы правил или Private Link. 00:13:37.820 --> 00:13:39.340 Стоимость запросов также различается. 00:13:39.540 --> 00:13:43.160 Стандарт стоит около 9 центов за 10 тысяч запросов для первых 250 миллионов. 00:13:43.160 --> 00:13:45.600 Премиум стоит около 15 центов за 10 тысяч запросов. 00:13:45.720 --> 00:13:47.500 В больших масштабах эта разница становится ощутимой. 00:13:47.580 --> 00:13:48.540 Так как же сделать выбор? 00:13:48.700 --> 00:13:49.960 Вот мое эмпирическое правило. 00:13:50.160 --> 00:13:54.040 Если у вас обычный веб-сайт или API, которому нужна глобальная производительность и базовая безопасность, 00:13:54.180 --> 00:13:55.080 начните с тарифа Стандарт. 00:13:55.260 --> 00:13:56.920 Базовая плата в 35 долларов доступна, 00:13:57.060 --> 00:14:00.060 а пользовательские правила WF справляются с большинством распространенных угроз. 00:14:00.200 --> 00:14:01.860 Вы всегда сможете перейти на другой тариф позже, 00:14:02.020 --> 00:14:03.660 если ваши потребности в безопасности вырастут. 00:14:03.760 --> 00:14:06.680 Если вы работаете в регулируемой отрасли, здравоохранении, финансах, 00:14:06.820 --> 00:14:09.400 газсекторе или обрабатываете конфиденциальные данные клиентов, 00:14:13.160 --> 00:14:14.360 которых вы могли даже не подумать. 00:14:14.480 --> 00:14:16.240 PrivateLink делает ваши источники невидимыми, 00:14:16.320 --> 00:14:18.320 а защита от ботов останавливает автоматизированные атаки, 00:14:18.440 --> 00:14:19.520 которые не распознал бы Стандарт. 00:14:19.620 --> 00:14:21.940 И последнее, если вы раздаете только статический контент, 00:14:22.020 --> 00:14:24.120 и вам не нужны функции маршрутизации или безопасности, 00:14:24.240 --> 00:14:25.740 традиционная CDN может быть дешевле. 00:14:25.880 --> 00:14:28.240 Azure CDN от Microsoft все еще существует, 00:14:28.360 --> 00:14:30.960 и для передачи статики она зачастую более экономична. 00:14:31.060 --> 00:14:32.780 Но для большинства реальных приложений, 00:14:32.920 --> 00:14:36.240 где нужны маршрутизация, безопасность, кэширование и ускорение, 00:14:36.440 --> 00:14:38.400 Front Door Standard — это оптимальный выбор. 00:14:38.700 --> 00:14:40.640 Соберем все вместе на реальном примере. 00:14:40.640 --> 00:14:42.580 Позвольте мне показать вам реальный сценарий, 00:14:42.580 --> 00:14:45.400 чтобы вы увидели, как все эти компоненты работают вместе. 00:14:45.600 --> 00:14:47.420 Представьте, что у вас интернет-магазин. 00:14:47.560 --> 00:14:49.080 У вас есть серверы в трех регионах — 00:14:49.080 --> 00:14:50.640 Северной Америке, Европе и Азии. 00:14:50.840 --> 00:14:54.000 Ваши клиенты повсюду — от Японии до Бразилии и Южной Африки. 00:14:54.160 --> 00:14:57.880 Без Front Door клиент в Токио подключается напрямую к вашему серверу в США. 00:14:58.080 --> 00:15:01.020 Каждое изображение, страница товара и запрос на оформление заказа 00:15:01.020 --> 00:15:02.140 должны пересечь Тихий океан. 00:15:02.280 --> 00:15:04.680 Это медленно, а если ваш сервер в США выйдет из строя, 00:15:04.840 --> 00:15:06.000 клиент просто увидит ошибку. 00:15:06.120 --> 00:15:07.320 Теперь добавим Front Door. 00:15:07.320 --> 00:15:09.260 Клиент в Токио открывает ваш сайт. 00:15:09.260 --> 00:15:12.460 Его браузер обращается к ближайшему узлу Азур, назовем его Токио. 00:15:12.600 --> 00:15:14.740 Этот узел проверяет состояние ваших трех серверов. 00:15:14.920 --> 00:15:15.620 Все они в порядке. 00:15:15.760 --> 00:15:16.800 Он измеряет задержку. 00:15:16.980 --> 00:15:18.600 Азиатский сервер отвечает быстрее всех, 00:15:18.820 --> 00:15:21.300 поэтому запрос направляется туда по частной магистрали Microsoft. 00:15:21.620 --> 00:15:23.960 Страница загружается меньше, чем за секунду вместо трех. 00:15:24.100 --> 00:15:27.180 Теперь представьте, что азиатский сервер перегружен во время распродажи. 00:15:27.360 --> 00:15:30.000 Датчики состояния Front Door фиксируют рост задержки. 00:15:30.200 --> 00:15:32.640 Система начинает перенаправлять трафик на европейский сервер, 00:15:32.640 --> 00:15:34.040 как на следующий лучший вариант. 00:15:34.240 --> 00:15:35.960 Клиенты по-прежнему получают быстрый доступ. 00:15:35.960 --> 00:15:40.080 Может, не такой быстрый, как с азиатского сервера, но все же лучше, чем соединение США. 00:15:40.280 --> 00:15:43.620 Весь процесс переключения происходит автоматически без вмешательства в настройки. 00:15:43.780 --> 00:15:45.740 Тем временем на периферии работает WAF. 00:15:45.880 --> 00:15:49.280 Он блокирует попытку SQL-инъекции от ботнета, сканирующего вашу форму оплаты. 00:15:49.400 --> 00:15:52.000 Он блокирует трафик от известных вредоносных IP-адресов 00:15:52.000 --> 00:15:55.340 и ограничивает частоту запросов с IP, который парсит ваш каталог товаров. 00:15:55.500 --> 00:15:58.040 Ни одна из этих атак даже не доходит до ваших исходных серверов. 00:15:58.040 --> 00:16:00.380 Ваша бэкенд-команда даже не узнает, что они были. 00:16:00.500 --> 00:16:06.000 А статический контент, изображение товаров, CSS-файлы, библиотеки JavaScript кэшируются в Токио. 00:16:06.120 --> 00:16:08.620 Первый посетитель загружает их с азиатского источника. 00:16:08.820 --> 00:16:11.760 Второй посетитель получает их мгновенно из периферийного кэша. 00:16:11.920 --> 00:16:14.580 Постоянные посетители видят почти мгновенную загрузку, 00:16:14.720 --> 00:16:17.440 так как все необходимое уже находится в ближайшем к нему зле. 00:16:17.600 --> 00:16:20.400 Все это – ускоренная маршрутизация, автоматическое переключение, 00:16:20.640 --> 00:16:23.340 защита периферии и кэширование контента – работает безупречно. 00:16:23.340 --> 00:16:25.320 Ваши клиенты даже не подозревают об этом. 00:16:25.460 --> 00:16:27.420 Они просто видят быстрый и надежный сайт. 00:16:27.420 --> 00:16:28.520 Что нужно запомнить? 00:16:28.680 --> 00:16:30.720 Azure Front Door действует как глобальный регулировщик, 00:16:30.840 --> 00:16:32.540 направляя пользователей на самый быстрый сервер, 00:16:32.700 --> 00:16:35.200 кэшируя контент и блокируя атаки до того, как они достигнут вас. 00:16:35.340 --> 00:16:37.140 Система построена на трех уровнях устойчивости, 00:16:37.320 --> 00:16:40.180 поэтому даже если регион выйдет из строя, ваш сайт останется доступным. 00:16:40.300 --> 00:16:43.600 Для большинства проектов стандартный тариф всего за 35 долларов в месяц – 00:16:43.600 --> 00:16:45.620 это оптимальное сочетание производительности и цены. 00:16:45.780 --> 00:16:49.240 Переходите на премиум-версию, когда потребуется расширенная защита или private link. 00:16:49.240 --> 00:16:52.080 Начните с малого, с одного источника и развивайтесь дальше. 00:16:52.240 --> 00:16:54.000 Front Door масштабируется вместе с вами. 00:16:54.000 --> 00:16:56.500 Если у вашего веб-приложения есть пользователи в разных регионах, 00:16:56.660 --> 00:16:58.100 настройте профиль Front Door уже сегодня. 00:16:58.280 --> 00:17:01.480 Даже один сервер получает преимущество глобального ускорения и защиты. 00:17:01.700 --> 00:17:03.540 Подписывайтесь на любимый подкаст-платформе 00:17:03.540 --> 00:17:06.320 и поделитесь этим с тем, кто только начинает свой путь в облаке.