Classic Solution Architecture 비교하며 이해하기(AWS)

총 2가지 경우를 두고 아키텍쳐에 대해 공부해보았다. 

1. Stateless Web APP

개념

• 서버는 요청 간에 상태를 저장하지 않음
• 각 요청은 독립적이며, 필요한 모든 정보를 클라이언트가 매번 보내야 함
• 주로 REST API가 이 구조

예시

• RESTful API 서버
• CDN 기반의 정적 웹사이트
• JWT (JSON Web Token)로 인증 처리하는 SPA (Single Page Application)

2. Stateful Web APP

개념

• 서버는 사용자 상태(세션, 로그인 정보 등)를 기억
• 사용자의 이전 요청 정보를 바탕으로 다음 요청을 처리

예시

• 전통적인 웹 애플리케이션 (ex. JSP/Servlet, PHP)
• 로그인 후 쇼핑 카트나 게임 세션 유지
• 세션 기반 로그인 방식 (서버에 session ID 저장)

Stateless Web APP

 

가정: 특정 Domain으로 요청을 보내면 시간을 알려주는 서버가 있다.

 

 

스펙은 EC2의 가장 기본인 T2.Micro를 사용하고 있다.

여기서 이제 요청자 수가 많아졌다고 가정하자. 그리고 그에 따라 스펙도 M5로 Scale Up 되었다고 가정

 

문제는 이제 T2에서 M5로 바뀌는 과정에서 다운타임이 존재한다는 것이다. 그래서 이문제를 해결하고자

Scale Up이 아닌 Scale Out을 진행하기로 했다.

문제가 없을 것 처럼 보이지만 현재 Rout53의 정책은 A Record(IP기반 라우팅)을 따르고 있고 TTL은 1시간이 기준이다.

그렇다면 만약 하나의 EC2가 다운된다면 어떻게 될까?

해당 서버에 요청을 보내고 있던 요청자는 서버가 다운되었다고 알것이고, 일정 시간(TTL) 동안 사용하지 못하게 된다.

그래서 이제 해결할 수 있는 방법이 ELB와 ASG를 사용하는 것이다.

이렇게 될 경우, ELB가 적절한 사용 가능한 서버로 로드밸런싱 해주기 때문에 위와 같은 문제가 발생할 수 없다.

여기서 좀 더 고도화 시켜 보자면,

 

특정 가용 영역에 문제가 발생할 경우를 대비해서 ASG에도 여러 인스턴스를 Multi AZ에 구축을 해두면 더 좋다. 또한 비용 효율성을 고려한다면 ASG의 인스턴스에 대해 Minimum 혹은 Desired 값을 측정해둘 수 있다.

 

이래서 현재 위의 Architecture를 Classic Solution Architecture라고 부르기도 한다.

 

이번에는 Stateful WebApp에 대해서 살펴보았다.

 

 

Stateful WebApp

가정: 쇼핑몰 웹사이트, 장바구니에 물품들을 담아서 이용중

 

 

처음에는 아까 봤던거와 마찬가지로 MutiAZ에 인스턴스를 둔 ASG와 Route53 -> ELB로 라우팅을 하고 있다. 문제는 다음과정에서 발생한다.

A는 홈페이지에서 특정 물품들을 장바구니에 담고 있는 중이다. 중간에 새로고침을 눌렀는데 장바구니에 담아두었던 물품들이 전부 사라졌다. 이는 새로고침을 통해 다시 요청을 보내면서, ELB가 새로운 서버로 연결을 시켜 기존 데이터가 사라진 것이다.

 

이런 경우에는 다음과 같은 방식으로 해결 할 수 있다.

 

1. Stickiness (Session Affinity)

Sticky Session이라는 것을 통해 계속해서 같은 서버로 요청을 보내는 것이다. 즉, 기존 장바구니가 지워지거나 버려지는 경우가 확실히 줄어든다.

 

2. User Cookies

HTTP 요청에 Cookies를 담아 보내는 방식이다. 즉 Cookies에 장바구니에 담긴 목록과 정보를 전부 담아서 보낸다.

이렇게 되면 다른 서버로 요청이 보내지더라도 쿠키에 장바구니가 저장되어 있기때문에 문제가 없다.

 

다만, 다음과 같은 문제가 발생한다.

 

1. HTTP 요청이 쿠키를 담아 보내면서 무거워진다.

2. 보안성이 떨어진다.

3. 쿠키의 크기가 4KB를 넘으면 안된다는 제약이 있다.

 

이제 위 문제들을 해결하기 위해 Server Session이라는 것을 사용할 수 있다.

 

3. Server Session

 

A. AWS ElastiCache 사용

캐시 저장소를 사요함으로써 장바구니 정보를 캐시 DB에서 받아온다.

 

B. AWS RDS(DB 사용)

이 경우에는 RDS를 사용하는데, RDS의 Read Replicas를 활용하여 순전히 읽기 목적으로 위한 DB를 두는 것이다.

 

C. Lazy Loading

이 경우는 위 A, B 방법을 혼합하여 사용했다고 생각하면 된다.

 

Cache DB에 정보가 있다면, Cache DB에서 요청을 보내고 받는다. 만약 캐시가 비어있거나 없는 RDS DB로 요청을 보내서 받아온다. 

 

---

이번에는 직접 모놀리식 Architecture부터 전통적인 Classic Soultion Architecture까지 하나하나 장단점을 비교해보면서 어떤식으로 고도화 시키는지에 대해 공부해 보았다.

 

솔루션아키텍트의 기본이자 가장 중요한 부분은 바로 'WHY'라고 생각한다. 왜 사용했는지, 왜 이런식으로 구축했는지에 대해 고민해보고 비교할 수 있는지를 잘 설명해야 한다고 하는데 이번 기회로 조금이나마 도움이 되었다.