Project_blue(중간발표 회고록)

예시

<aside> 💡 여러분의 중간점검을 돕고, 추후 더 빠른 이력서 작성을 위해 회고록 양식을 공유 드립니다. 작성하신 회고록을 기반으로 다음주 튜터님 미팅이 이루어질 예정이니, 새롭게 추가/개선할 기능이나 수정 방향성에 대해서 깊은 고민을 할 수 있는 기회가 되길 바랍니다 😊

</aside>

중간발표까지의 후기 및 소감

<aside> 📢 대면 피드백 미팅 전

</aside>

1. 중간발표 자료(기입)

발표자료

https://docs.google.com/presentation/d/1oTF84r-7nApZAky3BNsX1PabJ49v9JzUDJhXxw8QRFY/edit#slide=id.p2

https://github.com/everydayspring/project-blue
프로젝트 정보
- 서비스명 : TICKET🎫SPRING
- 서비스 기획 의도 : 사용자가 공연, 전시회, 콘서트 등 다양한 문화의 티켓을 쉽게 예매하고 관리할 수 있는 온라인 플랫폼을 제공하기 위해 기획되었습니다.
- 프로젝트 한 줄 설명 : 공연 등 다양한 문화 및 엔터테이먼트 이벤트의 티켓을 온라인으로 예매할 수 있는 서비스
- 최종 MVP 스펙 :
  - Front-End: HTML(결제파트 프론트)
  - Back-End: Spring boot
  - Database: Mysql
  - Deploy: Gibhub, AWS EC2
- 팀 노션 URL : TICKET_Blue
- (선택)서비스 배포 URL : http://3.36.38.240:9090/api-test

2. 기술적 의사결정 & 트러블슈팅 기록

기술적 의사결정

요구 사항	기술	선택한 이유
언어	Java	-Java는 컴파일 타임 타입체크와 메모리 관리 기능을 통해 안정적이고 빠른 성능을 보장함

Spring과 같은 풍부한 프레임워크와 라이브러리를 통해 다양한 기능을 쉽게 구현할 수 있음
객체 지향적 구조 덕분에 대규모 개발과 유지보수에 유리함. | | 데이터베이스 | MySQL | - 관계형 데이터베이스를 사용해서 공연, 사용자, 예매 등 복잡한 관계를 관리할 수 있음
ACID 트랜잭션을 지원하기 때문에 예매 과정에서 발생할 수 있는 오류나 충동을 방지할 수 있음 | | CI/CD | Jenkins | | | 동시성 제어 | Redis 분산 락 | 예매나 쿠폰 발급시 한번에 많은 요청이 들어올 수 있기 때문에 동시성 제어를 사용 → -특정 작업이 여러 서버에서 동시에 실행되지 않도록 제어하여 중복 방지 -특정 자원을 다수의 인스턴스가 동시에 변경하지 않도록 막아 데이터 일관성을 유지 -한 번에 하나의 프로세스만 리소스에 접근할 수 있도록 보장해 데이터 충돌을 방지 -TTL(Time-to-Live)을 설정해 락이 영구적으로 유지되지 않도록 해 데드락 상황을 방지 | | 공연 검색 | 선택한 기술
ElasticSearch

선택지

AWS Opensearch | - 공연, 영화, 콘서트 등의 정보를 기반으로 빠른 검색 환경이 필요했음
ES는 대용량 데이터여도 빠른 텍스트 검색을 제공해줌
단순 키워드 검색 외에도 정렬, 필터링, 범위 검색 등이 가능 (실제로 bookingdate 같은 범위검색기능을 사용함)
제공하는 데이터가 많아질 수록 효과적으로 관리할 수 있다고 판단함 | | | | | | | | | | | | |
트러블 슈팅
- 레디스에서 데이터를 캐싱 시 Java LocalTime을 읽지 못하는 오류
- 레디스에서 객체를 저장 시 객체의 생성자를 읽을 수 없다는 오류
- Jenkins 서버에서 git repository clone 후 application build 과정에서 리소스 부족으로 인한 무한로딩, EC2 접근불가능
- Build Docker 단계에서 Docker 명령어를 찾지 못하는 ‘Docker not found’ 문제
- 쿠폰 락 적용 이슈
- 날짜 데이터 조회 시, 강제정렬되어 표시되는 문제
- 잘못된 캐싱 처리로 인한 데이터 미변경 이슈
- Elastic Search, Dto 통합이슈
- Elastic Search, 의존성 이슈

[튜터님들 피드백]

김재환 튜터님
ip 개인정보 노출 되어있는 부분 개선 필요캐싱 : Postman으로 어떻게 감축됐는지 잘 나왔는데, 기타 자료에 수치 자료가 많지 않아 아쉬웠음Jira, GitHub 연결한 형상관리 부분 좋음엘라스틱 서치에서 스케쥴러 : 여러 서버로 했을 때 데이터에 대한 동기화 처리가 제대로 안될 수 있는 점 인지 필요
김동현 튜터님
아키텍쳐 : 로그 수집기가 없음메일 발송 : 동기처리 되어있을텐데, 메일 발송은 작업 외에 추가 부수적인 작업물임. 트랜잭션이 걸려있을 것이라서 메인 로직과 메일 발송은 따로 관리해야 함(참고 : 트랜잭션 이벤트 리스너 -> 커밋 에프터 옵션 등)> 메일 발송은 동기처리 되어 있으면 안됨!
신민아 튜터님
jira 도입한 점이 인상적 -> 최종프로젝트에서 그래프 관련하여 보여주거나, 리드미에 추가하면 좋을 듯 함'성능 향상 목적으로 DB 마스터/슬레이브 구조로 나눴다'> 수치화된 자료 추가 필요 (쿼리 프로파일링 등)엘라스틱 서치 부분 : 셋 다 Lucene 기반임검색 관련 질문 : 일부 데이터가 소실될 수 있음 -> 대비책이 있는지?> 힌트 : 색인 했을 때 bulk index request 하는지? 단건으로 하는지?> created at 쓰는 곳에 마지막으로 색인했던 데이터 Entity의 created at을 활용하는 방법이 있다!