[Cloud 인프라 아키텍트 방법론] 랜딩존(VPC, VNET 구성)

- VPC, VNET 구성 원칙

 Onpremise에서 VPC 및 VNET은 백본이라고도 볼 수 있다. 명확한 의미에서 백본은 아니지만, VPC와 VNET 기준으로 망을 만들 수 도 있고, 망간의 구분 기준을 만들 수도 있다. (VPC는 AWS, VNET은 Azure용도이고 역할은 거의 동일하다. VPC로 통일하도록 하겠다)

 예를 들면 MES와 관련된 서비스는 A라는 VPC를 통해 만들고, MIS와 관련된 서비스를 B라는 VPC를 만들어서 나눌 수 도 있다. 물론 MES, MIS정도의 규모라면 네트워크 기준이 아닌 구독 기준으로 나누는 것이 효율적일 수 있다. 왜냐하면 비용적으로 또는 보안적으로 기능을 나누는 것이 유리하기 때문이다. VPC를 나누는  원칙을 몇 가지 정하자면 아래와 같다.

 (1) 개발/품질/운영간에는 VPC을 나누는 것이 좋다. 서로 다른 영역에 있어야, 인적 장애도 방지할 수 있고, 보안관리에도 용이하다.

 (2) 당연한 이야기지만 서로 다른 업무간에는 NW을 나누는 것이 좋다. 물론 너무 많이 나눈다면, 관리측면에서 많은 비용이 소모된다. 우선 업무별 범주를 크게 나누어 보고 해당 범주 안에서 VPC를 나누는 것이 좋다.

 (3) 특정한 기능에서 IP대역을 많이 사용한다면 나누는 것이 좋다. 특정 IP를 많이 사용한다면 한쪽의 VPC으로 몰아서 별도로 관리해야 IP관리 및 사용 효율성 차원에서 좋다.

 

- 네트워크 관계 모델 Hub & Spoke

 VPC관의 관계를 정의할 때, 일반적으로 쓰이는 모델 몇가지가 있다. 그 중 가장 많이 사용되는 아키텍처는 Hub & Spoke이다. 물론 VPC을 리니어 하게 연결하여 관계를 정의할 수 있다. 다만 그렇게 되면 수많은 피어링이 필요하게 되어 불필요한 네트워크 비용이 소모된다.

 

 1. Hub & Spoke 모델이란?

  Hub & Spoke모델은 Shared Model이라고도 불린다. VPC간에 피어링을 하는 대신에, Hub VPC를 하나 두고 그 아래 여러 개의 Spoke VPC를 피어링 하여 통신하는 형태이다. (Peering을 해도 되고, Hub VPC를 Transit Gate로 두어 세팅하는 방법도 가능하다.) 보통은 A, B, C의 VPC를 운영/개발/품질로 나누어서 세팅하기도 하고, VPC가 2개뿐이라면 Hub VPC를 운영으로 두어 두 개의 VPC로도 세팅이 가능하다.

 

 2. Hub & Spoke 모델의 장점

 1) 네트워크의 독립성 : 한 VPC의 서비스가 다른 VPC에 영향을 받지 않는다. 하나의 VPC이슈가 다른 VPC

                                     로 전이되지 않는다.

 2) 네트워크 모듈화 : 네트워크가 기능적으로 분리 되어있기 때문에 애플리케이션상에서 네트워크의 변경이

                                  필요할 경우 다른 VPC의 영향을 미치지 않고 변경이 가능하다. 

 3) 네트워크 확장성 : VPC를 하나 더 추가할 경우, 추가 피어링이 필요없이 Hub에만 연결하면 바로 확장이

                                  가능하다.

 4) 네트워크 보안 : 운영, 개발 환경을 논리적으로 분리가 가능하다. 예를들면 개발 VPC만 인터넷에 오픈하여,

                             검증하고, 운영존은 인터넷과 분리하여 배포가 가능하다.