프로젝트/ACC Load Test Project

부하테스트 프로젝트 설계 1차

dayeonsheep 2025. 4. 11. 15:14

 

주제: 재난감지 및 알림 웹앱 서비스

 

  •  API
  • 역할
    • BE : 소윤, 민희님 → Spring, Node.js
      • 만들어야하는 API : 실시간 스트리밍 지원 API, 재난 감지 알림 API ⇒ AI연동, 사용자 관리 API(시나리오 고려해서 구체적으로 수정)
    • FE : 다연 → Next.js 이용해서 react (ts) 
    • AI : 재난감지 AI API → 허깅페이스, 캐글 참고
    • Infra : 다같이
      • 기본 배포는 제가 맡고, 하고 싶은 부분 있다면 같이 나누기
  • 논의사항
    • CI/CD → 할건지? (github actions + argoCD) => 자주 업데이트 해야하는 API가 아니라서 제외
    • 부하테스트 툴 → k6
    • 모니터링 툴 → grafana + prometheus
      • 로그 분석이 필요할 것 같다 ⇒ Loki
      • Cloudwatch → 필요한 부분이 있는지 재고려
  • SLO & SLI 설계
  • SLO (Service Level Objectives) - 사용자가 체감하는 서비스 품질 목표 (실제 달성해야 하는 목표)항목 목표
API 응답 시간 95% 요청이 500ms 이내
알림 전송 지연 90% 메시지가 5초 이내 도달
서비스 가용성 월 99.9%
CCTV 스트리밍 지연 < 2초 내 latency 유지
장애 대응 속도 1분 내 알림 전파 & 자동 복구 시작

 

  • SLI (Service Level Indicators) - SLO를 측정할 실제 성능 지표항목 측정 방법
응답 지연 API Gateway + CloudWatch Latency
메시지 전송 시간 SNS 전송 로그
스트리밍 딜레이 CloudFront / Kinesis delivery metrics
가용성 Route53 + CloudWatch Alarm
에러율 5xx 비율 (Lambda, API Gateway, ECS 등)

 

 

CloudFront vs Kinesis 비교 (CCTV 스트리밍 용도)

더보기
항목 CloudFront Kinesis
역할 정적/동적 콘텐츠 CDN (캐시 & 전송) 실시간 데이터 스트림 처리
적합한 상황 정해진 CCTV URL이나 녹화 영상 전송 IoT 센서, CCTV 실시간 프레임 처리, 실시간 분석
지연 시간 수백 ms 이내 (CDN 기반) 수십~수백 ms (스트림 기반, Consumer에 따라 변동)
비용 트래픽 전송량 기준 ($0.08~0.12/GB) 샤드 단위 요금 + 데이터 처리량 기준 (비쌈)
확장성 글로벌 엣지 노드, 무제한 캐시 샤드 수 늘려야 확장됨
운영 복잡도 쉬움 (캐싱 설정만 하면 됨) 어렵고 코드 필요 (프로듀서-컨슈머 구조)
재난 적합성 “빠르게 전달만” 필요할 때 적합 실시간 처리 & 분석이 필요한 경우 적합

단순히 실시간 CCTV 영상을 전달하려면 CloudFront가 훨씬 저렴하고 빠르고 쉬움.
반면 영상 내 얼굴 감지, 객체 추적 같은 분석이 필요하면 Kinesis + Lambda / Firehose 조합 괜찮.
다만 우리 서비스에서는 자연 재해상황 인식만 필요하기 때문에 제외

  • 운영 목표 설계
    • API 응답 시간 500ms 이하 유지 → 더 줄일 수 있을지…
    • 트래픽 급증 시 Auto Scaling이 1분 내로 서버 확장 → 얘도 더 줄이면 좋겠어요
    • 스트리밍 지연 2초 이하로 최소화
  • 기능 설명
    실시간 CCTV 스트리밍 CCTV API를 활용해 영상 표시
    지도 기반 UI 지도에서 CCTV, 교통 상황, 재난 발생 지역 표시, 재난 부근 CCTV 마크 색깔을 빨간색으로 변경
    재난 감지 & 알림 AI 감지 데이터 & 긴급 경고 알림 표시
  • 아키텍처 서비스 고려
    • 사용자 번호 저장 db → RDS aurora serverless 있는데 비쌀 것 같음 ⇒ 서버리스로 확장성, 비용 고려해서 lambda + dynamodb 써도 괜찮을 듯 ⇒ 근데 걱정되는 건 spring이 cold start 시간이 좀 길어질 가능성이 커서 부하테스트에서 api 응답시간 목표가 충족되지 않을 것 같음
    • 아키텍처 설계하다 보니까 빠르고 확장성 있게 전달하려면 서버리스 구축이 가장 비용최적화, 성능최적화면에서 적절한데, Lambda로 무거운 Spring을 쓰면 cold start 때문에 긴급 응답 실패 위험 있어서 lambda는 경량화된 알림 처리용 API로 쓰고, 메인 백엔드는 ECS에 올리는 걸 고려해도 괜찮을 것 같음
    • 위 사례가 안된다면 cold start 고려해서 SLO 수정

 

항목 사용 서비스 추정 사용량 (3시간)  예상 비용
API 처리 Lambda (Node.js 기준) 10억 호출 (초당 10만 × 3,600초 × 3시간) 약 $300~400
API 처리 (Spring) ECS Fargate (CPU 1vCPU, 2GB 메모리, 10개 컨테이너) 3시간 약 $30~50
DB DynamoDB (RCU/WCU 최대 자동 확장) 수천만 read/write 약 $100~200
정적 콘텐츠 제공 S3 + CloudFront 1TB 전송 (지도 + UI) 약 $100
모니터링 CloudWatch + Prometheus (로그/지표) 5~10GB 지표/로그 약 $5~15
알림 SNS (SMS 기준) 10,000건 전송 약 $100~200
CCTV 스트리밍 CloudFront 1TB 영상 전송 CloudFront: $80

→ 이걸 다 할순 없어서, db 용량 줄여서 실제 알림 되는지 받는것만 테스트

→ 추정 사용량도 재난 상황고려해서 3시간으로 잡았는데 더 줄여도 되고 (테스트용으로는 1시간기준 혹은 10분으로 동접자 수만 동일하게 해서 비교 등)

→ 프론트 정적 배포도 용량 줄일 수 있는 체크

⇒ DB + 알림 비용은 최소로. 나머지는 lambda api 처리량 조절하면서 나머지도 비용조절

 

  • 아키텍처 draft
    • VPC 대역 설계
      • ECS fargate 부분 : CIDR 나눠서 private subnet, public subnet 나눠 설계 필요
    • DynamoDB는 사용자 정보 받는 거 확장할 때 좋기도 한데, 부하테스트용 로그 데이터 기록으로 추가
      • 어떤 사용자에게, 어떤 재난 상황에 대해, 몇 시에, 어떤 메시지가 발송됐는지
      • 특히 ⇒ API 처리 시간이나 알림 딜레이는 어땠는지 저장

1차 간단 아키텍처

 

  • 아키텍처 주요 추가 고려사항
    • Cloudwatch → 어떻게 연결했을 때 효율적이고 필요한 부분이 있는지
    • ECS → LB 붙이는 점 고려
    • Cloudfront CDN 캐시 최적화
    • Kafka 도입 고려
저작자표시 비영리 변경금지