클라우드 아키텍처 (CA)
갱신: 2026-10-07
화면과 애플리케이션의 책임은 각각 정보 아키텍처와 애플리케이션 아키텍처에 있다. 여기서는 서비스가 어느 네트워크 경계에 놓이고 외부와 어떤 길로 통신하는지만 다룬다.
전체 구성
2026-10-07 판은 2026-09-29 판과 견주어 브라우저·SQS 노드가 생기고 Cloudflare·GitHub Actions 노드가 빠졌으며, 서비스 이름에 버전(RDS PostgreSQL 18.4, Valkey 9.1)이 붙지 않는다. 이 그림은 그림 원본에서 가져왔고 AWS 콘솔로 다시 대조하지 않았다 — 미확인.
요청 상한 — server 앞 Service Connect
server 태스크로 들어오는 요청은 ALB → Service Connect Envoy(ingress) → 앱 순서로 지난다. 응답 헤더 server: envoy 가 그 흔적이다. ALB 에서 오는 요청도 이 Envoy 를 지나므로, Service Connect 의 요청당 상한이 브라우저 요청에도 걸린다.
| 설정 | 값 | 이유 |
|---|---|---|
heymoa-server 서비스 serviceConnectConfiguration.services[portName=http].timeout.perRequestTimeoutSeconds | 1800 | 채팅 SSE emitter 의 절대 상한 SSE_TIMEOUT_MS(30분)에 맞춘다. 0(무제한)은 쓰지 않는다 |
같은 자리 idleTimeoutSeconds | 기본 300 | SSE·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초에 29 HTTP 약 11만 건 중 16.1초를 넘긴 응답은 0건이었다. 조사는 APP-754에 있다.ERR_HTTP2_PROTOCOL_ERROR 로 끊기고 다시 붙었다(81턴 중 13턴). Envoy 가 15초에 앱 쪽 연결을 끊고, 약 1초 뒤 ALB 가 브라우저 쪽 HTTP/2 스트림을 0x2 로 리셋한 것이다. ALB 로그의 /events 가운데 15.9초를 넘긴 22건이 전부 16.0초 0x2 였고, 09-27
곁효과. 상한은 서비스 전체에 걸린다. 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건이었다.