Cloud

[Cloud] Server생성으로 Cloud기본 이해하기 (NAVERCloud활용)

Yeji Heo 2024. 4. 25. 12:25

클라우드상에서 VPC, Subnet, Server를 직접 만들고 접속해보면서

각종 클라우드 개념(Region, Zone, IGW, NAT....)과 매커니즘을 공부한 것을 기록한다!


1.  VPC

가상의 데이터센터 세운다. (NCloud에서는 최대 3개까지 생성 가능)

사용할 IP주소 범위를 CIDR을 적용해서 만든다. 

 


2. Subnet생성과 Network ACL

 

VPC에서 설정한 IP 주소 범위 내에서 방(Subnet)을 나눈다. (Subnet은 NCloud에서 최대 200개)

예를 들면 외부 통신용 Room, 내부에서만 쓸 DB용 Room등을 Subnet IP주소 범위를 통해 구분하는 것이다.

그러므로 당연히 Subnet IP 주소 범위는(CIDR로 구분했던) VPC보다 작아야 할 것이다.

(VPC에서/16까지 고정범위로 설정했다면, Subnet은 /24와 같이 더 좁은 범위로 지정하게 될 것.)

NCLOUD에서 Subnet을 생성하는 모습

 

이렇게 Subnet을 생성할 때 Zone, Network ACL, 용도를 설정하게 되는데, 그 개념에 대해 먼저 알아보자.

 


 

- Region

한 Region안에서는 고대역폭, 낮은 지연 시간으로 네트워크 연결을 할 수 있다.

실제로 각 지역에 IDC(Internet Data Center)가 있고, 거기에서 클라우드 서비스를 제공하기 때문이다.

즉, 미국서부에 주 고객층이 있다면 미국서부 Region을 통해 서비스를 제공하는 것이 유리하다.

NCLOUD에서 제공하는 Region 목록. 규모가 작을 경우 '한국'등 국가 단위로 Region을 제공한다.

 

 

- Zone

한 Region내에서 물리적으로 분리 된 데이터센터들이다.

각 Zone은 서로 독립적이기 때문에(실제 위치가 다르니까)

한쪽 Zone에 장애/화재 등 문제가 발생해도 다른 Zone을 통해 복구가 가능하다.

(유식한 말로는  High Availability(HA) 서비스의 서버 이중화를 통한 Disaster Recovery(DR)라 한다.)

 

NCloud에서는 단일Zone으로 제공되는 Region도 있고, 멀티Zone(한국, 싱가폴, 일본)으로 제공되는 Region도 있는데

한국의 경우 KR1, KR2로 2개의 Zone이 멀티존으로 제공되고있다. 

Subnet 생성 과정에서 가용Zone을 지정하는 모습

 

 

 

- Internet GateWay 허용 여부

VPC내에서 각 방(Subnet)들을 만들어줄건데, 이 방들은 서로 특징이 다를 수도 있다. 접근 범위 등 말이다.

예를 들어, 우리집(VPC)에 내방(Public Subnet)과 막내동생 아기의 방(Private Subnet)이 있다고 해보자. 

내 방에는 내 친구들도 들어올 수 있고 다른 외부 사람들이 들어와도 된다.

그러나 아기 방에는 나만 들어갈 수 있다. 외부인이 아기 방에 들어가려면 내 방에서 내 허락을 받고 가야된다.(나를 거쳐가야한다.)

반대로 나는 내 방에서 자유롭게 밖으로 나갈 수가 있지만, 아기 방의 아기는 집 밖으로 막 나갈 수 없다. 소중하기 때문이다.  ==>소중한 건 뭘까? 외부 사람들이 쉽게 접근하지 못하는 영역, DB정보 등에 해당한다.

 

즉, Public Subnet은 Internet GateWay를 yes로 허용하여 외부에서 치고 들어올 수도 있고, 나갈 수도 있다. 공인 IP를 할당하기 때문이다. 

그러나 Private Subnet은 Internet GateWay를 no로 하여 직접적으로 들어올수도/나갈수도 없게 하기 위한 것이 목적이라 공인IP를 할당하지 않으며, 부여된 로컬IP를 통해 내부 Subnet끼리만 접근할 수 있다. 

Subnet생성 과정에서 Internet Gateway선택으로 Private Subnet을 생성하려는 모습

 

 

 

- NAT(Network Address Translation)

한편, DB서버를 Private Subnet에 만들었다면 외부로부터 설치해야할 각종 프로그램이 있을텐데 

그 경우에는 어떡하지? NAT GateWay를 통해 가능하다. 

private subnet에서 NAT GW를 통해 외부와 통신할 때는 사설IP를 공인 IP로 변환하면서 그 IP정보를 NAT가 가지고있고, 리눅스 등을 설치하고자 그 파일을 가져올때도 기억해뒀던 IP로 들어오게 되는 것이다. 

즉, 외부에서 직접적으로 들어오는 것은 여전히 안 되고, NAT를 통해 흘러들어오기만 가능하기 때문에 '단방향적'이라는 얘기를 하곤 한다. (요청은 Subnet쪽에서만 할 수 있고 외부에서는 할 수 없는, OutBound통신만 가능.)

 

 

- Network ACL

Subnet의 방화벽이다. 약간 헷갈렸던 게 private, public과는 별개의 개념인가?였다.

Internet GateWay를 통해서는 공인 IP를 통해 외부와 통신할 것인가를 설정한 거고,

NACL은 외부통신인지 내부통신인지보다, 오가는 요청&응답에 대해 필터링을 하는 과정이라고 생각한다.

단순히 이 Subnet에 어떤 접근소스와 포트를 가진 녀석들이 들어오거나(Inbound) 나갈 수 있는지(Outbound) 리스트업 한 것이다. 

 

  • Network ACL Rule 특징

NACL은 Defalut로 All permit(Allow)이기 때문에, 따로 설정을 하지 않으면 모든 것들이 들어오고 나갈 수 있다.

그러므로 차단하고자 하는 것을 명시하는 BlackList Firewall에 해당하는데, 그렇다면 허용여부 옵션은 굳이 왜 있을까?

우선순위가 있기 때문이다. 예를 들어, 특정 접근소스만 허용하고 그 외에는 전부 차단하려고 한다면 허용하고싶은 접근소스에 높은 우선순위를 두고 그 외 모든 접근소스를 차단하면 되는 것이다.

 

  • 특징의 활용

서버 방화벽인 ACG는 NACL과 반대로 Default가 All Deny다(WhiteList Firewall).

즉, 내가 Rule을 설정해주지 않으면 어떤 소스도 접근할 수 없기 때문에 꼭 설정을 해주어야 하는 것이다.

이처럼 ACG와 NACL의 서로 다른 특성에 알맞게 잘 조합하여 접근/방출을 제어할 수 있다.

예를 들어 중국에서 오는 접근만 모두 차단하고 싶다면 ACG로는 어려울 것이다.

모든 접근소스를 다 허용하도록 등록해줘야하기 때문이다. 

그럴 때 BlackList Firewall인 NACL을 쓴다면, 기본적으로 모든 접근을 허용하되 중국의 접근소스만 차단으로 등록해주면 되므로 더 편할 수 있다. 

public subnet에 적용할 NACL을 정의했다.

 

private subnet에 적용할 NACL을 정의했다.

 

 

 

- Subnet 생성

Public Subnet과 Private Subnet의 NACL을 각각 만들고, 이 Rule을 적용한 각 Subnet을 생성했다.

public subnet에 nacl을 적용해 추가한 모습
private subnet에 nacl을 적용해 추가한 모습

 


3. 서버 생성과 ACG 

 

이제 각 Subnet에 Server를 생성해보자. (VPC ⊃ Subnet  ⊃ Server)

Private Subnet에는 DB용으로 쓰일 서버를 만들고, Public Subnet에는 Tomcat등 WAS가 설치 될 배포용 서버 등을 만들게 되는 것이다. 

서버를 만들 때는 앞서 말했듯이 ACG라는 서버 방화벽을 씌워줄 것이므로 ACG를 먼저 만들겠다.

 

- ACG 생성

앞서 말했듯이 ACG는 Default가 All Deny이므로 허용할 접근소스를 리스트업 해준다.

public subnet에 만들어질 public한 server 방화벽 룰 설정

 

위는 public subnet에 위치하는 server에 접근하는 소스의 방화벽 Rule 예시이다.

 

- 외부에서 내 서버에 Ping을 날려보기 위해서 Ping이 사용하는 프로토콜 ICMP (Internet Control Message Protocol)의 모든 접근(0.0.0.0/0)을 허용했다.

- HTTP로 들어오는 모든 접근도 허용하고자 80포트를 허용했다. HTTP는 TCP위에서 작동하므로 프로토콜은 TCP로 한 것이다.

- 나는 서버 접속을 위해 SSH(Secure Shell)프로토콜을 사용할 것인데(cmd에서 "SSH 유저명@IP" 형식으로 접속), 이는 TCP상에서 작동하는 형태이므로 SSH의 포트인 22의 모든 접근 소스도 허용해줬다. 

 

이런식으로 각자 요구사항에 맞게 ACG의 Inbound와 Outbound Rule을 잘 명시해주면 된다.

 

- Server 생성

Server생성탭에서 서버이미지의 운영체제 및 하이퍼바이저를 선택하고 (OS마다, 하이퍼바이저마다 특징이 다른데 이 부분은 생략하겠다. 나는 Ubuntu, KVM조합으로 했다.) 위와 같은 서버 설정 탭으로 넘어온다.

 

만들어둔 VPCSubnet을 선택한다. VPC는 난 1개만 만들었으니 선택해주고,

DB서버처럼 폐쇄적인 서버를 만들 거라면 private서브넷에 넣어주는 등 본인이 만든 서브넷 중 선택하면 된다.

서버 스펙은 제일 저렴한 걸로ㅎㅎ 했다.

 

공인IP는 외부와의 통신을 위해 할당하는데, private subnet안에 생성하는 서버는 폐쇄적이니까 공인IP필요도 없고 애초에 할당이 안 된다(라디오박스가 아예 비활성화 상태다.)

public subnet에 생성하는 서버는 미설정하면 내가 가지고있던 공인 IP를 추후에 할당 해주면되고, 새로운 공인IP할당받아도 된다. 

 

내부, 외부의 네트워크 통신을 위해 Network Interface를 할당해준다. 외부 네트워크의 경우 Internet GateWay 및 라우터를 지난 네트워크가 Route Table에 명시된 Routes를 보고 통신을 하게 된다.

public

 

Script는 Init Script탭에서 작성한 script를 선택할 수 있다.

Init Script는 서버 생성 시 실행되는데, 서버에 설치해야할 패키지, 초기 설정 내용을 스크립트로 작성해서 일괄 실행하게 된다. 같은 용도의 서버를 여러 대 만들 계획이거나, 주기적으로 같은 환경을 가진 서버를 생성할 때, 용도별로 초기 세팅이 필요할 때 등 어떤 공통된 설치 및 세팅을 해주고 싶을 때 사용하게 된다.

예를 들어 Tomcat이 설치될 서버를 여러개 생성하고 싶다면, Tomcat설치 관련 명령어를 스크립트화 해서 서버 생성시 각각 넣어주어, 편리하게 환경을 구축할 수 있는 것이다.


4. 각 서버 동작 확인 & 어떻게 통신할까

내가 구축한 VPC에

private subnet과 public subnet을 각각 만들었고

각 subnet안에 서버를 1대씩 생성했다.

이제 각각에 접속해보며 어떻게 통신하는지 살펴보겠다.

 

- Route Table

NCloud는 VPC생성 시점에서 default-public-table 과 default-private-table이 제공된다.

Internet Gateway를 통해 들어온 네트워크는 이 Route table을 보고 어떻게 라우팅할지 판단하게 된다.

 

public table의 연관Subnet 목록

 

public subnet은 이 테이블에 연관되어 있기 때문에,

이 테이블의 Routes에 적힌대로 라우팅된다.

public table의 Routes 명시

public table에는 public subnet이 연관되어있다. 

모든 접근 소스(0.0.0.0/0)은 IGW를 통해 외부로 연결 되며

10.0으로 시작하는 접근소스는 Local로 연결 되도록 설정되어 있다.

 

 

privat table

한편, Subnet지원 유형이 '사설'인(사설 Subnet을 위한 테이블) private-table은 위와 같다.

public table의 routes와 달리 Internet GateWay는 타겟으로 하지 않고 있다. 즉, IGW를 통해 외부와 통신하지 않는다.

그러나 Local끼리는 통신할 수 있도록, 10.0으로 시작하는 목적지는 LOCAL로 라우팅하도록 명시한 것이다.

 

한편, NATGW도 타겟으로 되어있는데, NAT 개념과 생성에 대해서는 다음 글에서 알아보도록 하고

서버 테스트부터 해보자.

 

- 각 서버 접속 및 통신

 

1. public subnet의 서버

먼저 public subnet에 만든 서버의 공인IP로 접속해보자.

콘솔에서 ssh 계정명@공인IP를 입력해서 접속했다.

 

 

구글에 ping을 날려보면, 이 서버는 외부와도 잘 통신하는 것을 확인할 수 있다.

ping www.google.com

 

 

2. private subnet의 서버

private subnet에 위치한 서버는 Internet Gateway전용 여부를 No로 했으니 Route table은 커녕 IGW도 거치지 못한다.

공인IP가 없으므로 외부 접속 자체가 불가한 것이다.

 

그러나 공인 IP가 있는 public subnet에 일단 접근한다면

public subnet은 Route table에서 확인했듯이 10.0.0.0/16목적지의 Local로는 라우팅 할 수 있다.

따라서 private subnet에 있는 서버에 접근하고자 한다면

public subnet의 공인IP를 통해 public subnet 까지 이동 ==> private subnet의 로컬IP를 통해 private subnet에 도달!

 

아래는 public 서버에 접속한 상태에서, ssh 계정명@로컬IP을 입력해서 private서버에도 접속한 모습이다.

똑같이 구글에 ping을 날려보면 여기서는 응답을 받을 수 없다.

외부와 통신하지 않는 폐쇄적인 서버이기 때문이다. 

그러나 같이 로컬에 있는 서버인 public subnet의 서버에는 ping을 날리고 서로 통신할 수 있다.

 

하지만 개발을 하다보면, DB서버와 같이 폐쇄적인 서버에도 JDK설치하고 Linux설치하고.. 외부로부터 뭔가 받아와야할 필요가 생긴다. 이 때 사용하는게 NAT Gateway이다. 다음 글에서 정리하도록 할게요!!!