RECIPIA_MEMBER

• MSA 프로젝트 레시피아 서비스의 멤버 서버 프로젝트
• 배포 URL (원스토어): https://m.onestore.co.kr/mobilepoc/apps/appsDetail.omp?prodId=0000774118
• 소개 페이지 (노션): https://upbeat-willow-06b.notion.site/7ece9e5f602a43f583d7f4cf101e7d69?pvs=4

목차

1. 프로젝트 소개
2. 개발 기간
3. 개발 환경
4. 주요 기능
5. 인프라
   • MSA 인프라 구성
   • ECS 구성
   • CI/CD 설계
6. ERD
7. 아키텍처
   • 헥사고날 아키텍처 도입
   • MSA 환경에서 DB 정합성 보장 과정
   • ZERO-PAYLOAD 정책
   • 미발행된 SNS 메시지 재발행
8. 개발 전략
9. 주요 기능 상세 설명
10. 테스트 코드
11. 성능 테스트

🔸 프로젝트 소개

• 레시피아는 레시피를 이미지와 함께 작성하고 공유할 수 있는 SNS입니다.
• 검색을 통해 찾고싶은 레시피 이름을 검색하여 구경할 수 있습니다.
• 다양한 회원을 팔로우하며 마음에 드는 레시피에 댓글을 작성할 수 있고, 좋아요, 북마크를 할 수 있습니다.
• 멤버 서버는 그중 회원 관련 프로세스를 담당하고 있습니다.

🔸 개발 기간

• 2023.05 ~ 2023.02 (베타버전 출시)
• 계속해서 추가개발을 진행중입니다.

🔸 개발 환경

• Java 17
• Spring Boot 3.1.2, Spring Security6
• IDE: Intellij, Datagrip
• Database: RDS(PostgreSQL), Redis
• ORM: JPA
• 협업 툴: Jira, Confluence, Notion, Slack

🔸 주요 기능

김이준, 최진안 (페어)

1. 로그인 (Spring Security, JWT)
2. Access Token 재발행
3. 회원가입 (휴대폰 번호/이메일/닉네임 중복체크, S3 이미지 저장, SNS)

김이준

1. 로그아웃
2. 이메일 찾기
3. 비밀번호 재설정 (Java Mail Sender로 메일 전송)
4. 회원 탈퇴(SNS)
5. 마이페이지 조회/수정(SNS)
6. 팔로우 요청(SNS)/팔로우 취소
7. 팔로우/팔로잉 목록 조회
8. 회원 신고
9. 비밀번호 수정
10. 문의사항 등록/조회

🔸 인프라

MSA 인프라 구성

• 프로젝트는 MSA로 구성되어있으며 총 세개(멤버, 레시피, 지프킨)의 서비스로 이루어져있습니다.
• 그 중 멤버서버 ECS 클러스터에 MEMBER 서버를 구축하였습니다.
• 외부 데이터베이스는 RDS(PostgreSQL), Redis, S3를 사용합니다.
• 이벤트 드리븐, 메시지 드리븐으로는 SNS, SQS를 사용합니다.

ECS 구성

• ECS 인프라는 다음과 같이 ECR에 저장된 스프링부트 이미지를 받아서 컨테이너로 동작시킵니다.
• 하나의 ECS에는 하나의 서비스, 하나의 태스크 정의로 실행됩니다.
• SpringBoot에는 Zipkin서버로 로그를 전송하도록 설계하였습니다.

CI/CD 설계

• CI/CD는 AWS의 CodePipeline으로 구축하였습니다.
• main 브랜치에 merge 발생 시 AWS CodePipeline이 자동으로 활성화됩니다. 이 과정은 GitHub 웹훅을 통해 이루어지며, GitHub의 변경 사항을 감지하여 트리거합니다.
• CodeBuild를 사용해 Docker 이미지를 생성한 후 ECR에 저장합니다. 이 단계에서는 소스 코드를 Docker 이미지로 빌드하고, 생성된 이미지를 ECR에 안전하게 업로드합니다.
• CodePipeline이 ECR에 저장된 Docker 이미지를 감지하고, ECS에 롤링 업데이트 방식을 사용하여 무중단 배포를 진행합니다. 롤링 업데이트를 통해 새 버전의 애플리케이션을 점진적으로 배포하면서 서비스 중단 없이 업데이트를 완료할 수 있습니다.

🔸 ERD

AQuery를 사용하여 멤버 서버의 ERD를 설계하였습니다.

🔸 아키텍처

헥사고날 아키텍처 도입

MSA 환경에서 DB 정합성 보장 과정

• 유저가 닉네임을 변경하면 멤버 서버에서는 닉네임 변경사항을 멤버 DB에 반영하고 Spring Event를 발행합니다. (이벤트 리스너는 2개를 선언)
• 스프링 이벤트 리스너중 1개가 동작하여 멤버 DB의 Outbox 테이블에 이벤트 발행 여부를 기록하고 DB 커밋을 합니다.(트랜잭션 커밋완료)
• 트랜잭션 커밋이 완료되면 AFTER_COMMIT을 적어준 또다른 스프링 이벤트 리스너가 동작하여 닉네임 변경 토픽으로 SNS� 메시지를 발행합니다.
• SNS 메시지가 발행되면 2개의 SQS리스너가 동시에 동작하게 됩니다.
  • 레시피 서버에서 닉네임 변경 토픽을 리스닝하고있던 SQS가 실행됩니다.
  • 멤버 서버에서 닉네임 변경 토픽을 리스닝하고 있던 SQS가 실행됩니다. 이때 Outbox 테이블에 이벤트 발행 여부(published 컬럼)를 true로 업데이트합니다.
• 레시피 서버의 SQS 리스너가 동작할때 FeignClient를 사용하여 멤버 서버에 가장 최신의 유저 닉네임 정보를 요청합니다.
• 멤버 서버로부터 받아온 가장 최신의 유저 닉네임 정보를 레시피DB에 반영합니다.

ZERO-PAYLOAD 정책

• 데이터 전송시 메시지 내부에는 memberId만을 포함하도록 합니다.
• 분산추적을 위한 traceId는 SNS의 messageAttributes를 사용하여 전송합니다.

미발행된 SNS 메시지 재발행

• Spring Batch를 사용하여 5분마다 미발행된 메시지를 재발행 합니다.
• Outbox 테이블에 저장된 발행여부(published)가 false것을 조회하여 배치가 동작합니다.

🔸 개발 전략

1. 스프링 시큐리티와 JWT를 통한 인증 및 인가

2. 에러 중앙 처리

• 이 프로젝트의 에러 처리 전략은 @RestControllerAdvice를 활용하여 모든 예외를 중앙에서 처리합니다.
• 이를 통해, 커스텀으로 정의된 ErrorCode 클래스를 사용하여 에러 코드 및 메시지 관리를 효율적으로 수행합니다.

🔸 주요 기능 상세 설명

1️. 로그인

2. Access Token, Refresh Token 발행

3. Access Token 재발행

4. 회원가입

5. 임시 비밀번호 발급

🔸 테스트 코드

• 단위/통합 테스트 진행 (171개)
• Junit5, mockito, S3Mock, BddMockito 사용
• 외부 DB (Redis)를 사용한 테스트도 진행했습니다.

🔸 성능 테스트

• 상용 서버 성능 테스트 결과

• 다양한 환경에서의 성능 테스트 결과 분석

• 하드웨어 성능의 영향: 로컬 M2 Max 64GB 환경에서의 성능이 M1 16GB 환경보다 월등히 높다. 이는 M2 Max의 더 높은 CPU 성능과 더 많은 메모리 용량이 성능 향상에 기여했음을 시사한다. TPS(Transactions Per Second) 평균과 최고치 모두에서 M2 Max 환경이 M1 환경을 크게 앞서며, 평균 테스트 시간도 상당히 단축된다.

• 상용 환경에서의 성능 제약: EC2 t4g.small 환경에서의 성능은 로컬 환경과 비교하여 현저히 낮다. TPS 평균과 최고치가 매우 낮고, 평균 테스트 시간이 크게 증가한다. 이는 EC2 t4g.small 인스턴스의 리소스 제약과 네트워크 지연 시간 등 외부 요인 때문일 가능성이 높다.

• 성공한 테스트 비율: 모든 환경에서 에러 없이 성공한 테스트의 비율이 100%로, 애플리케이션의 안정성은 환경에 관계없이 일관되게 유지되고 있다는 것을 나타낸다.

• 성능 최적화의 중요성: 특히 상용 환경에서 애플리케이션을 배포할 때, 하드웨어 성능, 네트워크 설정, JVM 최적화 등 다양한 요소들을 고려하여 성능을 최적화하는 것이 중요하다.

(더 자세한 내용은 여기에서 확인할 수 있다.)