WEBVTT

00:00:00.000 --> 00:00:01.880
에이저 가상 네트워크란 무엇일까요?

00:00:02.020 --> 00:00:05.280
대부분의 사람들은 이 용어를 들으면 가상 머신을 배포할 때 켜는 설정 중 하나,

00:00:05.660 --> 00:00:08.500
즉 체크박스를 선택하고 잊어버리는 사소한 설정이라고 생각합니다.

00:00:08.680 --> 00:00:09.840
하지만 진실은 다릅니다.

00:00:10.100 --> 00:00:12.440
에이저 가상 네트워크는 단순한 설정이 아닙니다.

00:00:12.620 --> 00:00:14.760
에이저에서 구축하는 모든 것의 기반입니다.

00:00:15.020 --> 00:00:20.060
모든 가상 머신, 모든 데이터베이스, 모든 앱 서비스, 배포하는 모든 함수가 그 안에 위치합니다.

00:00:20.260 --> 00:00:23.120
작동 원리를 모른다면 눈을 감고 비행하는 것과 같습니다.

00:00:23.480 --> 00:00:26.440
이번 에피소드가 끝나면 vnet이 무엇인지, 어떻게 작동하는지,

00:00:26.680 --> 00:00:29.640
그리고 배포하는 모든 리소스가 왜 vnet에 의존하는지 이해하게 될 것입니다.

00:00:29.640 --> 00:00:34.660
vnet 위 정의, ip 주소 작동 방식, 서브넷, 보안, 나우팅, 그리고 vnet을 연결하는 방법을 다룰 예정입니다.

00:00:34.760 --> 00:00:36.700
커피 한 잔 준비하시고 시작해볼까요?

00:00:36.820 --> 00:00:38.020
vnet이란 무엇인가요?

00:00:38.200 --> 00:00:39.740
프라이빗 클라우드 네트워크입니다.

00:00:39.940 --> 00:00:41.860
가장 간단한 정의부터 시작해봅시다.

00:00:42.060 --> 00:00:46.240
에이저 가상 네트워크, 줄여서 vnet은 에이저 내의 전용 사설 네트워크입니다.

00:00:46.440 --> 00:00:48.500
개인 사무실 건물이라고 생각하면 쉽습니다.

00:00:48.700 --> 00:00:50.200
허용된 사람만 들어올 수 있습니다.

00:00:50.500 --> 00:00:54.600
누가 문을 통과할지, 어떤 층에 갈 수 있을지, 누구의 출입을 완전히 차단할지 당신이 결정합니다.

00:00:54.760 --> 00:00:56.960
vnet이 존재하기 전에는 상황이 달랐습니다.

00:00:56.960 --> 00:01:00.780
클라우드에 가상 머신을 배포하면 기본적으로 인터넷에 그대로 노출되었습니다.

00:01:00.980 --> 00:01:02.520
주변에 사설 네트워크가 없었죠.

00:01:02.660 --> 00:01:04.800
ip 주소를 아는 사람이라면 누구든 연결을 시도할 수 있었습니다.

00:01:04.960 --> 00:01:06.300
그건 보안상이 악몽이었습니다.

00:01:06.480 --> 00:01:07.460
무엇이 바뀌었을까요?

00:01:07.700 --> 00:01:10.300
에이저는 격리된 사설 네트워크 공간을 생성할 수 있는 기능을 제공했습니다.

00:01:10.520 --> 00:01:11.740
당신이 경계를 정의합니다.

00:01:12.000 --> 00:01:13.500
무엇을 그 안에 넣을지 결정합니다.

00:01:13.720 --> 00:01:16.400
명시적으로 허용하지 않는 한 경계밖에 그 무엇도 들어올 수 없습니다.

00:01:16.680 --> 00:01:19.500
미리 알아야 할 점은 vnet은 특정 에이저 리전에 위치한다는 것입니다.

00:01:19.740 --> 00:01:20.740
전역적이지 않습니다.

00:01:20.740 --> 00:01:23.400
서유럽 리전에 vnet을 생성하면 해당 리전에만 존재합니다.

00:01:23.540 --> 00:01:25.720
다른 리전에 있는 리소스가 바로 여기에 들어올 수는 없습니다.

00:01:26.000 --> 00:01:28.600
그들은 자체 vnet이 필요하거나 나중에 연결을 설정해야 합니다.

00:01:28.760 --> 00:01:31.440
vnet을 생성할 때 ip 주소 공간을 직접 정의해야 합니다.

00:01:31.640 --> 00:01:33.240
에이저가 대신 선택해주지 않습니다.

00:01:33.460 --> 00:01:35.780
리소스가 사용할 ip 주소 범위를 직접 결정합니다.

00:01:36.000 --> 00:01:39.580
이는 매우 중요한 책임이며 다음 섹션에서 올바르게 설정하는 방법을 다룰 것입니다.

00:01:39.760 --> 00:01:40.600
핵심은이 겁니다.

00:01:40.960 --> 00:01:42.220
vnet은 기반입니다.

00:01:42.480 --> 00:01:47.820
배포하는 모든 가상 머신, 데이터베이스, 에이저 함수가 그 안에 위치합니다.

00:01:47.820 --> 00:01:51.340
vnet이 없다면 리소스에는 사설 네트워크 컨텍스트가 없습니다.

00:01:51.600 --> 00:01:55.020
경계도, 경리도, 보안도 없이 클라우드 위에 둥둥 떠다니는 셈이죠.

00:01:55.220 --> 00:01:57.140
그렇다면 이것이 여러분에게 어떤 의미일까요?

00:01:57.320 --> 00:02:00.060
에이저에서 무언가를 구축한다면 리소스를 배포한 후가 아니라

00:02:00.060 --> 00:02:01.880
시작부터 vnet을 먼저 구성하세요.

00:02:02.040 --> 00:02:03.960
vnet은 여러분이 구축할 땅과 같습니다.

00:02:04.280 --> 00:02:06.260
땅을 사지 않고 집을 짓지는 않겠죠.

00:02:06.480 --> 00:02:07.320
같은 원리입니다.

00:02:07.560 --> 00:02:10.540
ip 주소 지정과 cidr, 주소 공간 선택에 대해 알아보겠습니다.

00:02:10.820 --> 00:02:12.000
그럼 시작해볼까요?

00:02:12.120 --> 00:02:15.380
vnet을 만들 때 가장 중요한 첫 번째 결정은 ip 범위를 정하는 것입니다.

00:02:15.380 --> 00:02:17.540
이를 위해 cidr 표기법을 사용합니다.

00:02:17.540 --> 00:02:20.300
cidr은 클래슬리스 인터 도메인 라우팅 위 약자이지만

00:02:20.300 --> 00:02:23.560
실제 의미는 이만큼의 ip 주소가 필요하다고 말하는 것과 같습니다.

00:02:23.840 --> 00:02:24.900
이게 왜 중요할까요?

00:02:25.140 --> 00:02:29.460
선택한 범위에 따라 가상 네트워크에 담을 수 있는 리소스의 양이 결정되기 때문입니다.

00:02:29.660 --> 00:02:30.920
작동 방식은 이렇습니다.

00:02:31.180 --> 00:02:34.420
cidr은 16이나 24와 같은 슬래시와 숫자를 사용합니다.

00:02:34.620 --> 00:02:36.740
그 숫자가 주소 공간의 크기를 나타내죠.

00:02:36.960 --> 00:02:39.720
16은 약 6만 5천 개의 ip 주소를 제공합니다.

00:02:40.000 --> 00:02:41.140
상당히 많은 양이 있죠.

00:02:41.140 --> 00:02:46.340
24는 약 250개를 제공하며 소규모 팀이나 단일 애플리케이션 계층에 적합합니다.

00:02:46.340 --> 00:02:50.900
따라서 v-net을 설계할 때는 리소스 수와 그룹화 방법을 고려해야 합니다.

00:02:51.100 --> 00:02:53.500
이제 아무 ip 범위나 선택할 수는 없습니다.

00:02:53.880 --> 00:02:58.940
에이저는 내부 네트워크를 위한 사설 ip 범위를 지정하는 rfc 1918 표준을 따릅니다.

00:02:59.180 --> 00:03:00.320
세 가지 옵션이 있습니다.

00:03:00.660 --> 00:03:04.280
10x, x, x 범위는 가장 크며 확장할 여유가 충분합니다.

00:03:04.440 --> 00:03:08.060
172.16x, x 범위는 약간 작지만 여전히 유용합니다.

00:03:08.060 --> 00:03:12.620
그리고 192.168x, x 범위는 아마집 공유기에서 사용 중일 겁니다.

00:03:12.820 --> 00:03:13.880
중요한 점이 있습니다.

00:03:14.120 --> 00:03:17.640
v-net 위 주소 공간은 연결하려는 다른 네트워크와 겹치면 안 됩니다.

00:03:17.880 --> 00:03:19.140
이는 흔히 하는 실수입니다.

00:03:19.400 --> 00:03:23.800
많은 사람이 익숙한 범위를 선택했다가 나중에 회사 네트워크와 충돌한다는 사실을 알게 됩니다.

00:03:24.000 --> 00:03:29.580
회사 사무실 네트워크가 20.0.0.0-16을 사용한다면 에이저에서도 같은 범위를 사용하지 마세요.

00:03:29.780 --> 00:03:33.240
나중에 연결하려 하면 충돌이 발생해 트래픽이 길을 잃게 됩니다.

00:03:33.240 --> 00:03:35.040
구체적인 예를 들어보겠습니다.

00:03:35.380 --> 00:03:38.960
에이저와온 프레미스 데이터센터를 연결하는 하이브리드 구성을 구축하는데

00:03:38.960 --> 00:03:43.780
데이터센터가 20.0.0.0-16을 사용한다고 가정해봅시다.

00:03:43.960 --> 00:03:48.320
같은 범위로 v-net을 만들면 두 네트워크가 동일한 IP를 놓고 다투게 됩니다.

00:03:48.600 --> 00:03:49.340
생각해보세요.

00:03:49.640 --> 00:03:52.800
같은 IP 범위를 사용하는 두 네트워크는 제대로 통신할 수 없습니다.

00:03:53.100 --> 00:03:54.460
주소가 같은 두 집과 같습니다.

00:03:54.840 --> 00:03:56.100
우편물이 헷갈리게 되죠.

00:03:56.320 --> 00:03:58.260
나중에 해결하고 싶지 않은 골치 아픈 문제입니다.

00:03:58.440 --> 00:04:00.340
그러니 미리 계획하고 고유한 범위를 선택하세요.

00:04:00.540 --> 00:04:01.920
마지막으로 계획 팁을 하나 드립니다.

00:04:01.920 --> 00:04:03.860
생각보다 더 큰 범위를 선택하세요.

00:04:04.040 --> 00:04:06.000
지금은 24면 충분하다고 생각할지 모르지만

00:04:06.000 --> 00:04:08.580
애플리케이션이 성장하면 16이 필요해질 것입니다.

00:04:08.760 --> 00:04:10.420
나중에 변경하기는 쉽지 않습니다.

00:04:10.620 --> 00:04:14.580
v-net을 만들고 리소스를 배포한 후에는 주소공간을 변경하기가 매우 번거롭습니다.

00:04:14.800 --> 00:04:17.400
가능은 하지만 운영 중인 시스템에서 하고 싶은 작업은 아닐 겁니다.

00:04:17.620 --> 00:04:19.340
그러니 성장할 여유공간을 충분히 확보하세요.

00:04:19.540 --> 00:04:20.840
이게 여러분에게 어떤 의미일까요?

00:04:21.000 --> 00:04:22.860
v-net 위 주소공간을 땅을 사는 것에 비유해보세요.

00:04:23.080 --> 00:04:24.540
미래의 성장을 위해 충분히 확보하세요.

00:04:24.760 --> 00:04:26.740
작은 땅이 필요하다고 생각되면 중간 크기를 구입하세요.

00:04:26.940 --> 00:04:28.440
나중에 스스로에게 고마워하게 될 겁니다.

00:04:28.440 --> 00:04:29.820
그게 핵심 포인트입니다.

00:04:30.000 --> 00:04:32.400
미래의 성장을 고려하여 주소공간을 계획하세요.

00:04:32.660 --> 00:04:34.340
서브넷, 네트워크 분할하기.

00:04:34.580 --> 00:04:36.760
이제 v-net을 만들고 주소공간을 선택했습니다.

00:04:37.040 --> 00:04:37.980
그 다음은 무엇일까요?

00:04:38.180 --> 00:04:40.060
모든 것을 하나의 큰 풀에 그냥 쏟아붓지는 마세요.

00:04:40.220 --> 00:04:41.440
거기에 서브넷이 필요합니다.

00:04:41.680 --> 00:04:43.960
서브넷은 v-net 위 기본 구성 요소 중 하나입니다.

00:04:44.220 --> 00:04:46.680
서브넷을 통해 리소스를 구성하고 보호할 수 있습니다.

00:04:46.980 --> 00:04:49.740
서브넷은 v-net 주소공간의 더 작은 섹션입니다.

00:04:50.000 --> 00:04:52.820
v-net 이 건물이라면 서브넷은 각각의 방입니다.

00:04:52.820 --> 00:04:57.160
서버실, 접수처, 휴게실을 모두 같은 열린 공간에 두지는 않겠죠.

00:04:57.360 --> 00:04:58.640
여기서도 같은 원리입니다.

00:04:58.840 --> 00:05:01.980
간단한 개념이지만 네트워크 관리 방식에 엄청난 차이를 만듭니다.

00:05:02.160 --> 00:05:04.020
리소스마다 다른 서브넷에 배치하세요.

00:05:04.240 --> 00:05:06.600
웹서버는 한 서브넷에, 데이터베이스는 다른 서브넷에,

00:05:06.840 --> 00:05:08.700
애플리케이션 로직은 세 번째 서브넷에 두는 식이죠.

00:05:08.860 --> 00:05:09.500
왜 그럴까요?

00:05:09.680 --> 00:05:10.800
두 가지 이유 때문입니다.

00:05:11.000 --> 00:05:11.980
보안과 구성이죠.

00:05:12.200 --> 00:05:13.520
보안부터 이야기해보죠.

00:05:13.700 --> 00:05:15.160
보통 가장 중요하니까요.

00:05:15.300 --> 00:05:16.200
보안이 우선입니다.

00:05:16.460 --> 00:05:17.700
누군가 웹서버를 해킹했을 때,

00:05:18.060 --> 00:05:20.160
그 사람이 데이터베이스에 직접 접근하게 해서는 안 됩니다.

00:05:22.820 --> 00:05:26.300
공격자는 그 경계를 넘어야 하며, 여러분은 무엇이 통과할지 정확히 제어할 수 있습니다.

00:05:26.500 --> 00:05:29.560
네트워크 보안 그룹을 사용하여 서브넷 간 트래픽을 제어할 수도 있습니다.

00:05:29.840 --> 00:05:31.340
그건 다른 영상에서 다룰 주제지만,

00:05:31.800 --> 00:05:34.500
서브넷이 그런 보안의 기초라는 점을 알아두는 것이 좋습니다.

00:05:34.700 --> 00:05:35.700
다음은 구성입니다.

00:05:36.000 --> 00:05:38.680
모든 것이 제자리에 있으면 관리하기가 더 쉽습니다.

00:05:38.680 --> 00:05:40.800
어떤 서브넷에 프런트엔드 리소스가 있고,

00:05:41.020 --> 00:05:43.300
어느 서브넷에 백엔드 데이터가 있는지 알 수 있습니다.

00:05:43.520 --> 00:05:45.500
각 리소스를 개별적으로 구성하는 대신,

00:05:45.620 --> 00:05:48.500
전체 서브넷의 정책과 규칙을 한 번에 적용할 수 있습니다.

00:05:48.740 --> 00:05:50.680
시간을 절약하고 오류를 줄일 수 있죠.

00:05:50.880 --> 00:05:53.620
자, 여기서 사람들이 당황하기 쉬운 세부사항을 알려드리겠습니다.

00:05:53.920 --> 00:05:58.380
에이저는 각 서브넷에서 라우팅 및 DNS와 같은 내부 용도로 5개의 IP 주소를 예약합니다.

00:05:58.600 --> 00:06:01.580
따라서 24 범위로 256개의 주소를 가진 서브넷을 만들면,

00:06:02.020 --> 00:06:04.200
실제로 사용할 수 있는 주소는 251개뿐입니다.

00:06:04.200 --> 00:06:05.460
흔히 겪는 함정입니다.

00:06:05.720 --> 00:06:08.140
256개를 계획해도 실제로는 251개만 얻게 됩니다.

00:06:08.360 --> 00:06:10.680
그러니 서브넷 크기를 정할 때는 항상 여유를 조금 두세요.

00:06:10.880 --> 00:06:13.720
다행인 점은 VNet 생성 후에도 서브넷을 추가할 수 있다는 것입니다.

00:06:13.920 --> 00:06:16.300
생성 시점에 설정한 것에 얽매일 필요는 없습니다.

00:06:16.300 --> 00:06:21.060
관리 도구나 모니터링 시스템용 서브넷이 따로 필요하다는 것을 나중에 깨달아도 괜찮습니다.

00:06:21.240 --> 00:06:21.920
문제 없습니다.

00:06:22.300 --> 00:06:24.380
하지만 미리 계획하는 것이 여전히 좋습니다.

00:06:24.600 --> 00:06:28.460
나중에 서브넷을 추가할 수는 있지만, 리소스를 옮겨야 할 수도 있어 작업에 방해가 될 수 있습니다.

00:06:28.660 --> 00:06:30.300
하지만 가장 좋은 방법은 따로 있습니다.

00:06:30.580 --> 00:06:33.300
처음부터 애플리케이션의 각계층에 맞춰 서브넷을 분리하세요.

00:06:33.500 --> 00:06:35.360
애플리케이션 아키텍처를 고려해보세요.

00:06:35.620 --> 00:06:42.120
보통 사용자 요청을 처리하는 프런트엔드, 비즈니스 로직을 수행하는 백엔드, 데이터를 저장하는 데이터 계층이 있습니다.

00:06:42.440 --> 00:06:44.400
이들 각각은 별도의 서브넷을 가져야 합니다.

00:06:44.400 --> 00:06:47.480
운영 환경에서 서브넷을 분리해야겠다고 깨닫기까지 기다리지 마세요.

00:06:47.640 --> 00:06:49.820
리소스가 이미 배포된 상태에서는 훨씬 더 어렵습니다.

00:06:50.000 --> 00:06:51.420
이것이 여러분에게 어떤 의미일까요?

00:06:51.620 --> 00:06:54.040
서브넷은 네트워크를 조직화하고 안전하게 유지하는 방법입니다.

00:06:54.240 --> 00:06:55.300
마치 건물의 방과 같습니다.

00:06:55.660 --> 00:06:58.280
일찍 계획을 세우고 애플리케이션의 각계층에 전용 공간을 부여하세요.

00:06:58.460 --> 00:07:00.600
그것이 네트워크를 깔끔하고 안전하게 관리하는 방법입니다.

00:07:00.760 --> 00:07:02.600
공용 IP와 사설 IP에 대해 알아봅시다.

00:07:02.800 --> 00:07:03.600
무엇이 보일까요?

00:07:03.800 --> 00:07:05.360
IP 주소에 대해 이야기해봅시다.

00:07:05.560 --> 00:07:07.720
모든 IP 주소가 동일한 것은 아니기 때문입니다.

00:07:07.720 --> 00:07:11.540
VNET에 리소스를 배포하면 기본적으로 사설 IP 주소가 할당됩니다.

00:07:11.720 --> 00:07:14.860
이는 VNET의 다른 리소스와 통신할 때 사용하는 주소입니다.

00:07:15.100 --> 00:07:17.020
내선 전화번호와 같다고 생각하면 됩니다.

00:07:17.320 --> 00:07:19.220
건물 내부 사람들만 연결할 수 있죠.

00:07:19.480 --> 00:07:23.060
사설 IP는 VNET 내부 나 연결된 네트워크에서만 접근할 수 있습니다.

00:07:23.340 --> 00:07:26.580
집에서 노트북을 사용할 때는 에이저 위 사설 IP에 연결할 수 없습니다.

00:07:26.880 --> 00:07:28.340
인터넷상에 있는 게 아니니까요.

00:07:28.520 --> 00:07:30.080
여러분의 사설 네트워크 안에 있는 것입니다.

00:07:30.280 --> 00:07:32.840
그렇다면 리소스를 인터넷에서 접근 가능하게 만들려면 어떻게 해야 할까요?

00:07:32.980 --> 00:07:34.480
공용 IP 주소를 부여하면 됩니다.

00:07:34.480 --> 00:07:38.720
외부 세계에 공개되는 주소로 내선 번호가 아닌 공개된 전화번호를 갖는 것과 같습니다.

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

00:07:40.540 --> 00:07:42.100
공용 IP는 선택사항입니다.

00:07:42.340 --> 00:07:46.540
에이저는 요청하지 않는 한 리소스에 공용 IP를 부여하지 않으므로 명시적으로 할당해야 합니다.

00:07:46.700 --> 00:07:47.860
이는 위도된 설계입니다.

00:07:48.060 --> 00:07:50.660
기본은 사설이어야 하며 공용은 신중한 선택이어야 합니다.

00:07:50.860 --> 00:07:52.500
많은 초보자가 여기서 실수를 합니다.

00:07:52.740 --> 00:07:54.640
모든 것에 공용 IP를 부여하는 것이죠.

00:07:54.820 --> 00:07:57.720
웹서버, 데이터베이스, 백엔드 API 모두의 말입니다.

00:07:57.920 --> 00:07:58.960
그건 보안 위험입니다.

00:07:59.300 --> 00:08:02.760
데이터베이스나 백엔드 API는 인터넷에서 접근할 필요가 없습니다.

00:08:02.760 --> 00:08:07.180
사용자가 실제로 상호작용하는 프런트엔드 리소스에만 공용 IP를 할당해야 합니다.

00:08:07.340 --> 00:08:10.680
공용 IP는 정적, 스태틱과 동적, 다이나믹 위 두 가지 유형이 있습니다.

00:08:10.900 --> 00:08:14.220
정적 공용 IP는 리소스를 중지했다가 다시 시작해도 동일하게 유지됩니다.

00:08:14.400 --> 00:08:16.260
동적 공용 IP는 변경될 수 있습니다.

00:08:16.480 --> 00:08:20.740
운영 애플리케이션을 실행 중에 라면 사용자가 언제나 접속할 수 있도록 정적 IP가 필요할 것입니다.

00:08:20.960 --> 00:08:23.600
무언가를 테스트 중에 라면 동적 IP도 괜찮습니다.

00:08:23.820 --> 00:08:28.260
주소블록을 예약할 수 있는 공용 IP의 접두사, 프리픽스라는 기능도 사용할 수 있습니다.

00:08:28.260 --> 00:08:33.580
한 번에 하나씩 만드는 대신 범위를 예약하고 해당 범위에서 개별 주소를 할당합니다.

00:08:33.800 --> 00:08:37.220
프로젝트에 여러 공용 IP가 필요하다는 것을 알 때 유용합니다.

00:08:37.440 --> 00:08:39.080
이것이 여러분에게 어떤 의미일까요?

00:08:39.280 --> 00:08:41.000
사설 IP가 안전한 기본값입니다.

00:08:41.200 --> 00:08:42.540
내부전화 내선 번호와 같습니다.

00:08:42.920 --> 00:08:46.760
공용 IP는 외부에서 접근해야 하는 리소스에만 선택적으로 사용합니다.

00:08:46.960 --> 00:08:51.460
필요할 때는 정적인지 동적인지, 접두사가 적절한지 고려해야 합니다.

00:08:51.700 --> 00:08:57.220
트래픽을 제어하는 네트워크 보안 그룹, VNET, 서브넷, IP 주소 설정을 모두 완료했습니다.

00:08:57.220 --> 00:09:00.300
하지만 들어오고 나가는 트래픽을 어떻게 제어할까요?

00:09:00.460 --> 00:09:03.100
이때 네트워크 보안 그룹, NSG이 필요합니다.

00:09:03.260 --> 00:09:07.200
NSG는 리소스에 출입하는 트래픽을 제어하는 게이트 키퍼 역할을 합니다.

00:09:07.400 --> 00:09:12.900
클럽 입구의 경호원이 신분증을 확인하고 명단을 대조하여 출입을 통제하는 것과 같습니다.

00:09:13.320 --> 00:09:17.320
리소스에 도달하려는 모든 트래픽은 먼저의 경호원을 거쳐야 합니다.

00:09:17.620 --> 00:09:19.620
NSG는 규칙에 따라 작동합니다.

00:09:19.620 --> 00:09:27.180
각 규칙은 원본 IP 주소, 대상 IP 주소, 포트 번호, 프로토콜이라는 4가지 요소를 기반으로 허용 또는 거부를 결정합니다.

00:09:27.360 --> 00:09:34.180
예를 들어 사무실 IP에서 443포트로 들어오는 트래픽은 허용하거나 인터넷에서 22포트로 들어오는 모든 트래픽은 차단할 수 있습니다.

00:09:34.400 --> 00:09:35.900
이러한 수준의 제어가 가능합니다.

00:09:36.120 --> 00:09:37.740
이제 강력한 기능을 하나 소개합니다.

00:09:37.980 --> 00:09:41.900
NSG를 서브넷에 연결하거나 특정 VM의 네트워크 인터페이스에 직접 연결할 수 있습니다.

00:09:42.160 --> 00:09:45.240
서브넷에 연결하면 해당 NSG가 내부의 모든 리소스에 적용됩니다.

00:09:45.240 --> 00:09:48.020
모든 VM, 모든 데이터베이스, 모든 리소스의 말이죠.

00:09:48.140 --> 00:09:49.240
포괄적인 정책입니다.

00:09:49.460 --> 00:09:53.220
특정 VM의 네트워크 인터페이스에 연결하면 해당 머신에만 적용됩니다.

00:09:53.420 --> 00:09:55.040
두 가지 모두 수행할 수도 있습니다.

00:09:55.300 --> 00:10:00.000
광범위한 규칙을 위한 서브넷 수준 NSG와 예외를 위한 NIC 수준 NSG를 조합하는 것입니다.

00:10:00.200 --> 00:10:02.760
에이저가 생성하는 기본 규칙은 매우 합리적입니다.

00:10:03.000 --> 00:10:06.060
VNET 내의 모든 트래픽은 허용되어 리소스끼리 통신할 수 있지만,

00:10:06.620 --> 00:10:11.780
인터넷에서 들어오는 모든 트래픽은 차단됨으로 명시적으로 허용하지 않는 한 외부에서 리소스에 접근할 수 없습니다.

00:10:11.780 --> 00:10:13.140
좋은 출발점이 있죠.

00:10:13.320 --> 00:10:14.800
일반적인 예시를 하나 들어보겠습니다.

00:10:15.140 --> 00:10:18.280
리눅스 가상 머신을 관리하는데 SSH로 접속해야 한다고 가정해보죠.

00:10:18.420 --> 00:10:21.000
포트 22번으로 들어오는 인바운드 트래픽을 허용하는 NSG 규칙을 만들겠지만,

00:10:21.360 --> 00:10:23.340
아무 곳에서나 SSH의 접속을 허용하고 싶지는 않을 겁니다.

00:10:23.520 --> 00:10:25.100
그건 위험을 자초하는 일이니까요.

00:10:25.240 --> 00:10:28.620
따라서 자신의 IP 주소로 제한하여 본인만 SSH로 접속할 수 있게 하고,

00:10:28.800 --> 00:10:29.700
나머지는 모두 차단합니다.

00:10:29.900 --> 00:10:33.240
윈도우 머신의 경우, 포트 3389번을 사용하는 RDP도 같은 방식입니다.

00:10:33.420 --> 00:10:34.900
이게 여러분에게 어떤 의미일까요?

00:10:35.120 --> 00:10:38.360
NSG는 여러분의 첫 번째 방어선이며, 가장 좋은 점은 무료라는 것입니다.

00:10:38.360 --> 00:10:40.980
추가 비용이 들지 않으니 설정하지 않을 이유가 없습니다.

00:10:41.260 --> 00:10:44.220
모든 서브넷과 모든 리소스에는 NSG가 연결되어 있어야 합니다.

00:10:44.400 --> 00:10:46.920
모두 거부로 시작해서 필요한 것만 여는 방식을 사용하세요.

00:10:47.100 --> 00:10:49.660
경로 테이블과 라우팅, 트래픽 제어에 대해 알아봅시다.

00:10:49.820 --> 00:10:51.420
이제 라우팅에 대해 이야기해봅시다.

00:10:51.600 --> 00:10:52.880
어떤 트래픽을 허용할지 결정했다면,

00:10:53.200 --> 00:10:55.080
그 트래픽이 실제로 어디로 갈지 결정해야 하니까요.

00:10:55.220 --> 00:10:58.420
중요한 점은 에이저가 모든 서브넷에 대해 시스템 경로를 자동으로 생성한다는 것입니다.

00:10:58.640 --> 00:11:00.160
여러분은 아무것도 할 필요가 없습니다.

00:11:00.460 --> 00:11:03.100
기본적인 도로를 알고 있는 기본 내비게이션이라고 생각하세요.

00:11:03.100 --> 00:11:07.220
VNET 내부 트래픽, 피어링된 VNET로의 트래픽, 인터넷으로의 트래픽 모두 해당됩니다.

00:11:07.400 --> 00:11:11.580
별도의 설정 없이도 잘 작동하지만, 때로는 기본 내비게이션이 원하는 목적지로 안내하지 못할 때가 있습니다.

00:11:11.820 --> 00:11:14.480
그럴 때 필요한 것이 바로 사용자 정의 경로, 즉 UDR입니다.

00:11:14.680 --> 00:11:18.020
이를 통해 에이저 위 시스템 경로를 제정해하고 트래픽 경로를 직접 제어할 수 있습니다.

00:11:18.260 --> 00:11:19.240
어떻게 작동할까요?

00:11:19.420 --> 00:11:20.580
경로 테이블을 생성합니다.

00:11:20.820 --> 00:11:22.100
사용자 지정 경로를 추가합니다.

00:11:22.340 --> 00:11:24.360
그런 다음 해당 경로 테이블을 서브넷과 연결합니다.

00:11:24.360 --> 00:11:27.940
그 시점부터 해당 서브넷을 나가는 트래픽은 기본값 대신 여러분의 규칙을 따르게 됩니다.

00:11:28.100 --> 00:11:29.440
구체적인 예시를 들어보겠습니다.

00:11:29.760 --> 00:11:33.300
VNET에서 발생하는 모든 인터넷 트래픽이 먼저 방화벽을 거치게 하고 싶다고 가정해보죠.

00:11:33.420 --> 00:11:36.620
트래픽을 검사하거나 기록하고, 악성 사이트를 차단해야 할 수도 있으니까요.

00:11:36.760 --> 00:11:39.660
기본 시스템 경로는 인터넷 트래픽을 외부로 직접 내보냅니다.

00:11:39.840 --> 00:11:47.600
원하는 방식이 아니라면 0.0.0.0으로 향하는 모든 트래픽, 즉 인터넷상이 어디든 향하는 트래픽은 방화벽으로 보내 도로 경로를 만듭니다.

00:11:47.780 --> 00:11:49.500
그것이 바로 사용자 정의 경로입니다.

00:11:49.720 --> 00:11:52.240
경로 테이블은 다음홉, 넥스트홉 이라는 개념을 사용합니다.

00:11:52.420 --> 00:11:54.460
트래픽이 다음에 전송될 목적지를 의미하죠.

00:11:54.640 --> 00:11:55.660
몇 가지 옵션이 있습니다.

00:11:55.660 --> 00:11:58.400
방화벽과 같은 가상 어플라이언스로 보낼 수 있습니다.

00:11:58.580 --> 00:12:02.840
온프레미스 네트워크에 연결하는 방식인 가상 네트워크 게이트웨이로 보낼 수도 있습니다.

00:12:03.080 --> 00:12:07.720
인터넷으로 직접 보내거나 아무 곳으로도 보내지 않아 트래픽을 차단할 수 있습니다.

00:12:08.000 --> 00:12:13.160
핵심은 나우팅이 네트워크를 통과하는 트래픽의 경로를 제어하는 방식이라는 점을 이해하는 것입니다.

00:12:13.400 --> 00:12:17.220
시스템 경로는 좋은 기본값이지만 모든 상황에 항상 적합한 것은 아닙니다.

00:12:17.220 --> 00:12:23.040
트래픽이 검사 지점을 거치거나 특정 게이트웨이로 전달되어야 할 때 또는 완전히 차단해야 할 때 사용자 정의 경로가 필요합니다.

00:12:23.180 --> 00:12:24.900
이것이 여러분에게 어떤 의미일까요?

00:12:25.100 --> 00:12:30.280
나우팅은 트래픽이 이동할 곳을 지시하는 방법이며 필요할 때마다 에이저 위 기본값을 제정해 할 수 있는 권한이 있습니다.

00:12:30.500 --> 00:12:35.800
시스템 경로로 시작하여 그 기능을 이해하고 아키텍처상 필요할 때 사용자 지정 경로를 추가하세요.

00:12:35.980 --> 00:12:38.160
V-NET 피어링, 네트워크 연결하기.

00:12:38.400 --> 00:12:41.880
지금까지는 하나의 V-NET, 즉 하나의 건물과 하나의 사설 네트워크에 대해 이야기했습니다.

00:12:42.160 --> 00:12:44.400
그렇다면 여러 개의 V-NET이 있다면 어떻게 될까요?

00:12:44.400 --> 00:12:49.440
운영 환경과 테스트 환경을 따로 두거나 서로 다른 에이저 지역에서 애플리케이션을 운영할 수 있습니다.

00:12:49.620 --> 00:12:52.000
기본적으로 이러한 V-NET들은 완전히 격리되어 있습니다.

00:12:52.300 --> 00:12:53.300
서로 통신할 수 없습니다.

00:12:53.640 --> 00:12:55.540
마치 연결된 도로가 없는 서로 다른 건물과 같습니다.

00:12:55.840 --> 00:12:57.420
바로 이때 V-NET 피어링이 필요합니다.

00:12:57.600 --> 00:13:00.460
이를 통해 두 V-NET을 비공개로 연결할 수 있는데 정말 말 그대로 비공개입니다.

00:13:00.620 --> 00:13:03.680
피어링된 V-NET 간의 트래픽은 마이크로소프트 백본 네트워크 내에서만 이동합니다.

00:13:03.860 --> 00:13:05.480
공용 인터넷을 전혀 거치지 않습니다.

00:13:05.700 --> 00:13:08.900
즉 낮은 지연 시간과 높은 대역폭을 유지하며 외부 위협에 노출되지 않습니다.

00:13:08.900 --> 00:13:10.740
사람들이 놀라워하는 점이 하나 있습니다.

00:13:11.040 --> 00:13:12.740
피어링은 지역 간에도 작동합니다.

00:13:12.960 --> 00:13:14.420
이를 글로벌 피어링이라고 합니다.

00:13:14.640 --> 00:13:17.400
서유럽의 V-NET과 동남아시아의 V-NET을 피어링할 수 있으며

00:13:17.400 --> 00:13:20.200
이들 사이의 트래픽은 마이크로소프트 위 사설 네트워크를 통해 유지됩니다.

00:13:20.360 --> 00:13:23.480
VPN 게이트웨이나 공용 IP 없이 직접적인 사설 연결이 가능합니다.

00:13:23.660 --> 00:13:25.660
하지만 절대 어겨서는 안 되는 규칙이 있습니다.

00:13:25.940 --> 00:13:28.920
피어링되는 V-NET은 서로 중복되지 않는 주소 공간을 가져야 합니다.

00:13:29.140 --> 00:13:34.020
두 V-NET 이 모두 1.0.0.0.0-16 범위를 사용하려고 하면 피어링할 수 없습니다.

00:13:34.020 --> 00:13:38.320
IP 주소가 충돌하여 에이저 가패킷이 속한 네트워크를 알 수 없게 됩니다.

00:13:38.560 --> 00:13:42.240
그러니 앞서 언급한 주소 공간을 신중하게 선택하라는 계획팁을 기억하시나요?

00:13:42.500 --> 00:13:43.720
이것이 바로 그 이유입니다.

00:13:43.940 --> 00:13:47.560
나중에 V-NET을 피어링할 가능성이 있다면 처음부터 범위가 중복되지 않도록 하세요.

00:13:47.740 --> 00:13:49.400
이제 사람들이 자주 혼동하는 세부사항이 하나 있습니다.

00:13:49.620 --> 00:13:51.140
피어링은 비전이적, 넌트랜서티브입니다.

00:13:51.320 --> 00:13:52.080
그게 무슨 뜻일까요?

00:13:52.280 --> 00:13:53.920
V-NET A 가 V-NET B 와 피어링되고

00:13:53.920 --> 00:13:56.320
V-NET B 가 V-NET C 와 피어링되어 있다고 가정해봅시다.

00:13:56.460 --> 00:13:58.820
V-NET A는 B를 통해 자동으로 V-NET C에 도달하지 못합니다.

00:13:58.820 --> 00:14:00.460
서로 연결되어 있지 않기 때문입니다.

00:14:00.640 --> 00:14:02.980
각 피어링은 정확히 두 V-NET 사이에 직접적인 링크입니다.

00:14:03.140 --> 00:14:05.580
A 가 C와 통신하려면 A와 C 사이에 별도의 피어링이 필요합니다.

00:14:05.740 --> 00:14:07.580
그럼 대규모로 처리하려면 어떻게 해야 할까요?

00:14:07.740 --> 00:14:09.980
허브 앤 스포크, 허브 앤드 스포크, 아키텍처를 사용하면 됩니다.

00:14:10.200 --> 00:14:13.000
하나의 중앙 V-NET인 허브는 여러 다른 V-NET인 스포크와 피어링됩니다.

00:14:13.180 --> 00:14:17.100
허브에는 방화벽, VPN 게이트웨이, 모니터링 도구와 같은 공유 서비스가 포함될 수 있습니다.

00:14:17.320 --> 00:14:19.300
스포크에는 개별 워크로드가 포함됩니다.

00:14:19.300 --> 00:14:22.780
각 스포크는 허브와 직접 피어링되지만, 스포크끼리는 피어링되지 않습니다.

00:14:22.920 --> 00:14:26.040
한 스포크가 다른 스포크에 연결해야 하는 경우, 트래픽은 허브를 거쳐야 합니다.

00:14:26.200 --> 00:14:29.540
이를 통해 체계적으로 관리하고 보안 정책을 적용할 중앙 지점을 확보할 수 있습니다.

00:14:29.780 --> 00:14:31.340
이것이 여러분에게 어떤 의미일까요?

00:14:31.520 --> 00:14:34.640
피어링은 여러 V-NET과 지역에 걸친 네트워크를 구축하는 방법입니다.

00:14:34.800 --> 00:14:36.220
건물 사이를 잇는 다리와 같습니다.

00:14:36.600 --> 00:14:38.540
주소 공간이 격치지 않도록 계획하세요.

00:14:38.760 --> 00:14:40.540
피어링은 전이되지 않는다는 점을 기억하고,

00:14:40.900 --> 00:14:43.820
단일 V-NET을 넘어 확장할 때는 허브 앤 스포크 설계를 고려하세요.

00:14:43.820 --> 00:14:46.100
전체적인 연결 방식, 큰 그림을 보겠습니다.

00:14:46.360 --> 00:14:48.720
이제 한 발 물러서서 이러한 요소들이 어떻게 조화를 이루는지 살펴보겠습니다.

00:14:48.980 --> 00:14:50.260
그 지점에 진정한 강력함이 있습니다.

00:14:50.500 --> 00:14:51.720
먼저 V-NET으로 시작합니다.

00:14:51.900 --> 00:14:53.280
에이전 A 여러분만의 개인 공간입니다.

00:14:53.460 --> 00:14:54.620
여러분의 땅이라고 생각하세요.

00:14:54.820 --> 00:14:56.240
그 땅 안에서 서브넷을 만듭니다.

00:14:56.460 --> 00:14:57.620
그것들은 여러분의 방입니다.

00:14:57.840 --> 00:15:00.700
웹서버용, 데이터베이스용, 관리도구용으로 각각 나눕니다.

00:15:00.840 --> 00:15:04.180
각 서브넷은 V-NET 위 주소 공간에서 할당된 고요한 주소 블록을 갖습니다.

00:15:04.420 --> 00:15:05.760
그런 다음 보안을 추가합니다.

00:15:06.020 --> 00:15:08.040
네트워크 보안 그룹을 서브넷에 연결합니다.

00:15:08.040 --> 00:15:10.560
이 그룹은 들어오고 나가는 트래픽을 제어합니다.

00:15:10.780 --> 00:15:14.120
웹서브넷은 인터넷에서 443포트로 들어오는 트래픽을 허용합니다.

00:15:14.300 --> 00:15:18.060
데이터베이스 서브넷은 웹서브넷에서 1433포트로 들어오는 트래픽만 허용합니다.

00:15:18.220 --> 00:15:20.680
각 문 앞에 경비원이 누가 허용되는지 정확히 알고 있습니다.

00:15:20.960 --> 00:15:22.400
다음으로 라우팅을 설정합니다.

00:15:22.640 --> 00:15:26.060
모든 아웃바운드 인터넷 트래픽을 검사를 위해 방화벽으로 보내고 싶을 수 있습니다.

00:15:26.300 --> 00:15:29.600
경로 테이블을 만들고 사용자 지정 경로를 추가한 뒤 서브넷에 연결합니다.

00:15:29.820 --> 00:15:32.920
이제 트래픽은 네이저 기본 설정이 아닌 여러분이 설계한 경로를 따릅니다.

00:15:33.200 --> 00:15:35.040
마지막으로 모든 것을 하나로 연결합니다.

00:15:35.040 --> 00:15:37.060
브이넷을 다른 브이넷과 피어링합니다.

00:15:37.240 --> 00:15:40.440
예를 들어 방화벽과 공유 서비스를 포함하는 허브 브이넷과 연결할 수 있습니다.

00:15:40.660 --> 00:15:45.040
이제 애플리케이션이 여러 네트워크에 걸쳐있지만 하나의 연결된 시스템처럼 작동합니다.

00:15:45.240 --> 00:15:46.640
여기서 깨달음의 순간이 옵니다.

00:15:46.840 --> 00:15:48.720
이 요소 중 어느 것도 단독으로 작동하지 않습니다.

00:15:48.920 --> 00:15:50.640
서브넷 없는 브이넷은 빈 공간일 뿐입니다.

00:15:50.840 --> 00:15:52.700
NSG 없는 서브넷은 완전히 열려있습니다.

00:15:52.860 --> 00:15:55.400
명확한 설계 없는 나우팅은 트래픽을 엉뚱한 곳으로 보냅니다.

00:15:55.580 --> 00:15:57.520
계획 없는 피어링은 주소 충돌을 일으킵니다.

00:15:57.680 --> 00:15:58.820
이들은 하나의 시스템입니다.

00:15:58.820 --> 00:16:00.440
각 요소는 서로에게 의존합니다.

00:16:00.620 --> 00:16:01.860
구체적인 예를 들어보겠습니다.

00:16:02.200 --> 00:16:03.640
웹 애플리케이션을 상상해보세요.

00:16:03.900 --> 00:16:08.240
웹서버는 인터넷에서 오는 HTTPS 트래픽을 허용하는 NSG 가있는 공용 서브넷에 배치됩니다.

00:16:08.460 --> 00:16:12.680
애플리케이션 서버는 웹 서브넷에서 오는 트래픽만 허용하는 개인 서브넷에 배치됩니다.

00:16:12.920 --> 00:16:17.060
데이터베이스는 앱 서브넷의 트래픽만 허용하는 별도의 프라이빗 서브넷에 위치합니다.

00:16:17.360 --> 00:16:22.200
라우팅 테이블은 모든 아웃바운드 트래픽을 허브 브이넷 위 방화벽으로 강제 전송하여 로깅 및 검사를 수행합니다.

00:16:22.200 --> 00:16:25.900
그리고 이 전체 구성은 사내 네트워크와 피어링되어 내부팀이 관리할 수 있습니다.

00:16:26.080 --> 00:16:28.580
그것이 진정한 가치이지 반일 기능이 중요한 게 아닙니다.

00:16:28.720 --> 00:16:30.780
이 모든 것이 어떻게 함께 작동하느냐가 핵심입니다.

00:16:30.960 --> 00:16:35.540
20년 전에는 개별 서버를 구매하고 물리적 나우터를 구성하고 장치별로 방화벽을 관리해야 했습니다.

00:16:35.820 --> 00:16:38.360
모든 것이 수동이었고 느렸으며 비용도 많이 들었습니다.

00:16:38.580 --> 00:16:40.580
에이저는 이 모든 것을 서비스로 제공합니다.

00:16:40.780 --> 00:16:43.560
몇 번이 클릭이나 스크립트로 정의하면 그대로 작동합니다.

00:16:43.780 --> 00:16:45.380
이게 여러분에게 어떤 의미일까요?

00:16:45.580 --> 00:16:49.040
이 조각들이 어떻게 맞춰지는지 알게 되면 에이저 네트워킹은 예측 가능해집니다.

00:16:49.180 --> 00:16:50.260
추측할 필요가 없습니다.

00:16:50.260 --> 00:16:51.620
설계를 하는 것입니다.

00:16:51.780 --> 00:16:55.220
시스템을 이해하고 있기 때문에 문제가 생겨도 어디를 봐야 할지 정확히 알 수 있습니다.

00:16:55.420 --> 00:16:58.160
자, 이번 에피소드에서 여러분이 꼭 기억했으면 하는 점입니다.

00:16:58.320 --> 00:17:00.160
첫째, 가장 중요한 단계입니다.

00:17:00.380 --> 00:17:03.640
무엇이든 배포하기 전에 잘 계획된 주소 공간을 갖춘 VNET을 만드세요.

00:17:03.820 --> 00:17:06.160
그 단 하나의 결정이 이후에 모든 것에 영향을 미칩니다.

00:17:06.380 --> 00:17:09.100
둘째, 서브넷을 사용하여 애플리케이션 계층을 분리하세요.

00:17:09.280 --> 00:17:12.340
웹서버, 앱서버, 데이터베이스 등 각자에게 독립된 공간을 제공하세요.

00:17:12.520 --> 00:17:14.200
셋째, NSG로 시작하세요.

00:17:14.440 --> 00:17:15.000
무료입니다.

00:17:15.260 --> 00:17:18.140
강력하며 첫날부터 보안을 획기적으로 개선해줍니다.

00:17:18.140 --> 00:17:21.060
VNET은 에이저에서 구축하는 모든 것의 기반입니다.

00:17:21.260 --> 00:17:23.480
제대로 구축하면 다른 모든 과정이 쉬어집니다.

00:17:23.640 --> 00:17:26.660
잘못 구축하면 네트워크 문제와 씨름하는데 모든 시간을 보내게 될 것입니다.

00:17:26.860 --> 00:17:30.460
선호하는 팟캐스트 플랫폼에서 구독하고 에이저 여정을 시작하는 분들과 공유해주세요.

00:17:30.620 --> 00:17:32.600
무언가 깨달음을 얻었다면 댓글을 남겨주세요.

00:17:32.800 --> 00:17:34.240
다음 에피소드에서 뵙겠습니다.