이 문서는 [AWS 패턴] 배워서 바로 쓰는 14가지 AWS 구축 패턴을 읽고 정리한 내용입니다. 책의 내용을 개인적인 견해를 포함하여 정리한 내용입니다.
개요
일반적인 웹 서비스를 호스팅 하기 위한 4가지 패턴을 소개하고 있다.
이벤트 사이트
기업 웹사이트
성능을 중요시 하는 인트라 웹
가용성을 중시하는 인트라 웹
이벤트 사이트
아래의 요구사항을 충족하는 이벤트 사이트를 설계할 것
1개월 한정으로 이용한다.
사이트 사용자는 개인 사용자로서 인터넷으로 접속한다.
접속자 수는 많지 않아 고사양 서버는 필요없다.
웹 서버로 LAMP(Linux, Apache, MySQL, PHP) 환경을 사용한다.
비용ㅇ을 우선하며 다중화나 백업은 고려하지 않는다.
핵심 설계사항
리전 선택
네트워크 구성
서버 구성
호스팅존 구성
아키텍처 구성
기본적인 네트워크 구성
VPC + IGW + RTB
기본적인 서버 구성
Route53
EC2 + EBS + EIP
핵심 설계사항 1 - 리전 선택
리전 별로 물리적이 거리 및 비용이 다르기 때문에, 비용과 속도 중에 우선순위에 따라서 결정하면 됩니다.
핵심 설계사항 2 - 네트워크 구성
사설네트워크망을 Amazon VPC를 이용해서 구축합니다.
서버 목적로 Amazon Subnet을 만들고 해당 Subnet은 사용하려고 계획한 AZ의 숫자만큼 쌍으로 생성해야 합니다. 즉, 2개 유형의 서버를 2개의 AZs에 만든다면 Subnet은 4(= 2 × 2)개를 만들어야 합니다.
여기서 AZ(Availability Zones)는 N개 이상의 물리적 장소에 논리적으로 구성되어 있는 단위입니다.
즉, 서울에 4개의 물리적인 장소가 별도로 존재하며 4개의 AZ가 존재합니다.
이는 다음과 같이 물리적인 장소 4개에 걸쳐있는 4개의 논리적인 구분으로 구성됩니다.
도서에서는 로드 밸런서를 사용하지 않고 단일 EC2를 사용하고 있습니다.
도서에서는 단일 AZ, 단일 EC2를 사용하고 있으나 이 것은 99.5%의 SLA를 가진 저가용성, 저확장성 아키텍처입니다.
따라서 저는 복수 AZ, 복수 EC2를 사용하는 99.99%의 SLA 구성을 가지는게 좋다고 생각합니다. 여기에 ELB, ASG를 추가하여 고가용성, 고확장성 아키텍처를 구성하는게 좋습니다.
핵심 설계사항 3 - 서버 구성
이벤트 사이트에서 웹 서버를 담당할 AWS EC2 Instance를 작성할 것입니다.
AWS EC2 Instance는 AWS 상의 가상 서버로 아래의 설정을 가지도록 구성합니다.
OS : Amazon Linux 2 AMI (HBM)
Type : t3.medium (2 vCPUs, 4 GiB, -)
[도서]
도서에서는 LAMP 스텍이라면, 아래의 서버 요구사항이면 충족하다 나와있습니다.
즉 2GB MEM이 필요하기 때문에 약간의 여유를 포함하여 CPU는 1~2개, MEM은 3GB 이상이면 됩니다. 이를 충족하는 최소 스펙인 t3.medium을 선택하였습니다.OS = 1GB MEM
MySQL 등 미들웨어 = 1GB MEM
퍼블릭 IP 주소 자동할당(Auto-assign Public IP) : 비활성화
[도서]
도서에서는 퍼블릭 IP 주소 할당을 비활성화하고 고정 IP(EIP, Elastic IP)를 사용하고 있습니다.[견해]
저는 복수 AZs, 복수 EC2를 사용할 것이기 때문에 로드 밸런서를 별도로 사용할 것입니다. 이에 따라서 고정 IP또한 필요 없습니다.
단, 로드밸런서 없이 서버에 직접 연결을 할 것이라면 퍼블릭 IP 주소 자동할당 보다 고정 IP가 좋습니다. 퍼블릭 IP 주소는 인스턴스 중단 및 재시작 시 변경됩니다.
또한 Amazon EC2 Instance가 사용할 보안그룹을 아래와 같이 설정합니다.
Inbound Rule
도서
Type
Protocol
Port Range
Source
SSH
TCP
22
집 또는 회사의 퍼블릭 IP 주소
HTTP
TCP
80
0.0.0.0/0
HTTPS
TCP
443
0.0.0.0/0
견해 (👍)
Type
Protocol
Port Range
Source
SSH
TCP
22
집 또는 회사의 퍼블릭 IP 주소
HTTP
TCP
80
Amazon ELB의 ARN(고유식별키)
Outbound Rule : 전체 허용되는 기본값 유지
로드 밸런서의 보안그룹도 아래와 같이 설정합니다.
Inbound Rule
도서 : 사용 안함
견해 (👍)
Type
Protocol
Port Range
Source
SSH
TCP
22
집 또는 회사의 퍼블릭 IP 주소
HTTPS
TCP
443
0.0.0.0/0
Outbound Rule : 전체 허용되는 기본값 유지
로드 밸런서의 타켓 설정은 HTTPS:443으로 요청을 전달받아서 대상 그룹인 EC2 들의 HTTP:80으로 포워딩하도록 구성합니다.
핵심 설계사항 4 - 호스팅존 설정
Amazon Route53 호스팅 존을 생성합니다.
기본적으로 제공되는 SOA, NS 레코드는 그대로 유지합니다.
추가적으로 Amazon Certificate Manager로 HTTPS 설정을 하기 위한 TLS/SSL Certificate를 발급받습니다. 해당 인증서를 DNS 쿼리 질의 방식으로 인증할 것이기 때문에, Amazon Route53에 TLS/SSL Certificate에 대한 CNAME Record를 만듭니다.
마지막으로 Amazon ELB(Elastic Load Balancer)를 향한 A Record를 만듭니다.
전달할 때는 Amazon ELB의 별칭 ARN을 사용하도록 구성합니다.
운영 중에 리소스 변경하기
[도서]
서버 : 단일 EC2의 경우 서버를 종료하고 인스턴스를 변경해야 합니다.
디스크 : EBS 볼륨을 추가하고 EC2안에서 마운트(Mount) 해야합니다.
[견해]
서버 : 복수의 AZs, 복수의 EC2가 있는 경우 새로운 서버를 하나 만들고 요청이 들어가도록 해도 됩니다.
디스크 : EBS 볼륨을 추가하고 EC2안에서 마운트(Mount) 해야합니다.
이벤트 사이트 종료하기
불필요한 리소스를 모두 제거해야 합니다.
특히 호스팅존도 0.5$의 비용이 지출되므로, 불필요하다고 판단되면 제거해야 합니다.
Route53 Hosting Zone
EIP(Elastic IP) — 사용했다면 제거할 것
ELB(Elastic Load Balacner)
TG(Target Group)
EC2(Elastic Compute Cloud)
EBS(Elastic Blcok Storage)
추가적으로 아래 리소스들도 정리하여 깔끔하게 만들도록 합시다.
Securty Group
VPC(Virtual Prviate Cloud)
IGW(Internet Gateway)
RTB(Routing Table)
Subnet
결론
챕터 제목은 이벤트 사이트라고 되어 있지만 정확한 명은 일회용 사이트가 적합하다는 생각이 들었습니다.
아키텍처에서 아쉬운 점은 간단한 배포를 추구한 나머지 가용성, 확장성이 매우 낮았습니다.
기존의 아키텍처를 그대로 유지하면서 수정을 한다면 ELB, TG, ASG 등을 추가하는 것이 깔끔해보입니다.
하지만 조금 더 근대화된 아키텍처로 고가용성, 고확장성을 선택할 수 있다면 아래와 같이 할 것 같습니다.
서버와 데이터베이스 분리
서버는 ELB + EC2에서 API Gateway + Lamba로 변경 (사용자 수가 적기 때문)
데이터베이스는 RDS Aurora Serverless 사용 (사용자 수가 적기 때문)
이를 통해서 최소 비용으로 고가용성, 고확장성 아키텍처를 구성할 수 있을 것 같습니다.
기업 웹사이트
아래 요구사항을 충족하는 기업용 웹사이트 만들 것
공개 웹사이트로 사용자는 거래처, 잠재적 지원자, 입사 지원자 등이다.
정적 콘텐츠 중심이다.
서버를 다중화하여 장애에 대비한다.
부하가 높아지면 서버를 추가할 수 있게 구성한다.
장애 서버의 교체, 추가는 수동으로 조작한다.
응답시간과 비용을 고려하여 구성한다.
핵심 설계 사항
웹 서버 다중화
DB 서버 다중화
CDN과 객체 저장소를 사용한 정적 콘텐츠 전송
