클라우드 속 격리된 네트워크
퍼블릭 클라우드는 수많은 사용자가 같은 물리 인프라를 공유합니다. 그렇다면 내 서버와 옆 사람의 서버가 한데 섞이는 걸까요. 그렇지 않습니다. VPC(Virtual Private Cloud)는 그 공유 인프라 위에서 각 사용자가 외부와 논리적으로 분리된 자기만의 사설 네트워크 공간을 갖도록 해줍니다.
물리적으로는 자원을 나눠 쓰지만, 논리적으로는 마치 독립된 데이터센터를 통째로 임대한 것처럼 동작합니다. 사용할 IP 대역을 직접 정하고, 내부를 여러 구역으로 나누고, 구역마다 드나드는 트래픽 규칙을 세울 수 있습니다. 다른 사용자의 트래픽은 내 VPC 안으로 들어오지 못하고, 내 트래픽도 밖으로 새지 않습니다. 클라우드의 유연함과 자체 데이터센터의 통제력을 동시에 얻는 구조입니다.
VPC의 기본 구성 요소
VPC를 설계한다는 것은 결국 몇 가지 구성 요소를 어떻게 배치하느냐의 문제입니다. 큰 그림에서 작은 단위로 좁혀가며 짜는 것이 정석입니다.
IP 대역과 서브넷
VPC를 만들 때 가장 먼저 전체 IP 대역(CIDR 블록)을 정합니다. 보통 사설 대역에서 고르며, 이 큰 대역을 다시 여러 서브넷으로 쪼개 용도별로 배치합니다. 이때 대역을 너무 좁게 잡으면 나중에 자원을 늘릴 때 주소가 부족해 곤란해지므로, 처음부터 넉넉한 여유를 두고 설계하는 것이 중요합니다. 한번 정한 대역을 나중에 바꾸기는 매우 번거롭기 때문입니다.
퍼블릭 서브넷과 프라이빗 서브넷
모든 자원을 인터넷에 노출할 필요는 없습니다. 웹 서버처럼 외부와 직접 통신해야 하는 자원은 퍼블릭 서브넷에 두고, 데이터베이스처럼 외부에 드러나면 안 되는 자원은 프라이빗 서브넷에 둡니다. 이렇게 노출이 필요한 것과 숨겨야 할 것을 처음부터 분리하는 것이 보안 설계의 출발점입니다. 데이터베이스가 인터넷에서 직접 보이지 않으면, 공격자가 노릴 수 있는 표면 자체가 줄어듭니다.
트래픽이 드나드는 길
서브넷을 나눴다면 각 서브넷이 외부와 어떻게 연결되는지를 정해야 합니다. 라우팅 테이블이 그 경로를 결정하며, 어떤 게이트웨이를 두느냐에 따라 통신의 방향이 달라집니다.
인터넷 게이트웨이
퍼블릭 서브넷이 인터넷과 양방향으로 통신할 수 있게 해주는 관문입니다. 라우팅 테이블에 이 게이트웨이로 향하는 경로가 있어야 외부에서 들어오고 내부에서 나가는 통신이 가능합니다. 외부에 서비스를 제공하는 자원이 이 길을 통해 사용자와 만납니다.
NAT 게이트웨이
프라이빗 서브넷의 자원이 밖으로 나가는 통신은 필요하지만 외부에서 먼저 들어오는 것은 막고 싶을 때 씁니다. 예를 들어 데이터베이스 서버가 보안 업데이트를 받거나 외부 API를 호출해야 할 수는 있지만, 외부에서 그 서버로 직접 접속하는 길은 닫아두어야 합니다. NAT 게이트웨이는 나가는 통신만 허용하고 들어오는 직접 접속은 차단해, 이 비대칭을 구현합니다.
경계를 지키는 두 겹의 통제
VPC 안에서 트래픽을 통제하는 장치는 보통 두 층으로 나뉩니다. 하나는 서브넷 단위로 적용되는 네트워크 ACL이고, 다른 하나는 개별 자원 단위로 적용되는 보안 그룹입니다.
네트워크 ACL은 서브넷이라는 넓은 경계에 그물을 쳐서, 그 구역을 드나드는 트래픽을 큰 틀에서 거릅니다. 보안 그룹은 서버 한 대 한 대에 붙어, 그 자원이 받아들이고 내보낼 트래픽을 세밀하게 규정합니다. 넓은 거름망과 촘촘한 거름망을 겹쳐 쓰는 셈이라, 한 층의 규칙이 느슨해도 다른 층이 받쳐줍니다. 이 다층 통제의 작동 원리는 방화벽과 IDS/IPS와 같은 맥락입니다.
가용 영역에 걸친 설계
견고한 VPC 설계는 한 물리적 위치에 모든 것을 몰아넣지 않습니다. 클라우드는 보통 같은 지역 안에서도 전력과 네트워크가 분리된 여러 가용 영역을 제공하는데, 서브넷을 이 영역들에 나눠 배치하면 한 영역에 장애가 나도 다른 영역의 자원이 서비스를 이어갑니다.
예를 들어 같은 역할의 서버들을 두 개 이상의 영역에 나눠 두고 그 앞에 분산 장치를 두면, 한 영역 전체가 멈춰도 나머지 영역이 트래픽을 받아냅니다. 단일 지점에 의존하지 않는다는 원칙이 서브넷 배치 단계에서부터 적용되는 셈입니다. 이 영역 분리를 처음부터 고려해 대역과 서브넷을 나눠두는 것이 안정적인 설계의 기본입니다.
VPC를 서로 잇는 방법
규모가 커지면 VPC 하나로 끝나지 않습니다. 환경별로, 팀별로, 또는 리전별로 여러 VPC를 두고 이들을 연결해야 하는 상황이 생깁니다. 이때 가장 기본이 되는 것이 두 VPC를 일대일로 잇는 피어링입니다. 두 네트워크가 사설 주소로 직접 통신하게 해주지만, VPC 수가 늘면 연결 수가 급격히 많아진다는 한계가 있습니다.
그래서 VPC가 많아지면 중앙에 허브를 두고 모든 VPC를 그 허브에 연결하는 방식으로 넘어갑니다. 새 VPC를 추가할 때 허브에만 붙이면 되므로 관리가 단순해집니다. 어느 방식이든 전제 조건은 같습니다. 연결하려는 VPC들의 IP 대역이 겹치지 않아야 한다는 것입니다. 대역이 충돌하면 아무리 연결해도 트래픽이 올바른 곳을 찾아가지 못합니다. 결국 처음의 대역 설계가 나중의 확장 가능성까지 좌우하는 셈입니다.
설계할 때 흔히 놓치는 것
VPC 설계에서 가장 자주 발생하는 사고는 IP 대역이 다른 네트워크와 겹치는 경우입니다. 사내망이나 다른 VPC와 같은 대역을 써버리면, 나중에 둘을 연결하려 할 때 같은 주소가 양쪽에 존재해 어디로 보내야 할지 판단할 수 없게 됩니다. 그 결과 통신이 끊기거나 엉뚱한 곳으로 향합니다.
이 문제는 일단 운영에 들어간 뒤에는 해결이 매우 어렵습니다. 이미 배정된 주소를 모두 바꿔야 하기 때문입니다. 그래서 처음부터 전사적으로 대역을 조율해, 앞으로 연결할 가능성이 있는 모든 네트워크가 서로 겹치지 않도록 배정하는 것이 중요합니다. 사설 IP 대역의 표준 정의는 IETF RFC 1918 문서에서 확인할 수 있습니다.