02.Cloud Design Pattern

1. 멀티서버 패턴

Multi-Server 패턴(서버의 다양화)

다수의 가상서버(EC2)와 로드밸런싱 기능 ELB 하나로 구성된 형태. 인스턴스 장애로 인한 시스템 정지를 방지.

 

2. Scale Up 패턴

request 양에 따라 서버의 스펙이 자유롭게 확장-축소가 가능한 패턴. 자원부족으로 인한 시스템 정지 및 이러한 손실을 방지. 축소의 경우 불필요한 비용도 감소하는 장점 있음.

 

3. DB Replication 패턴

Replication 패턴(서버의 복제)

시스템 장애시 데이터 손실되지 않도록 db를 복제하는 구성. RDS를 서로 다른 Availability Zone에 배치시켜 데이터를 복제.

 

4. Functional Firewall 패턴

 

Functional Firewall 패턴(계층별 접속)

서버 별 역할에 따라 접속에 차등을 둠. EC2와 RDS에 보안그룹을 설정하고 필요한 통신만 허가하는 방식.
그룹 단위의 보안그룹을 설정한다(서버마다 설정시 오류 발생 가능성 o)

 

1. Region : AWS 데이터 센터가 설치된 지역. 
2. GovCloud : 리전과 동일하지만 미국의 정부부처, 계약된 소수기업만 사용하는 리전을 말함.
3. Availability Zone(AZ) : 리전 내에는 복수의 az 존재. 물리적으로 격리된 장소이며 다른 환경에서 운용되고 있음.
   동릴 az 안에서의 통신은 개인 IP 주소이므로 통신비용이 들지 않지만 타 지역 az 통신은 글로벌 ip를 사용하여 접속하므로 통신비용이 든다. 또한 같은 az 안에서 장애 발생 시 동일 리전 가동되고 있는 서버 또한 영향 有.
   
   -> DRS(Disaster Recovery System) 구축시 다른 az에서 운용하는게 좋은 이유가 이것 때문.  이때 다른 az 내에서 운용하는 구성을 Multi AZ 구성이라고 함(시스템 가용성 향상)

---

2022.04.11

DRS 구성시 같은 az 내에서 발생한 문제를 해결해야 하므로 같은 az에서 운용하는 것인 줄 알고 착각했었다.
인프라 구성에 정석 정답은 없지만, 현재 근무하는 회사나 서비스하는 규모와 범위 내에서 최대한의 가용성을 이끌어내면서 효율적으로 설계하는게 낫다는 것을 다시 알게 됨. RTO만 알기보단 DRS 개념까지 보다 더 자세하게 한번 더 짚는 계기가 됐다.