시스템 구조도를 받고 결제/예약 시스템을 구현하고 성능을 최적화시키는 프로젝트.
Frame work : springboot
DB : MySQL
CICD : github action
Container : Docker
Cloud : EC2, RDS
Load Balancer : NGNIX
10일 동안의 개발이기도 하고, 시스템의 복잡도가 그렇게까지 높지 않기에 MA 아키텍처를 선택했습니다.
MA로 했기에 배포를 쉽고 빠르게 할 수 있었고, 웹과의 연결 또한 간단하게 이루어질 수 있었습니다.
하지만, MSA로 설계했다면 더 좋았을거 같기도 했습니다.
MSA로 했다면 3가지 면에서 더 나았을거 같았습니다.
기존에는 t2.small로 EC2를 잡아서 비용 청구를 피할 수 없으나 만약 프리티어가 가능한 t2.micro로 로그인, 디자이너 관련, 예약, 결제 총 4개의 서버를 구축했다면 비용면으로 더 좋았을거 같았습니다.
또 서버를 분리시키므로 서버 단일의 복잡도를 높여서 로그인에서 redis 기반의 refresh+access JWT로 하고, 예약에서 redis로 분산처리를 했으면 보안성과 성능을 더 높일 수 있을 거 같았습니다.
각자 서버를 분리시켜서 협업을 진행한다면 코드 구조가 단조로워져서 유지보수 하기가 쉬워졌을 것이고, 충돌도 날 일이 없어서 협업하기 쉬운 환경이 이루어졌을 것 같았습니다. 물론 개발자 전원이 배포 경험이 있어야 하지만, 경험이 없더라도 배포 하는 방법을 알려주면서 더 나은 소통이 이루어졌을거 같았습니다.
이번 해커톤을 통해서는 MA로 DevOps를 함으로써 MSA로 전환했을 때의 장점에 대해서 생각해봤습니다. MSA에 더 익숙해진 다음에 다음 해커톤때는 무조건 MA로 하지 않고, MA와 MSA 중에서 무엇이 맞는지 생각해보고 프로젝트에 맞는 아키텍처로 구축해볼 생각입니다.