[멋쟁이사자처럼 지원페이지] #4 업데이트 진행 (MSA 구조 개요)

1. 서론

 

 하나의 시스템을 운영해보고 이를 점차 발전시켜나가는 경험을 위해 기존에 운영하던 강남대학교 멋쟁이사자처럼 지원페이지의 단점을 보완하고 업데이트를 진행하고자 하였다. 첫 버전을 배포하고 느낀 가장 큰 문제점은 유지보수이다. 첫 서비스를 배포하고 여러 오류가 채널톡으로 들어왔을 때 너무 힘들었다. 하나의 작은 오류도 다시 서비스를 빌드해야하기에 배포가 신경이 많이 쓰였던 것 같았다.

 

 매일 매일 기술블로그들을 구경하면서 본 구조 중 하나는 바로 MSA 구조였다. 방학기간동안 해당 구조를 공부하고 이를 우리 지원페이지에 적용하려 지금까지 노력하고 있다. 전체적인 구조는 다음과 같다.

---

---

2. 본론

 

- Rabbit-MQ

 

 내가 맡은 서비스는 apply-service와 config-service 그리고 Message Queue의 적용이다. config-service 같은 경우 github repository에서 yml파일을 가지고온다. 중요한 점은 yml 파일이 변경된다면 config-service를 다시 빌드해야하는 불편함이 있다. 이런 불편한 점을 해결하기 위해 Rabbit-MQ를 적용하여 다시 빌드하지 않고 URL endpoint를 통해 변경된 yml파일을 문제없이 적용하기 위해 해당 tool을 도입하였다.

 

- apply-service DB 설계

 

 이전 버전에서의 가장 큰 문제점은 질문의 내용을 변경할 수 없다는 것이다. 이를 해결하기위해 DB 구조를 재설계하여 질문을 변경하여 지원자들의 답변을 유동적으로 받을 수 있도록 구현하였다. 초반에 설계한 DB는 다음과 같다.

---

---

MSA 구조는 각 서비스별로 분리하여 프로젝트를 개발하기 때문에 user-service는 내역할이 아니어서 따로 개발을 진행하였다. 해당 서비스의 자원을 가지고 오려면 서버간 통신이 필요한데, 이는 다른 글에서 포스팅하려한다. 오른쪽의 테이블들이 내가 설계한 DB 구조이다.

 

 지원서의 상태를 따로 저장하고, 질문을 유동적으로 변경해야했기에 DB가 조금 많아졌다. 모집공고를 생성하고 해당 모집 공고에 적용할 질문들을 저장하는 테이블을 따로 생성한다. 중요한점은 답변 테이블인데 user들의 답변을 저장함과 동시에 어떤 공고에 어떤 질문에 대답을 했는지에 대한 정보도 저장해야했기에 answer 테이블을 따로 만들었다.

 

 사실 초반 설계는 여기서 끝났지만 지원서의 상태를 위한 테이블을 하나 더 만들었다. 해당 테이블을 생성한 이유는 VER1 서비스를 배포했을 때 몇몇 사용자가 자신의 지원서의 평가단계를 알고 싶어했기 때문이다. 지원서의 평가단계는 1차 합격, 2차 합격, 최종 합격이 있다. 따라서 user가 지원한 모집공고의 상태를 저장해야했기에 application 테이블을 따로 생성하여 해당 정보를 저장해주었다.

 

- 팀 내 공유를 위한 문서화

 

 팀 내부에서 파트끼리 혹은 팀원끼리 소통을 진행할 때 원활한 소통을 위해 문서화를 진행하였다. 팀원은 총 7명으로 백엔드 2, 프론트엔드 3, 안드로이드 1, 디자인 1로 구성되어있다. 다음은 우리 팀 문서 페이지이다.

---

Docs

---

 

3. 결어

 

 지속적인 서비스 개발을 위해 팀을 구성하고 팀장을 맡게 되었다. 기술적인 부분의 해결을 더욱 더 높였으면 좋겠다.