2024-01-22

오늘은 프로젝트 19일차이다. 오늘은 중간발표가 있는 날이였다.

중간발표를 하기 위해 주말동안 프론트를 테스트를 진행하면서 시간을 보냈고. 내가 담당한 파트의 부분은 전부끝났지만 팀원들의 파트가 끝나지 않았기 때문에 팀원들의 파트를 도와드리면서 최대한 마무리에 신경썼다.

 

다음은 프로젝트를 진행하면서 튜터님들이 프로젝의 전반적으로 살펴보시고 질문 주신것에 대한 답변 내용이다.

 

1. 특정 경매가 인기가 좋아 트래픽이 많이 발생했다면 어떤식으로 대응 할 계획이신가요?

    - 기본적으로 트래픽이많아 서버의 CPU 로드율이 높아지면 AutoSaciling 설정을 통해 추가 ec2 인스턴스를 배포할 계획입니다.
    -  DB, Redis 의 경우에도 RDS, Elastic Cache의 클러스터 설정으로 동적으로 노드를 늘려주거나 줄여주어 트래픽에 대응할 수 있습니다.
      다만 무작정 서버를 늘리는것에는 코스트 한계가 있기 때문에, 일정 치 이상 부하가 되면 alb 앞 단에 대기열 큐를 구성하여 트래픽 제어를 할 계획입니다.

2. 경매, 선착순 결제 등 좌석이 결제가 된 상황에서 공연이 취소 될 경우 환불을 진행해야
 하는데 이 때 DB에 어떻게 반영할건지 전략을 알려주세요.

   예매 상태에 환불 상태 추가하여 예매 상태 식별
환불 작업 배치 프로그램 개발
환불 공연 선택
공연에 포함된 모든 결제된 기록을 각각 별도의 트랜잭션으로 결제 취소 처리를 진행한다.
환불 처리에 대한 로그를 별도의 테이블에 기록하여 트랜잭션 오류 발생시 재처리를 시도
사용자한테 환불 처리 알림

3. Mysql 에도 입찰 테이블이 있고 Redis에도 입찰 테이블이 있는데 어느 시점에 어떻게 동기화가 진행되는지 동기화를 하는 이유는 무엇인지 알려주세요.

 - 우선 입찰 API 를 통해 입찰을 하게 되었을 떄, Redis 의 입찰가를 조회하여 상횡입찰인지에 대해 검증을 수행합니다.
   상회 입찰일 경우 DB 입찰 테이블에 입찰 정보를 저장합니다.

   결국 경매 입찰은, 아무리 많은 입찰 요청이와도 '상회입찰'만 실제 입찰이 되기 때문에, Redis를 통해 입찰 검증을하게되면 그만큼 DB에 부하를 주지 않습니다.
   그리고 Redis 입찰가 갱신하는 시점에 같이 DB 동기화를 해주는 이유는 다른 유저가 첫 경매정보를 조회할때, 해당 경매의 입찰테이블 에서 가장 높은 금액의 입찰가를 조회하기 떄문
   입니다.

4. 대용량 트래픽을 목표로 하고 있는데 알림 푸쉬 전략도 궁금합니다.

   입찰가 갱신과 추후 구현 예정인 경매 상태 알림 등 SSE 통신을 하게 되는데, SSE 연결객체는 각 서버의 메모리에서 관리를 하게됩니다.
   대용량 트래픽 처리를 위해서는 분산 서버 환경이 필수인데, 서버가 분산되는경우 SSE 알림이 각 서버별로 따로 동작하게 됩니다.
   이를 해결하기 위해 Redis Pub/Sub 구조를 활용하여 Client에 SSE 를 통해 메시지를 보내야 하는 경우, Redis 에 Publish하여 필요한 메시지를 서버들이 구독하여 각 SSE에
   연결된 클라이언트들에게 보내도록 구현하였습니다.

5. 로그인 전략과 선택 이유를 대규모 트래픽 이라는 키워드에 맞춰서 말씀해주세요

   대용량 트래픽 처리를 위해서 서버가 2대 이상 운영되어야 할 필요성이 있기 때문에, 분산, 무상태 아키텍처를 지원하는 JWT 를 이용한 로그인 전략을 선택하였습니다.
그리고 global redis를 통해 로그아웃 상태와 유효기간이 상대적으로 긴 refresh token을 관리함으로써 여러 서버 간에서 일관된 유저의 로그인 상태를 유지할 수 있도록 하기 위해 jwt 방식을 선택했습니다.

1. ERD가 초기와 많이 바뀌었습니다. 바뀐 이유와 어떤점이 개선 되었는지 설명해주세요.

초기에 ERD를 설계할때는 프로젝트 기획상 예매와 경매를 구분하고 화차별로 관리되어야 하기 때문에 공연장을 생성할때 생성된 좌석정보들과 공연이 생성될때 생성되는 회차별 좌석의 정보를 가지고 있는 공연 회차별 좌석 테이블을 생성하여 관리했습니다.
이러한 관리방식은 사용하지 않는 데이터가 발생할 경우가 많고, 공연정보가 생성될때마다 회차별로 좌석을 생성하기 때문에 적게는 1000~ 수만개의 좌석이 한번에 생성될 경우가 발생합니다. 이럴경우 DB가 부하가 심각하게 걸려 정상적인 서비스를 운영할 수 없다고 판단했습니다.

개선된점은 기존의 좌석에 대한 문제를 구역과 등급테이블로 분리하고 동시에 관리할 구역 등급 테이블을 추가하여 예매와 경매를 등록할시 좌석정보가 생성되게끔하여 사용하지 않는 데이터가 없게끔 변경하였고 동시에 생성트래픽을 관리하는것이 아닌 분산으로 트래픽을 관리하게 끔하여 DB부하를 최소화 했습니다.

2. Front 배포를 CloudFront로 선택했는데 그 이유를 설명해 주세요, 또 CDN이 무엇인지 설명해주세요.

CloudFront는 전세계에 분산된 서버 네트워킹을 사용하면서 트래픽이 급증하더라도 자동으로 확장이 되기 때문에 안정적인 성능을 유지하는 동시에 서버를 이용하는 비용이 낮고 CloudeFront의 장점인 캐싱키능을 사용하여  실시간으로 변동되는 경매 입찰 정보 요청 리소스의 응답시간을 단축해줍니다. 또한 AWS서비스와의 원할한 통합이 가능하기 때문에 선택했습니다.
CDN은 전 세계의 여러 지역으로 분산된 서버 네트워크를 말합니다. CDN의 핵심적인 목적은 지리적으로 분산된 사용자에게 웹 콘텐츠를 더 빠르고 효율적으로 제공이 가능하며,
분산된 서버를 통해 급증하는 트래픽에도 효율적으로 처리 할 수 있고, 비용절감 측면에서 큰 장점이 됩니다. 또한 자주 요청되는 콘텐츠를 캐시에 저장하여 다음 사용자가 같은 콘텐츠를 요청할 때 더 빠르게 제공할 수 있는 장점이 있습니다.

3. 입찰페이지에서 프론트 - 백엔드의 역할과 권한에 대해 설명해주세요

사용자가 직접 실시간으로 입찰을 진행하는 상호작용된 결과를 웹 페이지에서 실시간으로 보여주는 역할을 담당하며 입력과 행동에 따라서 발생한 데이터를 처리하고 유효성 검사를 진행하여 서버로부터 필요한 데이터를 요청하고 받은 응답을 표시할 권한이 있다.

백엔드는 사용자의 실시간으로 들어오는 요청을 비즈니스 로직으로 처리하며 여러 요청이 동시에 들어올때 이를 효과적으로 DB와 상호작용하여 필요한 데이터를 순서대로 처리 및 관리를 통해 사용자에게 즉각적인 피드백을 줄 수 있는 역할을 담당하며, 사용자에게 요청에 따른 데이터를 프론트엔드로 전송할지 결정하고 사용자의 접근 권한을 관리할 권한이 있습니다.

4. CI/CD를 적용한다고 하면 입찰 중에 배포가 될 수도 있습니다. 이럴 경우는 어떻게 동작하는지 예상 시나리오를 알려주세요.

블루/그린 배포는 CI/CD 프로세스의 일부로, 두 개의 병렬 환경(블루와 그린)을 사용, 개발자가 코드를 업데이트하면, CI 도구가 자동으로 테스트와 빌드를 수행한다. 테스트가 성공적으로 완료되면, 새 코드는 스테이징 환경에 배포되고 이후 프로덕션 환경에서 '그린' 환경에 새 코드가 배포되고, '블루' 환경은 기존 코드를 계속 운영한다. 배포가 안정적이면 트래픽이 점차적으로 '그린' 환경으로 이동 후 문제 발생 시, 트래픽을 신속하게 '블루' 환경으로 되돌려 롤백한다. 이 방식은 서비스 중단을 최소화하고 안정적인 코드 배포를 보장할 수 있다.

시5. 해당 프로젝트를 진행하면서 효율적이였던 협업 방식과 비효율적이였던 협업 방식을 하나씩 설명해주세요.

저희는 프로젝트를 진행하면서 문제상황이 발생했을때 서로 의견을 제시하며 합리적인 방향으로 타협하며 결정하는 방식으로 진행했습니다. 이러한 방법은 프로젝트의 문제상황을 팀전체가 알 수 있고, 개발 진행하면서 추가적인 문제가 발생했을때 인지한 부분에 대해서 빠르게 대처가 가능하다는 부분에서 효율적이였습니다.

개발 스코프가 높다보니 서로 어디까지 진행했는지에 대해서 소통하는 시간 없이 개발에만 집중하는 진행방식을 고수했었습니다. 이런방식은 각자 맡은 개발 부분만 이해하고 있고 서로 개발하는 부분에 대해서는 이해의 정도가 미흡했었기에 결론적으로 병합하여 통합으로 테스트 하는과정에서 비효율적이였다고 생각합니다.