모락 프로젝트 세 번째 스프린트에서 서버 구조를 설계하였습니다.
서버 구조를 설계하기 이전에 우리의 통신 방식은 다음과 같았습니다.
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을 이용해 서비스를 이용할 수 있습니다.
즉 무중단 배포를 진행할 수 있습니다.
이처럼 서버 구조를 변경하여 여러 이점들을 알 수 있었습니다.
우리의 서비스가 더 큰 서비스가 되어서 현재의 구조에서 더 큰 구조로 확장된다면 서버 구조에 대해서 더 공부해볼 수 있을 것 같습니다.
'우아한테크코스 > 모락 프로젝트' 카테고리의 다른 글
JPA entity에 validation annotation을 붙인 이유 (0) | 2022.08.28 |
---|---|
모락의 Git branch 전략 (0) | 2022.08.27 |
존재하지 않는 API 요청 커스터 마이징하기 (0) | 2022.08.16 |
Custom Error Code가 왜 필요했을까? (0) | 2022.08.10 |
Github OAuth 로그인 구현하기 (0) | 2022.07.16 |
댓글