본문 바로가기
교육

[44일 차] 21.09.23 : AWS 4

by ballena 2021. 9. 23.

인터넷 게이트웨이, NAT 인스턴스, Ingress Routing, ELB 이론


1교시

 

 

AWS 네트워크 기반, 코어 서비스 학습 시작.

이번 주까지는 콘솔(웹 화면)로 조작했었지만, 다음 주부터는 코드를 통해 조작하게 될 것이다.

-> 실무에서 사용하게 될 서버, 인스턴스, 서비스의 숫자는 실습과는 차원이 다르다.

-> 다수의 구성을 조작하려면 콘솔에서는 힘들다.

-> CloudFormation을 통해 코드로 만들기 : 하나의 설정 파일로 여러 방면에 사용 가능(템플릿)

 

AWS VPC 내부에서 외부 인터넷으로 연결

-> 외부에서 들어오는 것으로 시작하는 것이 아니라, VPC 내부 장비가 외부로 요청을 보내 통신을 시작하는 것

 

 

  • 인터넷 연결을 위한 4가지 조건

1. 인터넷 게이트웨이 : 외부 인터넷과 연결을 해주는 장비. 최종적으로 인터넷 게이트웨이를 통해 통신

1-1. 프라이빗 서브넷이라면 NAT 게이트웨이가 필요다하다.

2. 네트워크 라우팅 테이블 정보 : 모든 네트워크 대역 통신은 IGW로 전달하기 위해 경로를 지정

3. 공인 IP : AWS에 사용 가능한 공인 IP는 퍼블릭 IP나 탄력적 IP가 있다.

(퍼블릭 IP는 서브넷이 부여하는 임시 공인 IP, 탄력적 IP는 사용자가 부여하는 영구적 공인 IP)

4. 보안 그룹과 네트워크 ACL : 외부 네트워크와 통신을 허용

-> 보안 그룹은 인스턴스를 지키고, 네트워크 ACL은 서브넷을 지킨다.

-> 하나의 인스턴스(서브넷)에는 최소 하나의 보안 그룹(네트워크 ACL)이 있다.

-> 하나의 보안 그룹(네트워크 ACL)은 여러 인스턴스(서브넷)에 적용될 수 있다.

 

  • NAT 동작

-> 여기서 말하는 NAT는 엄밀히 말하면 PAT다.

-> 퍼블릭 인스턴스는 외부와 통신 시 NAT를 사용하지 않는다.

-> 프라이빗 인스턴스는 외부와 통신할 공인 IP가 없어서 NAT가 필요 : 인스턴스를 서브넷에 둘 때 IP를 할당받을 것인가, 에서 차이가 생기는 것이다.

프라이빗 인스턴스에서 패킷이 출발할 때, 출발지 IP와 목적지 IP가 있을 것이다. 목적지 IP는 공인 IP겠지만, 출발지 IP는 사설 IP다.

당연히 나갈 때는 문제가 없다. 응답이 돌아올 경우가 문제지. 인터넷 상의 라우터들은 이 사설 IP가 어디 있는지 모른다.

애초에 공개되어 있지 않으니까. 그리고 사설 IP는 같은 주소를 사용하는 장비가 다른 지역의 서브넷(네트워크)에 있을 수 있기도 하고.

아무튼 사설 네트워크에서 나갈 때 공유기에서 출발지 주소를 공인 IP로 바꿔줘야 한다.

-> 정적/동적 NAT는 각각 단점이 있었으니 패스.

-> 그래서 사용하는 것이 PAT. 공유기가 패킷을 내보낼 때 지정해놓은 포트 주소로 구분하는 것.

-> 변환된 공인 IP 주소가 패킷마다 동일해도, 돌아올 때 포트 주소로 구분

 

  • 인터넷 연결을 위한 3가지 방안

1. 인터넷 게이트웨이 : 퍼블릭 서브넷의 경우에는 이것 하나만으로 충분

-> 3 계층적 동작. 

-> VPC에서 외부로 나가는 통로일 뿐, 주소 변환의 기능은 없다(강의 자료와 헷갈릴 수 있으니 주의).

-> 애초에 퍼블릭 인스턴스면 공인 IP를 갖고 있으니까 나갈 때 공인 주소를 갖고 나갈 것이다.

-> 주소 변환의 기능은 프라이빗 서브넷이 외부와 통신할 때 사용된다고 보면 된다.

 

2. NAT 디바이스(NAT 인스턴스 + NAT 게이트웨이)

-> 4 계층적 동작 : PAT 동작이니까.

-> NAT 디바이스는 퍼블릭 서브넷에 위치해야 하는 점에 주의

   -> 프라이빗 서브넷은 애초에 공인 IP를 할당받지 않도록 설정된 서브넷이다.

   -> 프라이빗 서브넷에 연결된 라우팅 테이블에 외부와의 연결 정보가 없기 때문에 통신이 안된다.

   -> 라우팅 테이블에 추가하면요? : 외부와의 통신이 되는건데, 그럴 거면 프라이빗 서브넷을 왜 만드나?

-> 외부에서 들어오는 것은 막고, 내부에서 나가서 찾는 것은 열어두기 위해 NAT 디바이스를 두는 것이다.

 

3. Proxy 인스턴스

-> 7 계층적 동작 : 이것까지는 안한다.

-> 프록싱 기능. IP 주소와 포트 번호 변환

-> Application 수준 제어 가능

우리가 했던 것은 서버 측의 리버스 프록싱


2교시

 

 

  • 인터넷 게이트웨이

확장성과 가용성이 있는 VPC 구성 요소로, VPC와 인터넷 간의 통신을 가능하게 한다. 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 1:1 IPv4 주소 변환을 수행.

-> 주소 변환이 아니라 전달/연결해주는 것이라고 생각하자.

-> 하나의 VPC에는 하나의 IGW만 사용 가능 : 나가는 문이 여러 개면 헷갈린다.

-> 리전 당 VPC의 기본 할당량은 5개. 그 이상 필요하다면 따로 문의해서 풀어야 한다(최대 100개).

 

반복해서 나오는데, 원래 IGW에서 주소 변환을 해주는 것이지만, AWS에서는 인스턴스가 할당을 받을 때 공인 IP가 있다, 정도로 알아두면 된다.

-> 자세히는 인터넷 게이트웨이에 정적 NAT가 적용되어 있는 것이다.

-> 개념적으로 따지면 인터넷 게이트웨이에 사설 IP - 공인(탄력적) IP의 1:1 매칭 목록이 있는 것.

-> 인스턴스를 생성하는 순간 인터넷 게이트웨이가 가지고 있는 목록에 엔트리가 추가된다.

-> 나갈 때 사설 주소가 공인 주소로 바뀌고, 들어올 때 사용했던 공인 주소를 사설 주소로 바꾼다.

 

 

NAT 인스턴스 + NAT 게이트웨이 = NAT 디바이스

프라이빗 서브넷에 배치된 인스턴스는 공인 IP를 연결할 수 없어서 직접 인터넷 연결이 불가능. NAT 디바이스를 사용해 인터넷 또는 기타 AWS 퍼블릭 서비스에 연결 가능.

기본적으로 내부에서 외부 인터넷으로 통신만 가능하고, 외부에서 내부 AWS 구간으로 직접 통신은 불가능. 이거 하려면 NAT에 포트포워딩 필요

NAT 인스턴스와 NAT 게이트웨이 비교

워크로드(Workload) : 대충 작업 계획이라고 보면 된다.

 

AWS가 자체 관리하는 서비스들은 원격 접속 불가.

-> 애초에 직접 관리하는 번거로움을 피하기 위해 회사 측에서 관리해주는 서비스를 사용하는 것이다.

-> 관리하기 싫으면서 접속은 하고 싶다? 당연히 불가능.

 

NAT 인스턴스 eni(Elastic Network Interface)

-> 라우팅 테이블에서 NAT 게이트웨이 ID를 넣듯이 넣게 될 것이다.

 

NAT 제약사항

1. NAT 게이트웨이는 5 Gbps 대역폭을 지원하며, 최대 45 Gbps까지 자동 확장한다.

2. NAT 게이트웨이는 단일 대상(예시 : 외부 웹 서버 1대 IP)에 대해 분당 최대 55,000개의 동시 연결을 지원한다.

3. NAT 게이트웨이는 가용 영역당 기본 할당량은 5개이며, 그 이상 필요할 경우 따로 문의해야 한다(AWS 케이스 오픈 : 고객센터).


3교시

 

 

실습 준비

1. 기본 환경 구성

- VPC 1개, 인터넷 게이트웨이 1개 구성

- 프라이빗 서브넷, 퍼블릿 서브넷 1개씩 구성

- 프라이빗 서브넷에 인스턴스 2개, 퍼블릭 서브넷에 NAT 인스턴스 생성

- 프라이빗 서브넷 라우팅 테이블에 0.0.0.0/0에 대한 연결은 NAT 인스턴스 eni로 연결

- 퍼블릭 서브넷 라우팅 테이블 구성은 하던 대로

 

#!/bin/bash
(
  echo "qwe123"
  echo "qwe123"
  ) | passwd --stdin root
  sed -i "s/^PasswordAuthentication no/PasswordAuthentication yes/g" /etc/ssh/sshd_config
  sed -i "s/^#PermitRootLogin yes/PermitRootLogin yes/g" /etc/ssh/sshd_config
  service sshd restart

 

- NAT Instance(퍼블릭 인스턴스) 생성 시 'amzn-ami-vpc-nat' 포함된 AMI 사용.

(강의 자료에 탄력적 IP 연결, 이라는 것은 퍼블릭 IP 할당 활성화하라는 의미)

- 각 인스턴스에 사용할 보안 그룹 구성

보안 그룹 구성


4교시

 

 

각 인스턴스(퍼블릭1, 프라이빗2)에서 curl로 확인해보면

-> 퍼블릭은 확인 가능. 프라이빗은 확인 불가

 

  • 리눅스 인스턴스가 NAT가 되려면?

1. 포워딩 설정

인스턴스는 서버(종단 장비)다. 패킷이 도착하면 패킷을 더 이상 전달할 수 없다는 의미.

NAT 인스턴스는 VPC에서 나오는 패킷을 받아 외부로 전달해야 하는데, 종단 장비가 되면 기능을 수행할 수가 없다.

인스턴스는 기본적으로 스스로를 종단 장비로 인식하므로, 설정을 변경해줘야 한다. 이때 변경하는 설정이 포워딩 설정.

-> 포워드가 가능하도록 설정

포워드 설정을 하려면 커널 수준에서 다뤄야 한다.

/proc/sys/net/ipv4/ip_forward 파일의 내용은 0 또는 1로 변경할 수 있는데, 1로 변경하면 포워딩이 가능하도록 설정된다. 종단 장비일 경우 0일 것이다.

-> 리눅스의 장점. 커널 구성 요소가 파일 형식으로 되어 있어 사용자가 수정할 수 있다.

 

2. NAT 설정

리눅스는 방화벽이 2가지다(iptables, firewalld). 이 기능을 통해 netfilter라는 커널 수준의 기능 조절

amzn-ami-vpc-nat는 iptables를 사용.

sudo iptables -nL POSTROUTING -t nat -v 명령어로 netfilter에 있는 NAT 구성 정보를 볼 수 있다.

-> 마스커레이드 설정으로 인해 프라이빗 인스턴스의 주소가 NAT 인스턴스의 주소로 바뀌고, 이 주소가 인터넷 게이트웨이로 나가서 외부 인터넷으로 나간다.

이런저런 설정이 있지만, 우리는 amzn-ami-vpc-nat라는 ami를 사용하면 된다는 것.

그리고 프라이빗 라우팅 테이블에 0.0.0.0/0에 대한 연결을 NAT 인스턴스 eni로 해주면 된다.

NAT 인스턴스 > 네트워킹 탭 > 네트워크 인터페이스 > 인터페이스 ID 복사

복사한 인터페이스 ID를 프라이빗 라우팅 테이블에 0.0.0.0/0의 대상으로 추가

 

여기까지만 하면 원칙적으로는 설정 끝이지만...

NAT 인스턴스의 소스/대상 확인 비활성화 설정 필요. 기본값은 활성화되어 있다.

이걸 설정해야 비로소 포워딩이 된다.

(온프레미스에서는 필요 없지만, 여긴 AWS니까)

소스 확인 -> 패킷이 나갈 때 인터페이스에 할당된 주소가 출발지 주소로 되어 있어야 한다는 설정

대상 확인 -> 패킷이 들어올 때 패킷의 목적지 주소가 인터페이스에 할당된 주소로 되어 있어야 한다.

한마디로 AWS의 종단 장비를 위한 설정이다.

 

NAT 인스턴스 쪽으로 가서 > 체크 후 우측 상단의 작업 > 네트워킹 > 소스/대상 확인 변경 > 중지 체크 후 저장

 

이제 프라이빗 인스턴스에서 핑을 때려보면 응답이 온다. 성공!

 

curl http://checkip.amazonaws.com를 프라이빗 인스턴스에서 실행해 보면 NAT 인스턴스에서 실행했던 것과 동일한 결과가 나온다.

 

 

여기까지가 NAT 인스턴스 구성

프록시는 자체 서비스가 있으니 굳이 할 필요 없다.

 

NAT 게이트웨이가 있는데 왜 NAT 인스턴스를 쓰는가?

-> 사용자의 필요에 따라 커스텀이 가능하니까

-> 생각 없이 쓰려면 그냥 NAT 게이트웨이 쓰면 된다.

 

 

삭제 시에는 역방향으로.

1. 인스턴스 삭제

2. 인터넷 게이트웨이 삭제

3. VPC 삭제


5~6교시

 

 

VPC Ingress Routing

 

라우팅 시

- Ingress : 외부에서 들어오는 것을 보내주는 라우팅

- Egress : 밖으로 나갈 때 필요한 라우팅

 

VPC로 트래픽이 들어오고 나갈 때, 방화벽 등의 보안 프로그램 인스턴스를 경유할 경우

-> 미들박스 인스턴스를 통과하며 NAT를 2번(미들박스, 게이트웨이) 수행할 필요가 없다

-> 외부로 나갈 때 1번만 NAT 변경을 거친다(IGW에서)

-> 트래픽을 특정 하나의 지점(미들박스)으로 몰아서 필터링

 

요약하자면 내부로 들어갈 때 특정 장비로 유입시키는 것

 

모두에게 동일한 문제 발생 : MiddleBox는 접속 가능, Inner 2개는 접속 불가.

-> /proc/sys/net/ipv4/ip_forward 가 1이어야 한다.

sudo sysctl -w net.ipv4.ip_forward=1 실행해서 1로 변경

-> ip 관련 패킷을 포워드할 것인가?

 

sudo sysctl -w net.ipv4.conf.eth0.send_redirects=0 실행해서 0으로 변경

 

이제 접속이 된다.

얼핏 보면 외부에서 바로 InnerClient들로 접속한 것 같지만, 실제로는 중간에 있는 MiddleBox를 거쳐서 들어간 것이다.

Ingress Routing에서의 라우팅 테이블들

외부로 나갈 때에도, 외부에서 들어올 때에도 MiddleBox를 거치게 될 것이다.

-> 트래픽을 하나의 포인트로 모아서 볼 수 있다. 이제 MiddleBox에 보안 설정을 하면 필터링 역할도 할 수 있을 것이다.

-> 이러면 Inner를 굳이 프라이빗으로 구성할 필요가 없다.

 

MiddlrBox에 yum으로 iptraf 패키지를 설치하고, sudo iptraf-ng를 실행, eth0를 보면 트래픽 상황이 보인다.

인터넷 게이트웨이에 전용 엣지 테이블을 구성하고, 유입되는 트래픽을 하나의 장비로 모아 필터링, 보안, 모니터링이 가능하도록 하는 것.

 

 

삭제할 때 외 역순으로 삭제하는가?

-> 종속성 연결 문제


7교시

 

 

AWS 부하 분산

-> 고가용성 환경 구성

 

단일 서버 서비스 제공 환경은 장애 발생 시 답이 없다.

다수 서버 서비스 제공 환경은 하나의 서버(인스턴스)에서 장애가 발생해도 다른 서버가 있기에 서비스에 문제가 없다.

 

ELB(Elastic Load Balancer)

AWS에서 제공하는 부하 분산 기술. EC2 인스턴스의 상태를 확인하고 데이터를 분산하여 전달하는 단일 접점 역할을 수행. 중요하다.

(보통 Elastic이라고 붙으면 AWS가 관리하는 서비스다. 즉 사용자가 관리할 필요가 없다는 뜻)

 

 

로드 밸런서는 

1. 리스너 : 자신이 서비스하는 대상을 정의

-> 서비스 대상의 트래픽을 수신할 준비 : 대상에게 실제 유입될 트래픽 필터링

-> 특정 포트라던가, 프로토콜이라던가... Rule을 정하고 받는다.

2. 대상 그룹 : 부하 분산 대상을 정의

-> 하나 이상의 대상에 대한 라우팅으로 부하 분산

-> 대상 그룹에 속한 대상에 대해 주기적으로 Keepalive 프로세스를 통해 상태 확인 수행

-> 정상적 상태의 대상에게만 데이터 전달


8교시

 

 

ELB는 4가지(ALB, NLB, GLB, CLB)가 있는데, CLB는 옛날 버전이라 잘 사용하지 않는다.

1. Application Load Balancer : http/https와 같이 웹 애플리케이션에 대한 분산 처리를 제공

-> http/https에 특화된 어플리케이션 레벨의 로드 밸런서. 다른 LB에 비해 처리 속도가 느릴 수 있지만 HTTP(S)에 대한 세부적이고 다양한 정책을 통해 라우팅 가능.

-> URL 경로 기반 라우팅, 호스트 기반 라우팅, HTTP 헤더 기반 라우팅 등과 같이 다양한 규칙을 생성하여 포워드, 리다이렉션, 지정 HTTP 응답 등의 작업을 수행할 수 있다.

-> Lambda 함수를 호출해서 HTTP(S) 요청 처리 가능.

 

2. Network Load Balancer : TCP/UDP 프로토콜에 대한 포트 정보를 정의, 네트워크 기반의 분산 처리 제공

-> TCP/UDP/TLS 프로토콜에 대해 부하 분산을 수행할 수 있는 4 계층 레벨의 로드 밸런서.

-> 가장 빠른 처리 속도가 가능하며, 고정 IP나 탄력적 IP를 보유하고 있다.

-> VPC 엔드포인트 서비스로 연결하여 프라이빗 링크 구성을 할 수 있다.

 

3. Gateway Load Balancer : 비교적 최근에 나왔다.

ELB 유형별 차이

 

ELB 통신 방식

1. 인터넷 연결(Internet Facing Load Balancer)

-> 퍼블릭 주소를 가지고 있어 인터넷을 통해 요청을 로드 밸런서에 등록된 EC2 인스턴스로 라우팅

2. 내부(Internal Load Balancer)

-> 프라이빗 주소만 가지고 있어, 로드 밸런서를 위한 VPC 내부에 접근하여 등록된 EC2 인스턴스로 라우팅

 

 

ELB 특징

1. 고가용성 : ELB로 들어오는 트래픽을 다수의 대상으로 분산하여 고가용성 유지

2. 상태 확인 : 대상 그룹에 대한 Keepalive를 통해 주기적으로 상태 확인

3. 보안 기능 : 보안 그룹을 적용해 보안 옵션 부여(NLB는 보안 그룹이 적용되지 않음)

4. 4 계층/7 계층 로드 밸런싱 : HTTP(S) 7 계층의 애플리케이션을 로드 밸런싱하거나 TCP/UDP의 4 계층의 로드 밸런싱을 사용

5. 운영 모니터링 : ELB 어플리케이션 성능을 실시간으로 모니터

 

 

NLB 실습은 내일.

1. VPC 2개

2. 한 VPC에는 서브넷 2개(웹 서버용), 한 VPC에는 서브넷 1개(클라이언트용) : 모두 퍼블릭 서브넷

-> HTTP와 SNMP 사용

3. ALB, NLB 비교

 

내일은 LB 실습 후 DNS


1, 2교시 개념 수업은 다시 들을 만하다.

5교시 (14:30 ~ ) Ingress Routing 다시 듣기

따로 정리할 개념

1. NAT/PAT 

2. Proxy

'교육' 카테고리의 다른 글

[46일 차] 21.09.27 : AWS 6  (0) 2021.09.27
[45일 차] 21.09.24 : AWS 5  (0) 2021.09.24
[43일 차] 21.09.17 : AWS 3  (0) 2021.09.22
[42일 차] 21.09.16 : AWS 2  (2) 2021.09.16
[41일 차] 21.09.15 : Ansible 5(AWS, VPC), AWS 1  (0) 2021.09.15

댓글