포인트 충전 api 절차

/payments/charge/ready

request: itemId response : merchantUid, itemName, amount, email

/payments/charge

request : impUid, merchantUid
response : point

후원 절차

/donations

request : pageName, point
response : donationId, name, message, amount, createdAt

/donations/{donationId}/message

request : name, message, secret
response : -

환불은 내부로직만 바뀌고 엔드포인트 바뀐 것 없음

본인이 보낸 후원을 나중에 볼 수 있게끔 하기위해서 Donation에 DonationType 이라는 enum 타입 필드를 추가해주고,
후원 요청 시에 2개의 Donation을 각각 만들어서 creator와 donator가 가지고 있는 List에 집어넣어줬을 경우,
/donations/{donationId}/message 호출 시에 하나의 donationId 만 들어올텐데 두 도네이션의 Message를 다 업데이트 하기가 애매한 것 같음!
후원자가 본인이 보낸 후원 메세지에 대한 정보가 defaultMessage 여도 상관없다면 괜찮지만... 아니면 프론트한테 /donations 이후에 response 로 donationId를 2개를 response 해주고 message API 에서 2개의 id를 모두 받는 방법도 있긴하지만!

1. 이제 거의 모든 API가 토큰이 필요할텐데 (다 인가??) 인수테스트 짜는 담당이 이거 path 좀 config에 추가해줄레?
2. Payment 환불 시에 환불 기간 지났는지에 대한 로직을
   
   이걸로 짰는데 테스트 잊으면 안됑!
3. 이전에는 후원하는 절차에서 결제를 했어서 그때 메일이 발송됐는데, 후원시에는 발송안하고 포인트 충전하면 발송하게끔 해놨어
4. Donation에 들어가는 Message 로직을 좀 바꿔놨어! 이제 defaultName이 후원자의 nickname이니깐 이 부분 때문에 생성자가 바뀌었을거야 !!

더 말할게 있었던 것 같은데 . .. 기억안나네... 일단 바뀐점 보면서 궁금한거 다 물어봐!!
내가 놓친부분이 무조건 있을 것 같은데, 아마 테스트 짜면서 속속들이 발견될 것 같음 . . !!

구현사항

• prod 환경 프로퍼티 생성
• jasypt으로 중요 정보 암호화
• 배포 쉘 스크립트 수정

java -jar -Djasypt.encryptor.password={jasypt 암호} -Dspring.profiles.active=dev

이슈사항

• 스프링 부트 2.4 변경사항 으로 include로 프로퍼티가 안 불러와지는 이슈
• 아래 설정을 추가하면 정상동작

config:
    use-legacy-processing: true

• 어플리케이션 프로퍼티 수정문제는 상의 후 이슈를 새로 생성해서 처리하면 좋을듯

참고

• 스프링 부트 2.4 프로필 관련
  • https://github.com/kwon37xi/research-spring-boot-2.4

메일전송 비동기로 처리하도록 Async 추가했어! Async설정을 해주는 부분이 있는데, 이 부분을 일단 임의로 설정했어! 우리 서비스가 아직 그렇게 많은 요청이 들어오지 않아서 작게 잡아봤어!

비동기 테스트를 어떻게 할지 몰라서 일단 직접해보는 식으로 진행했는데, 개선 된 것 확인했어! 메일 전달 내용에도 문제가 없더라구!

PR올려볼게!

변경사항

• AsyncConfig 추가 및 메일전송 메소드에 @async 추가

  • CorePoolSize : 기본적으로 실행을 대기하고 있는 Thread의 개수
  • MaxPoolSize : 동시 동작하는, 최대 Thread 개수
  • QueueCapacity : CorePoolSize를 초과하는 요청이 Thread 생성 요청시 해당 내용을 Queue에 저장하게 되고, 사용할 수 있는 Thread 여유 자리가 발생하면 하나씩 꺼내서 동작
  • ThreadNamePrefix : Spring이 생성하는 쓰레드의 접두사를 지정
  • 참고

• PaymentInfo NoArgsContructor 추가

  • 이제 dev 서버 DB가 h2가 아니라서 로컬에서 돌리기가 힘들었으..
  • 그래서 Performance 환경으로 돌려서 테스트 해보았는데, Mock 결제 모듈 API를 사용하는 도중 PaymentInfo를 파싱하지 못하는 에러 발생해서 추가해줬어!

• index.html

  • 변경된 결제 로직에 맞춰서 수정해놨어!

ps. 추가로 여러 상황에서 다른 Async 설정을 사용하고 싶을 때는 어떻게 할까 찾아봤는데 이때는 @Overide말고 @Qualifier를 선언해서 사용한대!

• 참고

1. 정산 수수료 페이지에 접근할 수 있는 메인페이지의 플로팅버튼을 하나 만들었어

• 데스크탑 해상도에서는 innerTemplate을 벗어나서 배치를 해야돼서, 여백 때문에 fixed 처리했구

• 그 이하 해상도에서는 sticky로 footer를 안가리도록 처리했어

2. footer에 링크를 추가해서 다른 페이지에서는 이 링크로 접근가능

3. 정산 수수료 페이지

고민할 점

Payment 부분

• 필드로 member를 가지는데, 이전에 Donation의 경우 생성자 파라미터로 member를 바로 전달하지 않고, 일단 member가 null인 Donation을 생성하고 이후에 donation.to(member) 로 Donation의 member를 지정한다.
• 수요일 코드 합치기 진행할 때, Payment 또한 payment.to(member) 코드를 자연스럽게 만들었는데, 일단은 .to(member)를 하는 방향으로 변경하였음
• 대신 .to(...) 메서드의 경우 payment의 member 필드와 email 필드(Embedded type)를 둘 다 초기화하도록 하였다.

PaymentPendingReqeust

• itemId 를 Item의 각 상수값 이라고 보면 되는건지? 아니면 별개의 것으로 보면 되는거지? —> 이 부분 백엔드 측은 enum과 동일한 value를 주면되겠네~ 라고 했는데 파노가 완전 별개의 값을 주는게 더 안전하지 않을까? 라는 의견을 줬던거 같음.
• 이부분 확실하게 정해진게 없는거 같아서 임시적으로 enum에 일치시키는 것으로 함

Payment API 회의록에 아래와 같이 적혀있기는 함

MockTimeEntity (@CreateAt 필드 값을 필요로하는 테스트 용)

개인취향 JPA 사용기 2편 — Entity with Getter,Setter and Test | by Gemini Kim | Medium 내용 참고해서 MockTimeEntity 클래스를 생성함

• protected 필드에 접근 못한다고 에러 뜸

MockTimeEntity class

public class MockTimeEntity extends BaseTimeEntity {

    public static <T extends BaseTimeEntity> T mock(Class<T> clazz, LocalDateTime localDateTime) {
        try {
            T mock = clazz.getDeclaredConstructor().newInstance();
            mock.createdAt = localDateTime; // /todo: 이 부분 protected면 접근이 돼야하는데… 왜 안될까…? (임시로 public)으로 둠/
return mock;
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }

}

에러 내용

변경내용

Item Enum 애너테이션으로 Custom Validator 만들기

참고자료: Annotation으로 Enum 검증하기

Payment- util 패키지에 Enum 어노테이션, ItemValidator 클래스 참조! 사용한 위치: PaymentPendingRequest (요청 필드가 많이 바뀌었는데, 해당 필드에 대한 에러를 BindingResult에 전달하기 위해 CustomValidator 구현 <- 기존 방식)

PaymentInfo의 필드 값 변경

기존에는 아임포트가 저장하고 전달하는 결제 결과 중 name 필드를 우리 서비스에서는 pageName으로 저장했다. 하지만 우리의 서비스가 변경됐기 때문에… pageName 보다는 itemName (or itemCode… etc)이 더 적절하다고 생각하여, 변경함.

Payment 관련 API들 인터셉터 등록

• /payments/** 인터셉터에 등록하였음
• 이 부분은 수리도 동일한 작업을 한 것 같은데.... 🤔 충돌날 수도 있을듯.. 🥲

closed 335

환불 관련 인수테스트 작성하는데 어려움이 있어서, 리뷰를 먼저 받으려고합니다.

PaymentAcceptanceTest 에 주석으로 각 테스트에 대한 문제점을 간략히 적어놨으니 같이 참고해주시면 될 것 같습니다.

문제상황

테스트를 할 방법을 제시좀 부탁드립니다 🙏

1. refundVerificationNotExistRemainTryCount
   • 10번의 시도횟수를 차감시켜서 0으로 만드는 방법 (이 방식도 적용이 안됌, refundFailure가 매번 초기화되는 것 같음..)
   • 이 부분은 로직의 문제인지 횟수가 차감이 안됌... (10번 반복하면, 10으로 초기화 된 뒤, 1씩 차감하여 9라는 결과가 나옴)
   • 애초에 10번이라고해서 for문으로 10번 인증을 반복하는 행위도 좋은 방식은 아닌 것 같음.
2. refundPaymentCreatorNotHaveEnoughPoint
   • 예외 1: Member가 가진 Point가 donation 금액보다 적으면 예외!
   • paymentService#refundPayment의 예외1 부분, 이 경우를 테스트하려면 어떻게 해야할까 ?
   • member의 point를 차감시킬 방법이 없을까?
3. refundPaymentNotMatchingRefundInfo
   • 아임포트에서 조회한 결제 정보와 우리 서버에 저장된 정보가 일치하지 않은 경우 예외!
   • 현재 AcceptanceTest에서 @BeforeEach로 mocking을 통해 아임포트에서 조회한 정보를 가져오고있음. (부분 모킹을 하려면 해당 부분에서 진행해야한다)

그 외

PaymentAcceptanceTest 클래스 하단에 보면 아래와 같은 private 메서드가 있음.

이 경우 repository를 모킹해야해서, 부득이하게 public static 형식으로 만들 수가 없어 일단 private 메서드로 만들었는데, 이렇게 진행을 해도 괜찮은지? 의견을 주셨으면 합니다.

혹시나 왜 public static 얘기가 나왔는지 궁금해할까봐 아래에 사진 첨부!

우리가 이미 인수 테스트시에 이런 식으로 한글 메서드를 통해 편의를 위한 API 메서드를 만들었는데, 이전 양식에 위배되는 것 같아서... 같이 작성했습니다.

시간 되실 때, 피드백좀 부탁드려요 😅

아래는 아임포트 환불 플로우야.

1. 클라이언트에서 우리 서버로 환불요청을 해.
   • 이때 imp_id, merchant_uid, 환불사유, 환불금액 등을 받을 수 있는데 지금은 merchantUid만 받도록 했어.
   • 영수증에 imp_id 밖에 없어서 merchant_uid를 후원자가 알 수 없다면 imp_id로 변경할 수도 있어. 아임포트에 환불API 쏠 때는 merchant_uid, imp_id 둘 중 하나만 줘도 잘 동작해.
2. DB에서 결제 정보 조회.
   • 그림에선 2번이 인증 토큰 발급인데 코드상에선 3번의 결제 정보 조회를 먼저했어.
3. 인증토큰 발급.
4. 아임포트에 환불 요청
5. 환불결과 동기화
   • 결제 성공 로직과 비슷하게 작성했어.
6. 환불응답
   • 지금은 merchant_uid만 응답중.

PaymentSaveResponse -> PaymentPendingResponse Save보단 Pending이 적절한것 같아서 이름을 바꿔봤어.

close #508

as is: users/{memberId}/profiles or bankbook

to be: users/profiles or bankbook/{hashedInfo}

리눅스 디렉토리 개수 제한

해싱은 별도의 해싱 알고리즘 써야하나 싶었는데, 개인정보 저장할 때에 AES로 썼길레 그냥 이거 가져다가 씀
참고한 링크

• 매월 1일 00:00시에 스케줄러를 등록
• 정산 금액을 계산하는 SQL추가
• AdminService에 calculateExchangeAmount에 해당 로직이 들어있음!

제안

• MemberService의 exchange()를 requestExchange로 변경하면 어떤지,,

close #440

작업내용

• DonationStatus 를 기존 4개(‘환불가능’, ‘정산가능’, ‘정산완료’, ‘취소됨’)에서 2개로 (WAITING_FOR_EXCHANGE, EXCHANGED) 변경
• Donation의 DonationStatus를 CANCELLED, EXCHANGEABLE로 변경하는 기능
• Donation.toCancelled() , Donation.toExchangeable() 기능 제거
  • 관련 테스트도 모두 삭제
• Donation을 처음 생성했을 때 처음 DonationStatus를 WAITING_FOR_EXCHANGE로 초기화
• 공개 도네이션
  • findFirst5ByMemberAndStatusNotOrderByCreatedAtDesc() 기능 status로 필터링하지 않도록 변경
• DonationRepositoryTest에 불필요한 PaymentRepository 필드 제거

고민되는 부분

DonationRepositoryImpl 클래스

변경전

DonationStatus가 2개로 변경되면서 QueryDsl로 작성한 exchangeablePoint 와 currentPoint 가 동일한 로직으로 보임

변경후

• currentPoint의 의미는 정산 가능 + 정산 불가 를 합한 총 포인트
  • But 정산 불가능한 포인트는 없다.
  • currentPoint 기능은 없어져야할 것 같음. (테스트도 같이)
  • 일단은 안 지우고 그대로 뒀는데… 혹시나 지우면 안될까봐 일단 뒀는데 지워도 될지 안될지 코멘트 주면 좋을 것 같음

MemberService#validateExchangeable 메서드

• 정산 금액이 10,000원 이하인 경우 예외 발생하도록 되어있는 로직이 이 코드인데…
• 10,000 미만인 경우에만 정산 불가능하도록 변경 (이거 내가 해도 되는거지…?)

결론

DonationRepositoryImpl 클래스에 currentPoint(...) 삭제해도 되는지...? 🤔 (삭제해도 된다고 하면 메서드 삭제 + 테스트 코드 삭제할 예정)

번외…

여러분 … DonationType 이거는 뭐죠…?
이거 프론트 크루들이 만든거같은데 이게 뭐지…? 우리 도메인에 쓰이는 곳 없음. 필요없는거면 삭제하면 될 듯 Release할 때 생긴걸로 봤을 때는 force push 하다가 생긴게 아닐까…?

Closes #397

DonationRepository#findDonationByCreatorOrderByCreatedAtDesc()

1. OrderBy 개선

workbench 에서 퍼포먼스db로 쿼리시 평균 7초대 걸림 (오프셋없이). creator_id=1 일 때 7-9s, creator_id=2 일 때 3-4s. creator_id 가 1인 donation은 row 1,000,000 개, 2는 row 618,338 개야.

대안

1. id로 정렬 -> 6ms
2. created_at desc 인덱스 -> creator_id가 1이면 2s, 2면 6ms
   • created_at으로 인덱스를 걸면 creator_id 에 따라 Duration이 달라져.
   • 1,2 모두 실행계획은 동일함.

일단 id 정렬로 해놨는데 꼭 createdAt으로 정렬해야하는 이유가 있다면 코멘트로 알려줘.

2. paging 쿼리 개선

limit offset 방식을 개선 기존에는 퍼포먼스db 기준 offset 40,000부터 0.1s, 280,000부터 1s 넘어감. (정렬을 id로 걸었을 때 기준)

다들 아는 내용이겠지만 offset은 앞의 row 결과를 모두 읽은후에 버리기 때문에 필요없는 쿼리작업이 커서 성능이 좋지 않아. 그래서 offset 대신 where 로 id로 조건을 걸어서 쿼리 하도록 개선했어. 앞으로 이걸 no offset 방식이라고 말할게. no offset 방식은 더보기 방식으로만 구현이 가능해. 일반적인 페이징()에 적용할 수 없나 정말 많이 생각해봤는데, 결론은 불가능한걸로 나왔어. 우리 페이징은 더보기 방식이니까 그대로 진행하면 될 듯. 대신 API 수정이 필요해 (/donations/me).

API 변경점

AS-IS

# 요청 url
/donations/me?size=2&page=1 

# 응답 json
[
    {
        "donationId" : 1,
        "name" : "name1",
        "message" : "message1",
        "pageName" : "pagename",
        "amount" : 1000,
        "createdAt" : "2021-10-21T10:47:44.620008"
    },
    {
          ...
    }
]

TO-BE 쿼리파라미터 lastPageId = 전 페이지의 마지막 도네이션의 id. 다른이름도 추천받음 lastPageId가 0이면 가장 최신, 0이 아닐경우엔 where id < lastPageId로 조건을 걸어 해당 도네이션부터 조회.

• 1안: 응답json에 "lastPageId" 필드를 따로 줘서 프론트가 다음 요청할 때 쿼리파라미터로 전달. 응답json 형식이 바뀐다는 단점.
• 2안: 응답json 기존과 동일. JS에서 마지막 원소의 donatioId를 빼서 요청.

요청 url (1,2안 동일) /donations/me?lastPageId=1

응답 json

# 1안
{
    "lastPageId": 5
    "result": [
        {
            "donationId" : 1,
            "name" : "name1",
            "message" : "message1",
            "pageName" : "pagename",
            "amount" : 1000,
            "createdAt" : "2021-10-21T10:47:44.620008"
        },
        {
              ...
        }
    ]
}

# 2안
# AS-IS 와 같음

조졸두님의 페이징 성능 개선 아티클을 참고했어.

3. 이름 변경: find5NewestDonationsPage()

이름에는 paging 쿼리라는 뜻, 최신것부터 5개씩 가져온다는 뜻이 있었으면 좋겠어서 일단 이렇게 지었는데 더 좋은 의견있으면 얘기해줘!

기타

1. DonationRepository 의 donationOwner() -> donationReceiver() 프로젝트에서 DonationOwner라는 표현이 두 곳에서 쓰이는데, 서로 의미가 달라. 그래서 후원을 받는 창작자쪽은 Receiver로 바꿨어
   1. WrongDonationOwnerException은 후원자인지 검사
   2. 레포지토리쪽의 donationOwner()는 창작자인지 검사.
2. MemberRepository#findCurations() 성능 이슈 퍼포먼스db 기준 평균 14sec이 걸렸어. 단발성 쿼리로 같은 결과에 내지만 성능좋은 쿼리를 짜긴 힘들것같고, 아마 다른 방식으로 접근해야 할 것 같아.
3. DonationRepository#calculateExchangeAmountFromDonation() 제거

정산금액 작업 중복 실행 방지를 위해 ShedLock를 적용

• 로드밸런싱으로 WAS가 2대 동작 중이다.
• 정산 금액 계산 로직은 스케줄링을 통해 매달 1일 동작하도록 설정되어 있다.
• WAS 2대에서 해당 로직이 모두 동작할 필요가 없으며 1대만 돌아가면 됨

https://velog.io/@recordsbeat/%EB%A9%80%ED%8B%B0-%EC%84%9C%EB%B2%84%EC%97%90%EC%84%9C-%EC%8A%A4%EC%BC%80%EC%A4%84-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0-ShedLock

요청 url 변경

AS-IS: /donations/me?size=2&page=1 TO-BE: /donations/me?cursorId=0

cursorId

• **첫 페이지는 0**으로 요청
• 그 후는 저번 응답에서 마지막 원소(도네이션)의 donationId 로 요청

응답 json 예시

[
    {
          ...
    },
    {
          ...
    },
    {
          ...
    },
    {
          ...
    },
    {
        "donationId" : 5, // <- 5, 10, 15 단위로 오지 않음!!! 마지막 도네이션id에 뭐가 올지는 항상 다름
        "name" : "name1",
        "message" : "message1",
        "pageName" : "pagename",
        "amount" : 1000,
        "createdAt" : "2021-10-21T10:47:44.620008"
    },
]

만약 이렇게 온다면 마지막 도네이션의 donationId는 5기 때문에 다음 요청시 cursorId를 5로 요청