카카오페이 결제 연동 및 구독 기능 구현

[i960107]

🔍 해결하고자 하는 이슈

1. 카카오페이를 사용한 결제 구현. 회차별 결제가능하도록(구독 1회차, 구독 2회차 등)
2. 결제 완료시 유저 구독 상태 업데이트 및 슬랙 알림 메시지 발송 : 이벤트 핸들러 사용해서 결제 비지니스 로직과 분리

이 PR은 이슈 #14에서 요청된 기능을 구현합니다. Fixes #14

💡 주요 변경사항

1.Spring OpenFeign을 http client로 사용해서 카카오 결제 구현

• OpenFeign을 사용한 이유: 선언적으로 간단하게 http client를 구현 가능하다
• 결제는 1. 결제 준비 2. 결제 승인 단계로 이루어짐

  결제 준비

  1. 사용자의 구독 정보를 조회해서 결제 회차를 결정한다. 만약 이미 구독한 상태라면 마지막 결제 회차 +1, 구독하지 않아서 구독 정보가 없다면 1회차.
  2. 카카오 페이 요청에 사용할 order_id, user_id를 UUID를 사용해 생성한다. 보안을 위해 실제 id 대신 임시로 발급한 id로 요청한다.
  3. 결제 상태에 따라 rediredct될 url을 생성한다: - 환경별로 호스트 정보가 다르기때문에 application.yaml에서 서버 호스트 정보를 읽어서 동적으로 url 구성한다. 이때 쿼리 스트링으로 order_id를 추가한다.
  4. 요청을 보낸다.
  5. 요청에 성공하면 redis에 결제 요청 정보를 저장해둔다. 결제 승인단계에서 order_id 사용해서 결제 요청 정보를 복원하고 사용한다.

결제 승인

1. 결제 요청 정보를 복원한다.
2. 결제 요청 정보를 사용해서 카카오 페이에 결제 승인 요청을 보낸다. 만약 결제 승인에 실패하면 PaymentApprovalException을 발생시킨다.
3. 구독 정보를 가져온다. 첫 결제의 경우 구독 정보가 없기 때문에 새로 생성한다. 첫 결제의 경우 endDate를 100년 후로 지정해서 매 결제시마다 endDate를 업데이트해줄 필요가 없도록 한다. 구독 취소 혹은 결제 실패시에 endDate를 수정하도록 한다.
4. 결제 정보를 생성한다.
5. 결제 성공 이벤트를 발행한다. -> 유저의 구독 상태를 업데이트한다. 슬랙 메시지를 보낸다.

2.결제 완료시 유저의 구독 상태 업데이트

• SubscriptionPaymentService에서 결제 승인 후 PaymentSuccessEvent를 발행하면 UpdateSubscriptionWithPaymentSuccessEventHandler가 유저의 구독 상태를 update한다.
• SubscriptionPaymentService에서 UserService에 대한 의존성을 제거할 수 있게 되어 결합도를 낮출 수 있다.
• TransactionEvnetListener를 사용해서 트랜잭션을 분리한다. 유저 구독상태 업데이트에 실패해도 결제는 성공해야하고, 유저 상태 업데이트만 재시도할 수 있도록 할 수 있다. Requires_New로 설정해 새로운 트랜잭션에서 실행되도록한다
• 비동기적으로 실행하지 않는다. 유저 상태 업데이트를 비동기적으로 실행시에 유저 상태 업데이트가 끝나기 전에 새로운 요청에서 구독권이 없다고 조회될 수 있는 문제가 있다.

3.결제 완료시 슬랙 알림 메시지 발송

• SubscriptionPaymentService에서 결제 승인 후 PaymentSuccessEvent를 발행하면 SlackNotificationWithPaymentSuccessEventHandler가 메시지를 발송한다.
• SubscriptionPaymentService에서 SlackNotificationFeign에 대한 의존성을 제거할 수 있게 되고 응집도를 높일 수 있다.
• TransactionEventListener를 사용해서 비지니스로직이 커밋된 후에만 이벤트가 발행되도록 한다. 트랜잭션 밖에서 알림을 보내기때문에 슬랙 메시지 발송에 실패하여도 비지니스 로직은 롤백되지 않는다.
• 비동기적으로 실행되도록 해서 응답속도를 높인다.

✚ 추가 변경사항

1. Subscription(구독) 테이블 변경 및 Payment(결제) 테이블 생성

구독 테이블 변경 내역

• 카카오페이 정기 결제 코드를 위한 sid 필드 추가
• status 필드타입 enum(ACTIVE, CACEL-현재 구독 주기 끝에 만료, EXPIRED)로 변경

  payment테이블 생성

• 결제와 관련된 이벤트를 저장.
• seq으로 결제 회차 저장 (구독권이기 때문에 하나의 구독에 대해서 여러개의 결제 가능)
  • eventType 필드로 결제 이벤트 구분:
  • success: 성공한 결제
  • fail: 실패한 결제
  • cancelled: 결제 후 취소.

    payment테이블에 유니크 인덱스 생성

• subscription_id + seq
• 마지막 결제 회차 + 1로 현재 결제 회차를 결정할때 조회 속도 높이기 위함
• 해당 인덱스 사용할 수 있도록 PaymentRepository에 native query 작성 -> explain으로 인덱스 사용 확인

2. redis 설정 도메인 모듈로 이동

• 기존 app-api에서 redis를 설정하고 사용. 도메인 모듈에서 결제 준비시의 요청 정보를 저장(SavedPayRequest)하기 위해서 redis사용 필요해짐에 따라 도메인 모듈로 이동.
• 의존성 및 configuration 파일 이동

3. 설정 파일 합치기

• 기존에 db, oauth, default, secret등으로 너무 나누어져 있어서 관리하기 어려웠던 것을 합침
• 민감 정보는 .env 파일로 분리하고 .env파일의 값을 참조하도록.
• 도메인모듈에 domain, api모듈에 default, oauth로 합침.

✅ 리뷰가 필요한 사항

• [ ] 최대한 EventListener를 사용해서 SubscriptionPayment 의존성을 분리하려고 해봤는데 적절한지, 더 분리할 수 있는 부분이 있는지 궁금해요.
• [ ] UpdateSubscriptionWithPaymentSuccessHandler에서 @TransactionalEventListener를 동기적으로 실행하는데, 비동기로 실행하는게 좋을까요? 동기적으로 실행하도록 한 이유는 유저 상태 업데이트를 비동기적으로 실행시에 유저 상태 업데이트가 끝나기 전에 새로운 요청에서 구독권이 없다고 조회될 수 있다고 생각해서입니다.
• [ ] url을 어떻게 하는게 적절할지 모르겠어요. "/api/v1/subscription/kakao"를 호출시에 구독권 결제 페이지로 redirect해주는데, 구독과 결제가 섞인 로직이 섞인 url이라 이상하게 느껴지는데 이게 맞을까요??
• [ ] PaymentSuccessEvent를 처리하는 이벤트 핸들러가 두가지(슬랙 알림, 유저상태업데이트)인데 슬랙 알림 발송이 실패해서 에러가 발생하면 유저 상태 업데이트가 안되는 문제가 있어요. 이 경우에 유저 상태 업데이트 핸들러를 먼저 실행하도록 하거나, 슬랙 알림 핸들러에서 에러를 catch하거나 하는 방법이 있을 거 같은데 어떻게 해결하는게 더 적절한가요?

추가해야할 사항

• [ ] 실제 결제 위해서는 개인사업자 번호로 카카오 페이 제휴 필요.
• [ ] 배치로 구독 주기 마지막 날 자동 결제 기능 구현 필요
• [ ] 슬랙 알림 발송 실패, 유저 구독 상태 업데이트 실패시에 재시도 등 처리 필요. 특히, 유저 구독 상태 업데이트는 중요!
• [ ] 스웨거 문서 작성 필요
• [ ] 구독 취소 지원 필요: 구독 취소시 현재 구독 주기 끝에 구독 만료 처리

[hoho-green]

앗 그리고 feign 관련해서 timeout이나 retry 같은 설정도 부탁드려용

[hoho-green]

https://azderica.github.io/01-architecture-msa/

[hoho-green]

sonarqube 라는 정적 분석기가 있는데 이런것도 한번 돌려보시면 좋을거같아요

https://brunch.co.kr/@joypinkgom/207

[i960107]

sonarqube 라는 정적 분석기가 있는데 이런것도 한번 돌려보시면 좋을거같아요

https://brunch.co.kr/@joypinkgom/207

현재 sonarlint를 사용해서 개발중에 코드 분석을 하고 있는데 ci시에 sonarqube에서 체크하는 방법도 있네요! 살펴보겠습니다