소개
클라우드 인프라는 애플리케이션 요구사항(성능, 가용성, 비용, 보안)에 따라 다양한 설계 선택을 요구한다. 이 글에서는 장기간 유효한 핵심 개념을 정리하고, 설계 시 흔히 맞닥뜨리는 트레이드오프를 설명한 뒤, 실무에서 바로 적용 가능한 간단한 예제를 보여준다.
핵심 개념 정리
아래는 클라우드 인프라 설계에서 반복적으로 등장하는 안정적이고 범용적인 개념들이다.
지역(Region)과 가용영역(AZ)
지역은 물리적 지리 단위이고, 가용영역은 동일 지역 내 독립 전력·네트워크 인프라를 갖춘 데이터센터 그룹이다. 높은 가용성을 원하면 서비스와 데이터를 여러 AZ에 분산해야 하고, 지연(latency)과 규제(compliance) 요구사항을 고려해 지역을 선택해야 한다.
네트워킹
VPC(가상 네트워크), 서브넷, 라우팅, 방화벽(네트워크 ACL/보안 그룹) 설계는 보안과 성능에 직접 영향을 준다. 네트워크 설계는 다음을 고려한다: 퍼블릭/프라이빗 분리, 트래픽 경로 최소화, 서비스 디스커버리와 DNS 구성, 내부 통신 암호화(서비스 메쉬 등).
컴퓨트: VM vs 컨테이너 vs 서버리스
가상머신(VM)은 세밀한 제어와 기존 레거시 앱에 적합하다. 컨테이너는 빠른 배포와 밀도 높은 리소스 사용에 유리하고, 서버리스는 관리 부담을 크게 줄여준다. 선택은 운영 역량, 비용 모델, 성능 요구사항에 따라 달라진다.
스토리지 유형
블록 스토리지(디스크형)는 데이터베이스 등 지연 민감 작업에 적합하다. 객체 스토리지는 대용량 정적 파일과 백업에 좋고, 파일 스토리지는 공유 파일시스템이 필요한 워크로드에 적합하다. 일관성(consistency), 지연, 스냅샷/복제 요구사항을 기준으로 선택한다.
아이덴티티와 접근 제어
권한 최소화(Principle of Least Privilege), 역할 기반 접근 제어(RBAC), 키 관리(KMS), 감사로그는 보안의 핵심이다. 자동화된 비밀관리(Secret Manager) 사용을 권장한다.
관찰성(Observability)
로깅, 메트릭, 트레이싱을 통해 시스템 상태와 이상 징후를 빠르게 감지·대응할 수 있다. 알림(페이지)과 런북을 마련해 운영의 신뢰도를 높여야 한다.
설계 시 주요 트레이드오프
아래 항목들은 설계자가 빈번히 맞닥뜨리는 트레이드오프다.
비용 vs 성능
고성능 인스턴스와 고가용성 구성(다중 AZ/지역)은 비용을 증가시킨다. 예산 제약이 있다면 캐싱, 스케줄링된 비활성 리소스 종료, 예약 인스턴스 등으로 절감할 수 있다. 반대로 성능 우선인 경우에는 비용을 받아들이고 더 넉넉한 리소스와 더 가까운 지역을 선택해야 한다.
관리형 서비스 vs 자체 운영
관리형 데이터베이스나 컨테이너 관리 서비스(Managed Kubernetes)는 운영 부담을 줄여주지만 비용이 더 들 수 있다. 자체 운영은 유연성이 크지만 운영 인력과 책임이 필요하다. 조직의 운영 역량과 장기 TCO로 판단한다.
일관성 vs 가용성
분산 스토리지나 DB를 설계할 때 일관성 모델(강한 일관성 vs 최종적 일관성)과 가용성(Partition Tolerance)을 균형 있게 고려해야 한다. 트랜잭션 일관성이 필수라면 중앙집중형 또는 강한 일관성 설정을 사용해야 한다. 반대로 읽기 우선성과 지연 개선이 필요하면 캐시와 최종적 일관성을 사용한다.
멀티-클라우드 vs 싱글-클라우드
멀티-클라우드는 공급자 종속성(locks-in)을 줄이고 재해 복구에 유리하지만 운영 복잡도가 증가한다. 싱글-클라우드는 단순하고 통합된 관리가 가능하지만 공급자 장애에 더 취약하다. 서비스 중요도에 따라 선택한다.
실무 예제: Kubernetes에 간단한 웹 서비스 배포 (가용성 + 오토스케일)
아래 예제는 Kubernetes 클러스터에 stateless 웹 애플리케이션을 배포하고, 로드밸런서 서비스와 Horizontal Pod Autoscaler(HPA)를 설정하는 간단한 매니페스트다. 이는 클라우드 환경(대부분의 managed Kubernetes)에서 바로 적용 가능한 패턴이다.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web
image: nginx:stable
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: web-lb
spec:
type: LoadBalancer
selector:
app: web-app
ports:
- port: 80
targetPort: 80
---
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
이 구성의 운영상 고려사항:
- 다중 AZ에서 클러스터 노드가 분포되도록 프로비저닝(클라우드 공급자의 노드 그룹/인스턴스 그룹 설정).
- Pod 간 비즈니스 트래픽 암호화를 위해 네트워크 폴리시나 서비스 메쉬 적용 고려.
- 상태 저장이 필요한 경우에는 외부 관리형 데이터베이스나 지속성 스토리지(PV/PVC) 사용을 권장.
- 오토스케일은 애플리케이션의 스타트업 지연(startup latency)을 고려해 설정해야 한다(빠른 스파이크에 과다 확장/축소를 피함).
운영 체크리스트(짧게)
클라우드 인프라를 운영할 때 빠르게 검토할 항목들:
- 백업 및 복구 절차(주기/복구 시간 목표 RTO, 복구 지점 목표 RPO).
- 모니터링·알림, 런북(incident playbook).
- 비용 모니터링과 태깅 정책(resource tagging).
- 보안: IAM 정책, 네트워크 경계, 비밀 관리.
- 정기적인 복원력 테스트(장애 주입·DR 테스트).
마무리
클라우드 인프라 설계는 단기 유행 기능에 따라 바뀌지 않는 기본 원칙과, 특정 비즈니스 요구에 맞춘 트레이드오프의 균형을 맞추는 작업이다. 위의 핵심 개념과 트레이드오프를 바탕으로 작은 실험(예: PoC)을 통해 운영 비용과 가용성의 균형을 검증한 뒤 점진적으로 확장하는 방식을 권장한다.