실시간 채팅 이미지 전송 플로우

개발에 앞서 설계한 실시간 채팅 이미지 전송 흐름을 정리해봤다. 기존에 람다와 SQS를 사용한 프로필 이미지의 비동기 리사이징 로직을 최대한 활용할 수 있는 방향으로 고민해봤다.

이미지 채팅 플로우

Details

1. [Client → Server] Presigned URL 요청

2. [Server] S3 키(Key) 생성 및 티켓 발행

• 서버는 UUID를 이용해 고유한 Key(BaseName)을 만들고, S3에 저장될 경로(Key)를 결정한 뒤 업로드용 Presigned URL을 반환

3. [Client → S3] 이미지 업로드 (Binary 전송)

• 클라이언트는 서버가 준 URL을 통해 이미지를 S3에 직접 업로드. 이때 낙관적 UI를 적용해 사용자 화면에는 이미 전송 중인 것처럼 표시

4. [S3 → Lambda] 트리거 발동 (자동)

• S3에 파일이 들어오는 순간, 이벤트 트리거에 의해 람다가 실행

5. [Lambda → S3 / SQS] 이미지 리사이징 및 알림

• 람다는 원본을 읽어 썸네일을 생성해 S3에 다시 저장하고, 처리가 끝났다는 정보를 SQS 큐로 전송

6. [Client → Server] 채팅 이미지 전송 (/chat)

• S3 업로드를 마친 클라이언트는 웹소켓 채팅 메시지로 Key를 전송

7. [Server → S3] 객체 존재 여부 확인 (HEAD)

• 서버는 클라이언트가 보낸 Key에 해당하는 파일이 S3에 실제로 존재하는지 HeadObject로 검증합니다.

8. [Server → DB] 원본 데이터 저장 및 상태 확정

• 검증이 끝나면 DB(Image 테이블)에 원본 이미지 정보를 저장

9. [Server SQS Listener] 리사이징 완료 메시지 수신 (별도 쓰레드)

• 람다가 보낸 SQS 메시지가 도착하면 리스너가 동작
• 분기점 발생: 리스너가 DB에서 해당 Key(baseName)의 원본이 있는지 탐색
  • Case A (원본 있음): 서버가 8번 과정을 이미 마친 상태. 리스너는 즉시 Image 테이블의 해당 레코드에 썸네일/AVIF 경로를 업데이트(Upsert)
  • Case B (원본 없음): 서버 API가 아직 처리 중이거나 지연된 상태. 리스너는 리사이징 정보를 ImageSession 테이블에 임시 저장. ImageSession 들은 서버가 주기적으로 배치처리(ImageSession→ Image).

10. [Server → Message Broker] 조회용 URL 생성 및 브로드캐스트

• 서버는 DB에 저장된 Key를 바탕으로, 채팅방 참여자들이 즉시 볼 수 있는 조회용 URL을 생성하여 메시지 브로커(SimpleMessageBroker)에 전달.
  • URL을 바로 보내지 않고 Key로 조회용 URL을 만들어서 보내는 이유
    • 누구나 조회할 수 있는 프로필 이미지와 달리 상담 내용 중 이미지는 private bucket에 관리해야하기 때문에 일정 기간만 조회 권한이 있는 URL을 사용.

11. [Message Broker → All Clients] 실시간 렌더링

• 상대방(Client B)을 포함한 채팅방 내의 모든 사용자는 브로커로부터 메시지를 수신하고, 포함된 URL을 통해 이미지를 화면에 렌더링.