본문으로 건너뛰기

클라우드 아키텍처 (CA)

갱신: 2026-10-07

이 문서는 2026-09-29 시점의 구성 기록이다. 지금 구성은 클라우드 아키텍처 본문에 있다.

화면과 애플리케이션의 책임은 각각 정보 아키텍처와 애플리케이션 아키텍처에 있다. 여기서는 서비스가 어느 네트워크 경계에 놓이고 외부와 어떤 길로 통신하는지만 다룬다.

전체 구성​

요청 상한 — server 앞 Service Connect​

server 태스크로 들어오는 요청은 ALB → Service Connect Envoy(ingress) → 앱 순서로 지난다. 응답 헤더 server: envoy 가 그 흔적이다. ALB 에서 오는 요청도 이 Envoy 를 지나므로, Service Connect 의 요청당 상한이 브라우저 요청에도 걸린다.

설정값이유
heymoa-server 서비스 serviceConnectConfiguration.services[portName=http].timeout.perRequestTimeoutSeconds1800채팅 SSE emitter 의 절대 상한 SSE_TIMEOUT_MS(30분)에 맞춘다. 0(무제한)은 쓰지 않는다
같은 자리 idleTimeoutSeconds기본 300SSE·STOMP 하트비트가 10초라 걸리지 않는다
heymoa-ai 서비스 Service Connect 상한기본(요청 15초)server → ai 는 202 만 보는 짧은 호출이다

이 값은 콘솔·CLI(aws ecs update-service --service-connect-configuration)로만 있고 인프라 정의 파일이 없다. 바꿀 때 namespace·logConfiguration 을 함께 넣어야 하고, 바꾸면 새 배포가 일어난다.

1800 으로 올린 까닭. 기본값은 요청 15초다. 이 상한은 응답이 끝날 때까지의 절대 시각이라 프레임이 흐르고 있어도 끊는다. 2026-09-29 운영 chatloop 에서 긴 채팅 턴의 SSE 가 스트림을 연 지 16.0116.04초에 ERR_HTTP2_PROTOCOL_ERROR 로 끊기고 다시 붙었다(81턴 중 13턴). Envoy 가 15초에 앱 쪽 연결을 끊고, 약 1초 뒤 ALB 가 브라우저 쪽 HTTP/2 스트림을 0x2 로 리셋한 것이다. ALB 로그의 /events 가운데 15.9초를 넘긴 22건이 전부 16.0초 0x2 였고, 09-2729 HTTP 약 11만 건 중 16.1초를 넘긴 응답은 0건이었다. 조사는 APP-754에 있다.

곁효과. 상한은 서비스 전체에 걸린다. 15초에 504 로 끊던 느린 일반 API(09-28 target_processing_time 15.00초 안팎의 504 22건)가 이제 앱 자체 타임아웃이나 ALB idle_timeout(120초)까지 기다린다. 끊는 자리가 Envoy 에서 앱 쪽 판단으로 옮겨 갔다.

검증 (2026-09-29). 적용 뒤 19:00~19:08 운영 chatloop 40턴에서 16초를 넘긴 6턴(최대 20.5초)이 전부 재연결 없이(sse=1) 끝났고, 같은 창에 server 로그 Broken pipe 는 0건이었다.