[Seminar4] 인프라 구조

[Jang99u]

인프라 구조에 대한 이모저모

서버 생성을 완료하면 다음과 같이 상세정보를 확인할 수 있습니다.

서버가 몇개의 CPU를 사용하고 스토리지 정보는 어떻게 되는지와 같은 성능적인 부분보다는 인프라 구조가 어떻게 될까에 초점을 맞춰 봤습니다.

하나하나 자세히 살펴보기 전에.. 우리가 만들어진 인스턴스가 어떻게 돌아가는지 부터 알면 좋을 것 같아서 공부를 조금 해봤습니당

우리의 목표는 네이버 클라우드 서비스를 이용하여 인스턴스라는 가상의 서버를 생성하고 이를 외부 인터넷과 연결하게 해주는 것입니다. 아무런 인스턴스도 생성되지 않은 상태의 모습이 위와 같다고 했을 때, 인스턴스들이 만들어진 후의 형상은 어떻게 될까요 ?

가장 단순하게 생각하면 위와 같이 생성될 수 있을 것 같습니다. 각각의 인스턴스들은 모두 독립적으로 존재하여 외부의 인터넷과 통신을 하는 형상으로 존재하는 것처럼요. 하지만 실제로도 이렇게 존재할까요 ?

정답은 당연히 아니다 입니당. 각각의 인스턴스들이 모두 독립적으로 존재하게 되면, 각각의 인스턴스들은 모두 거미줄처럼 엉키게 되고 이런 구조는 너무도 복잡하고 비효율적입니다. 그렇다면 각각의 인스턴스들은 실제로 어떻게 존재할까요 ?

여기서 등장하는 개념이 VPC 입니다.

---

VPC(Virtual Private Cloud) 말 그대로 가상의 프라이빗한 클라우드.. 라고 할 수 있습니다. 제가 적으면서도 이게 무슨말인지 조금 헷갈려서 하나하나 풀어서 공부해봤습니다.

Virtual 말 그대로 가상의 환경이라는 뜻입니다. 조금 더 풀어보면, 물리적으로 구현된 것이 아닌 소프트웨어적으로 구현된 가상의 네트워크 입니다.

Private 프라이빗 네트워크. 즉 외부 네트워크와 격리된 사설 네트워크라는 뜻입니다. 외부 네트워크를 우리가 흔히 말하는 인터넷이라는 거대한 망이라고 생각해보겠습니다. 일단 그러면 사설 네트워크라는건 왜 필요한 걸까요 ?

→ 직관적으로 생각해보면, 일단 IPv4 로 표현할 수 있는 주소는 한계가 명확합니다. IPv4 주소 체계로는 간단히 계산해봤을 때 $2^{32}$개 정도의 IP를 할당할 수 있지만 이미 고갈된지 오래입니다. 이에 대한 해결방법으로 제시된 것이 특정 공간 내에서 특정 사용자들끼리만 이용하는 IP 할당 방법입니다.

→ 사설 IP는 보안상의 이유로도 사용됩니다. 공용 IP는 인터넷상에서 누구나 접근할 수 있지만, 사설 IP는 네트워크 외부에서는 접근이 불가능하기에 내부 리소스를 보호하는 데 유리합니다.

→ 주로 사설 IP 주소 대역에 대한 표준문서 RFC1918에 명시된 사설 IP 주소 대역을 이용합니다.

10.0.0.0 ~ 10.255.255.255 /8

172.16.0.0 ~ 172.31.255.255 /12

192.168.0.0 ~ 192.168.255.255 /16

---

이를 정리해보면 다음과 같습니다.

클라우드 내에서 인스턴스를 생성하면, 아무런 규칙이 없이 바로 생성되는 것이 아닙니다.

우리는 인스턴스를 생성해줄 때 위와 같이 VPC를 적어줬습니다.

즉, sopt-35-server 라는 VPC 위에서 인스턴스를 만들어주겠다. 라는 것을 명시적으로 정해준 것입니다.

그렇다면 sopt-35-server VPC로 타고 들어가보면 어떤 설정이 되어있을까용

---

VPC

CIDR 블록 부분을 눈여겨보면, 192.168.0.0/28 이라고 적혀있습니다.

즉 정리하면 sopt-35-server 라는 VPC는 192.168.0.0/28 라는 사설 네트워크 주소를 가지는 가상의 네트워크 라고 할 수 있겠습니다. 그림으로 그려보면 다음과 같습니다.

결국 우리가 VPC를 sopt-35-server 로 설정하고 인스턴스를 만든다면 최종 형상은 다음과 같을 것입니다.

물론 여기서 끝은 아닙니다. 우리는 서버 생성 시 VPC 뿐만 아니라 Subnet도 같이 설정해줬습니다. Subnet은 간단히 생각하면, 하나의 네트워크를 여러 개의 네트워크로 쪼개서 사용하는 것입니다.

예시로 하나의 sopt-35-server 를 4개의 네트워크로 쪼개고 싶다면 위와 같이 쪼개줄 수 있습니다. 당장 중요한 것은 아니므로 이 부분은 넘어가고, 우선은 sopt-35-server 서브넷이 가지고 있는 속성을 살펴보면 다음과 같습니다.

---

Subnet

중요하다고 생각하는 부분은 다음과 같았습니다 !

Subnet 이름

말 그대로 서브넷의 이름입니다. sopt-35-server 라고 되어있고, VPC 이름과 동일한 것을 확인할 수 있었습니다.

IP 주소 범위

sopt-35-server 이라는 VPC를 쪼갤때, 어떻게 쪼갤지 적혀있는 부분입니다. IP 주소 범위를 보면 VPC가 가지고 있는 IP 주소 범위와 동일한 것을 확인할 수 있습니다.

따라서, 따로 여러 개의 서브넷으로 나눠주지 않았고 VPC를 그대로 가져왔음을 확인할 수 있습니다.

VPC 이름

서브넷으로 나누고자 하는 VPC의 이름입니다. sopt-35-server 라 명시되어 있습니다.

즉, sopt-35-server 라는 VPC라는 네트워크에 대해 서브네팅을 해주겠다는 뜻입니다.

Network ACL

서브넷마다 적용되는 ACG 보안 규칙입니다.

Internet Gateway

public한 서브넷인지, private한 서브넷인지 명시해둔 부분입니다.

퍼블릭 서브넷 : 서브넷이 인터넷과 통신할 수 있음

프라이빗 서브넷 : 서브넷이 인터넷과 통신할 수 없음

위에 적은 자잘자잘한 설정들을 종합하였을 때, 우리가 인스턴스를 만들면 다음과 같은 형상이 될 것 같습니다.

우리는 sopt-35-server 이라는 이름의 VPC 위의 sopt-35-server 라는 이름의 서브넷 위에서 인스턴스를 생성합니다. 이 때 서브넷과 VPC가 사용하는 사설 네트워크 주소는 192.168.0.0/28 로 동일합니다.

---

다음으로 공부해본 부분은 공인 IP 와 비공인 IP 였습니다. (public IP & private IP)

하나의 인스턴스가 public IP와 private IP를 어떻게 동시에 가지는 것인지에 대해 명확히 알고있지 않아서.. 처음엔 많이 헷갈렸고, 열심히 공부해봤습니당.

private IP 부터 살펴보면 간단합니다. 인스턴스의 private IP 주소는 우리가 만든 VPC 네트워크 안에서 할당받을 수 있습니다. 직접 명시할 수도 있고, 임의로 배정받을 수도 있습니다.

sopt-35-server 의 네트워크 주소는 192.168.0.0/28 이므로 이 네트워크 안에서 인스턴스들이 할당받을 수 있는 IP 주소는 192.168.0.1 ~ 192.168.0.14 까지 총 14개 입니다. (네트워크 주소, broadcast 제외)

VPC 내에서 3개의 인스턴스를 생성하고 임의로 private IP를 할당받았다고 했을 때의 형상은 다음과 같습니당.

private IP를 할당받았더라도 아직 외부 인터넷과 통신이 가능한 것은 아닙니다.

private IP는 VPC 내부에서만 사용가능한 IP이기 때문에 내가 어떤 인스턴스의 private IP를 안다고 해서 외부에서 해당 인스턴스의 리소스를 바로 가져올 수 있지는 않습니다. 따라서 우리는 인스턴스에 public IP를 추가적으로 할당해줘야 합니다.

public IP 역시 간단합니당. 서버 생성 시 새로운 공인 IP 할당 옵션을 선택하게 되면, 인스턴스는 네이버 클라우드라는 클라우드 제공자가 가지고 있는 IP 주소 중 하나를 할당받습니다.

각각의 인스턴스에 할당된 public IP를 223.130.157.137 223.130.160.184 175.45.202.228 라고 했을 때, 그 형상은 다음과 같을 것 같습니다.

저는 여기서 궁금한 점이 생겼습니다.

여기까지 그려놓은 인프라 구조만 본다면 외부에서 223.130.157.137 라는 public IP 주소로 접근하러 했을 때 어떻게 접근할 수 있을까..?

위와 같은 구조에서는 외부로 가는 길목이 전혀 존재하지 않기 때문에 외부에서 인스턴스로 접근할 수도, 인스턴스에서 외부로 빠져나갈 수도 없습니다.

→ 인터넷 게이트웨이(IGW) 라는 외부와의 길목이 존재해야 인터넷과의 연결이 가능합니다 ! 사실은 위와 같은 인프라 구조에는 외부와 통신을 해주기 위한 인터넷 게이트웨이가 하나 숨어져 있던 것이었습니다.

인터넷 게이트웨이까지 추가한 형상은 위와 같습니다.

결론적으로.. 외부에서 VPC 내부의 인스턴스로 접근하려면 간단히 다음과 같은 수순을 거칩니다.

1. 외부 사용자는 인스턴스의 public IP 223.130.157.137 에 접근하여 리소스를 가져가고자 합니다.

2. 이 요청은 인터넷을 통해 여러 라우터를 걸쳐 클라우드 제공자인 네이버 클라우드의 네트워크로 들어옵니다.

3. 클라우드 제공자는 public IP 와 private IP 간의 매핑 정보를 가지고 있습니다.

   → 즉, 요청이 public IP 223.130.157.137 으로 들어오면, 클라우드 제공자의 네트워크 인프라에서 이를 자동으로 이에 매핑되는 private IP 192.168.0.7 로 변환하는 것입니다.

   → 이 과정에서 인터넷 게이트웨이를 통해 VPC 내부로 요청이 전달됩니다.

4. 인터넷 게이트웨이는 외부의 요청을 VPC 내부의 인스턴스로 연결해줍니다.

5. 이 과정이 반대로 이루어지며 요청에 대한 응답을 외부 사용자에게 다시 전달해줄 수 있습니다.

---

만약 하나의 VPC를 2개의 서브넷으로 서브네팅 했다면 ?

위의 인프라 구조에 약간의 디테일을 추가할 수 있을 것 같습니다.

게이트웨이를 통해 들어온 요청은 두 서브넷 중 어떤 서브넷으로 들어온 요청인지에 대해 판단이 필요합니다.

→ 따라서 라우터를 통한 적절한 라우팅이 필요할 것 같습니다.

결국 최종적인 형상은 위와 같을 것 같습니다 !

서브네팅의 방법론적인 부분이나 라우팅 테이블 같은 부분은 너무 깊게 가는거 같아서 추가적으로 적진 않았지만 추가적으로 충분히 고민해볼 부분인 것 같습니다.

---

노션으로 보면 조금 더 깔끔해요 !

https://everlasting-rodent-39b.notion.site/4-13f29a6254b080c8822cd43b920bdf16?pvs=4