[AWS] AWS SA 교육 1 (9/3~9/6)

3 (RDS 추가설명, VPC 기초)

4 (RDS 추가설명, VPC 기초)

Amazon Aurora

* 3개의 가용 영역에 6개의 복제본 사용 의미

- 2개의 가용 영역만 있다면 Aurora를 사용하지 못함

- 최소한 3개의 가용 영역이 필요하다는 것이고, 2개의 가용 영역에서 Aurora를 사용한다면 하나의 Hidden 영역이 있을 수 있다는 것을 의미함

Q. 왜 3개의 가용 영역이 필요할까?

A. 투표 시스템, Aurora는 클러스터이기 때문

2개의 가용영역만 있을 경우 어떤 데이터가 진짜인지 모름, 투표를 해서 과반수 이상이 되어야지만 어떤 데이터가 최신 데이터인지 알 수 있음, 그러기 위해 기본적으로 홀수 개의 가용 영역이 필요함

만약, 2개의 가용영역만 있을 때 장애가 나서 둘 중 하나만 남는 다면 한쪽에 모든 데이터가몰리게 됨 

근데, 이 데이터가 진짜인지 가짜인지 모름, 마지막 데이터가 여기까지인지 모름 두 개의 데이터가 다르기 때문

 

프라이빗 서브넷에 이터넷 연결

- NAT 게이트웨이는 퍼블릭 서브넷에 존재해야 함

- 라우팅 테이블에서는 프라이빗 서브넷에 있는 것을 라우팅을 해줘야 함

프라이빗 인스턴스 -> NAT 게이트웨이 -> 인터넷 게이트웨이

 

서브넷 사용 사례

- 데이터를 직접 접근하는 서비스, 배치 처리 인스턴스, 백엔드 인스턴스 -> 프라이빗 서브넷

- 웹 애플리케이션 인스턴스 -> 퍼블릭 또는 프라이빗 서브넷

 

서브넷 권장 사항

- 작은 크기보다는 더 큰 크기의 서브넷을 고려(/24 이상 권장)

- 너무 작게 잡아두면 확장하는데 문제가 발생함

- 워크로드 배치를 간소화하기 위해서 실제로 서브넷을 여러 개로 쪼개는 것 보다 큰 서브넷에 배포하는 게 더 좋음

 

탄력적 네트워크 인터페이스(Elastic Network Interface)

- 사설 IP를 가질 수 있음

- 프라이빗 IP 주소, 탄력적 IP 주소, MAC주소

 

Q. ENI를 여러 개 붙이는 이유?

A. 관리 네트워크 생성, VPC에서 네트워크 및 보안 어플라이언스 사용, 별도의 서브넷에 있는 워크로드/역할로 이중 홈 인스턴스 생성

애플리케이션 요구사항에 따라서 네트워크 인터페이스 카드를 여러 개 연결해야 되거나

 

탄력적 IP 주소

- 공인 IP 고정 제공

- BYOIP(Bring Your Own IP)를 지원 : 내가 소유하고 있는 IP를 아마존에서 사용할 수 있음

- HA를 걸 수 있지만 다운 타임이 발생할 수 있음

- 리전당 5개가 허용 되지만 support를 통해 늘릴 수 있음

 

클라우드에서의 보안

보안 그룹

- 규칙은 Stateful(상태 저장)임, 특정한 인바운드나 아웃바운드 정책을 잡아주면 그 정책에 대한 상태 값으로 처리할 수 있음

- 트래픽은 모든 IP 프로토콜, 포트 또는 IP주소로 제한할 수 있음

 

보안 그룹 : 기본 설정

- 모든 인바운드 트래픽 차단

- 모든 아웃바운드 트래픽 허용

 

 

 

5 (VPC 확장 기능인 VPN, 전용선 DX, TGW)

AWS 기반 네트워킹 

가상 프라이빗 게이트웨이(VGW)

- 사설 네트워크 VPN(vritual Private Network)과 온프레미스를 연결하기 위해 필요

 

VPN 연결

- 온프레미스 네트워크를 AWS로 확장

- AWS에서는 VPN을 이용하는 VGW를 생성하고, 온프레미스에서는 CGW(Customer Gateway)를 만들어서 VGW와 CGW간에 연결을 해줌

- WAN 구간 연결

* 참고로 CGW는 실제 온프레미스에 있는 네트워크 장비의 공인 IP정보와 그 백단에 있는 네트워크 대역대를 정의해둔 정의서,

실제 연결은 온프레미스의 VPN 장비와 아마존에서 제공하는 VPN 장비 간에 연결을 하는 것임

 

- 여러 대의 온프레미스 네트워크를 AWS로 연결할 수 있음

- VGW는 GW이므로 네트워크에 연결 됨, 그 네트워크는 VPC 단임

* VGW는 VPC와 연결되어 있고, 서브넷에서 게이트웨이로 라우팅 함, 라우팅을 동적으로 걸 수도 있고, 정적으로도 걸 수 있음

 

- VPN 연결을 하면 2대의 인스턴스가 뜸, 2대의 인스턴스가 VPN 장비처럼 동작함

- VPN과 VPN 장비 간에는 공인 IP로 통신하고, 뒷 단에 사설 네트워크는 SSL 인증서를 가지고 보안 채널을 통해 통신

 

Q. VGW에 2대의 인스턴스가 뜨는 이유?

A. 이중화 때문, 고가용성 때문에 두 대를 연결하고 쓰는 것을 권장함

 

- VPN 연결은 BGP연결을 지원함

 

Q. 온프레미스 장비가 이중화 돼야 한다면 VPN 연결은 몇 개가 필요한가?

A. VPC 연결이 2개가 돼야 함

총 4대의 인스턴스가 생김

 

AWS Direct Connect(DX)

- 전용선(프라이빗 네트워크)을 구성하기 위한 옵션

- AWS와 사설 네트워크 간에 전용선을 구성해서 대역폭과 Latency를 보장할 수 있다는 장점이 있음

 

DX 사용 사례

- 하이브리드 클라우드 아키텍처

- 네트워크 성능 예측 가능성(전용선으로 연결했기 때문에)

- 보안 및 규정 준수

 

크리티컬 워크로드를 위한 복원력

- 크리티컬 워크로드를 위해 기본적으로 온프레미스와 DX를 연결하고 백라인은 VPN으로 VPC를 연결 (VPN과 DX를 같이 사용)

- DX가 문제가 생기면 VPN으로 일단 사용할 수 있음

- 장점은 비용 효율적임

- 단점은 네트워크에 대한 퀄리티가 낮아지고, Latency가 증가함

- 두 개의 네트워크를 언제 장애가 나서 언제 우회할지를 선언하기 힘드니까 무조건 BGP를 띄워야함

- DX를 전용선과 연결한다고 하면 무조건 BGP로 띄워야 함

 

VPC 연결

- 개발, 테스트, 프로덕션 환경을 격리해서 만드는 것을 권장함

 

VPC 연결 - VPC 피어링

- 격리되어 있는 두 개의 네트워크(격리된)를 논리적으로 연결해서 통신할 수 있도록 해주는 

- 피어링을 하면 ID 값이 나오는데, ID를 기반으로 라우팅 테이블을 설정해주면, 서브넷 단위로 접근을 제어할 수 있음

- VPC 간 프라이빗 IP 주소 통신 지원

- 내부 및 리전 간 지원

- CIDR이 중복될 수 없음

- 트래픽은 항상 글로벌 AWS 백본에서 유지

- 전이적 피어링 관계는 지원되지 않음

ex) 개발 <-> 테스트 <-> 프로덕션

이렇게 피어링을 했을 때, 개발 -> 프로덕션으로 통신하기 위해서 별도의 피어링이 없는 한 개발에서 테스트를 거쳐 프로덕션으로 가는 것이 불가능함

기본적으로 IDC에서는 라우팅 테이블이 전이적 라우팅 테이블을 지원함 A장비에서 B장비를 통해 C장비로 보내는 것이 가능함, 하지만 VPC 피어링은 그것이 불가능함

 

VPC 연결 - Transit Gateway

- 단일 게이트웨이로 최대 5,000개의 VPC와 온프레미스 환경 연결 가능

- 네트워크 사이를 이동하는 모든 트래픽의 허브 역할 담당

- 가용성, 완전 관리형 라우팅 서비스

 

 

VPC 엔드포인트

- AWS를 벗어나지 않고 EC2 인스턴스를 VPC 외부와 프라이빗하게 통신할 수 있도록 에뮬레이션 해주는 것

- IGW, VPN, NAT를 통하지 않고 Amazon에 있는 인터넷 패킹 서비스들과 통신할 수 있게 해주는 것

- 제약 조건) 동일한 리전에 있어야 함

- 인터페이스 엔드포인트(실제 서비스에 사설 IP를 출력해서 서브넷에 직접 연결), 게이트웨이 엔드포인트(도메인으로 라우팅함)가 있음

 

VPC 외부에서 부터 VPC 엔드포인트로 액세스하기

- 온프레미스에서 서비스랑 통신해야 하는데 외부랑 통신하고 싶지 않을 때

온프레미스에서 VPN을 타고 들어와서 프록시 팜까지와서 프록시 팜이 게이트웨이를 타고 접근하는 것

VPC 간에 전이적 연결이 지원되지 않으므로 중간에 프록시를 연결해둬서 해결

---

6부 (AWS에서 고가용성을 구성하기 위한 Server Load Balancer)

AWS 기반 로드 밸런싱

 

Elastic Load Balancing(ELB)

- 수신되는 애플리케이션의 트래픽을 부하분산을 하기 위한 장치

 

ELB 기능

- HTTP, HTTPS, TCP, UDP 및 SSL 프로토콜을 사용

- 외부(External), 내부(Internal)에 위치할 수 있음

- 각 로드 밸런서에 DNS 이름이 부여됨

* 될 수 있으면 DNS로 통신하는 것이 아마존의 권장사항임

 

ELB 옵션

ALB(Application Load Balancer)

- L7 로드 밸런서

- HTTP, HTTPS를 지원하며 최적화되어 있음

- 도메인 권장사항

* 기본적으로 Secure TCP 통신 지원하긴 하지만 공식 지원이 아님

 

NLB(Network Load Balancer)

- L4 로드 밸런서

- TCP, UDP 프로토콜을 기반으로 하는 통신을 지원

- 기본적으로 Static IP를 지원

- 도메인을 지원하긴 하지만 고정 IP 사용도 가능

* WEB 프로토콜인 TCP 80, 443 포트를 라우팅 못하는 건 아니기 때문에 HTTP나 HTTPS를 서비스를 할 수 있긴 하지만,

4 계층 기준에서 사용할 수 있는 것

 

L4와 L7 로드 밸런서의 가장 큰 차이점

-  L4기반 로드 밸런서는 기본적으로 라운드 로빈임

- 트래픽이 오면 오는 순서대로 백엔드에 하나씩 전달

- 그렇기 때문에 백엔드 성능을 고려하는 게 아니고, 들어온 요청에 따라서 한 대씩 골고루 트래픽을 분배하는 것이 라운드 로빈 설정

- L7기반 로드 밸런서는 HTTP 프로토콜을 통해서 백엔드의 성능을 어느 정도로 인지를 하고, 성능이 많이 남는 쪽으로 트래픽을 보내는 내부적인 라우팅 정책이 있음

즉, ALB는 성능을 참조하는 라우팅과 라운드 로빈을 둘 다 지원한다면, NLB는 라운드 로빈만 지원함

 

참고

- ALB와 CLB(Classic Load Balancer, 이전 세대)는 인스턴스형임 그렇기 때문에 프록시처럼 동작함

- 따라서, Client IP를 알려면 X-Forwarded-For 헤더 값을 읽어서 상대방을 알 수 있음

- NLB는 일부 기능이기 때문에 Client IP를 직접 Source IP로 받을 수 있음

 

ELB를 사용해야 하는 이유

- 고가용성 보장 : 여러 개의 서버에 트래픽을 보내야 하기 때문에

- 상태 확인 : 백엔드 인스턴스가 실제 정상적으로 동작하는가 아닌가를 위한 헬스체크를 지원

- 보안 기능 : 프론트 엔드로 들어오기 전에 ALB에서 한 번 트래픽을 확인하고 넘겨주니깐, 앞단에서 WAF 같은 것을 설정할 수 있다면 필터링해서 넘길 수 있음

- TLS 종료 : 로드밸런서 단에서는 인증서를 확인하고,  뒷단에서는 평문 통신하는 것

 

등록 취소 지연

- duration time : 인스턴스를 제거해야 하는데, 사용자의 connection이 아직 남아 있다면 끊길 때까지 기다려주는 것을 의미함

- 인스턴스를 로드밸런서에 제거할 때 바로 제거가 되는 게 아니고, duration time을 기반으로 해서 몇 분 동안은 연결성을 보장하고 있음

- 대신 트래픽을 그 인스턴스로 라우팅 해주지는 않음

- 새로운 요청에 대해서 인스턴스가 트래픽을 추가로 받지는 않지만, 실제로 로드 밸런서에서 완전히 통신을 끊어버려서 사용자가 통신하지 못하도록 통신을 완전히 막는 것은 아님

 

고가용성

고가용성

- SLA(Service Level Aggrement, 서비스 수준 계약) 기반이라고 생각하면 됨

- 서비스에 대한 가용영역을 사용자와 계약하는 것을 의미함

- 가능한 모든 지점에서 중복성을 구현하여, 단일 장애로 인해 전체 시스템이 중단되지 않도록 하기

* 우리의 서비스가 얼마큼의 SLA 보장하고 있는지 확인할 필요성이 있음

 

얼마나 많은 가용 영역을 사용해야 하는가?

- 최소한 2개의 가용 영역을 사용해야 함

 

Q. 하나의 가용영역이 장애가 발생했을 때 인스턴스가 최소 2대가 유지돼야 한다면 필요한 가용 영역은?

가용영역이 2개일 땐 각각의 서버가 2대씩 총 4개의 서버가 필요함

가용영역이 3개일 땐 각각의 서버가 1대씩 총 3개의 서버가 필요함

이렇게 생각해 봤을 때 서버 3대를 이용하는 가용영역 3개가 더 좋음, 가용영역이 2개 일 땐 4개의 서버가 필요하기 때문

 

다중 리전 고가용성 및 DNS

Route 53

- DNS(Domain Name System) 서비스

- 도메인 이름을 IP 주소로 변환해 줌

- GSLB(Global Server Load Balancing), 도메인 기반 동작

- ex) 미국 서부에 있는 리전이 장애가 났을 때 EU(런던) 리전으로 트래픽을 우회할 수 있음

 

Route 53 라우팅 옵션

- 간단한 라운드 로빈

- 가중치 기반 라운드 로빈 : AB테스트, 카나리 배포, 트래픽을 온프레미스에서 AWS 인프라로 점차적으로 넘길 때

- 지연 시간 기반 라우팅 : 백엔드 성능에 따라서 배포, 가장 빨리 응답하는 곳에 라우팅

- 상태 확인 및 DNS 장애 조치 : 헬스 체크를 하다가 active가 죽으면 standby로 넘어가는 것

- 지리 위치 라우팅 : 특정한 지역에서는 어디로 갈지

- 다중 값 응답 : 여러 가지 옵션을 같이 쓸 수 있는 것