멘토링 날짜 : 2024년 1월 10일 수요일 오전 10:10
•
코드 컨벤션
◦
디렉토리명은 단수 명사
◦
클래스명은 파스칼 케이스
◦
테이블명은 tb_ 붙여서 통일성 유지
◦
엔티티는 -Entity 붙이지 말고 도메인명 그대로
◦
엔티티에 필요한 메서드 만들되, 명확하게 기능명을 메서드명으로 명명
◦
Repository에서 가져올 때 Optional 사용
◦
JpaRepository 상속 대신 RepositoryDefinition 어노테이션으로 필요한 메서드만 쓰기
◦
생성자는 서비스 코드 정적 팩토리 메서드, 테스트는 빌더 패턴 이용
◦
객체 간 변환 작업은 mapStruct 사용
◦
ResultCase로 성공 및 실패 케이스를 enum으로 묶음
◦
테스트는 단위 테스트만, 성공 케이스만을 다룸
◦
API당 요청, 응답 DTO 1개씩 만들기
◦
DTO 네이밍 규칙은 도메인 + 기능 + 요청/응답 + Dto, ex) UserLoginRequestDto
◦
DTO는 Record 사용
◦
패키지 구조는 domain, global, infra 로 나누어서, 하위는 각 도메인 별로 또 디렉토리 나누기.
•
깃플로우 전략
◦
Github flow 전략을 사용하여, main 브랜치를 유지하면서 새로운 작업을 시작할 때 브랜치 분기 후 작업하고 완료 시 머지.
◦
작업 시작 전 이슈로 작업 내용을 작성 후, 작업 완료 시 관련 이슈를 PR에 등록하기
◦
브랜치 분기 후 커밋에는 [#4] feat : add login api 와 같이 이슈번호 명시
•
배포 계획
◦
Github action으로 Ci & CD 구현하여 배포까지 진행.
◦
우선은 현재 EC2에 인스턴스를 1개 만들어둔 상태.
•
이번 주 한 일
◦
기획 및 기획 개편
(피드백) 전반적으로 잘 작성 되어 있음, 아래 기획과 관련된 문서 내용이 전체 목표 대비 얼마나 작성 되었는지 궁금합니다. → 1.10(수) 오전 피드백 시에는 기획 대비 예상 가능한 완성도를 얘기 해주셨던거 같습니다.
▪
시스템 상황 분석 및 기획서 작성
▪
ERD 작성
▪
와이어 프레임 작성
▪
API 명세 작성
▪
개발 컨벤션 작성
◦
개발 환경 설정
(피드백) 특별히 코멘트 할 내용 없습니다.
▪
깃허브 Organization 및 Repository 생성
▪
이슈 및 PR 템플릿 생성
▪
Branch protection 설정
•
main 브랜치 push 금지
•
PR approve 1개 이상 시 merge 가능
•
merge 시 브랜치 자동 삭제
▪
팀원 모두 AWS IAM 사용자 부여
▪
EC2 인스턴스 생성 및 pem 공유 완료
▪
프로젝트 기반 코드 작성
•
라이브러리, 디렉토리 구조, BaseEntity, 등등
◦
팀원 개인
▪
프로젝트 초기 설정을 하느라 다같이 모여서 의논하여 위를 진행했습니다.
김재윤
임지훈
황규정
장규빈
기술적인 방향을 잡기 위한 질문 정리
[부하테스트 관련]
•
부하테스트 프레임워크 ::: JMeter를 사용할까 vs nGrinder를 사용할까?
(피드백) 국내 테크 기업 타겟 → nGrinder / General → JMeter
[레디스 관련]
•
부하 테스트에서 1000개의 상품이 있다면 요청이 1000개 각각으로 균일하게 요청이 되는 것이 아닐텐데, 최대한 실제 환경과 같이 부하를 주려면 관련 알고리즘?
(피드백) 질문에 대한 답변부터 하자면 1~1000 integer 반복문을 돌리면서 2의 배수면 A상품, 3의 배수면 B상품… 이런식으로 요청을 주면 비중을 다르게 보낼 수 있으나, 부하테스트의 목적은 서버에 임계치 이상의 요청이 들어왔을 때 서버가 견고하게 버티면서 제대로 서비스를 처리해줄 수 있는지를 확인하는 것이 목표이기 때문에 균일하게 요청이 가냐 안가냐에 관심이 있는 부분은 아님.
◦
그리고 실제 상황과 비슷한 요청을 받을 때, 이를 캐싱하고 안 하고 의 기준들이 있는지
(피드백) 개발자가 그 때 그 때 판단함, 기준이라기 보단 휴리스틱이 있다고 얘기하고 싶음, 여러분들이 생각하기에 기준을 판단할 때 어떤 것들을 고려해서 캐싱 여부를 결정해야 할까요?
•
레디스 클러스터를 구성할 때, 직접 EC2에 구축을 해보는 것이 ElasticCache 와 같은 잘 구축된 서비스를 사용하는 것과 비교할 때 유의미한 경험일지.
(피드백) ElasticCache 쓰세요. AWS에서 항상 하는 말 - 바퀴를 재발명 하지 마라. 잘 만들어 놓은거 잘 쓰는것도 기술입니다.]
•
어떤 데이터를 캐싱해야할지 감이 잘 안 잡혀요. << 1차 멘토링 이후 질의>>
[메세지 브로커 관련]
•
메세지 브로커가 다음 역할을 위해 사용하려고 하는데 적합한지 궁금합니다.
(피드백) 일반적으로 적합하다고 생각됨
◦
큐를 사용하여 구매입찰/판매입찰 요청에 대한 동시성 제어
◦
master와 slave 동기화
•
RabbitMq를 사용하려고 하는데 rabbitmq보다 러닝커브가 더 낮은 대체제가 있는지 궁금합니다 :: 왜냐하면 환경설정하는 부분이 Erlang으로 되어있고, 자료가 너무 적어서요
(피드백) Message Queue는 Kafka, RabbitMq, AWS SQS 정도가 대세라고 생각되며 러닝커브가 낮은 대체제는 특별히 없음. 기초 수준을 넘어선 내용들은 한글로 누군가 작성한 가이드를 보면서 작업하는게 불가능한 측면이 있습니다. 직접 공식 레퍼런스를 참고하면서 개발에 적용하는 습관을 길러야 함.
[기타]
•
스케일 아웃 자동화는 어떻게 할 것인가
◦
AWS를 사용하여 스케일링을 할지 vs Nginx를 사용하여 스케일링을 할지
(피드백) 질문이 다소 추상적으로 해석됨. 대면 피드백 시 각각의 계획을 들려주세요.
◦
어떤 게 더 이점이 있는지 판단이 안 서요 (쌩으로 EC2부터 구현을 할지, AWS의 서비스들을 적극 이용할지)
(피드백) Elastic Cache에 남긴 코멘트와 동일함.
•
Serial Data를 기존의 MySQL에서 NoSQL로 저장한다면,
(피드백) DB 선택은 용도에 따라 다름. 무슨 데이터를 왜 NoSQL로 저장하려는지 부터 설명 해주세요. 릴레이션에 대한 질문은 NoSQL의 기본 컨셉을 조금 찾아보면 답이 나오는 내용이라 생각하는데, 여러분들의 생각이 어떤지부터 궁금합니다. 난이도는 물론 케바케지만… 못할 건 없다고 생각한다 라고 답변 드리겠습니다.
◦
InfluxDB 사용할지
◦
MoongoDB 사용할지
◦
이렇게 저장하게끔 변경하면 기존 RDB와 릴레이션이 깨지지 않을지
◦
이런 변경 사항이 기한 내에 공부해서 적용 가능한 난이도인지 궁금합니다.
•
main / sub 에 대한 동기화 관리를 하려고 하는데
◦
RabbitMQ를 사용하는 것이 적절한지, 아니면 다른 적정 기술이 있는지, 기한 내에 적용 가능한지 궁금합니다.
(피드백) AWS RDS 설정을 이용하세요. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.ReadReplicas.html
숙제: 멘토링 결과 및 다음 주까지 해올 일
•
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
◦
•
팀원 개인별로 작성해 주세요.
