클라우드의 이해

1 ) On-Premise와 Cloud Computing

클라우드 컴퓨팅이 등장하기 이전에는 대부분의 기업이 자체 데이터센터를 구축하여 IT 서비스를 운영하였다. 이러한 방식을 온프레미스(On-Premise) 라고 하며, 이후 인터넷을 통해 필요한 만큼 컴퓨팅 자원을 제공받는 클라우드 컴퓨팅(Cloud Computing) 이 등장하면서 인프라 구축 방식에 큰 변화가 발생하였다.

참고

일반적으로 On-Premise와 Cloud를 비교하는 경우가 많지만, 정확하게는 Private Cloud와 Public Cloud를 비교하는 개념에 가깝다.

On-Premise

개요

On-Premise는 기업이 직접 데이터센터를 구축하고, 서버와 네트워크 장비를 포함한 모든 IT 자산을 자체적으로 소유 및 운영하는 방식이다.

CPU, 메모리, 디스크, 운영체제(OS), 네트워크 장비, 소프트웨어 라이선스까지 모든 자원을 직접 구매하고 관리해야 한다.

특징

항목	내용
자원 소유	기업이 직접 소유
초기 비용	매우 높음
확장성	낮음
운영 관리	기업이 직접 수행
보안 및 통제	높음

장점

기업이 모든 시스템을 직접 관리하므로 높은 통제권을 가진다.
기업 내부 정책에 맞춘 보안 환경을 구축할 수 있다.
내부 서비스 품질을 직접 관리할 수 있다.

단점

높은 초기 투자 비용

서비스를 운영하기 위해 필요한 모든 장비를 직접 구매해야 한다. - 서버 - 스토리지 - 네트워크 장비 - 운영체제 - 각종 라이선스

초기 구축 비용이 매우 크며, 이후에도 장비 교체 및 유지보수 비용이 지속적으로 발생한다.

최대 사용량 기준으로 설계

온프레미스 환경에서는 필요한 순간에 서버를 즉시 추가할 수 없기 때문에 대부분 최대 예상 사용량(Peak Load) 을 기준으로 인프라를 설계한다.

예를 들어,

최대 동시 접속자 수
최대 네트워크 트래픽
최대 CPU 사용량

등을 모두 고려하여 여유 있게 시스템을 구축하게 된다.

그 결과 평상시에는 자원이 남더라도 항상 고사양의 인프라를 유지해야 한다.

증설 비용 사용자가 증가하면 단순히 서버를 추가하는 것으로 끝나지 않는다.

장비 구매
설치
네트워크 구성
운영 인력 투입

등이 모두 필요하므로 시간적·인적 비용이 함께 증가한다.

강사님 사례 예시

게임 서비스는 출시 전까지 실제 이용자 수를 예측하기 어렵다. 과거에는 오픈 베타 서비스를 통해 예상 수요를 확인한 뒤 서버를 구매하는 방식이 일반적이었다. 예를 들어 오픈 베타에서 약 200만 명이 접속하면 이를 근거로 투자금을 확보하고, 이후 필요한 서버를 대량 구매하여 데이터센터에 구축하였다. 또한 실제 유료 이용자는 전체 이용자의 일부에 불과하므로, 예상 접속자 수를 기반으로 서버 규모를 판단하는 것이 매우 중요했다. 대형 게임 회사에서도 신규 게임을 출시할 때 기존 게임의 서버를 회수하여 재배치하는 경우가 있었으며, 서버 운영을 위해 다양한 전문 인력을 직접 확보해야 하는 부담도 존재하였다.

정리

On-Premise는 최대 사용량을 기준으로 인프라를 구축한다.

초기 구축 비용과 증설 비용이 매우 크다.

모든 장비와 운영 인력을 직접 관리해야 한다.

대신 높은 통제권과 보안 수준을 확보할 수 있다.

Cloud Computing

개요

Cloud Computing은 컴퓨팅 자원을 직접 소유하지 않고 인터넷을 통해 필요한 만큼 사용하는 서비스 모델이다.

사용자는 서버를 구매하지 않고, 클라우드 사업자가 운영하는 데이터센터의 자원을 서비스 형태로 이용한다.

특징

IT 자산을 직접 소유하지 않는다.
인터넷만 연결되어 있으면 어디서든 사용할 수 있다.
필요한 시점에 자원을 신속하게 생성하거나 제거할 수 있다.
서비스 제공자의 최소한의 관리만으로 인프라를 구성할 수 있다.
여러 사용자가 공유하는 컴퓨팅 자원을 서비스 형태로 제공받는다.

Public Cloud가 게임 업계에서 빠르게 도입된 이유

게임 서비스는 출시 초기에 실제 접속자가 얼마나 될지 예측하기 어렵다.

예상보다 많은 사용자가 접속하면 서버가 부족해지고, 반대로 적게 접속하면 구매한 서버가 놀게 된다.

Public Cloud는 이러한 문제를 해결할 수 있었다.

필요한 만큼만 서버를 생성하고, 사용량이 줄어들면 즉시 반납할 수 있기 때문이다.

또한 클라우드 사업자는 서버, 네트워크, 스토리지 등을 관리하는 전문 인력을 보유하고 있으므로, 사용자는 필요한 자원을 요청하기만 하면 빠르게 인프라를 구성할 수 있다.

On-Premise와 Cloud의 비용

클라우드가 항상 On-Premise보다 저렴한 것은 아니다.

동일한 사양을 기준으로 비교하면 일정 기간까지는 클라우드가 유리할 수 있지만, 장기간 사용할 경우에는 On-Premise가 더 경제적일 수 있다.

클라우드 사업자 역시 데이터센터와 서버를 직접 구매하여 운영하기 때문에 장비 투자 비용을 일정 기간 동안 회수해야 한다.

강의에서는 대략 3년 정도까지는 클라우드가 유리할 수 있으며, 장기간 동일한 인프라를 계속 사용하는 경우에는 On-Premise의 비용 효율이 높아질 수 있다고 설명하였다.

이러한 이유로 대기업들도 모든 시스템을 클라우드로 이전하지 않고 일정 규모의 On-Premise 환경을 함께 유지하는 경우가 많다.

또한 단순한 장비 비용뿐 아니라 운영 인력, 기술 역량, 유지보수 비용까지 함께 고려해야 실제 총소유비용(TCO)을 판단할 수 있다.

On-Premise와 Cloud 비교

구분	On-Premise	Cloud
자원 소유	직접 소유	서비스 이용
초기 비용	높음	낮음
확장성	낮음	매우 높음
증설 속도	느림	매우 빠름
운영 관리	기업이 직접 수행	사업자가 대부분 수행
자원 활용	최대 사용량 기준 구축	필요한 만큼 사용
장기 비용	유리할 수 있음	장기간 사용 시 증가 가능

정리

On-Premise는 모든 인프라를 직접 구축하고 운영하는 방식이다.

초기 투자 비용은 크지만 높은 통제권과 보안성을 제공한다.

Cloud는 필요한 자원을 서비스 형태로 사용하는 방식으로 빠른 확장성과 유연성이 장점이다.

클라우드가 항상 저렴한 것은 아니며, 사용 기간과 운영 방식에 따라 비용 효율이 달라질 수 있다.

실제 기업은 비용, 운영 인력, 확장성 등을 종합적으로 고려하여 On-Premise와 Cloud를 함께 사용하는 경우도 많다.

2 ) Cloud의 정의와 특징

Cloud의 정의

Cloud Computing은 공유 가능한 컴퓨팅 자원(서버, 스토리지, 네트워크 등)을 하나의 자원 풀(Resource Pool)로 구성하고, 사용자가 네트워크를 통해 언제 어디서나 필요한 만큼 사용할 수 있도록 제공하는 컴퓨팅 모델이다.

사용자는 복잡한 구축 과정이나 서비스 제공자의 개입 없이 필요한 시점에 컴퓨팅 자원을 신속하게 생성하고 사용할 수 있으며, 사용이 끝나면 반납할 수 있다.

Cloud의 특징

Cloud Computing은 미국 국립표준기술연구소(NIST)에서 제시한 다음 다섯 가지 핵심 특징을 가진다.

특징	설명
On-Demand Self-Service	사용자가 필요할 때 직접 자원을 생성하고 사용할 수 있다.
Broad Network Access	네트워크를 통해 언제 어디서나 다양한 장치에서 접근할 수 있다.
Resource Pooling	여러 사용자가 공유하는 자원을 효율적으로 할당하여 사용한다.
Rapid Elasticity	자원을 빠르게 확장하거나 축소할 수 있다.
Measured Service	사용량을 측정하여 사용한 만큼 비용을 지불한다.

On-Demand Self-Service

주문형 셀프 서비스(On-Demand Self-Service)는 사용자가 별도의 기술 지원이나 서비스 제공자의 개입 없이 필요한 컴퓨팅 자원을 직접 생성하고 사용할 수 있는 특징이다.

필요한 시점에 서버를 생성하고, 사용이 끝나면 즉시 제거할 수 있어 자원 활용의 효율성을 높일 수 있다.

Broad Network Access

Broad Network Access는 네트워크를 통해 언제(Any Time), 어디서나(Any Place), 어떤 장치(Any Device)에서도 Cloud 자원에 접근할 수 있는 특징이다.

인터넷이 연결된 환경이라면 PC, 노트북, 스마트폰, 태블릿 등 다양한 장치에서 동일한 서비스를 이용할 수 있다.

Resource Pooling

Resource Pooling은 여러 사용자가 하나의 자원 풀(Resource Pool)을 공유하는 방식이다.

Cloud 사업자는 다중 임차 모델(Multi-Tenancy)을 이용하여 물리적인 서버 자원을 여러 사용자에게 효율적으로 분배한다.

사용자는 자신만의 서버를 사용하는 것처럼 보이지만 실제로는 다른 사용자와 물리적인 자원을 공유하여 사용한다.

Rapid Elasticity

Rapid Elasticity는 서비스 상황에 따라 컴퓨팅 자원을 빠르게 확장하거나 축소할 수 있는 특징이다.

사용자가 증가하면 서버를 추가하고, 사용량이 감소하면 자원을 줄여 비용을 절감할 수 있다.

이러한 특성은 유연성(Flexibility)과 확장성(Scalability)을 제공하는 Cloud의 핵심 장점이다.

Measured Service

Measured Service는 컴퓨팅 자원의 사용량을 지속적으로 측정하고 기록하는 방식이다.

Cloud 서비스는 일반적으로 Pay-Per-Use 또는 Pay-As-You-Go 방식의 과금 체계를 사용하며, 실제 사용한 자원만큼 비용을 지불한다.

정리

Cloud는 필요한 컴퓨팅 자원을 네트워크를 통해 즉시 사용할 수 있는 서비스 모델이다.

사용자는 직접 자원을 생성하고 제거할 수 있다.

자원은 여러 사용자가 공유하며 사용량에 따라 비용을 지불한다.

필요에 따라 자원을 빠르게 확장하거나 축소할 수 있다.

Cloud 설계 시 고려할 사항

Cloud 환경은 단순히 서버를 생성하는 것이 아니라 장애 대응과 서비스 연속성을 고려하여 설계해야 한다.

1. Fault Tolerance (내결함성)

Fault Tolerance는 시스템 일부에 장애가 발생하더라도 전체 서비스가 중단되지 않고 계속 동작할 수 있는 능력이다.

예를 들어 하나의 서버나 네트워크 장비에 장애가 발생하면 다른 장비가 즉시 해당 역할을 대신 수행하여 사용자는 장애를 거의 인식하지 못한다.

2. High Availability (고가용성)

High Availability는 서비스를 가능한 오랫동안 중단 없이 운영할 수 있는 능력이다.

이를 위해서는 단순히 서버를 하나 더 추가하는 것만으로는 충분하지 않다.

다음과 같은 구성 요소를 모두 고려하여 이중화(Redundancy)를 설계해야 한다.

서버
네트워크 장비
스토리지
데이터베이스
전원 및 네트워크 경로

3. Scalability (확장성)

Scalability는 서비스 요구사항에 맞추어 시스템의 처리 능력을 확장하거나 축소할 수 있는 능력이다.

확장 방식은 크게 두 가지로 구분된다.

방식	설명
Scale Up	CPU, 메모리 등 기존 서버의 성능을 향상
Scale Out	서버 수를 추가하여 처리 능력을 증가

Cloud 환경에서는 필요할 때 자원을 추가하고, 사용량이 감소하면 다시 축소하여 효율적으로 운영할 수 있다.

4. Redundancy / Resilience (중복성 / 탄력성)

Redundancy 또는 Resilience는 서비스 수요 변화에 따라 시스템이 자동으로 대응할 수 있는 능력을 의미한다.

단순히 확장이 가능한 수준을 넘어, 시스템이 부하를 감지하여 자원을 자동으로 늘리거나 줄이는 Auto Scaling까지 포함하는 개념이다.

예를 들어 학교에서 운영하는 서비스는 학기 중에는 많은 사용자가 접속하지만 방학에는 사용량이 크게 감소한다.

Cloud 환경에서는 방학이 시작되기 전에 서버 수를 줄여 비용을 절감하고, 개강 시점에는 다시 자원을 확장하여 효율적으로 운영할 수 있다.

이처럼 사용자 수가 계절이나 이벤트에 따라 크게 변하는 서비스에서는 Cloud의 자동 확장 기능이 매우 효과적이다.

토스, 마켓컬리와 같은 서비스도 이러한 자동 확장 기능을 적극적으로 활용하여 트래픽 변화에 대응하고 있으며, 대규모 Cloud 인프라를 운영하는 네이버와 카카오 역시 이러한 기술을 활용하고 있다.

정리

Fault Tolerance는 장애가 발생해도 서비스를 계속 제공하는 능력이다.

High Availability는 장시간 안정적으로 서비스를 운영하기 위한 설계이다.

Scalability는 시스템을 수평 또는 수직으로 확장하는 능력이다.

Resilience는 부하에 따라 자원을 자동으로 증감하는 탄력적인 운영 능력이다.

Cloud의 장점

장점	설명
경제성	초기 투자 비용 없이 필요한 만큼 사용한다.
자동화	업데이트, 보안 패치, 백업 등을 Cloud 사업자가 지원한다.
이동성	인터넷이 가능한 환경이라면 다양한 장치에서 동일한 서비스를 사용할 수 있다.
자원 공유	여러 사용자가 동일한 인프라를 효율적으로 공유한다.
빠른 구축	필요한 자원을 즉시 생성하여 사용할 수 있다.

Cloud의 한계

한계	설명
Internet Access	인터넷 연결이 없으면 Cloud 서비스를 이용할 수 없다.
Security	외부 환경을 이용하므로 보안 정책과 접근 제어를 고려해야 한다.
Privacy	데이터 저장 위치와 개인정보 보호에 대한 고려가 필요하다.
Vendor Lock-In	특정 Cloud 사업자의 서비스에 의존하면 다른 Cloud로 이전하기 어려울 수 있다.

Vendor Lock-In은 특정 Cloud 사업자만 제공하는 서비스를 사용하면서 발생하는 문제이다.

사업자마다 제공하는 서비스와 API가 다르므로, 특정 벤더의 서비스를 많이 사용할수록 다른 Cloud 환경으로 이전하는 비용과 난이도가 높아질 수 있다.

정리

Cloud는 네트워크를 통해 필요한 컴퓨팅 자원을 즉시 사용할 수 있는 서비스 모델이다.

핵심 특징은 On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity, Measured Service이다.

Cloud 설계에서는 내결함성, 고가용성, 확장성, 탄력성을 반드시 고려해야 한다.

Cloud는 경제성과 자동화, 빠른 구축이라는 장점을 가지지만 인터넷 의존성, 보안, 개인정보 보호, Vendor Lock-In 등의 한계도 존재한다.

3) Cloud Service 종류

Cloud 서비스는 사용자가 어느 수준까지 직접 관리하는지에 따라 여러 형태로 구분된다. 대표적인 서비스 모델은 IaaS, PaaS, SaaS이며, 원격 업무 환경을 위한 DaaS도 활용된다.

IaaS (Infrastructure as a Service)

IaaS는 서버, 스토리지, 네트워크, 방화벽, 로드밸런서 등의 인프라 하드웨어 자원을 가상화하여 사용자에게 제공하는 Cloud 서비스 모델이다.

사용자는 물리적인 장비를 직접 구매하지 않고 필요한 만큼의 인프라를 생성하여 사용할 수 있으며, 운영체제와 애플리케이션은 직접 설치하고 관리한다.

특징

서버, 스토리지, 네트워크 등 인프라 자원을 제공한다.
자유도가 높아 세밀한 설정이 가능하다.
운영체제와 애플리케이션은 사용자가 직접 관리한다.
인프라를 구성하는 각 자원에 대한 이해와 운영 지식이 필요하다.

대표 서비스

AWS EC2

참고

대부분의 CSP(Cloud Service Provider)는 기본적으로 IaaS 서비스를 제공한다.

PaaS (Platform as a Service)

PaaS는 애플리케이션을 개발하고 실행 및 관리할 수 있는 플랫폼과 프레임워크를 제공하는 Cloud 서비스 모델이다.

개발자는 서버나 운영체제를 직접 관리하지 않고 애플리케이션 개발에 집중할 수 있다.

특징

개발 플랫폼과 실행 환경을 제공한다.
운영체제와 미들웨어를 직접 관리하지 않아도 된다.
개발 환경을 빠르게 구축할 수 있다.
여러 개발자가 동일한 환경에서 작업할 수 있다.

예시

여러 개발자가 하나의 프로젝트를 진행하면 운영체제나 라이브러리 버전이 서로 달라 실행 오류가 발생할 수 있다.

PaaS는 동일한 개발 환경을 미리 제공하므로 환경 차이로 인한 문제를 줄일 수 있으며, 개발자는 환경 구축보다 애플리케이션 개발에 집중할 수 있다.

대표 서비스

Salesforce Platform
ServiceNow

SaaS (Software as a Service)

SaaS는 완성된 응용 프로그램을 인터넷을 통해 제공하는 Cloud 서비스 모델이다.

사용자는 별도의 설치나 유지보수 없이 웹 브라우저나 전용 프로그램을 통해 서비스를 사용할 수 있다.

대표 서비스

Microsoft 365
Adobe Photoshop(Adobe Creative Cloud)

DaaS (Desktop as a Service)

DaaS는 인터넷을 통해 가상 데스크톱 환경을 제공하는 Cloud 서비스이다.

인터넷만 연결되어 있다면 언제 어디서나 기업 내부망에 접속하여 동일한 업무 환경을 사용할 수 있으며, 모든 데이터는 중앙 서버에서 관리된다.

직원의 PC가 바이러스에 감염되거나 파손·분실되더라도 정보 유출 위험이 낮으며, 외부에서 기업망에 안전하게 접근할 수 있는 기술로 활용된다.

예시

데이터를 중앙 서버에만 저장하는 구조도 하나의 위험 요소가 될 수 있다.

실제로 카카오는 SK C&C 데이터센터 화재로 인해 주요 서비스가 장시간 중단되는 사고를 겪었다.

당시 내부 규정상 소스코드를 중앙 서버에 보관하는 구조였기 때문에 백업만으로는 즉시 서비스를 복구하는 데 한계가 있었다.

반면 Git과 같은 분산 버전 관리 시스템은 저장소가 여러 위치에 복제되므로 한 저장소에 장애가 발생하더라도 다른 저장소를 이용하여 복구할 수 있다.

이 사례는 중앙 집중형 관리의 편의성과 함께 장애에 대비한 이중화와 분산 저장의 중요성을 보여준다.

Cloud 서비스 모델 비교

구분	제공 범위	사용자가 관리하는 영역	대표 서비스
IaaS	인프라	운영체제, 미들웨어, 애플리케이션	AWS EC2
PaaS	개발 플랫폼	애플리케이션	Salesforce Platform, ServiceNow
SaaS	완성된 소프트웨어	없음	Microsoft 365, Adobe Photoshop
DaaS	가상 데스크톱	사용자 환경	Azure Virtual Desktop, Amazon WorkSpaces

Cloud 관련 사업자

CSP (Cloud Service Provider)

Public Cloud 서비스를 직접 제공하는 사업자이다.

자체 데이터센터와 인프라를 구축하여 서버, 스토리지, 네트워크 등의 Cloud 서비스를 제공한다.

대표 사업자

AWS
Google Cloud Platform(GCP)
Microsoft Azure
Oracle Cloud
NHN Cloud
NAVER Cloud
Kakao Cloud
KT Cloud

MSP (Managed Service Provider)

MSP는 자체 Cloud 인프라를 보유하지 않고 CSP의 Cloud 서비스를 고객에게 구축하고 운영·유지보수해 주는 전문 기업이다.

기업은 MSP를 통해 Cloud 구축, 운영, 모니터링, 비용 최적화 등의 서비스를 지원받을 수 있다.

대표 사업자

메가존클라우드
베스핀글로벌
메타넷플랫폼

참고

국내에서는 대기업 계열 CSP 외에도 메가존클라우드, 베스핀글로벌과 같은 MSP가 대표적인 Cloud 전문 기업으로 알려져 있다.

NeoCloud

GPU 클러스터와 AI 플랫폼을 중심으로 서비스를 제공하는 Cloud 사업자를 의미한다.

일반적인 CSP와 유사하게 인프라를 제공하지만, AI 모델 학습과 추론을 위한 GPU 자원 제공에 특화되어 있다는 차이가 있다.

대표 사업자

CoreWeave
NAVER Cloud

참고

NAVER Cloud는 NVIDIA와의 협력을 통해 AI GPU 인프라를 확대하며 AI 중심 Cloud 서비스를 강화하고 있다.

정리

IaaS는 인프라를, PaaS는 개발 환경을, SaaS는 완성된 소프트웨어를 제공한다.

DaaS는 인터넷을 통해 가상 데스크톱 환경을 제공하여 원격 업무를 지원한다.

PaaS는 개발 환경을 표준화하여 협업 과정에서 발생하는 환경 차이를 줄여준다.

DaaS는 중앙 관리가 가능하지만, 카카오 데이터센터 장애 사례처럼 중앙 저장소에 대한 장애 대비도 함께 고려해야 한다.

CSP는 Cloud 서비스를 직접 제공하는 사업자이며, MSP는 이를 구축·운영해 주는 전문 기업이다.

NeoCloud는 AI 학습을 위한 GPU 인프라를 중심으로 서비스를 제공하는 Cloud 사업자를 의미한다.

4 ) 클라우드 이용 모델 (Deployment Model)

클라우드 컴퓨팅은 인프라를 누구에게 제공하고 어떻게 구성하는지에 따라 여러 가지 이용 모델(Deployment Model)로 구분된다.

Public Cloud

Public Cloud는 클라우드 서비스 제공업체(CSP, Cloud Service Provider)가 구축한 인프라를 여러 사용자에게 인터넷을 통해 서비스 형태로 제공하는 모델이다.

사용자는 필요한 만큼의 컴퓨팅 자원을 임대하여 사용하며, 서버와 네트워크 등 인프라의 구축 및 운영은 클라우드 사업자가 담당한다.

특징

인터넷을 통해 누구나 이용 가능
초기 구축 비용이 낮음
사용량에 따라 비용을 지불하는 방식(Pay-as-you-go)
높은 확장성과 유연성을 제공

Private Cloud

Private Cloud는 하나의 조직만을 위해 구축되는 클라우드 환경이다.

기업 내부에 직접 구축하거나 외부 사업자가 특정 기업 전용으로 구축하여 운영할 수도 있다. 클라우드 기술을 활용하지만 특정 조직만 사용할 수 있다는 점이 Public Cloud와 가장 큰 차이이다.

특징

특정 조직만 이용
높은 보안성과 통제권 제공
기업 정책에 맞는 환경 구성 가능
구축 및 운영 비용이 상대적으로 높음

Multi Cloud

Multi Cloud는 둘 이상의 클라우드 서비스를 함께 사용하는 방식이다.

여러 Public Cloud를 함께 사용할 수도 있고, 여러 Private Cloud를 함께 사용하는 경우도 포함된다.

특징

두 개 이상의 Public Cloud 또는 Private Cloud 사용
서비스별 장점을 선택하여 활용 가능
특정 클라우드 사업자에 대한 의존도를 줄일 수 있음

Hybrid Cloud

Hybrid Cloud는 Public Cloud와 Private Cloud를 함께 사용하는 방식이다.

업무의 특성에 따라 보안이 중요한 시스템은 Private Cloud에서 운영하고, 확장성이 필요한 서비스는 Public Cloud에서 운영하는 등 두 환경을 조합하여 활용한다.

특징

Public Cloud와 Private Cloud를 혼합하여 사용
보안성과 확장성을 동시에 확보 가능
업무 특성에 따라 유연하게 자원 배치 가능

Community Cloud

Community Cloud는 공통의 목적이나 요구사항을 가진 여러 조직이 공동으로 클라우드 환경을 구축하고 운영하는 방식이다.

참여하는 조직들은 하나의 데이터센터를 함께 사용하며, 필요한 데이터를 공동으로 관리하고 활용할 수 있다.

사례

예를 들어 현대자동차와 현대오토에버가 공동으로 데이터센터를 구축하여 운영하고, 공통 데이터를 함께 활용한다면 이를 Community Cloud로 볼 수 있다.

다만 현대자동차 내부의 관점에서는 해당 클라우드가 자사 전용으로 사용되는 환경이므로 Private Cloud로 해석할 수도 있다.

즉, Community Cloud와 Private Cloud는 누구의 관점에서 바라보느냐에 따라 다르게 표현될 수 있다.

면접에서도 이러한 사례가 제시될 수 있으므로, 절대적인 답을 찾기보다는 문제에서 제시한 관점을 기준으로 판단하는 것이 중요하다.

이용 모델 비교

이용 모델	사용 대상	특징
Public Cloud	일반 사용자	클라우드 사업자가 제공하는 공유형 클라우드
Private Cloud	단일 조직	특정 조직만 사용하는 전용 클라우드
Multi Cloud	하나 이상의 조직	두 개 이상의 Public Cloud 또는 Private Cloud를 함께 사용
Hybrid Cloud	단일 또는 복수 조직	Public Cloud와 Private Cloud를 혼합하여 사용
Community Cloud	공통 목적의 여러 조직	공동으로 구축·운영하며 데이터를 공유

정리

Public Cloud는 여러 사용자가 함께 사용하는 공유형 클라우드이다.

Private Cloud는 특정 조직만 사용하는 전용 클라우드이다.

Multi Cloud는 두 개 이상의 클라우드 서비스를 함께 사용하는 방식이다.

Hybrid Cloud는 Public Cloud와 Private Cloud를 조합하여 사용하는 방식이다.

Community Cloud는 공통의 목적을 가진 여러 조직이 공동으로 구축·운영하는 클라우드이며, 관점에 따라 Private Cloud로 해석될 수도 있다.

5 ) Cloud와 On-Premise 비교 (Public Cloud & Private Cloud)

Cloud와 On-Premise는 비용 구조, 확장성, 운영 방식, 책임 범위 등 여러 측면에서 차이가 있다. 기업은 서비스의 특성과 운영 기간, 보안 요구사항 등을 종합적으로 고려하여 적합한 방식을 선택해야 한다.

비용 비교

일반적으로 단기간 사용은 Cloud, 장기간 사용은 On-Premise가 비용 측면에서 유리한 경우가 많다.

동일한 사양의 인프라를 오랜 기간 지속적으로 사용하는 경우에는 장비를 직접 구매하는 On-Premise가 총비용(TCO) 측면에서 유리할 수 있다. 반면 초기 투자 비용을 줄이고 빠르게 서비스를 시작해야 하는 경우에는 Cloud가 적합하다.

CapEx와 OpEx

Cloud 도입으로 기업의 비용 구조는 CapEx(Capital Expenditure) 중심에서 OpEx(Operating Expenditure) 중심으로 변화하였다.

구분	설명
CapEx	서버, 스토리지, 네트워크 장비 등 초기 자산 구매 비용
OpEx	인프라 운영 및 유지보수 비용(장비 사용 비용, 인건비, 운영 비용 등)

On-Premise는 초기 장비 구매 비용(CapEx)의 비중이 크지만, Cloud는 필요한 만큼 서비스를 사용하면서 운영 비용(OpEx) 형태로 지불하는 것이 일반적이다.

확장성 비교

Cloud는 필요한 시점에 컴퓨팅 자원을 즉시 추가하거나 제거할 수 있으므로 높은 확장성을 제공한다.

특히 대규모 IT 인프라를 직접 구축하기 어려운 중소기업도 Cloud를 이용하면 초기 투자 없이 대기업 수준의 서비스를 운영할 수 있다.

반면 On-Premise는 새로운 장비를 구매하고 설치해야 하므로 확장에 많은 시간과 비용이 필요하다.

안정성과 신뢰성

Cloud는 높은 가용성과 편의성을 제공하지만, 서비스 제공자에게 의존하는 만큼 다양한 리스크도 함께 존재한다.

클라우드의 리스크

IaaS(Infrastructure as a Service)의 리스크

Cloud 사업자의 인프라에서 장애가 발생하면 사용자의 서비스에도 직접적인 영향을 미칠 수 있다.

대표적인 위험 요소는 다음과 같다.

하드웨어 장애로 인한 서비스 중단
저장 데이터의 손실 가능성
데이터센터 장애에 따른 서비스 장애

또한 네트워크 환경에서는 다음과 같은 보안 위협이 발생할 수 있다.

통신 도청(Eavesdropping)
중간자 공격(MITM, Man-In-The-Middle Attack)
스푸핑(Spoofing)
네트워크 관리 미흡으로 인한 시스템 장애

사용자가 이러한 장애를 완전히 방지할 수는 없지만, 다음과 같은 대비는 가능하다.

가상 서버 백업
서버 이미지 또는 템플릿 생성
장애 발생 시 신속한 복구 환경 마련

Cloud 보안 거버넌스

Cloud 환경에서는 기업이 직접 모든 인프라를 관리하지 않는다.

데이터 저장과 시스템 운영의 일부를 Cloud 사업자에게 맡기게 되므로, 기업이 모든 보안 요소를 직접 통제할 수 없다는 한계가 존재한다.

또한 다음과 같은 리스크도 고려해야 한다.

보안 사고(Incident) 발생 시 제한적인 대응
서비스 장애 및 복구 과정에 대한 직접적인 통제 불가
Cloud 사업자의 서비스 종료 또는 파산으로 인한 서비스 연속성(Continuity) 문제

따라서 Cloud를 도입할 때에는 서비스 수준 협약(SLA, Service Level Agreement), 백업 정책, 재해 복구(Disaster Recovery) 정책 등을 함께 검토해야 한다.

책임 분계선 (Shared Responsibility)

Cloud 환경에서는 모든 책임을 Cloud 사업자가 부담하는 것이 아니다.

서비스 제공자가 책임지는 영역과 사용자가 직접 관리해야 하는 영역이 구분되며, 이를 책임 분계선(Shared Responsibility Model) 이라고 한다.

예를 들어,

Cloud 사업자는 물리 서버, 네트워크, 데이터센터 등의 인프라를 관리한다.
사용자는 운영체제 설정, 계정 관리, 애플리케이션, 데이터 보안 등을 관리한다.

따라서 Cloud를 사용하더라도 보안과 운영에 대한 모든 책임이 Cloud 사업자에게 있는 것은 아니며, 사용자 역시 자신의 관리 영역에 대한 책임을 부담해야 한다.

정리

단기간 사용은 Cloud, 장기간 사용은 On-Premise가 비용 측면에서 유리한 경우가 많다.

Cloud는 CapEx를 줄이고 OpEx 중심의 비용 구조를 제공한다.

Cloud는 뛰어난 확장성을 제공하여 초기 투자 없이 대규모 서비스를 운영할 수 있다.

Cloud 환경에서는 사업자의 장애나 네트워크 위협 등 다양한 리스크를 고려해야 한다.

Cloud는 책임을 모두 사업자가 부담하는 것이 아니라, 사용자와 사업자가 각각 책임지는 영역이 구분된다.

6 ) 클라우드에 필요한 기술

가상화

가상화(Virtualization)는 서버, 스토리지, 네트워크와 같은 물리적 자원을 소프트웨어를 통해 논리적인 자원으로 추상화하는 기술이다.

하나의 물리적 시스템을 여러 개의 독립된 시스템처럼 사용할 수 있도록 하며, 물리적 하드웨어의 기능을 소프트웨어로 구현하여 여러 가상 환경을 동시에 실행할 수 있다.

기업에서는 가상화를 통해 다음과 같은 효과를 얻을 수 있다.

물리적 하드웨어 자원을 효율적으로 사용
인프라 운영 및 관리 자동화
새로운 환경을 빠르게 생성하고 배포
장애 발생 시 복구 환경을 신속하게 구성
클라우드 컴퓨팅 환경의 기반 기술로 활용

가상화는 서버뿐 아니라 운영체제, 스토리지, 네트워크 등 다양한 인프라 영역에 적용된다.

과거에는 각 영역의 전문 엔지니어가 물리 장비를 직접 설정했지만, 점차 하드웨어 관련 기능이 소프트웨어로 추상화되면서 API나 코드를 통해 인프라를 관리할 수 있는 형태로 변화하고 있다.

이러한 흐름은 DevOps와도 밀접하게 연결된다. 인프라 구성을 코드로 관리하는 IaC(Infrastructure as Code)와 같은 방식은 개발자가 인프라 구성과 변경에 보다 쉽게 접근할 수 있도록 한다.

가상화의 이점

구분	장점	고려할 점
자원 활용	하나의 서버에서 여러 가상 머신을 실행하여 자원을 효율적으로 사용	여러 가상 머신이 동일한 물리 자원을 공유하므로 과도한 사용 시 자원 경합 발생 가능
비용	물리 장비 수 감소로 전력, 공간, 운영비 절감	일부 소프트웨어는 가상 환경에서 별도의 라이선스 비용이 발생할 수 있음
배포 속도	가상 머신 생성과 복제가 빠르며 Snapshot을 활용한 복구 가능	가상 머신 수가 많아질수록 관리와 모니터링 복잡도 증가
보안 및 격리	가상 머신 간 논리적 격리 가능	Hypervisor가 공격받으면 여러 가상 머신이 함께 영향을 받을 수 있음
운영 유연성	테스트 환경을 빠르게 구성하고 폐기 가능	고성능 작업에서는 물리 서버 대비 오버헤드가 발생할 수 있음

가상화 서비스

운영체제 가상화

하나의 운영체제에서 여러 애플리케이션을 서로 분리하여 실행하려는 목적으로 발전한 방식이다.

초기에는 chroot를 이용해 프로세스가 접근할 수 있는 파일 시스템의 범위를 분리하였다.

이후 FreeBSD Jail과 같은 기술에서는 파일 시스템뿐 아니라 CPU, 메모리, 네트워크 등 다양한 자원을 분리하여 하나의 운영체제에서 여러 독립된 환경을 실행할 수 있게 되었다.

Linux에서는 Namespace와 Control Group(cgroup)을 이용해 프로세스를 격리하고 자원을 제한하며, 이러한 기술을 기반으로 Container가 발전하였다.

Docker 역시 이러한 Linux 커널의 기능을 기반으로 컨테이너 환경을 제공한다.

운영체제 가상화는 DevOps 환경에서도 많이 사용되며, 애플리케이션 실행 환경과 인프라 구성을 소프트웨어 형태로 관리하고 배포하는 데 활용된다.

서버 가상화

서버 가상화는 하나의 물리적 컴퓨터 위에 여러 개의 독립된 가상 컴퓨터를 만드는 방식이다.

물리적 CPU, Memory, Disk, Network Adapter 등의 하드웨어를 소프트웨어로 가상화하고 각 가상 머신(Virtual Machine, VM)에 독립적인 운영체제를 설치한다.

가상 머신을 생성하고 하드웨어 자원을 할당하는 소프트웨어를 Hypervisor라고 한다.

Hypervisor는 구현 방식에 따라 다음과 같이 나뉜다.

물리 하드웨어에 직접 Hypervisor를 설치하는 방식
기존 운영체제 위에 Hypervisor를 설치하는 방식

스토리지 가상화

스토리지 가상화는 여러 물리적 저장 장치를 하나의 논리적인 저장 공간으로 구성하거나, 하나의 물리 스토리지를 여러 논리적 스토리지로 나누어 사용하는 기술이다.

스토리지 기능을 소프트웨어로 정의하고 제어하는 방식을 SDS(Software Defined Storage)라고 한다.

EMC, NetApp 등 많은 스토리지 제품도 API를 제공하여 소프트웨어를 통한 구성과 관리가 가능하다.

과거에는 전문 스토리지 엔지니어가 서비스별 용량을 계산하고 데이터 배치, 디스크 증설 등을 직접 관리하였다.

SDS를 이용하면 이러한 스토리지 구성과 관리 작업도 소프트웨어를 통해 제어할 수 있어 개발과 운영의 연계성이 높아진다.

네트워크 가상화

대표적인 네트워크 가상화 기술로 VLAN(Virtual LAN)이 있다.

VLAN은 하나의 물리적 스위치를 여러 개의 논리적인 네트워크로 분리할 수 있도록 한다.

대규모 네트워크에서는 더욱 유연하고 자동화된 네트워크 구성이 필요해졌고, 이러한 요구에 대응하기 위해 SDN(Software Defined Networking)이 등장하였다.

네트워크 구성과 정책을 소프트웨어로 제어할 수 있게 되면서 다음과 같은 영역도 점차 자동화되고 있다.

네트워크 설정
방화벽 정책
로드 밸런싱
네트워크 경로 제어

과거에는 네트워크 전문 엔지니어가 직접 구성하던 영역이었지만, 소프트웨어 기반 제어가 확대되면서 개발 부문에서도 네트워크 구성을 이해하고 일부 변경할 수 있게 되었다.

데이터 가상화

여러 위치나 형식에 존재하는 데이터를 물리적으로 이동시키지 않고 하나의 통합된 데이터 소스처럼 사용할 수 있도록 추상화하는 방식이다.

애플리케이션 가상화

애플리케이션을 운영체제에 직접 설치하지 않고 격리된 환경에서 실행할 수 있도록 구성하는 방식이다.

데스크톱 가상화

VDI(Virtual Desktop Infrastructure)는 사용자의 데스크톱 환경을 중앙 서버에서 실행하고 화면과 입력만 원격으로 전달하는 기술이다.

사용자는 자신의 모니터, 키보드, 마우스를 사용하지만 실제 프로그램 실행과 데이터 저장은 중앙 서버에서 이루어진다.

서버 가상화와 목적이 다르다.

서버 가상화 → 서비스를 제공하기 위한 서버 환경 구성
데스크톱 가상화 → 사용자의 작업 환경 제공

Hypervisor 가상화

Type 1: Native / Bare-Metal Hypervisor

Type 1 Hypervisor는 물리적 하드웨어 위에 일반적인 호스트 운영체제 없이 Hypervisor가 직접 실행되는 방식이다.

하드웨어에 직접 설치되기 때문에 Bare-Metal Hypervisor라고도 한다.

특징

중간에 일반적인 호스트 운영체제를 거치지 않아 오버헤드가 적다.
하드웨어를 직접 제어하므로 높은 성능과 안정성을 제공한다.
기업용 서버와 데이터센터 환경에서 많이 사용된다.
대규모 환경에서는 별도의 관리 서버나 관리 콘솔을 통해 여러 Hypervisor를 중앙에서 관리하는 경우가 많다.

대표적인 기술

VMware ESXi
Microsoft Hyper-V
KVM(Kernel-based Virtual Machine)
Xen 계열 Hypervisor

KVM

Linux 커널에 가상화 기능을 추가하여 Linux를 Hypervisor 역할로 동작하게 하는 기술이다.

Type 2: Hosted Hypervisor

Type 2 Hypervisor는 물리적 하드웨어 위에 먼저 호스트 운영체제를 설치한 후, 그 위에서 가상화 소프트웨어를 실행하는 방식이다.

Virtual Machine
      ↓
Hypervisor
      ↓
Host OS
      ↓
Hardware

특징

일반 애플리케이션처럼 설치하고 제거할 수 있다.
사용 방법이 비교적 간단하다.
Type 1보다 추가적인 소프트웨어 계층을 거치기 때문에 오버헤드가 발생할 수 있다.
개발, 테스트, 개인 실습 환경에서 많이 사용된다.

대표적인 소프트웨어

VMware Workstation
Oracle VirtualBox
Parallels Desktop
QEMU
UTM

Hyper-V는 Windows의 Hypervisor 기반 가상화 기술로 구조상 일반적인 Type 2 Hypervisor와는 구분해서 이해하는 것이 적절하다.

가상 머신의 구성 요소

CPU

물리 CPU의 처리 자원을 가상화하여 가상 머신에 vCPU(Virtual CPU) 형태로 할당한다.

Memory

물리 메모리의 일부를 가상 머신에 할당한다.

여러 가상 머신이 동일한 물리 메모리를 사용하지만 Hypervisor가 각 가상 머신의 메모리 공간을 논리적으로 분리한다.

Disk

가상 머신의 디스크는 일반적으로 가상 디스크 파일 형태로 구성된다.

해당 파일 안에 다음과 같은 내용이 저장된다.

운영체제
애플리케이션
사용자 데이터

Hypervisor는 이 파일을 가상 머신에서 하나의 실제 디스크처럼 사용할 수 있도록 제공한다.

Network Adapter

각 가상 머신에는 가상 네트워크 어댑터(vNIC)를 생성할 수 있다.

이를 이용해 다음과 같은 통신이 가능하다.

다른 가상 머신과 통신
호스트 시스템과 통신
외부 네트워크와 통신

Snapshot

Snapshot은 가상 머신의 특정 시점 상태를 저장해 이후 해당 상태로 되돌릴 수 있도록 하는 기능이다.

Snapshot에 포함되는 범위는 Hypervisor와 생성 옵션에 따라 달라질 수 있으며, 일반적으로 가상 디스크 상태를 기준으로 관리한다.

일부 환경에서는 메모리 상태까지 함께 저장하여 실행 중인 프로그램 상태를 복원할 수 있다.

저장할 수 있는 정보

가상 디스크의 상태
가상 머신 설정
선택적으로 메모리 상태

동작 원리

Snapshot은 가상 디스크 전체를 매번 복사하기보다 원본을 기준으로 변경된 데이터만 별도의 파일에 기록하는 방식으로 구현되는 경우가 많다.

대표적으로 Copy-on-Write 또는 차동 디스크 구조를 사용한다.

기본 가상 디스크가 존재한다.
Snapshot을 생성하면 현재 상태를 기준점으로 고정한다.
이후 발생하는 변경 사항은 별도의 차동 디스크에 기록한다.
Rollback을 수행하면 변경된 내용을 제거하고 Snapshot 시점의 상태로 돌아간다.

Base Disk
   │
   └── Snapshot
          │
          └── 변경 데이터

활용

운영체제 업데이트 전
시스템 설정 변경 전
프로그램 설치 및 테스트 전
개발 환경에서 여러 버전을 테스트할 때
악성코드 분석 환경을 초기 상태로 복원할 때

주의사항

Snapshot은 백업(Backup)을 대체하지 않는다.

Snapshot은 원본 가상 디스크와 연관되어 있기 때문에 원본 데이터가 손상되거나 저장 장치 자체에 문제가 발생하면 Snapshot도 함께 사용할 수 없을 수 있다.

또한 Snapshot을 장기간 유지하거나 여러 개를 누적하면 다음과 같은 문제가 발생할 수 있다.

차동 디스크 크기 증가
저장 공간 사용량 증가
Disk I/O 성능 저하
Snapshot 체인 관리 복잡성 증가

따라서 Snapshot은 필요한 작업이 끝나면 삭제하거나 병합하여 관리한다.

정리

Snapshot은 특정 시점으로 되돌리기 위한 기능이다.

전체 가상 머신을 별도 저장하는 Backup과 목적이 다르다.

Snapshot은 원본 가상 디스크에 의존하므로 장기 보관용 백업으로 사용하지 않는다.

Container

Container는 애플리케이션과 해당 애플리케이션을 실행하는 데 필요한 실행 환경, 라이브러리, 설정 파일 등을 하나의 독립적인 실행 단위로 구성하는 기술이다.

가상 머신은 하드웨어를 가상화한 뒤 각 VM마다 Guest OS를 실행한다.

반면 Container는 호스트 운영체제의 커널을 공유하면서 프로세스 수준에서 애플리케이션을 격리한다.

Virtual Machine

Application
Guest OS
Hypervisor
Host / Hardware

Container

Application + Dependencies
Container Runtime
Host OS Kernel
Hardware

Linux 컨테이너에서는 Namespace와 cgroup을 이용하여 프로세스를 격리하고 자원 사용량을 제어한다.

Namespace → 프로세스가 볼 수 있는 시스템 자원 분리
cgroup → CPU, Memory 등의 자원 사용량 제어

Container는 VM과 달리 Guest OS 전체를 별도로 실행하지 않기 때문에 상대적으로 가볍고 빠르다.

장점

Guest OS가 없어 상대적으로 가볍다.
Image 복제와 배포가 쉽다.
애플리케이션 시작 속도가 빠르다.
동일한 물리 서버에서 VM보다 많은 애플리케이션을 실행할 수 있다.
개발 환경과 운영 환경을 동일한 Image로 구성하기 쉽다.

한계

Container는 VM처럼 완전히 독립된 Guest OS를 실행하는 구조가 아니며, 호스트 커널을 공유한다.

따라서 VM에 비해 격리 경계가 약할 수 있으며 보안 설정이 중요하다.

또한 Container가 Linux에서만 사용할 수 있는 것은 아니다. Windows Container도 존재하지만, 컨테이너는 기본적으로 호스트와 호환되는 커널 환경을 공유해야 한다는 제약이 있다.

Container Runtime

Container Runtime은 Container를 생성하고 실행하며 수명 주기를 관리하는 소프트웨어이다.

containerd

containerd는 컨테이너 실행을 관리하는 오픈 소스 Container Runtime이다.

주요 기능은 다음과 같다.

Container Image 관리
Container 생성 및 실행
Container 중지 및 삭제
Container 수명 주기 관리

Docker에서도 내부적으로 containerd를 사용한다.

Kubernetes 역시 Container Runtime과 연동하여 Container를 실행한다.

Docker

Docker는 Container를 생성하고 실행하는 기능뿐 아니라 다음과 같은 기능을 함께 제공하는 Container 플랫폼이다.

Image Build
Image 관리
Container 실행
Network 관리
Volume 관리

Docker Engine 내부에서는 containerd를 이용해 실제 Container 실행을 처리한다.

CRI-O

CRI-O는 Kubernetes 환경을 위해 개발된 오픈 소스 Container Runtime이다.

Kubernetes의 CRI(Container Runtime Interface)에 맞춰 설계되었으며, Kubernetes에서 Container를 실행하는 데 필요한 기능에 집중한다.

Container Orchestration

Container Orchestration은 여러 Container를 여러 서버에 분산 배치하고 실행하며, 상태를 지속적으로 관리하기 위한 기술이다.

Container 수가 많아지면 사람이 직접 다음 작업을 관리하기 어렵다.

Container 배포
Container 상태 확인
장애가 발생한 Container 재시작
여러 서버에 Container 분산 배치
확장 및 축소
네트워크 연결

Container Orchestration은 이러한 작업을 자동화한다.

Docker Swarm

Docker에서 제공하는 Container Orchestration 기능이다.

설치와 구성이 비교적 간단하다.
Docker와 연동이 쉽다.
소규모 환경에서 사용하기 편리하다.
대규모 환경에서는 Kubernetes에 비해 기능과 생태계가 제한적이다.

Mesos

Apache Mesos는 여러 서버의 CPU, Memory 등 자원을 하나의 자원 풀처럼 관리하기 위한 분산 시스템 기술이다.

Twitter, Apple, Airbnb, Uber 등 여러 대규모 서비스에서 사용된 사례가 있다.

다만 Container Orchestration 기능을 구성하려면 Marathon 등의 추가 시스템과 연계해야 하므로 전체 구성이 복잡해질 수 있다.

Nomad

Nomad는 HashiCorp에서 개발한 Orchestration 도구이다.

비교적 단순한 구성으로 여러 환경에 Workload를 배포할 수 있다는 특징이 있다.

HashiCorp의 다른 도구와 연동하기 쉽다.

Consul
Vault

이미 HashiCorp 생태계를 사용하고 있는 조직에서는 함께 활용하기 좋다.

Kubernetes

Kubernetes는 Google이 내부에서 사용하던 Borg 시스템의 경험을 기반으로 개발된 Container Orchestration 플랫폼이다.

현재는 CNCF(Cloud Native Computing Foundation)에서 관리한다.

Container의 배포, 확장, 장애 복구, 네트워크 연결 등을 자동화하는 대표적인 Orchestration 플랫폼이다.

Serverless Computing과 Event Driven Architecture

Serverless Computing

Serverless Computing은 개발자가 서버를 직접 프로비저닝하거나 운영할 필요 없이 애플리케이션을 실행할 수 있도록 하는 클라우드 컴퓨팅 모델이다.

Serverless라는 이름은 실제 서버가 존재하지 않는다는 의미가 아니다.

개발자 관점에서 직접 관리해야 하는 서버가 보이지 않는다는 의미이다.

물리 서버의 운영, 관리, 확장 등은 Cloud Service Provider가 담당한다.

특징

서버 관리 부담 감소
자동 확장
실제 사용량을 기준으로 과금
인프라보다 애플리케이션 로직 개발에 집중 가능

FaaS (Function as a Service)

FaaS는 Serverless Computing의 대표적인 형태이다.

애플리케이션 전체를 하나의 장기 실행 프로그램으로 배포하는 대신, 특정 이벤트가 발생했을 때 실행되는 작은 함수 단위로 코드를 배포한다.

대표적인 서비스는 다음과 같다.

AWS Lambda
Google Cloud Functions
Microsoft Azure Functions

장점

인프라 관리 부담 감소
사용량이 적은 서비스에서 비용 절감 가능
기능을 빠르게 개발하고 배포할 수 있음
요청량에 따라 자동 확장 가능

단점

Cold Start
플랫폼 종속성
장시간 지속 실행되는 작업에서는 비용 증가 가능

Cold Start

함수가 일정 시간 동안 실행되지 않아 실행 환경이 준비되어 있지 않은 경우, 첫 요청에서 실행 환경을 초기화하는 시간이 추가로 발생할 수 있다.

플랫폼 종속성

특정 Cloud Provider의 서비스와 API에 강하게 의존하면 다른 Cloud Provider로 이전할 때 코드와 인프라 구성을 수정해야 할 수 있다.

장기 실행 비용

24시간 계속 실행되는 서비스라면 사용량 기반 Serverless보다 VM이나 Container 기반 서비스를 지속적으로 운영하는 것이 비용 측면에서 유리할 수 있다.

Event Driven Architecture

EDA(Event Driven Architecture)는 시스템 내부나 외부에서 발생하는 상태 변화를 Event로 표현하고 이를 생성, 전달, 소비하여 시스템을 동작시키는 Software Architecture 방식이다.

Publish / Subscribe 패턴이 대표적으로 사용된다.

핵심 구성 요소

구성 요소	역할
Producer	상태 변화를 감지하여 Event를 생성하고 발행
Event Broker	Event를 저장하거나 전달하여 Producer와 Consumer를 중재
Consumer	Event를 전달받아 비즈니스 로직 수행

Producer

시스템에서 발생한 상태 변화를 감지하여 Event를 생성한다.

예를 들어 다음과 같은 상황이 Event가 될 수 있다.

주문 생성
결제 완료
파일 업로드
사용자 가입

Event Broker

Producer가 생성한 Event를 전달받아 Consumer에게 전달하는 중간 계층이다.

대표적인 기술은 다음과 같다.

Apache Kafka
RabbitMQ

Cloud Provider에서도 이와 유사한 Managed Service를 제공한다.

Consumer

Event Broker에서 Event를 전달받아 자신의 비즈니스 로직을 수행한다.

Loose Coupling

EDA의 중요한 특징은 Loose Coupling(느슨한 결합)이다.

Producer가 Consumer를 직접 호출하지 않고 Broker를 통해 Event를 전달하므로 각 서비스가 서로 강하게 의존하지 않는다.

따라서 하나의 서비스가 변경되어도 다른 서비스에 미치는 영향을 줄일 수 있다.

장점

높은 유연성과 확장성
새로운 Consumer 추가가 비교적 쉬움
서비스 간 결합도 감소
장애 격리 가능
대량의 Event를 Broker에서 완충하여 처리 가능

특정 Consumer에 장애가 발생해도 Broker가 Event를 일정 기간 보관할 수 있다면, Consumer 복구 후 처리되지 않은 Event를 다시 처리할 수 있다.

또한 트래픽이 순간적으로 증가하더라도 Broker가 Event를 임시로 보관하여 Consumer가 처리 가능한 속도로 가져갈 수 있다.

단점

시스템 복잡도 증가

여러 서비스와 Event Broker가 분산되어 동작하기 때문에 시스템 전체 흐름을 추적하기 어려워질 수 있다.

데이터 일관성

여러 서비스가 Event를 순차적으로 처리하므로 모든 데이터가 동일한 순간에 변경되지 않을 수 있다.

이 때문에 최종적 일관성(Eventual Consistency)을 고려한 설계가 필요하다.

중복 처리

네트워크 장애나 재전송 과정에서 동일한 Event가 두 번 이상 전달될 수 있다.

따라서 Consumer는 동일한 Event를 여러 번 받아도 결과가 중복되지 않도록 멱등성(Idempotency)을 고려하여 구현해야 한다.

정리

Serverless는 개발자가 서버 관리에서 벗어나 애플리케이션 로직에 집중하도록 하는 실행 모델이다.

FaaS는 특정 Event가 발생할 때 Function을 실행하는 Serverless의 대표적인 형태이다.

EDA는 Event를 중심으로 서비스들을 연결한다.

Event Broker를 사용하면 Producer와 Consumer 간 결합도를 낮출 수 있다.

스토리지와 데이터 구조

Cloud Storage를 선택할 때는 필요한 저장 용량만 고려해서는 안 된다.

다음과 같은 요소를 함께 고려해야 한다.

데이터를 어떤 형태로 저장하는가
얼마나 자주 접근하는가
어느 정도의 읽기/쓰기 성능이 필요한가
여러 시스템이 동시에 접근해야 하는가
데이터를 얼마나 오래 보관해야 하는가

Cloud 환경에서는 대표적으로 다음 세 가지 Storage 방식을 사용한다.

Object Storage
Block Storage
File Storage

Object Storage

Object Storage는 데이터를 Object 단위로 저장한다.

하나의 Object는 다음 요소로 구성된다.

데이터 본문
Metadata
고유 식별자 또는 Key

Object Storage는 전통적인 디렉토리 기반 파일 시스템과 달리 기본적으로 평면적인 Namespace 구조를 사용한다.

사용자에게 디렉토리처럼 보이는 경로를 제공할 수 있지만 실제로는 Object Key의 문자열 구조를 이용해 표현하는 경우가 많다.

또한 Web API 기반으로 접근할 수 있도록 설계되어 있어 프로그램과 Cloud Service에서 사용하기 쉽다.

특징

구조가 단순하다.
대규모 확장에 유리하다.
대용량 데이터를 장기간 저장하기 좋다.
HTTP 기반 API를 이용한 접근이 쉽다.

활용 예시

로그
백업
이미지
동영상
정적 파일
장기 보관 데이터

Block Storage

Block Storage는 데이터를 고정된 크기의 Block 단위로 나누어 저장하는 방식이다.

운영체제에서는 일반적인 디스크처럼 인식하며 파일 시스템을 구성한 뒤 사용한다.

가상 머신의 디스크로 많이 사용한다.

특징

빠른 읽기/쓰기 성능
데이터 일부만 수정 가능
운영체제에서 일반 디스크처럼 사용 가능
Database와 같이 높은 I/O 성능이 필요한 환경에 적합

반면 사용자가 직접 다음 작업을 수행해야 하는 경우가 많다.

Partition 구성
File System 생성
Mount
용량 관리

File Storage

File Storage는 일반적인 디렉토리와 파일 구조를 그대로 제공하는 방식이다.

네트워크를 통해 여러 Client가 하나의 File System에 동시에 접근할 수 있다.

특징

디렉토리 기반 계층 구조
여러 Client가 동시에 접근 가능
기존 파일 시스템 방식과 유사하여 사용하기 쉬움
파일 공유와 협업에 적합

활용 예시

공유 문서
Web Server의 공통 정적 리소스
사용자 Home Directory
여러 Server가 함께 사용하는 파일

다만 많은 Client가 동시에 대량의 데이터를 읽고 쓰는 환경에서는 병목이 발생할 수 있다.

Storage 비교

구분	Object Storage	Block Storage	File Storage
저장 단위	Object	Block	File
구조	평면 Namespace	Block Device	Directory / File
접근 방식	Web API	Disk 방식	공유 File System
장점	대규모 확장, 구조 단순	빠른 I/O, 높은 제어 수준	사용 편리, 공유 용이
단점	일반 디스크처럼 직접 수정하기 어려움	File System을 직접 관리해야 함	높은 성능이나 대규모 동시 I/O에서는 병목 가능
주요 용도	대용량 데이터, 백업, 로그	Database, VM Disk	File 공유
대표 서비스	AWS S3, Azure Blob Storage, Google Cloud Storage	AWS EBS, Azure Managed Disks, Google Persistent Disk	AWS EFS, Azure Files, Google Filestore

AWS S3 Glacier

AWS S3 Glacier 계열 Storage Class는 자주 사용하지 않는 데이터를 장기간 저렴하게 보관하기 위한 저장 방식이다.

대표적인 용도는 다음과 같다.

장기 백업
Archive
법적 보관 데이터
장기간 접근하지 않는 로그

데이터를 압축할 필요가 있다면 일반적으로 사용자가 데이터를 압축한 후 S3에 업로드한다.

Glacier가 사용자의 파일을 임의로 압축해서 저장하는 방식으로 이해하면 안 된다.

Storage 요금

Cloud Storage는 단순히 저장 공간만을 기준으로 과금하지 않는다.

대표적인 과금 요소는 다음과 같다.

저장 용량
API 요청 및 I/O 작업 횟수
외부로 전송되는 데이터 양
Storage Class
데이터 조회 방식

따라서 저장 용량이 작더라도 요청 횟수나 데이터 전송량이 많으면 비용이 증가할 수 있다.

수명 주기 관리

Lifecycle Management는 데이터의 사용 패턴이나 보관 기간에 따라 Storage Class를 자동으로 변경하거나 데이터를 삭제하도록 정책을 설정하는 기능이다.

예를 들어 다음과 같은 정책을 구성할 수 있다.

데이터 생성
↓
자주 사용하는 Storage
↓
30일 후
↓
저비용 Storage
↓
1년 후
↓
Archive Storage
↓
보존 기간 종료
↓
삭제

수명 주기 관리를 사용하면 오래된 데이터를 사람이 직접 이동하거나 삭제하지 않아도 되며, 데이터의 중요도와 접근 빈도에 따라 저장 비용을 줄일 수 있다.

정리

가상화는 물리 자원을 소프트웨어로 추상화하여 하나의 자원을 여러 논리 자원으로 사용할 수 있도록 한다.

Hypervisor 기반 가상화는 가상 머신마다 독립적인 운영체제를 실행하며 Type 1과 Type 2로 구분할 수 있다.

Snapshot은 특정 시점의 가상 머신 상태를 복원하기 위한 기능이며 Backup과는 목적이 다르다.

Container는 호스트 커널을 공유하면서 프로세스를 격리하여 VM보다 가볍게 애플리케이션을 실행할 수 있다.

Container Runtime은 Container를 실행하고, Container Orchestration은 여러 Container의 배포와 상태 관리를 자동화한다.

Serverless는 서버 관리 부담을 Cloud Provider에 위임하고 애플리케이션 로직에 집중할 수 있도록 한다.

EDA는 Event Broker를 중심으로 Producer와 Consumer를 느슨하게 결합한다.

Cloud Storage는 Object, Block, File Storage로 구분하며 사용 목적과 접근 방식에 따라 적절한 Storage를 선택해야 한다.

Lifecycle Management를 이용하면 데이터의 접근 빈도와 보관 기간에 따라 저장 위치와 삭제 시점을 자동으로 관리할 수 있다.