프로젝트 개발에 앞서, 본 서비스의 소개와 아키텍처에 대해 간략히 소개해보자.
더불어 내가 맡은 도메인들을 소개할 것이다.
What ?
우리 팀은 개발자들을 위한 구인구직 웹 서비스를 계획했다.
구인구직 서비스는 많은데 ?
맞는 말이다. 때문에 차별성을 위해 우리는 개발자들에 초점을 맞추었다.
세상에는 정말 다양한 개발자가 존재한다. 학생, 인턴, 주니어, 시니어, 등등 ,,
개발자의 역량마다 할 수 있고, 해야하는 일은 전부 다 다르다.
예를 들어 간단한 초중학교 코딩 교육을 10년차 시니어 개발자가 할 수 없지 않는가 ?
용돈이 필요한 대학생 개발자가 적합할 것이다.
이처럼 우리는 일을 난이도, 역량에 맞추어 구분할 것이며 이를 적합한 개발자들에게 맞춤형으로 제공할 계획이다.
( feat .. 내가 학생 때도 있었으면 좋았을텐데 ,, )
How ?
자 그럼 우리는 어떤 기술을 사용해서 개발할 것이냐 !
서비스 아키텍처부터 말하자면, 우리는 DDD, MSA 패턴을 적극 활용할 것이다.
모든 서비스를 하나의 서버에서 관리하는 모놀리틱 아키텍처는 요즘 시대에 적합하지 않다.
당연히 초기에는 구성도 간단하고 기능도 많이 존재하지 않고, 대용량 트래픽이 발생하지 않아 문제가 없을 수 있다.
오히려 프로젝트 기간을 늘리는 삽질일 수도 있다.
하지만 모놀리틱 아키텍처는 많은 문제점이 있다.
우선 모든 기능들이 하나의 서버 안에 있기 때문에, 하나의 서비스에 장애가 생기면 시스템 전체가 문제가 생긴다.
즉 모듈화가 제대로 이루어지지 않는다는 것이다. 하나의 모듈을 수정하려면 시스템 전체를 수정해야한다.
때문에 모듈 확장이 어렵다는 치명적인 단점이 있다.
또한 서비스 기능에 적합한 기술을 적용하기 어렵다.
그럼 마이크로 서비스 아키텍처는 무엇이냐 !
말 그대로다.
전체 서비스를 도메인 (비즈니스 로직) 단위로 나눈다. 그리고 그 도메인들을 각각의 서버로 개별적인 모듈로 관리 배포한다.
즉 각각의 모놀리틱 서버들이 여러개 존재하며 각각 배포 관리 통신된다는 뜻이다.
때문에 하나의 도메인을 확장, 수정 할 때 다른 도메인들은 건드릴 필요가 없다는 큰 장점이 있다.
당연히 유지보수하기 편할 것이다.
또한 각각의 서버이기 때문에, 기술 스택이 겹치지 않아도 된다.
spring, flask, node.js 편한 프레임워크를 고른 후, 심지어는 DB 도 고를 수 있다. mysql, mogoDB 등
객체지향설계에서 강조하는 (SOLID) 느슨한 결합을 이룰 수 있는 것이다 !!
But, 사실 그렇게 간단하지는 않다.
MSA 패턴이 좋아보이지만, 신경써야할 부분들이 참 많다.
서비스를 DDD로 나누는 부분부터, 인증 인가 요청을 담당할 API GateWay 를 구성해야 하고 ,,
각각 서버의 엔트포인트, 포트를 관리해주는 Eureka 서버도 배포 해야하며 ,,
각각의 서버는 클라우드 (AWS) 를 이용해 관리 배포(CI/CD) 되야한다. 물론 RDS 도 써야겠지 ,,?
서버를 배포하려면 인,아웃 바운드 및 보안처리도 해줘야한다.
이정도만 있게 ?
MSA 는 메세지큐를 통한 비동기 이벤트처리를 권장한다. 적절한 상황에 맞추어 동기적인 API, 비동적인 MQ 통신을 사용해야한다.
각각의 서버마다 데이터가 존재하기 때문에 데이터 일관성도 매우 중요한 문제이다.
적절한 롤백처리를 해줘야겠지 ?
MSA 패턴으로 서비스를 작게 구성했다면 컨테이너화 시키는것이 좋겠지 ?
도커를 활용해 컨테이너 환경으로 배포 관리 하는 것이 좋을 것이다.
또 이를 관리해주는 쿠버네티스를 사용하면 더더욱 좋을 것이다. ( 아 물론 더럽게 비싸다고 한다. )
놀랍겠지만, 이 모든 것이 인프라 설정이라는 것이다.
우리는 아직 개발은 시작도 안 했는데 이렇게나 신경 쓸게 많다.
때문에 !! 이 모든 것을 다 완벽하게 알고 시작할 수는 없다.
물론 어느정도 개념은 알고 있어야한다. 우리 팀도 이전에 미니프로젝트로 MSA 패턴으로 API 서버를 만들어 통신해봤기에 가능했다.
하면서 모르는 부분은 더 찾아서 공부하고 기록하는 방식으로 진행할 것이다.
도메인 분리
자 그럼 필요한 기능들을 도메인 단위로 구분해보자. DDD 에서 도메인이란 비즈니스 로직을 의미한다.
도메인 단위로 서버가 구분될 것이다.
우선 시나리오를 써보자.
시나리오
- 로그인 및 회원가입
- 구인 글 작성
- 회원이 이력서 제출 을 통해 지원
- 구인 글 작성자가 이력서 확인
- 구인 글 작성자가 원하는 회원에게 채팅 요청
- 확정하기 를 누르면 쿠폰 선택 화면 뜨고
- 쿠폰 선택 완료하고 결제하기 누르면 포인트 차감/적립 → 수수료 제외 후 적립
- 구인 글 모집 종료
- 채팅방은 유지
과연 어떤 비즈니스 로직이 나올까 ?
- 회원
- 프로필 (사진 포함)
- 회원 CRUD
- 이력서 CRUD
- 받은 이력서 확인
- 보낸 이력서 확인
- 회원 전체 관리 CRUD
- 게시물 + 댓글 + 즐겨찾기
- 게시물 CRUD → 모집글 → 게시물에 카테고리 부분 필요
- 검색 및 페이징
- 댓글 CRUD
- 구인글 모집 종료 (게시글 U)
- 게시물 전체 관리 CRUD → 부적절한 게시물로 … 관리자가 .. 검토 중 U : 블락 처리
- 결제
- 포인트 충전 & 차감 U
- 포인트 충전 기록 C
- 결제 내역 기록 C (거래 기록)
- 포인트 유효 기간 체크 (배치 프로그램)
- 결제 내역 전체 조회, 삭제 RD
- 채팅
- 채팅 방 생성 → 유저 2명 → 다른 사용자에게 채팅방 생성에 대한 알람을 전달
- 채팅 메세지 전송
- 거래 확정하기
- 부가기능으로 채팅방 나가기
- 쿠폰
- 쿠폰 발급, 사용
- 회원가입 시 첫 쿠폰 발급
- 유효기간 체크
- 카테고리별 쿠폰 … …
- 쿠폰 발급, 사용
- API 게이트웨이 → 인증 & 인가 & 토큰
- 로그인
- 회원가입 → 회원가입 후 유저쪽으로 데이터 쏘기
- 토큰 발급
- Eureka 서버
이와 같이 6개의 도메인으로 구분할 수 있다.
팀원들과 회의 끝에 나는 회원, 채팅 서비스를 담당했다.
물론 웹페이지 개발도 포함해서 ,, 이전에 작업해둔게 있어서 많지는 않겠지만 웹페이지 css 개발은 너무 어렵다 ..
모든 요청은 API 게이트웨이를 통과해 인증 처리를 마친 후, 요청된 url 에 맞는 서버로 전송될 것이다.
프로젝트 이름은 Devit 이며, DevitUser, DevitChat 도메인을 담당해 개발할 예정이다.
본 서비스 아키텍처를 그림으로 표현하는 이와 같을 것이다.
다음 포스팅은 유저 도메인부터 개발하는 과정을 설명할 것이다.
'개인 공부 > Devit' 카테고리의 다른 글
| [Devit] #3 Spring Stomp 를 사용해 채팅 구현하기 (0) | 2023.02.24 |
|---|---|
| [Devit] #2 유저 설계 ( Token, RabbitMQ ) (1) | 2022.06.30 |
