1장. 온프레미스와 클라우드의 이해

구분	온프레미스	클라우드
비용 방식	장비 선구매	사용량 기반 과금
초기 비용	높음	낮음
장기 비용	자원 활용률에 따라 유리할 수 있음	설계와 사용량에 따라 크게 변동

확장 방식

구분	온프레미스	클라우드
확장 방법	장비 추가 구매	즉시 서버 생성
확장 속도	느림	빠름
탄력성	제한적	자동 확장 가능

운영 책임

구분	온프레미스	클라우드
하드웨어	내부 책임	클라우드 사업자
OS / 애플리케이션	내부 책임	대부분 내부
물리 보안	내부 책임	사업자 책임

7. 갑자기 사용자가 10배 늘어난다면?

온프레미스

서버 용량이 부족하다
새 장비를 주문한다
배송과 설치를 기다린다
설정을 완료한다

시간이 오래 걸린다.

클라우드

서버를 여러 대 추가 생성한다
자동으로 트래픽을 분산한다

몇 분 안에 확장이 가능하다.

이 차이가 클라우드의 가장 큰 특징이다.

8. 클라우드는 무조건 더 좋은가?

그렇지는 않다.

사용량이 많아지면 비용이 커질 수 있다
설계를 잘못하면 불필요한 자원이 계속 과금된다
자동화와 운영 이해가 필요하다

클라우드는 단순한 서버 임대가 아니라
운영 방식의 변화다.

9. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

서버는 24시간 동작하는 컴퓨터다.
온프레미스는 서버를 직접 소유하고 운영하는 방식이다.
클라우드는 서버를 빌려 사용하는 방식이다.
두 모델의 차이는 위치가 아니라 운영 구조에 있다.

2장. 클라우드는 어떻게 서버를 제공하는가

1. 서버를 몇 분 만에 만드는 것이 가능한 이유

1장에서 우리는 클라우드가 서버를 임대하는 방식이라고 배웠다.

그렇다면 이런 질문이 생긴다.

버튼을 누르면 왜 몇 분 만에 서버가 만들어질까?
실제 물리 서버를 새로 설치하는 것일까?

답은 아니다.

클라우드는 대부분 가상화 기술을 이용해
하나의 물리 서버를 여러 개로 나누어 제공한다.

2. 물리 서버와 가상 서버

물리 서버

실제 하드웨어 장비
CPU, 메모리, 디스크, 네트워크 카드가 물리적으로 존재
데이터센터에 설치되어 있음

가상 서버

물리 서버 위에 소프트웨어적으로 만들어진 서버
독립된 운영체제를 실행
다른 가상 서버와 격리되어 동작

사용자는 가상 서버를 사용하지만,
실제로는 물리 서버의 자원을 나누어 사용하는 구조다.

3. 가상화란 무엇인가

가상화(Virtualization)는

하나의 물리 자원을 여러 개의 논리적 자원으로 나누는 기술

이다.

예를 들어:

CPU 32코어
메모리 256GB

를 가진 물리 서버가 있다면,

이를 나누어

4코어 / 16GB 서버 여러 개
8코어 / 32GB 서버 여러 개

처럼 만들 수 있다.

이렇게 만들어진 각각의 서버는
독립된 컴퓨터처럼 동작한다.

4. 하이퍼바이저의 역할

이 작업을 수행하는 소프트웨어를 하이퍼바이저라고 한다.

하이퍼바이저는 다음을 담당한다.

물리 CPU를 여러 개의 가상 CPU로 분할
메모리를 나누어 각 가상 서버에 할당
디스크를 논리적으로 분리
네트워크를 가상으로 구성

즉, 물리 자원을 관리하고 나누어주는 관리자 역할을 한다.

5. 왜 이것이 클라우드를 가능하게 하는가

클라우드 사업자는 대규모 데이터센터에
수많은 물리 서버를 보유하고 있다.

사용자가 “새 서버를 만들어 달라”고 요청하면,

이미 준비된 물리 서버 위에
하나의 가상 서버를 생성하고
운영체제를 올린 뒤
네트워크를 연결해준다

이 과정이 자동화되어 있기 때문에
몇 분 안에 서버가 생성될 수 있다.

물리 장비를 새로 설치하는 것이 아니라,
이미 존재하는 자원을 분할하여 제공하는 것이다.

6. 가상화의 장점

가상화는 클라우드에 다음과 같은 장점을 제공한다.

1) 빠른 생성

물리 설치 없이 즉시 서버 제공 가능

2) 높은 자원 활용률

하나의 물리 서버를 여러 사용자가 공유

3) 격리

한 가상 서버의 장애가 다른 서버에 직접 영향을 주지 않음

4) 유연한 확장

필요할 때 서버를 추가 생성 가능

7. 가상 서버는 완전히 독립적인가

가상 서버는 논리적으로 독립적이지만
물리 자원을 공유한다는 사실은 변하지 않는다.

따라서 다음과 같은 상황이 발생할 수 있다.

같은 물리 서버의 다른 가상 서버가 과도한 자원을 사용
네트워크 공유로 인한 지연
디스크 I/O 경쟁

이 문제를 줄이기 위해
클라우드 사업자는 자원 격리 기술을 지속적으로 발전시키고 있다.

8. 가상 머신과 컨테이너

가상화에는 두 가지 주요 방식이 있다.

가상 머신(VM)

독립된 운영체제를 포함
격리 수준이 높음
상대적으로 무거움

컨테이너(Container)

운영체제를 공유
가볍고 빠름
마이크로서비스 구조에 적합

현재 대부분의 클라우드 서비스는
가상 머신 기반 구조 위에서 시작되었으며,
최근에는 컨테이너 기술도 널리 활용되고 있다.

9. 클라우드 서비스마다 부르는 이름

각 클라우드 서비스는
이 가상 서버를 서로 다른 이름으로 부른다.

Amazon Web Services → EC2
Google Cloud Platform → Compute Engine
Microsoft Azure → Virtual Machine

이름은 다르지만,
기본 원리는 동일하다.

10. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 물리 서버를 직접 빌려주는 것이 아니다.
가상화 기술을 이용해 물리 자원을 나누어 제공한다.
하이퍼바이저가 자원을 분할하고 관리한다.
이 구조 덕분에 빠른 생성과 확장이 가능하다.

3장. 클라우드 서비스 모델의 이해

1. 같은 서비스를 다른 방식으로 운영한다면

우리가 간단한 웹 서비스를 만든다고 가정해보자.

사용자는 회원가입을 한다.
로그인 후 게시글을 작성한다.
게시글은 데이터베이스에 저장된다.

이 서비스를 운영하려면 다음이 필요하다.

서버
운영체제
웹 서버 프로그램
데이터베이스
네트워크 설정
보안 설정
백업 및 모니터링

이 중에서 누가 어디까지 관리하느냐에 따라
클라우드 서비스 모델이 나뉜다.

2. IaaS란 무엇인가

IaaS는 Infrastructure as a Service의 약자다.
인프라를 서비스 형태로 제공한다는 의미다.

예를 들어 Amazon Web Services 에서는
가상 서버 서비스를 EC2라고 부른다.

게시판 서비스를 IaaS로 운영하면 다음과 같다.

우리가 직접 해야 하는 일

가상 서버 생성
운영체제 설치 및 설정
웹 서버 설치
데이터베이스 설치
보안 패치 적용
백업 구성
확장 설계

클라우드는 서버, 네트워크, 스토리지를 제공하지만
그 위의 대부분은 우리가 책임진다.

IaaS는 온프레미스와 가장 유사한 모델이다.
차이는 물리 장비를 직접 소유하지 않는다는 점이다.

3. PaaS란 무엇인가

PaaS는 Platform as a Service의 약자다.
실행 환경을 서비스로 제공한다는 의미다.

같은 게시판 서비스를 PaaS로 운영하면
우리가 관리해야 할 영역이 줄어든다.

우리가 하는 일

애플리케이션 코드 작성
기능 개발
데이터 구조 설계

클라우드가 대신하는 일

운영체제 관리
런타임 환경 관리
자동 확장
일부 보안 패치
관리형 데이터베이스 운영

즉, 우리는 인프라보다
애플리케이션 개발에 집중하게 된다.

IaaS보다 추상화 수준이 한 단계 높다.

4. SaaS란 무엇인가

SaaS는 Software as a Service다.
완성된 소프트웨어를 서비스 형태로 제공하는 모델이다.

지금까지는 게시판을 “직접 만든다”는 전제였다.
하지만 SaaS에서는 게시판을 직접 개발하지 않는다.

이미 만들어진 서비스를 사용한다.

우리가 하는 일

계정 생성
사용자 관리
기능 설정
요금 결제

우리가 하지 않는 일

서버 관리
운영체제 관리
보안 패치
확장 설계
백업 구성
인프라 모니터링

이 모든 것은 서비스 제공자가 담당한다.

예를 들어
Microsoft 의 Microsoft 365,
Google 의 Google Workspace 등이 이에 해당한다.

SaaS는 개발이나 인프라 운영이 아닌
“서비스 사용”에 가깝다.

5. 한눈에 비교하면

같은 게시판 서비스를 기준으로 정리하면 다음과 같다.

모델	우리가 관리하는 범위
IaaS	운영체제 이상 대부분
PaaS	애플리케이션 중심
SaaS	거의 없음

오른쪽으로 갈수록
직접 관리해야 할 영역은 줄어들고
추상화 수준은 높아진다.

6. 왜 이렇게 나뉘어 있는가

클라우드는 단순히 서버를 빌려주는 산업이 아니다.
운영 부담을 얼마나 줄여줄 것인가에 따라 발전해왔다.

인프라만 제공 → IaaS
실행 환경까지 제공 → PaaS
완성된 소프트웨어 제공 → SaaS

즉, 관리 범위를 단계적으로 줄여가는 구조다.

7. 어떤 모델을 선택해야 할까

정답은 없다.
서비스의 목적과 조직의 역량에 따라 달라진다.

세밀한 제어가 필요하면 IaaS
개발 속도가 중요하면 PaaS
직접 개발할 필요가 없으면 SaaS

실제 환경에서는 이 모델들을 혼합해 사용한다.

예를 들어:

핵심 서비스는 IaaS
데이터베이스는 관리형(PaaS)
협업 도구는 SaaS

이처럼 상황에 맞게 조합하는 것이 일반적이다.

8. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

같은 서비스라도 운영 방식은 달라질 수 있다.
차이는 “누가 어디까지 관리하느냐”이다.
IaaS는 인프라 중심 모델이다.
PaaS는 실행 환경 중심 모델이다.
SaaS는 완성된 소프트웨어 모델이다.

4장. 클라우드 책임 공유 모델의 이해

1. 클라우드를 쓰면 모든 책임이 사라질까

클라우드를 처음 접하면 이런 생각을 할 수 있다.

서버를 빌렸으니, 보안과 장애도 클라우드가 다 책임지는 것 아닐까?

하지만 그렇지 않다.

클라우드는 모든 책임을 대신해주는 서비스가 아니다.
클라우드 사업자와 사용자 사이에 책임이 나뉘어 있다.

이것을 책임 공유 모델(Shared Responsibility Model) 이라고 한다.

2. 책임 공유 모델이란 무엇인가

책임 공유 모델은 다음을 의미한다.

클라우드는 인프라의 일부를 책임지고,
사용자는 그 위에서 동작하는 것에 대해 책임진다.

예를 들어 Amazon Web Services 는
자사 공식 문서에서 이 모델을 명확히 설명하고 있다.

핵심은 다음과 같다.

클라우드는 클라우드 자체의 보안(Security of the Cloud) 을 책임진다.
사용자는 클라우드 위에서 사용하는 것(Security in the Cloud) 을 책임진다.

3. 물리 인프라에 대한 책임

클라우드 사업자가 책임지는 영역은 다음과 같다.

데이터센터 건물 보안
물리 서버 장비
네트워크 장비
전력 및 냉각 시스템
하이퍼바이저 계층

즉, 우리가 직접 접근할 수 없는 물리 영역은
클라우드가 책임진다.

온프레미스라면 우리가 직접 관리해야 할 부분이다.

4. 운영체제와 애플리케이션은 누가 책임질까

여기서부터는 서비스 모델에 따라 달라진다.

IaaS의 경우

물리 서버 → 클라우드 책임
가상 서버 → 클라우드 책임
운영체제 → 사용자 책임
애플리케이션 → 사용자 책임
데이터 → 사용자 책임

즉, OS부터 위는 우리가 관리한다.

PaaS의 경우

운영체제 → 클라우드 책임
런타임 환경 → 클라우드 책임
애플리케이션 코드 → 사용자 책임
데이터 → 사용자 책임

관리 범위가 줄어든다.

SaaS의 경우

인프라 → 클라우드 책임
플랫폼 → 클라우드 책임
애플리케이션 운영 → 클라우드 책임
데이터 입력 및 접근 권한 관리 → 사용자 책임

SaaS에서도 데이터 보호와 접근 제어는
사용자의 책임이다.

5. 실제 사고 사례를 생각해보자

예를 들어 이런 상황을 가정해보자.

서버에 보안 패치를 적용하지 않았다.
관리자 비밀번호를 단순하게 설정했다.
데이터베이스를 외부에 공개했다.

이 경우 책임은 누구에게 있을까?

클라우드가 아니라
사용자에게 있다.

클라우드는 “환경”을 제공하지만,
그 위의 설정 실수까지 대신 책임지지는 않는다.

6. 책임 공유 모델이 중요한 이유

클라우드 전환을 고려할 때
가장 흔한 오해 중 하나는 다음이다.

클라우드로 가면 보안이 자동으로 해결된다.

하지만 실제로는

잘못된 권한 설정
과도하게 열린 네트워크
암호화 미적용
백업 미구성

등은 여전히 사용자의 책임이다.

따라서 클라우드는 보안을 없애는 기술이 아니라,
보안의 경계를 바꾸는 모델이다.

7. 책임 공유 모델을 한눈에 정리하면

영역	IaaS	PaaS	SaaS
데이터센터	클라우드	클라우드	클라우드
물리 서버	클라우드	클라우드	클라우드
운영체제	사용자	클라우드	클라우드
애플리케이션	사용자	사용자	클라우드
데이터	사용자	사용자	사용자

오른쪽으로 갈수록
사용자의 관리 범위는 줄어든다.
하지만 데이터 책임은 항상 사용자에게 있다.

8. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 모든 책임을 대신해주지 않는다.
물리 인프라는 클라우드가 책임진다.
운영체제와 애플리케이션은 모델에 따라 달라진다.
데이터 보호 책임은 항상 사용자에게 있다.
보안은 사라지는 것이 아니라 경계가 이동하는 것이다.

5장. 클라우드의 과금 구조 이해하기

1. 왜 클라우드 비용은 체감이 다를까

온프레미스에서는 비용 구조가 비교적 단순하다.

서버 구매 비용
랙 비용
회선 비용
유지보수 비용

대부분 고정 비용이다.

하지만 클라우드는 다르다.

자원을 “소유”하지 않고 “사용”하기 때문에
비용이 사용량에 따라 계속 변한다.

이 차이 때문에 클라우드 비용은
예측이 어렵게 느껴질 수 있다.

2. 클라우드 과금의 기본 원리

클라우드 과금의 핵심은 단순하다.

사용한 만큼 지불한다.

대표적인 클라우드 사업자인
Amazon Web Services 역시
대부분의 서비스가 사용량 기반 과금이다.

과금 단위는 다음과 같이 나뉜다.

서버 사용 시간
CPU / 메모리 크기
스토리지 용량
네트워크 트래픽
요청 횟수

즉, 자원을 여러 단위로 나누어 계산한다.

3. 서버 과금은 어떻게 계산될까

가상 서버(IaaS)의 경우 보통 다음 요소로 계산된다.

인스턴스 유형 (CPU, 메모리 크기)
실행 시간 (시간 또는 초 단위)
추가 스토리지
네트워크 아웃바운드 트래픽

예를 들어,

24시간 계속 실행
고사양 인스턴스
트래픽이 많음

이면 비용이 크게 증가한다.

반대로,

필요할 때만 실행
자동 종료
소형 인스턴스 사용

이면 비용을 줄일 수 있다.

4. 스토리지와 네트워크 비용

초보자가 가장 자주 놓치는 부분이
네트워크 비용이다.

스토리지 과금

저장 용량 기준
I/O 요청 횟수 기준
백업 및 스냅샷 용량 기준

네트워크 과금

클라우드 내부 트래픽
리전 간 트래픽
인터넷으로 나가는 트래픽

특히 인터넷으로 나가는 트래픽(아웃바운드)은
비용이 빠르게 증가할 수 있다.

스트리밍, 이미지 서비스, 대용량 다운로드 서비스는
이 부분이 매우 중요하다.

5. 고정 비용과 변동 비용의 차이

온프레미스는 고정 비용 중심이다.

서버를 구매하면 비용은 이미 발생
사용률이 높을수록 효율이 좋아짐

클라우드는 변동 비용 중심이다.

사용량이 적으면 비용도 적음
사용량이 많으면 비용도 증가

즉, 클라우드는 유연성을 제공하는 대신
비용이 예측하기 어려울 수 있다.

6. 언제 클라우드가 비싸게 느껴질까

다음과 같은 환경에서는
클라우드가 오히려 더 비싸게 느껴질 수 있다.

24시간 고부하가 지속되는 서비스
자원을 거의 100% 사용 중인 환경
이미 감가상각이 끝난 장비 운영 중인 경우

이 경우 온프레미스가 비용 효율이 더 높을 수 있다.

7. 언제 클라우드가 유리할까

다음과 같은 경우에는 클라우드가 유리하다.

트래픽 변동이 큰 서비스
특정 시간대만 고부하
빠른 실험과 확장이 필요한 환경
초기 투자 비용을 줄이고 싶은 경우

클라우드는 “항상 싸다”가 아니라
“필요한 만큼만 쓴다”는 점이 핵심이다.

8. 비용을 이해하는 사고 방식

클라우드를 사용할 때는
다음 질문을 항상 해야 한다.

이 서버는 24시간 필요할까?
자동으로 줄일 수 있는 구조인가?
트래픽을 줄일 방법은 없는가?
관리형 서비스가 오히려 효율적인가?

클라우드에서는
아키텍처 설계가 곧 비용 설계다.

9. 정리

이 장에서 기억해야 할 핵심은 다음과 같다.

클라우드는 사용량 기반 과금이다.
서버, 스토리지, 네트워크가 주요 비용 요소다.
네트워크 아웃바운드는 특히 주의해야 한다.
고정 부하 서비스는 온프레미스가 유리할 수 있다.
비용은 설계에 따라 크게 달라진다.

6장. 확장성과 가용성의 이해

1. 서버는 반드시 멈추지 않아야 할까

온프레미스 환경에서는 이런 생각이 자연스럽다.

서버는 절대 죽으면 안 된다.
가장 좋은 장비를 써야 한다.
장애는 최대한 막아야 한다.

하지만 현실에서는 어떤 시스템도
영원히 멈추지 않을 수는 없다.

하드웨어 고장
네트워크 장애
갑작스러운 트래픽 폭증
소프트웨어 오류

클라우드는 이 현실을 전제로 설계된다.

서버는 죽을 수 있다.
중요한 것은 “죽지 않게 만드는 것”이 아니라
“죽어도 서비스가 유지되게 만드는 것”이다.

2. 확장성이란 무엇인가

확장성(Scalability)은
부하가 증가해도 서비스를 유지할 수 있는 능력이다.

예를 들어:

사용자가 100명일 때는 서버 1대로 충분
사용자가 10,000명으로 늘어나면 서버가 더 필요

이때 어떻게 대응할 것인가가 확장성의 핵심이다.

3. 두 가지 확장 방식

수직 확장

기존 서버의 성능을 높인다.
CPU, 메모리를 더 큰 사양으로 변경한다.

한계가 명확하다.
장비 교체가 필요하고, 물리적 제한이 존재한다.

수평 확장

서버 수를 늘린다.
여러 대가 동시에 요청을 처리한다.

이 방식은 이론상 확장 한계가 낮다.
클라우드는 이 수평 확장에 매우 유리하다.

대표적인 클라우드 서비스 제공자인
Amazon Web Services 는
자동 확장 기능을 제공한다.

부하가 증가하면 서버를 자동으로 늘리고,
부하가 줄어들면 자동으로 줄인다.

4. 가용성이란 무엇인가

가용성(Availability)은
서비스가 얼마나 지속적으로 이용 가능한지를 의미한다.

예를 들어:

99% 가용성
99.9% 가용성
99.99% 가용성

숫자가 높을수록 장애 허용 시간이 줄어든다.

하지만 가용성은 단순히
“서버가 켜져 있는가”의 문제가 아니다.

하나의 서버가 꺼져도
전체 서비스는 계속 동작하는가?

이 질문이 핵심이다.

5. 단일 장애 지점

단일 장애 지점(Single Point of Failure)은
한 지점의 장애가 전체 서비스 중단으로 이어지는 구조다.

예:

서버 1대만 운영
데이터베이스 1대만 운영
로드 밸런서 없음

이 구조에서는 작은 장애도
전체 중단으로 이어진다.

클라우드는 이러한 단일 장애 지점을 제거하기 쉽게 만든다.

6. 다중 영역 구성

클라우드 환경에서는
서버를 서로 다른 물리적 영역에 배치할 수 있다.

Amazon Web Services 는
이를 리전과 가용 영역이라는 구조로 제공한다.

가용 영역은 서로 물리적으로 분리된 데이터센터
전력과 네트워크가 독립적
동시에 장애가 발생할 확률이 낮음

여러 영역에 서버를 배치하면
하나의 데이터센터가 장애가 나도
서비스는 유지된다.

7. 클라우드의 설계 철학

온프레미스 사고:

강력한 한 대의 서버
장애를 막는 구조

클라우드 사고:

여러 대의 비교적 작은 서버
장애를 전제로 한 구조
자동 확장
자동 복구

이 차이가 가장 중요하다.

클라우드는 완벽한 서버를 제공하는 것이 아니라
유연하게 복구 가능한 환경을 제공한다.

8. 확장성과 가용성은 비용과 연결된다

서버를 여러 대 운영하면 비용 증가
다중 영역 구성하면 비용 증가
데이터 복제하면 비용 증가

따라서 다음 질문이 중요하다.

우리 서비스는 어느 수준의 가용성이 필요한가?
장애 허용 범위는 어디까지인가?
비용 대비 적절한 설계는 무엇인가?

클라우드에서는
아키텍처 설계가 곧 비용 설계다.

9. 이 장의 핵심 정리

서버는 언제든지 장애가 날 수 있다.
클라우드는 장애를 전제로 설계한다.
수평 확장은 클라우드의 핵심 강점이다.
단일 장애 지점을 제거하는 것이 중요하다.
가용성 수준은 설계와 비용의 균형이다.

7장. 리전과 가용 영역의 이해

1. 서버를 여러 대 두면 충분할까

6장에서 우리는 단일 장애 지점을 제거해야 한다고 배웠다.

그렇다면 서버를 2대 이상 두면 충분할까?

만약 두 서버가 같은 건물,
같은 전력 설비, 같은 네트워크 장비를 사용한다면
건물 단위의 사고가 발생했을 때 둘 다 동시에 멈출 수 있다.

정전
화재
네트워크 장비 고장
자연 재해

따라서 고가용성을 위해서는
서버를 단순히 여러 대 두는 것이 아니라
물리적으로 분리된 위치에 배치해야 한다.

이 구조를 가능하게 하는 개념이
리전과 가용 영역이다.

2. 리전이란 무엇인가

리전(Region)은
클라우드 사업자가 특정 지리적 위치에 구축한
하나의 독립된 인프라 단위다.

예를 들어
Amazon Web Services 는
서울, 도쿄, 프랑크푸르트, 버지니아 등
전 세계 여러 리전을 운영하고 있다.

각 리전은 다음과 같은 특징을 가진다.

독립된 전력 인프라
독립된 네트워크 인프라
독립된 데이터센터 그룹
다른 리전과 물리적으로 분리

하나의 리전이 장애가 나더라도
다른 리전에는 영향을 주지 않도록 설계되어 있다.

리전은 재해 복구 단위라고 이해하면 쉽다.

3. 가용 영역이란 무엇인가

이제 중요한 개념이다.

가용 영역(Availability Zone, AZ)은
하나의 리전 안에 존재하는
서로 다른 물리적 데이터센터다.

여기서 중요한 점은 다음이다.

가용 영역은 데이터센터 내부의 구역이 아니다.
같은 건물 안의 다른 방이 아니다.

서로 완전히 분리된 독립 데이터센터다.

4. 가용 영역에 대한 흔한 오해

많은 사람들이 처음에 이렇게 생각한다.

하나의 데이터센터 건물 안에 여러 구역이 있는 것인가?
서버실을 나눈 개념인가?

아니다.

가용 영역은 다음과 같은 구조다.

예를 들어 서울 리전에 3개의 가용 영역이 있다면:

서울 내 서로 다른 위치의 3개 독립 데이터센터
전력 설비가 서로 다름
네트워크 인입 경로가 다름
동시에 장애가 날 확률이 매우 낮음

즉,

서울 강남의 데이터센터 하나
서울 마포의 데이터센터 하나
서울 성수의 데이터센터 하나

이런 개념에 가깝다.

(정확한 위치는 보안상 공개되지 않는다.)

5. 서울과 부산은 같은 리전일까

이론적으로는 하나의 리전에
서울과 부산이 포함될 수도 있다.

하지만 일반적으로는 다음 원칙이 있다.

같은 리전 안의 가용 영역은
지연 시간이 매우 낮아야 한다.
수 밀리초(ms) 수준의 빠른 통신이 가능해야 한다.

서울-부산처럼 거리가 먼 경우에는
보통 다른 리전으로 구분된다.

왜냐하면:

리전 간은 재해 복구 단위
가용 영역은 고가용성 단위
지연 시간 차이가 크기 때문

즉,

가용 영역은 “같은 도시권 내의 분리된 데이터센터”
정도로 이해하는 것이 가장 정확하다.

6. 왜 가용 영역이 중요한가

고가용성의 핵심은
단일 장애 지점을 제거하는 것이다.

예를 들어:

서버 1대 → 장애 시 서비스 중단
서버 2대를 서로 다른 가용 영역에 배치 → 한 영역 장애 시에도 서비스 유지

이를 다중 AZ 구성이라고 한다.

이 구조에서는:

한 데이터센터가 정전되어도
네트워크가 끊겨도
특정 건물에 사고가 발생해도

서비스는 계속 동작할 수 있다.

7. 리전과 가용 영역의 차이 정리

구분	리전	가용 영역
단위	지리적 지역	독립된 데이터센터
목적	재해 복구	고가용성
거리	도시/국가 단위	같은 도시권 내
지연 시간	비교적 있음	매우 낮음
장애 범위	대규모	부분적

리전은 “대규모 재해 대비”
가용 영역은 “일반적인 장애 대비”

라고 이해하면 쉽다.

8. 설계 철학과의 연결

6장에서 배운 내용을 다시 생각해보자.

서버는 죽을 수 있다.
데이터센터도 장애가 날 수 있다.
하나의 도시도 재해를 겪을 수 있다.

클라우드는 이를 전제로
리전과 가용 영역이라는 구조를 제공한다.

즉,

클라우드는 물리적 분리를 기본 설계로 제공한다.

이 점이 온프레미스와의 중요한 차이 중 하나다.

9. 이 장의 핵심 정리

서버 여러 대만으로는 충분하지 않다.
물리적 분리가 고가용성의 핵심이다.
리전은 지리적 단위다.
가용 영역은 서로 다른 물리적 데이터센터다.
가용 영역은 같은 건물 안의 구역이 아니다.
다중 AZ 구성은 기본 설계 전략이다.

8장. 서버 아키텍처의 기초 이해

이 장에서 말하고자 하는 것

클라우드는 새로운 개념처럼 보이지만,
결국 그 위에서 동작하는 것은 “서버”다.

클라우드를 이해하려면
먼저 서버가 무엇이고,
웹 서비스가 어떻게 구성되는지 이해해야 한다.

이 장의 목적은 다음 세 가지다.

서버의 기본 개념 이해
웹 서비스의 구성 요소 이해
클라우드 위에 올라가는 구조를 머릿속에 그릴 수 있게 만들기

1. 서버란 무엇인가

서버(Server)는 특별한 장비가 아니다.

다른 컴퓨터의 요청을 받아 처리하는 컴퓨터

이다.

웹 브라우저로 어떤 사이트에 접속하면
브라우저는 서버에 요청(Request)을 보내고,
서버는 처리 결과를 응답(Response)으로 반환한다.

이 구조를 클라이언트-서버 구조라고 한다.

클라이언트 → 요청을 보내는 쪽
서버 → 요청을 처리하는 쪽

2. 웹 서비스는 어떻게 동작하는가

게시판 서비스를 예로 들어보자.

사용자가 브라우저에서 글 작성 버튼 클릭
브라우저가 서버에 HTTP 요청 전송
서버가 요청을 처리
데이터베이스에 저장
결과를 다시 사용자에게 응답

이 과정은 하나의 서버가 아니라
여러 역할의 서버가 나누어 수행한다.

3. 서버의 역할 분리

서비스가 커질수록 서버의 역할을 나누게 된다.

1) 웹 서버

HTTP 요청을 받아 처리
정적 파일 제공 (이미지, CSS, JS)
애플리케이션 서버로 요청 전달

대표적인 웹 서버 소프트웨어:

Nginx
Apache

2) 애플리케이션 서버

실제 비즈니스 로직 처리
로그인 검증
게시글 저장 처리
API 응답 생성

예:

Node.js
Java (Spring)
PHP
Python (Django)

3) 데이터베이스 서버

데이터 저장
조회, 수정, 삭제 수행

대표적인 DB:

MySQL
PostgreSQL
MariaDB

4) 캐시 서버

자주 사용하는 데이터를 메모리에 저장
응답 속도 향상

예:

Redis
Memcached

왜 역할을 나누는가

성능 향상
부하 분산
보안 분리
확장성 확보
장애 영향 최소화

4. 서버 운영체제(OS)

서버도 운영체제가 필요하다.

대표적인 서버 OS는 다음과 같다.

1) Linux 계열

Ubuntu
Rocky Linux
Debian
CentOS (구버전)

특징:

오픈소스
라이선스 비용 없음
서버에 최적화
클라우드에서 가장 많이 사용

2) Windows Server

Microsoft 환경에 적합
.NET 기반 서비스와 궁합이 좋음
라이선스 비용 존재

클라우드에서 Linux가 많은 이유

비용 절감
자동화 도구와의 호환성
컨테이너 생태계
안정성

5. 서버는 항상 한 대로 운영할까 (Tier 구조)

초기에는 한 대로 시작할 수 있다.
하지만 확장성과 안정성을 위해 구조를 분리한다.

1) 단일 서버 구조 (All-in-One)

웹 + 앱 + DB 모두 한 서버

flowchart LR
  U[사용자/브라우저] --> S[단일 서버\nWeb + App + DB]

장점:

간단
초기 구축 빠름

단점:

장애 시 전체 중단
확장 어려움

2) 2-Tier 구조

애플리케이션 서버와 DB 서버 분리

flowchart LR
  U[사용자/브라우저] --> A[App 서버\nWeb + App]
  A --> DB[DB 서버]

장점:

DB 보호 가능
앱 서버 확장 가능

3) 3-Tier 구조

웹 서버 / 애플리케이션 서버 / DB 서버 분리

flowchart LR
  U[사용자/브라우저] --> W[Web 서버]
  W --> A[App 서버]
  A --> DB[DB 서버]

장점:

역할 명확
확장 유연
보안 분리 가능

실무 확장 예시

flowchart LR
  U[사용자] --> LB[로드밸런서]
  LB --> W[Web 서버]
  W --> A1[App 서버 #1]
  W --> A2[App 서버 #2]
  A1 --> DB[DB 서버]
  A2 --> DB

이 구조가 클라우드에서 가장 흔한 형태다.

6. 클라우드와 서버의 연결

클라우드는 서버 구조를 바꾸는 것이 아니다.

웹 서버
앱 서버
DB 서버
캐시 서버

이 구성은 그대로 유지된다.

차이점은:

물리 장비를 직접 소유하지 않음
서버를 빠르게 생성 가능
자동 확장 가능
관리형 DB 사용 가능

즉,

클라우드는 기존 서버 아키텍처를
더 유연하게 운영할 수 있게 만든 환경이다.

7. 이 장의 핵심 정리

서버는 요청을 처리하는 컴퓨터다.
웹 서비스는 여러 역할의 서버로 구성된다.
Tier 구조는 확장성과 보안을 위한 설계 방식이다.
Linux는 클라우드에서 가장 많이 사용되는 서버 OS다.
클라우드는 서버 구조 위에서 동작한다.

9장. 상태와 무상태의 이해

1. 상태란 무엇인가

상태(State)란
어떤 시스템이 이전 요청의 정보를 기억하고 있는 것을 의미한다.

예를 들어:

로그인 후 세션 정보가 서버 메모리에 저장됨
장바구니 정보가 특정 서버에 저장됨
사용자의 임시 데이터가 서버 내부에 보관됨

이 경우, 서버는 이전 요청의 정보를 “기억”하고 있다.

이를 상태가 있는 서버라고 한다.

2. 상태가 있는 서버의 문제점

상태가 있는 서버는 처음에는 단순해 보인다.
하지만 확장성과 연결되면 문제가 발생한다.

1) 로드밸런싱 문제

사용자가 로그인 후
서버 A에 세션이 저장되었다고 가정하자.

이후 요청이 서버 B로 전달되면
B는 로그인 정보를 알지 못한다.

즉, 특정 사용자가 특정 서버에 묶이게 된다.

이를 세션 종속성(Session Affinity) 문제라고 한다.

2) 서버 장애 시 데이터 손실

서버 A가 장애로 종료되면
그 서버 메모리에 있던 세션 정보도 사라진다.

사용자는 다시 로그인해야 할 수 있다.

3) 수평 확장의 제약

클라우드에서는 서버를 여러 대로 늘리는 것이 일반적이다.

하지만 상태가 서버 내부에 있다면
서버를 자유롭게 늘리고 줄이기 어렵다.

Auto Scaling이 제대로 동작하기 힘들다.

3. 무상태란 무엇인가

무상태(Stateless)는
각 요청이 독립적으로 처리되는 구조를 의미한다.

즉,

어떤 서버가 요청을 받아도 동일한 결과를 낼 수 있어야 한다.
이전 요청 정보에 의존하지 않는다.

서버는 단순히 요청을 처리하는 역할만 한다.

4. 왜 클라우드에서는 무상태가 중요한가

클라우드는 다음을 전제로 설계된다.

서버는 언제든지 종료될 수 있다.
Auto Scaling으로 서버 수가 변한다.
다중 AZ 환경에서 서버가 분산된다.

이 환경에서 상태를 서버 내부에 저장하면
구조가 복잡해진다.

따라서 클라우드에서는
무상태 설계를 기본 전략으로 사용한다.

5. 무상태 설계는 어떻게 구현하는가

무상태가 되기 위해서는 상태를 서버 외부로 분리해야 한다.

1) 세션을 데이터베이스에 저장

로그인 정보
사용자 설정 정보

모든 서버가 같은 DB를 참조한다.

2) 캐시 서버 사용

Redis 같은 외부 캐시에 세션 저장.

장점:

빠른 속도
서버 간 공유 가능

3) JWT 방식 사용

로그인 정보를 토큰 형태로 사용자에게 전달하고
서버는 토큰을 검증만 수행.

서버가 세션을 저장하지 않아도 된다.

6. 상태와 무상태 비교

구분	상태 있음	무상태
세션 저장 위치	서버 내부	외부 저장소
확장성	제한적	매우 유리
장애 대응	취약	유리
로드밸런싱	복잡	단순

7. 현실적인 접근

완전한 무상태가 항상 가능한 것은 아니다.

예를 들어:

파일 업로드 중 임시 저장
대용량 처리 작업
트랜잭션 처리

이 경우에도
핵심 원칙은 같다.

서버 내부가 아니라 외부 저장소에 상태를 둔다.

8. 설계 철학으로서의 무상태

온프레미스 사고:

서버는 오래 살아있다.
메모리에 저장해도 괜찮다.

클라우드 사고:

서버는 언제든지 교체될 수 있다.
서버는 일시적인 존재다.
상태는 외부에 둔다.

이 사고 전환이
클라우드 네이티브 설계의 핵심이다.

9. 이 장의 핵심 정리

상태는 이전 요청 정보를 기억하는 것이다.
상태가 서버 내부에 있으면 확장이 어렵다.
무상태는 요청이 독립적인 구조다.
클라우드에서는 무상태 설계를 권장한다.
상태는 외부 저장소에 분리하는 것이 원칙이다.

Keyboard shortcuts

AWS로 이해하는 클라우드 컴퓨팅 기초