클라우드 서비스란?
- 인터넷을 통해 컴퓨팅 자원, 데이터 저장, 소프트웨어, 플랫폼 등의 IT 관련 서비스를 원격으로 제공하는 서비스
- 클라우드 서비스를 이용하면 하드웨어와 소프트웨어를 구입하거나 유지 관리할 필요 없이 컴퓨팅 리소스를 활용 가능
클라우스 서비스의 모델
IaaS (Infrastructure as a Service)
- 클라우드를 통해 컴퓨팅, 스토리지, 네트워킹, 가상화와 같은 주문형 인프라 리소스를 조직에 제공
- 고객이 자체 데이터 센터 인프라를 관리, 유지 관리 또는 업데이트 할 필요는 없지만 운영체제, 미들웨어, 가상 머신, 앱 또는 데이터를 책임 짐
인프라(Infrastructure)란?
- IT에서 인프라란 컴퓨터 시스템을 운영하기 위한 기반 시설
- 쉽게 말해, 컴퓨터가 제대로 작동하도록 돕는 필수 장비들
Ex)
▶ 컴퓨터 자체: CPU, 메모리, 하드디스크, 네트워크 카드 등
▶ 데이터 저장 공간: 데이터를 저장하는 큰 창고(서버)
▶ 네트워크: 인터넷에 연결될 수 있는 선과 연결 장치
▶ 전기와 냉각 시스템: 서버를 시원하게 유지하고, 전원을 공급
좀 더 간단한 설명
- IaaS란 인프라(서버, 저장 공간, 네트워크)를 인터넷을 통해 빌려주는 서비스를 의미
- 전통적인 방식
- 회사마다 컴퓨터, 서버, 저장 장치를 직접 사고 유지
- 서버가 고장나면 직접 고쳐야하고, 서버를 둘 공간도 필요하고, 비용도 많이 듦
- IaaS 방식
- 컴퓨터나 서버 같은 인프라를 클라우드 회사가 대신 관리
- 사용자는 인터넷으로 필요한 만큼만 사용하고 돈을 지불
집을 빌리는 개념으로 비유
- 옛날 방식(전통적 방식)
- 집(서버)을 직접 구매하고 관리, 수리, 청소도 모두 해야 함
- 이사 가고 싶으면 새 집을 또 구매
- IaaS 방식(클라우드)
- 필요한 집을 렌트해서 사용
- 주인이(클라우드 제공자) 관리와 수리를 다 해주고 나는 필요한 방(컴퓨팅 파워, 저장 공간)만 사용
- 즉, 전통적인 방식은 집을 매매한 것이라면 IaaS 방식은 월세 또는 전세로 생각할 수 있음
책임 | 관리 |
데이터 센터(서버 방), 전기, 인터넷 연결 | IaaS 제공자 |
컴퓨터(서버), 저장 공간, 네트워크 | IaaS 제공자 |
운영체제(OS), 애플리케이션, 데이터 | 사용자 |
IaaS의 예시
- 구글 드라이브처럼 파일 저장 공간을 인터넷에서 빌려 쓰는 것
- AWS EC2 : 아마존의 가상 서버
- Microsoft Azure Virtual Machines : 가상 컴퓨터 빌리기
CaaS (Containers as a Service)
- 컨테이너를 사용하여 애플리케이션을 개발 및 배포하기 위해 필요한 모든 하드웨어 및 소프트웨어 리소스를 제공 및 관리
- 경우에 따라 IaaS의 하위 집합 또는 확장 서비스로 간주되기도 하는 CaaS는 기본 리소스로 VM 대신 컨테이너를 사용
- 개발자 및 IT 운영팀은 CaaS를 사용할 경우 컨테이너 실행 및 관리를 위한 인프라 또는 플랫폼을 빌드하고 유지보수할 필요 없이 애플리케이션을 개발, 실행, 관리 가능
- 고객은 여전히 코드를 작성하고 데이터와 애플리케이션을 관리해야 하지만, 클라우드 서비스 제공업체에서 컨테이너화된 앱을 빌드하고 배포하는 환경을 관리하고 유지관리
컨테이너(Container)란?
- 애플리케이션이 실행되기 위한 모든 환경(코드, 라이브러리, 설정 파일 등)을 한 "박스" 안에 담아둔 것
- 이 박스를 사용하면 애플리케이션이 어디서든(서버, 개발자 컴퓨터, 클라우드) 실행 가능
Ex) Docker 컨테이너
좀 더 간단한 설명
- 컨테이너(Container)라는 기술을 클라우드에서 빌려 쓸 수 있게 해주는 서비스
- 컨테이너 : 도시락 박스처럼, 애플리케이션 실행에 필요한 모든 걸 담아둔 '박스'
- 도시락 안에 음식(코드), 포크와 젓가락(라이브러리), 소스(설정 파일) 등으로 구성
- CaaS : 도시락 박스를 빌리고, 관리할 수 있는 플랫폼
- 내가 원하는 도시락을 주문하면, CaaS 서비스가 박스를 준비해서 나에게 보내 줌
- 도시락 박스는 관리가 쉽고, 어디서든 바로 먹을 수 있음
직접 요리와 배달 음식으로 비유
- 전통적인 방식 : 직접 요리해서 먹기
- 시장에 가서 재료를 구매
- 조리도구(서버)도 직접 관리
- 음식을 옮기려면 큰 냄비를 들고 가야 함
- CaaS 방식: 도시락 배달 서비스
- 내가 원하는 음식을 도시락으로 만들어서 가져다 줌
- 어디서든 바로 먹을 수 있음 (= 애플리케이션 실행 가능)
- 관리나 세부적인 조리는 배달 업체(CaaS 서비스 제공자)가 알아서 함
CaaS의 예시
- AWS Elastic Kubernetes Service (EKS) : 컨테이너 관리 서비스
- Google Kubernetes Engine (GKE) : 구글의 컨테이너 관리 플랫폼
- Azure Kubernetes Service (AKS) : 마이크로소프트의 컨테이너 서비스
PaaS (Platform as a Service)
- 클라우드를 통해 애플리케이션을 개발하는 데 필요한 모든 하드웨어 및 소프트웨어 리소스를 제공하고 관리
- 개발자와 IT 운영팀은 인프라 또는 플랫폼을 자체적으로 빌드하고 유지관리할 필요 없이 PaaS를 사용하여 애플리케이션을 개발, 실행, 관리 가능
- 고객은 여전히 코드를 작성하고 데이터와 애플리케이션을 관리해야 하지만, 클라우드 서비스 제공업체에서 앱을 빌드하고 배포하는 환경을 관리하고 유지관리
좀 더 간단한 설명
- 애플리케이션을 개발하고, 실행하고, 관리할 수 있는 플랫폼(환경)을 클라우드에서 제공하는 서비스
- 즉, 개발자가 코딩에만 집중할 수 있게 개발 환경(운영체제, 데이터베이스, 개발 툴 등)을 제공
- 서버, 네트워크, 운영체제 관리 같은 귀찮은 일은 PaaS 제공자가 알아서 처리
피자 만들기에 비유
- 전통적인 방식 : 집에서 피자 전부 만들기
- 피자 도우부터 소스, 치즈, 토핑까지 전부 직접 준비하고, 오븐도 직접 돌려야 함
- 준비도 오래 걸리고, 맛있게 만들려면 전문 기술도 필요
- PaaS 방식 : 반조리 피자 키트
- 반조리 피자 키트를 제공받으면, 도우, 소스, 치즈, 기본 토핑은 이미 준비된 상태
- 내가 할 일은 토핑을 추가하거나 굽기만 하면 끝
- PaaS에서의 역할 분담
- PaaS 제공자 : 운영체제, 데이터베이스, 서버 환경, 배포 도구 같은 기본 "피자 도우와 소스"를 준비
- 개발자(사용자) : 애플리케이션 코드, 커스터마이징(특별한 토핑)을 추가
비교 항목 | 전통적인 방식 | PaaS 방식 |
설치 / 준비 | 서버, 운영체제, 데이터베이스, 네트워크 직접 설정 | 이미 준비된 개발 환경 제공 |
관리 | 운영체제 업데이트, 서버 관리, 보안 등 직접 처리 | PaaS 제공자가 알아서 처리 |
개발 초점 | 개발 외에 인프라와 환경 설정도 신경 써야 함 | 개발에만 집중 가능 |
비용 | 처음부터 전부 다 준비하느라 초기 비용이 큼 | 사용한 만큼만 비용 지불, 초기 비용이 적음 |
PaaS의 예시
- Heroku : 웹 애플리케이션을 쉽게 개발, 배포할 수 있는 플랫폼
- Google App Engine : 구글의 클라우드 플랫폼으로 개발 환경 제공
- AWS Elastic Beanstalk : 애플리케이션을 쉽게 배포하고 관리할 수 있는 AWS 서비스
SaaS (Software as a service)
- 전체 애플리케이션 스택, 즉 고객이 액세스하고 사용할 수 있는 전체적인 클라우드 기반 애플리케이션을 제공
- 서비스 제공업체가 전적으로 관리하며 모든 업데이트, 버그 수정, 전반적인 유지보수를 포함하며 즉시 사용 가능
- 대부분의 SaaS 애플리케이션은 웹브라우저를 통해 직접 액세스
→ 즉, 고객이 다른 기기에 어떤 것도 다운로드하거나 설치할 필요가 없음
좀 더 간단한 설명
- 인터넷을 통해 소프트웨어를 서비스로 제공하는 것
- 소프트웨어를 다운로드하거나 설치할 필요 없이 웹 브라우저에서 로그인해서 바로 사용
- 구글 드라이브, Gmail, 슬랙 같은 서비스가 SaaS
피자 배달에 비유
- 전통적인 방식 : 집에서 피자 만들기
- PaaS와 마찬가지로 직접 모든 재료 등을 준비해서 만들어야 함
- SaaS 방식: 완제품 피자 배달 서비스
- SaaS는 완전히 구워진 피자를 배달받는 것
- 내가 할 일은 피자를 주문하고, 도착한 피자를 먹는 것이 전부
- Ex) 배달 앱에서 피자를 시키면 조리, 배달까지 완료
비교 항목 | 전통적인 방식 | SaaS 방식 |
설치 / 준비 | 소프트웨어를 구매하고, 설치하고, 업데이트까지 직접 관리 | 소프트웨어를 설치할 필요 없이 로그인해서 바로 사용 |
관리 | 하드웨어, 소프트웨어 업데이트와 보안 관리 모두 필요 | 서비스 제공자가 모든 관리 처리 |
사용법 | 사용하기까지 많은 시간과 설정이 필요 | 인터넷만 있으면 어디서든 바로 사용 가능 |
비용 | 소프트웨어를 한 번에 구매하는 초기 비용이 큼 | 월 구독료 같은 방식으로 저렴하게 사용 가능 |
SaaS의 예시
- 개인 사용자 : Gmail, Google Docs, Netflix
- 기업 사용자 : Slack, Salesforce, Zoom, Microsoft 365
- Google Workspace (Gmail, Google Drive, Google Docs) : 인터넷만 있으면 어디서든 문서 작성, 이메일 확인이 가능
- Netflix : 영화를 다운로드하지 않아도, 스트리밍으로 바로 감상 가능
- Salesforce : 기업용 CRM(고객 관계 관리) 시스템으로 고객 데이터를 관리할 수 있음
PaaS와 SaaS의 차이
- PaaS : 내가 피자를 완성하려면 토핑을 얹고 굽는 것까지는 해야 함
- SaaS : 완성된 피자를 배달받아 바로 먹으면 됨
클라우드 서비스 모델의 주요 차이점
- 클라우드 컴퓨팅에서 각 모델들의 차이점을 한 마디로 요약하면 제어와 책임의 수준
- 다음의 그림에서 파란색은 사용자가 관리해야할 부분, 초록색은 클라우드 제공자가 관리해야할 부분
클라우드와 다양한 모델 옵션은 집과 연관 지어 생각
- 온프레미스
- 집을 처음부터 새로 짓기로 결정했다면 모든 것을 직접 함
- 원자재와 공구를 마련하고, 모든 것을 조립하고, 필요한 물건이 있을 때마다 매장으로 달려가서 사와야 함
- 이는 하드웨어부터 애플리케이션에 이르기까지 모든 것을 소유하는 온프레미스에서 애플리케이션을 실행하고 확장하는 것과 비슷
- IaaS (Infrastructure as a Service)
- 바쁘다면 대신 일해줄 도급업자를 고용하는 것이 좋음
- 원하는 집의 모습과 방 개수를 알려주면 도급업자는 지시에 따라 집을 지음
- 애플리케이션에 대한 IaaS도 마찬가지
- 하드웨어를 대여하여 애플리케이션을 실행하지만 OS, 런타임, 확장 및 모든 데이터를 관리할 책임은 본인에게 있음
- Ex) Compute Engine
- CaaS (Containers as a service)
- 집을 구매할 때 뒤따르는 유지보수가 부담스러운 경우 대여를 선택 가능
- 기본 설비는 포함되어 있고 가구를 직접 들여놓고 공간을 꾸밈
- 컨테이너를 사용하면 컨테이너화된 애플리케이션을 도입할 수 있으므로 기본 운영체제에 대해 걱정할 필요 없이 규모와 런타임을 제어 가능
- Ex) Google Kubernetes Engine(GKE)
- PaaS (Platform as a Service)
- 거주 공간의 가구 배치를 걱정하지 않으려면 가구가 배치된 집을 대여 가능
- PaaS를 사용하면 자신의 코드를 가져와서 배치하지만 서버 관리와 확장은 클라우드 제공업체에 맡길 수 있음
- Ex) App Engine, Cloud Run
- FaaS (Function as a Service)
- 집에서 멀리 떨어져서 일하기 위해 작은 전용 공간이 필요하면 공동 작업 공간에서 책상 하나를 임대 가능
- FaaS를 사용하면 특정 태스크(작업)를 수행하는 작은 코드 또는 함수를 빌드하고 배포 가능
- 클라우드 제공업체는 함수가 실행될 때 필요에 따라 확장을 추가
- Ex) Cloud Functions
- SaaS (Software as a Service)
- 건축이 완료된 집을 임대하거나 구입하여 이사간다고 가정
- 하지만 이번에는 청소나 잔디 관리 등의 유지 비용을 지불
- SaaS도 이와 동일
- 클라우드 제공업체가 관리, 유지보수, 보호하는 완전한 애플리케이션을 특정 목적으로 사용하기 위해 비용을 지불
- 하지만 자신의 데이터 관리는 자신이 책임
- Ex) Google Workspace
각 모델의 장단점
모델 | 장점 | 단점 |
IaaS | ▶ 인프라에 대한 제어 수준이 가장 높음 ▶ 필요에 따라 확장 가능 ▶ 단일 장애점이 없어 안정성이 높은 편임 ▶ 초기 자본 지출 감소(예: 사용한 만큼만 지불) ▶ 프로비저닝 지연과 리소스 낭비 감소 ▶ 개발 및 TTM(time to market) 가속화 |
▶ 자체 데이터 보안 및 복구에 대한 책임 ▶ 직접 구성하고 유지보수해야 함 ▶ 클라우드 기반 인프라에서 기존 애플리케이션을 보호하기 어려움 |
CaaS | ▶ 마이크로서비스 실행, 관리, 확장에 이상적 ▶ 개발 간소화로 TTM(time to market) 단축 ▶ 네트워크 및 애플리케이션 구성요소의 제어 및 구성 세분화 ▶ 하이브리드 클라우드 및 멀티 클라우드와 같은 환경 간 워크로드 이동성 증가 ▶ 성능 모니터링 및 컨테이너 조정 기본 제공 |
▶ 클라우드 서비스 제공업체에 따라 일부 CaaS 솔루션에 제공되는 언어 지원이 제한적 ▶ CaaS를 사용할 경우 OS와 동일한 커널을 공유하므로(VM보다 안전하다고 간주되지만) 컨테이너 보안 위험이 증가할 수 있음 |
PaaS | ▶ 완전하고 사용하기 쉬운 개발 플랫폼에 즉시 액세스 가능 ▶ 유지보수 및 인프라 보안을 책임 지는 클라우드 서비스 제공업체 ▶ 모든 기기에서 모든 인터넷 연결을 통해 사용 가능 ▶ 필요에 따라 확장 가능 |
▶ 애플리케이션 스택이 가장 관련성 높은 구성요소로 제한될 수 있음 ▶ 클라우드 서비스 제공업체에 따라 공급업체 종속이 문제가 될 수 있음 ▶ 운영 및 전체 인프라에 대한 낮은 제어 수준 제한된 맞춤설정 |
SaaS | ▶ 간편하게 설정하고 사용 시작 ▶ 제공업체가 하드웨어부터 소프트웨어까지 모든 것을 관리하고 유지관리 ▶ 모든 기기에서 모든 인터넷 연결을 통해 소프트웨어에 액세스 가능 |
▶ 인프라 또는 보안 제어 통제 불가능 ▶ 기존 도구 및 애플리케이션과의 통합 문제 ▶ 클라우드 서비스 제공업체에 따라 공급업체 종속이 문제가 될 수 있음 ▶ 맞춤설정이 제한적이거나 없음 |
'Computer Science' 카테고리의 다른 글
[Third Party] 서드 파티의 개념 (1) | 2024.12.16 |
---|---|
[Software Engineering] CBD 방법론 (1) | 2024.12.03 |
[Database] 트랜잭션의 개념과 ACID 원칙 (1) | 2024.11.18 |
[Network] RESTful API vs Socket 통신 차이 (2) | 2024.11.18 |
[Software Architecture] REST API과 RESTful API (0) | 2024.11.18 |