0. 문제
클라우드 컴퓨팅 서비스를 제공하는 사업자는 이용자에게 신뢰성과 일관된 품질을 제공하기 위해 클라우드 컴퓨팅 SLA(Service Level Agreement) 적용이 필수적이다.
**클라우드 서비스 유형별(IaaS, PaaS, SaaS)**로 서비스 품질 요소(성능, 가용성, 보안, 서비스 제공성)에 대해 설명하시오. (25점)
1. 서론: 정의 + 배경 + 출현 이유
(1) SLA 정의
**SLA(Service Level Agreement)**는 클라우드 서비스 제공자와 이용자 간에 서비스 품질 보장에 대한 계약적 합의로, 성능, 가용성, 보안, 지원 등 서비스 수준 기준과 책임범위를 명확히 정의함.
(2) 배경 및 출현 이유
- 클라우드 서비스는 인터넷 기반의 비가시적 자원에 의존하기 때문에 품질, 신뢰성, 책임에 대한 명확한 기준이 필요함
- SLA는 서비스 이용자의 권리 보호, 성능 기대 충족, 장애 발생 시 보상 기준 마련 등을 위해 필수
- 클라우드 유형에 따라 서비스 범위가 다르므로, SLA 항목도 유형별로 차별화되어야 함
2. 본론: 서비스 유형별 품질 요소 설명
🔹 (1) IaaS (Infrastructure as a Service)
: 가상머신, 네트워크, 스토리지 등 인프라 자원을 제공
| 품질 요소 | 설명 |
|---|---|
| 성능 | - CPU, Memory, Disk IO, Network Bandwidth 등 자원 성능의 예측 가능성 - 고성능 컴퓨팅(HPC) 지원 여부, 스토리지 IOPS 보장 |
| 가용성 | - 가상머신 가동 시간(Uptime), 다중 리전 및 AZ(Availability Zone) 구성 가능성 - SLA 기준: 99.9% 이상 가동 시간 보장 |
| 보안 | - VM 간 격리, 가상 네트워크 방화벽, 암호화 저장소 지원 - ID 기반 접근 제어(IAM), 로그 추적 가능 여부 |
| 서비스 제공성 | - API 기반의 자원 자동 생성, 오토스케일링 - 인프라 확장/복구의 신속성, 리소스 할당 속도 |
🔧 예시: AWS EC2, Azure VM, Google Compute Engine 등
🔹 (2) PaaS (Platform as a Service)
: 개발과 배포를 위한 플랫폼 환경을 제공
| 품질 요소 | 설명 |
|---|---|
| 성능 | - 애플리케이션 런타임 성능 (빌드 속도, 실행 시간 등) - 미들웨어 성능, DB 처리 성능 |
| 가용성 | - 플랫폼 서비스(예: DBaaS, 메시징 서비스)의 장애 내성 - 자동 백업/복구 기능 여부 |
| 보안 | - 코드 실행 샌드박싱, API 키 관리 - 플랫폼 레벨의 취약점 자동 패치, 인증 모듈 연동(OAuth, SSO 등) |
| 서비스 제공성 | - CI/CD 연동성, 템플릿 기반 배포 속도 - 멀티 언어 및 프레임워크 지원, 확장성 유연성 |
🔧 예시: AWS Elastic Beanstalk, Heroku, Azure App Service, Google App Engine
🔹 (3) SaaS (Software as a Service)
: 최종 사용자를 위한 완전한 애플리케이션 서비스 제공
| 품질 요소 | 설명 |
|---|---|
| 성능 | - 응답 시간(페이지 로딩, 검색 속도 등), 트랜잭션 처리율 - 사용자 수 증가에 따른 자동 확장 |
| 가용성 | - 웹 UI/모바일 앱의 정상 접근 가능성 - 서비스 중단 시 RTO, RPO 보장 여부 |
| 보안 | - 사용자 데이터 격리, GDPR/ISMS 등 규정 준수 - 사용자 인증/접근제어, 2FA 등 |
| 서비스 제공성 | - 사용자 계정 관리, 고객 지원 채널, UI 사용 편의성 - 사용량 통계, API 제공 등 확장성 |
🔧 예시: Google Workspace, Microsoft 365, Salesforce, Slack, Notion
3. 결론: 실제 적용 방안 + 고려사항 + 제언
(1) 실제 적용 방안
- 클라우드 서비스 계약 시 SLA 기준을 명확히 정의하고, 서비스 유형에 맞는 항목별 품질 보장치를 확인해야 함
- SLA 문서에는 가용성 보장(예: 99.99%), 장애 복구 시간(RTO/RPO), 보상 조건, 대응 절차 등을 포함
(2) 고려사항
- SLA는 단순한 기술 문서가 아닌 법적 효력을 가지는 계약 문서로, 측정 기준, 예외 조건, 이행 방식까지 명확히 해야 함
- 서비스 유형에 따라 **고객 책임 모델(Shared Responsibility Model)**이 다르므로, 보안/가용성 범위도 세심히 검토 필요
(3) 제언
- SLA 기준이 미흡하면 장애나 성능 저하 시 분쟁의 원인이 되므로, 도입 초기부터 정량화된 품질 지표 설정이 중요
- 멀티 클라우드나 하이브리드 환경에서는 각 벤더의 SLA 조율 및 통합 모니터링 체계 구축이 필요함
- 특히 보안이나 가용성이 중요한 경우 SLA 준수 모니터링 시스템 구축도 병행되어야 함
✅ 요약 비교
| 구분 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 제공 범위 | 인프라 자원 | 개발 플랫폼 | 최종 애플리케이션 |
| SLA 핵심 요소 | CPU/네트워크, Uptime | 실행 성능, 자동화 | 응답 시간, 사용자 편의 |
| 고객 책임 | 가장 큼 | 중간 | 가장 적음 |
| 보안 통제 범위 | OS/앱 직접 관리 | 일부 관리 | 벤더 전담 |
DevSecOps ⚙️ + Pentest 🚩