인프라 구축 과정 이해하기
각 단계가 왜 필요한지, 어떤 목적을 가지고 있는지 이해하는 것이 중요
1. VPC(Virtual Private Cloud) 생성
왜 필요한가 ?
VPC는 AWS 클라우드 내에서 나만의 격리된 가상 네트워크 환경(논리적으로 격리된 가상 네트워크)이다.
실제 회사에 물리적인 데이터센터가 있다고 생각하면 이해하기 쉽다. 이것은 내 리소스들(서버, 데이터베이스 등)이 존재할 기본적인 네트워크 경계를 정의한다.
- 같은 VPC 내의 인스턴스들은 기본적으로 서로 통신할 수 있다. → 마치 회사 내부 네트워크처럼 같은VPC 내의 모든 컴퓨터들이 서로를 볼 수 있는 구조이다.
VPC를 생성하는 것은 마치 땅을 구매하고 그 주변에 울타리를 치는 것과 같다. 이 울타리 안에서만 나는 완전한 통제권을 가지게 된다. 다른 AWS 고객들의 리소스와 완전히 분리되어 있고, 나만이 정한 규칙에 따라서만 내부 및 외부와 통신할 수 있다.
VPC 생성 시 정의한 CIDR 블록(ex. 10.250.0.0/16)은 이 가상 네트워크에서 사용할 수 있는 IP 주소의 범위를 결정한다. 마치 나의 데이터센터가 가질 수 있는 주소의 총량이라고 생각하면 된다.
2. 서브넷 생성
왜 필요한가 ?
서브넷은 VPC를 더 작은 네트워크 세그먼트로 나누는 것이다.(VPC 내에서 IP 주소 범위를 나눈 더 작은 네트워크 단위) 마치 큰 건물을 여러 개의 방으로 나누는 것과 같다. 서브넷을 생성하는 주요 이유는
- 네트워크 격리와 보안: 다른 목적을 가진 리소스들을 분리하여 보안을 강화한다. 예를 들어, 웹 서버(NGINX)와 애플리케이션 서버(Tomcat)를 분리함으로써, 웹 서버가 해킹되더라도 애플리케이션 서버에 대한 직접적인 접근은 제한된다.
- 가용성 향상: 여러 가용 영역(2A, 2C)에 서브넷을 분산 배치함으로써 한 가용 영역에 문제가 생겨도 다른 가용 영역의 리소스는 계속 작동할 수 있다. 이는 마치 여러 도시에 사무실을 두어 한 도시에 정전이 발생해도 비즈니스가 중단되지 않도록 하는 것과 같다.
- 퍼블릭/프라이빗 구분: 일부 서버는 인터넷에 노출되어야 하지만(퍼블릭 서브넷), 다른 서버는 내부에서만 접근 가능해야 한다(프라이빗 서브넷).
내가 했던 구성에서는 Bastion과 NGINX 서버를 위한 퍼블릭 서브넷, Tomcat 서버를 위한 프라이빗 서브넷으로 나누었다. 이는 웹 서버는 인터넷에서 접근 가능하게 하고, 애플리케이션 서버는 직접적인 인터넷 접근으로부터 보호하기 위한 전형적인 설계이다.
실제 적용 예시
- AZ 2A에 있는 리소스:
- VEC-PRD-VPC-NGINX-PUB-2A (NGINX 서버)
- VEC-PRD-VPC-TOMCAT-PRI-2A (Tomcat 서버)
- VEC-PRD-VPC-BASTION-PUB-2A (Bastion 서버)
- AZ 2C에 있는 리소스:
- VEC-PRD-VPC-NGINX-PUB-2C (NGINX 서버)
- VEC-PRD-VPC-TOMCAT-PRI-2C (Tomcat 서버)
만약 AZ 2A에 대규모 정전이나 네트워크 장애가 발생한다면, 2A에 있는 모든 서버(NGINX, Tomcat, Bastion)는 작동이 중단될 것이다. 하지만 AZ 2C에 있는 NGINX와 Tomcat 서버는 계속 정상적으로 작동할 것.
로드 밸런서(VEC-NGINX-ALB)가 트래픽을 정상 작동 중인 AZ 2C의 서버들로만 라우팅하게 되어, 사용자는 서비스 중단을 최소한으로 경험하게 된다.
결국 서브넷의 주요 목적은
- 네트워크 분할 : 큰 네트워크를 관리하기 쉬운 작은 단위로 나눈다.
- 네트워크 특성 정의 : 서브넷은 퍼블릭(인터넷에 직접 연결 가능) 또는 프라이빗(인터넷에 직접 연결 불가)으로 구성될 수 있따.
인스턴스는 반드시 하나의 서브넷에 속해야 한다. 인스턴스는 자신이 속한 서브넷의 특성에 따라 외부와 통신한다.
예를 들어, 퍼블릭 서브넷에 있는 인스턴스는 인터넷과 직접 통신할 수 있지만, 프라이빗 서브넷에 있는 인스턴스는 NAT 게이트웨이와 같은 중간 장치를 통해서만 인터넷과 통신할 수 있다.
3. 인터넷 게이트웨이 생성 및 연결
왜 필요한가 ?
인터넷 게이트웨이(IGW)는 VPC와 인터넷 사이의 연결 통로이다. 이것이 없다면 내 VPC는 완전히 고립된 네트워크가 되어 인터넷과 전혀 통신할 수 없게 된다.
→ 인터넷 게이트웨이는 VPC 전체를 인터넷에 연결하는 관문
인터넷 게이트웨이는 마치 건물의 정문과 같다. 이 문을 통해 외부와 통신이 가능해진다. 퍼블릭 서브넷에 있는 서버(Bastion, NGINX)가 인터넷에 접근하거나, 사용자들이 인터넷을 통해 당신의 웹 서버에 접근하기 위해서는 이 게이트웨이가 필수적이다.
VPC와 인터넷 게이트웨이를 연결한다고 해서 VPC 내의 모든 인스턴스가 자동으로 인터넷에 연결되는 것은 아니다. 인스턴스가 인터넷과 통신하기 위해서는 3가지 조건이 필요하다.
- VPC에 인터넷 게이트웨이가 연결되어 있어야 한다.
- 인스턴스가 퍼블릭 서브넷에 있어야 한다.
- 인스턴스의 라우팅 테이블에 인터넷으로 향하는 트래픽(0.0.0.0/0)을 인터넷 게이트웨이로 보내는 규칙이 있어야 한다.
- 인스턴스에 퍼블릭 IP가 할당되어 있어야 한다.
이 모든 조건이 충족되어야 인스턴스가 인터넷과 통신할 수 있다.
4. 라우팅 테이블 구성
라우팅이란 무엇인가 ?
라우팅은 네트워크에서 데이터 패킷이 출발지에서 목적지까지 어떤 경로로 이동해야 하는지를 결정하는 과정. 이것은 마치 도시에서 한 장소에서 다른 장소로 가는 방법을 결정하는 것과 유사하다.
라우팅 테이블의 역할
라우팅 테이블은 네트워크 트래픽이 어디로 가야 하는지에 대한 지침서이다. 각 라우팅 테이블은 여러 개의 라우팅 규칙(라우트)으로 구성된다. 각 라우트는 두 가지 주요 정보를 포함한다.
- 목적지(Destination): 어떤 IP 주소로 가는 트래픽인지
- 타겟(Target): 그 트래픽을 어디로 보낼 것인지
IP 주소 범위 표기 : CIDR
IP 주소 범위를 표현할 때 CIDR(Classless Inter-Domain Routing) 표기법을 사용
예를 들어:
10.250.0.0/16: 10.250으로 시작하는 모든 IP 주소 (총 65,536개 주소)0.0.0.0/0: 모든 IP 주소 (인터넷 전체)
0.0.0.0/0은 "모든 IP 주소"를 의미하며, 이는 인터넷으로 가는 모든 트래픽을 의미한다. 이것은 "그 외 모든 목적지"에 대한 일종의 기본 경로(default route)이다.
라우팅 테이블 예시 설명
예를 들어, 퍼블릭 서브넷의 라우팅 테이블은
| 목적지(Destination | 타겟(Target) | 설명 |
|---|---|---|
| 10.250.0.0/16 | local | VPC 내부 트래픽은 VPC 내에서 처리 |
| 0.0.0.0/0 | igw-xxxxxx | 그 외 모든 트래픽(인터넷 트래픽)은 인터넷 게이트웨이로 전송 |
이 테이블이 의미하는 바는:
- "만약 목적지 IP가 10.250.x.x 형태라면(VPC 내부), 로컬 네트워크를 통해 전송하세요."
- "그 외 모든 IP 주소로 가는 트래픽은 인터넷 게이트웨이로 보내세요."
왜 필요한가 ?
라우팅 테이블은 네트워크 트래픽이 어디로 가야 하는지 결정하는 규칙들의 집합이다. 이는 마치 도로의 이정표와 같아서, 특정 목적지로 가려면 어떤 길을 택해야 하는지 알려준다.
→ 네트워크 트래픽의 길 안내자 역할. 쉽게 설명하자면, 특정 목적지로 가는 패킷이 어떤 경로로 이동해야 하는지 결정하는 규칙 집합이다.
예를 들어,
- VPC 내부 트래픽(10.250.0.0/16): VPC 내부에서 처리
- 인터넷 트래픽(0.0.0.0/0): 인터넷 게이트웨이로 전송
각 서브넷은 하나의 라우팅 테이블과 연결된다. 이 라우팅 테이블이 해당 서브넷의 트래픽이 어디로 가야 하는지 결정한다.. 퍼블릭 서브넷은 인터넷 게이트웨이로 가는 경로가 있는 라우팅 테이블과 연결되고, 프라이빗 서브넷은 NAT 게이트웨이로 가는 경로가 있는 라우팅 테이블과 연결된다.
내 구성에서는 두 종류의 라우팅 테이블을 만들어봤다.
- 퍼블릭 라우팅 테이블(VEC-PRD-RT-PUB): 인터넷으로 가는 트래픽(0.0.0.0/0)을 인터넷 게이트웨이로 보낸다. 이를 통해 퍼블릭 서브넷의 서버들이 인터넷과 통신할 수 있다.
- 프라이빗 라우팅 테이블(VEC-PRD-RT-PRI): 인터넷으로 가는 트래픽을 NAT 게이트웨이로 보낸다. 이렇게 하면 프라이빗 서브넷의 서버들이 인터넷에 접근할 수 있지만, 외부에서는 이 서버들에 직접 접근할 수 없다.
만약 특정 목적지로 가는 경로가 라우팅 테이블에 정의되어 있지 않다면, 그 목적지로의 트래픽은 차단된다. → 이것을 네트워크가 열려있지 않다라고 표현할 수 있다.
- 인터넷 접근이 불가능한 경우:
- 만약 프라이빗 서브넷의 라우팅 테이블에 인터넷 경로(0.0.0.0/0 → NAT 게이트웨이 또는 인터넷 게이트웨이)가 없다면, 해당 서브넷의 인스턴스는 인터넷에 접근할 수 없다.
- 특정 VPC 피어링 접근이 불가능한 경우:
- 다른 VPC와 피어링 연결을 했더라도, 라우팅 테이블에 해당 VPC의 CIDR 범위를 향한 경로가 없다면 통신이 불가능.
5. 보안그룹 생성
왜 필요한가 ?
보안 그룹은 EC2 인스턴스 수준의 가상 방화벽. 이는 인스턴스로 들어오고 나가는 트래픽을 제어한다. 보안 그룹은 마치 각 서버 주변의 보안 요원과 같아서, 누가 서버에 접근할 수 있는지, 어떤 종류의 통신이 허용되는지 결정한다.
→ 특정 포트와 프로토콜을 통한 트래픽만 허용한다.
예를 들어, 웹 서버에는 HTTP(80), HTTPS(443) 포트를 열어두고, SSH 접속을 위해 22번 포트를 열어둘 수 있다.
내 구성에서는 여러 서버 역할에 맞게 여러 보안 그룹을 만들었다.
- Bastion 보안 그룹: SSH(22), HTTP(80), HTTPS(443) 포트를 열어 관리자가 원격으로 접속할 수 있게 합니다.
- NGINX 보안 그룹: 웹 트래픽(80, 443)과 관리를 위한 SSH(22)를 허용합니다.
- Tomcat 보안 그룹: 웹 트래픽(80, 443)과 Tomcat 애플리케이션 트래픽(8080)을 허용합니다.
각 서버 유형에 맞는 최소한의 필요한 포트만 열어둠으로써 보안을 강화하는 것이다.→ “최소 권한의 원칙”
6. EC2 인스턴스 생성
EC2(Elastic Compute Cloud) 인스턴스는 실제로 애플리케이션을 실행하는 가상 서버이다. 지금까지 구축한 모든 네트워크 인프라는 이 서버들이 안전하고 효율적으로 작동할 환경을 만들기 위한 것이었다.
- Bastion 서버: 관리자가 프라이빗 네트워크에 안전하게 접근할 수 있는 "징검다리" 역할을 한다.
- NGINX 서버: 웹 서버로서 사용자의 요청을 받아 적절한 애플리케이션 서버로 전달한다.
- Tomcat 서버: 애플리케이션 서버로서 실제 비즈니스 로직을 처리한다.
이 서버들은 각각의 역할에 맞는 서브넷에 위치하고, 적절한 보안 그룹을 적용받아 안전하게 통신할 수 있다.
패킷의 여정 : 네트워크 통신의 전체 과정
네트워크 패킷이 목적지에 도달한 후에 어떻게 처리되는가 ?
라우팅 추가 설명 : Tomcat 서버로 라우팅된 패킷의 경우
NGINX 서버(10.250.1.240)에서 Tomcat 서버(10.250.2.240)로 패킷이 전송되는 과정과 그 이후의 일을 살펴보자.
- 패킷 생성: NGINX 서버가 HTTP 요청 패킷을 생성합니다. 이 패킷에는 출발지(10.250.1.240)와 목적지(10.250.2.240) 정보가 포함됩니다.
- 라우팅 결정: 패킷이 NGINX 서버의 네트워크 인터페이스를 떠나면, AWS 네트워크 인프라는 라우팅 테이블을 확인합니다. 목적지가 10.250.0.0/16 범위에 있으므로 "local" 라우팅이 적용됩니다.
- VPC 내부 전송: AWS 네트워크 인프라는 패킷을 VPC 내부 네트워크를 통해 10.250.2.240으로 보냅니다.
- 패킷 도착: 패킷이 Tomcat 서버에 도착합니다.
- 보안 그룹 확인: Tomcat 서버에 연결된 보안 그룹이 해당 트래픽(예: 포트 8080으로 들어오는 HTTP 트래픽)을 허용하는지 확인합니다.
- 패킷 수신 및 처리: 보안 그룹이 트래픽을 허용하면, Tomcat 서버는 패킷을 수신하고 처리합니다. 이는 일반적으로 다음과 같은 단계를 포함합니다
- 패킷 헤더 검사
- TCP 연결 상태 확인
- 애플리케이션 계층으로 데이터 전달
- Tomcat 애플리케이션 서버가 HTTP 요청 처리
- 응답 생성
- 응답 전송: Tomcat 서버는 응답 패킷을 생성하여 NGINX 서버로 돌려보냅니다. 이 과정에서도 동일한 라우팅 메커니즘이 적용됩니다.
인터넷 게이트웨이로 라우팅된 패킷의 경우
NGINX 서버(10.250.1.240)에서 인터넷의 웹 서버(예: google.com의 142.250.xxx.xxx)로 패킷이 전송되는 과정을 살펴보자.
- 패킷 생성: NGINX 서버가 HTTP 요청 패킷을 생성합니다. 이 패킷에는 출발지(10.250.1.240)와 목적지(142.250.xxx.xxx) 정보가 포함됩니다.
- 라우팅 결정: 패킷이 NGINX 서버의 네트워크 인터페이스를 떠나면, AWS 네트워크 인프라는 라우팅 테이블을 확인합니다. 목적지가 10.250.0.0/16 범위 밖이므로 "0.0.0.0/0" 규칙이 적용되어 인터넷 게이트웨이로 라우팅됩니다.
- 인터넷 게이트웨이 처리: 인터넷 게이트웨이는 패킷을 받아 중요한 변환 작업을 수행합니다:
- 프라이빗 IP(10.250.1.240)를 퍼블릭 IP(탄력적 IP 또는 자동 할당된 퍼블릭 IP)로 변환(NAT 기능)
- 패킷 헤더 업데이트
- 패킷의 무결성 검사
- 인터넷으로 전송: 변환된 패킷은 AWS 네트워크를 떠나 인터넷 상의 여러 라우터를 거쳐 목적지 서버(142.250.xxx.xxx)로 전송됩니다.
- 목적지 서버 처리: 구글 서버는 패킷을 수신하고 HTTP 요청을 처리한 후 응답을 생성합니다.
- 응답 경로:
- 구글 서버는 응답 패킷을 NGINX 서버의 퍼블릭 IP로 보냅니다.
- 이 패킷은 인터넷을 통해 AWS 네트워크의 인터넷 게이트웨이로 돌아옵니다.
- 인터넷 게이트웨이는 목적지 IP를 다시 프라이빗 IP(10.250.1.240)로 변환합니다.
- 변환된 패킷은 VPC 내부 라우팅을 통해 NGINX 서버로 전달됩니다.
- 응답 수신 및 처리: NGINX 서버는 응답 패킷을 수신하고 처리합니다.
중요한 개념 : 패킷 저장이 아닌 전달
핵심적으로 이해해야 할 점은 인터넷 게이트웨이나 라우터는 패킷을 "저장"하지 않는다는 것. 이들은 "저장-전달" 방식으로 작동한다.
- 패킷을 아주 짧은 시간 동안 버퍼에 임시 보관합니다(밀리초 단위).
- 패킷을 어디로 보낼지 결정합니다(라우팅 결정).
- 필요한 변환을 수행한다(NAT 등).
- 즉시 다음 목적지로 전달
