WEBVTT

00:00:00.000 --> 00:00:03.220
버지니아에 있는 데이터센터와 같이 한 곳에 호스팅한다고 가정해봅시다.

00:00:03.360 --> 00:00:05.520
뉴욕이나 시카고의 고객들에게는 괜찮겠지만

00:00:05.520 --> 00:00:08.540
도쿄나 런던, 시드니에 있는 사람들은 어떨까요?

00:00:08.720 --> 00:00:10.300
그 사람이 사이트를 방문할 때

00:00:10.300 --> 00:00:13.900
마다 요청은 서버에 도달하기 위해 바다와 대륙을 건너야 합니다.

00:00:14.120 --> 00:00:18.180
이미지 하나, 페이지 로드 하나, API 호출 하나 마다 같은 긴 여정을 거치며

00:00:18.180 --> 00:00:19.920
그 지연 시간은 빠르게 누적됩니다.

00:00:20.120 --> 00:00:23.100
실제로 연구에 따르면 페이지 로드 시간이 1초만 지연되어도

00:00:23.100 --> 00:00:26.480
전환율이 떨어지고 답답함을 느낀 방문자가 떠나버릴 수 있습니다.

00:00:26.480 --> 00:00:29.580
하지만 사이트가 입소문을 타거나 본넥 공격을 받으면

00:00:29.580 --> 00:00:30.380
어떻게 될까요?

00:00:30.520 --> 00:00:32.800
버지니아에 있는 단 하나의 서버는 엄청난 부하를 받게 됩니다.

00:00:32.960 --> 00:00:34.960
속도가 느려지고 심하면 완전히 중단될 수도 있습니다.

00:00:35.120 --> 00:00:36.800
대비책이 없다면 꼼짝없이 당하게 됩니다.

00:00:37.000 --> 00:00:39.840
도쿄, 런던, 상파울로와 같은 다른 지역의 사이트 복제본을 만들어

00:00:39.840 --> 00:00:41.080
가용성 문제를 해결할 수 있습니다.

00:00:41.260 --> 00:00:42.200
그러면 도움이 됩니다.

00:00:42.480 --> 00:00:44.100
하지만 이제 새로운 문제가 생깁니다.

00:00:44.300 --> 00:00:46.480
각 방문자를 어떻게 올바른 위치로 안내할까요?

00:00:46.660 --> 00:00:49.480
일본에 있는 사람이 실수로 미국 서버에 접속하게 하고 싶지는 않을 겁니다.

00:00:49.680 --> 00:00:51.520
트래픽을 라우팅할 스마트한 방법이 필요한데

00:00:51.520 --> 00:00:53.540
바로 이때 에이저 프론트 도어가 등장합니다.

00:00:53.540 --> 00:00:56.600
에이저 프론트 도어, 즉 글로벌 교통경찰을 만나보세요.

00:00:56.780 --> 00:00:59.580
에이저 프론트 도어를 글로벌 교통경찰이라고 생각해보세요.

00:00:59.780 --> 00:01:00.980
교차로 한 곳에만 있는 것이 아니라

00:01:00.980 --> 00:01:03.740
전세계 주요 교차로마다 수천 명의 경찰이 배치된 셈입니다.

00:01:03.920 --> 00:01:06.900
누군가 웹사이트를 방문할 때마다 가장 가까운 경찰이 나서서 말합니다.

00:01:07.080 --> 00:01:08.060
도쿄에 계시군요.

00:01:08.220 --> 00:01:09.860
가장 빠른 매장은 싱가포르에 있습니다.

00:01:10.200 --> 00:01:11.240
그쪽으로 안내해드릴게요.

00:01:11.580 --> 00:01:13.860
그렇다면 일반 로드밸런서와는 무엇이 다를까요?

00:01:14.040 --> 00:01:16.080
대부분의 로드밸런서는 계층 4에서 작동하며

00:01:16.080 --> 00:01:18.440
IP 주소와 포트를 보고 트래픽을 라우팅합니다.

00:01:18.640 --> 00:01:20.040
기본적인 용도로는 충분하지만

00:01:20.040 --> 00:01:22.600
에이저 프론트 도어는 계층 7에서 작동하므로

00:01:22.600 --> 00:01:25.300
HTTP 및 HTTPS 트래픽을 이해합니다.

00:01:25.520 --> 00:01:27.260
사용자가 입력한 URL을 살펴보고

00:01:27.260 --> 00:01:28.880
브라우저 헤더를 확인하며

00:01:28.880 --> 00:01:31.000
어떤 콘텐츠를 요청하는지 파악하여

00:01:31.000 --> 00:01:33.260
이를 바탕으로 스마트한 라우팅 결정을 내립니다.

00:01:33.500 --> 00:01:36.460
이 IP는 저 서버로 보낸다 라고 단순히 말하는 대신

00:01:36.460 --> 00:01:40.440
프론트 도어는 API 사용자에 대한 요청은 미국 백엔드로 보내고

00:01:40.440 --> 00:01:43.640
이미지에 대한 요청은 도쿄에 캐시된 복사본으로 보낸다

00:01:43.640 --> 00:01:44.460
고 할 수 있습니다.

00:01:44.700 --> 00:01:47.480
이제 이 모든 것을 가능하게 하는 내부 구조를 살펴보겠습니다.

00:01:47.480 --> 00:01:51.220
에이저 프론트 도어는 전세계 130개 이상의 메트로 지역에 걸쳐

00:01:51.220 --> 00:01:54.320
210개 이상의 거점, 팝을 갖춘 마이크로소프트의

00:01:54.320 --> 00:01:55.940
글로벌 네트워크에서 실행됩니다.

00:01:56.120 --> 00:01:59.040
각 거점을 작은 교통 초소, 즉 모든 주요 도시에서

00:01:59.040 --> 00:02:02.320
초기 요청을 빠르게 처리할 수 있는 지역 사무소라고 생각해보세요.

00:02:02.580 --> 00:02:03.880
사용자가 사이트를 방문하면

00:02:03.880 --> 00:02:06.500
버지니아에 있는 원본 서버까지 멀리 이동하는 대신

00:02:06.500 --> 00:02:08.140
가장 가까운 거점으로 연결됩니다.

00:02:08.340 --> 00:02:10.920
그러면 해당 거점은 마이크로소프트 위 전용 백본망을 통해

00:02:10.920 --> 00:02:12.540
사용자의 요청을 백엔드로 전달합니다.

00:02:12.740 --> 00:02:15.540
공용 인터넷은 예측할 수 없기 때문에 이것이 중요합니다.

00:02:15.540 --> 00:02:18.680
트래픽이 여러 네트워크를 거치며 10여번이 홉을 통과할 때마다

00:02:18.680 --> 00:02:21.500
지연 시간과 잠재적 임팩트 손실이 발생할 수 있습니다.

00:02:21.680 --> 00:02:23.500
반면에 마이크로소프트 위 백보는

00:02:23.500 --> 00:02:26.700
데이터 센터를 직접 연결하는 전용 고속 네트워크입니다.

00:02:26.920 --> 00:02:29.120
따라서 요청이 가장 가까운 거점에 도달하면

00:02:29.120 --> 00:02:32.500
나머지 여정은 빠르고 안정적인 고속도로에서 이루어집니다.

00:02:32.660 --> 00:02:35.160
도쿄, 런던, 상파울로 어디에 있든 상관없이

00:02:35.160 --> 00:02:38.120
모든 사용자가 더 빠른 로드 시간, 더 낮은 지연 시간,

00:02:38.500 --> 00:02:39.760
더 나은 경험을 누릴 수 있습니다.

00:02:39.980 --> 00:02:42.620
이 모든 과정은 방문자가 전혀 알지 못하는 사이에

00:02:42.620 --> 00:02:43.800
자동으로 이루어집니다.

00:02:43.800 --> 00:02:47.180
3중 보건역 계층, AFD가 유지되는 방법

00:02:47.180 --> 00:02:49.780
이제 전 세계적인 교통경찰이라는 아이디어는 좋지만

00:02:49.780 --> 00:02:53.220
경찰 자체가 멈추면 어떻게 될까 하는 생각이 들지도 모릅니다.

00:02:53.400 --> 00:02:55.620
에이저 프론트 도어가 전체 앱의 단일 진입점이라면

00:02:55.620 --> 00:02:58.000
이는 꽤 큰 단일 장애 지점이 될 수 있지 않을까요?

00:02:58.400 --> 00:02:59.900
마이크로소프트는 그 점을 고려했습니다.

00:03:00.060 --> 00:03:01.800
그들은 프론트 도어의 3중 보건역 계층을 구축하여

00:03:01.800 --> 00:03:03.160
서비스가 거의 중단되지 않도록 했습니다.

00:03:03.360 --> 00:03:04.780
그 계층들을 하나씩 살펴보겠습니다.

00:03:05.120 --> 00:03:06.820
첫 번째 계층은 프론트 엔드입니다.

00:03:07.080 --> 00:03:09.840
제가 언급했던 210개 이상의 거점 기억하시나요?

00:03:09.840 --> 00:03:12.620
각각은 완전히 독립적인 트래픽 거점입니다.

00:03:12.820 --> 00:03:15.800
이러한 팝은 전 세계 130개 이상의 대도시 지역에 위치하며

00:03:15.800 --> 00:03:19.820
마이크로소프트 데이터 센터 및 파트너 코로케이션 시설 내에서 운영됩니다.

00:03:20.020 --> 00:03:22.100
모든 팝은 여러 서버 렉을 보유하고 있으며

00:03:22.100 --> 00:03:25.360
상단에 엣지 컨트롤러가 내장형 로드밸런서 역할을 합니다.

00:03:25.580 --> 00:03:26.960
팝 내의 서버 하나가 실패하면

00:03:26.960 --> 00:03:30.960
엣지 컨트롤러가 트래픽을 동일한 팝 내의 정상 서버로 즉시 라우팅합니다.

00:03:31.220 --> 00:03:32.240
만약 전체 팝이 다운되면

00:03:32.240 --> 00:03:35.280
그때 애니캐스트, 애니캐스트, IP 주소 지정이 작동합니다.

00:03:35.280 --> 00:03:38.460
방문자의 요청은 자동으로 가장 가까운 다음 팝으로 전달됩니다.

00:03:38.620 --> 00:03:41.360
중단도 없고 수동 개입도 필요 없으며 그냥 자동으로 처리됩니다.

00:03:41.520 --> 00:03:43.320
두 번째 계층은 대체, 폴백 계층입니다.

00:03:43.500 --> 00:03:45.340
하지만 팝이 과부하 상태가 되면 어떻게 될까요?

00:03:45.500 --> 00:03:48.780
엄청난 트래픽 급증이나 한 지역의 여러 팝 이동시에 다운되는 상황을 가정해봅시다.

00:03:48.980 --> 00:03:51.300
남은 팝만으로는 부하를 감당하지 못할 수도 있습니다.

00:03:51.520 --> 00:03:53.200
바로 그때 대체 계층이 나섭니다.

00:03:53.400 --> 00:03:55.440
이는 수백 개가 아닌 수십 개의 별도 팝 세트로

00:03:55.440 --> 00:03:57.780
동일한 소프트웨어와 아키텍처를 실행합니다.

00:03:57.780 --> 00:04:01.260
이들은 파트너 시설이 아닌 마이크로소프트 데이터 센터 내에만 존재합니다.

00:04:01.420 --> 00:04:03.280
프론트 엔드 팝 이 트래픽을 분산해야 할 때

00:04:03.280 --> 00:04:05.020
요청을 이 대체 계층으로 전환합니다.

00:04:05.200 --> 00:04:07.680
동일한 캐싱, 동일한 나우팅, 동일한 보안이 적용됩니다.

00:04:07.840 --> 00:04:09.540
방문자는 그 차이를 전혀 느끼지 못합니다.

00:04:09.720 --> 00:04:11.240
콘텐츠를 받는 속도가 약간 느려질 수는 있어도

00:04:11.240 --> 00:04:12.680
여전히 콘텐츠를 문제없이 수신합니다.

00:04:12.840 --> 00:04:14.460
세 번째 계층, 트래픽 쉴드입니다.

00:04:14.660 --> 00:04:15.780
이것이 바로 관리자입니다.

00:04:16.040 --> 00:04:17.640
전체 프론트 도어 네트워크를 감시하는

00:04:17.640 --> 00:04:19.460
글로벌 지휘센터라고 생각하시면 됩니다.

00:04:19.460 --> 00:04:23.200
모든 팝에 걸친 트래픽 패턴, 부하 수준, 상태를 모니터링합니다.

00:04:23.320 --> 00:04:24.860
특정 팝에 과부하가 감지되면

00:04:24.860 --> 00:04:27.720
단순히 풀백 계층이 작동하기를 기다리지 않습니다.

00:04:27.920 --> 00:04:31.100
dns가 프론트 도어 엔드포인트를 확인하는 방식을 업데이트하여

00:04:31.100 --> 00:04:32.600
선제적으로 트래픽을 전환합니다.

00:04:32.820 --> 00:04:35.280
글로벌 애니캐스트 ip에서 지역 ip로 전환하여

00:04:35.280 --> 00:04:37.840
클라이언트를 완전히 다른 팝세트로 이동시킬 수 있습니다.

00:04:38.040 --> 00:04:39.900
필요하다면 대륙을 넘나들 수도 있습니다.

00:04:40.140 --> 00:04:43.100
트래픽 쉴드는 프론트 도어를 마법처럼 느껴지게 만드는 핵심입니다.

00:04:43.300 --> 00:04:45.240
백그라운드에서 끊임없이 최적화를 수행하며

00:04:45.240 --> 00:04:47.160
문제가 발생하기 전에 경로를 조정합니다.

00:04:47.360 --> 00:04:49.100
이제 한 가지 언급할 점이 있습니다.

00:04:49.360 --> 00:04:52.460
2025년 10월, 에이저 프론트 도어는 심각한 장애를 겪었습니다.

00:04:52.740 --> 00:04:54.560
구성 변경 과정에서 안전성 검사가 누락되어

00:04:54.560 --> 00:04:56.800
마이크로소프트 365, 엑스박스 라이브 및

00:04:56.800 --> 00:04:59.100
수천 개의 고객 웹사이트에 광범위한 문제가 발생했습니다.

00:04:59.480 --> 00:05:01.480
마이크로소프트는 그 사건에서 교훈을 얻었습니다.

00:05:01.740 --> 00:05:04.340
구성 파이프라인에서 모든 비동기 처리를 제거했습니다.

00:05:04.680 --> 00:05:07.220
이제 모든 코드 경로는 롤아웃 중에 테스트를 거칩니다.

00:05:07.500 --> 00:05:09.860
롤백 시간을 4시간에서 1시간으로 단축했으며

00:05:09.860 --> 00:05:12.560
2026년 3월까지 10분을 목표로 하고 있습니다.

00:05:12.560 --> 00:05:15.560
또한 마이크로셀 세분화를 도입하여 향후 발생할 영향을

00:05:15.560 --> 00:05:17.880
테넌트의 1% 미만으로 제한하고 있습니다.

00:05:18.100 --> 00:05:19.400
핵심은 완벽한 시스템은 없지만

00:05:19.400 --> 00:05:21.240
프론트 도어 위 3계층 아키텍처는

00:05:21.240 --> 00:05:22.880
지역적 장애, 트래픽 급증,

00:05:23.220 --> 00:05:25.800
심지어 일부 구성 오류까지 견뎌내 도록 설계되었다는 것입니다.

00:05:25.960 --> 00:05:28.280
대부분의 애플리케이션에는 그 정도로 충분합니다.

00:05:28.480 --> 00:05:30.280
정말 중요한 미션 크리티컬 시스템의 경우

00:05:30.280 --> 00:05:32.200
비상 경로로 에이저 트래픽 매니저를

00:05:32.200 --> 00:05:33.500
프론트 도어 앞에 배치할 수 있지만

00:05:33.500 --> 00:05:35.240
이는 나중에 다룰 고급 주제입니다.

00:05:35.400 --> 00:05:36.560
트래픽을 유도하는 방식,

00:05:36.560 --> 00:05:38.680
나우팅 및 오리진 그룹에 대해 알아봅시다.

00:05:38.840 --> 00:05:41.200
210개 이상의 부수와 3중 백업을 갖추니

00:05:41.200 --> 00:05:43.160
글로벌 교통경찰이 각 방문자를

00:05:43.160 --> 00:05:45.140
어디로 보낼지 어떻게 결정할까요?

00:05:45.320 --> 00:05:47.360
거기에 바로 오리진 그룹이 사용됩니다.

00:05:47.580 --> 00:05:49.020
오리진 그룹은 기본적으로

00:05:49.020 --> 00:05:50.480
백엔드 서버의 집합입니다.

00:05:50.740 --> 00:05:52.680
웹사이트 나앱이 실제로 실행되는

00:05:52.680 --> 00:05:54.580
매장 목록이라고 생각하면 됩니다.

00:05:54.880 --> 00:05:56.520
북미의 서버 하나, 유럽의 하나,

00:05:56.900 --> 00:05:58.120
아시아의 하나를 둘 수 있습니다.

00:05:58.380 --> 00:06:00.160
이들은 모두 같은 오리진 그룹에 포함됩니다.

00:06:00.380 --> 00:06:02.000
이제 프론트 도어는 모든 서버에 맹목적으로

00:06:02.000 --> 00:06:02.920
트래픽을 보내지 않습니다.

00:06:02.920 --> 00:06:04.800
끊임없이 서버가 살아있는지 확인합니다.

00:06:04.960 --> 00:06:07.100
이를 상태 프로브, 헬스 프로브라고 합니다.

00:06:07.300 --> 00:06:09.380
매초각 프론트 도어 팝은 특정 경로,

00:06:09.660 --> 00:06:11.780
일반적으로 사이트의 루트, 나 헬스 같은

00:06:11.780 --> 00:06:14.020
전용 상태 엔드포인트를 호출하여

00:06:14.020 --> 00:06:14.940
서버를 확인합니다.

00:06:15.180 --> 00:06:17.440
서버가 응답하지 않거나 오류 코드를 반환하면

00:06:17.440 --> 00:06:19.860
프론트 도어는 이를 비정상으로 표시하고

00:06:19.860 --> 00:06:21.220
트래픽 전송을 중단합니다.

00:06:21.420 --> 00:06:23.300
마치 교통경찰이 고객을 보내기 전에

00:06:23.300 --> 00:06:25.660
매장이 실제로 열려있는지 확인하는 것과 같습니다.

00:06:26.020 --> 00:06:28.120
하지만 정상적인 서버가 여러 대 있다면

00:06:28.120 --> 00:06:30.280
방문자를 어디로 보내야 할까요?

00:06:30.280 --> 00:06:32.560
프론트 도어는 우선 순위, 지연 시간,

00:06:32.560 --> 00:06:34.960
가중치라는 세 가지 요소를 사용하여 결정합니다.

00:06:35.120 --> 00:06:37.300
이 요소들은 특정 순서에 따라 함께 작동합니다.

00:06:37.460 --> 00:06:38.780
첫 번째는 우선 순위입니다.

00:06:38.980 --> 00:06:40.140
한 서버를 기본으로 지정하고

00:06:40.140 --> 00:06:41.800
다른 서버를 백업으로 지정할 수 있습니다.

00:06:42.020 --> 00:06:44.900
기본 서버를 우선 순위로, 백업 서버를 우선 순위로 설정하세요.

00:06:45.080 --> 00:06:47.680
정상적인 상황에서는 모든 트래픽이 기본 서버로 전달됩니다.

00:06:47.840 --> 00:06:48.980
따라서 기본 서버가 다운되면

00:06:48.980 --> 00:06:50.440
트래픽이 백업 서버로 전환됩니다.

00:06:50.680 --> 00:06:51.200
간단하죠.

00:06:51.420 --> 00:06:53.180
이는 장애가 발생하지 않는 한 하나의 리전에서

00:06:53.180 --> 00:06:55.400
모든 것을 처리하려는 액티브 패시브 설정에 유용합니다.

00:06:55.580 --> 00:06:57.340
하지만 두 서버를 모두 활성 상태로 유지하고 싶다면

00:06:57.340 --> 00:06:58.060
어떻게 해야 할까요?

00:06:58.060 --> 00:06:59.540
그때 지연 시간이 필요합니다.

00:06:59.660 --> 00:07:01.140
여러 서버의 우선 순위가 동일한 경우

00:07:01.140 --> 00:07:03.580
프론트 도어는 지연 시간이 가장 짧은 서버,

00:07:03.600 --> 00:07:06.520
즉 방문자의 위치에서 응답 시간이 가장 빠른 서버로 트래픽을 보냅니다.

00:07:06.680 --> 00:07:08.760
따라서 런던에 있는 사용자는 유럽 서버로,

00:07:09.200 --> 00:07:11.680
도쿄에 있는 사용자는 아시아 서버로 연결됩니다.

00:07:11.880 --> 00:07:14.600
기본값이 50mm 초인 민감도 설정도 있습니다.

00:07:14.920 --> 00:07:17.120
두 서버 간 지연 시간 차이가 50mm 초 이내라면

00:07:17.120 --> 00:07:19.880
프론트 도어는 두 서버의 속도가 동일하다고 간주합니다.

00:07:20.120 --> 00:07:22.060
이렇게 하면 속도가 거의 비슷한 서버 간에

00:07:22.060 --> 00:07:23.760
계속 전환되는 것을 방지할 수 있습니다.

00:07:24.020 --> 00:07:26.260
지연 시간이 동일할 때는 가중치가 적용됩니다.

00:07:26.260 --> 00:07:29.260
가중치를 할당하여 서버 간의 트래픽을 분산할 수 있습니다.

00:07:29.440 --> 00:07:31.680
앱의 새 버전을 테스트하고 싶다고 가정해보겠습니다.

00:07:32.040 --> 00:07:35.120
현재 서버의 90, 새 서버의 12 가중치를 부여할 수 있습니다.

00:07:35.360 --> 00:07:37.720
즉 방문자 10명 중 약 9명은 기존 버전으로,

00:07:38.120 --> 00:07:39.520
1명은 새 버전으로 이동합니다.

00:07:39.720 --> 00:07:40.840
이는 점진적인 롤아웃,

00:07:41.140 --> 00:07:44.920
AB 테스트 또는 용량이 서로 다른 서버 간의 부하 분산에 매우 적합합니다.

00:07:45.140 --> 00:07:46.400
여기서 중요한 점이 있습니다.

00:07:46.700 --> 00:07:48.760
이 모든 과정이 자동으로 이루어진다는 것입니다.

00:07:48.980 --> 00:07:51.940
원본 그룹을 한 번만 구성하면 나머지는 프론트 도어가 처리합니다.

00:07:52.180 --> 00:07:54.180
서버를 검사하고, 지연 시간을 측정하고,

00:07:54.180 --> 00:07:57.140
우선 순위를 준수하며, 가중치에 따라 트래픽을 분산합니다.

00:07:57.280 --> 00:08:00.780
또한 이 모든 작업을 요청이 백엔드에 도달하기 전 엣지에서 수행합니다.

00:08:00.980 --> 00:08:04.260
즉, 서버가 트래픽에 출처 나 라우팅 방법을 파악할 필요가 없습니다.

00:08:04.580 --> 00:08:06.440
서버는 그저 콘텐츠를 제공하기만 하면 됩니다.

00:08:06.700 --> 00:08:08.840
엣지에서의 보안, 웹브 등 다양한 기능에 대해 알아봅니다.

00:08:09.000 --> 00:08:10.660
자, 이제 보안에 대해 이야기해보겠습니다.

00:08:11.000 --> 00:08:13.680
프론트 도어는 마이크로소프트 네트워크의 가장 엣지에 위치하므로,

00:08:14.040 --> 00:08:16.740
공격이 서버에 도달하기 전에 차단하기에 가장 완벽한 장소입니다.

00:08:16.920 --> 00:08:19.460
건물 입구에 있는 보안 검색대라고 생각하면 됩니다.

00:08:19.460 --> 00:08:22.340
입장을 원하는 사람은 누구나 먼저 통과해야 합니다.

00:08:22.500 --> 00:08:25.520
이 검문소를 웹 애플리케이션 방화벽, 웹이라고 하며,

00:08:25.860 --> 00:08:28.380
프론트 도어 스탠다드와 프리미엄 모드에 내장되어 있습니다.

00:08:28.680 --> 00:08:30.860
일반적인 웹 공격을 자동으로 차단합니다.

00:08:31.100 --> 00:08:35.460
공격자가 폼필드에 악성 데이터베이스 명령을 몰래 삽입하는 SQL 인젝션,

00:08:35.460 --> 00:08:37.720
페이지에 스크립트를 삽입하는 사이트 간 스크립팅,

00:08:38.060 --> 00:08:42.880
XSS 또는 과도한 트래픽으로 서버를 마비시키는 DDoS 공격 등이 여기에 해당합니다.

00:08:43.080 --> 00:08:47.140
웹는 이 모든 것을 엣지에서 포착하여 원본 서버에 도달하기 전에 차단합니다.

00:08:47.140 --> 00:08:50.340
자동 보호회에도 사용자 지정 규칙을 생성할 수 있습니다.

00:08:50.560 --> 00:08:55.600
예를 들어, 사이트가 유럽 고객만을 위한 것이라면 다른 지역에서 오는 트래픽을 완전히 차단할 수 있습니다.

00:08:55.800 --> 00:09:00.460
또는 특정 IP 대역에서 계속 사이트를 탐색하는 것이 감지되면 해당 IP 대역을 차단할 수도 있습니다.

00:09:00.680 --> 00:09:04.640
요청 헤더, URL 패턴, 심지어 사용 중인 브라우저를 기반으로 필터링할 수도 있습니다.

00:09:04.860 --> 00:09:08.320
웹를 사용하면 누가 접속할 수 있고 없는지에 대해 매우 구체적인 제어가 가능합니다.

00:09:08.500 --> 00:09:10.140
여기서 가격 계층이 중요해집니다.

00:09:10.360 --> 00:09:14.140
스탠다드는 차단 및 허용 대상을 정의할 수 있는 사용자 지정 웹 규칙을 제공합니다.

00:09:14.140 --> 00:09:19.380
프리미엄은 마이크로소프트 위협 인텔리저스를 기반으로 한 관리형 규칙 세트를 추가하여 한 단계 더 나아갑니다.

00:09:19.520 --> 00:09:24.380
이 규칙들은 마이크로소프트 네트워크 전반에서 확인되는 실제 공격 패턴에 따라 지속적으로 업데이트됩니다.

00:09:24.540 --> 00:09:30.100
또한 프리미엄에는 자동화된 스크래퍼, 크리덴셜 스토핑 공격 및 기타 봇을 자동으로 차단하는 보호 기능이 포함되어 있습니다.

00:09:30.380 --> 00:09:35.860
그리고 프라이빗 링크, 프라이빗 링크, 지원이 추가되어 공용 인터넷 대신 프라이빗 네트워크 연결을 통해 원본 서버에 연결할 수 있습니다.

00:09:35.860 --> 00:09:39.160
즉, 백엔드 서버를 외부 세계로부터 완전히 숨길 수 있습니다.

00:09:39.360 --> 00:09:41.240
프론트 도어만이 서버에 접근할 수 있습니다.

00:09:41.460 --> 00:09:43.280
이는 보안 측면에서 매우 중요한 부분입니다.

00:09:43.460 --> 00:09:45.660
많은 공격이 프론트 도어를 직접 겨냥하지 않습니다.

00:09:45.880 --> 00:09:47.580
공격자들은 뒷문을 찾으려고 합니다.

00:09:47.840 --> 00:09:53.680
원본 서버에 공용 IP 주소가 있으면 공격자가 직접 서버를 탐색하여 프론트 도어의 모든 보호장치를 우회할 수 있습니다.

00:09:53.900 --> 00:09:59.180
프라이빗 링크를 사용하면 원본 서버에 공용 엔드포인트가 없고 프론트 도어를 통해서만 접근할 수 있으므로 그런 일은 불가능합니다.

00:09:59.340 --> 00:10:02.260
따라서 누군가 서버의 IP를 알아내더라도 서버에 접근할 수 없습니다.

00:10:02.260 --> 00:10:04.200
그 결과 심층 방어가 이루어집니다.

00:10:04.380 --> 00:10:06.320
웹은은 애플리케이션 계층 공격을 차단합니다.

00:10:06.520 --> 00:10:08.560
사용자 지정 규칙은 특정 요구사항을 처리합니다.

00:10:08.760 --> 00:10:10.640
보호 기능은 자동화된 위협을 막아줍니다.

00:10:10.840 --> 00:10:13.260
그리고 프라이빗 링크는 원본 서버를 보이지 않게 유지합니다.

00:10:13.460 --> 00:10:19.640
이 모든 과정이 트래픽이 인프라에 도달하기 전 엣지에서 이루어짐으로 서버는 공격을 막아내는 대신 콘텐츠 제공에 집중할 수 있습니다.

00:10:19.860 --> 00:10:22.080
캐싱을 통해 속도를 더욱 향상할 수 있습니다.

00:10:22.360 --> 00:10:27.200
라우팅과 보안은 다루어 두니 프론트 도어를 더욱 유용하게 만드는 또 다른 기능인 캐싱에 대해 알아보겠습니다.

00:10:27.200 --> 00:10:28.540
개념은 간단합니다.

00:10:28.700 --> 00:10:31.260
웹사이트 콘텐츠 중 상당수는 자주 변경되지 않습니다.

00:10:31.460 --> 00:10:36.660
이미지, css 파일, 자바스크립트 라이브러리, 제품 사진, 어쩌면 일부 html 페이지도 포함됩니다.

00:10:36.820 --> 00:10:46.480
모든 방문자가 원본 서버에서 데이터를 가져와야 한다면 서버가 동일한 요청을 반복해서 처리하고 매번 같은 바이트를 인터넷으로 전송해야 함으로 시간과 대역폭이 낭비됩니다.

00:10:46.660 --> 00:10:50.240
캐싱은 정적 콘텐츠의 사본을 에지팝에 보관하여 이 문제를 해결합니다.

00:10:50.460 --> 00:10:55.000
누군가 같은 파일을 다시 요청하면 팝은 원본 서버에 연락할 필요 없이 즉시 해당 파일을 제공합니다.

00:10:55.000 --> 00:10:58.080
마치 모든 통행료 징수소 옆에 작은 창고를 두는 것과 같습니다.

00:10:58.360 --> 00:11:02.600
모든 고객을 본사 공장으로 보내는 대신 선반에 이미 있는 물건을 바로 건네주는 것이죠.

00:11:02.780 --> 00:11:04.080
성능 차이는 극적입니다.

00:11:04.340 --> 00:11:08.200
바다를 건너 왕복할 필요 없이 같은 도시에 있는 서버에서 응답이 옵니다.

00:11:08.400 --> 00:11:10.340
초 단위가 아닌 밀리 초 단위로 말이죠.

00:11:10.540 --> 00:11:15.420
또한 원본 서버는 처리할 요청이 줄어들어 실제로 처리가 필요한 동적 작업에 집중할 수 있게 됩니다.

00:11:15.680 --> 00:11:18.240
그런데 캐싱이 모든 것에 자동으로 적용되는 것은 아닙니다.

00:11:18.440 --> 00:11:21.400
무엇을 캐시할지 얼마나 오래 보관할지는 사용자가 제어합니다.

00:11:21.400 --> 00:11:26.240
프론트 도어는 원본 서버에 맥스 에이지 나에스 맥시지 같은 표준 캐시 제어 헤더를 준수하며

00:11:26.240 --> 00:11:30.500
필요에 따라 원본 헤더를 재정의하여 캐싱 규칙을 직접 구성할 수도 있습니다.

00:11:30.720 --> 00:11:35.920
콘텐츠를 업데이트할 때 캐시를 삭제하면 프론트 도어가 이전 사본을 버리고 새로운 사본을 가져오도록 지시할 수 있습니다.

00:11:36.120 --> 00:11:40.440
이는 신제품 출시나 가격 변경처럼 새 버전이 즉시 반영되어야 하는 경우에 중요합니다.

00:11:40.600 --> 00:11:41.400
핵심은이 겁니다.

00:11:41.740 --> 00:11:44.300
프론트 도어는 정적 콘텐츠만을 위한 것이 아닙니다.

00:11:44.300 --> 00:11:55.400
api, 개인화 페이지, 장바구니와 같은 동적 콘텐츠의 경우에도 요청이 가장 가까운 팝에 도달하면 공용이터넷이 아닌 마이크로소프트 위 전용 백본망을 통해 원본 서버로 전달됨으로 전송 속도가 빨라집니다.

00:11:55.560 --> 00:11:58.740
이 전용 백본망은 개방형 웹보다 더 빠르고 안정적입니다.

00:11:58.960 --> 00:12:01.600
따라서 캐시되지 않은 요청도 속도가 향상됩니다.

00:12:01.840 --> 00:12:05.040
이것이 프론트 도어와 기존 cdn의 주요 차이점 중 하나입니다.

00:12:05.260 --> 00:12:07.800
cdn은 정적 콘텐츠를 캐싱하는 것이 전부입니다.

00:12:08.000 --> 00:12:11.340
프론트 도어는 정적 콘텐츠를 캐싱할 뿐만 아니라 그 외 모든 것도 가속화합니다.

00:12:11.340 --> 00:12:15.160
일석이조인 셈이조, 가격 계층, 어떤 것을 선택해야 할까요?

00:12:15.280 --> 00:12:17.820
좋습니다. 중요한 질문인 비용 이야기를 해보죠.

00:12:17.960 --> 00:12:20.740
비용은 얼마나 들며 실제로 어떤 계층을 선택해야 할까요?

00:12:20.920 --> 00:12:23.560
숫자를 살펴보기 전에 왜 이것이 중요한지 알아보겠습니다.

00:12:23.840 --> 00:12:28.940
선택하는 계층은 가격뿐만 아니라 애플리케이션을 보호하는 데 사용할 수 있는 보안 및 기능도 결정합니다.

00:12:29.140 --> 00:12:31.220
프론트 도어는 세 가지 버전으로 제공됩니다.

00:12:31.420 --> 00:12:32.700
클래식은 이전 버전입니다.

00:12:32.940 --> 00:12:36.380
여전히 작동은 하지만 마이크로소프트는 새 프로젝트에 이를 사용하지 않을 것을 권장합니다.

00:12:36.560 --> 00:12:38.160
클래식은 곧 사라질 예정입니다.

00:12:38.160 --> 00:12:42.660
2025년 이후에는 새로운 리소스를 생성할 수 없으며 2027년에는 완전히 종료됩니다.

00:12:42.800 --> 00:12:46.060
따라서 새로 시작하는 경우 라면 스탠다드 또는 프리미엄을 고려해야 합니다.

00:12:46.260 --> 00:12:47.840
가장 간단하게 정리해드리겠습니다.

00:12:48.200 --> 00:12:50.840
스탠다드 요금제는 기본 비용이 월 35달러입니다.

00:12:51.040 --> 00:12:53.340
프리미엄 요금제는 월 330달러입니다.

00:12:53.620 --> 00:12:55.880
상당한 차이 같지만 흥미로운 점이 있습니다.

00:12:56.200 --> 00:12:59.460
기가바이트 당 데이터 전송 요금은 두 계층 모두 동일합니다.

00:12:59.680 --> 00:13:04.700
북미와 유럽의 경우 아웃파운드 트래픽은 처음 10TB까지 기가바이트 당 약 8.25센트입니다.

00:13:04.700 --> 00:13:07.720
엣지에서 오리진으로의 전송은 기가바이트 당 약 2센트입니다.

00:13:07.880 --> 00:13:08.840
둘 다 가격이 같습니다.

00:13:09.240 --> 00:13:11.780
그렇다면 추가되는 300달러로 무엇을 얻게 될까요?

00:13:11.920 --> 00:13:12.780
바로 기능입니다.

00:13:13.020 --> 00:13:17.200
프리미엄에는 마이크로소프트 위협 인텔리저스를 기반으로 하는 관리형 웹후 규칙이 추가되며

00:13:17.200 --> 00:13:20.100
실제 공격 패턴에 따라 규칙이 자동으로 업데이트됩니다.

00:13:20.260 --> 00:13:24.100
또한 봇 보호 기능, 오리진을 공용 인터넷으로부터 숨길 수 있는 프라이빗 링크 지원,

00:13:24.500 --> 00:13:26.520
더욱 심층적인 보안 분석 기능도 제공됩니다.

00:13:26.520 --> 00:13:31.680
스탠다드는 글로벌 로드 밸런싱, 캐싱, 동적 가속 및 사용자 지정 웹후 규칙을 제공합니다.

00:13:31.860 --> 00:13:34.580
IP 대여, 국가 또는 요청 패턴을 차단할 수 있습니다.

00:13:34.800 --> 00:13:37.740
단지 관리형 규칙 집합이나 프라이빗 링크 기능을 사용할 수 없을 뿐입니다.

00:13:37.920 --> 00:13:39.280
요청에 따른 비용도 다릅니다.

00:13:39.560 --> 00:13:43.080
스탠다드는 처음 2억 5천만 건의 요청까지 1만 건당 약 9센트입니다.

00:13:43.280 --> 00:13:45.300
프리미엄은 1만 건당 약 15센트입니다.

00:13:45.480 --> 00:13:47.120
규모가 커지면 그 차이는 크게 늘어납니다.

00:13:47.300 --> 00:13:48.640
그렇다면 어떻게 선택해야 할까요?

00:13:48.820 --> 00:13:49.980
제 경험칙은 다음과 같습니다.

00:13:50.300 --> 00:13:52.320
일반적인 웹사이트나 API를 운영 중이며,

00:13:52.320 --> 00:13:55.040
글로벌 성능과 기본 보안이 필요하다면 스탠다드로 시작하세요.

00:13:55.240 --> 00:13:56.980
월 35달러의 기본 요금은 합리적이며,

00:13:57.360 --> 00:14:00.160
사용자 지정 웹후 규칙으로 대부분의 일반적인 위협을 처리할 수 있습니다.

00:14:00.360 --> 00:14:03.320
나중에 보안 요구 사항이 커지면 언제든지 업그레이드할 수 있습니다.

00:14:03.540 --> 00:14:06.980
규제가 엄격한 산업, 위료, 금융, 정부 분야에 종사하거나

00:14:06.980 --> 00:14:10.600
민감한 고객 데이터를 다룬다면 프리미엄은 추가 비용을 지불할 가치가 있습니다.

00:14:10.840 --> 00:14:14.060
관리형 웹후 규칙은 미처 생각하지 못한 위협까지 차단해줍니다.

00:14:14.280 --> 00:14:16.300
프라이빗 링크는 오리진을 보이지 않게 유지하고,

00:14:16.300 --> 00:14:19.600
보호 기능은 스탠다드 감악지 못하는 자동화된 공격을 차단합니다.

00:14:19.760 --> 00:14:21.800
마지막으로, 정적 콘텐츠만 제공하며,

00:14:21.920 --> 00:14:25.380
라우팅이나 보안 기능이 필요 없다면 기존 CDN이 더 저렴할 수 있습니다.

00:14:25.620 --> 00:14:28.020
마이크로소프트 위 에이저 CDN은 여전히 존재하며,

00:14:28.400 --> 00:14:30.920
순수 정적 콘텐츠 배포에는 종종 더 비용 효율적입니다.

00:14:31.120 --> 00:14:35.780
하지만 라우팅, 보안, 캐싱, 가속이 모두 필요한 대부분의 실제 애플리케이션에는

00:14:35.780 --> 00:14:38.000
프론트 도어 스탠다드가 최적의 선택입니다.

00:14:38.220 --> 00:14:40.620
모든 내용을 종합하여 실제 사례를 살펴보겠습니다.

00:14:40.620 --> 00:14:43.560
이 모든 요소가 실제로 어떻게 작동하는지 보여드리기 위해

00:14:43.560 --> 00:14:45.120
실제 시나리오를 설명해드리겠습니다.

00:14:45.420 --> 00:14:47.660
여러분이 이커머스 사이트를 운영한다고 가정해봅시다.

00:14:47.820 --> 00:14:50.340
북미, 유럽, 아시아 등 세 지역에 서버를 두고 있습니다.

00:14:50.600 --> 00:14:53.980
고객들은 일본부터 브라질, 남아프리카 공화국까지 전 세계에 퍼져 있습니다.

00:14:54.220 --> 00:14:58.000
프론트 도어가 없다면 도쿄의 고객은 미국의 서버에 직접 연결해야 합니다.

00:14:58.220 --> 00:15:01.760
모든 이미지, 제품 페이지, 결제 요청이 태평양을 건너야 합니다.

00:15:01.960 --> 00:15:03.040
매우 느린 방식 2조.

00:15:03.220 --> 00:15:05.540
미국 서버가 다운되면 고객은 에러 화면만 보게 됩니다.

00:15:05.800 --> 00:15:07.240
이제 프론트 도어를 추가해봅시다.

00:15:07.240 --> 00:15:09.460
도쿄에 있는 고객이 여러분의 사이트에 접속합니다.

00:15:09.460 --> 00:15:12.540
고객의 브라우저는 가장 가까운 에이저 위치, 즉 도쿄에 연결됩니다.

00:15:12.680 --> 00:15:15.440
해당 위치는 서버 3대의 상태를 확인하는데 모두 정상입니다.

00:15:15.660 --> 00:15:16.860
지연 시간을 측정합니다.

00:15:17.100 --> 00:15:21.280
아시아 서버의 응답이 가장 빨라 마이크로소프트 위 전용 백본망을 통해 그쪽으로 요청을 보냅니다.

00:15:21.500 --> 00:15:23.960
3초가 걸리던 페이지 로딩 시간이 1초 이내로 단축됩니다.

00:15:24.160 --> 00:15:27.200
이제 반짝 세일 중에 아시아 서버에 과부하가 걸렸다고 가정해봅시다.

00:15:27.380 --> 00:15:30.360
프론트 도어의 상태 프로브가 지연 시간 증가를 감지합니다.

00:15:30.600 --> 00:15:33.680
차선책인 유럽 서버로 트래픽을 전환하기 시작합니다.

00:15:33.680 --> 00:15:39.960
고객은 아시아 서버만큼은 아니더라도 미국까지 가는 것보다는 훨씬 빠른 서비스를 경험합니다.

00:15:40.160 --> 00:15:43.460
이 모든 장애 조치는 설정 변경 없이 자동으로 이루어집니다.

00:15:43.660 --> 00:15:45.700
그 사이 엣지에서 웹프가 작동합니다.

00:15:45.940 --> 00:15:49.120
결제품을 공격하는 본넷의 SQL 인젝션 시도를 차단합니다.

00:15:49.340 --> 00:15:51.880
알려진 악성 IP 대역의 트래픽을 차단합니다.

00:15:52.120 --> 00:15:55.140
상품 카탈로그를 긁어가는 IP위 요청 속도를 제한합니다.

00:15:55.380 --> 00:15:57.760
이러한 공격은 원본 서버에 전혀 도달하지 못합니다.

00:15:57.940 --> 00:16:00.320
백엔드팀은 공격이 발생했다는 사실조차 모릅니다.

00:16:00.320 --> 00:16:06.040
정적 콘텐츠, 상품 이미지, CSS 파일, 자바스크립트 라이브러리는 도쿄 위치에 캐싱됩니다.

00:16:06.180 --> 00:16:08.680
첫 번째 방문자는 아시아 원본에서 불러옵니다.

00:16:08.840 --> 00:16:11.760
두 번째 방문자는 엣지 캐시에서 즉시 가져옵니다.

00:16:11.980 --> 00:16:17.340
재방문자는 필요한 모든 것이 근처 엣지 위치에 있으므로 거의 즉시 로딩되는 화면을 봅니다.

00:16:17.540 --> 00:16:23.000
빠른 라우팅, 자동 장애 조치, 엣지 보안, 콘텐츠 캐싱이 모두 매끄럽게 연동됩니다.

00:16:23.220 --> 00:16:25.060
고객은 이런 기능이 있는지 조차 모릅니다.

00:16:25.260 --> 00:16:27.360
그저 빠르고 안정적인 사이트라고만 생각할 뿐입니다.

00:16:27.520 --> 00:16:28.740
꼭 기억해야 할 점이 있습니다.

00:16:28.740 --> 00:16:32.560
에이저 프론트 도어는 글로벌 교통경찰처럼 사용자를 가장 빠른 서버로 연결하고

00:16:32.560 --> 00:16:35.360
엣지에서 콘텐츠를 캐싱하며 공격을 사전에 차단합니다.

00:16:35.520 --> 00:16:40.080
삼중 보건역 계층으로 구축되어 있어 특정 리전이 다운되어도 사이트는 계속 유지됩니다.

00:16:40.260 --> 00:16:45.560
대부분의 프로젝트에서 월 35달러인 표준 계층은 성능과 비용 측면에서 최적의 선택입니다.

00:16:45.760 --> 00:16:49.140
고급 보안이나 프라이빗 링크가 필요할 때 프리미엄으로 업그레이드하세요.

00:16:49.360 --> 00:16:51.760
단일 원본으로 작게 시작해서 점차 확장해보세요.

00:16:52.040 --> 00:16:54.000
프론트 도어는 여러분과 함께 성장합니다.

00:16:54.000 --> 00:16:58.000
웹앱 사용자가 여러 지역에 퍼져 있다면 지금 바로 프론트 도어 프로필을 설정하세요.

00:16:58.180 --> 00:17:01.340
단 한 대의 서버만 있어도 글로벌 가속 및 보안 혜택을 누릴 수 있습니다.

00:17:01.580 --> 00:17:06.280
즐겨 사용하는 팟캐스트 플랫폼에서 구독하고 클라우드 여정을 시작하는 분들께의 영상을 공유해주세요.