EKB - AWS EKS (서비스 및 인프라) 가이드
이 문서는 EKB 서비스 인프라의 AWS 아키텍처에 대한 포괄적인 개요를 제공합니다. 이 아키텍처는 AWS 매니지드 서비스, Kubernetes 오케스트레이션 및 자동 스케일링을 활용하는 클라우드 네이티브 패턴을 따릅니다.
AWS 아키텍처 개요
이 아키텍처는 AWS 매니지드 서비스, Kubernetes 오케스트레이션 및 자동 스케일링을 활용하는 클라우드 네이티브 패턴을 따릅니다.
아키텍처 다이어그램
flowchart TD
INTERNET["🌐 INTERNET"]
DNS["DNS Provider
(Route 53 / Cloudflare / etc.)
──────────────────────────────
• app.your-domain — Web Frontend
• api.your-domain — FastAPI Backend
• automations.your-domain — Automator
• supabase.your-domain — Supabase Kong
• signoz.your-domain — SigNoz"]
ALB["APPLICATION LOAD BALANCER
──────────────────────────────
• SSL Termination via ACM
• HTTP → HTTPS Redirect
• Health Checks & Target Groups
• Routing by hostname/path"]
subgraph VPC["VPC"]
subgraph PUB["Public Subnets (3 AZs)"]
NAT["NAT Gateway × 3"]
end
subgraph PRIV["Private Subnets (3 AZs)"]
NODES["EKS Worker Nodes"]
end
end
subgraph EKS["EKS CLUSTER"]
KARPENTER["KARPENTER — Dynamic Node Provisioning
──────────────────────────────
• Spot prioritisation & consolidation
• Interruption handling via SQS
• Node classes: general, compute-intensive, database"]
KEDA["KEDA — Event-driven Pod Autoscaling
──────────────────────────────
• CPU / Memory threshold scaling
• Fast scale-down stabilisation"]
PODS["APPLICATION PODS
──────────────────────────────
• Web Frontend (port 3000)
• FastAPI Backend (port 8001)
• Celery Workers
• Automator (port 80)
• Supabase services (Kong, Auth, Storage…)
• PostgreSQL Automator (port 5432)"]
SIGNOZ["OBSERVABILITY — SigNoz (optional)
──────────────────────────────
• Distributed tracing, metrics, logs
• k8s-infra agent for cluster metrics"]
end
subgraph DATA["DATA LAYER"]
REDIS["ELASTICACHE
(Redis)
──────────
• Encryption
• Multi-AZ
• Port 6379"]
MQ["AMAZON MQ
(RabbitMQ)
──────────
• Async queue
• AMQP/SSL
• Port 5671"]
SUPABASE["SUPABASE
(DB / Auth)
──────────
Option A: Cloud
Option B: Self-hosted
via CNPG HA on EKS"]
end
INTERNET --> DNS
DNS --> ALB
ALB --> VPC
PUB --> PRIV
PRIV --> EKS
EKS --> DATA
정보
셀프호스팅 Supabase는 CloudNativePG가 관리하는 HA PostgreSQL 클러스터(ha-supabase-db)와 PgBouncer 풀링, 객체 스토리지를 위한 MinIO, 그리고 helm-deployment/supabase-kubernetes-ha를 통해 배포되는 전체 Supabase 애플리케이션 스택을 사용합니다. 셀프호스팅이 필요하지 않은 경우 Supabase Cloud가 대안입니다.
주요 구성 요소
1. 네트워킹 레이어
DNS Provider
- 목적: 도메인 이름 해석; 모든 제공자와 함께 작동 (Route 53, Cloudflare 등)
- 도메인 (자신의 도메인을 사용하세요, 예:
example.com):app.example.com— Web Frontendapi.example.com— FastAPI Backendautomations.example.com— Automator Servicesupabase.example.com— Supabase Kong (셀프호스팅 전용)signoz.example.com— SigNoz 관측 가능성 (선택 사항)
- SSL 검증: ACM DNS 검증에 필요한 CNAME 레코드
Application Load Balancer (ALB)
- 목적: SSL 종료, 로드 밸런싱 및 호스트명 기반 라우팅
- 기능:
- ACM 인증서를 사용한 SSL/TLS 종료 (와일드카드 또는 서비스별)
- HTTP → HTTPS 리다이렉트
- 모든 대상 그룹에 대한 헬스 체크
- 관리 주체: AWS Load Balancer Controller (
helm-deployment/infrastructure의 Helm 차트)
VPC
- CIDR: 환경별 설정 (예:
10.x.0.0/16) - 가용 영역: 선택한 리전에 3개 AZ
- 서브넷: 퍼블릭 3개 (NAT Gateway용) + 프라이빗 3개 (EKS 노드용)
- 아웃바운드: 각 AZ별 NAT Gateway로 노드 아웃바운드 트래픽 처리
2. 컴퓨팅 레이어
EKS 클러스터
- 버전: Kubernetes 1.33
- System Node Group: Karpenter 컨트롤러를 실행하는 매니지드 노드 그룹 (AWS 모범 사례에 따라 Karpenter가 관리하는 노드에는 실행되지 않음)
- 애드온: EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy
Karpenter — 동적 노드 프로비저닝
- 목적: 적시 노드 프로비저닝 및 비용 최적화
- 노드 클래스:
- 범용: 대부분의 워크로드용 Spot 인스턴스
- 컴퓨팅 집약적: CPU 바인드 작업용 고CPU 인스턴스
- 메모리 집약적: 대규모 데이터셋용 메모리 최적화 인스턴스
- 데이터베이스: 상태형/데이터베이스 워크로드용 온디맨드 인스턴스
- GPU: AI/ML 워크로드용 GPU 인스턴스 (선택 사항)
- 기능: Spot 우선순위화, 자동 통합, SQS 기반 중단 처리
KEDA — Kubernetes 이벤트 기반 자동 스케일링
- 목적: 리소스 메트릭 기반 수평 Pod 스케일링
- 대상:
| 서비스 | 복제본 수 | CPU 임계값 | 메모리 임계값 |
|---|---|---|---|
| Web Frontend | 2–8 | 60% | 80% |
| FastAPI Backend | 2–10 | 70% | 80% |
| Celery Workers | 2–8 | 70% | 80% |
| Automator | 2–8 | 70% | 80% |
- 스케일 다운: 빠른 응답을 위한 30초 안정화 윈도우
3. 애플리케이션 서비스
Web Frontend
- 포트: 3000
- 복제본 수: 2–8 (KEDA 관리)
- 목적: 사용자 인터페이스를 제공하는 React 애플리케이션
FastAPI Backend
- 포트: 8001
- 복제본 수: 2–10 (KEDA 관리)
- 목적: 비즈니스 로직과 데이터 접근을 처리하는 REST API 서버
Celery Workers
- 복제본 수: 2–8 (KEDA 관리)
- 목적: 백그라운드 작업 처리 (RabbitMQ를 통해 큐잉)
Automator Service
- 포트: 80
- 복제본 수: 2–8 (KEDA 관리)
- 목적: 워크플로우 자동화 및 오케스트레이션
Supabase Kong
- 포트: 8000 (내부 클러스터 서비스)
- 목적: 모든 Supabase 서비스를 위한 API 게이트웨이
- 라우팅:
odin-services/main-ingress.yaml에 정의된 ALB 인그레스를 통해 외부 트래픽이 Kong에 도달
SigNoz (선택 사항)
- 네임스페이스:
monitoring - 구성 요소: SigNoz 플랫폼 + k8s-infra DaemonSet 에이전트
- 목적: 분산 추적, 메트릭 집계, 로그 관리
- 활성화:
ENABLE_SIGNOZ=true
4. 데이터 레이어
ElastiCache Redis
- 목적: 캐싱, 세션 저장 및 Celery 브로커/결과 백엔드
- 설정:
- 노드 유형: 구성 가능 (예:
cache.t3.micro) - 포트:
6379-静态 저장소 및 전송 중 암호화 - 고가용성을 위한 Multi-AZ
- 노드 유형: 구성 가능 (예:
- 활성화:
ENABLE_AWS_SERVICES=true
Amazon MQ (RabbitMQ)
- 목적: 비동기 작업 처리를 위한 메시징 큐
- 설정:
- 엔진: RabbitMQ
- 포트:
5671(AMQP/SSL),15671(Management/SSL) - 배포 모드: 단일 인스턴스 또는 액티브/스탠바이
- 활성화:
ENABLE_AWS_SERVICES=true
Supabase — 옵션 A: 클라우드 (매니지드)
- 목적: 외부 매니지드 PostgreSQL, Auth, Storage 및 Realtime
- 연결:
values/odin-services.yaml에 설정된 Supabase 프로젝트 URL 및 서비스 역할 키
Supabase — 옵션 B: EKS에서 셀프호스팅
- 목적: 클러스터 내부에서 실행되는 전체 Supabase 스택
- 구성 요소:
- CloudNativePG 오퍼레이터 (
cnpg-system) — Postgres 클러스터 생명주기 관리 - HA Supabase DB (
ha-supabase-db) — PgBouncer 풀러가 포함된 CloudNativePG 클러스터 리소스 - Supabase 애플리케이션 (
supabase네임스페이스) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
- CloudNativePG 오퍼레이터 (
- 배포 순서: CloudNativePG → HA Supabase DB → Supabase 앱
- 활성화:
ENABLE_CNPG=true,ENABLE_HA_SUPABASE_DB=true,ENABLE_SUPABASE=true
PostgreSQL Automator
- 목적: Automator 서비스를 위한 로컬 PostgreSQL 데이터베이스
- 포트: 5432
- 스토리지: EBS 퍼시스턴트 볼륨
- 노드 어피니티: 데이터베이스 전용 노드
5. 보안 및 IAM
IAM 역할
| 역할 | 목적 |
|---|---|
| EKS Cluster Role | 클러스터 수준 API 권한 |
| Node Group Role | EC2 노드 권한 (ECR, SSM, 네트워킹) |
| Karpenter Controller Role | EC2 프로비저닝, SQS 중단 큐 |
| AWS Load Balancer Controller Role | ELBv2 및 EC2 관리 |
| EBS CSI Driver Role | EBS 볼륨 생명주기 관리 |
역할 이름은 <env-name>-<component> 패턴을 따르며 EKS Terraform 모듈에 의해 생성됩니다.
보안 그룹
- ALB: AWS Load-balancer Controller에 의해 자동 생성 (80/443 인바운드)
- EKS Cluster: 노드 간 및 Pod 간 통신
- Redis: VPC CIDR에서만 포트 6379 허용
- RabbitMQ: VPC CIDR에서만 포트 5671, 15671 허용
SSL/TLS
- 종료: ALB 수준 (Pod는 내부에서 일반 HTTP를 수신)
- 인증서: ACM 인증서 — 서비스별 또는 단일 와일드카드
- 검증: DNS 제공자를 통한 DNS CNAME 검증
- 최소 프로토콜: TLS 1.2
6. 인프라 코드
Terraform 모듈
modules/eks: EKS 클러스터, VPC, 노드 그룹, Karpenter, IAM, Helm 릴리스- 상태: 버전 관리가 활성화된 S3 버킷, DynamoDB 잠금 테이블
Terragrunt
- 환경 격리:
terragrunt/environments/아래 환경별 디렉토리 - 템플릿:
env-template-folder— 새 환경을 생성하려면 복사하여 플레이스홀더를 채우세요 - DRY 구성: 환경별 오버라이드가 포함된 공유
root.hcl - 활성화/비활성화 플래그: 환경 변수를 통해 서비스 토글 (
ENABLE_*)
Helm 차트
| 차트 | 네임스페이스 | 설명 |
|---|---|---|
infrastructure | infrastructure | ALB Controller |
odin-services | default | Web, API, Workers, Automator, Ingress |
aws-ebs-csi-driver | kube-system | EBS 볼륨 프로비저닝 |
keda | keda | Pod 자동 스케일링 |
cloudnative-pg | cnpg-system | PostgreSQL 오퍼레이터 |
ha-supabase-db | ha-supabase-db | HA Postgres 클러스터 + PgBouncer |
supabase-kubernetes-ha | supabase | 전체 Supabase 스택 |
signoz | monitoring | 관측 가능성 플랫폼 |
k8s-infra | monitoring | 클러스터 메트릭 에이전트 |
데이터 흐름
1. 사용자 요청 흐름
User → DNS → ALB (SSL termination) → EKS Pod (Web Frontend)
→ EKS Pod (FastAPI Backend)
→ EKS Pod (Supabase Kong)
- 사용자가
app.example.com에 접속 - DNS가 ALB를 가리키도록 해석
- ALB가 SSL을 종료하고 호스트명에 따라 올바른 대상 그룹으로 라우팅
- Web Frontend가 React 앱을 제공하고
api.example.com에 API 호출 - FastAPI Backend가 요청을 처리하고 데이터 서비스에 읽기/쓰기
2. API 요청 흐름
Client → ALB → FastAPI Backend → Redis (cache) / RabbitMQ (queue) / Supabase (DB)
- 클라이언트가
api.example.com을 호출 - ALB가 FastAPI Pod로 라우팅
- 백엔드가 Redis 캐시를 확인; 미스 시 Supabase 데이터베이스를 쿼리
- 비동기 작업이 RabbitMQ에 큐잉되고 Celery Workers에 의해 처리
3. 백그라운드 처리 흐름
FastAPI → RabbitMQ → Celery Worker → Supabase DB
- FastAPI가 RabbitMQ에 작업을 큐잉
- Celery Worker가 작업을 디큐잉하고 처리
- 결과가 Supabase 데이터베이스에 다시 기록
4. Automator 워크플로우
Automator → PostgreSQL (local) → Redis → External APIs
- Automator가 워크플로우 요청을 수신
- 워크플로우 상태가 로컬 PostgreSQL 인스턴스에 저장
- Redis가 중간 결과를 캐싱
- 외부 API가 자동화의 일부로 호출
5. 스케일링 흐름
Metrics → KEDA → Pod scaling → Karpenter → Node provisioning
- KEDA가 구성된 임계값에 따라 CPU/메트릭을 평가
- Pod가 구성된 복제본 수 범위 내에서 수평 스케일링
- 클러스터 용량이 부족하면 Karpenter가 새 EC2 노드를 프로비저닝 (Spot 우선)
- 부하가 감소하면 KEDA가 Pod를 스케일 다운; Karpenter가 유휴 노드를 통합하고 종료
6. 보안 흐름
Internet → ALB (TLS 1.2+, ACM) → Security Groups → Pods → IAM IRSA roles → AWS APIs
- 모든 외부 트래픽이 ALB에서 TLS를 종료
- 보안 그룹이 최소 권한 네트워크 접근을 적용
- Pod가 IRSA (IAM Roles for Service Accounts)를 통해 AWS 서비스와 통신
고가용성 요약
| 기능 | 구현 |
|---|---|
| 멀티 AZ 배포 | EKS 노드, Redis, 서브넷에 3개 AZ |
| 로드 밸런싱 | 다수의 대상 그룹을 포함한 ALB |
| Pod 중복성 | 서비스당 최소 2개 복제본 |
| 데이터베이스 HA | CloudNativePG 클러스터 + PgBouncer (셀프호스팅) 또는 Supabase Cloud |
| 캐시 중복성 | ElastiCache Multi-AZ |
| 노드 자동 스케일링 | Spot + 온디맨드 혼합을 사용하는 Karpenter |
| Pod 자동 스케일링 | KEDA CPU/메모리 기반 |
| 관측 가능성 | SigNoz (선택 사항) |
| 상태 관리 | 버전 관리가 포함된 S3 + DynamoDB 잠금 |
비용 최적화
- Spot 인스턴스: Karpenter는 모든 비데이터베이스 워크로드에 대해 Spot을 우선시
- 노드 통합: Karpenter가 미사용 노드를 자동으로 회수
- Pod 적정 크기 조정: KEDA가 유휴 기간에 Pod를 스케일 다운
- 필요한 곳에만 온디맨드: 데이터베이스 노드 클래스는 안정성을 위해 온디맨드 사용
유지보수 및 운영
배포 프로세스
cd terragrunt/environments/<your-env-name>
# 필요한 ENABLE_* 및 도메인/인증서 환경 변수를 설정하세요
terragrunt apply
# 롤링 업데이트: 이미지 태그 또는 values 파일을 업데이트한 후 다시 적용하세요
전체 배포 절차는 Terragrunt 배포 가이드를 참조하세요.
백업 전략
- EBS 스냅샷: 퍼시스턴트 볼륨(Automator DB, Supabase MinIO)에 대한 자동 스냅샷
- CloudNativePG: 지속적인 WAL 아카이빙 + 예약된 기본 백업 (구성된 경우)
- Supabase Cloud: 매니지드 일일 백업 (클라우드 옵션)
- IaC 상태: 버전 관리된 S3 버킷
재해 복구
- 멀티 AZ: 모든 상태형 서비스가 여러 가용 영역에 걸쳐 분산
- CloudNativePG HA: Postgres 프라이머리와 복제본 간 자동 페일오버
- Supabase Cloud: 크로스 리전 중복성 (클라우드 옵션)
- Terraform 상태: S3 버전 관리를 통해 이전 상태로의 롤백 가능