[대규모 시스템 설계] 1장. 단일 서버 시스템 설계(3)

무상태(stateless) 웹 계층

• 웹 어플을 수평적으로 확장하려면, 상태 저보가 웹 계층에서 제거되어야 한다.

상태 정보 의존적인 아키텍처

• 상태 정보를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유가 되도록 한다.
• 반면 무상태 서버에는 해당 상태 정보가 없다.

상태 정보 의존적인 아키텍처의 문제점

• 그림 참고..
  1. 고정 세션 문제
     • 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야함.
     • 대부분의 로드 밸런서는 해당 문제를 지원하기 위해 고정 세션(sticky session) 기능을 제공한다.
       • 하지만 해당 기능은 로드 밸런서에 부담을 준다고 한다.
  2. 유연성의 저하
     • 로드 밸런서 뒤에 서버를 추가하거나 제거하기가 까다로워진다.
     • 서버의 장애를 처리하기도 복잡해진다.

상태 정보 의존적인 아키텍처 예시

• 사용자 A 의 세션 정보와 프로파일 이미지의 경우 서버 1로 저장.
• 요청이 서버 2로 전송되면 인증이 실패해버림
  • 서버 2에는 해당 세션 정보가 없음..

무상태(stateless) 아키텍처

• 상태 정보를 웹 서버로부터 분리하여 공유 저장소에 보관함으로써 단순하고 안정적이며, 확장이 용이한 구조를 제공함.
• 웹 서버 간의 상태 정보 의존성을 제거해서 트래픽에 따라 서버를 유연하게 추가하거나 제거가 가능하다.

무상태 아키텍처의 특징

• 공유 저장소의 사용
  • 모든 웹 서버는 필요할 때 상태정보를 공유 저장소에서 가져온다
  • 상태 정보는 웹 서버로부터 물리적으로 분리되어 있다(DB 서버)
• 단순해짐
  • 상태 정보 의존성이 없음. ⇒ 웹서버가 단순해짐
  • 웹 서버의 장애가 발생해도 다른 서버가 요청을 처리할 수 있음 ⇒ 안정성이 높다.
• 규모 확장에 용이하다.
  • 상태 정보가 서버에 없기에 웹 서버를 추가하거나 제거하기 쉽다
  • 자동 규모 확장 기능을 통해 트래픽에 따라 웹 서버를 동적으로 조절가능

기본 무상태 아키텍처

1. 사용자 A B C 가 HTTP 요청을 웹 서버로 전송한다.
2. 웹 서버는 필요한 경우 공유 저장소(shared storage) 로부터 상태 정보를 가져온다
3. 상태 정보가 웹 서버로부터 분리되어 있어서, 사용자의 요청은 어떤 웹 서버로도 전달될 수 있다.

글로벌적인 확장을 위해

• 전 세계 사용자에게 쾌적한 서비스 제공을 위해, 여러 데이터 센터를 지원하는 것이 좋음.
• 가용성 증대와 UX 개선이 가능하다.