• HLS : 미디어 스트리밍에 있어서 점유율이 가장 높습니다.
  But, latency가 3초로 실시간 전송이 필요한 우리 서비스에는 미흡하다고 판단했습니다.
• Twillio : 웹상 통화 API로 간단한 사용 방법과 실시간 전송, 일반 스마트폰과 웹 사용자와의 통화를 지원했습니다.
  But, 사용자마다 임시 번호를 구입해야하거나 미리 대량의 번호를 사 두고 돌아가며 지급해야하는 운영의 복잡성이 올라갑니다.
  
• WebRTC : latency가 매우 낮고 실시간 전송을 보장하며 데이터 전송에서 서버를 거치지 않아 네트워크 사용량이 적습니다.
  But, 학습곡선이 높을 수 있고 NAT 환경에서의 연결을 위해 TURN 서버 구축이 필수이며 서버 비용이 높을 수 있습니다.
  

-> 서비스의 기술 요구사항에 따라 WebRTC 가 가장 적합하여 채택했습니다.

• MCU : 중앙에 미디어 서버를 두고 통신하는 방식으로 미디어 서버 구현 난이도와 클라우드 비용 문제가 상충하여 채택하지 않았습니다.
• Mesh : 클라이언트 간 미디어를 직접 전송하는 방식으로 1대1일때 품질이 우수하고 대기시간이 짧아 채택했습니다.
• SFU : 대규모 다자간 통신으로 확장성이 있고, SFU 역시 미디어 서버를 사용하지만
  MCU와 달리 서버에서 인코딩/디코딩을 하지 않아 추후 지속적인 서비스를 위해 고려하고 있습니다.

-> 1대1 통화를 우선으로 하니 Mesh로 구성했습니다.

• Google STT : 실시간 스트리밍을 제공하고 다양한 언어를 지원하지만 화자 분리 기능이 존재하지 않았습니다.
• OpenAI Whisper : 무료지만 실시간 스트리밍을 제공하지 않아 Batch 처리를 해야 하므로 지연도가 높아집니다.
• Amazon Transcribe : 실시간 스트리밍을 제공하고 추후 다자간 통신을 위한 화자 분리가 가능합니다.
  공식 문서가 잘 되어 있었고, 이미 사용하고 있는 Amazon의 다른 서비스와 함께 관리 및 운영이 수월했습니다.

-> Speech-to-Text 기술은 Amazon Transcribe를 활용했습니다.

• Terraform: AWS 인프라 구성 (VPC, EKS, RDS)
• Ansible: Kubernetes 클러스터, ArgoCD 설치
• Kubespray: K8s 클러스터 자동 설치

• 매니페스트 관리: K8s 리소스 정의 매니페스트 관리
• 자동 배포: ArgoCD를 통한 자동 배포
• 설정 관리: 마이크로서비스 및 인프라 설정 포함

1. CD Repository로 인프라 구성 및 ArgoCD 설치
2. ArgoCD가 Manifests Repository와 연동되어 전체 시스템 자동 구성
3. 이후 모든 변경사항은 Git을 통해 자동 배포

앵무말ERD

• 역할: 사용자 정보를 저장합니다.
• 주요 필드:
  • user_id: 사용자 고유 식별자 (Primary Key)
  • nickname: 사용자의 닉네임
  • email: 사용자 이메일
  • provider: 소셜 로그인 방식 (e.g., KAKAO, GOOGLE)
  • profile_image: 사용자 프로필 이미지
  • created_at, updated_at: 데이터 생성 및 수정 시간

• 역할: 대화 관련 정보를 저장합니다.
• 주요 필드:
  • talk_id: 대화 고유 식별자 (Primary Key)
  • status: 대화 상태 (ACTIVE, INACTIVE, CLOSED)
  • created_at: 대화 생성 시간
  • closed_at: 대화 종료 시간
  • room_name: 대화방 이름
  • sender_id: 발신자 ID
  • receiver_id: 수신자 ID

• 역할: 대화 방에서 생성된 투두(To-Do) 항목을 저장합니다.
• 주요 필드:
  • todo_id: 투두 고유 식별자 (Primary Key)
  • title: 투두 제목

• 역할: 마이페이지에서 유저별 투두(To-Do)를 관리하며, 사용자, 대화, 투두 간의 관계를 연결합니다.
• 주요 필드:
  • user_id: 사용자 ID (Foreign Key)
  • todo_id: 투두 ID (Foreign Key)
  • talk_id: 대화 ID (Foreign Key)
  • todo_status: 투두의 상태를 나타내는 필드
• 관계:
  • Users, Todos, Talks 테이블과 모두 연관. RoomUser_Detail은 다대다 관계를 구현하는 연결 테이블 역할을 합니다.

• Users ↔ RoomUser_Detail: 사용자와 마이페이지 상세 정보는 1:N 관계입니다.
• Talks ↔ RoomUser_Detail: 대화와 마이페이지 상세 정보는 1:N 관계입니다.
• Todos ↔ RoomUser_Detail: 투두와 마이페이지 상세 정보는 1:N 관계입니다.

RoomUser_Detail 테이블의 데이터 증가 문제
RoomUser_Detail 테이블은 대화가 시작될 때 유저 수(2명)와 투두의 갯수만큼 데이터가 생성됩니다.
예를 들어, 대화 하나에 두 명의 유저와 10개의 투두 항목이 있다면, 이 대화로 인해 RoomUser_Detail 테이블에는 2 x 10 = 20개의 데이터가 추가됩니다.
여러 대화와 투두가 반복적으로 추가되면 데이터가 기하급수적으로 증가하여 성능 및 저장 공간에 문제가 발생할 수 있습니다.

최적화 전략 구상

• 인덱싱 추가 → 빠른 쿼리 개선.
• 캐싱 도입 → 자주 조회되는 데이터를 캐시에 저장.
• 데이터 수명 관리 → 오래된 데이터를 주기적으로 삭제.
• 비즈니스 로직 개선 → 중복 데이터 최소화.

성능 개선 & 리팩토링 내용입니다.

테스트 & 모니터링 내용입니다.