Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- 유노코딩
- Python
- Git
- 파이썬
- 방송대
- 클라우드컴퓨팅
- redis
- 방송대컴퓨터과학과
- 오픈소스기반데이터분석
- 코딩테스트
- 엘리스sw트랙
- 코딩테스트준비
- mongoDB
- Azure
- aws
- 꿀단집
- 개발자취업
- CSS
- 파이썬프로그래밍기초
- 중간이들
- node.js
- TiL
- 프로그래머스
- 데이터베이스시스템
- 코드잇
- 99클럽
- HTML
- nestjs
- 항해99
- JavaScript
Archives
- Today
- Total
배꼽파지 않도록 잘 개발해요
방송대 클라우드컴퓨팅 - 11강. 클라우드 아키텍처 2 본문

1. 오토 스케일링
2. 클라우드 버스팅
3. 무중단 서비스 재배치
[실습]
1. 오토 스케일링 (Auto Scaling)
(1) 개념
- 수평 스케일링 자동화 기술
사용자의 증가/감소에 따라 가상 서버 수를 자동으로 늘리거나 줄이는 기능. - 리소스 풀링 + 로드 밸런싱 결합형 구조로, 부하를 자동 감시하고 필요한 만큼의 리소스를 동적으로 할당한다.
(2) 동작 방식
| 구성요소 | 역할 |
| 클라우드 사용량 모니터 | CPU, 메모리 등 사용량을 실시간 감시하고 임곗값을 지정함. |
| 자동 확장 리스너(Listener) | 임계상황 발생 시 이벤트를 감지하고 자동으로 서버 증설/회수 실행. |
(3) 자동 확장 동작 예시
- CPU 사용률이 90% 초과 → 새로운 가상 서버 생성 + 로드밸런서에 연결.
- CPU 사용률이 30% 미만 → 불필요한 서버를 로드밸런서에서 제거 후 반환
👉 즉, 트래픽 폭주 시 자동으로 서버가 늘어나고, 트래픽이 줄면 비용 절약을 위해 다시 줄어듦.
(4) 장점
- 서비스 중단 없이 확장/축소 가능
- 비용 효율성 향상 (필요할 때만 자원 사용)
- 관리 자동화로 인력 개입 최소화
2. 클라우드 버스팅 (Cloud Bursting)
(1) 개념
- 프라이빗 클라우드의 자원이 한계에 도달했을 때, 일시적으로 퍼블릭 클라우드를 빌려 쓰는 기술
- 목표: 물리적 확장 없이도 단기간에 시스템 전체 처리능력 향상
(2) 주요 특징
- 융통성과 비용 효율성 확보:
필요 시에만 퍼블릭 클라우드 사용 → 고정 인프라 확장 불필요 - 프라이빗 클라우드 중심 구조로, 내부 시스템이 주체가 되어 외부 리소스를 일시 활용.
(3) 동작 3단계
| 단계 | 내용 |
| ① 동일 환경 구성 | 프라이빗 클라우드와 동일한 서비스를 퍼블릭 클라우드에 구성 |
| ② 조건 설정 | CPU 등 임곗값을 기준으로 버스팅 조건, 이관할 데이터/앱 지정 |
| ③ 데이터 전송 | 임계 도달 시 데이터와 애플리케이션을 퍼블릭 클라우드로 전송하여 확장 가동 |
(4) 동작 형태
| 구분 | 설명 |
| 버스트 아웃(Burst Out) | 프라이빗 → 퍼블릭 클라우드로 서비스 확장. |
| 버스트 인(Burst In) | 사용 종료 후 퍼블릭 리소스 반납, 프라이빗 환경으로 복귀. |
(5) 설계 시 고려사항
- 임계값 설정 주의:
처리량 100% 직전(예: 80%)에서 버스트아웃을 실행해야 데이터 복제 지연 방지 - 보안/규정 준수:
민감 데이터는 외부 전송 전에 암호화·접근제어 필요 - 복제 시간:
전송 데이터가 많을수록 복제 시간 ↑ → 서비스 지연 위험
3. 무중단 서비스 재배치 (Live Migration)
(1) 필요성
항상 실행되어야 하는 24/365 서비스(예: 금융, 포털 등)는 중단 없는 환경이 필수
유지보수나 신규 서버 이관 등으로 다운타임이 불가피할 때 이를 최소화하는 기술
(2) 온프레미스 대비 클라우드 구조 비교
| 구분 | 온프레미스 환경 | 클라우드 환경 |
| 이중화 방식 | 액티브–액티브, 액티브–스탠바이 구조 필요 (비용↑) | 가상 서버 복제 및 동적 재배치로 비용↓ |
| 운영 방식 | 직접 장비 구매·유지 | 가상화 인프라에서 자동 복제·이관 |
| 다운타임 대응 | 핫/웜/콜드 스탠바이 구성 | 하이퍼바이저 기반 VM 복제로 무중단 이관 |
(3) 액티브–스탠바이 구성 단계
| 구성 | 특징 |
| 핫 스탠바이 (Hot) | 백업 서버도 상시 구동 중. 즉시 전환 가능 |
| 웜 스탠바이 (Warm) | 백업 서버 구동 준비 상태. 전환까지 약간의 지연 |
| 콜드 스탠바이 (Cold) | 백업 서버 정지 상태. 전환 전 기동 필요 (소규모 환경에 적합) |
기술적 가용성: 액티브–액티브 > 핫 > 웜 > 콜드,
비용: 반대 순서 (콜드 < 웜 < 핫 < 액티브–액티브)
(4) 클라우드 환경의 재배치 절차
- 새로운 물리 서버에 하이퍼바이저가 새로운 VM을 생성
- 기존 서버의 VM을 복제하여 OS 및 프로그램을 이관
- 공유 디스크 기반이라면 서비스 중단 없이 즉시 전환 가능
(5) 가상 디스크 이관 유형
| 유형 | 설명 | 사용 예 |
| 로컬 스토리지(비공유 디스크) | VM 내부에 물리적으로 저장 | OS, DB 등 자주 접근 데이터 |
| 원격 공유 디스크 | 여러 VM이 동일한 데이터 접근 가능 | 로그, 파일 공유 등 공용 데이터 |
핵심 요약
| 구분 | 핵심 내용 |
| 오토 스케일링 | 리소스 풀링 + 로드밸런싱을 기반으로 수평 스케일링 자동화 |
| 클라우드 버스팅 | 프라이빗 자원이 한계에 도달하면 퍼블릭 클라우드를 임시로 활용 |
| 무중단 서비스 재배치 | 가상화 및 복제 기술을 이용해 다운타임 없는 서버 이관 실현 |
| 핫/웜/콜드 스탠바이 | 즉시성 vs 비용의 트레이드오프를 고려한 백업 구조 설계 |
728x90
'방송대 컴퓨터과학과 > 클라우드컴퓨팅' 카테고리의 다른 글
| 방송대 클라우드컴퓨팅 - 15강. 연습문제 2 (0) | 2025.11.08 |
|---|---|
| 방송대 클라우드컴퓨팅 - 12강. 클라우드 컴퓨팅의 미래 (이론) (0) | 2025.11.07 |
| 방송대 클라우드컴퓨팅 - 10강. 클라우드 아키텍처 1 (0) | 2025.11.05 |
| 방송대 클라우드컴퓨팅 - 9강. 클라우드 컴퓨팅 기술 3 (0) | 2025.10.31 |
| 방송대 클라우드컴퓨팅 - 8강. 연습문제 1 (0) | 2025.10.31 |