README.md

README

🍖 와구 북

---

흔한 맛집 리뷰는 가라! 새로운 맛집 기록, 공유, 참여

친구와 약속을 잡을 때, “여기 어때?” 라고 물어보고 한참 뒤에 답변을 받은 경험이 있으신가요?🥹

내가 가본 맛집들을 간편하게 기록할 수 있는 서비스가 필요하지 않으신가요?🤓

WAGU BOOK은 이런 분들을 위해 기록 공유 참여에 초점을 둔 맛집 서비스입니다!

편하게 작성하고 빠르게 소통하세요!!

나만의 포스팅을 작성해보세요! 🤌

🔗 와구 북 서비스 및 노션

---

🍷 와구북 바로가기

🍷 팀 노션

📢 주요 서비스 기능

---

🍷 포스트 자동 생성 기능

“사진으로 간단하게 기록을 완성하세요!”

• 포스트를 작성할 때, [이미지, 음식점, 메뉴] 정보를 입력해서 AI를 통해 리뷰를 자동으로 작성할 수 있습니다
• AI리뷰를 사용하지 않거나, 수정할 수도 있습니다

🍷 친구들과 함께 맛집 찾기

“음성채팅과 친구들이 보고있는 장소를 확인하며 친구들과 소통하며 맛집을 골라보세요!”

• 생성된 링크에서 친구들과 실시간으로 지도를 보며 식당을 탐색할 수 있습니다
• 몇몇 식당을 선택하고 투표를 통해 가고싶은 맛집을 선택해보세요
• 지도에서는 친구들이 실시간으로 보고있는 위치를 확인할 수 있습니다
• 음성채팅으로 대화하며 의견을 공유해 보세요

🍷 라이브 스트리밍

“실시간으로 음식의 감동을 공유하세요!!”

• 라이브 스트리밍을 통해 자신의 먹방을 자랑할 수 있습니다
• 스트리밍에 참여하는 채팅을 통해 상호작용하며 맛집 탐색에 도움을 받아보세요

⚙️ 서비스 아키텍쳐

---

📌 핵심 기술

---

• 실시간 통신 기술
  • 음성 및 스트리밍 서비스를 위한 SFU 방식 WebRTC 서버 구현
  • 미디어 서버 Openvidu 사용
  • 채팅, 좌표 데이터 전달을 위한 WebSocket 서버 구현
• 이미지 업로드 시 효율적인 공간 사용 및 로딩 최적화를 위해 Graphics2D를 사용한 이미지 리사이징
• 동시성 문제(Race Condition) 해결을 위해 Redis를 사용한 분산 Spin-Lock 구현
• 유지할 필요가 없는 공유, 투표 데이터 Redis 사용한 일시 저장
• Github Actions/AWS ALB/Docker를 통한 blue-green 배포방식의 CI/CD 무중단 배포 구현
• 미디어 전송 서버와 데이터 전송 서버를 구분하여 확장성 증가

📝 기술적 의사 결정

---

기술적 의사 결정 요약

기술	도입 이유	후보군	의견 조율 및 기술 결정
Web Socket	채팅, 데이터 전송	Polling / Long Polling / Web Socket	WebSocket 사용 결정
WebRTC (SFU)	실시간 스트리밍 및 음성	HLS / Mesh / SFU / MCU	WebRTC (SFU) 사용 결정
Redis (Lettuce)	TTL이 필요한 데이터를 저장하기 위한 DB 선정	Lettuce / Redisson	Lettuce 사용 결정
Github Action & DockerHub / AWS CodeDeploy	지속적 통합과 지속적 배포를 통한 업무 효율 상승	Jenkins / Github Action / Travis CI	Github Action과 AWS CodeDeploy 사용 결정

---

세부 내용

• WebRTC (SFU)

  • HLS와 같은 선택지가 있었지만, WebRTC를 사용하게 된 이유는 기본적으로 낮은 지연 시간(Low Latency) 때문입니다.
  • HLS는 기본적으로 HTTP 기반의 프로토콜이기 때문에 초 단위의 지연이 발생할 수 있지만, WebRTC는 P2P 연결을 기반으로 하여 매우 낮은 지연 시간을 제공합니다.
  • WebRTC는 단순한 영상 전송뿐만 아니라 오디오와 데이터를 포함한 양방향 통신을 지원합니다.
  • 짧은 기간 내에 WebRTC를 직접 구현하는 것은 어렵다고 판단하였으며, OpenVidu를 Spring Boot에 이식하여 구현하기로 결정했습니다.
  • 클라이언트 측에서 세션을 생성하는 요청이 들어오면, Spring의 컨트롤러가 해당 요청을 받아 OpenVidu로 전달하고, OpenVidu가 세션을 관리하는 방식으로 구현합니다.

• Redis (Lettuce)

  • TTL이 필요한 데이터를 저장하는 DB로 Lettuce를 선정했습니다.
  • 투표 기능에서, 투표가 종료되면 데이터를 DB에 계속 저장하는 것은 낭비라고 판단했습니다.
  • 투표하기 기능에서 여러 사용자가 동시에 같은 가게에 투표할 경우, 투표 결과가 1번만 반영되는 문제를 해결하기 위해 락이 필요했습니다.
  • Lettuce는 Redisson보다 가벼우며, 단순한 락 기능을 위해 추가적인 종속성과 복잡성을 도입하는 것보다 효율적입니다.
  • Lettuce를 사용하여 Spinlock을 직접 구현함으로써, 락 획득과 해제를 직접 관리하여 성능 최적화를 달성할 수 있습니다.
  • Spinlock은 자원을 기다릴 때 CPU를 사용하여 반복적으로 시도하는 방식이며, 락의 타임아웃, 재시도 횟수, 대기 시간을 조정할 수 있어 특정 상황에 맞춘 최적화가 가능합니다.

• Github Action & DockerHub / AWS CodeDeploy

  • 지속적 통합과 지속적 배포를 위해 Github Action과 AWS CodeDeploy를 사용하기로 결정했습니다.
  • 현재 프로젝트 관리는 GitHub를 통해 진행 중이며, 소규모 프로젝트이고 추가 설치 과정 없이 GitHub에서 제공하는 환경에서 CI 작업이 가능하기 때문에 Github Action을 사용하는 것이 적합하다고 판단했습니다.
  • 프로젝트 규모를 고려하여 초기 설정이 적고 편의성이 높아 리소스를 줄이는 방향으로 진행했으며, 자동화 배포를 위해 Github Action과 AWS CodeDeploy를 사용하기로 결정했습니다.

⚽ 트러블 슈팅

---

• Blue-Green배포 시 세션 로그인 문제
  • 문제 상황
    • 두 개의 서버가 띄워져 있을 때 로드밸런서를 통해 Round Robin 방식으로 트래픽이 분산되는 경우 세션 로그인이 유지되지 못하는 문제가 발생했습니다.
  • 이유
    • 기본적으로 AWS ALB의 경우 Round Robin 방식으로 트래픽을 분산시키기 때문에 세션로그인을 통해 로그인 하고 쿠키에 박혀있는 세션은 첫 번째 서버에서 인증받은 세션입니다. 빌드가 완료된 다음 서버에 연결할 때는 다른 서버로 연결이 되기 때문에 인증에 실패하게 됩니다.
  • 해결 방법
    • AWS 로드밸런서의 트래픽 분산 방식을 Sticky 방식으로 변경했습니다. Sticky 방식은 이전에 서버에 접근한 기록이 있는 경우에는 동일한 서버로 트래픽을 분산하는 방식입니다.

🗨️ 유저 피드백

• 유저 피드백

⌛ 시간이 더 있었다면 도전했을 기술들

• 대용량 트래픽 처리(Docker를 사용한 scale-out)
• Graphics2D를 사용하지 않고 픽셀 보간법을 사용해서 이미지 리사이징과 복원
• 소셜 로그인(카카오, 네이버, 구글)

🛠 기술 스택

Backend Tech Stack

Infrastructure

Team Collaboration Tool

🧑🏻‍💻 개발 기간 & 조원

✔️ 2024.5.30 - 2024.07.27