멘토링 날짜 : 2024년 1월 17일 수요일 오전 10:10
이번 주 한 일
•
기획 및 기획 개편
◦
아키텍처적으로 바닥부터 하기 보다, AWS의 여러 기능을 잘 활용하는 쪽으로 변경함
◦
현재 프로덕션 기능을 완성 후, 더 볼륨을 키우기로 계획 중.
•
프론트 환경 설정 및 개발
◦
Vite, React, MUI, Zustand, React query 사용.
◦
CloudFront & S3 로 프론트 배포 완료
◦
◦
HTTPS 완료
•
백엔드 배포 환경 구성 완료
◦
로드 밸런서 설정 완료
◦
스케일 아웃 설정 완료
◦
무중단 배포 설정 완료
◦
◦
HTTPS 완료
•
2024년 1월 17일 오전 중으로 기능 완성을 목표로 함.
•
팀원 개인
김재윤
임지훈
장규빈
황규정
기술적인 방향을 잡기 위한 질문 정리
•
동시성 제어 :: 현재 도메인 요구사항 특성상, 해야할까?
1.
사용자 포인트 동시접근 시나리오
•
{ 내 판매입찰을 누군가 즉시구매한 경우 } { 판매입찰을 내가 즉시구매한 경우 }
{ 판매입찰을 내가 즉시구매한 경우 } •
{포인트 - - } {포인트 ++}
{포인트 ++}2.
구매/판매 동시접근 시나리오
•
하나의 트랜잭션 내에서 판매입찰 / 구매입찰을 조회, 삭제 처리 중,
•
만약 여러 사용자가 동일한 판매입찰 / 구매입찰 데이터에 접근한다면 ??
•
MVC 아키텍쳐를 이렇게 가져가도 괜찮을까
◦
Service를 Provider 와 Service로 분리
Provider : 유스케이스 흐름제어 << 다른 도메인 서비스 의존주입
Service : 해당 도메인의 세부 비즈니스 처리 (데이터 조회,조작,가공)
▪
네이밍을 이렇게 규정지어도 될까?
▪
현업에서는 어떻게 하는가?
•
현재 Redis를 EC2에서 띄워서 사용하고 있는데, 클러스터 구성을 안 할 거라면, ElasticCache를 사용하지 않아도 될까요?
숙제: 멘토링 결과 및 다음 주까지 해올 일
•
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
◦
•
팀원 개인별로 작성해 주세요.
•
이외에도 기술적인 방향을 잡기 위한 질문을 정리해두시면 가장 좋습니다!
→ 단, “A는 어떻게 구현하나요”의 질문은 삼가주세요.
→ “A와 B를 알아보았는데, 둘 중 A가 낫다고 판단했는데 맞을까요?”의 식의 고민의 흔적을 담아 질문해주세요.
•
멘토링 결과:
[배치와 스케쥴링의 차이점]
배치 : 특정 시점에 일괄 데이터를 처리하는 작업
스케쥴링 : 매 주기마다 특정 작업을 실행하는 작업
배치를 구현하는 과정에서 스케쥴링이 필요.
[스프링 쿼츠 vs 스프링 배치]
스프링 배치가 쿼츠를 흡수하여 현재(24.01.17) 스프링 배치 라이브러리를 내려받으면 쿼츠를 함께 사용 가능함.
[동시성 관련 질문]
•
동시성 제어의 주체 : 모델 -> DBMS
•
MVC (3 tier 아키텍처) 중 가장 중요한 부분 : 모델 (동시성을 제어함)
•
동시성 제어가 일반적으로 왜 필요로 하는지 ?
: ACID 지켜야 하기 때문
-> ACID 하면 무엇이 좋나요?
: 데이터 정합성을 유지할 수 있음
[배치 작업 동시성 제어 질문]
•
배치 작업 할 때 동시성 제어를 해야하는 상황:
- 인스턴스가 2개
•
해결 방안은 4가지
1. 배치 인스턴스를 따로 띄워서 작업 -> 물리적으로 구현 시간 오래걸림
2. 기존 인스턴스에서 딱 1대만 실행하기
- 레디스 분산락 걸면 랜덤 1대가 실행되므로, 특정 1대가 실행토록 하기
3. 이마저도 안 되면, 마지막으로 레디스 분산락
4. 하지만, 돈주고 상용 SW 쓰는 것이 직접 개발하는 것보다 나음
해결 방안:
1. 따로 배치 인스턴스를 띄워서 작업하기
2. 삭제 작업이므로 여러 인스턴스가 같은 데이터를 삭제하는 것은 문제가 되지 않을 것 같음
3. AWS의 Lambda를 이용해서 사용하기 (결정된듯)
[[2주차 멘토링 노트]]
[동시성 제어 질문]
동시성 제어는 직접 서버를 돌려봐야 확인 가능할 것 같다.
•
동시성 제어의 주체는 DBMS이고, 대부분의 상용 DBMS는 동시성 제어를 위한 옵션을 제공하므로, 사실 우리가 신경쓸 필요는 없음 -> isolation 옵션 이용해보기 (대표적으로 오라클, MySQL)
데이터 정합성 오류가 발생한다면, 99% 서비스 로직의 문제.
[MVC 아키텍처 질문]
•
특별히 코멘트 x
•
~~해서 ~~하도록 결정했다. 정도만 가져가기
[레디스 질문]
•
이미 잘 구성하고 서비스 되고 있다면 엘라스틱캐시 안 쓰고 EC2에 올려 써도 문제 X
[인프라 구성]
•
아키텍처 그림 상에 Saas, function이 섞여있음. 구상도 유튜브 영상보고 수정할 것.
[부하 테스트]
•
JMeter를 이용하여 부하테스트할 때 라우터53을 통하는 것과 직접 인스턴스에 쏘는 것의 차이점
: 클라우드 프론트를 통하냐, 로드밸런서를 통하냐
: 대용량 트래픽 관점에서, 로드 밸런서는 부하가 낮은 EC2로 보내져서 성능 더 빨리짐
: 클라우드 프론트에서는 지리적으로 가까운 캐싱서버로 요청되어 속도 빨라짐
: 부하 테스트의 목적은 여러가지 있지만, 많이 부하를 받아 확인하고 싶은거라면 CF와 LB통할 필요 X
: CF, LB 로 보내면 로드밸런싱이 잘 되는가, 캐싱되어 속도가 빨라졌는가를 테스트할 때 씀, 하지만 돈 많이 듦
: 오토 스케일링이 잘 되는지 테스트 해보고 싶으면 일회성으로 대용량 없이 테스트해보면 됨.
•
튜터님의 조언
•
기술 검색을 할 때는 3년 이내로 필터링을 추천함
•
기술 면접 열심히 준비하기 !!
•
숙제: 멘토링 결과 다음 주까지 해올 일
◦
아키텍처 구상도 재구성
◦
기술면접 준비 잘하기
