항해99 실전 프로젝트 (8일차)

질문 리뷰

• JPA를 사용하는데, 티켓을 보면 연관관계로 키를 받는데, 복합키를 사용해서 써야되는지 아니면 쓰지 않고 사용해도되는지?
  • 쓰지 않았을 때는 티켓을 생성하면, 4개의 조회 쿼리가 발생하게 되는데, 100개의 티켓을 생성하면 400개의 조회쿼리가 발생하게 돼서 코드가 맞는건지?

Facade -> Service -> Repository -> Entity
N+1은 fetch join, entity graph

---

• 저번 기수 분들의 프로젝트를 벤치마킹을 했는데, 테이블의 수가 세 개인 분들이 있습니다. 저희 테이블이 과한건지, 여기서 더 줄일 수 있는 부분이 있는건지 궁금합니다.

프로젝트마다 다르다, 사바사 필요하면 정규화 해야한다.

---

• 양방향을 무조건 안쓰는 게 좋은건지?

양방향 맵핑을 써야하는 순간이 있지만, 습관적으로 사용하는건 안좋음.
도메인에 흐름에 맞춰서 맵핑 관계가 있다.

---

• 엔티티에서 메소드를 만들어서 엔티티에 접근하는게 좋은건지, 다른 방향(setter, builder)등 쓰는게 더 좋은건지 궁금합니다.

팀의 취향, 별도의 팩토리 메소드를 만들어줘도 됨
사용할거면 일관되게 하나만 사용

---

• 티켓 환불에 대해서 상태 값만 업데이트 해주면 되는데, 이전 질문에서 POST로 해야되는 부분, 그리고 PATCH대신 PUT을 사용해야하는지?

PATCH, PUT을 사용하는게 맞다.

---

• 스프링 시큐리티에서 서비스단에서 로그인 할 때 JWT를 넣는데, 시큐리티에서 로그인을 하는게 맞는건가요 ?

UserService에 UserDetailService를 implements를 해서 사용해도 됨
따로 클래스 만들어서 사용해도 됨
규모가 터지면 보통 나눈다고 함

---

• postgreSQL은 update에 대해서 mvcc를 이용해 버전관리를 하기 때문에 불리한데, 티켓팅 서비스를 하게 된다면 짧은 시간 내에 많은 update가 이루어지는데 이를 방지하기 위해 redis 같은 cache를 이용해 티켓 재고를 빠르게 처리하고 관리하면서 update를 나중에 이루어지게 하는게 맞는 방향인가요?

이렇게 진행해도 된다. 성능을 챙겨간다.

1. RDBMS 사용
2. 인메모리 스토리지 + RDBMS 사용
3. 캐시 + RDBMS
   조합의 성능을 비교하는걸 추천

---

• 실무에서 서버 재해 복구 전략을 실제로 사용을 하나요?

항상 사용하고, 많이 도입이 되어있다.
임의로 장애를 일어내고 복구하는 훈련을 함

---

• 실무에서 삭제 했을 때 응답코드는 주로 200, 204중 어떤 것을 응답하나요?

실무에서 200을 사용
성공에 대한 결과는 어지간하면 200

---

• 실무에서 ElasticSearch, OpenSearch 중 어떤 것을 사용하나요?

두개 다 사용함, 멘토님은 ElasticSearch를 사용
2개 중 뭐가 더 좋은지 자료로 정리를 해서 기술 선택

---

• 패키지 별로 버전 관리를 할 때 컨트롤러, 서비스 두 개다 v1, v2 패키지를 만들어주나요? 아니면 컨트롤러만 v1 패키지를 작성하고 서비스는 하나로 운영하나요?

컨트롤러, 서비스 v1, v2 나눠주는게 좋음
서비스 코드 복붙 수준이면 서비스까지는 공유해도 된다.
기능이 완전히 다르다, 서비스도 나눠주는게 맞음

---

프로젝트 강점 리뷰

Redis

• Redis는 인메모리여도 날아갈수있겠지만 RDB, AOF로 띄울 때 다시 데이터가 다시 올라간다.
• 그래서 휘발성이랑은 안맞는다.
• 이유도 모르고 휘발성이랑 단어를 쓰면 먹이감이 되기 쉽다.

Kafka

• 자바로 작성되어있다.
• 내부적으로 되어있는 기능들, 유지보수들의 기능들이 매우 많아
• 일단 현재는 개념적으로 알고 있는게 좋다.

이력서

• AWS에서 사용하는 클라우드 서비스는 사용했다고만으로 이력서에 작성해도 의미가 없다.
• 그걸 가지고 기능을 구현을 해봤다, 트러블 슈팅에서 구현해봤다로 해야지 의미가 있음
• 자신 있는 것만 이력서에 작성을 해야지 된다.

MVP

• MVP 스코프 범위에 필요한 기술셋이 중요, 불필요한 기술셋의 보여주기식은 안좋다.

문서를 참고 할 때

• 공식 사이트를 믿어야지, 그 외 사람들은 비판적으로 바라 볼 필요가 있다.
• 공식 문서만 책임지는 말만 한다.

대용량 트래픽

• 대용량 트랜잭션이 중요, RDBMS로 하는게 좋을 것 같다.

ETag

• 백엔드 어플에서 도입하는거 보단, 읽기의 작업이 많을 땐 Redis에서 백엔드 캐시를 따로 쓰는게 맞는듯

ECS + Fargate는 서버리스가 아니다.

• 완전 서버리스가 아니다.
• 서버리스는 기본적으로 람다 함수, 특정 트리거가 되면 서버가 생겼다가 사라지는 것
• 일단 서버가 있는 구조다.