[4주차] 클라우드에서의 가상 머신과 네트워크
학습목표
1. 기본 인프라를 구글 클라우드에 배포하기
2. 구글 클라우드에서 클라우드 로드 밸런싱 기능이 어떻게 작동하는지 살펴 보기
3. 라우팅 테이블, 방화벽, VPC 피어링을 포함한 중요 VPC 호환성에 대해 상세히 살펴 보기
4. 구글 컴퓨트 엔진의 목적과 사용 사례 파악하기
5. 구글 클라우드에서 네트워킹의 기본 파악하기
6. 구글 컴퓨트 엔진이 어떻게 확장할 수 있는지 개략적으로 설명하기
[4-1] 가상 프라이빗 클라우드 네트워킹
이번 섹션에서는 어떻게 구글 컴퓨트 엔진이 가상 네트워킹에 중점을 두고 작동하는지 알아보도록 한다. 구글 클라우드의 많은 사용자는 자신의 가상 프라이빗 클라우드를 그들의 첫 번째 구글 클라우드 프로젝트 내부에 정의하거나 디폴트 가상 프라이빗 클라우드를 시작함으로써 발을 내딛는다.
그렇다면 여기서 가상 프라이빗 클라우드란 대체 무엇일까? 가상 프라이빗 클라우드, 이른바 VPC는 구글 클라우드와 같이 공공 클라우드 내에서 호스트되는 안전하고, 개별적인 프라이빗 클라우드 컴퓨팅 모델이다. VPC에서 고객은 코드를 실행하고, 데이터를 저장하고, 웹사이트를 호스트하고, 그밖에 일반적인 프라이빗 클라우드에서 할 수 있는 모든 작업을 수행할 수 있다. 그러나 이 프라이빗 클라우드는 퍼블릭 클라우드 공급업체에 의해 원격으로 호스트된다.
이는 VPC가 공용 클라우드 컴퓨팅의 확장성과 편리성을 사설 클라우드 컴퓨팅의 데이터 격리와 결합한다는 것을 의미한다. VPC 네트워크는 구글 클라우드 리소스를 서로 연결하고, 인터넷에 연결한다. 여기에는 네트워크 분할, 인스턴스에 대한 엑세스를 제한하기 위해 방화벽 규칙을 사용하는 것, 특정 목적지로 트래픽을 전달하기 위한 정적 경로 생성이 포함된다. 여기에는 많은 새로운 구글 클라우드 사용자들을 놀라게 하는 것들이 있다. 구글 VPC 네트워크는 글로벌하다. 그리고 전 세계의 모든 구글 클라우드 리전에서 더 큰 네트워크의 세분화된 부분인 서브넷을 가질 수 있다. 서브넷은 리전을 구성하기 위한 구역에 걸쳐있을 수 있다. 이 아키텍처를 사용하면 글로벌 범위로 네트워크 레이아웃을 쉽게 정의할 수 있다. 그리고 심지어 리소스는 동일한 서브넷의 다른 구역에 존재할 수도 있다. 서브넷의 크기는 그것에 할당된 IP 주소의 범위를 확장함으로써 증가시킬 수 있고, 이미 구성된 가상 머신에는 영향을 미치지 않는다.
예를 들어, asia-east1과 us-east1 리전에 정의된 2개의 서브넷이 있는 vpc1이라는 VPC가 있다. 만약 그 VPC에 3개의 컴퓨트 엔진 가상 머신이 연결되어 있으면, 그들이 다른 구역에 있다 하더라도 동일한 서브넷에 존재하는 이웃이라는 것이다. 이 기능을 사용하여 운영 중단 상황에 탄력적인 솔루션을 구축하고, 간단한 네트워크 레이아웃을 유지할 수 있다.
[4-2] 컴퓨트 엔진
이 강의의 초반에 우리는 서비스형 인프라인 IaaS에 대해 살펴 보았다. 이제는 구글 클라우드의 IaaS 솔루션인 컴퓨트 엔진에 대해 알아보도록 한다. 컴퓨트 엔진을 사용하면, 사용자들은 구글 인프라에서 가상 머신을 생성하고 실행할 수 있다. 선불 개념은 없고, 수천 개의 가상 CPU가 빠르고 일관된 성능을 제공하도록 설계된 시스템에서 실행될 수 있다. 각 가상 머신에는 완전한 운영 체제의 성능과 기능이 포함되어 있다. 이것은 가상 머신이 물리적인 서버처럼 구성될 수 있다는 것을 의미한다. 필요한 CPU 전력과 메모리의 양, 필요한 스토리지의 양과 타입, 운영 체제를 지정함으로써 말이다. 가상 머신 인스턴스는 구글 클라우드 콘솔을 통해 생성될 수 있으며, 이는 구글 클라우드 프로젝트와 리소스를 관리하는 웹 기반 도구인 구글 클라우드 CLI나 컴퓨트 엔진 API를 통해 가능하다. 그 인스턴스는 구글에서 제공하는 리눅스와 윈도우 서버 이미지 또는 이러한 이미지의 사용자 정의된 버전을 실행할 수 있다. 또한, 다른 운영 체제의 이미지를 구축 및 실행하고, 가상 머신을 유연하게 재구성할 수도 있다. 구글 클라우드를 시작하는 빠른 방법은 구글과 타사 공급업체 모두의 솔루션을 제공하는 클라우드 마켓플레이스를 통하는 것이다. 이러한 솔루션들을 사용하면, 소프트웨어, 가상 머신 인스턴스, 스토리지나 네트워크 세팅을 직접 구성할 필요가 없지만, 필요하다면 그들 중 많은 수가 실행 전에 변경될 수 있다. 클라우드 마켓플레이스에 있는 대부분의 소프트웨어 패키지는 구글 클라우드 리소스에 대한 일반 사용료를 넘는 추가 비용 없이 사용할 수 있다. 일부 클라우드 마켓플레이스 이미지는 상업적으로 라이센스가 부여된 소프트웨어를 사용하여 사용료, 특히 타사에서 게시한 사용료를 부과하지만, 그들은 작업이 실행되기 이전에 월 별 요금의 견적을 보여준다.
그렇다면 컴퓨트 엔진의 프라이싱과 빌링 구조는 어떻게 될까? 가상 머신을 사용할 경우, 컴퓨트 엔진은 최소 1분을 기준으로 초 단위로 계산하고, 지속 사용으로 인한 할인은 실행 시간이 길어질수록 자동적으로 가상 머신에 적용된다. 따라서 한 달 동안 25% 이상 실행되는 각 가상 머신에 대해 컴퓨트 엔진은 추가 시간(분)마다 자동으로 할인을 적용한다는 것이다. 또한, 컴퓨트 엔진은 일종의 약정 할인을 제공한다. 즉, 안정적이고 예측 가능한 워크로드의 경우, 1년 또는 3년의 사용 기간을 약속함으로써 그에 대한 보상으로 특정 양의 가상 CPU와 메모리를 정상 가격에 비해 최대 57% 할인된 가격으로 구입할 수 있다.
그리고 선점형(Preemptible) VM과 스팟 VM이 있다. 대규모 데이터셋을 분석하는 배치 작업과 같이 작업이 끝날 때까지 사람이 앉아서 기다릴 필요가 없는 작업량이 있다고 해보자. 우리는 작업을 실행하기 위해 선점형 VM이나 스팟 VM을 실행함으로써 경우에 따라 최대 90%까지 비용을 절약할 수 있다. 선점형 VM이나 스팟 VM은 한가지 측면에서 일반적인 컴퓨트 엔진 VM과 구별된다. 컴퓨트 엔진의 경우, 리소스가 다른 곳에 필요한 경우, 작업을 종료할 수 있는 권한을 지니고 있다. 선점형 VM이나 스팟 VM을 사용하면 비용은 절감할 수 있지만, 작업을 중지하거나 재시작하는 것은 직접 처리해야 한다.
스팟 VM은 더욱 많은 기능을 제공한다는 점에서 선점형 VM과 구분된다. 예를 들어, 선점형 VM은 한 번에 최대 24시간만 실행할 수 있지만, 스팟 VM에는 최대 런타임의 개념이 없다. 하지만 프라이싱 측면에서는 둘은 동일하다. 스토리지 측면에서, 컴퓨트 엔진은 프로세싱 디스크와 영구적인 디스크 사이에 높은 처리량을 얻기 위해 특정 옵션이나 머신 타입을 필요로 하지 않는다. 그것이 디폴트고, 추가 비용 없이 제공된다. 마지막으로, 커스텀 머신 타입이 필요한 경우에만 비용을 지불하게 된다. 컴퓨트 엔진을 사용하면, 사전 정의된 머신 타입 셋을 사용하거나, 자체 커스텀 머신 타입을 생성함으로써 가상 CPU의 수와 메모리의 양과 같은 인스턴스의 머신 속성을 선택할 수 있다.
[4-3] 가상 머신 스케일링
앞서 살펴본 것처럼, 컴퓨트 엔진을 사용하면 사전 정의된 머신 타입 셋을 사용하거나, 자체 커스텀 머신 타입을 생성함으로써 가상 CPU의 수와 메모리의 양과 같은, 우리의 인스턴스에 가장 적합한 머신 속성을 고를 수 있다. 이를 위해 컴퓨트 엔진은 오토스케일링이라는 기능을 갖고 있다. 이를 통해 VM은 로드 메트릭을 기반으로 애플리케이션에 추가되거나 제거될 수 있다. 이 작업을 수행하는 다른 부분은 VM들 사이에 들어오는 트래픽의 균형을 맞추는 것이다. 구글의 가상 사설 클라우드(VPC)는 몇 가지 다른 종류의 로드 밸런싱을 지원하며, 이는 나중에 살펴본다. 컴퓨트 엔진을 사용하면, 인메모리 데이터베이스와 CPU 집약적인 분석과 같은 워크로드에 적합한 매우 큰 VM을 실제로 구성할 수 있지만, 대부분의 구글 클라우드 고객은 스케일 업이 아닌 스케일 아웃으로 시작한다. 즉, 사양을 업그레이드하는 게 아니라, 여러 대의 서버가 분산하여 처리하는 것을 선택한다는 것이다. VM당 최대 CPU 수는 machine family에 연결되고, 사용자가 사용할 수 있는 할당량도 제한되며, 이 할당량은 구역에 따라 달라진다. 현재 사용 가능한 VM 머신 타입은 cloud.google.com/compute/docs/machine-types에서 확인할 수 있다.
[4-4] 중요한 VPC의 호환성
이제 가장 중요한 VPC의 호환 기능 몇 가지를 살펴보도록 한다. 물리적인 네트워크와 마찬가지로, VPC에는 라우팅 테이블이 있다. VPC 라우팅 테이블이 내장되어 있어, 우리는 라우터를 프로비저닝하거나 관리할 필요가 없다. 이들은 외부 IP 주소에 대한 요구 없이 동일한 네트워크 내, 서브네트워크 간, 심지어 구글 클라우드 구역 사이에 한 인스턴스에서 다른 인스턴스로 트래픽을 전달하는 데 사용된다.
구글 클라우드 용도로 프로비저닝하거나 관리할 필요가 없는 또 다른 것은 방화벽이다. VPC는 글로벌 분산 방화벽을 제공하며, 이 방화벽은 들어오고 나가는 트래픽 모두를 통해 인스턴스에 대한 엑세스를 제한하도록 제어할 수 있다. 컴퓨트 엔진 인스턴스의 네트워크 태그를 통해 방화벽 규칙이 정의될 수 있으며, 이는 매우 편리하다.
예를 들어, 우리는 모든 웹 서버에 WEB 태그를 지정하고, 80번 포트나 443번 포트에 있는 트래픽이 IP 주소와 무관하게, WEB 태그가 있는 모든 VM에 허용된다는 방화벽 규칙을 작성할 수 있다. VPC가 구글 클라우드 프로젝트에 속한다는 것은 우리가 알고 있다.
그런데 만약 어떤 회사에 여러 구글 클라우드 프로젝트가 있는데 VPC들이 서로 통신해야 한다면 어떨까? VPC 피어링을 사용하면 두 VPC 간의 관계를 설정하여 트래픽을 교환할 수 있다. 다른 방식으로는, IAM의 모든 기능을 사용하여, 한 프로젝트에서 다른 프로젝트의 VPC와 상호작용할 수 있는 사용자와 대상을 정하기 위해 Shared VPC를 구성할 수도 있다.
[4-5] 클라우드 로드 밸런싱
이전에 우리는 어떻게 가상 머신이 변화하는 부하에 대응하기 위해 자동으로 스케일링하는지 살폈다. 그런데 한 번에 4개의 VM이, 다른 순간에는 40개의 VM에 의해 제공되는 애플리케이션이 있다면, 그때는 어떻게 해야 할까? 이때 등장하는 개념이 클라우드 로드 밸런싱이다. 로드 밸런서의 역할은 한 애플리케이션의 여러 인스턴스에 사용자 트래픽을 분산하는 것이다. 로드 밸런싱은 로드를 분산함으로써 애플리케이션이 성능 문제를 겪을 위험을 줄인다. 클라우드 로드 밸런싱은 모든 트래픽에 대한 소프트웨어 정의의 완벽한 분산 관리 서비스다. 그리고 로드 밸런서는 관리해야 하는 VM에서 실행되지 않기 때문에 스케일링이나 매니징에 대해 걱정할 필요가 없다. HTTP 또는 HTTPS, 기타 TCP와 SSL 트래픽, UDP 트래픽 등 우리는 모든 트래픽 앞에서 로드 밸런싱을 둘 수 있다. 클라우드 로드 밸런싱은 자동적인 멀티 리전 대체 작동을 포함한 리전 간의 로드 밸런싱을 제공하여 백엔드가 제대로 작동하지 않을 경우 트래픽을 몇 분 단위로 부드럽게 이동한다. 클라우드 로드 밸런싱은 사용자들, 트래픽, 네트워크, 백엔드 상태와 기타 관련 조건의 변화에 신속하게 반응한다. 그런데 만약 수요가 아주 크게 증가할 것으로 예상하면 어떻게 해야 할까? 예를 들어, 우리가 즐기는 온라인 게임이 이미 인기가 많다. 그때 구글로 들어오는 로드를 경고하기 위해 지원 티켓을 필요로 할까? 아니다. 소위 말하는 pre-warming은 필요치 않다.
대신, 일련의 로드 밸런싱 옵션을 제공한다. 웹 애플리케이션에 대해 리전 간의 로드 밸런싱이 필요한 경우, 우리는 글로벌 HTTP(S) 로드 밸런싱을 사용한다. HTTP가 아닌 SSL 트래픽의 경우, 글로벌 SSL 프록시 로드 밸런서를 사용한다. 만일 SSL을 사용하지 않는 다른 TCP 트래픽의 경우, 글로벌 TCP 프록시 로드 밸런서를 사용한다. 그 2가지 프록시 서비스는 특정 포트 번호에만 작동하며, TCP에만 작동한다. 만일 UDP 트래픽 또는 임의의 포트 번호에 있는 트래픽을 로드 밸런싱하길 원한다면, Regional External Passthrough Network 로드 밸런서를 사용하여 구글 클라우드 리전에서 로드 밸런싱을 수행할 수 있다. 또한, Regional External Application 로드 밸런서와 Proxy Network 로드 밸런서를 배포할 수도 있을 것이다. 이 모든 서비스의 공통점은 인터넷에서 구글 네트워크로 들어오는 트래픽을 대상으로 한다는 점이다. 그러나 만약 애플리케이션의 프레젠테이션 계층과 비즈니스 계층 사이의 프로젝트 내부에서 트래픽을 로드 밸런싱하려면 어떻게 해야 할까? 이 경우, Proxy Network 로드 밸런서, Passthrough Network 로드 밸런서, Application 로드 밸런서를 지원하는 Regional Internal 로드 밸런서를 사용하면 된다. 그것을 통해 구글 클라우드 내부 IP 주소에서 트래픽을 수신하고, 컴퓨트 엔진 VM들 간의 로드 밸런싱을 수행할 수 있다. 마지막으로, 구글 클라우드 Cross-region Internal 밸런서는 트래픽이 가장 가까운 백엔드로 향하도록 보장하는 트래픽 관리를 포함하여, 세계적으로 분산된 백엔드 서비스에 트래픽을 로드 밸런싱할 수 있도록 지원하는 7계층 로드 밸런서이다.
[4-6] 클라우드 DNS와 클라우드 CDN
가장 유명한 무료 구글 서비스 중 하나인 8.8.8.8은 전 세계에 공개 도메인 명칭 서비스(DNS)를 제공한다.
DNS는 인터넷 호스트 이름을 주소로 변환하는 것이며, 구글은 고로도 발달된 DNS 인프라를 지니고 있다. 그로 인해 모든 사람이 8.8.8.8을 이용할 수 있다. 하지만 구글 클라우드에 내장된 애플리케이션의 인터넷 호스트 이름과 주소는 어떨까? 구글 클라우드는 클라우드 DNS를 제공하여 전 세계가 그것들을 찾을 수 있게 돕는다. 그것은 구글과 동일한 인프라에서 실행되는 관리형 DNS 서비스이다. 지연 시간이 짧고, 가용성이 높으며, 사용자가 애플리케이션과 서비스를 모두 이용할 수 있도록 하는 비용 효율적인 방법이다. 게시하는 DNS 정보는 전 세계의 곳곳의 위치에 제공된다. 클라우드 DNS는 또한 프로그래밍 가능하다. 우리는 클라우드 콘솔, CLI, 또는 API를 이용하여 수백만 개의 DNS 구역과 레코드를 게시하고 관리할 수 있다.
또한, 구글은 엣지 캐시의 글로벌 시스템을 보유하고 있다. 엣지 캐싱이란, 캐싱 서버를 활용하여 콘텐츠를 최종 사용자에게 더 가깝게 저장하는 것을 말한다. 이 시스템을 사용하여 클라우드 CDN(Content Delivery Network)를 통해 애플리케이션에서 콘텐츠 전달을 가속화할 수 있다. 이는 고객이 더욱 낮은 지연 시간을 경험하고, 콘텐츠 원본이 더욱 적은 부하를 경험하며, 우리가 심지어 비용을 아낄 수 있음을 의미한다. HTTP(S) 로드 밸런싱을 설정한 이후, 클라우드 CDN은 하나의 체크박스로 활성화될 수 있다.
물론, 다른 CDN도 많이 존재한다. 이미 하나의 CDN를 사용하고 있다면, 구글 클라우드의 CDN Interconnect 파트너 프로그램의 일부일 수 있으며, 그렇기에 계속 사용할 수 있다.
[4-7] 구글 VPC에 네트워크 연결
많은 구글 클라우드 고객들은 그들의 구글 가상 사설 클라우드 네트워크를 온프레미스 네트워크나 다른 클라우드의 네트워크 같은 시스템 내 다른 네트워크에 연결하기를 원한다. 그리고 이것을 달성하기 위한 효과적인 방법이 몇 가지 있다. 한 가지 옵션은 인터넷을 통한 VPN 연결로 시작하고, 클라우드 VPN을 사용해 일종의 '터널' 연결을 만드는 것이다. 연결을 동적으로 만들기 위해 클라우드 라우터라 불리는 구글 클라우드 기능을 사용할 수 있다. 클라우드 라우터를 사용하면, 다른 네트워크와 구글 VPC가 Border Gateway Protocol(BGP)을 사용하여 VPN을 통해 경로 정보를 교환할 수 있다. 이 방법을 사용하면, 만일 우리가 우리의 구글 VPC에 새로운 서브넷을 추가할 때, 우리의 온프레미스 네트워크에 자동으로 경로가 표시될 것이다. 그러나 인터넷을 사용하여 네트워크를 연결하는 것이 항상 모두에게 최선의 선택이라고 할 수는 없다. 여기에는 보안 문제와 대역폭 신뢰의 문제가 있기 때문이다.
따라서 두 번째 옵션은 Direct Peering을 사용하여 구글을 '피어링'하는 것이다. 피어링은 라우터를 구글의 존재 지점과 동일한 공공 데이터 센터를 두고 네트워크 간의 트래픽을 교환하는 데 사용하는 것을 의미한다.
구글은 전 세계에 100개 이상의 지점을 보유하고 있다. 그리고 그 지점에 없는 고객의 경우, Carrier Peering 프로그램에서 파트너와 협업하여 연결할 수 있다. 캐리어 피어링을 사용하면, 서비스 공급업체의 네트워크를 통해 온프레미스 네트워크에서 구글 워크스페이스와 하나 이상의 공용 IP 주소를 통해 노출될 수 있는 구글 클라우드 제품에 직접 엑세스할 수 있다. 그렇지만 피어링의 한 가지 단점은 구글 서비스 레벨 계약(SLA)에는 포함되지 않는다는 점이다.
만약 상호 연결을 위한 최고의 가동 시간을 확보하는 것이 중요하다면, Dedicated Interconnect을 사용하는 것이 좋은 해결책이 될 것이다. 이 옵션을 사용하면 구글에 하나 이상의 다이렉트 사설 연결을 할 수 있다. 이러한 연결들이 구글의 사양에 맞는 토폴로지를 갖고 있다면, 그것들은 최대 99.99%까지 SLA를 적용받을 수 있다. 또한, 이러한 연결은 VPN에 의해 백업이 가능해 심지어 신뢰성이 뛰어나기까지 하다.
다른 옵션으로는, 우리는 Partner Interconnect을 살펴볼 수도 있다. 그것은 지원되는 서비스 공급업체를 통해 온프레미스 네트워크와 VPC 네트워크 사이의 연결을 제공한다. Partner Interconnect 연결은 데이터 센터가 Dedicated Interconnect 콜로케이션 시설에 닿을 수 없는 물리적 위치에 있거나, 데이터가 초당 10 GB의 연결을 보장할 필요가 없는 경우에 유용하다. 가용성의 요구에 따라, Partner Interconnect는 일부 다운타임을 견딜 수 있는 미션 크리티컬 서비스(* 고도의 신뢰성이 요구되는 분야) 또는 애플리케이션을 지원할 수 있도록 구성될 수 있다. Dedicated Interconnect와 마찬가지로, 이러한 연결들이 구글의 사양에 충족하는 토폴리지를 지니는 경우, 최대 99.99%가 SLA의 적용을 받을 수 있지만, 타사 서비스 공급업체에 의해 제공되는 Partner Interconnect의 모든 측면이나 구글 네트워크의 외부의 문제에 대해서는 구글은 어떠한 책임도 지지 않는다.
그리고 마지막 옵션은 Cross-Cloud Interconnect이다. Cross-Cloud Interconnect은 구글 클라우드와 다른 클라우드 서비스 공급업체 사이의 고대역폭 전용 연결을 구축할 수 있도록 도와준다. 구글은 구글 네트워크와 다른 클라우드 서비스 제공업체 간의 전용 물리적 연결을 제공한다. 우리는 이 연결을 통해 구글 VPC 네트워크를 지원받는 클라우드 서비스 공급업체에 의해 호스트되는 네트워크에 연결할 수 있다. Cross-Cloud Interconnect는 통합 멀티클라우드 전략을 채택할 수 있도록 지원하기도 한다. Cross-Cloud Interconnect는 다양한 클라우드 서비스 공급업체를 지원할 뿐만 아니라, 복잡성 감소, 사이트 간 데이터 전송, 암호화 기능도 제공한다. Cross-Cloud Interconnect는 10 Gbps 또는 100 Gbps의 2가지 크기로 제공된다.
[4-8] VPC 네트워킹과 구글 컴퓨트 엔진 시작
이제는 어느덧 친숙해진 앱 화면이다. 몇 번 해봤다고 이제 꽤나 능숙해졌다.
서브넷이 포함된 디폴트 네트워크다. 여기에 있는 각 서브넷은 내부 IP 주소 범위와 게이트웨이에 대한 구글 클라우드 리전 및 프라이빗 RFC 1918 CIDR 블록과 연결된다.
이번엔 경로를 확인해 본다. 경로는 VM 인스턴스와 VPC 네트워크에 내부 네트워크 또는 구글 클라우드 외부의 인스턴스에서 목적지로 트래픽을 보내는 방법을 알려준다. 각 VPC 네트워크에는 서브넷들 간에 트래픽을 라우팅하고, 적합한 인스턴스의 트래픽을 인스턴스로 전송하는 기본 경로가 제공된다.
이번에는 방화벽을 확인해 본다. 기본 네트워크에는 4개의 유입 방화벽 규칙이 존재한다. 여기서 규칙 4가지를 삭제하고, VPC 네트워크도 삭제하면, 경로도 전부 사라진 것을 확인할 수 있다.
이번엔 VM 인스턴스를 해본다. 디폴트 옵션으로 생성을 만들면 오류가 발생한다. 이는 네트워크 인터페이스에 더이상 네트워크가 존재하지 않기 때문이다. 따라서 VPC 네트워크에서 생성을 해야 한다.
이렇게 VPC 네트워크를 만들었으니, 이제 VM 인스턴스를 시도할 수 있게 되었다.
확실히 문제 없이 VM 인스턴스를 생성할 수 있게 되었다. 2개의 VM 인스턴스를 생성했다.
이번 랩에서는 기본 네트워크를 서브넷, 경로, 방화벽 규칙과 함께 탐색하였다. 여기서 각 방화벽 규칙은 무엇을 의미하는지, VM 인스턴스를 만들 수 있는 조건은 무엇인지를 이해할 수 있었다.
이것으로 4주차의 학습을 마친다.