웹 서비스 아키텍처 상식

4 Mar 2021 ~ 4 Mar 2021

웹서비스 아키텍처

현재 내가 사용하는 spring boot는 tomcat을 통해 데이터를 주고 받고, tomcat으로 들어온 정보를 spring에서 처리해준다 (WAS)
tomcat은 was이고, spring은 tomcat위에서 돌아간다. 통틀어서 WAS라고 부른다.
보통 웹서버(아파치 등)과 웹어플리케이션 서버를 통해서 서비스한다.
정적인 컨텐츠(html,css,js 등)는 웹서버에서 처리한다.
웹서버를 사용하는 이유 : 성능, 보안
- 성능: throughput, 시간당 동시접속자 처리량이 좋기 때문에
- 요즘은 아파치보다 nginx를 더 많이 사용한다.
  - 스레드 기반 vs 이벤트 기반
  - http://aosabook.org/en/nginx.html
Database
- 데이터의 영구적인 저장 및 관리(읽기, 쓰기)
서비스에선 DB 백업은 필수
- 1년에 디스크 폴트 확률이 15%정도 된다.
1. 새로운 서버를 들여서 DB 백업
  - IDC(Internet Data Center)
  - 서버를 해킹당하거나 물리적으로 무너지면 데이터가 날아갈 위험
2. 클라우드 환경에 DB 백업
  - 클라우드는 데이터가 날아갈 확률이 100만년에 1건정도
  - 매우 안전하다.

웹서비스 아키텍처 예: 서버가 3대일 때
- 서버1: WebServer + WAS
- 서버2: DB(Primary)
- 서버3: DB(Secondary)
- 클라우드: 로그 백업(서버1), 미디어 백업(서버1), DB 백업(서버2)
- 미디어(이미지, 동영상)은 DB에 저장하지 않고, WAS가 있는 서버에 파일로 보관한다.(속도 때문에)
- 미디어를 주고받기 위한 API만 WAS로 구현하여 미디어 서버를 따로 두기도 한다.
- 서버3은 서버2의 DB를 실시간 복제한다. (또는 읽기전용 DB로 쓰기도 한다.)
  - 클라우드 백업은 하루에 한번, 일주일에 한번 등과 같이 주기를 가지고 백업을 하기 때문에 서버3과 차이가 있다.
- 클라우드를 통해 살리려면 몇시간이 걸릴지 모른다(전체 데이터를 복사하기 때문에) 그러나, 서버3을 사용해 살리면 몇분밖에 안걸린다.

웹서비스 아키텍처 예: 서버가 4대일 때
- 서버1 : WebServer
- 서버2 : WAS
- 서버3 : DB
- 서버4 : DB
- 서버1 -> 서버2 -> 서버3 -> 서버4 의 순서로 접근하게 된다.
- 서버2, 서버3, 서버4는 외부 ip로 접근을 막아야한다
- 보통 서버1을 Bastion 서버로 사용하는데, 서버1에 SSH로 붙어서 서버2,3,4에 또 SSH로 붙어 조작하는 용도이다.

웹 서비스 아키텍쳐 예: 서버가 4대일 때(2)
- 서버1: Webserver + WAS
- 서버2: Webserver + WAS
- 서버3: DB
- 서버4: DB
- 로드밸런서에 사용자가 접근하여 서버1 또는 서버2에 접속하게 된다.
- 로드밸런서는 하드웨어적인 장비이다. (L7, L4)
  - 클라우드에서는 쿠버네티스 같은 소프트웨어적으로 로드밸런서를 제공하기도 한다.

로드밸런서 사용하는 상황
- 서버1(WAS)에 처음 요청이 간 후, 서버2(WAS)로 요청하게 되면 서버1에 세션이 남아있으므로 세션을 인식하지 못하는 문제
  - 해결1: Sticky Session
    
    L4 대신 L7 로드 밸런서를 사용하면, 쿠키를 읽어 사용자를 어떤 서버로 요청할지 고정함으로써 문제를 해결 할 수 있다.
    - 로드밸런싱이 골고루 되지 않을 수 있다는 단점이 있다.
    - L7 로드 밸런서는 L4보다 비싸다.
  - 해결2: Session Clustering
    
    Session DB 서버를 별도로 둬서 Session을 읽을 수 있게 한다.
    - 이를 SDB(Session DB)라고 하며, 주로 Redis를 사용한다.
- 미디어 파일도 동기화를 해야하기 때문에, 미디어 서버를 필수로 두어야 한다.

web