크레아

이번 장에서는 앞서 구성한 CloudFront + S3 Origin 기반 CDN 구조가 실제 운영 환경에서 어떻게 동작하는지 검증하는 과정을 정리한다.Ch27에서는 CloudFront, S3 Origin, ALB Origin, OAC, ACM, WAF를 구성했고, Ch28에서는 GitLab CI를 통해 Frontend 빌드 결과물을 S3에 업로드하고 CloudFront Invalidation을 수행하는 배포 자동화를 구성했다.이번 장에서는 단순히 배포가 성공했는지 확인하는 것을 넘어, CloudFront가 실제로 정적 리소스를 캐싱하는지, /api/* 요청이 ALB Origin으로 정상 전달되는지, 배포 후 변경사항이 반영되는지, 그리고 운영 중 발생할 수 있는 CDN 관련 이슈를 어떻게 확인할 수 있는..

이번 장에서는 앞서 구성한 CloudFront + S3 Origin 기반 CDN 아키텍처에 맞춰 Frontend 배포 파이프라인을 변경하는 과정을 정리한다.기존 Frontend는 GitLab CI에서 Docker Image를 빌드하고, ECR에 Push한 뒤 GitOps 저장소의 image tag를 수정하면 ArgoCD가 EKS에 Frontend Pod를 배포하는 구조였다.하지만 Ch27에서 Frontend 정적 리소스 제공 책임을 EKS Pod에서 S3 Origin + CloudFront로 분리했기 때문에, 더 이상 ops-client는 Docker Image로 배포할 필요가 없다.따라서 이번 장에서는 ops-client 저장소의 빌드 결과물인 dist/ 디렉토리를 S3 버킷에 업로드하고, CloudF..

이번 장에서는 기존 EKS 기반 Frontend 배포 구조를 CloudFront + S3 Origin 기반 CDN 구조로 전환하는 과정을 정리한다.기존에는 Frontend와 Backend가 모두 EKS 위에서 Pod로 실행되고, 외부 사용자는 ALB를 통해 Frontend 서비스에 접근하는 구조였다. 하지만 Frontend가 CSR 방식으로 동작하고, 빌드 결과물이 정적 파일로 생성되는 구조라면 반드시 EKS Pod에서 정적 리소스를 서빙할 필요는 없다.따라서 이번 장에서는 Frontend 정적 리소스는 S3 Origin에 배포하고, CloudFront를 통해 캐싱하며, Backend API 요청만 기존 ALB → EKS Backend로 전달하는 구조를 구성한다. ✅ 목적기존 구조는 다음과 같았다...

1. 개요EV 충전 데이터 분석의 핵심은각 충전 세션(Session)을 정확하게 정의하고,충전 중 발생하는 이벤트(Event)를 세션에 연결하여 KPI를 도출하는 것이다.본 글에서는 다음 내용을 다룬다.Session / Event / Station 데이터 모델 정의이벤트 기반 데이터를 세션 단위로 정규화하는 방식Analytics Layer(Parquet) 기반 KPI 계산 구조Athena SQL을 활용한 주요 KPI 예시운영형 대시보드 구성: ETL 2개 분리 + Athena View + QuickSight SPICE + Refresh 주기Quicksight Dashboard 구성 현황2. 전체 데이터 모델 흐름 실시간으로 수집된 EV 충전 데이터는 다음 단계를 거쳐 KPI로 변환된다.Raw → Proc..

1. 개요실시간 스트림(Kinesis → Lambda Normalizer)으로 들어온 데이터는 결국 S3에 적재되고,이 S3를 중심으로 Raw → Processed → Analytics 레이어를 나눈 Lakehouse 구조를 만든다.이 글에서는 다음을 다룬다.Raw / Processed / Analytics 3계층 S3 설계Glue Data Catalog + Crawler 구성Glue ETL Job으로 Processed JSON → Analytics Parquet 변환Athena WorkGroup을 통한 Analytics 조회 구조이 구조의 목표는 세 가지다.신뢰성 – 원본 그대로 보존해서 언제든지 재처리 가능정규화 – 분석 가능한 스키마로 가공된 데이터 유지분석 성능 – Parquet + Partiti..

1. 개요이 글에서는 실시간 EV 충전 데이터(OCPP 이벤트)를 수집하는 Streaming Layer 전체를 구축한다.구성 요소는 다음 네 가지다.EKS OCPP Handler → Kinesis (Producer)Kinesis Data StreamLambda Normalizer (Kinesis Consumer)IAM / IRSA / DLQ / Event Source Mapping이 레이어의 목적은 실시간 이벤트를 안정적으로 수집하고, 이후 분석 파이프라인에서 처리할 수 있도록 정규화된 입력 데이터를 만드는 것이다.2. 전체 흐름EV Charger → WebSocket → EKS OCPP Handler → Kinesis Data Stream → Lambda Normalizer → S3 Raw / Proc..

1. 왜 실시간 데이터 파이프라인이 필요한가EV 충전 인프라는 단순한 트랜잭션 로깅이 아니라실시간 이벤트 스트림을 기반으로 운영되는 시스템이다.충전기에서 발생하는 이벤트들은 대부분 실시간 처리가 요구된다.세션 시작/종료 시각충전량(kWh) 증가충전 중 오류 코드커넥터 상태 변화충전기/스테이션 가동 여부이 데이터는 수집 즉시 다음과 같은 분석 및 운영 의사결정에 사용된다.실시간 충전기 상태 모니터링세션 단위 KPI 집계충전량/매출 추정장애 대응(MTTR 계산)스테이션 가동률 분석문제는 기존 방식이 다음과 같았다는 점이다:WebSocket → DB 직결 구조로 인해 확장성이 부족함메시지 포맷이 비정형이라 session join/정규화가 어려움DB에 직접 쌓아 분석하는 방식이라 표준화된 Data Lake/An..