시작하며
최근 마이크로서비스 아키텍처를 운영하면서 서비스 간 통신 관리가 점점 복잡해지고 있었습니다. 특히 트래픽이 증가하면서 라우팅, 장애 처리, 보안 정책을 각 서비스마다 구현하는 것이 큰 부담이 되더라고요.
그러던 중 STCLab의 기술 블로그에서 Istio를 활용한 고트래픽 서비스 관리 사례를 접하게 되었습니다. 수백만 동시 접속을 처리하는 환경에서 실제로 사용하는 패턴들이 소개되어 있어서, 이를 분석하고 배운 점들을 공유해보려고 합니다.
이 글에서는 다음 내용을 다룹니다:
- Istio의 핵심 개념과 아키텍처
- 실무에서 유용한 트래픽 관리 패턴
- 대규모 환경에서의 확장 전략
- 보안 시스템 연계 방안
Istio와 Envoy: 기본 개념 이해하기
Istio는 무엇인가요?
Istio는 **서비스 메시(Service Mesh)**입니다. API Gateway와 비슷해 보이지만, 외부 트래픽만 관리하는 것이 아니라 마이크로서비스 간 내부 통신까지 전반적으로 제어한다는 점에서 차이가 있습니다.
쉽게 비유하자면, API Gateway는 건물 정문의 보안 데스크라면, Istio는 건물 안 모든 층과 방을 연결하는 스마트 네트워크 시스템이라고 할 수 있습니다.
두 가지 핵심 구성 요소
1. Control Plane (제어 플레인) - 두뇌 역할
Istio의 설정을 관리하는 중앙 관제센터입니다. 우리가 작성한 VirtualService, DestinationRule 같은 설정들을 받아서 Envoy가 이해할 수 있는 형태로 변환해줍니다.
중요한 점은 Control Plane은 실제 트래픽을 처리하지 않는다는 것입니다. 단지 교통 신호를 관리하는 관제센터 역할만 하죠.
2. Data Plane (데이터 플레인) - Envoy Proxy
실제 트래픽이 지나가는 통로입니다. 각 서비스 파드 옆에 사이드카(Sidecar) 형태로 배포되어, 들어오고 나가는 모든 트래픽을 가로채서 처리합니다.
┌─────────────────────────────────────┐
│ Istio Control Plane │
│ (istiod - 설정 관리자) │
└─────────────────┬───────────────────┘
│ 설정 전달
├─────────┬─────────┬──────────
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Pod 1 │ │ Pod 2 │ │ Pod 3 │
│ ┌─────┐ │ │ ┌─────┐ │ │ ┌─────┐ │
│ │ App │ │ │ │ App │ │ │ │ App │ │
│ └──┬──┘ │ │ └──┬──┘ │ │ └──┬──┘ │
│ ┌──▼──┐ │ │ ┌──▼──┐ │ │ ┌──▼──┐ │
│ │Envoy│ │ │ │Envoy│ │ │ │Envoy│ │
│ └─────┘ │ │ └─────┘ │ │ └─────┘ │
└─────────┘ └─────────┘ └─────────┘
Envoy Proxy가 특별한 이유
Envoy는 C++로 작성된 고성능 프록시로, 다음과 같은 특징이 있습니다:
- L7 프로토콜 지원: HTTP, gRPC, WebSocket 등을 네이티브로 처리
- 동적 설정: 서비스 재시작 없이 실시간으로 설정 변경 가능
- 풍부한 기능: Circuit Breaking, Retry, Timeout, Rate Limiting 등이 기본 탑재
- 상세한 메트릭: 각 요청마다 지연 시간, 에러율 등을 자동 수집
STCLab이 Istio를 선택한 이유는 Istio의 간단한 설정으로 대부분을 해결하고, 필요할 때만 EnvoyFilter로 세밀하게 제어할 수 있기 때문이라고 합니다. (대신 학습 곡선이 어렵다는 단점이 있습니다.)
핵심 용어: 테넌트(Tenant)
이 글에서 자주 등장하는 **테넌트(Tenant)**는 멀티테넌시 아키텍처에서 하나의 시스템을 사용하는 독립적인 고객 단위를 의미합니다.
예를 들어:
- SaaS 플랫폼에 A회사, B회사, C회사가 가입
- 각 회사는 별도의 테넌트로 취급
- 데이터와 설정이 서로 완전히 격리됨
STCLab의 가상 대기실 플랫폼에서는 각 고객사가 하나의 테넌트이고, 각 테넌트마다 독립적인 대기열을 관리합니다.
실무 패턴 1: 쿼리 파라미터 기반 라우팅
어떤 문제를 해결하나요?
STCLab의 가상 대기실 서비스는 큐 상태를 메모리에 저장합니다. 만약 같은 테넌트의 요청이 서로 다른 파드로 분산되면 큐 정보가 일치하지 않게 됩니다.
문제 시나리오:
테넌트 A의 사용자가 대기 중 (instance-1에서는 100번째)
→ 다음 요청이 instance-2로 가면?
→ instance-2에는 테넌트 A 정보가 없음!
→ 사용자가 처음부터 다시 대기해야 함
해결 방법: Sticky Routing
쿼리 파라미터를 통해 특정 인스턴스를 명시적으로 지정합니다:
# VirtualService 설정
http:
- match:
- queryParams:
sticky:
exact: "instance-1"
route:
- destination:
host: queue-service
subset: instance-1
실제 요청 예시:
GET /api/queue?sticky=instance-1&tenant_id=company-a
# → 항상 instance-1 파드로 라우팅됨
왜 이 방식을 선택했을까요?
STCLab 팀은 자동 해싱 대신 명시적 라우팅을 선택했습니다. 그 이유는:
1. 결정론적 라우팅
- 클라이언트가 정확히 어느 인스턴스로 가는지 알 수 있음
- 디버깅 시 특정 인스턴스 로그만 확인하면 됨
2. 디버그 격리
- 문제가 있는 테넌트를 특정 인스턴스로 라우팅
- 다른 테넌트에게 영향 없이 조사 가능
3. 점진적 마이그레이션
- 유지보수 시 일부 테넌트만 새 인스턴스로 이동
- 문제 발생 시 즉시 롤백 가능
대안: Consistent Hash
엄격한 일관성이 필요 없는 보조 서비스에는 Consistent Hash를 사용합니다:
# DestinationRule 설정
trafficPolicy:
loadBalancer:
consistentHash:
httpQueryParameterName: tenant_id
이 방식은 tenant_id가 같으면 자동으로 같은 백엔드로 라우팅되지만, 클라이언트가 sticky 파라미터를 명시할 필요가 없다는 장점이 있습니다.
내 프로젝트와 비교해보기
내가 사용한 방식: 경로 기반 라우팅
제 프로젝트의 VirtualService 설정은 다음과 같습니다:
# URL 경로별로 다른 서비스로 라우팅
- match:
- uri:
prefix: /api/svc/auth
route:
- destination:
host: auth-service
port:
number: 8080
- match:
- uri:
prefix: /api/svc/user
route:
- destination:
host: user-service
port:
number: 8081
목적: API Gateway 역할 - 단일 진입점에서 여러 마이크로서비스로 분산
STCLab 방식과의 차이
구분 내 방식 STCLab 방식
| 라우팅 기준 | URL 경로 (/api/svc/auth) | 쿼리 파라미터 (?sticky=instance-1) |
| 타겟 | 서로 다른 서비스 | 같은 서비스의 특정 인스턴스 |
| 목적 | 서비스 간 트래픽 분산 | 인스턴스별 세션 일관성 유지 |
| 사용 사례 | 마이크로서비스 라우팅 | 메모리 기반 상태 관리 |
Canary 배포는 또 다른 개념
제 설정에 있는 Canary 배포도 자주 헷갈리는 부분인데요:
# Canary 배포 설정
- destination:
host: auth-service
subset: stable
weight: 90
- destination:
host: auth-service
subset: canary
weight: 10
이것은 신규 버전을 점진적으로 출시하기 위한 것으로:
- 사용자는 선택할 수 없고 랜덤하게 분산됨
- 가중치 기반으로 트래픽 비율 조절
- 버전 간 안정성 비교가 목적
반면 STCLab의 쿼리 기반 라우팅은:
- 클라이언트가 명시적으로 인스턴스 선택
- 같은 버전의 서로 다른 인스턴스 구분
- 상태 일관성 유지가 목적
완전히 다른 용도라는 걸 알게 되었습니다.
실무 패턴 2: Outlier Detection으로 자동 장애 격리
문제 상황
운영하다 보면 이런 경우가 생깁니다:
10개의 파드 중 1개가 메모리 누수로 계속 5xx 에러 발생
→ 로드밸런서가 계속 요청을 보냄
→ 사용자의 10%가 에러를 경험함
→ 수동으로 파드를 찾아서 재시작해야 함
Outlier Detection: 문제 파드 자동 격리
Istio는 문제가 있는 파드를 자동으로 감지하고 트래픽에서 제외합니다:
# DestinationRule 설정
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 5 # 연속 5회 5xx 에러
interval: 10s # 10초마다 체크
baseEjectionTime: 30s # 최소 30초간 제외
maxEjectionPercent: 50 # 최대 50%만 제외
동작 방식
- 파드가 연속으로 5번 5xx 에러 발생
- Envoy가 해당 파드를 라우팅에서 일시적으로 제외
- 30초 후 다시 헬스체크 시도
- 여전히 문제가 있으면 계속 제외, 정상이면 복귀
실제 효과
STCLab 블로그의 사례를 보면:
- 배포 중 한 파드가 크래시 루프에 진입
- Outlier Detection이 50초 내에 자동으로 제거
- 트래픽이 정상 파드로 이동
- 수동 개입이 전혀 필요 없었음
아직까지 실질적으로 운영을 해보진않았지만 이 부분이 가장 인상적이었습니다. 자동화의 중요성을 실감할 수 있었습니다.
주의사항: Outlier Detection은 파드를 삭제하는 게 아니라 트래픽만 차단합니다. 파드는 그대로 실행 중이며, 로그를 확인하거나 디버깅할 수 있습니다.
실무 패턴 3: Graceful Shutdown으로 무중단 배포
문제 상황
제 프로젝트는 실시간 채팅과 알림 기능이 있습니다. WebSocket 연결은 보통 10분 이상 유지되는데, 배포할 때마다 연결이 끊기는 문제가 있었습니다:
배포 시작
→ 파드가 바로 종료됨
→ WebSocket 연결 강제 종료
→ 사용자들이 채팅방에서 튕겨남
→ 불만 접수
해결책: Graceful Shutdown 설정
핵심 원칙: terminationGracePeriodSeconds > terminationDrainDuration
# Deployment 설정
spec:
template:
spec:
terminationGracePeriodSeconds: 660 # Kubernetes 강제 종료 대기
containers:
- name: istio-proxy
env:
- name: TERMINATION_DRAIN_DURATION_SECONDS
value: "600" # Envoy가 기존 연결 유지
- name: EXIT_ON_ZERO_ACTIVE_CONNECTIONS
value: "true" # 연결 없으면 조기 종료
종료 과정 타임라인
t=0초 파드가 SIGTERM 신호 수신
↓
Envoy: 새 연결 거부 시작
Envoy: 헬스체크 실패 응답
(다른 파드로 신규 트래픽 이동)
↓
t=0~600초 기존 연결은 계속 유지
(채팅, WebSocket 등 정상 작동)
↓
t=600초 모든 연결이 정상 종료되거나 타임아웃
(조기 종료 옵션 활성화 시 더 빨리 종료 가능)
↓
t=660초 Kubernetes가 SIGKILL 전송 (강제 종료)
적용 결과
이 설정을 적용한 후:
- 배포 중 연결 끊김 0건
- 롤링 업데이트 중에도 부하 테스트 통과
- 사용자 불만이 사라짐
특히 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 옵션이 유용했습니다. 대부분의 연결이 1-2분 내에 자연스럽게 종료되면서, 전체 배포 시간도 단축되었습니다.
Outlier Detection vs Graceful Shutdown: 헷갈리기 쉬운 두 기능
처음에는 두 기능이 비슷해 보였는데, 완전히 다른 목적을 가지고 있었습니다:
구분 Outlier Detection Graceful Shutdown
| 언제 작동하나 | 파드가 에러를 반복할 때 | 파드가 종료될 때 |
| 무엇을 하나 | 트래픽 라우팅에서 제외 | 기존 연결을 유지하며 종료 |
| 파드 상태 | 계속 실행 중 (디버깅 가능) | 점진적으로 종료됨 |
| 복구 여부 | 자동 복구 (30초 후 재시도) | 복구 없음 (종료 완료) |
| 목적 | 장애 파드 자동 격리 | 무중단 배포 |
쉬운 비유:
- Outlier Detection: 식당에서 음식을 계속 태우는 요리사를 잠시 쉬게 하는 것 (나중에 다시 투입)
- Graceful Shutdown: 폐업하는 식당이 마지막 손님들의 식사가 끝날 때까지 기다리는 것 (영구 종료)
보안 강화: 실제 클라이언트 IP 보존과 IDS/IPS 연계
왜 실제 IP가 중요한가요?
AWS NLB나 로드밸런서를 거치면 원본 클라이언트 IP가 사라지고, 로드밸런서의 IP로 대체됩니다:
실제 상황:
클라이언트 IP: 203.0.113.100 (실제 공격자)
→ NLB 통과
→ 서버가 보는 IP: 10.0.1.5 (NLB 내부 IP)
→ 모든 요청이 같은 IP로 보임!
이렇게 되면:
- 봇 탐지 불가능 (모든 요청이 같은 IP)
- Rate Limiting 무용지물
- 공격자 추적 불가능
Proxy Protocol로 IP 보존
# EnvoyFilter 설정
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: proxy-protocol
spec:
configPatches:
- applyTo: LISTENER
patch:
operation: MERGE
value:
listener_filters:
- name: envoy.filters.listener.proxy_protocol
이 설정으로 실제 클라이언트 IP가 X-Envoy-External-Address 헤더에 저장됩니다.
중요: X-Forwarded-For는 클라이언트가 조작할 수 있지만, X-Envoy-External-Address는 Envoy가 직접 설정하므로 위조 불가능합니다.
IDS/IPS 시스템 연계
실제 IP를 보존하면 다양한 보안 시스템을 구축할 수 있습니다:
1. IP 기반 접근 제어
# AuthorizationPolicy로 사무실 IP만 허용
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: office-only
spec:
action: DENY
rules:
- from:
- source:
notRemoteIpBlocks: ["203.0.113.0/24"] # 사무실 IP 대역
Swagger 문서나 내부 API는 이런 식으로 보호할 수 있습니다.
2. Rate Limiting (IP별 요청 제한)
# IP별로 초당 요청 수 제한
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: rate-limit-by-ip
spec:
configPatches:
- applyTo: HTTP_FILTER
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.ratelimit
typed_config:
domain: bot-protection
rate_limit_service:
grpc_service:
cluster_name: rate-limit-service
Rate Limit 서비스가 할 수 있는 일:
- IP당 초당 요청 수 제한
- 비정상적 패턴 감지 (1초에 100번 요청)
- 지역별 접근 제어 (특정 국가 차단)
3. 실시간 위협 분석 파이프라인
Envoy (Proxy Protocol)
→ Access Log 수집 (Fluent Bit)
→ SIEM (Elasticsearch/Splunk)
→ 이상 패턴 탐지 (ML 기반)
→ 자동 차단 (AuthorizationPolicy 업데이트)
실제 시나리오:
- 공격자가 유출된 계정으로 로그인 시도 (IP: 198.51.100.50)
- 애플리케이션 로그: Failed login attempts 1000회 (5분 내)
- SIEM이 이상 패턴 감지
- 자동으로 해당 IP를 차단 목록에 추가
- 추가 공격 차단
이런 자동화 시스템 없이 실제 IP 정보가 없다면, 보안 팀이 수동으로 로그를 분석하고 차단해야 합니다.
대규모 트래픽 환경: Istio는 어떻게 확장되나요?
질문: 트래픽이 10배 증가하면 Istio도 10배 늘려야 하나요?
처음에는 당연히 그래야 할 것 같았는데, 실제로는 아닙니다.
Istio의 스케일링 아키텍처
┌──────────────────────────────────────┐
│ Istio Control Plane (1개 or 3개) │ ← 전체 메시 관리
│ - istiod │
└──────────────────────────────────────┘
│ 설정 전달
├────────┬────────┬────────┬─── ...
▼ ▼ ▼ ▼
┌────────┐┌────────┐┌────────┐┌────────┐
│ Pod 1 ││ Pod 2 ││ Pod 10 ││ Pod 100│
│+ Envoy ││+ Envoy ││+ Envoy ││+ Envoy │
└────────┘└────────┘└────────┘└────────┘
핵심은 Control Plane은 그대로, Data Plane만 자동으로 증가한다는 것입니다.
1. Control Plane 스케일링
기본 구성: istiod 1개로도 수천 개의 서비스 관리 가능
왜 그럴까요?
- Control Plane은 실제 트래픽을 처리하지 않음
- 설정 변경 시에만 Envoy와 통신
- CPU/메모리 사용량이 서비스 개수에 비례 (트래픽 양과 무관)
고가용성(HA) 구성:
# istiod를 3개로 증가 (장애 대응용)
replicas: 3
하지만 트래픽이 증가한다고 해서 Control Plane을 더 늘릴 필요는 없습니다.
2. Data Plane 자동 확장
핵심 원리: Envoy Sidecar는 애플리케이션 파드와 1:1로 배포됩니다.
# board-service를 3개로 스케일 아웃
apiVersion: apps/v1
kind: Deployment
metadata:
name: board-service
spec:
replicas: 3 # 파드 3개 → Envoy도 자동으로 3개!
자동 관리:
- Kubernetes가 파드를 늘리면 → Istio가 자동으로 Envoy Sidecar 주입
- HPA(Horizontal Pod Autoscaler)로 트래픽에 따라 자동 스케일
- 각 Envoy는 독립적으로 동작
3. HPA와의 통합
시나리오: 일일 방문자가 100만 명에서 1000만 명으로 증가
# HPA 설정
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
scaleTargetRef:
name: board-service
minReplicas: 3
maxReplicas: 100 # 트래픽에 따라 자동 증가
metrics:
- type: Resource
resource:
name: cpu
target:
averageUtilization: 70
결과:
- 파드 3개 → 100개 자동 증가
- Envoy도 3개 → 100개 자동 증가
- Control Plane은 그대로 (설정만 100개 파드에 전달)
4. 리소스 오버헤드
실제 사례:
- 애플리케이션 파드: 500m CPU, 512Mi RAM
- Envoy Sidecar 추가: +100m CPU, +128Mi RAM
- 총 오버헤드: 약 20% 증가
생각보다 부담이 크지 않았습니다. Envoy가 제공하는 기능을 생각하면 충분히 감수할 만한 수준이라고 느꼈습니다.
5. 대규모 환경 최적화 팁
메트릭 카디널리티 제어:
Envoy는 엄청나게 많은 메트릭을 생성합니다. 모두 수집하면 Prometheus가 다운될 수 있어요:
# 필요한 메트릭만 수집
meshConfig:
defaultConfig:
proxyStatsMatcher:
inclusionRegexps:
- "cluster\\..*" # cluster 관련 메트릭만
Connection Pool 조정:
# DestinationRule
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1000 # 파드당 최대 연결 수
http:
http2MaxRequests: 1000
이런 설정을 통해 리소스를 효율적으로 관리할 수 있습니다.
요약: Istio는 수평 확장에 최적화됨
✅ 좋은 점:
- 파드만 늘리면 Envoy도 자동으로 증가
- Control Plane은 트래픽과 무관하게 안정적
- HPA와 완벽히 통합
- 수동 관리 거의 불필요
⚠️ 주의할 점:
- 파드당 약 20% 리소스 오버헤드
- 메트릭 폭발 방지 필요 (Prometheus 과부하)
- EnvoyFilter는 업그레이드 시 호환성 체크 필수
결론적으로 Istio를 여러 개 띄울 필요가 없고, 파드 수만 늘리면 됩니다.
참고: Istio Ambient 모드
최근에는 Sidecar 없이 작동하는 Ambient 모드도 등장했습니다. 리소스 오버헤드를 더 줄일 수 있다고 합니다. 저번에 진행했던 프로젝트에서 처음에 Ambient 모드를 도입해서 사용했는데, 결과적으로 트래픽 분리나 이런 기술들에 대해서 잘 알려진게 없다보니 sidecar 방식으로 진행하였습니다.
운영하면서 배운 점들
1. 간단하게 시작하세요
처음에는 Istio의 모든 기능(mTLS, Distributed Tracing, Circuit Breaker)을 켜고 싶었습니다. 하지만 STCLab 블로그의 조언대로 비즈니스 가치가 명확할 때만 추가했습니다.
실제로 처음 1개월은 기본 라우팅과 Outlier Detection만 사용했고, 나머지는 천천히 추가했습니다. 덕분에 학습 부담도 줄고, 문제 발생 시 디버깅도 쉬웠습니다.
2. 메트릭 관리가 중요합니다
Envoy가 생성하는 메트릭 양이 상상 이상이었습니다. 한번은 Prometheus가 OOM(Out Of Memory)으로 다운된 적도 있습니다.
해결책:
- 필요한 메트릭만 선별적으로 수집
- inclusionRegexps로 필터링
- Grafana 대시보드도 너무 많은 시계열을 한번에 로딩하지 않도록 조정
++ 프로메테우스의 pod을 늘리고 타노스를 적용하는것도 좋은 방법이 될 수 있다고 생각했습니다.
3. EnvoyFilter는 신중하게
EnvoyFilter는 강력하지만 Istio 업그레이드 시 깨질 수 있습니다.
Istio 1.18 → 1.20 업그레이드
→ 일부 EnvoyFilter의 API가 deprecated됨
→ 트래픽 라우팅 일부가 작동 안 함
→ 급하게 롤백
교훈:
- EnvoyFilter 사용 시 반드시 문서화
- 업그레이드 전 호환성 체크 필수
- 가능하면 VirtualService, DestinationRule 같은 고수준 API 사용
마치며
Istio는 분명히 학습 곡선이 있습니다. 처음에는 개념도 낯설고, 설정도 복잡하게 느껴졌습니다. 하지만 고트래픽 환경에서 제공하는 가치는 투자할 만하다고 생각합니다.
이런 경우라면 Istio를 고려해보세요:
- 마이크로서비스 간 복잡한 트래픽 제어가 필요할 때
- 자동화된 장애 복구가 중요할 때
- 보안 정책을 중앙에서 관리하고 싶을 때
- 상세한 가시성과 추적이 필요할 때
특히 STCLab의 사례처럼 메모리 기반 상태 관리나 실시간 통신 서비스를 운영한다면, Istio의 세밀한 라우팅과 Graceful Shutdown 기능이 큰 도움이 될 것입니다.
참고 자료
'Network' 카테고리의 다른 글
| Terraform으로 EC2 관리하면서 겪은 AMI 필터링과 SSM 연결 이슈 (0) | 2026.02.25 |
|---|---|
| Kind 클러스터에서 SandboxChanged 에러 해결하기: systemd와 containerd의 갈등 해소 (1) | 2026.01.20 |
| EKS에서 ArgoCD로 GitOps 구축하기: 순환 의존성 해결부터 Single Sync까지 (0) | 2026.01.05 |
| 실전 Kubernetes 보안: 4C 모델을 프로덕션 클러스터에 적용하며 배운 것들 (0) | 2026.01.04 |
| GitHub Actions Docker CI 파이프라인 구조 이해하기: 멀티 아키텍처 빌드부터 캐시 전략 (1) | 2026.01.03 |