이번 섹션에서는 AWS에서 어떻게 아키텍쳐를 구성할지 예시를 통해 배워보자

Enable scalability

1. 위의 두가지 예시를 비교해보자 1번 예시에서는 Capacity가 꽉 찬 경우 서버는 다운되고 사용자는 서비스를 이용하지 못 할 것이다. 이후 로그 혹은 항의를 통해 비상이 걸린 관리자가 새로운 서버를 실행하는데 걸리는 몇분간은 서비스가 다운될 것이다. 그러나, Cloud를 사용한다면 말이 달라진다. AWS의 경우 CloudWatch를 사용해서 EC2의 CPU 사용량이 설정한 한계(Ex:75%)를 넘는다고 하면 CloudWatch는 즉각 알람을 발생시키고 이로 인해 Auto Scaling을 통해 새로운 서버가 즉각 실행된다. 결국 서비스가 다운될 일은 없는 것이다.

   대신 비용은 좀 더 나갈 수 있겠지.(Trade off) 안정성↔비용

Automate your environment

1. 위의 예시를 비교해보자 만약 서버가 오류로 다운되었다고 생각해보자 이또한 마찬가지로 직접 확인하거나 소식을 듣지 않으면 알 수 없다.(물론, 머기업이라면 내부에 알람시스템을 만들긴 했겠지) 그러나, Cloud를 사용한다면 CloudWatch를 통해 서버가 다운된 것을 즉시 알람을 통해 알 수 있고CloudWatch가 자동적으로 새로운 인스턴스를 Launching함에 따라 즉각적인 대응이 가능해진다.

Treat resources as disposable

1. Resource를 일회용품 처럼 사용. Cloud를 사용함에 따라 기존에 인프라를 하드웨어 개념이 아닌 소프트웨어 개념으로 접근할 수 있다. 이는 결국 인프라를 언제든지 마음대로 조정할 수 있다. 위의 설명들을 보면 좀 더 이해 가능하다.

Use loosely coupled components

1. 전통적인 방식의 서버는 어플리케이션 계층과 매우 복잡하게 연결되어 있다. 이는 추후에 서버 하나를 삭제하거나 서버가 다운될 경우 매우 복잡도로 인해 복구에 많은 문제를 야기할 수 있다. 그러나 cloud를 사용한다면 말이 달라진다. Load balancing을 통해 트래픽을 적절히 제어할 수 있고 사용자의 목적지도 제어할 수 있으므로 복잡도가 낮고 오직 Load balancing에만 잘 연결되어있으면 알아서 처리해주기 때문에 매우 단순한 구조가 된다.(이를 보아 AWS의 Load Balancing은 L7 로드밸런싱인가 보다…)

Design services, not servers

1. 서버가 아닌 서비스에 집중해라. EC2를 통해 서버를 직접 구축하고 자유자재로 사용할 수 있지만 항상 EC2가 최선은 아니다. Container 혹은 Serverless를 사용해서 구축할 수 있는 만큼 다양한 사양들을 보고 결정하고 서비스 로직을 구현하는데 집중해라. 왜? EC2보다 구축하는데 훨씬 편하니까 ㅋ

Choose the right database solution