🏁

Come2us #3 - Infra & DevOps BluePrint

Date

2025/11/30

1. 개요

•

프로젝트명: COME2US (Sprint #3)

•

목표:

◦

ECS 기반 2차 아키텍처를 Kubernetes(EKS) 기반으로 확장

◦

GitOps 기반 선언적 배포 구조 정립 (GitHub Actions + ArgoCD)

◦

서비스 메시에 Istio 도입하여 보안(mTLS)·트래픽 제어·관찰성 확립

◦

Helm 기반 Kubernetes Manifest 템플릿화

◦

Kafka(MSK) 기반 이벤트 시스템을 결제(Payment) 서비스 중심으로 부분 도입

◦

인프라 자동화는 Terraform 중심으로 유지

◦

Istio를 활용한 Canary 배포 전략 도입

◦

Karpenter 기반 자동 노드 프로비저닝 도입

•

핵심 구성 계층

계층	주요 구성 요소
Network Layer	VPC, Subnet(Public/App/Data), NAT, LB, Route53
Compute Layer	EKS, NodeGroup, Karpenter
Service Layer	Spring Boot Microservices, Istio, Envoy Sidecar, Helm
Data Layer	RDS(PostgreSQL), Redis, MSK(Kafka), S3
DevOps Layer	GitHub Actions(CI), ArgoCD(CD), Terraform, Helm
Observability Layer	CloudWatch, Prometheus, Grafana, Loki, Tempo(Tracing)

2. 시스템 아키텍처 요약

아키텍처 다이어그램

주요 변경점 요약 (ECS → EKS 전환)

영역	2차 프로젝트 (기존)	3차 프로젝트 (변경 버전)
컨테이너 오케스트레이션	ECS Fargate	EKS + Karpenter
배포 체계	Jenkins + Terraform	GitHub Actions(CI) + ArgoCD(CD)
서비스 디스커버리	Eureka	K8s Service + Istio Mesh
트래픽 라우팅	Spring Cloud Gateway	Istio Ingress Gateway + Envoy
App 설정 관리	Config Server	Helm Values + ConfigMap/Secret
이벤트 시스템	-	Kafka(MSK) 도입 (결제 서비스, 로그 파이프라인)
관찰성	CloudWatch 중심	Prometheus + Grafana + Loki + Tempo
배포 전략	Blue/Green	Canary Deployment (Istio 기반)

3. 네트워크 구조

•

2차 프로젝트와 동일한 2-AZ 구성

•

Public, Private(Application), Private(Database) Subnet을 분리하여 트래픽 및 보안 계층화

◦

기존과 동일

•

Istio Ingress Gateway는 LoadBalancer Service이며, AWS NLB 생성

•

모든 서비스 간 통신은 Envoy Sidecar를 통해 처리

구분	역할	구성 계획
Public Subnet	외부 노출용 리소스	- ALB(Grafana, ArgoCD) - NLB(Istio Ingress Gateway) - NAT
Private Subnet(Application)	내부 서비스	EKS Worker Node
Private Subnet(Database)	데이터 리소스	RDS, Redis, MSK
Routing	IGW / NAT	Outbound → NAT
DNS	Route53 + ACM	HTTPS 통신 기반 인증서 관리

4. 애플리케이션 계층

구성 요소

요소	설명
EKS Cluster	모든 MSA 서비스의 런타임 환경
NodeGroup + Karpenter Autoscaling	On-demand 최소 구성 + Karpenter 통한 Autoscaling
Pod / Deployment / Service	내부 서비스들은 ClusterIP를 통해 노출
Istio (Service Mesh)	mTLS, Traffic Splitting, Routing, Circuit Breaker
Envoy Sidecar	Pod 간 통신 프록시
Helm Charts	Microservice 템플릿 관리
ArgoCD	GitOps 기반 지속적 배포(CD)

서비스 흐름

Client → Route53 → Istio Ingress Gateway → Envoy Sidecar
→ K8s Service → Microservice Pod
→ RDS / Redis / MSK(Kafka)
→ Envoy Sidecar → Istio Ingress Gateway → Client 응답
Plain Text
복사

5. 데이터 계층

•

기존과 동일한 데이터베이스를 유지하며, MSK(Kafka)를 도입하여 이벤트 기반 메시징 처리

구성요소	설계 의도
RDS (PostgreSQL)	Multi-AZ 구성 (Writer: AZ-a, Standby: AZ-b, Reader 다중 구성)
Redis (ElastiCache)	- Session Redis (세션 + 비영속 데이터 저장소) - Cache Redis (캐시 저장소)
MSK (Kafka)	- 결제(Payment) 서비스 적용 - 로그 파이프라인 적용
S3	- 이미지 저장소 및 정적 오브젝트 저장 - VPC Endpoint 통한 사설 연결 구성

6. 이벤트 기반 아키텍처 - MSK

Details: 결제하기-SAGA패턴을 이용한 설계

MSK(Kafka)는 결제 승인 결과를 비롯한 주문·상품·쿠폰 서비스 간 SAGA 보상 트랜잭션을 구현하기 위한 핵심 메시징 플랫폼으로 사용한다.

본 프로젝트에서는 결제 서비스 중심의 부분 도입을 시작으로, 점진적으로 EDA를 확장한다.

6.1 도입 배경

목적	설명
SAGA 보상 트랜잭션 처리	결제 승인 실패 시 주문/재고/쿠폰 원복 처리
서비스 간 강결합 제거	동기 HTTP 호출 제거 → 비동기 메시지 기반 통신
장애 전파 차단	외부 서비스 실패가 주문 서비스까지 전파되지 않도록 격리

6.2 이벤트 흐름

결제 승인 성공 흐름

payment-service → payments-paid 발행

order-service consume → 주문 상태 PREPARING 로 변경

결제 승인 실패(보상 흐름)

payment-service → payments-failed 발행

order-service consume → 주문·쿠폰 원복 (idempotent)

order-service → orders-failed 발행

product-service consume → 재고 롤백

6.3 Topic 설계

이벤트	Topic 명	발행 주체	소비 주체
결제 승인 성공	payments-paid	payment-service	order-service
결제 승인 실패	payments-failed	payment-service	order-service
주문 보상 실패	orders-failed	order-service	product-service

6.4 Kafka 클러스터 구성

항목	값	이유
Broker 개수	3개	Quorum(2) 확보, 고가용성
Partition 수	3개	Broker 수의 배수 → Leader 분산
Replica 수	3개	장애 시에도 메시지 유실 방지
보관 기간	7일	비정상 이벤트 재처리 대비

6.5 Consumer Group 전략

•

서비스별 1 Consumer Group

◦

주문(Rebalancing) 문제를 줄이고 안정적인 메시지 처리를 위해

order-service-group, product-service-group 형태로 구성

•

같은 그룹 내에서는 메시지 병렬성 = Partition 수

◦

현재 Partition=3 → 3개 인스턴스까지 병렬 처리 가능

•

Exactly Once 보장

◦

Consumer는 메시지를 처리 성공 시 명시적으로 Commit

◦

실패 시 Commit하지 않고 DLQ로 이동 → 재처리 가능

6.6 DLT (Dead Letter Topic)

Kafka에서 Consumer가 메시지 처리에 실패할 경우, 해당 메시지는 DLT(Dead Letter Topic)

으로 이동하며 재처리 또는 수동 복구를 위한 근거 데이터로 사용된다.

DLT 적용 포인트

실패 위치	DLT 활용 이유
order-service (payments-failed 처리 실패)	주문/쿠폰 원복 실패 시 반드시 재처리 필요
product-service (orders-failed 처리 실패)	재고 원복 실패 시 비즈니스 장애 유발

DLT 메시지 스키마

1) payments.failed 처리 실패 이벤트

필드	내용
orderId	주문 ID
paymentKey	PG 결제 키
errorSource	order-service or product-service
errorCode	내부 에러 코드
errorMessage	오류 메시지2) orders-failed 처리 실패
timestamp	실패 발생 시각

2) orders.failed 처리 실패 이벤트

필드	내용
orderDetailId	주문 상세 ID
optionValueId	옵션 ID
quantity	원복해야 하는 수량
paymentKey	PG 결제 키
errorSource	order-service or product-service
errorCode	내부 에러 코드
errorMessage	오류 메시지

DLT 활용 전략

DLT Consumer를 통한 자동 재처리

•

일시적 장애(잠깐의 DB 락, 네트워크 지연 등)는 재처리 시 성공 가능

•

주문/재고 시스템 데이터 정합성을 위해 반드시 필요

운영자 수동 재처리

•

구조적 장애(논리적 오류, 스키마 문제 등)는 수동 조치 필요

DLT 모니터링

•

Grafana / CloudWatch에서 DLT 적재량을 모니터링해 운영 장애 조기 감지

•

특정 Topic의 DLT 증가 = 특정 서비스 장애로 볼 수 있음

6.7 멱등성(Idempotency) 전략

중복 메시지 처리 및 중복 결제 실행 방지를 위한 멱등성 처리 전략.

1) 결제하기 API 멱등성 – Toss Idempotency-Key

•

클라이언트에서 UUIDv4 기반 명등키 Idempotency-Key  생성 및 전달

•

토스페이먼츠가 서버 내부적으로 멱등 처리

•

ALREADY_PROCESSED_PAYMENT 응답 시 → 보상 트랜잭션 실행 금지

2) Consumer 멱등성

•

Kafka 메시지는 At-Least-Once가 기본이므로 동일 메시지가 중복 전달될 가능성 존재

•

Consumer는 DB 상태 기반 멱등성 체크 필요

예시 (order-service):

if (order.status == FAILED) return
if (order.status == PREPARING) return
Java
복사

6.8 Producer 발행 실패 처리

방안 1) Transactional Outbox Pattern

DB 업데이트 + Event 저장을 하나의 트랜잭션으로 묶어 원자성 보장

장점:

•

Kafka 장애에도 데이터 유실 없음

•

재처리 가능

방안 2) 발행 실패 재시도 테이블 + 스케줄러

•

publishStatus = FAILED 마킹

•

스케줄러가 1분 간격 재시도

•

Exponential Backoff 적용 가능

6.9 PENDING 장기 체류 주문 스케줄러

결제 지연·외부 서비스 오류로 인해 5분 이상 PENDING 상태로 남아있는 주문 정리 로직

실행 전략

•

스케줄 주기: 1분

•

타임아웃 기준: 5분

처리 방식

5분 이상 PENDING 주문 조회

주문 상태 FAILED로 변경

쿠폰 / 재고 롤백 요청 발행

DB 업데이트 후 Kafka에 보상 이벤트 발행

개선 방안

외부 시스템 호출을 비동기 이벤트 기반으로 전환 (최적 방식)

•

주문 서비스는 DB 업데이트 + Kafka 이벤트 발행으로 작업 종료

•

product/payment 서비스가 토픽을 구독하여 자체적으로 롤백 실행

•

응답 대기 시간이 없으므로 안정성 + 성능 개선

청크 처리 (대량 주문 대비)

•

PENDING 주문을 전체 조회하지 않고 chunk 단위로 처리

•

시스템 부하 감소

•

실패 시 특정 chunk만 재처리 가능

7. CI/CD 파이프라인

GitOps 파이프라인 다이어그램

GitHub Actions (CI)

•

Lint → Build → Test → Docker Build → ECR Push

•

Helm values 업데이트

ArgoCD (CD)

•

GitOps Repo 상태를 기준으로 EKS 상태 자동 동기화

•

Health/Sync 자동 관리

•

Helm-Based Release 관리

•

데이터 보존을 위한 EBS Volume 또는 EFS Volume 마운트 고려

◦

ArgoCD는 GitOps 기반의 stateless 운영 모델을 사용하므로 별도의 EBS/EFS 마운트 불필요

◦

ArgoCD는 Kubernetes 리소스를 Git 저장소를 통해 재생성할 수 있으므로,
EKS 클러스터 재생성 시에도 Git 상태를 기준으로 전체 상태 복구 가능

8. 배포 전략 - Canary

우선적으로는 Istio VirtualService 기반의 수동 Canary 방식으로 운영

도입 배경

•

Blue/Green 대비 더 안전한 점진적 배포 제공

•

Istio VirtualService 기반 트래픽 분할 가능

•

서비스 안정성 확보를 위한 점진적 검증

•

GitOps 기반 배포 이력 보존

8.1 배포 흐름

신규 버전 배포

DestinationRule을 통한 v1/v2 Subset 정의

VirtualService 기반 Canary 트래픽 설정

•

v1: 90%, v2: 10%

Grafana + Tempo + Loki 기반 모니터링

•

Latency/Error, Log, Trace

오류 시 Rollback

•

v1 = 100%

정상 동작 시 트래픽 확대

•

10 → 30 → 50 → 100

8.2 Canary 배포 단계

단계	트래픽 비율	수행 항목	성공 기준
Phase 0	0% → 10%	신규 버전(v2) 배포, VirtualService weight 10% 적용	Pod Ready 100%, 오류 없음
Phase 1	10% → 30%	주요 API 응답 검증	Latency 증가 < 200ms, Error Rate < 1%
Phase 2	30% → 50%	실제 사용자 트래픽 점진적 반영	5xx < 0.3%, Business Error < 1%
Phase 3	50% → 100%	전체 트래픽 전환	Pod 안정화, 로그 이상 없음

8.3 Canary 실패 기준 (Rollback 조건)

Rollback은 즉시 VirtualService를 Stable(v1)로 전환하여 처리한다.

분류	조건
HTTP 오류율	5xx 비율 3% 이상 (1분 평균)
Latency 증가	평균 응답속도 200ms 이상 증가
애플리케이션 오류율	Business Error 1% 이상
Readiness 실패	신규 Pod Ready 실패
리소스 임계치	CPU > 80%, Memory > 85%

8.4 구성 요소

요소	역할
Deployment (v1/v2)	버전별 Pod
DestinationRule	Subset 정의 (labels 기반)
VirtualService	트래픽 비율 조정
Envoy Sidecar	실제 트래픽 분배 수행
ArgoCD Sync	GitOps 기반 자동 배포

8.5 고려사항 (Manual Canary 운영 관점)

항목	설명
Observability	Grafana / Loki / Tempo 통합 필요
Sticky Session	세션 일관성 확보가 필요한 API에 대한 Session Redis 호환성 검증 필요
테스트 자동화 필요성	Canary 단계별 검증을 위한 k6/JMeter 등의 API Test 구성 고려
Resource Impact	v1/v2 동시 운영으로 인한 Pod 수 증가 → HPA/Karpenter
향후 확장성	현재는 프로젝트 기간 고려하여 수동 Canary 운영 방식 적용 향수 Auto Rollback을 도입할 경우 Argo Rollouts + AnalysisTemplate 기반 확장

9. 오토스케일링 전략

9.1 Pod Autoscaling (HPA)

9.1.1 HPA 정책 기준

•

CPU 사용률 > 70%

•

Memory 사용률 > 75%

•

Target Metric 기반 자동 확장

•

Canary 배포시 v1 + v2 Pod 동시 존재 고려

•

Karpenter Node 생성 시간을 고려한 최소 Replica 버퍼 전략 적용

9.1.2 서비스별 HPA minReplicas 버퍼 전략

Karpenter의 Node Provisioning 시간동안 기존 Pod가 과부하되지 않도록 최소 Replica를 여유있게 유지한다.

서비스 유형	트래픽 특성	초기 구성 minReplica 버퍼
Gateway (Ingress)	외부 요청 집중, Latency 민감	평시 Pod의 150%
Order / Payment	Latency 민감, 장애 영향 큼	130~150%
Product	높은 조회 빈도	120~130%
User	일반 API	120%
AI	중요도 낮음, 사용량 적음	100~110%

9.1.3 서비스별 HPA 설정

서비스	Min~Max	특징
Gateway (Ingress)	3~6	요청 집중 구간, 안정성 중요
User/Product	2~10	조회 중심, 트래픽 변동폭 큼
Order/Payment	2~5	주문/결제 중심, 안정성 중요
AI	1~2	최소 유지

9.1.4 Requests / Limits

•

임시 - GPT 추천값 / 추후 모니터링 반영 조정

서비스	CPU Request	CPU Limit	Memory Request	Memory Limit
Gateway	250m	500m	512Mi	1Gi
User/Product	200m	400m	256Mi	512Mi
Order	200m	500m	512Mi	1Gi
Payment	300m	600m	512Mi	1Gi
AI	100m	300m	256Mi	512Mi

9.2 NodeAutoscaling (Karpenter)

•

Karpenter를 도입하여 자동 Node Provisioning을 목표로 함

9.2.1 Karpenter 도입 배경

문제	설명
ECS / 기존 EKS의 한계	Pod 증가 시 NodeGroup의 scale-out 속도가 느림
고정 노드 비용 발생	항상 Node를 유지해야 해서 비용 증가
Canary 배포 시 Pod 일시 증가	Canary 실행 시 v1+v2 Pod 동시 운영 → 노드 부족 발생
트래픽 변동성	Product, Order 서비스의 트래픽 변동 폭이 큼

9.2.2 Karpenter 동작 흐름

HPA가 Pod 증가 
→ 기존 Node capacity 부족 → Pod Pending 발생
→ Node Provisioning (Karpenter)
→ Pod Scheduling 완료
→ 트래픽 감소 → Idle Node 발생
→ Idle Node 자동 제거 (Consolidation)
Plain Text
복사

9.2.3 Autoscaling 고려사항

•

Karpenter Provisioning 시간동안 기존 Pod의 과부화 방지를 위한 minReplicas 버퍼 적용

•

Canary 배포 시 v1/v2 Replica 동시 증가 → Karpenter 즉각 확장 필수

•

트래픽 감소 시 Consolidation을 통해 비용 최소화

•

Pod 요청(Request)이 낮게 잡히면 과도한 확장 발생하므로 적절한 Request 필요

•

Spot Instance 사용 고려

10. Observability

Details: Observability 아키텍처 문서

10.1 구성요소

계층	구성 요소	역할
Metrics	Prometheus	애플리케이션·Istio·Node 메트릭 수집
Logs	Fluentbit → Loki	stdout 로그 수집 및 저장
Tracing	Envoy / Spring Boot OTel → OTel Collector → Tempo	분산 트레이싱 저장
Dashboard	Grafana	Metrics / Logs / Tracing 시각화
Infra Logs	CloudWatch Logs	Node, Control Plane, EKS Infra 로그 저장

10.2 Metrics 수집 흐름

10.2.1 애플리케이션 / 서비스 메트릭

•

Spring Boot Actuator의 /actuator/prometheus 활용

•

Prometheus Operator를 사용하여 메트릭 수집

•

서비스별 ServiceMonitor를 통해 Scrape

데이터 흐름:

Application Pod (/actuator/prometheus)
→ ServiceMonitor
→ Prometheus
→ Grafana
Plain Text
복사

10.2.2 Istio (Envoy) 메트릭

•

Istio Telemetry v2 활성화

•

Prometheus가 Istio의 Envoy Proxy를 Scrape

•

ServiceMonitor 활용

Envoy SideCar
→ Prometheus (ServiceMonitor)
→ Grafana (Istio Dashboard)
Plain Text
복사

Istio Standard Metrics

Istio standard metrics exported by Istio telemetry.

https://istio.io/latest/docs/reference/config/metrics/

10.2.3 Node / 시스템 메트릭

•

구성요소

◦

kube-state-metrics

◦

node-exporter (PodMonitor 활용)

•

수집 지표

◦

CPU / Memory

◦

Pod 상태

◦

Node 상태 / Disk I/O

◦

네트워크 등 인프라 자원 상태 모니터링

10.3 Logs 수집 흐름

구성 요소

•

FluentBit DaemonSet

•

Loki

•

S3

로그 흐름

Container stdout/stderr
→ Fluentbit
→ Loki → S3
→ Grafana
Plain Text
복사

Fluentbit 주요 필터

•

JSON Log Parser

•

Level 필터

10.4 Tracing 수집 흐름

Tracing은 Envoy(네트워크 레벨) + Application(비즈니스 레벨) 모두 수집하며, OTel Collector를 거쳐 Tempo에 저장

10.4.1 Envoy → Tempo(Zipkin)

Envoy가 Zipkin 포맷으로 Trace 생성

•

Istio Proxy(Envoy)는 Zipkin 포맷 Trace를 기본 지원

•

Ingress Gateway, Sidecar 모두 Span 생성

OTel Collector가 Zipkin 포맷 수신

•

Collector의 Zipkin Receiver가 Envoy에서 보낸 데이터를 수신

•

내부적으로 OTLP로 변환 → Tempo로 Export

Collector에서 Tempo로 Export

데이터 흐름

Envoy (Zipkin)
→ OTel Collector (zipkin receiver)
→ OTel Collector (otlp exporter)
→ Tempo
→ Grafana
Plain Text
복사

10.4.2 Application → Tempo (OTLP)

Java 서비스를 OpenTelemetry Java Agent로 구성하여 OTLP/gRPC로 Trace 전송

Application (OTLP → grpc)
→ OTel Collector (otlp receiver)
→ Tempo (otlp exporter)
→ Grafana
Plain Text
복사

10.4.3 End-to-End 트레이싱

Envoy Span과 Application Span은 동일 Trace ID를 공유하여 하나의 전체 트랜잭션 흐름으로 결합된다.

11. 고가용성 & 장애 복구 전략

•

EKS Multi-AZ NodeGroup 운영

•

RDS Multi-AZ Failover

•

Redis Multi-AZ

•

ArgoCD Rollback

•

S3 Versioning

•

Terraform 기반 인프라 re-provision

12. 비용 관리 전략

항목	전략
EKS	NodeGroup 온디맨드 최소 유지 + Karpenter 자동 확장
Node	Consolidation으로 Idle Node 최소화
NAT Gateway	Dev/Stage 최소 구성
CloudWatch Logs	15일 보관
Redis	ClusterMode Off
MSK	결제 서비스 중심 최소 구성
ECR	Private ECR 사용