WEBVTT

00:00:00.000 --> 00:00:03.320
Ви розміщуєте його в одному місці, скажімо, у Центрі обробки даних у Вірджинії.

00:00:03.480 --> 00:00:08.320
Для клієнтів у Нью-Йорку чи Чикаго це працює добре, але як щодо когось у Токіо, Лондоні чи Сіднеї.

00:00:08.520 --> 00:00:14.180
Щоразу, коли ця людина відвідує ваш сайт, її запит має долати океани і континенти, щоб дістатися вашого сервера.

00:00:14.300 --> 00:00:19.860
Кожне зображення, кожне завантаження сторінки, кожен виклик АРІ здійснює ту саму довгу подорож, і ця затримка швидко накопичується.

00:00:19.860 --> 00:00:26.480
Дослідження показують, що навіть одна секундна затримка завантаження сторінки може коштувати вам конверсій і відлякувати розчарованих відвідувачів.

00:00:26.480 --> 00:00:30.660
Але ось у чому річ, що станеться, коли ваш сайт стане віральним або ботнет вирішить його атакувати.

00:00:30.840 --> 00:00:34.940
Ваш єдиний сервер у Вірджинії буде перевантажений. Він сповільниться, а може навіть повністю вийти з ладу.

00:00:35.060 --> 00:00:36.820
Ви залишитеся без плану резервного копіювання.

00:00:37.000 --> 00:00:41.200
Ви можете вирішити проблему доступності, створивши копії вашого сайту в різних регіонах Токіо, Лондоні, Сан-Павлу.

00:00:41.200 --> 00:00:44.140
Це допомагає. Але тепер у вас з'являється нова проблема.

00:00:44.340 --> 00:00:46.520
Як спрямувати кожного відвідувача до потрібного місця?

00:00:46.520 --> 00:00:49.620
Ви ж не хочете, щоб хтось із Японії випадково потрапив на ваш американський сервер.

00:00:49.740 --> 00:00:53.640
Вам потрібен розумний спосіб маршрутизації трафіку, і саме тут на допомогу приходить Azure Front Do.

00:00:53.820 --> 00:00:57.120
Знайомтеся з глобальним регулювальником трафіку, ось що таке Azure Front Do.

00:00:57.260 --> 00:01:03.620
Уявіть Azure Front Do як глобального регулювальника не одного на перехресті, а тисячі таких, що стоять на головних вузлах по всьому світу.

00:01:03.620 --> 00:01:11.500
Щоразу, коли хтось відвідує ваш сайт, найближчий регулювальник втручається і каже «Ви в Токіо. Найшвидше сховище для вас знаходиться в Сінгапурі. Дозвольте мені відправити вас туди».

00:01:11.500 --> 00:01:14.080
Отже, чим це відрізняється від звичайного балансувальника навантаження?

00:01:14.240 --> 00:01:18.660
Більшість балансувальників працюють на четвертому рівні, дивлячись на IP-адреси та порти для маршрутизації трафіку.

00:01:18.820 --> 00:01:25.060
Це добре для базових потреб, але Azure Front Do працює на сьомому рівні, тобто він розуміє трафіки HTTP та HTTPS.

00:01:25.060 --> 00:01:33.600
Він може аналізувати URL-адресу, яку ввів користувач, перевіряти заголовки браузера, бачити, який контент запитується і приймати розумні рішення щодо маршрутизації на основі всього цього.

00:01:33.800 --> 00:01:45.100
Замість того, щоб просто сказати «Цей IP йде на той сервер», Front Do може сказати «Цей запит для користувачів АРІ йде на ваш сервер у США, а запит на зображення – докешованої копії в Токіо».

00:01:45.100 --> 00:01:47.300
Ось що робить це можливим залаштунками.

00:01:47.300 --> 00:01:55.740
Azure Front Do працює на глобальній мережі Microsoft, що налічує понад 210 точок присутності в більш ніж 130 містах по всьому світу.

00:01:55.900 --> 00:02:02.440
Уявіть кожну точку присутності як невеликий пункт регулювання, місцевий офіс у кожному великому місті, який може швидко обробити початковий запит.

00:02:02.600 --> 00:02:08.360
Коли користувач відвідує ваш сайт, він підключається до найближчого вузла замість того, щоб подорожувати до вашого вихідного сервера у Вірджинії.

00:02:08.520 --> 00:02:12.600
Потім цей вузол спрямовує їхній запит через приватну магістраль Microsoft до вашого бекенду.

00:02:12.600 --> 00:02:15.720
Це важливо, оскільки публічний інтернет не передбачуваний.

00:02:15.880 --> 00:02:21.060
Ваш трафік може пройти через десяток мереж, кожна з яких додає затримку та ризик втрати пакетів.

00:02:21.180 --> 00:02:26.960
Магістральна мережа Microsoft, навпаки, є приватною високошвидкісною мережею, що безпосередньо з'єднує їхні дата-центри.

00:02:27.100 --> 00:02:32.800
Тож, як тільки ваш запит потрапляє до найближчої точки присутності, решта шляху проходить швидкою та надійною магістралью.

00:02:32.800 --> 00:02:39.840
Ви отримуєте швидке завантаження, меншу затримку та кращий досвід для користувачів всюди, чи то в Токіо, Лондоні або Сан-Паулу.

00:02:39.980 --> 00:02:43.740
І все це відбувається автоматично, безвідома ваших відвідувачів.

00:02:47.160 --> 00:02:53.100
Можливо, ви думаєте, ідея глобального регулювальника трафіку чудова, але що буде, якщо він сам вийде з ладу?

00:02:53.240 --> 00:02:58.000
Якщо Azure FrontDo – це єдина точка входу для вашого застосунку, то це серйозна точка відмови, чи не так?

00:02:58.000 --> 00:03:03.140
Компанія Microsoft передбачила це. Вони вбудували три рівні стійкості у FrontDo, тому сервіс майже ніколи не вимикається.

00:03:03.300 --> 00:03:04.880
Дозвольте розповісти про них детальніше.

00:03:05.020 --> 00:03:06.680
Перший рівень – інтерфейс – FrontEnd.

00:03:06.860 --> 00:03:10.160
Пам'ятаєте ті понад 210 точок присутності, про які я згадував?

00:03:10.280 --> 00:03:12.980
Кожна з них є повністю незалежним вузлом обробки трафіку.

00:03:13.160 --> 00:03:19.660
Ці точки розташовані у понад 130 містах світу, працюючи в дата-центрах Microsoft та партнерських колокаційних центрах.

00:03:19.660 --> 00:03:25.540
Кожна точка має декілька стійок серверів з периферійними контролерами, що діють як вбудований балансувальник навантаження.

00:03:25.700 --> 00:03:31.100
Якщо один сервер у точці виходить з ладу, контролер перенаправляє трафік на справний у тій самій точці.

00:03:31.260 --> 00:03:35.000
А якщо виходить з ладу ціла точка, вступає в дію IP-адресація Anycast.

00:03:35.180 --> 00:03:38.600
Запит вашого відвідувача автоматично спрямовується до наступної найближчої точки.

00:03:38.820 --> 00:03:41.620
Жодних перебоїв чи ручного втручання – усе відбувається самостійно.

00:03:41.780 --> 00:03:43.320
Другий рівень – резервний – фолбек.

00:03:43.320 --> 00:03:45.080
Але що, якщо точка перевантажена?

00:03:45.260 --> 00:03:48.840
Скажімо, стався величезний стрибок трафіку, або кілька точок у регіоні відключилися одночасно.

00:03:48.980 --> 00:03:51.280
Решта точок можуть не впоратися з таким навантаженням.

00:03:51.440 --> 00:03:53.280
Саме тоді в гру вступає резервний рівень.

00:03:53.440 --> 00:03:57.980
Це окремий набір точок і їх десятки, а не сотні, що працюють на тому самому програмному забезпеченні та архітектурі.

00:03:58.100 --> 00:04:01.260
Вони розміщуються лише в дата-центрах Microsoft, а не в партнерських об'єктах.

00:04:01.380 --> 00:04:05.260
Коли фронтальній точці потрібно зменшити навантаження, вона перекидає запити на цей резервний рівень.

00:04:05.260 --> 00:04:07.640
Таке саме кешування, маршрутизація та безпека.

00:04:07.800 --> 00:04:09.660
Ваші відвідувачі ніколи не помітять різниці.

00:04:09.800 --> 00:04:12.620
Можливо, контент завантажиться трохи повільніше, але вони все одно його отримають.

00:04:12.760 --> 00:04:14.540
Третій рівень – це захисний екран трафіку.

00:04:14.700 --> 00:04:15.840
Це головний наглядач.

00:04:15.960 --> 00:04:19.440
Уявіть це як глобальний командний центр, що стежить за всією мережею фронт-до.

00:04:19.600 --> 00:04:23.200
Він моніторить моделі трафіку, рівні навантаження та стан усіх точок присутності POP.

00:04:23.420 --> 00:04:27.840
Коли він виявляє, що певні точки перевантажені, він не просто чекає на активацію резервного рівня.

00:04:27.840 --> 00:04:32.620
Він проактивно перенаправляє трафік, оновлюючи те, як DNS розпізнає ваш кінцевий вузол фронт-до.

00:04:32.760 --> 00:04:38.040
Він може перемикатися з глобальної Anycast IP-адреси на регіональну, повністю переводячи клієнтів на інші набори точок.

00:04:38.160 --> 00:04:40.160
За потреби він може навіть долати континенти.

00:04:40.380 --> 00:04:42.920
Саме захисний екран робить фронт-до майже магічним.

00:04:43.100 --> 00:04:47.220
Він постійно оптимізує роботу у фоновому режимі, коригуючи маршрути ще до виникнення проблем.

00:04:47.420 --> 00:04:49.040
Тепер я маю дещо зазначити.

00:04:49.180 --> 00:04:52.620
У жовтні 2025 року Azure Frontdo зазнав значного збою.

00:04:52.620 --> 00:04:59.500
Зміна конфігурації оминула перевірки безпеки, що спричинило масштабні проблеми в Microsoft 365, Xbox Live та тисячах клієнтських сайтів.

00:04:59.600 --> 00:05:01.300
Microsoft зробила з цього висновки.

00:05:01.500 --> 00:05:04.500
Вони прибрали всю асинхронну обробку з конвейера конфігурації.

00:05:04.660 --> 00:05:07.200
Тепер кожен шлях коду тестується під час розгортання.

00:05:07.380 --> 00:05:12.720
Вони скоротили час відкату з 4 годин до 1 і планують досягти 10 хвилин до березню 2026 року року.

00:05:12.860 --> 00:05:18.040
Вони також впроваджують мікрокоміркову сегментацію, щоб обмежити майбутній вплив до менш ніж 1% корендерів.

00:05:18.040 --> 00:05:25.980
Суть у тому, що жодна система не є ідеальною, але трирівнева архітектура Frontdo розроблена так, щоб витримувати регіональні збої, сплески трафіку і навіть деякі помилки конфігурації.

00:05:26.180 --> 00:05:28.340
Для більшості програм цього цілком достатньо.

00:05:28.480 --> 00:05:35.360
Для критично важливих систем ви можете додати Azure Traffic Manager перед Frontdo як аварійний шлях, але це вже складна тема для іншого разу.

00:05:35.480 --> 00:05:38.320
Як він спрямовує трафік, маршрутизація та групи джерел.

00:05:38.320 --> 00:05:45.400
Отже, у нас є цей глобальний регулювальник трафіку з понад 210 точками та трьома рівнями резервування, але як він насправді вирішує, куди відправити кожного відвідувача?

00:05:45.520 --> 00:05:47.300
Тут у гру вступають групи джерел.

00:05:47.440 --> 00:05:50.520
Група джерел – це, по суті, колекція ваших серверів беккенду.

00:05:50.680 --> 00:05:54.860
Уявіть, це як ваш список магазинів, реальні місця, де працює ваш сайт чи програма.

00:05:54.980 --> 00:05:58.320
У вас може бути один сервер у Північній Америці, один у Європі та один в Азії.

00:05:58.500 --> 00:06:00.340
Усі вони входять до однієї групи джерел.

00:06:00.340 --> 00:06:02.880
Тепер Франт До не просто сліпо надсилає трафік на всі з них.

00:06:03.020 --> 00:06:04.820
Він постійно перевіряє, чи вони працюють.

00:06:04.960 --> 00:06:06.840
Це називається перевіркою стану HealthPro.

00:06:07.100 --> 00:06:11.320
Кожні кілька секунд кожна точка Франт До пінгує ваші сервери, звертаючись до певного шляху,

00:06:11.420 --> 00:06:15.160
зазвичай до корення сайту або спеціальної кінцевої точки перевірки стану, як от Health.

00:06:15.320 --> 00:06:21.360
Якщо сервер не відповідає або видає код помилки, Франт До позначає його як непрацездатний і припиняє надсилати туди трафік.

00:06:21.360 --> 00:06:25.680
Це наче регулювальник, який перевіряє, чи відкритий магазин, перш ніж впускати покупців.

00:06:25.800 --> 00:06:30.680
Але коли у вас є кілька справних серверів, виникає питання, який із них має прийняти відвідувача.

00:06:30.820 --> 00:06:35.180
Франт До використовує три фактори для прийняття рішення – пріоритет, затримка та вага.

00:06:35.280 --> 00:06:37.340
І вони працюють разом у певному порядку.

00:06:37.500 --> 00:06:38.680
Перший – це пріоритет.

00:06:38.840 --> 00:06:41.820
Ви можете призначити один сервер основним, а інший – резервним.

00:06:42.040 --> 00:06:45.000
Встановіть для основного перший пріоритет, а для резервного – другий.

00:06:45.120 --> 00:06:47.540
За звичайних умов увесь трафік йде на основний сервер.

00:06:47.540 --> 00:06:50.320
Тож, якщо основний виходить з ладу, трафік перемикається на резервний.

00:06:50.460 --> 00:06:51.440
Просто чи не так?

00:06:51.540 --> 00:06:55.560
Це чудово підходить для схем «активний-пасивний», де ви хочете, щоб один регіон обробляв усе, поки він справний.

00:06:55.700 --> 00:06:58.020
Але що, якщо ви хочете, щоб обидва сервери були активними?

00:06:58.120 --> 00:06:59.580
Тут у гру вступає затримка.

00:06:59.740 --> 00:07:04.100
Якщо кілька серверів мають однаковий пріоритет, Франт До надсилає трафік на той, що має найменшу затримку,

00:07:04.180 --> 00:07:06.480
тобто найшвидший відвук із місця розташування відвідувача.

00:07:06.480 --> 00:07:11.420
Отже, користувач у Лондоні спрямовується на ваш європейський сервер, а користувач у Токіо – на азійський.

00:07:11.540 --> 00:07:15.120
Також існує налаштування чутливості, за замовчуванням це 50 мілісекунд.

00:07:15.260 --> 00:07:18.380
Якщо різниця в часі відповіді двох серверів становить менше, ніж 50 мілісекунд,

00:07:18.480 --> 00:07:20.000
Франт довважає їх однаково швидкими.

00:07:20.140 --> 00:07:23.860
Це запобігає постійному перемиканню між серверами, які мають приблизно однакову швидкість.

00:07:23.980 --> 00:07:26.320
А коли затримка однакова, у справу вступає вага.

00:07:26.440 --> 00:07:29.240
Ви можете призначити вагу, щоб розподілити трафік між серверами.

00:07:29.240 --> 00:07:31.920
Припустімо, ви хочете протестувати нову версію свого застосунку.

00:07:32.060 --> 00:07:35.160
Ви можете надати своєму поточному серверу вагу 90, а новому – вагу 10.

00:07:35.360 --> 00:07:39.640
Це означає, що приблизно 9 із 10 відвідувачів підуть на стару версію, а один із 10 – на нову.

00:07:39.760 --> 00:07:42.560
Це ідеально підходить для поступового розгортання, A-B-тестування

00:07:42.560 --> 00:07:45.500
або просто балансування навантаження між серверами з різною потужністю.

00:07:45.640 --> 00:07:48.520
Ось що важливо. Усе це відбувається автоматично.

00:07:48.520 --> 00:07:51.940
Ви один раз налаштовуєте групу джерел, а решту бере на себе Франт До.

00:07:51.940 --> 00:07:55.280
Він перевіряє ваші сервери, вимірює затримку, дотримується пріоритетів

00:07:55.280 --> 00:07:57.020
і розподіляє трафік залежно від ваги.

00:07:57.120 --> 00:08:00.780
І робить це все на периферії, ще до того, як запит дійде до вашої серверної частини.

00:08:00.920 --> 00:08:04.760
Це означає, що вашим серверам не потрібно визначати, звідки прийшов трафік або як його спрямувати.

00:08:04.980 --> 00:08:06.480
Вони лише обслуговують контент.

00:08:06.640 --> 00:08:08.920
Безпека на периферії, WAF та подальший захист.

00:08:09.020 --> 00:08:10.700
Тепер давайте поговоримо про безпеку.

00:08:10.700 --> 00:08:13.240
Оскільки Франт До розташований на самому краю мережі Microsoft,

00:08:13.240 --> 00:08:16.700
це ідеальне місце, щоб зупинити атаки ще до того, як вони досягнуть ваших серверів.

00:08:16.860 --> 00:08:19.660
Сприймайте це як контрольно-пропускний пункт на вході до будівлі.

00:08:19.780 --> 00:08:22.440
Кожен, хто хоче увійти, має спершу пройти через нього.

00:08:22.640 --> 00:08:26.000
Цей контрольний пункт називається BrandMaurum Web-додатків або WAF,

00:08:26.100 --> 00:08:28.460
і він вбудований як у Франт До Стендад, так і в преміум.

00:08:28.640 --> 00:08:31.000
Він автоматично блокує поширені веб-загрози.

00:08:31.000 --> 00:08:36.540
Наприклад, SQL-ін'єкції, коли зловмисник намагається впровадити шкідливі команди бази даних у поле форми

00:08:36.540 --> 00:08:40.400
або міжсайтовий скриптинг, де в сторінки впроваджуються скрипти або ДОС-атаки,

00:08:40.540 --> 00:08:42.700
спрямовані на перевантаження серверів трафіком.

00:08:42.920 --> 00:08:47.260
WAF перехоплює все це на периферії та відхиляє запити до того, як вони досягнуть вашого джерела.

00:08:47.440 --> 00:08:50.520
Окрім автоматичного захисту, ви також можете створювати власні правила.

00:08:50.680 --> 00:08:53.360
Наприклад, якщо ваш сайт призначений лише для клієнтів у Європі,

00:08:53.360 --> 00:08:55.740
ви можете повністю заблокувати трафік з інших регіонів.

00:08:55.860 --> 00:08:59.060
Або якщо ви помітили певний діапазон IP-адрес, що постійно сканує ваш сайт,

00:08:59.060 --> 00:09:00.340
ви можете заблокувати і його.

00:09:00.500 --> 00:09:03.160
Ви також можете фільтрувати трафік на основі заголовків запитів, шаблонів URL

00:09:03.160 --> 00:09:04.940
або навіть браузера, який використовує користувач.

00:09:05.120 --> 00:09:08.200
WAF надає дуже точний контроль над тим, хто отримує доступ, а хто ні.

00:09:08.340 --> 00:09:10.160
Ось тут і стають важливими ці нові рівні.

00:09:10.340 --> 00:09:14.580
Рівень Standard надає власні правила WAF, де ви самі визначаєте, що блокувати, а що дозволяти.

00:09:14.580 --> 00:09:19.540
Рівень Premium іде далі, додаючи керовані набори правил на основі аналізу загроз від Microsoft,

00:09:19.540 --> 00:09:24.220
який постійно оновлюється з урахуванням реальних атак, виявлених у всій мережі Microsoft.

00:09:24.400 --> 00:09:27.860
Premium також містить захист від ботів, що автоматично блокує скрапери,

00:09:28.020 --> 00:09:30.100
підбір облікових даних та інші типи ботів.

00:09:30.240 --> 00:09:33.340
Крім того, він додає підтримку Private Link, яка дозволяє підключатися до джерел

00:09:33.340 --> 00:09:35.720
через приватне мережеве з'єднання замість публічного інтернету.

00:09:35.720 --> 00:09:39.500
Це означає, що ваші серверні частини можуть бути повністю приховані від зовнішнього світу.

00:09:39.640 --> 00:09:41.520
Тільки FrontDo може отримати до них доступ.

00:09:41.720 --> 00:09:43.380
Це надзвичайно важливо для безпеки.

00:09:43.380 --> 00:09:45.460
Багато атак спрямовані не на FrontDo.

00:09:45.640 --> 00:09:47.580
Вони намагаються знайти чорний хід.

00:09:47.720 --> 00:09:50.120
Якщо ваш вихідний сервер має публічну IP-адресу,

00:09:50.220 --> 00:09:53.920
зловмисники можуть сканувати її напряму, оминаючи всі засоби захисту FrontDo.

00:09:54.100 --> 00:09:57.580
З Private Link це неможливо, оскільки джерело не має публічної кінцевої точки

00:09:57.580 --> 00:09:59.000
і доступне лише через FrontDo.

00:09:59.000 --> 00:10:02.500
Тож навіть якщо хтось дізнається IP вашого сервера, він не зможе до нього підключитися.

00:10:02.640 --> 00:10:04.220
Результат – ешелонований захист.

00:10:04.400 --> 00:10:06.360
WAF блокує атаки на рівні додатків.

00:10:06.360 --> 00:10:08.580
Власні правила вирішують ваші специфічні завдання.

00:10:08.760 --> 00:10:10.860
Захист від ботів зупиняє автоматизовані загрози.

00:10:11.000 --> 00:10:13.080
А Private Link робить ваші джерела невидимими.

00:10:13.240 --> 00:10:16.680
Усе це відбувається на периферії ще до того, як трафік досягне вашої інфраструктури,

00:10:16.760 --> 00:10:20.000
тому ваші сервери зосереджені на обслуговуванні контенту, а не на боротьбі з атаками.

00:10:20.280 --> 00:10:21.980
Кешування – пришвидшення роботи.

00:10:21.980 --> 00:10:25.280
Отже, ми розглянули маршрути за цію та безпеку, але є ще одна функція,

00:10:25.440 --> 00:10:27.360
яка робить FrontDo дуже корисною – кешування.

00:10:27.520 --> 00:10:28.580
Ось у чому ідея.

00:10:28.580 --> 00:10:31.320
Багато контенту вашого веб-сайту змінюється не дуже часто.

00:10:31.520 --> 00:10:36.500
Зображення, CSS-файли, бібліотеки JavaScript, фотографії продуктів, можливо, навіть деякі HTML-сторінки.

00:10:36.660 --> 00:10:39.860
Якщо кожен окремий відвідувач повинен завантажувати їх з вашого вихідного сервера,

00:10:39.940 --> 00:10:44.460
ви марнуєте час і пропускну здатність, оскільки сервер змушений обробляти один і той самий запит знову і знову,

00:10:44.460 --> 00:10:46.480
щоразу відправляючи ті самі байти через інтернет.

00:10:46.620 --> 00:10:50.320
Кешування виправляє це, зберігаючи копію статичного контенту на периферійному вузлі POP.

00:10:50.320 --> 00:10:55.320
Коли хтось наступного разу запитає той самий файл, вузл POP надасть його миттєво, навіть не звертаючись до вашого вихідного сервера.

00:10:55.400 --> 00:10:58.080
Це ніби мати невеликий склад біля кожного пункту пропуску.

00:10:58.240 --> 00:11:02.480
Замість того, щоб відправляти кожного клієнта назад на головний завод, ви просто даєте їм те, що вже є на полиці.

00:11:02.640 --> 00:11:04.400
Різниця в продуктивності вражаюча.

00:11:04.400 --> 00:11:08.500
Замість подорожі через океан і назад, відповідь приходить із сервера в тому самому місті.

00:11:08.820 --> 00:11:10.060
Мілісекунди замість секунд.

00:11:10.060 --> 00:11:15.940
А ваш вихідний сервер отримує перепочинок, оскільки він обробляє менше запитів і може зосередитися на динамічних завданнях, які дійсно потребують обробки.

00:11:16.060 --> 00:11:18.260
Отже, кешування не є автоматичним для всього.

00:11:18.480 --> 00:11:21.100
Ви самі контролюєте, що саме кешувати і як довго.

00:11:21.100 --> 00:11:25.820
Frant.do дотримується стандартних заголовків керування кешем з вашого сервера, як от Maxage або Smaxage,

00:11:25.900 --> 00:11:30.800
і ви також можете налаштовувати правила кешування безпосередньо, замінюючи заголовки вашого сервера, якщо це потрібно.

00:11:30.800 --> 00:11:35.820
Коли ви оновлюєте контент, ви можете очистити кеш і наказати Frant.do видалити старі копії та завантажити нові.

00:11:35.960 --> 00:11:40.520
Це важливо для таких речей, як запуск продуктів або зміна цін, де нова версія має стати видимою негайно.

00:11:40.520 --> 00:11:41.680
Ось у чому справа.

00:11:41.800 --> 00:11:44.280
Frant.do призначений не лише для статичного контенту.

00:11:44.400 --> 00:11:49.220
Навіть для динамічного контенту, як от АРІ, персоналізовані сторінки або кошики покупок, він прискорює доставку,

00:11:49.220 --> 00:11:53.880
оскільки як тільки запит потрапляє на найближчий вузол, він рухається до вашого сервера приватною магістралью Microsoft,

00:11:54.080 --> 00:11:55.500
а не через загальнодоступний інтернет.

00:11:55.660 --> 00:11:58.820
Ця приватна магістраль швидша та надійніша за відкриту мережу.

00:11:58.920 --> 00:12:01.620
Тож навіть не кешувані запити отримують прискорення.

00:12:01.620 --> 00:12:05.100
Це одна з ключових відмінностей між Frant.do і традиційною CDN.

00:12:05.260 --> 00:12:08.080
CDN кешує статичний контент і це, власне, все.

00:12:08.240 --> 00:12:11.240
Frant.do кешує статичний контент і прискорює все інше.

00:12:11.420 --> 00:12:12.800
Це угода два в одному.

00:12:13.020 --> 00:12:14.900
Тарифні плани, який з них обрати.

00:12:14.900 --> 00:12:18.000
Гаразд, давайте поговоримо про гроші, бо це головне питання.

00:12:18.200 --> 00:12:20.780
Скільки це коштує і який саме рівень вам слід обрати?

00:12:20.940 --> 00:12:23.400
Перш ніж ми перейдемо до цифр, ось чому це важливо.

00:12:23.600 --> 00:12:29.020
Вибраний рівень впливає не лише на ціну, а й визначає безпеку та функції, доступні для захисту вашого додатка.

00:12:29.020 --> 00:12:31.220
Як ви знаєте, Frant.do має три версії.

00:12:31.400 --> 00:12:32.680
Classic – це стара версія.

00:12:32.840 --> 00:12:36.180
Вона все ще працює, але Microsoft не рекомендує використовувати її для нових проєктів.

00:12:36.340 --> 00:12:38.380
Версія Classic поступово виводиться з експлуатації.

00:12:38.380 --> 00:12:42.860
Жодних нових ресурсів після 2025 року та повне припинення роботи до 2027 року.

00:12:42.960 --> 00:12:46.240
Тож, якщо ви починаєте з нуля, вам слід обирати між Standard або Premium.

00:12:46.460 --> 00:12:47.700
Ось найпростіший огляд.

00:12:47.880 --> 00:12:50.860
Тариф Standard коштує 35 доларів на місяць, як базова плата.

00:12:51.020 --> 00:12:53.660
Тариф Premium коштує 330 доларів на місяць.

00:12:53.780 --> 00:12:55.380
Це значний стрибок, але ось найцікавіше.

00:12:56.100 --> 00:12:59.380
Тарифи на передачу даних за гігабайт ідентичні для обох рівнів.

00:12:59.520 --> 00:13:04.820
У Північній Америці та Європі вихідний трафік коштує близько 8,25 цента за гігабайт для перших 10 терабайтів.

00:13:08.380 --> 00:13:11.560
Однакові для обох. Отже, що дають ці додаткові 300 доларів?

00:13:11.940 --> 00:13:13.140
Функціональні можливості.

00:13:13.260 --> 00:13:20.060
Premium додає керовані правила WAF на базі аналітики загроз Microsoft, які автоматично оновлюються на основі реальних моделей атак.

00:13:20.180 --> 00:13:26.560
Ви також отримуєте захист від ботів, підтримку Private Link, щоб ваше джерело залишалося прихованим від публічного інтернету та глибшу аналітику безпеки.

00:13:26.680 --> 00:13:31.720
Standard надає глобальне балансування навантаження, кешування, динамічне прискорення та користувацькі правила WAF.

00:13:31.720 --> 00:13:34.860
Ви можете блокувати діапазони IP-адрес, країни або шаблони запитів.

00:13:34.980 --> 00:13:37.540
Ви просто не отримуєте керовані набори правил або Private Link.

00:13:37.680 --> 00:13:39.340
Плата за запити також відрізняється.

00:13:39.560 --> 00:13:43.140
Standard коштує близько 9 центів за 10 тисяч запитів для перших 250 мільйонів.

00:13:43.260 --> 00:13:45.600
Premium коштує близько 15 центів за 10 тисяч запитів.

00:13:45.720 --> 00:13:47.500
При великих обсягах ця різниця стає відчутною.

00:13:47.620 --> 00:13:48.760
Тож як зробити вибір?

00:13:48.860 --> 00:13:49.740
Ось моє правило.

00:13:49.920 --> 00:13:55.020
Якщо ви керуєте типовим веб-сайтом або ARRI, яким потрібна глобальна продуктивність і базова безпека, почніть зі Standard.

00:13:55.020 --> 00:14:00.140
Базова плата 35 доларів є доступною, а користувацькі правила WAF впораються з більшістю поширених загроз.

00:14:00.280 --> 00:14:03.440
Ви завжди можете оновитися пізніше, якщо ваші вимоги до безпеки зростуть.

00:14:03.580 --> 00:14:10.580
Якщо ви працюєте в регулюваній галузі, як-от охорона здоров'я, фінанси, державний сектор або обробляєте конфіденційні дані клієнтів, преміум вартий додаткових витрат.

00:14:10.680 --> 00:14:14.320
Керовані правила WAF виявляють загрози, про блокування яких ви могли навіть не подумати.

00:14:14.320 --> 00:14:19.460
Private Link робить ваші джерела невидимими, а захист від ботів зупиняє автоматизовані атаки, які Standard не зміг би виявити.

00:14:19.620 --> 00:14:25.720
Останнє, якщо ви надаєте лише статичний контент і вам не потрібна маршрутизація чи функції безпеки, традиційна мережа CDN може бути дешевшою.

00:14:25.860 --> 00:14:30.920
Azure CDN від Microsoft все ще існує, і для передачі сутостатичного контенту це часто вигідніше.

00:14:31.060 --> 00:14:38.220
Але для більшості реальних застосунків, де потрібні маршрутизація, безпека, кешування та прискорення, франт до Standard є ідеальним вибором.

00:14:38.220 --> 00:14:40.720
Підсумовуючи, розглянемо реальний приклад.

00:14:40.900 --> 00:14:45.220
Дозвольте мені розповісти про реальний сценарій, щоб ви побачили, як саме ці компоненти працюють разом.

00:14:45.360 --> 00:14:47.600
Уявіть, що ви керуєте сайтом електронної комерції.

00:14:47.780 --> 00:14:50.640
Ви маєте сервери в трьох регіонах – Північній Америці, Європі та Азії.

00:14:50.640 --> 00:14:53.960
Ваші клієнти всюди – від Японії до Бразилії та Південної Африки.

00:14:54.100 --> 00:14:57.960
Без франт до клієнт у Токіо підключається безпосередньо до вашого сервера в США.

00:14:57.960 --> 00:15:02.100
Кожне зображення, сторінка продукту та запит на оформлення замовлення має перетнути тихий океан.

00:15:02.220 --> 00:15:02.940
Це повільно.

00:15:03.060 --> 00:15:05.940
А якщо ваш сервер у США вийде з ладу, клієнт просто побачить помилку.

00:15:06.080 --> 00:15:07.260
Тепер додайте франт до.

00:15:07.420 --> 00:15:09.300
Клієнт у Токіо відкриває ваш сайт.

00:15:09.300 --> 00:15:12.540
Його браузер звертається до найближчого вузла Azure, назвімо його Tokyo.

00:15:12.740 --> 00:15:15.460
Цей вузол перевіряє стан трьох ваших серверів, вони справні.

00:15:15.620 --> 00:15:16.840
Він вимірює затримку.

00:15:17.000 --> 00:15:21.300
Азійський сервер відповідає найшвидше, тому він спрямовує запит туди через приватну магістраль Microsoft.

00:15:21.300 --> 00:15:24.000
Сторінка завантажується менш ніж за секунду замість трьох.

00:15:24.120 --> 00:15:27.180
Тепер уявіть, що азійський сервер перевантажений під час розпродажу.

00:15:27.360 --> 00:15:29.940
Зонди стану франт до виявляють підвищену затримку.

00:15:29.940 --> 00:15:34.100
Він починає перенаправляти трафік на європейський сервер, найкращий варіант після першого.

00:15:34.260 --> 00:15:39.960
Клієнти все одно отримують швидку роботу, можливо, не таку швидку, як з азійським сервером, але швидше, ніж через США.

00:15:40.120 --> 00:15:43.600
Увесь процес перемикання відбувається автоматично, без втручання в налаштування.

00:15:43.740 --> 00:15:45.760
Тим часом на периферії працює WAF.

00:15:45.760 --> 00:15:49.120
Він блокує спробу SQL-ін'єкції від ботнету, що сканує вашу форму оплати.

00:15:49.300 --> 00:15:51.980
Він блокує трафік із відомих шкідливих діапазонів IP-адрес.

00:15:51.980 --> 00:15:55.460
І обмежує частоту запитів від IP, який витягує дані з вашого каталогу товарів.

00:15:55.580 --> 00:15:57.880
Жодна з цих атак не доходить до ваших вихідних серверів.

00:15:58.060 --> 00:16:00.440
Ваша команда бекенду навіть не знає, що вони відбулися.

00:16:00.560 --> 00:16:05.960
А статичний контент, зображення товарів, файли CSS, бібліотеки JavaScript кешуються у вузлів Токіо.

00:16:06.100 --> 00:16:08.640
Перший відвідувач завантажує їх з азійського джерела.

00:16:08.640 --> 00:16:12.000
Другий відвідувач миттєво отримує їх із периферійного кешу.

00:16:12.140 --> 00:16:17.360
Повторні відвідувачі бачать миттєве завантаження, бо все необхідне вже є на найближчому вузлі.

00:16:17.500 --> 00:16:23.140
Усе це швидка маршрутизація, автоматичне перемикання, захист і кешування працює разом бездоганно.

00:16:23.320 --> 00:16:25.220
Ваші клієнти навіть не здогадуються про це.

00:16:25.420 --> 00:16:27.320
Вони просто бачать швидкий і надійний сайт.

00:16:27.480 --> 00:16:28.820
Ось що варто запам'ятати.

00:16:28.820 --> 00:16:35.160
Azure Front.do діє як глобальний регулювальник, спрямовуючи користувачів на швидші сервери, кешуючи контент і блокуючи атаки.

00:16:35.380 --> 00:16:40.140
Він побудований на трьох рівнях стійкості, тому навіть якщо регіон вийде з ладу, ваш сайт працюватиме.

00:16:40.300 --> 00:16:45.640
Для більшості проєктів стандартний тариф за 35 доларів на місяць – це баланс продуктивності та вартості.

00:16:45.800 --> 00:16:49.440
Переходьте на преміум, якщо потрібна розширена безпека або приватний зв'язок.

00:16:49.580 --> 00:16:51.900
Починайте з одного джерела і масштабуйтеся.

00:16:52.060 --> 00:16:53.800
Front.do зростає разом із вами.

00:16:53.800 --> 00:16:58.060
Якщо ваш застосунок має користувачів у різних регіонах, налаштуйте профіль Front.do вже сьогодні.

00:16:58.200 --> 00:17:01.460
Навіть один сервер отримує переваги глобального прискорення та безпеки.

00:17:01.580 --> 00:17:06.260
Підписуйтесь на вашу улюблену подкаст-платформу і діліться цим із тими, хто починає свій шлях у хмари.