MSA 기반 인증 서버
스마일게이트 윈터데브캠프에서 팀 프로젝트 시작하기 전 개인 프로젝트 개발 과제를 진행했다.
블로그 , URL shortener , MSA 인증 서버 중 인증 서버 개발 과제를 선택했고
그 이유는 팀 프로젝트에서 백엔드 담당 이기 때문에 Spring Boot를 사용해보기 위해 선택했다.
MSA 구성
기간이 1달 정도이고, 기말고사 기간이 2주 겹쳐있었기 때문에 React의 경우는 매우 간단하게 짰고 최대한 서버 부분에 집중했다.
User 서비스 : 회원가입, 로그인 처리
Order 서비스 : User 서비스와 1:N관계를 갖는 주문 정보를 처리
Discovery 서비스 : 각 서비스들의 상태 정보를 처리
Gateway 서비스 : 각 서비스들로 중계 역할을 수행
요구 사항
윈터데브캠프에서 요구한 주요 요구사항들은 아래와 같다.
- 가입, 로그인 페이지
- 유저 관리 페이지
- 인증 서버 API
- RDBMS DB 사용
- Password Encryption
학습 내용
이를 구현하기 위해 많은 학습이 필요했다
특히, 인증에서 암호화 부분, MSA에서 요청 처리, 토큰 관련 로그인 부분에서 학습을 하였다.
인증 암호화
대부분 Spring Security에서 제공하는 기능들을 사용하였다.
비밀번호 인증은 BcryptPasswordEncoder를 사용하였고, AuthenticationFilter에 의해 로그인을 확인한다.
MSA
MSA에 대한 경험과 지식이 많이 부족하여 걱정하였으나 Spring에서 제공하는 기능이 매우 강력함을 느낄 수 있었다...
MSA를 구축하기 위해 Discovery Service(Eureka)를 구현하였으며 이를 통해 각 서비스들이 Discovery 서비스를 통해 관리? 확인? 될 수 있다.
Discovery에 등록되면, Gateway에서 Discovery Service에서 각 서비스들의 상태, 주소를 알 수 있다.
이를 통해 사용자 -> Gateway -> 서비스 형태로 요청이 이루어지도록 구현하였다.
인증 토큰
인증 토큰의 경우 자동로그인에서 많이 사용된다.
JWT 토큰 형태로 access token과 refresh token을 구현하였다.
1. Access Token 만료 Refresh Token 만료-> 에러, 재로그인하여 둘 다 새로 발급받아야 한다.
2. Access Token 만료, RefreshToken 유효-> Refresh Token을 검증하여 Access Token ,Refresh Token 재발급
3. Access Token 유효, Refresh Token 만료-> Refresh Token 만료 시 재 로그인
4. Access Token 유효, Refresh Token 유효-> 정상 처리
를 기본으로 생각했고 시간 상 문제로 Refresh 토큰은 모두 구현하지 못했지만, 이 후 팀프로젝트에서 1인프로젝트를 기반으로 더욱 세세하게 구현할 기반을 마련할 수 있게 되었다.
일반적인 모놀리식 구조의 경우 jwt를 각 도메인?에서 검증해서 사용하기 때문에 매우 복잡해진다.
그러나 MSA 구조의 경우 Gateway를 거쳐야 하기 때문에 게이트웨이에서 jwt 여부와 유효성 검사를 도맡아 할 수 있다.
따라서 Gateway에서 jwt 여부, 유효성 검사를 담당하고 이 후 필요한 경우 각 서비스에서 jwt 내부의 payload 에서 데이터를 꺼내서 쓰는 형식으로 구현하였다.
아쉬운 점
빠르게 한달이 지나고 프로젝트를 정신없이 마무리하면서 많은 아쉬움이 남았다.
- 깃허브를 잘 활용하지 못했다.
- 개인프로젝트이기 때문에 브랜치, 이슈와 같은건 힘들다고 생각하지만 커밋 컨벤션 부분에서 많은 아쉬움이 남았다.
- 어떤 커밋인지, 어떤 내용인지 상세히 기술하도록 해야겠다.
- 디렉토리 구조가 이상한 것 같다.
- controller - dto - jpa - security - service - vo 이런식으로 되어 있는데 정정할 필요성을 느꼈다.
- 특히 dto 내부에 response, request의 내용을 분리하는 것이 더 깔끔할 것 같다.
- exception ,config, 폴더가 필요할 것 같다.
- jpa 보다 domain 으로 디렉토리 명을 수정하고 내부에 repository와 entity를 담는 방식으로 수정하면 좋을 것 같다.
- Service 함수명이 Controller와 거의 일치한다.
- 예를 들면, POST ~/users 요청이면 이에 대한 controller의 함수명이 createUser이고, service 함수명도 createUser이다.
뭐가 문제인지는 잘 모르겠지만 이 부분에 대해 정리할 필요가 있을 것 같다.
- 예를 들면, POST ~/users 요청이면 이에 대한 controller의 함수명이 createUser이고, service 함수명도 createUser이다.
- Response 응답 형식이 들쑥날쑥하다.
- Response의 경우 status, data, description, success/fail 여부 등을 담고 있을텐데 이에 대한 형식을 공통으로 잡고 data에 각 동작별 데이터를 담을 수 있도록 하는게 좋은 것 같다.
- 예를 들어 <D> 처럼 템플릿 형태로 ResponseDto를 구성하고 CreateUser의 응답을 보낼 때 ResponseDto에 User 객체를 담아서 보내는 형식이 가능할 것 같다.
- 에러처리가 적절하지 못했다.
- 에러 status, exception, response 다 미흡했다고 생각한다.
- status 의 경우 Errorcode를 정의하여 각 서비스 별로 AUTH 001, AUTH 002 이런식의 Enum을 활용할 수 있을 것 같다
내부에 description이나 message를 담을 수 있을 것 같다. - exception의 경우 상황에 따라 던져서 ExceptionHandler를 통해 ErrorResponse를 반환하는 방식을 사용하면 좋을 것 같다.
처음에 비해 많이 늘었기 때문에 더 많은 아쉬움이 남고, 부족한 부분들이 보이는 것 같다.
Spring 첫 프로젝트 이기도 하고, 앞으로 윈터데브캠프에서 팀프로젝트도 남았기 때문에 이를 계기로 더 나은 프로젝트를 만들기 위해 노력해야겠다.
'프로젝트 > 스마일게이트 윈터데브캠프' 카테고리의 다른 글
[윈터데브캠프] 팀 프로젝트 - 유저, 푸시 서버 (0) | 2023.04.03 |
---|---|
[윈터데브캠프] 팀프로젝트 - 인증 (게이트웨이, 인증 서버) (0) | 2023.04.03 |
[윈터데브캠프] 팀프로젝트 - API,DB (+요청/응답, 포트) (0) | 2023.04.03 |
[윈터데브캠프] 팀프로젝트 - 아키텍처 (0) | 2023.03.31 |