[Test] GCP 2백엔드 WebSocket 접속 분산·공용 Redis 검증

[Gimini-3]

목적

머지된 #377의 수신자별 인가 개선과 #379의 단일 백엔드 GCP 측정을, 두 백엔드와 공용 Redis 및 내부 로드밸런서 경로로 확장한다. 접속 분산, 교차 노드 권한 회수, 메시지 전달을 서로 다른 결과로 판정한다.

시험 범위

• 동일 커밋·JVM·환경 설정의 백엔드 A/B와 시험 전용 공용 Redis를 GCP 내부망에서 실행한다.
• A/B 직접 접속을 먼저 검증하고, 그다음 내부 로드밸런서를 통해 신규 WebSocket 연결이 양쪽에 도달하는지 확인한다.
• A/B 각각의 구독 수를 독립적으로 수집하고, 두 백엔드에서 발행 중 실제 ADMIN 회수 후 새 인가 판정을 확인한다.
• A만 발행할 때 B 구독자의 수신 결과를 별도로 측정해 SimpleBroker·로컬 갱신 신호의 경계를 기록한다.
• 별도 회차에서 A 앱 프로세스 중단 후 기존 소켓 단절과 B로의 새 연결·재접속을 구분한다.

완료 기준

• 실행별 run ID, KST 시각, 대상 커밋, 설정의 비밀 제외 요약, k6 수치, A/B 세션 수, 오류와 정리 결과를 분리 보존한다.
• 안정된 연결 50개 기준 A/B가 모두 실제 연결을 받고 총합이 k6 연결 수와 일치하는지 검증한다. 정확한 50:50은 요구하지 않는다.
• 회수 HTTP 200 이후 시작한 새 대시보드 권한 판정에서 잘못 허용된 전송 0건을 양쪽에서 확인하고, 이전에 이미 허용된 전송의 늦은 수신은 별도 집계한다.
• 교차 노드 메시지 미전달이 관측되면 결과를 숨기지 않고 별도 Fix 범위로 기록한다.
• 시험 계정·토큰·임시 암호를 정리하고 공개 결과에서 계정·주소·프로젝트 ID·비밀을 기록 전에 제외한다.

범위 밖

Redis HA, OpenProxy 또는 primary 장애, 다중 백엔드 RAG 개인 알림 보장, 브라우저 SockJS fallback의 운영 호환성은 이 시험만으로 주장하지 않는다. 운영 코드 수정은 관측 결과에 따라 별도 이슈/PR로 진행한다.