aws 기본 architecture

1. Stateless Web App

서버에 상태가 저장되지 않고 단순히 api response 로 작동하는 단순 Web App

 

 

Route53 에 의해 DNS가 쿼리되고 사용자들은 Health Check되는 ELB에 의해 Webapp 에 LoadBalancing 되어서 각 EC2에 요청을 보내고 응답을 받는다. 

 

2. Stateful Web App

서버에 상태가 저장되어 클라이언트와 서버가 지속적으로 동기화 되어야 하는 WebApp

Route53 에 의해 DNS가 쿼리되고 사용자들은 Health Check되는 ELB에 의해 Webapp 에 LoadBalancing 되어서 각 EC2에 요청을 보내고 응답을 받는다. 단지 Auto Scailing Group 일 경우 병렬로 존재하는 EC2가 각 Response에 사용자의 정보가 누락될 가능성이 존재한다. 만일 쇼핑몰 사이트에서 장바구니에 쇼핑 목록이 담겼다면 계속해서 1번 EC2에 요청을 보내야 한다. 그렇지 않고 2번 EC2에 요청을 보낸다면 장바구니는 초기화 될것이다. 이때 사용하는 것이 Stickiness Session이다. Stickiness Session은 Client가 한번 요청을 보낸 EC2로 계속해서 Request를 보낸다.

2-1 Cookie 사용

Session affinity 는 만일 요청을 보내고 있던 EC2가 Down된다는 하는 경우 사용자가 그 EC2가 복구 될 때까지 사이트 접속을 하지 못하는 경우가 생긴다. 이는 그렇기에 사용자의 Request의 Header에 Cookie를 사용해 사용자의 정보를 보내는 방법을 사용할 수 있다. 이 경우 Client의 Cookie값에 의해 현재 사용자의 Session을 정의할 수 있기 때문에 사용자의 정보를 어느 인스턴스로 요청을 보내던지 잃어 버리지 않는다. 하지만  Cookie는 공격자의 공격에 너무 취약하고, http 리퀘스트가 너무 무거워져서 요청과 응답이 늦어질 가능성이 있다.  그래서 Cookie 방식은 추천하지 않는다.

2-3 ElasticCache 사용

ElasticCache를 사용해 Session 정보를 저장하고 각 요청에 대해 Store/Retrieve 하는 방법, 이 방법은 공격자의 공격에 안전하고 매우 흔하게 사용되는 방법이다.

2-4 DB에 저장

DB에 Session정보를 저장. RDS를 사용시 Read Replicas를 둬서 RDS의 성능에 영향을 주지 않게 한다.

2-5 Lazy Loading

처음 사용자가 요청하면 cache에 요청을 보내고 해당 정보가 없으면 RDS에 Write를 한다. 이후 Elastic Cache에 해당 정보를 cache하고 이후 정보는 cache에 요청해 Session을 관리한다. 즉 RDS는 Cache의 저장 정보를 관리하는 Master용도로 사용되고 cache는 이후 이 정보를 빠르게 각 인스턴스에 Request/Response 한다. 이는 RDS에 대한 traffic을 줄이고 CPU사용량을 줄인다.