e-커머스 Public Cloud 아키텍처(비-Kubernetes) — 가용성/응답시간/보안/비용 최적화까지

아래 다이어그램을 기준으로, 쿠버네티스 없이 운영하는 e-커머스 public cloud 레퍼런스를 정리했다. 목표는 네 가지다: 가용성, 빠른 응답, 철저한 보안, 비용 최적화(특히 버스트 트래픽). AWS 기준으로 설명한 부분이니 참고 바란다.

1) 전체 구조 개요

• 네트워크
  • 단일 VPC 안에 Public / Private Subnet 쌍을 다중 AZ로 구성.
  • Public: ALB, NAT Gateway, Bastion(옵션)
    Private: EC2(ASG), RDS Multi-AZ, 내부 서비스, VPC Endpoints.
  • Site-to-Site VPN: 온프레미스 관리망 → VGW(VPN Gateway). 운영/DB 관리 트래픽은 모두 사설 경로로만.
• 트래픽 입구
  • CloudFront(CDN) 앞단 + AWS WAF.
    정적 리소스는 S3를 오리진으로, 동적 요청은 ALB(EC2 App) 오리진으로 분기.
  • 일부 API(웹훅/이벤트성)는 API Gateway → Lambda → SQS/DynamoDB의 서버리스 경로로 우회(버스트 흡수용).
• 애플리케이션
  • ALB → Auto Scaling Group(EC2). 이미지는 ECR/CodeDeploy/SSM 어떤 방식이든 무관.
  • 상태 데이터는 RDS Multi-AZ (MySQL/PostgreSQL). 읽기 폭주 시 리드 리플리카 추가.
• 보안/가시성
  • WAF, GuardDuty, Macie, Inspector, Security Hub.
  • CloudTrail, CloudWatch, VPC Flow Logs, AWS Config, Systems Manager(SSM).
• 엔드포인트
  • Gateway/Interface VPC Endpoints로 S3, DynamoDB, CloudWatch Logs, SSM, ECR 등 내부 통신 → NAT 비용 최소화.

2) 요청 흐름(두 갈래)

2-1. 정적/캐시 가능 콘텐츠

Client → CloudFront(+WAF) → S3(정적) | ALB(동적 캐시 가능 경로)

• CloudFront 캐시, 압축, HTTP/2/3, TLS 1.3, Origin Shield로 TTFB/백엔드 부하 감소.
• 이미지/JS/CSS는 장기 캐시 + 해시 버전. 캐시 미스도 Edge에서 흡수.

2-2. 동적/이벤트성 경로

1. 일반 동적: Client → CloudFront → ALB → EC2(ASG) → RDS
2. 버스트/비동기: Client/외부 웹훅 → API Gateway → Lambda → SQS 큐잉 → 백엔드 컨슈머(EC2 or Lambda) → DynamoDB/RDS

• 순간 폭주(세일/푸시/정산 배치)는 SQS로 완충. 컨슈머 수평 확장으로 안전하게 처리.
• 읽기 폭주 페이지(랭킹/재고조회)는 DynamoDB + DAX 캐시로 분리 가능(선택).

3) 가용성 설계

• 멀티 AZ 기본. ALB, ASG(분산), RDS Multi-AZ(동기 스탠바이).
• 헬스체크 + 자동 복구: ALB Target, EC2 Status, RDS 자동 페일오버.
• NAT GW는 AZ별 배치(한 AZ 장애 시 다른 AZ 경로 사용).
  비용이 크면, 아예 NAT 의존을 줄이는 전략이 더 중요
• S3/CloudFront 본질적으로 고가용. DNS는 Route 53 헬스체크/Failover 레코드 옵션.

4) 응답 시간 최적화

• CDN 우선: 캐시 히트율이 성능과 비용을 동시에 잡는다.
• ALB + Keep-Alive: 연결 재사용, 짧은 타임아웃 튜닝, gZIP/Brotli(CloudFront) 압축.
• DB: 가장 느린 계층. 읽기는 캐시, 쓰기 경로는 비동기화(SQS)로 피크 분산.
• VPC 엔드포인트: 내부 서비스 호출이 NAT를 타지 않도록 근거리 연결.
• 애플 확장: ASG 스텝/예측 스케일링, 새벽 세일 직전 프리워밍.

5) 보안 설계

• 엣지: CloudFront WAF 룰셋, 레이트 리밋, IP 허용/차단, 봇 필터.
• 네트워크: 퍼블릭/프라이빗 서브넷 분리, SG 최소 권한, DB는 사설/허용 IP만.
• 식별/감사: IAM 최소권한, CloudTrail 전 구역, S3/Logs 불변 저장(버전/보존정책).
• 탐지/평가: GuardDuty(위협 탐지), Inspector(취약점), Macie(민감데이터), Security Hub로 통합.
• 운영 접근: VPN + IAM 조합.

6) 비용 최적화 — 특히 버스트(이벤트성) 대비

핵심은 NAT 절감, 캐시율, 비동기화, 요금제 믹스다.

6-1. NAT 비용 줄이기

• VPC Endpoints 필수: S3/DynamoDB Gateway, CloudWatch Logs/SSM/ECR 등 Interface.
  → 대량 아웃바운드가 NAT로 안 빠진다(처리량*요율 절감).
• 애플이 외부로 나가는 호출은 최소화. 서드파티 호출은 Lambda 경유 비동기로 묶어 호출 수를 줄인다.

6-2. CDN으로 오리진 보호

• 정적은 S3 오리진, 동적도 짧은 TTL + Stale-while-revalidate로 캐시.
• 이미지 리사이즈/서빙은 Lambda@Edge/CloudFront Functions 조합 고려(원본 저장 최소화, 전송량↓).

6-3. 버스트 트래픽은 큐로 흡수

• 주문/알림/정산/웹훅은 API GW → Lambda → SQS로 스파이크를 평탄화.
  컨슈머는 ASG/Lambda로 서서히 스케일. DB에 직접 몰리지 않음.
• DynamoDB는 온디맨드 쓰기(버스트 캐치) + TTL/GSIs 관리로 비용 제어.
  캐시가 가능한 읽기는 DAX로 RPS 흡수.

6-4. 컴퓨팅 요금제 믹스

• Savings Plans/RI로 상시 트래픽의 50~70% 커버.
  남는 피크는 온디맨드 + 비동기 경로로 처리.
• 스팟은 웹 프론트엔드에는 비권장(중단 리스크). 비동기 컨슈머/배치에만 제한적 사용.

6-5. RDS 비용/성능 밸런스

• 초기에 **RDS Multi-AZ(프리미엄 IO 아님)**로 시작, IOPS 병목 시에만 IO-Optimized/프로비저닝 IOPS.
• 리드 트래픽은 리드 리플리카 + CloudFront 캐시/애플 캐시로 DB 크기 상승 억제.
• 크리티컬 스파이크 쓰기는 SQS 완충 후 배치 커밋. 트랜잭션 단위 재설계가 가장 큰 비용 절감 포인트.

6-6. 로깅/옵저버빌리티 요금 관리

• 로그 샘플링과 짧은 보존기간 + Glacier 전환.
• VPC Flow Logs는 필요한 서브넷/계층만, 필터링 저장.

7) 컴포넌트별 체크리스트

• VPC/서브넷
  • AZ A/C 쌍. 퍼블릭(NAT/ALB), 프라이빗(EC2/RDS/엔드포인트).
  • 라우팅: 프라이빗 → 엔드포인트 우선, 외부만 NAT.
• CloudFront + WAF
  • 캐시 정책, 압축, Origin Shield, WAF 매니지드 룰 + 커스텀 레이트리밋.
• ALB + ASG(EC2)
  • 헬스체크, 스케일아웃 기준(CPU+응답시간+큐 길이), 배포 전 웜업.
  • AMI 골든 이미지 + UserData 최소화 → 기동 시간 단축.
• API Gateway + Lambda + SQS/DynamoDB(옵션 경로)
  • 버스트 경로 분리, DLQ/리트라이, 멱등키(중복 처리 방지).
  • DynamoDB 온디맨드 + 파티션키 설계.
• RDS Multi-AZ
  • 백업/스냅샷, 파라미터그룹, 연결 풀링, 슬로우 쿼리 지표.
  • 리드 리플리카와 쓰기 분리 시 라우팅/드라이버 관리.
• 보안/운영
  • IAM 최소 권한, SSM 세션, 키/시크릿은 Secrets Manager/Parameter Store.
  • GuardDuty/Inspector/Macie 알림을 Security Hub로 통합, CloudWatch Alarms와 연계.

8) 왜 “비-Kubernetes”인가

• 팀/운영 복잡도 없이도 ALB+ASG와 서버리스만으로 가용성과 탄력성을 충분히 달성.
• 버스트는 큐 기반 비동기로 해결하는 편이 더 예측 가능하고 저렴하다.
• 운영 표준(SSM/Inspector/Config/CloudTrail)과 비용 가시성 확보가 단순.

9) 향후 확장 옵션(트래픽 성숙 단계)

• 읽기 스케일↑: 글로벌 캐시(CloudFront), DB 리플리카, DynamoDB 도입.
• 쓰기 스파이크↑: SQS 단계적 확장, 컨슈머 수평 확장, 배치 커밋 최적화.
• DB 레이턴시/장애 민감↑: Aurora로 마이그레이션(서버리스 v2 포함) 검토.
• 글로벌 유저↑: CloudFront 지역 최적화, Route 53 지연시간 기반 라우팅.

요약

• 정적은 S3+CloudFront, 동적은 ALB+ASG, 버스트는 API GW+Lambda+SQS로 분리한다.
• RDS Multi-AZ로 쓰기 일관성/가용성 보장, 리드 리플리카/캐시로 읽기 확장.
• VPC Endpoints로 NAT 의존을 줄이고, CDN 캐시율을 끌어올려 오리진/전송 비용을 동시에 깎는다.
• Savings Plans/RI는 상시 부하만 덮고, 피크는 비동기 + 온디맨드로 처리한다.
• 보안과 로깅은 **엣지(WAF)**와 계정 단위 탐지/감사로 기본값을 높여 유지한다.

이 구성은 가용성/응답시간/보안/비용 네 축을 동시에 만족시키면서, 세일 시즌 같은 버스트 트래픽을 안전하게 흡수한다. 운영은 단순하고, 비용은 예측 가능하며, 스케일 경로도 명확하다.

🛠 마지막 수정일: 2025.10.14