[Chore] WebSocket 운영 안정화 후속 계획

[SungKong00]

상태: 보류 / WebSocket 운영 인프라 후속 작업만 이 이슈에서 추적

앱 재진입 시 REST resource ID 복구는 #40, #79, #86에서 다룹니다.
단일 스케줄러의 100건 초과 재탐색 공정성은 #123에서 다룹니다.

목표

현재 WebSocket 구현을 단일 서버에서 안전하게 유지하고, 이후 ALB·다중 인스턴스 환경으로 확장할 때 필요한 보안·연결·배포·브로커·검증 작업을 한곳에 보관합니다.

추적 원칙

• 지금은 이 통합 이슈만 열어 둡니다.
• 세부 이슈를 닫는 것은 구현 완료가 아니라 추적 위치를 이 이슈로 옮긴다는 뜻입니다.
• 실제 착수 시 한 PR에서 리뷰 가능한 크기로 새 이슈를 발행하고 이 이슈에 연결합니다.
• WebSocket은 상태 변경 명령이 아니라 상태 변경 알림 신호로 사용합니다.
• 최종 상태와 재접속 복구는 REST/DB를 기준으로 합니다.
• DB commit 이후 best-effort로 알림을 시도하며, 알림 실패가 DB transaction을 rollback하지 않게 합니다.
• 공개 서버를 대상으로 공격성 handshake/probing을 하지 않고 로컬·승인된 test 환경에서 검증합니다.
• 같은 target group에 SimpleBroker 노드와 Broker Relay 노드를 섞지 않습니다.

현재까지 확정·완료된 기준

• STOMP inbound 명령을 fail-closed로 제한 — 기존 [Security] STOMP inbound 명령을 fail-closed로 제한 #110, 커밋 0171611
• matching·lesson 이벤트를 화면 상태가 아니라 REST 재조회 신호로 고정 — 기존 [Docs/Test] WebSocket 이벤트 계약과 Android 소비 방식 확정 #111, 커밋 43fb0cf
• 단일 인스턴스 origin·heartbeat·순서·버퍼·관측성 서버 구현 — 기존 [Refactor] 단일 인스턴스 WebSocket 연결 안정화 및 관측성 강화 #112, 커밋 4174428
• 전달 보장은 best-effort로 유지하고 MVP에서 Outbox를 도입하지 않기로 결정 — [ADR] WebSocket 전달 보장 수준과 Outbox 도입 기준 확정 #117, 커밋 8a4ec53
• 실제 Android 연결·heartbeat·재연결 smoke 완료 증거 확인
  • 연결 이슈: TEAM-SSING/SSING-ANDROID [Test] 2노드·draining·broker 장애 WebSocket 시나리오 검증 #116
  • 현재 이슈는 닫혀 있으나 체크리스트와 구현 근거가 없어 완료 여부 재확인 필요

나중에 다시 분리할 작업 묶음

1. 연결 인증 수명과 회원 상태 반영

• access token 만료 시 연결 종료 또는 재인증 정책 확정
• 회원 정지·탈퇴·권한 회수를 열린 연결에 반영
• Android reconnect/backoff와 인증 실패 구분
• 만료·정지·탈퇴별 단위 및 실제 STOMP 연결 테스트
• token, raw header, payload 없는 안전한 로그·metric

2. 매칭 스케줄러 다중 실행 방어

• 단일 인스턴스의 100건 초과 starvation 수정은 #123에서 처리
• DB 기준 lease 또는 distributed lock 적용 필요성 결정
• 두 runner가 같은 요청을 동시에 처리하지 않는 소유권 기준 확정
• stale lease, 일부 실패, retry, 프로세스 재시작 시나리오 검증
• schema 변경 시 migration·rollback 계획과 안전한 summary log 구성

3. ALB/ACM 단일 타깃 배포 기준

• EC2/ASG 또는 ECS 실행 방식 결정
• Android WSS → ALB+ACM → private HTTP Spring 구조와 Caddy 제거/유지 결정
• private target port, security group, DNS, ACM, forwarded headers 구성
• heartbeat보다 긴 ALB idle timeout과 readiness/health 기준
• deregistration delay, draining, hard cutover, rollback runbook
• Broker Relay 전에는 old/new target이 겹치는 rolling·blue/green 금지

4. 외부 STOMP Broker Relay와 다중 노드 user destination

• ActiveMQ/RabbitMQ 등 broker 선택 ADR
• local/test SimpleBroker와 scaled Relay profile/property 분리
• relay host/port/login/passcode/TLS 및 system/client heartbeat 구성
• userDestinationBroadcast, userRegistryBroadcast 구성
• 기존 /user/queue/matching, /user/queue/lesson과 convertAndSendToUser 계약 유지
• user queue cleanup·권한·destination prefix 검증
• broker down/recovery 중 publish failure 격리와 민감정보 비로그
• 같은 target group의 broker mode·endpoint·namespace 혼용 방지

5. 실제 2노드·draining·broker 장애 검증

• app A 연결 ↔ app B 이벤트 발행을 양방향 matching·lesson에서 검증
• 동일 사용자 다중 session과 다른 사용자 destination 격리
• broker 중단 중 DB commit 유지, 복구 후 신규 이벤트 전달
• target draining과 rolling/blue-green 전환 검증
• client heartbeat timeout·재연결·재구독
• 중복·지연·순서 변경 뒤 REST 최종 상태 보정
• [Bug] 매칭 재탐색 스케줄러 100건 초과 starvation 수정 #123 적용 후 두 runner 동시 실행과 재탐색 공정성 회귀 검증
• 연결 수·publish latency·queue pressure 여유 측정
• Docker Compose/Testcontainers 기반 한 명령 재현 harness

착수 조건

• 남은 API 연동과 관련 PR 안정화
• 개발·테스트 seed로 매칭·강습 시나리오 반복 재현 가능
• Android matching·lesson 구독 및 REST 재조회 흐름 smoke 완료
• WebSocket DTO·event factory·after-commit 흐름을 바꾸는 열린 PR 정리
• 실제 다중 인스턴스 배포 일정 확정

실제 착수할 때 이슈를 다시 만드는 기준

1. 위 1~5 작업 묶음 중 실제 배포에 필요한 것만 선택합니다.
2. 한 이슈는 하나의 독립 커밋 또는 한 PR에서 검증 가능한 크기로 만듭니다.
3. 각 새 이슈에 문제, 비범위, 완료 조건, 검증 명령, rollback 기준을 넣습니다.
4. 새 이슈는 이 통합 이슈를 상위 링크로 연결합니다.
5. 권장 순서는 인증 수명 → 스케줄러 → 단일 타깃 ALB → Broker Relay → 2노드 종합 검증입니다.

제외 범위

• [Feat] 취소 강습 재진입 복구 API 보강 #40 취소 강습 재진입 시 resource ID 복구
• [Feat] 소비자 앱 재진입 시 활성 매칭 복구 API 보강 #79 소비자 앱 재진입 시 활성 매칭 resource ID 복구
• [Feat] 강사 매칭 제안 상세 조회 및 수락 후 재접속 복구 보강 #86 강사 매칭 제안 수락 후 재접속 복구
• [Bug] 매칭 재탐색 스케줄러 100건 초과 starvation 수정 #123 단일 인스턴스 스케줄러의 100건 초과 재탐색 공정성
• Android 구현 자체
• Transactional Outbox, exactly-once, offline replay

위 항목은 WebSocket 인프라 안정화와 별도 문제이므로 필요할 때 독립적으로 유지합니다.