[SAA] MyClothes.com

Stateful Web App: MyClothes.com

• 사람들이 온라인에서 옷을 살 수 있게 하며 돌아다닐 때 사용할 수 있는 쇼핑 카트가 있고 수백명의 유저들이 동시에 존재
• 모든 유저들은 웹사이트를 탐색하고 우리는 쇼핑 카트의 상태가 있더라도 앱을 확장할 수 있으며 수평적 확장성을 유지하고 싶음
  그러므로 유저들이 웹사이트를 탐색하는 동안 쇼핑 카트를 잃어버리게 해서는 안 됨
• 주소 등과 같은 세부 정보는 데이터베이스에 효과적으로 저장 가능해야 하며, 어디에서는 접근 가능하도록 해야 함
• 또한 가능하면 우리의 앱을 웹 계층을 가능한 무상태형으로 유지하기를 원함
  무상태형 : 질문에 답하기 위해 어떤 데이터베이스나 외부 정보도 필요 없음
  
• 유저가 있고 Route 53과 Multi AZ ELB가 존재하며 자동 확장 그룹과 세 개의 AZ가 기본일 때
  만약 유저가 한 인스턴스를 정해 말할거라고 한다면 그 인스턴스에 쇼핑 카트를 생성하게 되고
  다음 요청은 같은 인스턴스가 아닌 다른 인스턴스로 가게 되어 쇼핑 카트를 잃어버리게 된다면 나쁜 웹사이트가 됨
  이를 고치기 위해 ELB 기능을 이용한 Stickiness (Session Affinity)를 이용
  
  

  

Introduce Stickiness (Session Affinity)

• 유저가 첫 번째 인스턴스에게 말을 해 무언가를 쇼핑 카트에 추가한 후 
  두 번째 요청, 세 번째 요청 ˙˙˙ 을 할 경우 Stickiness 때문에 다른 인스턴스가 아닌 똑같은 인스턴스로 가게 됨
  
• 하지만 만약 EC2 인스턴스가 어떤 이유로 종료된다면 쇼핑 카트를 잃어버리게 되므로 이에 대한 개선이 필요
  
• 그 개선으로 쿠키를 소개
  
  

Introduce User Cookies

• EC2 인스턴스가 쇼핑 카트의 내용을 저장하는 대신 유저가 쇼핑 카트의 내용을 저장하는 사람일 경우,
  유저는 로드 밸런서에 매번 연결되고 쇼핑 카트에 모든 것이 있다고 말할 수 있으며 이는 웹사이트 쿠키를 통해 이루어짐
• 또한 유저가 첫 번째 서버, 두 번째 서버, 세 번째 서버와 말을 한다면 쇼핑 카트 내용을 직접 보내는 유저가 한 명이므로
  각 서버는 쇼핑 카트의 내용이 무엇인지 알 수 있게 됨
  이로인해 각각의 EC2 인스턴스가 이전에 무슨 일이 있었는지 알 필요가 없으므로 무상태형을 달성할 수 있음
• 하지만 쇼핑카트에 무언가를 추가할 때마다 웹 쿠키에 더 많은 데이터를 보내야 하므로 HTTP 요청이 점점 더 무거워지며
  공격자에 의해 쿠키가 변형될 수 있어 보안 위험도 가지게 됨
  또한 쿠키는 전반적으로 4kbyte 미만이므로 쿠키에 큰 데이터 셋을 저장할 수 없음
• 이 쿠키 아이디어를 발전시켜야 함
  
  

Introduce Server Session

• 웹 쿠키에서 전체 쇼핑 카트를 보내는 것 대신에 세션 ID를 전송하며, 백그라운드에서는 ElastiCache Cluster가 존재해야 함
• 세션 ID를 보낼 때는 이것을 카트에 추가할 것이라며 EC2 인스턴스와 이야기해야하므로
  ElastiCache에 카트 내용과 검색할 ID를 추가하고 이 내용은 세션 ID가 됨
• 유저가 세션 ID로 두 번째 요청을 할 때 다른 EC2 인스턴스로 이동하면
  다른 EC2 인스턴스는 ElastiCache에서 카트의 내용을 조회하기 위해 세션 ID로 세션 데이터를 검색
• ElastiCache는 밀리초 미만의 성능을 가지고 있어 이 과정이 매우 빠르게 일어날 수 있다는 장점을 가지며
  어떤 공격자도 ElastiCache를 바꿀 수 없어 더욱 안전함
• 세션 데이터 저장의 대안으로 DynamoDB를 사용하기도 함
  
  

Storing User Data in a database

• 사용자 데이터를 데이터베이스 안에 저장하고 싶고 사용자 주소도 저장하고 싶을 때
  장기 저장용인 RDS와 이야기함으로써 주소와 이름, 기타 등등의 사용자 정보를 직접 저장하고 검색할 수 있음
• 또한 인스턴스가 각각 RDS와 말할 수 있어 효과적으로 Multi AZ 무상태형을 달성할 수 있음
  
  

Scaling Reads

• 웹사이트가 운영되면서 대부분의 유저들이 웹사이트를 탐색하는 일을 하고 있다는 것을 깨달아 읽기를 확장하고 싶을 때
  쓰기 작업을 수행하는 RDS 마스터를 사용할 수 있음
• 일부 복제가 발생하는 RDS 읽기 전용 복제본을 가지고 무언가를 읽을 때마다 읽기 전용 복제본에서 읽을 수 있음
  RDS에 최대 5개까지 읽기 전용 복제본을 가질 수 있게 RDS 읽기를 확장할 수 있음
  
• 반면 더 많은 비용을 지불해야하는 단점이 존재
  
  

Scaling Reads (Alternative) – Write Through

• 캐시를 사용하는 Write Through를 통해서 EC2 인스턴스와 이야기하여 읽기를 확장할 수 있음
• 유저가 EC2 인스턴스와 이야기를 하여 필요한 정보를 가지고 있는지 물어보고
  만약 갖고 있지 않다면 RDS에서 읽어와 다시 ElastiCache에 저장하고
  똑같은 질문이 들어올 경우 캐시에 저장되어 있기 때문에 캐시 히트를 얻고 즉시 응답을 얻을 수 있음
• 이를 통해 RDS에서 더 적은 트래픽을 처리할 수 있어 CPU 사용량을 줄이고 성능을 개선시킬 수 있음
  반면, 캐시를 유지관리해야하며 더 많은 비용을 지불해야하는 단점이 존재
  
  

Multi AZ – Survive disasters

• 재난 상황을 피하고 싶을 때는 로드 밸런서를 Multi AZ로 만들고, RDS도 Multi ZA를 가져
  재난이 발생할 때마다 넘겨받을 수 있는 대기 복제본을 가지게 되며, ElastiCache 또한 Redis를 사용할 경우 Multi AZ를 가짐
• 반면 더 많은 비용을 지불해야하는 단점이 존재
  
  

Security Groups

• 보안 그룹을 통해 매우 안전해지길 원할 때, ELB 측에서 오는 HTTP 트래픽을 위해 HTTP를 열게 되어
  EC2 인스턴스, RDS, ElastiCache는 로드 밸런서로부터 오는 트래픽 받도록 직접적으로 들어오는 트래픽을 제한
  
  

In this lecture we’ve discussed… 3-tier architectures for web applications

• ELB sticky sessions
• 쿠키를 저장하고 웹 앱을 상태 비저장(무상태)으로 만들기 위한 웹 클라이언트
• ElastiCache 사용
  - For storing sessions (대체 : DynamoDB)
  - For caching data from RDS
  - 다중 AZ
• RDS 사용
  - For storing user data (훨씬 더 오래가는 타입의 데이터)
  - 읽기 확장을 위한 읽기 전용 복제본
  - 재해 복구를 위한 다중 AZ
• 서로를 참조하는 보안 그룹을 통한 철저한 보안
  (웹 계층, 고객 계층, 데이터 계층을 서로 참조)