본문 바로가기
우아한테크코스/모락 프로젝트

모락 프로젝트의 서버 구조 (리버스 프록시)

by 자바지기 2022. 8. 8.
반응형

mo-rak.com

 

모락 프로젝트 세 번째 스프린트에서 서버 구조를 설계하였습니다.

 

서버 구조를 설계하기 이전에 우리의 통신 방식은 다음과 같았습니다.

1. 정적 파일을 요청할 때는 정적 파일이 담긴 서버에 요청을 보냅니다.

2. 서버의 API 요청을 할 때는 서버로 요청을 보냅니다.

 

이러한 구조로 서비스를 실행할 때 문제가 있었습니다.

사용자가 서버 내부의 데이터가 필요하다면 WAS에 직접적으로 요청을 보내야 했습니다.

WAS에 사용자가 직접적으로 접근할 수 있게 하였을 때는 여러 문제가 발생할 수 있습니다.

 

1. 보안

제일 큰 문제는 보안입니다. WAS에 직접적으로 접근이 가능할 경우 데이터베이스가 털릴 가능성이 있습니다.

데이터 베이스에는 우리의 중요한 데이터들이 많이 있기 때문에 항상 조심히 지켜줘야 합니다! 

 

2. 서버 과부하

서버에 많은 요청이 올 경우 과부하가 올 수 있습니다. 

세 번째 스프린트 이전까지 https 를 적용하지 않고 http통신으로 진행했지만, 만약 https 로 통신을 했다면 사용자의 매 요청마다 https 연결을 해야 할 것입니다. 매 요청마다 https 연결하는 것 자체가 서버에 과부하를 유발합니다.

 

3. 배포 시 서비스 중단

우리는 현재 서비스를 개발하는 단계이므로 계속해서 배포를 진행해야합니다.

이때 사용자가 서버 한 대와 직접적으로 소통을 하고 있으므로 배포를 위해 서버를 중단하면 사용자는 서비스를 이용할 수 없게 됩니다.

 

이러한 단점들을 보완하기 위해 우리는 다음과 같은 서버 구조로 변경하였습니다.

 

1. 사용자가 mo-rak.com 으로 요청을 보낸다.

2. HTTPS 통신으로 웹 서버로 요청이 전달된다.

3. 요청이 정적 파일을 달라는 요청이라면 웹 서버 내부에 있는 정적 파일을 사용자에게 보내준다.

4. 요청이 서버 API 요청이라면 내부망을 통해 웹 서버에서 WAS로 요청을 전달한다.

5. WAS에서 DB로 접근해야 한다면 내부망을 통해 DB로 접근한다. 

6. 요청에 대한 응답을 전달한다.

 

이 구조, 즉 웹 서버를 리버스 프록시로 사용하는 구조로 변경하고 난 뒤 이전 구조의 단점들을 해결할 수 있었습니다.

 

1. 보안

사용자가 WAS로 접근하기 위해서는 무조건 웹 서버를 거쳐야합니다.

웹 서버는 WAS를 숨겨주는 역할을 합니다. 따라서 보안이 강화됩니다.

 

2. 서버 과부하

사용자와 WAS가 직접적으로 HTTPS 통신을 진행한다면 서버에 과부하가 옵니다. 그러나 위의 구조에서는 사용자와 웹 서버 사이에서만 HTTPS 통신을 진행합니다. WAS는 웹 서버와 내부망을 통해 http 통신을 진행합니다. WAS의 통신 부담을 줄일 수 있습니다.

 

3. 배포 시 서비스 중단

현재는 WAS가 한 대만 존재합니다.

웹 서버는 사용자의 요청이 들어오면 호출 서버를 선택할 수 있기 때문에 여러 대의 WAS를 연결할 수 있습니다.

따라서 다음과 같이 WAS를 여러 대 생성하여 웹 서버와 연결하면 배포 시 서비스를 중단하지 않아도 됩니다.

 

배포를 해야할 때 WAS 1에서 먼저 배포를 진행합니다. 이때 WAS 2는 서비스를 계속 진행합니다. 사용자는 WAS 2를 이용해 서비스를 계속 이용할 수 있습니다. WAS 1에서 배포가 끝나면 WAS 2 배포를 진행합니다. 이 때 사용자들은 WAS 1을 이용해 서비스를 이용할 수 있습니다.

즉 무중단 배포를 진행할 수 있습니다.

 

이처럼 서버 구조를 변경하여 여러 이점들을 알 수 있었습니다.

우리의 서비스가 더 큰 서비스가 되어서 현재의 구조에서 더 큰 구조로 확장된다면 서버 구조에 대해서 더 공부해볼 수 있을 것 같습니다.

반응형

댓글