ADR-06: PaaS 우선 인프라 전략
| 날짜 | 작성자 | 리포지토리 |
|---|---|---|
| 2024-12-17 | @KubrickCode | All |
배경
문제 정의
모든 소프트웨어 팀은 근본적인 인프라 결정에 직면한다: 운영 책임을 얼마나 직접 맡을 것인가 vs 관리형 플랫폼에 위임할 것인가. 이 결정은 다음에 큰 영향을 미친다:
- 리소스 배분: 인프라 vs 제품 개발에 투입하는 시간
- 필요 역량: 팀 내 DevOps 전문성 요구 수준
- 비용 구조: 운영 비용 vs 플랫폼 수수료
- 아키텍처 유연성: 커스터마이징 가능 범위 vs 플랫폼 제약
인프라 스펙트럼
| 접근법 | 운영 부담 | 유연성 | 대규모 비용 |
|---|---|---|---|
| 베어메탈 | 매우 높음 | 최대 | 가장 낮음 |
| IaaS (VM) | 높음 | 높음 | 낮음 |
| Kubernetes | 중상 | 높음 | 중간 |
| PaaS (관리형) | 낮음 | 제한적 | 높음 |
| 서버리스 | 최소 | 가장 제한 | 변동적 |
핵심 의사결정 요소
- 팀 규모 및 구성: 가용한 DevOps 전문성
- 제품 성숙도: 요구사항과 아키텍처의 안정성
- 트래픽 패턴: 워크로드의 예측 가능성과 규모
- 시간 제약: 출시 속도 요구사항
- 예산 모델: CapEx vs OpEx 선호도
핵심 질문
전담 인프라 인력이 없는 팀에서, 운영 안정성을 유지하면서 제품 개발 속도를 극대화하려면 인프라 전략을 어떻게 접근해야 하는가?
결정
PaaS 우선 인프라 전략 채택. 자체 관리 인프라보다 관리형 서비스 우선.
핵심 원칙:
- 운영 오버헤드 최소화: 인프라 관리를 플랫폼 제공자에게 위임
- 제품에 집중: 엔지니어링 시간을 인프라가 아닌 제품 기능에 투입
- 트레이드오프 수용: 복잡도 감소 대가로 더 높은 단위 비용 인정
- 이식성 유지: 컨테이너화된 워크로드로 마이그레이션 옵션 확보
검토한 옵션
옵션 A: PaaS / 관리형 서비스 (선택)
인프라 운영을 처리하는 관리형 플랫폼에 서비스 배포.
장점:
- 최소한의 운영: 서버 패치, OS 업데이트, 인프라 유지보수 불필요
- 빠른 배포: Git-push 배포 워크플로우, 즉시 롤백
- 내장 기능: 통합 로깅, 모니터링, SSL 인증서, CDN
- 자동 스케일링: 수동 개입 없이 트래픽 급증 처리
- 개발자 경험: 단순한 멘탈 모델, 낮은 인지 부하
- 예측 가능한 비용: 명확한 가격 모델, 예상치 못한 인프라 비용 없음
단점:
- 높은 단위 비용: 원시 컴퓨팅 대비 관리형 서비스 프리미엄
- 플랫폼 제약: 제한된 커스터마이징, 고정된 런타임 환경
- 벤더 종속 리스크: 플랫폼 특화 기능이 전환 비용 발생
- 제한된 제어: 인프라 수준 최적화 불가
- 이그레스 비용: 데이터 전송 비용 누적 가능
- 기능 제한: 고급 네트워킹, 커스텀 커널 등 사용 불가
옵션 B: IaaS 직접 관리
클라우드 제공자의 가상 머신을 프로비저닝하고 인프라를 직접 관리.
장점:
- 완전한 제어: OS, 네트워킹, 보안의 완전한 커스터마이징
- 비용 효율: 특히 대규모에서 낮은 단위 비용
- 플랫폼 제약 없음: 어떤 소프트웨어 스택, 어떤 설정도 가능
- 최적화 가능: 특정 워크로드 특성에 맞춤 튜닝
- 멀티 클라우드 준비: 표준 VM은 제공자 간 이식 가능
단점:
- 운영 부담: 패칭, 모니터링, 보안, 백업, 스케일링
- 전문성 필요: 전담 DevOps 지식 필요
- 느린 이터레이션: 더 많은 설정과 유지보수 오버헤드
- 보안 책임: 하드닝과 컴플라이언스에 대한 전적인 책임
- 용량 계획: 리소스를 미리 예측하고 프로비저닝해야 함
옵션 C: Kubernetes (관리형 또는 자체 관리)
Kubernetes 클러스터에 컨테이너화된 워크로드 배포.
장점:
- 오케스트레이션 파워: 고급 스케줄링, 자가 치유, 롤링 업데이트
- 이식성: 동일한 매니페스트가 어떤 Kubernetes 클러스터에서도 작동
- 생태계: 서비스 메시, 관측성, GitOps를 위한 풍부한 도구
- 스케일 효율: 워크로드의 최적 빈 패킹
- 업계 표준: 광범위한 채택, 큰 인재 풀
단점:
- 복잡성: 가파른 학습 곡선, 많은 움직이는 부품
- 운영 오버헤드: 관리형 Kubernetes도 상당한 전문성 필요
- 리소스 오버헤드: 컨트롤 플레인 비용, 최소 클러스터 크기 요구사항
- 소규모에서 과잉: 상당한 규모까지 이점이 실현되지 않음
- YAML 난립: 클러스터 크기에 따라 설정 복잡도 증가
결과
긍정적
최대화된 제품 집중
- 엔지니어링 시간을 인프라가 아닌 기능에 투입
- 운영 방해 없이 빠른 이터레이션 사이클
- 개발과 운영 간 컨텍스트 스위칭 감소
낮은 진입 장벽
- 시작에 DevOps 전문성 불필요
- 새 팀원이 즉시 생산적
- 문서와 지원이 쉽게 이용 가능
운영 안정성
- 플랫폼 제공자가 가용성과 이중화 처리
- 자동 페일오버와 복구
- 전문 인프라 팀 없이 전문가급 인프라
예측 가능한 속도
- 배포 복잡성 제거
- 스테이징과 프로덕션 간 일관된 환경
- 내장 CI/CD 통합
부정적
비용 프리미엄
- 원시 인프라보다 높은 리소스당 비용
- 사용량에 따라 선형 증가 (볼륨 할인 없음)
- 완화: 사용량 모니터링, 애플리케이션 효율 최적화, 규모 임계점에서 재평가
벤더 종속
- 플랫폼 특화 기능이 마이그레이션 마찰 발생
- 가격 변경이 예상치 못하게 예산에 영향
- 완화: 워크로드 컨테이너화, 플랫폼 특화 추상화 회피, 탈출 전략 유지
제한된 커스터마이징
- 특정 요구에 맞게 인프라 튜닝 불가
- 고정된 런타임 환경과 제약
- 완화: 충분한 유연성 있는 플랫폼 선택, 블로커를 플랫폼 제공자에 에스컬레이션
아키텍처 제약
- 일부 패턴이 PaaS에서 불가능하거나 비용이 높음
- 네트워크 토폴로지 제한
- 완화: 플랫폼 제약 내에서 설계, 엣지 케이스에 대안 평가
기술적 영향
| 영역 | 영향 |
|---|---|
| 배포 | Git-push 워크플로우, 플랫폼 네이티브 CI/CD |
| 모니터링 | 플랫폼 제공 관측성, 외부 APM 필요할 수 있음 |
| 스케일링 | 자동 수평 스케일링, 수직 스케일링은 제한적일 수 있음 |
| 네트워킹 | 플랫폼 관리 로드 밸런싱, 커스텀 네트워킹 제한 |
| 데이터 영속성 | 관리형 데이터베이스 권장, 스테이트풀 워크로드 제약 |
| 비용 모델 | 사용량 기반 가격, 예측 가능하나 잠재적으로 높음 |
| 마이그레이션 | 컨테이너화가 다른 플랫폼으로의 이식성 보존 |
재고가 필요한 시점
- 인프라 비용이 동등한 전담 DevOps 인건비를 초과할 때
- 플랫폼 제약이 핵심 기능 구현을 막을 때
- 트래픽 패턴이 사용량 기반 가격을 비효율적으로 만들 때
- 팀이 전담 인프라 전문성을 갖추게 될 때
- 컴플라이언스 요구사항이 인프라 수준 제어를 요구할 때
- 성능 요구사항이 플랫폼 역량을 초과할 때