SA 문서 2차 피드백

팀 피드백

Redis

Redis 키 관리에 대해 나중에 키가 많아지면서 어려움을 겪으므로, 미리 **키 명세서를 정리를 잘했다.
캐시 전용 Redis와 대기열 Redis를 분리하는 것이 효율적이다.
Redis를 고도화하는 방법으로 master-slave sentinel 구성을 고려할 수 있다. 실시간 서비스 장애 대응에 유리하다.

문서 작성 및 관리

현재 작성된 문서는 매우 잘 되어 있으므로, 이를 GitHub Wiki로 옮기면 포트폴리오 확인 시 유용할 것이다.

인프라 설계도

GCP(구글 클라우드)를 고려했으나, 예산이 많이 소요되어 20만 원의 한정된 예산으로는 어렵다. AWS 기준으로도 비용이 빡빡할 것으로 예상된다.
원하는 스펙으로 GPT에게 일주일치 예상 비용을 추정해볼 수 있다.
쿠버네티스
- ArgoCD 없이도 매니페스트 파일의 변경 사항을 감지할 수 있는지 찾아보면 좋겠다.
- 만약 쿠버네티스를 사용하지 않을 경우 Docker 기반으로 EC2 또는 ECS를 사용하는 대안이 있다.
- GitHub와 Ansible을 활용하여 배포 스크립트 및 관리 툴을 자동화하면, 개발자가 코드 푸시 시 시스템이 자동으로 처리할 수 있다.
- 14조에서도 쿠버네티스 사용을 채택했다.

시스템 구조도

정책 정리
특히 대기열과 같은 곳은 정책 정리가 중요하다. 예를 들어 웨이팅 호출을 하고난 후에도 방문하지 않을 경우 삭제기준이 어떻게 되는지?

예약 및 결제 처리
예약 등록 후 5분 내 처리가 이루어지며, 실패 시 롤백하는 방법은 좋게 보인다. 이벤트성 비동기 처리는 괜찮다.
Streams 도 가능하지만, Topic 방식으로도 처리 방식을 분리할 수 있다.

질문 및 기타 사항

로그 전달 방식은 Redis 기반 파일 방식보다 Grafana나 ELK로 전달하는 것이 더 효율적이다.
예약이 이미 등록되었다면 순서 처리에 대해 추가 고민이 필요하지 않다.
대용량 처리를 위해 Kafka를 사용하되, 순서가 중요하다면 RabbitMQ를 사용하는 것이 더 적합하다.

개인 피드백

Q. 비동기 처리를 도메인에 자연스럽게 추가 해볼 수 있는 방안이 있을지?

A. 리마인드 알림을 끌어와서 작업을 해도 될 것같다. 웨이팅은 그래도 예약발송은 카프카보다는 스케쥴러-배치를 쓸것같다.
사실 AI나 알림같은 경우 이번 부트캠프 핵심 기술로서 보면 아쉬운게 맞다. 차라리 억지로 두 도메인에 기술을 엮는 것 보다는 빨리 구현을 끝내고, 리뷰 같은 비동기 처리를 진행하지만 보류 했던 추가 기능을 맡는 것도 방법일 것 같다.