05 / 09
성능 관련 요소
Edge 캐싱 응답 개선, Cloud Map 내부 통신 최적화, ElastiCache 캐시 계층, Health Check 안정성
성능 최적화 설계 방향
통합 포탈 서비스는 사용자 체감 성능과 내부 처리 효율을 동시에 개선하는 방향으로 설계되었습니다. Edge 캐싱, 내부 통신 최적화, 캐시 계층 도입, 안정성 개선을 통해 성능을 체계적으로 개선하였습니다.
CloudFront 기반 응답 성능 개선
CloudFront를 통해 정적 리소스를 엣지에서 캐싱하고, 사용자와 가까운 위치에서 응답을 제공합니다. TLS 종료를 CloudFront에서 처리함으로써 사용자 체감 응답 속도를 개선하였습니다. 특히 해외 사용자 접근 시에도 latency를 줄일 수 있는 구조를 확보하였습니다.
엣지 캐싱
정적 리소스를 전 세계 엣지 로케이션에서 제공
Latency 감소
TLS 종료
CloudFront에서 TLS 핸드셰이크 처리로 백엔드 부하 감소
TTFB 개선
압축 전송
Gzip/Brotli 압축으로 전송 데이터 크기 감소
전송 속도 향상
| 요청 유형 | CloudFront 미적용 | CloudFront 적용 | 개선 포인트 |
|---|---|---|---|
| 정적 리소스 (JS/CSS/이미지) | Origin 서버까지 왕복 | 엣지에서 즉시 응답 | 응답 시간 대폭 감소 |
| API 요청 | 직접 ALB 접근 | CloudFront 경유 (TLS 최적화) | TTFB 개선 |
| 해외 사용자 | 리전까지 직접 접근 | 가까운 엣지에서 응답 | 글로벌 latency 감소 |
내부 통신 최적화 — Cloud Map
기존에는 서비스 간 호출이 외부 엔드포인트 또는 ALB를 경유했을 가능성이 있었으나, 이를 Cloud Map 기반으로 전환하여 내부 통신 latency를 줄이고 서비스 간 호출 효율을 개선하였습니다.
기존 방식 (ALB 경유)
• ALB를 경유하여 네트워크 홉 증가
• 외부 엔드포인트 의존
• 불필요한 로드밸런싱 오버헤드
개선 방식 (Cloud Map)
• DNS 기반 직접 호출
• ALB 경유 제거
• 네트워크 홉 감소
캐시 계층 도입 — ElastiCache (Valkey)
도입 배경
인증 서비스에서 권한을 업데이트하면 각 마이크로서비스에 전파하는 구조였습니다. 그런데 서비스가 Scale-out되어 여러 ECS Task가 실행 중일 때, ALB가 요청을 분산하면서 특정 Task에만 권한 변경이 반영되고 나머지 Task는 이전 상태를 유지하는 문제가 발생했습니다.
문제 상황 — Scale-out 시 권한 불일치
인증 서비스에서 권한 갱신 → 각 서비스의 로컬 메모리에 권한 캐시 보유
서비스가 Task A, B, C로 Scale-out → ALB가 요청을 임의의 Task 하나로 전달
권한 업데이트가 Task A에만 반영 → Task B, C는 이전 권한 상태 유지
결과: 동일 요청인데 어떤 Task에 도달하느냐에 따라 정상/권한 오류가 갈림
핵심 인식
이 문제는 "요청 라우팅"이 아니라 "상태 동기화 / 데이터 일관성" 문제입니다. ALB는 요청을 분산할 뿐이고, 모든 Task에 동일한 데이터를 반영하는 것은 애플리케이션/데이터 계층에서 해결해야 합니다.
해결 — 공유 캐시 계층 도입
여러 Task가 항상 동일한 권한 정보를 보게 하려면, 권한 데이터를 각 Task의 로컬 메모리가 아닌 공유 저장소에서 읽도록 해야 합니다. ElastiCache를 도입하여 모든 서비스와 Task가 하나의 공통 캐시를 바라보게 구성했습니다.
Before — 로컬 메모리 캐시
각 Task가 자체 메모리에 권한 보유 → 불일치 발생
After — ElastiCache 공유 캐시
모든 Task가 공통 캐시 참조 → 즉시 일관성 확보
대안 검토 — Sidecar Redis vs ElastiCache
인증 서비스의 Task Definition에 Redis 컨테이너를 Sidecar로 붙이는 방식도 검토했으나, Scale-out 시 Redis도 함께 복제되어 캐시가 분산되는 동일한 문제가 발생합니다.
| 비교 항목 | Sidecar Redis | ElastiCache |
|---|---|---|
| Scale-out 시 | Redis도 복제 → 캐시 분산 | 단일 엔드포인트 유지 |
| 장애 격리 | Redis 장애 시 서비스 Task 전체 영향 | 독립 관리, Failover 자동 전환 |
| 서비스 간 공유 | Task 내부에서만 접근 가능 | 모든 서비스에서 접근 가능 |
| 운영 부담 | 직접 관리 필요 | AWS 관리형, 패치/백업 자동 |
캐시 적용 흐름
비용
• 최소 구성(cache.t3.micro) 기준 약 $15/월
• 서비스 수가 늘어나도 Redis 추가 생성 불필요
• DR 리전은 Terraform으로 필요 시에만 생성하여 비용 절감
보안 설정
• 비밀번호는 Secrets Manager에 저장
• 전용 Security Group으로 ECS Task에서만 접근 허용
• Execution Role에 Secrets 접근 권한 부여 (Task Role과 분리)
캐싱 대상
• 인증/권한 데이터
• 세션 데이터
• 반복 조회 데이터
기대 효과
• Scale-out 시 권한 일관성 확보
• DB 부하 감소 및 응답 속도 개선
• 장애 격리 및 Failover 자동 전환
안정성 및 배포 신뢰성 개선
ALB Target Group의 Health Check를 서비스에 맞게 조정하였습니다. 기본 경로(/) 대신 실제 서비스 endpoint를 사용하여 ECS 서비스 상태를 정확하게 판단합니다.
기본 Health Check
GET /• 서비스 실제 상태 반영 불가
• 정적 페이지만 확인
• DB 연결 등 실제 의존성 미확인
커스텀 Health Check
GET /api/health• 실제 서비스 상태 정확 반영
• DB/Cache 연결 상태 확인
• 배포 시 불필요한 재시작 방지
글로벌 대응 구조
CloudFront를 활용한 구조는 기본적으로 글로벌 엣지 네트워크를 활용할 수 있기 때문에 다지역 사용자 대응이 가능하고, 향후 글로벌 확장 기반을 확보하였습니다.
Asia Pacific
Seoul
Tokyo
Singapore
Mumbai
North America
Virginia
Oregon
Ohio
Europe
Frankfurt
London
Paris
Summary
통합 포탈 서비스는 "Edge 캐싱 + 내부 통신 최적화 + 캐시 계층 + 안정성 개선"을 통해 성능을 체계적으로 개선한 아키텍처로 구축되었습니다. 사용자 체감 성능과 내부 처리 효율을 동시에 확보하여, 안정적이고 빠른 서비스 경험을 제공합니다.