[천재교육] 프로젝트 기반 빅데이터 서비스 개발자 양성 과정 9기
학습일 : 2024.12.11
📕 프로젝트 작업 내역
- 네트워크 란?
- AWS에서의 네트워크 개념
- AWS 인프라 간 VPC 연결 필요?
- VPC 내에서도 인터넷에 접근할 수 있는 이유
📗 수행 결과
1. 네트워크 란?
컴퓨터와 다른 장치들이 서로 연결되어 데이터를 주고받는 시스템
즉, 정보를 주고받는 길
1) 정의
- 컴퓨터와 다른 장치들이 서로 연결되어 데이터를 주고받는 시스템. 즉, 정보를 주고받는 길
- 예시로 이해하기
- 집에서 사용하는 Wi-Fi는 네트워크의 한 종류
- Wi-Fi를 통해 스마트폰, 노트북, TV가 인터넷에 연결되고 서로데이터를 주고받음
2) 네트워크의 구성 요소
- 장치(Device): 컴퓨터, 스마트폰, 서버 등 데이터를 주고받는 주체
- 라우터(Router): 데이터를 전달하고 경로를 정하는 장치. 집의 Wi-Fi 라우터
- 스위치(Switch): 네트워크 내부에서 장치들을 연결
- 인터넷(Internet): 전 세계 네트워크를 연결한 거대한 네트워크
3) 네트워크의 기본 작동 원리
- 데이터를 주고받을 때 주소가 필요. 이 주소를 IP 주소라고 부름
- ex: 192.168.1.1 (집의 라우터가 장치들에게 부여하는 주소)
- 데이터를 주고받는 규칙을 프로토콜(Protocol)이라고 함
- ex: HTTP(웹사이트), FTP(파일 정송), SMTP(이메일 전송) 등
4) 네트워크의 종류
- LAN (Local Area Network)
- 작은 지역에 제한된 네트워크
- ex: 집, 회사 등의 Wi-Fi 네트워크
- WAN (Wide Area Network)
- 전 세계적으로 연결된 네트워크
- ex: 인터넷
- VPC (Virtual Private Cloud)
- AWS 같은 클라우드 서비스에서 제공하는 네트워크로, 사용자가 직접 네트워크를 구성할 수 있음
- 외부와 격리된 네트워크를 만들어 데이터를 안전하게 관리
5) 네트워크가 왜 중요한가?
- 데이터 공유
- 네트워크가 있어야 여러 장치가 데이터를 주고받을 수 있음
- ex: 이메일, 웹 사이트 접속, 파일 다운로드
- 보안
- 데이터를 안전하게 주고받으려면 네트워크 보안이 중요
- ex: AWS에서 VPC를 사용해 네트워크를 격리하면 외부 공격으로부터 보호할 수 있음
- 서비스 제공
- 서버가 네트워크를 통해 웹사이트, API 등을 사용자에게 제공
- ex: 네이버, 구글 같은 서비스도 네트워크를 통해 운영됨
6) AWS에서 네트워크(VPC)의 역할
- AWS에서는 VPC를 통해 네트워크를 구성하고 보안을 강화할 수 있음
- VPC 안에 서버, 데이터베이스, Lambda 등을 배치하여 외부와 격리된 환경을 만듦
- 이렇게 하면 인터넷에서 직접 접근할 수 없으므로 보안이 강화됨
VPC 설정 시 | VPC 미설정 시 | |
네트워크 격리 | 내부 네트워크 격리 (보안 강화) | 퍼블릭 네트워크 사용 (보안 리스크 증가) |
S3 접근 | VPC 엔드포인트로 안전한 접근 | 인터넷을 통해 접근 |
인터넷 접근 | 기본적으로 제한 (NAT 게이트웨이 필요) | 자동 활성화 (모든 리소스 인터넷 접근 가능) |
리소스 간 통신 | VPC 내부에서만 통신 가능 (보안성 높음) | 인터넷을 통해 통신 가능 |
보안 | 데이터베이스와 민감 리소스 보호 | 퍼블릭 네트워크에서 접근 가능 위험 |
비용 | 내부 네트워크 통신으로 비용 절감 | 외부 트래픽 비용 발생 가능 |
7) 요약
- 네트워크는 데이터를 주고받는 길
- 네트워크를 통해 장치들이 연결되고, 인터넷 같은 큰 네트워크로 확장됨
- AWS에서는 VPC를 사용해 네트워크를 격리하고, 데이터를 안전하게 관리
2. AWS 에서의 네트워크 개념
1) 서브넷 (Subnet)
(1) 정의
- 서브넷은 VPC 내부에서 네트워크를 더 작게 나눈 네트워크 구역
- VPC 전체는 하나의 큰 네트워크인데, 이를 서브넷을 나누어 리소스를 관리하고 격리할 수 있음
(2) 서브넷의 주요 특징
- IP 주소 범위
- 서브넷은 VPC의 IP 주소 대역(Classless Inter-Domain Routing, CIDR) 중 일부를 할당받아 사용할 수 있는 IP 주소 블록임
- 퍼블릭 서브넷 vs 프라이빗 서브넷
- 서브넷을 퍼블릭 또는 프라이빗으로 구분하여 네트워크 트래픽의 흐름을 제어할 수 있음
- 가용 영역(AZ)과 연결
- 서브넷은 특정 가용 영역(Availability Zone)에 배치됨
- ex: ap-northeast-2a 같은 AZ에서만 사용 가능
(3) 서브넷의 역할
- EC2, Lambda, RDS(데이터베이스) 등 AWS 리소스가 위치하는 곳
- 리소스 간 네트워크 통신의 범위를 제한하고, 보안을 강화할 수 있음
2) 서브넷 리소스
(1) 서브넷에 배치되는 리소스란?
서브넷에 배치되는 리소스는 AWS의 컴퓨팅 및 데이터 관련 서비스임
- ex:
- EC2 인스턴스: VPC 내의 특정 서브넷에 배치됨
- RDS(데이터베이스): 보통 프라이빗 서브넷에 배치되어 외부 접근을 차단
- Lambda: VPC에 연결된 경우 특정 서브넷에 할당됨
- 로드 밸런서(ALB/NLB): 퍼블릭 서브넷에 배치되어 외부 트래픽을 처리
(2) 서브넷 리소스를 설정하는 이유
- 리소스를 퍼블릭 서브넷에 두면 인터넷과 직접 통신 가능
- 리소스를 프라이빗 서브넷에 두면 외부로부터 격리되어 보안 강화
3) 게이트웨이 (Gateway)
(1) 정의
- 게이트웨이(Gateway)는 네트워크 트래픽의 출입구 역할을 하는 네트워크 컴포넌트
- VPC 안팎으로 트래픽을 전달하는 데 사용
(2) AWS에서 사용되는 주요 게이트웨이 유형
- 인터넷 게이트웨이(Internet Gateway, IGW)
- VPC를 외부 인터넷과 연결
- 퍼블릭 서브넷에서만 사용 가능
- EC2 인스턴스가 인터넷에 접속하거나 외부에서 접근할 수 있게 해줌
- NAT 게이트웨이(NAT Gateway)
- 프라이빗 서브넷의 리소스가 인터넷에 접속할 수 있게 해줌
- 프라이빗 서브넷의 보안을 유지하면서 외부로 나가는 트래픽만 허용
- 외부에서 프라이빗 서브넷으로는 직접 접근할 수 없음
- VPC 엔드포인트(VPC Endpoint)
- VPC 내부에서 AWS 서비스(S3, DynamoDB 등)에 연결할 때 사용
- 인터넷을 통하지 않고, AWS 네트워크를 통해 안전하게 통신
4) 퍼블릭 서브넷 vs 프라이빗 서브넷
(1) 퍼블릭 서브넷
- 인터넷 게이트웨이(IGW)와 연결
- 인스턴스에 퍼블릭 IP를 할당해 외부에서 접근 가능
- 주로 외부 사용자와 통신해야 하는 리소스(ex: 웹 서버, 로드 밸런서) 배치
(2) 프라이빗 서브넷
- 인터넷 게이트웨이 없이 NAT 게이트웨이를 사용해 외부로 나가는 트래픽만 허용
- 외부 인터넷에서 접근 불가
- 보안이 중요한 데이터베이스나 내부 서비스 배치
5) 예시로 이해하기
[장고 웹 서버와 데이터베이스]
- 장고 웹 서버
- 퍼블릭 서브넷에 배치
- 인터넷 게이트웨이를 통해 외부 사용자가 웹 서버에 접근 가능
- 데이터베이스
- 프라이빗 서브넷에 배치
- NAT 게이트웨이를 통해 데이터베이스가 외부 업데이트를 받을 수 있지만, 외부에서 직접 접근은 불가
6) CIDR (Classless Inter-Domain Routing)
네트워크에서 IP 주소를 효율적으로 할당하고 라우팅을 관리하기 위한 표준 방식
(1) CIDR의 역할
- IP 주소 블록 표현
- CIDR은 네트워크 주소를 "주소/프리픽스 길이" 형태로 표현
- ex: 192.168.1.0/24 → IP 주소와 네트워크 범위를 나타냄
- 네트워크 범위 설정
- /24는 서브넷 마스크를 의미하며, 네트워크에 사용 가능한 IP 주소의 범위를 정의
- 더 작은 네트워크로 세분화하거나, 더 큰 네트워크로 통합할 수 있음
(2) CIDR 표기법
CIDR 표기법은 다음 두 부분으로 구성
- 네트워크 주소
- IP 주소를 기준으로 네트워크를 나타냄 (ex: 192.168.1.0)
- 프리픽스 길이
- 슬래시(/) 뒤의 숫자는 네트워크 부분을 나타내는 비트 수
- ex: /24 → 앞 24비트가 네트워크 부분, 나머지 8비트가 호스트 부분
(3) CIDR 예시
- 192.168.1.0/24
- 네트워크 범위: 192.168.1.0 ~ 192.168.1.255 (총 256개 IP)
- 네트워크 크기: 254개의 사용 가능한 호스트(2개는 네트워크 및 브로드캐스트용)
- 10.0.0.0/16
- 네트워크 범위: 10.0.0.0 ~ 10.0.255.255 (총 65,536개 IP)
- 대규모 네트워크에 적합
- 172.16.0.0/12
- 네트워크 범위: 172.16.0.0 ~ 172.31.255.255 (총 1,048,576개 IP)
- 내부 네트워크에서 자주 사용
(4) CIDR의 주요 장점
- IP 주소의 효율적 사용
- 네트워크를 필요한 크기로 세분화하여 IP 낭비를 줄임
- ex: /28 → 16개의 IP만 사용 가능한 소규모 네트워크 생성
- 라우팅 간소화
- 여러 네트워크를 하나의 CIDR 블록으로 통합하여 라우팅 테이블을 간단하게 유지
- 유연성
- 기존의 클래스 기반 네트워크(A, B, C 클래스)를 대체하여 더 유연한 네트워크 설계 가능
(5) CIDR과 AWS
AWS에서 VPC와 서브넷을 생성할 때 CIDR 범위를 지정해야 함
- VPC CIDR
- VPC 전체의 네트워크 범위를 정의
- ex: 10.0.0.0/16
- 서브넷 CIDR
- VPC 안에서 서브넷별 네트워크 범위를 지정
- ex: 10.0.1.0/24, 10.0.2.0/24
7) 가용 영역 (Availability Zone, AZ)
(1) 정의
- 가용 영역(AZ)은 AWS 데이터 센터의 논리적 구분*을 나타냄
- 높은 가용성과 내구성을 제공하기 위해 설계된 AWS 리소스 배치 개념
* AWS는 사용자가 가용 영역을 특정 이름(a, b, c)으로 논리적으로 구분할 수 있도록 제공. 동일한 리전 내에서도 사용자마다 ap-northeast-2a가 다른 물리적 AZ일 수 있음. 이는 AWS가 물리적 데이터 센터의 세부 정보를 공개하지 않기 때문
(2) 가용 영역의 특징
- 물리적 데이터 센터 그룹
- 가용 영역은 AWS 리전(Region) 내의 물리적으로 독립된 데이터 센터 그룹
- 동일 리전의 다른 가용 영역과 지리적으로 분리되어 재해 발생 시에도 영향을 최소화
- 네트워크 연결
- 각 가용 영역은 다른 AZ와 고속 저지연 네트워크로 연결되어 있음
- 동일 리전 내의 AZ 간 통신은 AWS 내부 네트워크를 통해 빠르고 안정적으로 이루어짐
- 리소스 배치
- 하나의 리전 내 여러 가용 영역에 리소스를 배치하면 재해나 장애 시 서비스 중단을 최소화할 수 있음
- AWS 서비스와 AZ
- EC2, RDS, EBS 등 대부분의 AWS 리소스는 특정 AZ에 배치됨
- S3는 리전 단위로 관리되므로 AZ를 직접적으로 선택하지 않아도 됨
(3) 가용 영역의 예
AWS는 전 세계 여러 리전에 AZ를 제공함. 각 리전은 고유한 가용 영역(AZ)을 포함함
- ex: 서울 리전(ap-northeast-2)
- 가용 영역: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c
(4) AWS 서비스에서 가용 영역 활용
- EC2
- EC2 인스턴스는 특정 AZ에 배치됨
- 동일 리전 내 다른 AZ 간의 네트워크 연결을 통해 서비스 확장 가능
- RDS (다중 AZ 배포)
- RDS는 자동으로 하나의 AZ에 기본 인스턴스를 생성하고, 다른 AZ에 복제본을 생성하여 고가용성을 보장
- EBS (볼륨 스토리지)
- EBS는 AZ 단위로 설계되므로, EC2 인스턴스와 동일한 AZ에 배치해야 성능 저하가 없음
- ELB (Elastic Load Balancer)
- 여러 AZ에 분산되어 트래픽을 자동으로 분배
- 고가용성과 부하 분산을 제공
8) 요약
- 서브넷
- VPC 내 네트워크를 더 작은 단위로 나눈 구역
- 퍼블릭/프라이빗 서브넷으로 나뉘며, 리소스가 위치
- 서브넷 리소스
- EC2, RDS, Lambda 등이 서브넷에 배치되는 리소스
- 게이트웨이
- 인터넷 게이트웨이: 외부 인터넷 연결
- NAT 게이트웨이: 프라이빗 서브넷에서 외부로 나가는 트래픽 허용
3. AWS 인프라 간 VPC 연결 필요?
AWS 서비스 간의 연결에 있어서, S3, EC2, Lambda, Step Functions 등이 반드시 같은 VPC 내에 있어야만 통신이 가능한 것은 아님. 서비스의 특성과 네트워크 구조에 따라 연결 방식이 달라지기 때문
1) AWS 서비스 간 VPC 연결 필요 여부
(1) EC2
- VPC 필수
- EC2는 반드시 VPC 내에서 실행됨. 모든 EC2 인스턴스는 VPC에 소속되며, 퍼블릭 또는 프라이빗 서브넷에 위치하게 됨
- VPC 내 리소스 연결
- EC2가 다른 VPC 리소스(예: Lambda, 데이터베이스)와 연결되려면 같은 VPC에 있거나 VPC 피어링 또는 AWS PrivateLink를 통해 연결해야 함
(2) Lambda
- VPC 선택 가능
- Lambda는 기본적으로 AWS 관리 네트워크에서 실행되므로, VPC에 속하지 않아도 사용 가능
- 하지만 Lambda가 VPC 내부 리소스(예: EC2, RDS, 프라이빗 서브넷의 데이터베이스 등)에 접근하려면 해당 Lambda를 특정 VPC에 연결해야 함
- VPC 내부 연결: Lambda는 VPC 내 특정 서브넷에 연결되고, 보안 그룹을 통해 네트워크 트래픽을 제어
(3) S3
- VPC와 독립적
- S3는 리전 단위로 관리되며, VPC에 종속되지 않음. 퍼블릭 인터넷을 통해 접근할 수 있음
- VPC에서 S3에 안전하게 접근: VPC 엔드포인트(VPC Endpoint)를 설정하면, 인터넷을 거치지 않고 AWS 네트워크를 통해 S3와 안전하게 통신할 수 있음
(4) Step Functions
- VPC와 독립적
- Step Functions는 관리형 서비스로, VPC에 종속되지 않음
- Step Functions와 VPC 내부 리소스 통신: Step Functions가 실행 중 Lambda를 호출하고, 해당 Lambda가 VPC 내부에서 실행되는 리소스와 연결되는 구조를 사용
4. VPC 내에서도 인터넷에 접근할 수 있는 방법
- VPC 내의 EC2 인스턴스에서 외부 인터넷과 연결 가능한 이유: VPC 설정에 따라 외부 인터넷 접근이 허용될 수 있기 때문
- VPC 내에서도 인터넷에 접근할 수 있는 방법이 여러 가지 존재함
1) VPC에서 인터넷 연결의 기본 원리
VPC 내 리소스가 외부 인터넷과 연결되기 위해서는 아래 두 가지가 필요함
- 인터넷 게이트웨이 (Internet Gateway, IGW)
- VPC를 외부 인터넷과 연결하는 AWS 리소스
- 퍼블릭 서브넷에 연결되어 있어야 VPC 내 인스턴스가 외부 인터넷과 통신할 수 있음
- 퍼블릭 IP (Public IP)
- EC2 인스턴스에 퍼블릭 IP 또는 엘라스틱 IP (Elastic IP)가 할당되어 있어야 외부에서 접속 가능
2) VPC 서브넷의 유형
- 퍼블릭 서브넷 (Public Subnet)
- 인터넷 게이트웨이가 연결되어 있고, 인스턴스에 퍼블릭 IP가 할당된 서브넷
- 이 서브넷의 리소스는 외부 인터넷과 통신할 수 있음
- 프라이빗 서브넷 (Private Subnet)
- 인터넷 게이트웨이가 연결되어 있지 않으며, 외부 인터넷과 통신하려면 NAT 게이트웨이를 사용해야 함
- 보안이 중요한 데이터베이스나 내부 서비스용 리소스가 위치함
3) VPC에서 장고 서버가 외부와 연결되는 이유
장고 서버가 EC2에 배포되고 퍼블릭 IP로 외부 사용자와 연결되는 이유는 다음과 같음
- 퍼블릭 서브넷에 위치
- 장고 서버가 퍼블릭 서브넷에 배치되고, 인터넷 게이트웨이가 VPC에 연결되어 있기 때문
- 퍼블릭 IP 할당
- EC2 인스턴스가 퍼블릭 IP 또는 엘라스틱 IP를 가지고 있어 외부에서 접근 가능하게 설정됨
- 보안 그룹(Security Group)
- 보안 그룹에서 HTTP/HTTPS 포트를 열어 외부 사용자가 EC2에 접근할 수 있도록 허용
4) 요약
- VPC 내에서도 퍼블릭 서브넷과 인터넷 게이트웨이를 사용하면 외부 인터넷과 연결이 가능
- 장고 서버를 퍼블릭 서브넷에 배치하고 퍼블릭 IP를 할당하면 사용자와 연결할 수 있음
- 민감한 데이터는 프라이빗 서브넷에 배치하고 VPC 내부 통신으로 보호
- AWS 보안 기능(보안 그룹, WAF, HTTPS)을 활용하여 보안을 강화
📙 내일 일정
- 최종 프로젝트
'TIL _Today I Learned > 2024.12' 카테고리의 다른 글
[DAY 104] 최종 프로젝트_ 인터넷 게이트웨이, 라우팅 테이블, ACL (0) | 2024.12.16 |
---|---|
[DAY 102] 최종 프로젝트_ Labeling Pipeline (2) | 2024.12.12 |
[DAY 100] 최종 프로젝트_ GitLab (1) | 2024.12.10 |
[DAY 99] 최종 프로젝트_ AWS 아키텍처 설계 (1) | 2024.12.09 |
[DAY 98] 최종 프로젝트_ 모델 Fine Tuning, 플로우 차트 (2) | 2024.12.06 |