프로젝트 아키텍처

김태성·2024년 8월 2일

개인 프로젝트-1

목록 보기

14/53

이제 내 사이트가 어떻게 구성되는지 고민해야 할 시기가 왔다.
공부를 핑계삼아 나도 모르게 피해왔다는 느낌이 들었다.
하지만 이런 두려움을 극복하고 본격적으로 프로젝트를 만들어 나가자.
기초준비에 1달넘게 썼으면 충분히 공들였다고 생각한다.

프론트/백

클라이언트에서 데이터를 요청했을때의 요청 흐름이다.

클라이언트가 사이트에 데이터를 요청한다.
사이트는 서버에 특정 데이터 값을 요청한다.
서버는 사이트에 데이터를 반환한다.
반환된 데이터를 클라이언트에 제공한다.

기본적인 client - front - back 구조이다.
특별할 것도 없이 요청 - 반환 작업만을 하기에 구조가 단순하다.

공공 API 데이터 요청

이부분이 좀 독특하다. 과정을 설명하자면

내가 사용하는 데이터들은 공공 API에서 받은 데이터 + 유저 데이터를 기반으로 한다.
이때 공공 데이터는 정해진 데이터를 일정 주기마다 추가한다.
따라서 매일 공공 데이터의 갱신이 필요하다.
공공 데이터를 갱신하되, 그중 client에게 일정하게 제공하는 데이터는 캐싱한다.(오늘의 날씨 등)
이후 필요한 데이터를 서버에 제공한다.

캐싱을 하는 데이터는 전국 날씨/전기요금 평균 등
누가 데이터를 요청해도 항상 일정한 값을 줄 수 있고 미리 계산해야 하는데이터를 저장하는 것이다.
이러한 계산을 요청시마다 한다면 수많은 중복계산으로 인한 오버헤드가 꽤 커질것이라 생각했다.

로드 밸런싱

(was는 web을 포함하지않나? 싶지만 apache는 http 서버, tomcat는 servlet container이다.)

아파치 톰켓과 AWS는 로드 밸런싱 기능을 제공한다.
AWS는 Elastic Load Balancing 라는 L4 로드밸런싱 서비스를 제공하고,
아파치는 L7 로드밸런싱을 제공한다.
(AWS에서 Application Load Balancing이라는 L7 로드밸런싱도 제공하지만 일단은 넘어가자.)

레퍼런스1 : https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html
레퍼런스2 : https://tomcat.apache.org/tomcat-9.0-doc/balancer-howto.html
레퍼런스3 : https://ko.wikipedia.org/wiki/아파치_톰캣
아파치 톰켓이라는 것은
Apache Http Server - Tomcat의 연동을 의미하는 것이다.
mod-proxy를 통해 Tomcat 단독으로는 하지 못하는 로드밸런싱, 보안 등의 이점을 얻는다.

따라서 우리는 (아파치로드 밸런싱의 수 * 아마존 로드밸런싱의 수) 만큼의 was를 가질 수 있게 되었다.
어차피 서버 인스턴스가 하나밖에 안되고, 멀티코어로 돌릴것도 아니라서 성능에는 별 차이가 없을수도, 많은 서버를 돌리기 위해서 성능이 떨어질 수도 있다.

레퍼런스 : https://stackoverflow.com/questions/27336657/does-it-make-sense-to-have-an-amazon-elastic-load-balancer-with-just-one-ec2-ins

라고 예상을 하고 찾았더니 역시나 우리 스택오버플로우 큰형님들도 맞다고 했다.

정리를 하자면