시스템 설계

sangeun·2020년 2월 19일
0

시스템 설계는 대용량 서비스를 빠르게 제공하기 위해 도입된다. 현재 우리 서비스와 같은 경우에는 하루에 1000명 정도의 사용자를 예측하고 있으므로 큰 필요성이 없지만

  • 예상 사용자를 늘릴 경우
  • 좀더 빠른 서비스 제공을 목표로 할 경우

이렇게 두 가지의 경우를 추구한다면 생각해 볼 필요가 있다.

시스템 설계도

reverse proxy

  • 로드밸런싱
  • ssl termination
  • ip blocking
  • logging

이를 위해 nginx, apache 등을 많이 사용한다.
하지만 이러한 기능들 중 로깅, ssl과 같은 부분은 톰캣에서 사용할 수 있을 것이라 결론이 나왔다.

WAS

실제 비즈니스 로직이 들어가는 부분이다. 여러 개의 WAS로 이루어질 수 있다.

Queue

비동기 방식에 주로 사용된다. 응답을 기다리지 않고 바로 리턴을 하는 방식이다. 큐 뒤에 다수의 Worker를 둬서, 대용량 처리에 유리하다. 아래와 같은 방식들로 요청이 들어오면 비동기적으로 다른 business component들(은행, 다른 서비스들 등..) 에게 알린다.

만약 payment측에서 결제 승인 웹훅을 merchant로부터 받는 방식이었다면, 웹훅이 많아질 때를 고려해 queue에 넣는 방식을 생각할 수 있다. 하지만 지금은 payment에서 웹훅을 merchant로 보내는 방식이므로, 도입한다면 merchant에 Queue를 도입하게 된다. 하지만 이 프로젝트는 payment가 메인이므로 우선순위를 낮추었다.

Data grid

session과 같은 공유 정보와 캐시 영역으로 사용된다.

DBMS

Primary Secondary 계층으로 여러 개의 db들을 둘 수 있다.
CRUD는 Primary DB에서 수행하고 Primary DB의 데이타를 Staging DB로 고속 복사한후 Staging DB에서 N개의 Secondary DB로 데이타를 복사한다. Read는 Secondary DB에서 수행할 수 있다. 대부분의 서비스들은 read 요청이 많으므로 성능 향상을 낼 수 있다.

샤딩, 파티셔닝과 같은 솔루션도 고려해볼 수 있다.

Object Store

S3와 같이 이미지를 저장해 둘 때 사용하는 저장소이다.

하지만 우리 서비스와 같은 경우에는 이미지를 처리할 일이 없으므로 크게 고려하지 않았다.

CDN

자바스크립트 파일과 css, 이미지같은 잘 변화되지 않는 파일들은 불필요하게 서버에서 받을 필요가 없다. 그보다는 사용자에게 가까운 곳에 위치한 캐시 서버에서 전달을 받는 편이 빠르다.

CDN은 우리 프로젝트에서 충분히 도입할 수 있다고 생각했기에, 후에 더 알아볼 예정이다.

참고: https://bcho.tistory.com/661
https://www.slideshare.net/Byungwook/3-34910563
https://cdn.hosting.kr/cdn%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94/

profile
꾸준히

0개의 댓글