5. AWS 환경 설계

1. 리전을 어떻게 선택하는가?

 

1.1 데이터 주권 및 규정 준수

 

거버넌스 요구 사항으로 5개의 탄소 중립 리전 제공

https://aws.amazon.com/ko/about-aws/sustainability/

AWS 및 지속 가능성

 

1.2 데이터에 대한 사용자 근접성

 

http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it

Latency is Everywhere and it Costs You Sales - How to Crush it - High Scalability -

2006년 Amazon 내부 조사에 따르면 Amazon.com의 지연 시간이 100밀리초 늘어날 때 마다 매출 1% 감소

2006년 Google 연구 조사에서도 500밀리초 지연 시 트래픽과 매출이 20% 감소

 

1.3. 서비스 및 기능 가용성

AWS에서는 서비스를 모든 리전에서 제공할 수 있을 때까지 기다렸다가 출시하지 않고, 서비스가 준비되면 먼저 릴리스하고 가능한 빠르게 제공 리전 확장

 

1.4. 비용 효율성

 

I.  서비스 비용은 리전 별 상이

II.  Amazon S3 같은 일부 서비스에는 데이터 전송 시 비용 발생

III. 다른 리전의 전체 환경 복제 시 비용 효율성 고려 필요

 

2. 가용 영역은 몇 개나 사용해야 하나?

 

2.1. 권장 사항: 리전 당 2개의 가용 영역(AZ)을 시작

 

I.   한 가용 영역의 리소스에 접근할 수 없더라도 애플리케이션에 장애가 발생해서는 안됨

II.  애플리케이션 대부분은 2개의 가용 영역 지원 가능

III. HA를 위해 3개 이상의 가용 영역을 사용하면 일반적으로 비용 효율성이 떨어짐
단, Amazon EC2 heavy 사용률 스팟 인스턴스 또는 Amazon DynamoDB와 같이 Active/Passive를 넘어서는 데이터 소스의 경우, 3개 이상의 AZ 사용 시 누리는 이점이 있을 수 있음

 

2.2. 사용 예시

 

2.3. 2개의 가용 영역을 사용하는 다른 이유

 

I. Amazon EC2 스팟 인스턴스 사용률이 매우 높은 애플리케이션

-  다양한 요금 옵션을 위해 2개 이상의 가용 영역

 

II. MySQL, MS SQL Server 및 Oracle과 같은 데이터 원본을 사용하는 애플리케이션

-  액티브/패시브 지원을 위해 2개의 가용 영역

 

III. Cassandra 또는 MongoDB와 같은 데이터 소스를 사용하는 애플리케이션

-  매우 높은 가용성을 위해 2개 이상의 가용 영역

 

3. 모든 것을 하나의 VPC에 구성해야 하나?

 

3.1. 하나의 VPC가 적절한 사용 사례

 

-  고성능 컴퓨팅

-  자격 증명 관리

-  한 명 또는 매우 작은 팀이 관리하는 소규모 단일 애플리케이션

 

사용 사례 대부분은 인프라를 조직하는 데 2개 이상의 VPC 및 복수 계정을 사용함.

 

3.2. AWS 인프라 패턴

 

 

I. 다중 VPC 패턴

 

-  관리형 서비스 공급자와 같은 단일 팀 도는 단일 조직

-  팀 수가 제한 되면 표준 유지 관리 및 액세스 관리가 훨씬 용이

-  예외 사항: 거버넌스 및 규정 준수 표준은 조직의 복잡성과 관계 없이 워크로드 격리를 요구 할 수 있음.

 

II. 복수 계정 패턴

 

-  대규모 조직 및 IT팀이 여러 개인 조직

-  빠른 성장이 예상되는 중간 규모의 조직

-  액세스 및 표준 관리는 조직이 복잡할수록 어려울 수 있어 복수 계정 패턴이 적합

 

3.3 그 외 중요 고려 사항

 

AWS 서비스 대부분이 실제로 VPC 내에 위치하지 않음

 

I.  AWS 리전 간 네트워크 트래픽은 기본적으로 AWS 글로벌 네트워크 백본을 통과

II. 때때로 리전 간 트래픽이 퍼블릭 인터넷을 사용

III. Amazon S3와 DynamoDB는 퍼블릭 인터넷을 통과하지 않고도 연결되도록 VPC 엔드포인트를 제공

 

VPC 네트워킹 구성 요소

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Networking.html

VPC 네트워킹 구성 요소 - Amazon Virtual Private Cloud

4. VPC를 Subnet으로 어떻게 나누어야 하나?

 

4.1. CIDR 표기

 

I. VPC를 생성할 때, CIDR 표기법으로 IP 주소 집합을 지정

 

II. Classless Inter-Domain Routing (CIDR) 표기법

 

CIDR 표기법 예에 있는 16은 이러한 비트 중 몇 개가 잠겨 있고 변경할 수 없는 지 나타냄.

잠겨 있지 않은 비트는 1과 0사이에서 변경 될 수 있어 전체 범위의 값을 사용할 수 있음.

 

III. CIDR 예: 10.0.0.0/16

사용 가능한 가장 낮은 IP

사용 가능한 가장 높은 IP

4.2. VPC 및 IP 주소

 

AWS VPC는 /16과 /28 사이의 CIDR 범위를 사용할 수 있음.

CIDR 범위의 숫자가 하나씩 증가할 때마다, 총 IP수는 절반으로 줄어듦

CIDR	총 IP
/16	65,536
/17	32,768
/18	16,384
/19	8,192
/20	4096
/21	2048
/22	1024
/23	512
/24	256
/25	128
/26	64
/27	32
/28	16

 

4.3. 서브넷이란? 

 

서브넷은 CIDR 범위로 나누어진 네트워크의 세그먼트 또는 파티션을 말함

예: CIDR /22인 VPC는 총 1,024개의 IP를 포함

참고: 모든 서브넷에서 처음 4개와 마지막 1개의 IP 주소는 AWS에서 사용하기 위해 예약되어 있음.

-  10.0.0.0: 네트워크 주소

-  10.0.0.1: AWS에서 VPC 라우터용으로 예약

-  10.0.0.2: AWS에서 Amazon 제공 DNS에 매핑하기 위해 예약

-  10.0.0.3: 차후 사용을 위해 AWS에서 예약

-  10.0.0.255: 네트워크 브로드캐스트 주소 AWS는 VPC에서 브로드캐스트를 지원하지 않으므로, 이 주소를 예약

 

4.3.1. Public Subnet

퍼블릭 인터넷에 대한 인바운드/아웃바운드 액세스를 지원하도록 인터넷 게이트웨이에 대한 라우팅 테이블 항목을 포함

 

4.3.2. Private Subnet

인터넷 게이트웨이에 대한 라우팅 테이블 항목이 없으며, 퍼블릭 인터넷에서 직접 액세스할 수 없음

일반적으로 ‘점프 박스’ (NAT/Proxy/Bastion host)를 사용하여 제한된 아웃바운드 전용 퍼블릭 인터넷 액세스를 지원

애플리케이션 또는 기능 티어(웹/앱/데이터 등)를 기준으로 서브넷을 정의하기 보다는, 인터넷 접근성을 기준으로 서브넷을 구성해야 함.   이를 통해 퍼블릭 리소스와 프라이빗 리소스 간에 명확한 서브넷 수준의 격리를 정의할 수 있음

 

4.4. 권장 사항

 

I. 가용 영역당 1개의 Public 및 1개의 Private 서브넷으로 시작

인터넷에 직접 액세스해야 하는 모든 리소스(Public Load Balancer, NAT Instance, Bastion Host 등)는 Public Subnet으로

모든 다른 인스턴스는 프라이빗 서브넷으로 구성 (예외: 직접적 또는 간접적으로도 인터넷에 대한 액세스가 전혀 필요 없는 리소스는 별도의 Private Subnet으로 구성)

 

II. 퍼블릭 서브넷보다 프라이빗 서브넷에 더 많은 IP를 할당

 

일반적으로 리소스 대부분은 Private Subnet에서 호스팅할 수 있으며 필요에 따라 인터넷에 대한 제어된 액세스를 위해 Public Subnet을 사용할 수 있음

 

이 때문에 Public Subnet과 비교하여 프라이빗 Subnet에 훨씬 더 많은 IP를 제공하도록 서브넷을 계획해야 함.

 

III. 작은 크기보다는 더 큰 크기의 서브넷을 고려

 

-  워크로드 배치를 간소화

 ㅁ  워크로드를 10개의 작은 서브넷 중 어디에 배치할지 선택하는 것이 1개의 큰 서브넷보다 더 복잡

 

-  IP를 낭비하거나 IP가 부족할 확률이 낮음

 ㅁ  서브넷에서 사용 가능한 IP가 부족한 경우, 해당 서브넷에 IP를 추가할 수 없음

 ㅁ  예: 251개의 IP가 할당된 서브넷에서 IP를 25개만 사용하는 경우, IP가 부족한 다른 서브넷과 226개의 미사용 IP를 공유할 수 없음

 ㅁ  참고: 더는 ARP(Address Resolution Protocol) 브로드캐스트 도메인을 제한할 필요가 없음. 이 부분은 VPC에서 처리

 

4.5. Subnet

 

I. DataStore Instance: Private Subnet

II. Batch Instance: Private Subnet

III.BackEnd Instance: Private Subnet

IV. Web application Instance: Public or Private Subnet

-  웹 티어 인스턴스를 퍼블릭 서브넷에 넣을 수 있지만, 실제로는 퍼블릭 서브넷에 배치된 로드 밸런서 뒤에, 프라이빗 서브넷 내에 배치하는 것이 좋음

- 일부 환경에서는 웹 애플리케이션 인스턴스를 탄력적 IP에 직접 연결해야 하며(Elastic IP를 Load Balancer에 연결 할 수 있더라도) 그런 경우 웹 애플리케이션 인스턴스는 퍼블릭 서브넷에 있어야 함.

 

5. VPC 트개픽은 어떻게 제어하는가?

 

5.1. 라우팅 테이블: VPC 리소스 간 트래픽 보내기

 

-  라우팅 테이블

 ㅁ  네트워크 트래픽이 라우팅 되는 장소 결정

 ㅁ  메인(기본) 및 사용자 지정 라우팅 테이블

 ㅁ  로컬 경로 항목을 포함하는 모든 라우팅 테이블

    > 전체 VPC를 담당하는 로컬 경로

  > 로컬 경로 항목은 삭제 할 수 없음

 

 ㅁ  서브넷 당 라우팅 테이블은 하나, 즉 서브넷 별로 사용자 정의 라우팅 테이블 사용 필요

 

5.2. 보안 그룹을 통해 VPC  트래픽 보안

 

5.2.1. 보안 그룹

-  하나 이상의 인스턴스에 대한 인바운드 및 아웃바운드 트래픽 제어하는 가상 방화벽

-  기본적으로 모든 수신 트래픽을 거부하며 TCP, UDP 및 ICMP 프로토콜을 기반으로 필터링할 수 있는 허용 규칙을 사용

-  상태 기반이라 인바운드 요청이 허용되는 경우 아웃바운드 응답이 자동으로 허용

-  소스/대상을 CIDR 블록 또는 다른 보안 그룹으로 정의하여 보안 계층을 생성할 수 있음.

 

5.2.2. 보안 그룹을 사용하여 트래픽 제어

5.2.3. 보안 그룹이 구성되는 방법

-  기본적으로 모든 새롭게 생성되는 보안 그룹은 모든 목적지에 대한 모든 아웃바운드 트래픽을 허용

-  보안 그룹의 기본 아웃바운드 규칙을 수정하면 복잡성이 증가하므로 규정 준수에 필요한 경우가 아니면 수정하지 않는 것이 좋음

-  대부분 조직은 애플리케이션 내 각 기능 티어(웹/앱/데이터 등)에 대한 인바운드 규칙으로 보안 그룹을 생성

보안 그룹 체인 다이어그램

5.3. 네트워크 ACL

 

-  네트워크 ACL이란

 ㅁ  서브넷에서 송수신되는 트래픽을 제어하는 선택적 가상 방화벽

 ㅁ  기본적으로 모든 수신/송신 트래픽을 허용하며 상태 비저장 규칙을 사용하여 트래픽을 허용 또는 거부함

 ㅁ  ‘상태 비저장 규칙’은 모든 인바운드와 아웃바운드 트래픽을 검사하며, 연결은 추적하지 않음

 ㅁ  규칙은 보안 그룹처럼 인스턴스 수준이 아니라 서브넷 경계에만 적용함.

 

5.4. VPC로 트래픽 보내기

 

5.4.1. 인터넷 게이트웨이

-  VPC의 인스턴스와 인터넷 간에 통신 허용

-  기본적으로 가용성이 뛰어나며, 중복적이고 수평적으로 확장

-  인터넷으로 라우팅 가능한 트래픽을 위해 서브넷 라우팅 테이블의 대상을 제공

 

5.4.2. VPC 서브넷의 인스턴스에 대한 인터넷 액세스 활성 방법

 

-  인터넷 게이트웨이를 VPC에 연결

-  서브넷의 라우팅 테이블이 인터넷 게이트웨이를 가리키도록 함

-  서브넷의 인스턴스가 퍼블릭 IP 주소 도는 탄력적 IP 주소를 갖도록 함

-  NACL 및 보안 그룹에 관련 트래픽이 인스턴스에서 송수신되도록 허용해야 함.

 

5.4.3. 프라이빗 인스턴스의 아웃바운드 트래픽은 어떻게?

 

Network Address Translation 서비스

- 프라이빗 서브넷의 인스턴스가 인터넷 또는 다른 AWS 서비스로의 아웃바운드 트래픽을 시작하도록 활성화

-  프라이빗 인스턴스가 인터넷에서 들어오는 트래픽을 수신하지 못하도록 차단함.

-  두가지 기본 옵션

 ㅁ  퍼블릭 서브넷의 NAT로 설정된 Amazon EC2 인스턴스

 ㅁ  NAT 게이트웨이

 

5.4.4. 구성안

 

5.4.5. NAT 게이트웨이와 EC2 NAT 인스턴스 비교

구분	VPC NAT 게이트웨이	NAT 인스턴스
가용성	고가용성이 기본	스크립트를 사용해 장애 조치 관리
대역폭	10Gbps까지 순간 확장	인스턴스 유형의 대역폭에 따라 다름
유지 관리	AWS에서 관리	고객이 관리
보안	NACL	보안 그룹 및 NACL
포트 전달	지원하지 않음	지원
범위	가용 영역	가용 영역

 

5.4.6. 서브넷, 게이트웨이 및 라우팅

-  서브넷을 퍼블릭으로 만들려면, 인터넷 게이트웨이를 통해 라우팅해야 함

-  프라이빗 서브넷의 인스턴스가 데이터를 인터넷으로 송신해야 하는 경우, 트래픽을 NAT 인스턴스 또는 NAT 게이트웨이로 라우팅해야 함

-  보안 그룹을 사용하여 보안을 더욱 강화해야 함

 

6. VPC 트래픽 로깅

 

6.1. Amazon VPC Flow Log

 

I.        VPC의 트래픽 흐름 세부 정보를 캡처

II.      VPC, 서브넷 및 ENI에 대해 활성화 될 수 있음

III.     로그는 CloudWatch Logs로 게시됨

 

6.2. 사용 사례

 

I.        연결 문제 해결

II.      네트워크 액세스 규칙 테스트

III.     트래픽 모니터링

IV.     보안 인시던트 탐지 및 조사

 

7. 여러 개의 VPC 연결 방법

 

7.1. 고객 게이트 웨이 (CGW)

 

 

7.2. VPC PEERING

 

7.2.1. 개요:

 

VPC 피어링 연결을 사용하면 Peer VPC간 Traffic을 라우팅 할 수 있음

https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/what-is-vpc-peering.html

-  프라이빗 IP 주소 사용

-  상호 리전 지원

-  IP 공간은 중복 불가

-  2개의 VPC 사이에 하나의 피어링 리소스만 존재

-  전이적 피어링 관계 미지원

-  다른 AWS 계정 사이 구축 가능

 

7.2.2. 작동 방법

-  인터넷 게이트웨이나 가상 게이트웨이 필요 없음

-  단일 장애 지점 없음

-  대역폭 병목 현상 없음

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

 

7.2.3. 제한 사항

-  VPC당 생성할 수 있는 활성 및 보류 VPC 피어링 연결의 수 제한

-  VPC Peering은 전이적 피어링 관계 지원하지 않음

-  동일한 2개의 VPC간에 동시에 두 개 이상의 VPC 피어링 연결을 생성할 수 없음

-  VPC 피어링 연결에서 MTU는 1,500 Byte

-  배치 그룹은 피어링된 여러 VPC를 포괄할 수 있지만, 피어링된 VPC의 인스턴스간에는 양방향 대역폭이 제공되지 않음

-  VPC 피어링 연결에서는 유니캐스트 역 경로 전달은 지원되지 않음

-  피어링된 VPC에서 인스턴스 간에 프라이빗 DNS 값을 확인 할 수 없음.

 

7.2.4. VPC 피어링 규칙

 

7.2.5. VPC Peering 보안

-  피어링 연결 설정에는 양쪽 승인이 필요

-  라우팅 제어: 라우팅 테이블이 원격 서브넷에 라우팅할 수 있는 로컬 서브넷을 제어

-  보안 그룹이 인스턴스가 수신 또는 송신할 수 있는 트래픽 제어

-  네트워크 ACL이 서브넷이 수신 또는 송신할 수 있는 트래픽을 제어

-  엣지 투 엣지 라우팅 또는 전이적 트러스트 지원 안 됨: 실수로 예상치 못한 네트워크 연결을 생성하는 일이 줄어듦

 

8. 온프레미스 구성 요소 통합 (Hybrid Cloud)

 

8.1. 싱글 VPN을 통한 연결

2개의 VPN 엔드포인트 제공

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html

Amazon VPC란 무엇인가? - Amazon Virtual Private Cloud

8.2. 다수의 VPN을 통한 연결

I.  Amazon VGW는 다수의 고객 게이트웨이 연결을 지원 및 권장

II.  라우팅 구성 시 고객에게 유연성을 제공하도록 동적 및 정적 라우팅 옵션 둘 다 제공

III.  동적 라우팅은 BGP 피어링을 활용하여 AWS와 해당 원격 엔드포인트 간 라우팅 정보를 교환

IV.  BGP 사용 시 같은 고객 게이트웨이 디바이스에서 IPSec과 BGP 연결이 모두 종료가 되어야 하므로, IPSec과 BGP 연결을 둘 다 종료 할 수 있어야 함.

 

8.3. AWS Direct Connect

 

- AWS Direct Connect는 AWS와 사용자 데이터 센터 사이에 프라이빗 네트워크 연결 제공

- AWS Direct Connect는 AWS 클라우드 서비스에 액세스할 때 인터넷 대신 사용할 수 있는 네트워크 서비스

 

8.3.1. 이점

 

-  네트워크 전송 비용 절감

-  애플리케이션 성능 향상

-  대용량 데이터 세트 전송

-  보안 및 규정 준수

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

-  사설 데이터 센터 확장

-  인터넷 기반 IPSec VPN 연결 대안(IPSec VPN 연결은 페일오버에 사용 가능)

 

8.3.2. 구성안

-  예측 가능한 네트워크 성능

-  대역폭 비용 감소

-  1- 또는 10-Gbps 프로비저닝된 연결

-  BGP 피어링과 라우팅 정책 지원

 

8.3.3. 제한 사항

-  통신 및 호스팅 제공업체가 추가로 필요하거나 새로운 네트워크 회로를 프로비저닝해야 할 수 있음

 

1.8.3.4. AWS Direct 로케이션 목록

https://aws.amazon.com/ko/directconnect/features/

AWS Direct Connect 기능

 

9. AWS 아키텍처 개선

AS-IS	TO-BE

-  2개의 AZ로 복제

-  NAT 게이트웨이 대신 NAT 인스턴스 사용

 

10. 기본 VPC와 기본 서브넷

 

10.2 기본 VPC란

 

-  계정의 각 리전에는 기본 VPC가 있음

-  기본 CIDR은 172.31.0.0/16

-  VPC 기반 리소스(Amazon EC2, Amazon RDS, Elastic Load Balancing 등)를 생성하면서 사용자 정의 VPC를 지정하지 않으면, 리소스는 해당 리전 내 기본 VPC에 배치

-  기본 서브넷, IGW, 기본 서비넷을 IGW에 연결하는 기본 라우팅 테이블, 기본 보안 그룹 및 기본 NACL을 포함

-  다른 VPC와 같은 형태로 구성 가능(예: 서브넷 추가)

 

10.2 기본 서브넷이란

 

-  각 기본 VPC의 각 가용 영역(AZ)내에 생성됨

-  CIDR 블록 /20(IP 4,096개)이 할당된 퍼블릭 서브넷

-  IGW로 향하는 경로를 제거하면, 기본 서브넷(및 모든 퍼블릭 서브넷)을 프라이빗 서브넷으로 변환할 수 있음

-  새 가용 영역이 리전에 추가 되면 해당 리전의 기본 VPC가 새 가용 영역에 배치된 서브넷을 갖고 옴.

 

10.3. 기본 VPC와 기본 서브넷은 언제 사용해야 하나

 

-  기본 VPC와 서브넷은 AWS 계정을 실험할 때만 사용

 ㅁ  기본 VPC는 새로운 VPC VPC를 설정할 필요 없이, VPC 기반 리소스가 인스턴스를 시작하는 것을 테스트하는 간편한 방법 제공

 

-  실제 환경에서는 자체 VPC 및 서브넷 생성 필요

 ㅁ  VPC와 서브넷의 구성을 더 잘 제어하고 파악할 수 있음

 ㅁ  손쉽게 삭제하고 새로운 VPC 및 서브넷을 생성할 수 있음.

 

10.4. VPC 기본 고려 사항

 

-  CIDR 블록을 신중하게 선택 – “/16”으로 시작

-  여러 개의 작은 서브넷 대신 대규모 서브넷 사용

-  서브넷을 단순하게 유지하고 인터넷 접근성(Public/Private)에 따라 나눔

-  고가용성을 위해 VPC에서 다중 AZ 배포를 사용

-  보안 그룹을 사용하여 리소스 간의 트래픽을 제어

-  VPC Flow Log를 사용하여 VPC의 트래픽을 추적 및 모니터링

-  API 호출 또는 AWS Management Console응ㄹ 통해 VPN 링크의 상태 검사

 

11. 고가용성 환경 만들기 (파트 1: 로드 밸런싱 및 내결함성)

 

11.1 고가용성 정의

 

고가용성(HA)은 인적 개입 없이 애플리케이션의 가동 중단 시간이 최소화되도록 보장하는 것

구분	가동률	연간 최대 가동 중단 시간	일일 기준 가동 중단 시간
9가 1개	90%	36.5일	2.4시간
9가 2개	99%	3.65일	14분
9가 3개	99.9%	8.76시간	86초
9가 4개	99.99%	52.6분	8.6초
9가 5개	99.999%	5.26분	0.86초

 

11.2. 고가용성 설계 원칙

 

11.2.1. 단일 장애 지점 방지 (SPoF)

 

모든 기능은 장애가 발생한다는 가정하에 역방향으로 설계

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

잘못된 구성	모범 사례

 

11.2.2. 요구 사항 기반

 

-  복구 목표 시간(RTO) : 시스템이 얼마나 빨리 복구 되어야 하는가?

-  복구 목표 지점(RPO): 데이터 손실을 얼마나 감당할 수 있는가?

-  목표 달성 비용: 이러한 목표를 달성하려면 얼마나 많은 비용이 필요한가?

기본적으로 비기능적인 요구 사항이 인프라의 설계를 정의

고가용성과 내결함성 환경은 다중 AZ와 교차 리전으로 확장되지만 이러한 설계에는 비용이 추가

 

11.2.3. 고가용성 요소

 

-  내결함성

 ㅁ  애플리케이션 구성 요소의 기본적인 중복성

-  복구성

 ㅁ  재해 발생 후 서비스 복구와 관련된 프로세스, 정책 및 절차

-  확장성

 ㅁ  애플리케이션이 설계 변경 없이 성장을 수용하는 능력

 

11.2.4. On-Premise HA와 AWS HA 비교

 

-  기존 온프레미스 IT에서 고가용성은

 ㅁ  비용이 매우 많이 들고

 ㅁ  전적으로 미션 크리티컬한 애플리케이션에만 적합

-  AWS는 다음을 사용할 수 있도록 함으로써 다양한 가용성과 복구성 옵션을 제공

 ㅁ  여러 대의 서버

 ㅁ  각 가용 영역 내에 격리된 중복 데이터 센터

 ㅁ  각 리전 내에 여러 개의 가용 영역

 ㅁ  전 세계에 분산된 리전

 ㅁ  내결함성 서비스

-  다중 리전 배포로 인해 다음이 증가

 ㅁ  가용성

 ㅁ  비용

 ㅁ  복잡성

다중 리전 배포가 필요하지 않는 한, 단일 리전을 기본으로 함

단일 리전을 사용하는 경우, 다중 AZ가 가장 기본적인 HA 솔루션

 

11.2.5.     AWS 서비스 및 고가용성

 

11.3. Elastic Load Balancing (ELB)

 

11.3.1. ELB 특징

 

수신되는 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스에 걸쳐 분산하는 관리형 로드 밸런싱 서비스

-  인스턴스 간에 로드를 분산

-  비정상 인스턴스를 인식하고 이에 대응

-  퍼블릭 또는 내부 솔루션이 될 수 있음

-  HTTP, HTTPS, TCP 및 SSL(보안 TCP) 프로토콜을 사용

-  각 로드 밸런서에 퍼블릭 DNS 이름이 제공

 ㅁ  인터넷 연결 로드 밸런서는 로드 밸런서 노드들의 퍼블릭 IP 주소와 공개적으로 확인되는 DNS 이름을 가지고 있음

 ㅁ  내부 로드 밸런서는 로드 밸런서 노드들의 프라이빗 IP 주소와 공개적으로 확인되는 DNS 이름을 가지고 있음.

 

11.3.2. ELB 제품

 

https://aws.amazon.com/ko/elasticloadbalancing/features/#compare

DIY 로드 밸런서와 Elastic Load Balancing 비교

DIY	Elastic Load Balancing
비관리형(고객이 관리)     고객이 요구 사항에 맞게 Amazon EC2에 로드 밸런서 생성     조정은 고객이 처리해야 함	AWS에서 관리     일반적으로 가장 비용 효율적인 솔루션     자동 조정

 

11.3.3. Elastic Load Balancing 제공 기능

 

-  상태 확인

-  교차 영역 로드 밸런싱

-  프록시 프로토콜

-  고정 세션

-  연결 드레이닝

 

11.3.4. Elastic Load Balancing의 고정 세션

 

고정 세션 기능을 사용하면 로드 밸런서가 사용자의 세션을 세션의 수명 동안 특정 인스턴스에 바인딩할 수 있음

-  기간 기반 세션 고정은 각 요청에 대해 로드 밸런서 생성 쿠키를 사용하여 애플리케이션 인스턴스를 추적

-  애플리케이션 제어 세션 고정은 쿠키를 사용해 요청을 처리한 원래 서버에 세션을 연결함.

 

11.3.5. 로드 밸런스 용 연결 드레이닝

 

연결 드레이닝을 활성화하면 인스턴스가 등록 해지 되거나 비정상이 되는 경우, 로드 밸런서가 더는 새로운 요청을 백엔드 인스턴스에 전송하지 않음

연결 드레이닝은 Auto Scaling과 통합되어 로드 밸런서 뒤에서 용량을 보다 더 손쉽게 관리 가능

연결 드레이닝 활성화 방법

-  AWS Management Console

-  API

-  CLI

-  AWS CloudFormation

 ㅁ  https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

How Elastic Load Balancing works - Elastic Load Balancing

11.3.6. Cloud 설계 패턴: 다중 로드 밸런서 패턴

 

웹 애플리케이션에 액세스하는 디바이스 유형에 따라 설정이 다른 로드 밸런서를 여러 개 지정

11.3.7. 가용성 개선 아키텍처

AS-IS	TO-BE

 

-  인터넷 연결 로드 밸런서

 ㅁ  퍼블릭 서브넷에 배포됨

 ㅁ  2개의 가용 영역에 있는 웹 서버로 트래픽 분산

 

-  내부 로드 밸런서

 ㅁ  인트라넷 연결 또는 내부

 ㅁ  로드 밸런싱에 대한 VPC 액세스를 사용하여 클라이언트에서 EC2 인스턴스로 트래픽 분산

 

11.4. 탄력적 IP 주소

 

-  동적 클라우드 컴퓨팅에 적합하게 설계된 고정 IP 주소

-  Amazon EC2 인스턴스에 연결될 수 있음

-  사용자와 클라이언트가 같은 IP 주소를 가진 대체 리소스를 사용할 수 있게 함으로 인스턴스 또는 소프트웨어의 장애 숨김

 

12. 리전 전체의 HA 지원

 

12.1 Amazon Route 53

 

-  Amazon Route 53는 AWS에서 제공하는 신뢰할 수 있는 DNS 서비스

-  Amazon Route 53이라는 이름은 DNS 서버가 포트 53에서 쿼리에 응답한다는 사실에서 착안

12.2 Amazon Route 53 특징

 

-  안정성

 ㅁ  중복 위치

 ㅁ  100% 서비스 수준 계약(SLA)에 따라 지원

 

-  사용 편의성

 ㅁ  콘솔

 ㅁ  프로그래밍 방식 API

 ㅁ  도메인 이름 관리

 

-  빠름

  ㅁ  세계적인 Anycast 네트워크

  ㅁ  신속한 변경 전달

 

-  AWS와 통합됨

 ㅁ  ELB-Alias 쿼리

 ㅁ  지연 시간 기반 라우팅

 

-  비용 효율성

 ㅁ  저렴한 요금

 ㅁ  종량 과금제 모델

 

-  유연성

 ㅁ  지리 위치 라우팅

 ㅁ  가중치 기반 라운드 로빈

 ㅁ  셀프 앨리어싱

 

12.3. Amazon Route 53 지원 라우팅

 

-  단순 라우팅: 단일 서버 환경

-  가중치 기반 라운드 로빈: 리소스 레코드 세트에 가중치를 할당하여 빈도를 지정

 ㅁ  각 응답이 처리되는 빈도를 지정하기 위해 리소스 레코드 세트에 가중치 할당 가능

 

-  지연 시간 기반 라우팅: 글로벌 애플리케이션의 성능 향상 지원

 ㅁ  전 세계 사용자를 대상으로 애플리케이션의 성능 향상 가능

 ㅁ  LBR은 애플리케이션이 실행되고 있는 여러 AWS 리전의 실제 성능 측정치를 기준으로 가장 빠른 환경을 제공하는 AWS 앤드포인트로 고객을 라우팅

 

-  상태 확인 및 DNS 장애 조치: 주 사이트에 액세스 할 수 없는 경우 백업 사이트로 장애 조치

 ㅁ  웹 사이트의 가동 중단을 탐지하고 최종 사용자를 애플리케이션이 제대로 작동하는 대체 위치로 리디렉션 가능

 ㅁ  이 기능 활성 시 Amazon Route 53 상태 확인 에이전트가 가용성을 확인하기 위해 애플리케이션의 각 위치/엔드포인트를 모니터링하여 고객 사용 애플리케이션의 가용성 향상

 

-  지리 위치 라우팅: 대륙 별, 국가별 또는 미국 주 별로 지리적 위치 지정

 ㅁ  사용자의 지리적 위치(DNS 쿼리의 Origin)에 따라 트래픽을 지원할 리소스를 선택 할 수 있음

 ㅁ  지리 위치 라우팅 사용 시 콘텐츠를 현지화 하고 웹 사이트의 일부 도는 전체를 사용자의 언어로 표시 가능

 ㅁ  배포 권한이 있는 위치에만 콘텐츠를 배포하도록 제한 가능

 ㅁ  앤드 포인트 간 로드를 분산함으로 각 최종 사용자 위치를 일관되게 동일한 엔드 포인트로 라우팅 가능

 

12.4 Amazon Route 53 DNS 장애 조치

 

-  자체 애플리케이션의 백업 및 장애 조치 시나리오 구성

-  AWS 상 고가용성 다중 리전 아키텍처 활성화

-  여러 상태 확인, 도메인 이름 기반 상태 확인, 문자열 매치, 요청 간격 지정 등을 조합하여 상태 확인 기능 개선

-  문자열 매치:

 ㅁ  상태 확인 시 페이지 본문의 컨텐츠 처음 5KB안에서 특정 문자열 검색

 ㅁ  이를 이용해 DB 인스턴스가 작동 중인지 확인 가능 (DB 연결에 성공한 경우만 페이지에 포함되는 문자열을 매치)

 

12.5 사용 사례: 다중 리전 배포

 

Amazon Route 53에서는 사용자가 사용자와 가까운 미국에 있는 Elastic Load Balancing 로드 밸런서로 자동 리디렉션

-  이점

 ㅁ  리전에 대한 지연 시간 기반 라우팅

 ㅁ  AZ에 대한 로드 밸런싱 라우팅

 

12.6 일반적인 아키텍처

 

-  CNAME www에 대한 DNS 레코드 두개와 더불어 장애 조치 라우팅의 라우팅 정책 생성

 ㅁ  첫번째 레코드가 기본 라우팅 정책이며 웹 애플리케이션의 ELB 가리킴

 ㅁ  두번째 레코드는 “예비” 라우팅 정책이며 정적인 S3웹사이트(장애 안내 페이지)를 가리킴

-  Route 53 상태 확인을 통해 기본 라우팅 정책에 문제가 없는지 확인

 ㅁ  기본 레코드가 사용되었으면 모든 트래픽이 웹 애플리케이션 스택의 기본값이 됨

 

12.7 Amazon Route 53 참고 자료

 

-  Amazon Route53을 DNS 서비스로 사용하는 도메인 생성하기

 ㅁ  https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html

What is Amazon Route 53? - Amazon Route 53

-  기존 도메인을 Amazon Route 53으로 마이그레이션 하기

 ㅁ  https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/MigratingDNS.html

Making Amazon Route 53 the DNS service for an existing domain - Amazon Route 53

-  상위 도메인을 마이그레이션 하지 않고 Amazon Route 53을 사용하는 하위 도메인 생성하기

ㅁ  https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/MigratingSubdomain.html

Migrating DNS service for a subdomain to Amazon Route 53 without migrating the parent domain - Amazon Route 53

-  Elastic Load Balancing용 별칭 레코드 세트 생성하기

 ㅁ  https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

Choosing between alias and non-alias records - Amazon Route 53

13. AWS 외부에 있는 구성 요소 연결

 

13.1. VPN 연결 Architecture 1

-  각 VPN 연결은 두개의 터널로 구성되며, 각 터널은 고유한 가상 프라이빗 게이트웨이 퍼블릭 IP 주소 사용

-  이를 통해 VPN 연결에 대해 제한적이지만 자동으로 장애 조치가 보호됨

-  단, VPN 연결에 장애 발생 시 전체 연결 끊어질 가능성 있음.

 

13.2 VPN 연결 Architecture 2

-  VPN 연결 장애를 대비하여 VPC에 대한 두번째 VPN 연결 설정

-  중복 VPN 연결 및 고객 게이트웨이를 사용하여 이중화

-  동적으로 라우팅 되는 VPN 연결은 BGP(Border Gateway Protocol)를 사용하여 고객 게이트웨이와 가상 프라이빗 게이트웨이 간 라우팅 정보 교환

-  고정으로 라우팅 되는 VPN 연결에서는 고객 게이트웨이의 사용자 측 네트워크 고정 경로를 입력해야 함

-  BGP를 통해 알려지고 고정으로 입력된 경로 정보를 사용하여 양측의 게이트웨이는 사용 가능한 터널을 확인하고 오류가 발생할 경우 트래픽을 다시 라우팅할 수 있음

 

13.3 AWS Direct Connect 연결 Architecture 1 

13.4 AWS Direct Connect 연결 Architecture 2 (단일 라우터 및 듀얼 포트)

-  중복성은 BGP 정책을 기반으로 함

-  고객은 하나의 링크를 인바운드와 아웃바운드 트래픽 둘다 보다 우선하도록 BGP 정책을 설정

-  로컬 기본 설정과 MED 값이 두 링크 사이에서 동일하다면, 트래픽은 둘 모두에 대략적으로 로드 밸런싱 함

-  중복 Direct Connect 링크 설정 가이드

 ㅁ  https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html

Classic - AWS Direct Connect

14. Sample Architecture

 

14.1 IAM

 

14.2 Subnet 기본

 

14.3 그 외 설계 고려 사항

 

-  로드 밸런서

 ㅁ  탄력적 로드 밸런서에서 구성해야 하는 포트는 무엇인가?

 

-  데이터베이스

 ㅁ  RDS 또는 EC2 인스턴스를 사용해야 하나

 ㅁ  데이터베이스는 어떻게 확장되는가?

 

-  웹 서버 및 애플리케이션 서버

 ㅁ  컨텐츠는 어디에 저장되는가?

 ㅁ  리소스를 어떻게 보안해야 하는가?

 

14.4 Sample 솔루션