[AWS 구축 패턴] 1. 웹사이트

1. 기본 사이트

 

- 기본 웹사이트 설계, DomainName을 설정하여 원활히 접속하도록 설정

- EC2-EBS-Route 53

 

1) 기본 EC2-EBS로 구성된 웹서버 인스턴스와 스토리지를 기반

 

2) Route 53: AWS에서 제공하는, DNS 웹서비스. 도메인 이름을 등록하고 클라이언트 접근 시 DNS서버로 사용.

 

 

2. 다중 웹 사이트

 

- 웹서버 다중화

- DB서버 다중화

- CDN(컨텐츠 전송 네트워크)과 객체 저장소를 사용한 정적 컨텐츠 배포

- EC2-S3-RDS-ELB-클라우드 프론트

 

1) ELB: 로드밸런서

 

-  AMI: Amazon Machine Image, 하나의 EC2에서 인스턴스 여러개를 띄우고 싶을 때, AMI를 이용하여 같은 인스턴스 여러개를 띄운다. 같은 서버환경이 구축됨.

 

- 적용할 인스턴스와 Check 주기를 설정하여 자동으로 모니터링하도록 구성한다. 여러개의 인스턴스 중 부하가 낮은 서버로 자동으로 분산시켜준다

 

2) RDS: DB서비스

 

- AWS에의 RDB는 EC2 자체에 DB를 설치하거나, AWS RDS를 사용하는 방법이 있다.

- AWS RDS를 사용하면 여러가지 엔진을 선택할 수 있다(MySQL, Postgre 등)

- 다중화는 AZ를 통해 진행(이건 안써봐서 뭔지 모르것다)

 

3) S3: 오브젝트 저장소

4) 클라우드 프론트: CDN

- S3와 클라우드 프론트 모두 웹서버 역할을 한다(정적 컨텐츠 배포)-> 보통 정적 컨텐츠를 따로 배포하는 이유는 사용자가 많은 사이트에 대해 같은 리소스를 여러번 배포하므로 비효율적이기 때문

- CDN: Contents Distribution Network로 세계 각지에 배치된 서버에서 컨텐츠를 캐싱하고 전달: 서버접속 및 DB접속이 없으므로 부하 및 비용을 낮춘다

 

 

3. DB엔진 도입

 

 

- Auto-Scaling

- ElasticCache

- EC2-RDS-ELB-ElasticCache-CloudWatch

 

1) Auto-Scailing: 사용자 조정에 따라 트래픽에 맞춰 가용 인스턴스 갯수를 조절(자동 스케일업/다운), EC2에서 설정

2) CloudWatch: 스케일링 가동 여부는 CloudWatch에 의한 모니터링 결과로 결정. 모니터링 항목을 정하고 스케일링이 가동되도록 설정

 

3) ElasticCache: 우리가 아는 인메모리 캐시와 동일. 

 

 

4) (추가) RDS for Aurora: 캐시는 너무 빠른데, 그에 비해 DB접근은 많이 느리다. 보통 MySQL은 업데이트시 Rock을 걸고 트랜잭션 로그를 교환하며 업데이트를 하는데, Aurora는 로그 스토리지를 가지고 있어 Rock없이 로그 스토리지에서 읽어 업데이트가 가능하기 때문이다.  

 

 

4. 가용성 높이기

 

- 물리적인 장애를 고려한 설계

- 기본적으로 라우트 53이 메인 사이트의 장애를 감지하면 백업 사이트로 동적 라우팅한다. 데이터는 백업사이트로 자동 동기화한다.

- 복구가 필요한 경우에는 CloudWatch로 모니터링하다가 복구