1. API 명세에 보면 주문 기능에 대한 API 가 /buy, /sell, /my 이렇게 3가지로 나누어져 있는데요. 주문이면 /orders 가 들어가거나 제품에 대한 동작이라면 /products/{productId}/sell 이런식으로 하는게 더 좋지 않을까요? 어떻게 생각하시나요?

• 동작에 대한 API 설계
  • Domain으로서 먼저 접근을 하려고 하였습니다. REST API 를 설계하고자 resource 위주로 설계하였기에 각각의 domain 에 따라 API를 구성하게끔 하였습니다.
  • 하지만 말씀해주신 내용을 기반으로 몇 가지 API를 수정할 예정에 있습니다.
    • 가령 즉시구매와 즉시판매 같은 경우, /api/sell/{productId}/now를 사용하여 판매입찰도메인을 사용하기 보다, /order를 사용하는 것이 좋아보인다고 생각합니다.
  • 판매입찰을 sell로, 구매입찰을 buy로 나타내고 있기 때문에 동작으로서 사용되고 있지 않습니다.

2. API 명세에서 하나만 더 말씀드리고 싶은건 판매 입찰내역, 완료내역을 추출할때 경로는 /history 까지만 명시하고 그뒤에 입찰/완료 여부는 쿼리 파라미터로 구현하는게 좋지 않을까요? 어떻게 생각하시나요?

• 쿼리파라미터로 받게 되는 경우, 상태에 대한 정확한 값을 알아야 하기 때문에 두 상태에 따른 API로 분리하였습니다.
• 현재 구매 입찰 상태가 두 가지로 한정되기 때문에, 쿼리파라미터로 분기처리하는 것은 효율적이지 않다고 생각했습니다.
• 하지만 서비스가 확장되어 입찰 상태가 여러가지인 경우에는, /api/buy/history에 쿼리 파라미터로서 상태를 조회하는 방법으로 리팩토링 할 것 같습니다!

3. ERD 상으로는 쿠폰을 주문에 사용했을때 연관관계를 표현하지 못하는 것 같습니다. 쿠폰을 사용하는 기능도 고려해서 주문 데이터와 연관관계를 만든다면 어떻게 만들 수 있을까요?

• 연관관계를 뺀 이유
  • 만약 주문도메인과 쿠폰도메인 간의 연관관계를 만들게 되는 경우, 여러 주문에 대해 여러 쿠폰이 사용될 수 있으므로, 다대다 연관관계를 사용해야합니다.
  • 이는 기존에 하나의 주문에 대해 구매자,판매자,상품에 대한 조인에 추가적인 쿠폰 조인 연산까지 처리해야하는 오버헤드를 발생합니다.
  • 현재 정책과 앞으로의 정책을 미루어보았을 때, 쿠폰은 단지 가격에 대한 할인의 역할을 해주는 도메인일 뿐, 주문과 쿠폰과의 연관관계를 나타내어 데이터로 저장할 필요가 없다고 생각합니다.
  • 따라서 저희는 쿠폰에 대해서 팩토리 혹은 ENUM을 사용하여 할인정책에 대한 할인만 연산수행하기로 하였습니다.
• 만약에 연관관계를 만들게 된다면
  • 다대다 연관관계를 만들어서 외래키값을 설정한 뒤,
  • 해당 외래키값을 Nullable하게 설정하고,
  • 쿠폰과 주문과 상품과 유저를 조인을 통해 요청을 처리할 것 같습니다.
  • 만약 조인 오버헤드가 심하다면, 주문에 대한 어그리거트를 도큐먼트 형식으로 표현하여 저장할 것 같습니다.

4. 아키텍쳐 상으로는 프론트 배포에 대한 내용이 안보이는데요. 프론트 배포 과정에 대한 설명을 추가로 해주세요.

• 재윤
  • 프론트는 팀원 1명이 담당하기로 해서, 깃 브랜칭 전략은 따로 없이 main 브랜치에 바로 푸쉬하도록 하였고, github action을 이용하여 main 브랜치에 푸쉬가 되면 빌드 후 AWS S3에 정적 파일들이 배포가 됩니다. 그리고 cloudFront에서 S3의 파일에 접근하여 사용자가 이용할 수 있도록 하였습니다.
  • 이를 통해 수동으로 S3에 배포할 시간을 줄여서 코드 작성에 더욱 시간을 쏟을 수 있었으며, 또한 클라우드프론트에 배포까지 함으로써 사용자는 지리적으로 가까운 캐싱 서버로부터 정적 파일을 내려받아 빠르게 이용할 수 있게 되었습니다.

5. 도커 스케일 아웃을 구현하셨다고 되어있는데 수동으로 스케일 아웃하는지 자동으로 하는지 자동으로 한다면 어떻게 할 수 있을지 얘기해주세요.

• 현재는 아키택처가 바뀌어서 nginx가 아니라 AWS Application Load Balancer를 이용한 자동 오토 스케일링을 적용했습니다.
• Nginx에서 AWS Load Balancer로 아키텍처를 변경하였습니다.
• 이유로는 Nginx의 설정 허들이 AWS Load Balancer 보다 높지만 설정 허들에 비해 성능이 동일하거나 비교적 낮기 때문입니다.
• 현재 타켓그룹에 대한 인스턴스 증가 설정을 자동으로 설정하였습니다
• 인스턴스에 부하가 생기면 최소 1개에서 최대 3개까지 인스턴스가 늘어나도록 설정했으며 추후 부하테스트를 통해 인스턴스를 늘려나가며 트래픽에 대한 대응책을 마련할 예정입니다. 👍(지훈)

6. MySQL DB를 Master&Slave 구조로 구성해주셨는데요 각각의 역할이 무엇이며 Master 에서 장애가 발생했을 경우 어떻게 조치해야할 지 과정을 설명해주세요.

• 규정
  • DB를 Master와 Slave로 나눈 이유는 DB에서 장애가 났을 때를 대비한 것 입니다. Master는 가장 주된 데이터베이스로 메인 데이터베이스라고 생각하면 될 것 같습니다. 역할은 데이터베이스의 쓰기 / 수정 / 삭제를 맡고 있으며, Slave는 데이터베이스를 읽는 역할을 합니다. 만약 Master에서 장애가 발생할 경우 추가적으로 있는 Slave 중 한 DB를 Master로 승격시키는 것으로 장애를 극복하려고 합니다. 👍(지훈)

7. Gihub 이슈나 PR 을 잘 정리해주시고 서로 리뷰도 잘 남겨주셨는데요. 서로 리뷰해주면서 좀더 좋은 방법을 찾고 개선한 경험이 있다면 대표적으로 한개만 얘기해주세요.