Notice

Recent Posts

Recent Comments

Link

« 2026/01 »
일	월	화	수	목	금	토
				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 more

Archives

Today

Total

관리 메뉴

Gom3rye

클라우드 본문

현대 오토에버 클라우드 스쿨

클라우드

Gom3rye 2025. 6. 10. 17:42

728x90

클라우드 기본 개념

클라우드 배포 모델

Ex. Community Cloud: 삼성전자 ↔ 삼성전자 서비스 센터가 같이 일할 때 쓰는 클라우드 (다른 회사이지만 공유하는 데이터가 있어야 할 때)

Private Cloud Community Cloud Public Cloud Hybrid Cloud

확장성	제한적	제한적	매우 높음	매우 높음
복원성	매우 높음	매우 높음	중간	중상
보안	높은 보안 수준	준수한 수준	서비스 제공자 의존	준수한 수준
성능	좋음	매우 좋음	중하	좋음
비용	매우 높음	높음	사용량만큼 지불	높음

Ex. 배달의 민족

aws(서버) ——> 모바일

|______> 인터넷이 안되면 로컬 데이터

aws 서버가 죽으면 서비스 사용 못함 → SoF (Single Point of Failure)

따라서,

aws ——| 모바일 |

gcp ——|______|

클라우드를 활용하는 이유

인프라 규모 산정의 용이성
- 컴퓨팅 자원의 규모를 산정하는 것은 매우 어려운 일
- 비지니스 관점에서는 중요하게 고려해야 할 사항
- IT 자원을 피크 타임에 맞춰서 구축을 하게 돼서 자원의 낭비가 심하다.
- 자원 낭비를 줄이는 방법
  - 단계적 확장
    - 수요를 예측해서 단계적으로 IT 자원을 확장하는 방법
    - 이전 데이터를 이용해서 분기별로 수요량을 예측해서 컴퓨팅 자원을 확보한다.
  - 피크타임 확장
    - 피크타임이 될 때까지 기다린 후 피크 시점에 IT 자원을 증설하는 방법
    - IT 자원 관점에서 보면 낭비 요소를 제거할 수 있지만 비즈니스 안정성은 확보되지 않는 단점이 있다.
  - 동적 확장
    - 자원이 필요할 때 필요한 만큼만 동적으로 자원을 확보해 서비스에 할당하는 방법
비용의 절감
- 자원을 동적으로 할당하게 되면 비용적인 측면에서도 효과적이다.
- 구축 비용이 절감된다.
- 운용 비용이 절감된다. → 인력에 대한 비용 뿐 아니라 서비스의 테스트와 배포와 같은 시간적 비용도 포함한다.
탄력성
- 확장과 축소가 편리하다.
가용성
- 시스템 유지 보수와 같은 시스템 shutdown 상태를 포함해서 실제 인프라가 임의의 시간에 활용 가능한가를 측정한다.
- 가용성은 인프라의 런타임 예외 발생 상황에 대한 대처가 얼마나 잘되고 있는지를 나타내는 지표이다.
  - 가용성 = 운영시간/전체시간 = (전체시간-shutdown된 시간)/전체시간
  - 신뢰도 = 운영시간/가용시간 = (전체시간-shutdown된 시간)/(전체시간-이미 예측한 shutdown된 시간)
신속성
- 가변적인 IT 서비스 자원 요청에 신속하게 대응
투명한 사용량 측정
- 사용자에게 실시간으로 클라우드 컴퓨팅 인프라를 사용한 사용량을 대시보드 형태로 제공한다.
복원성
- 클라우드에서는 가상머신을 주로 이용하는데 가상머신을 통한 서비스에 장애가 발생한 경우 손쉽게 가상머신 파일을 이동하거나 공유 스토리지를 통해 클라우드 컴퓨팅 인프라에서 서비스를 복구할 수 있다.
- AWS의 경우는 대부분 메인 시스템에 문제가 발생해서 접근이 불가능할 경우 서브 시스템에 접근하도록 해서 서비스에 문제가 발생할 경우 서비스를 복원할 수 있도록 해준다.

클라우드 컴퓨팅에 영향을 준 기술

클러스터링

여러 자원을 묶어 마치 하나의 거대한 자원으로 활용할 수 있는 기술

자원은 동일한 스펙일 수도 있고 상이한 스펙일 수도 있지만 대부분은 동일한 스펙의 자원을 네트워크로 연결하고 네트워크도 광대역 네트워크보다는 동일한 물리적 공간에서 연결된 형태를 의미한다.
컴퓨팅 자원은 LAN(Local Area Network)을 이용해서 서로 통신을 하게 되고 컴퓨팅 자원을 통제하는 Master Node가 존재하는데 마스터 노드는 별도의 컴퓨터로 분리될 수도 있고 일반 컴퓨팅 자원에 마스터의 역할을 부여하기도 한다.
스토리지에 대한 접근도 필요한데 이 경우는 LAN을 통한 스토리지 접근도 가능하지만 SAM(Storage Area Network)을 통해서 컴퓨팅 자원이 스토리지 자원에 접근할 수 있게 한다.
네트워크를 통해서 IT 자원을 거대한 하나의 자원으로 보이게 해야 하는데 이렇게 네트워크를 통해서 IT 자원을 클러스터링 함으로써 부족한 컴퓨팅 자원을 늘릴 수 있고 상황에 따라서 자원과 분리해서 활용할 수 있게 한다.
네트워크를 통한 IT 자원을 연결한 후에는 반드시 이를 통합적으로 관리해주는 소프트웨어가 필요한데 이러한 특수 소프트웨어는 클러스터링의 목적에 맞게 인프라를 관리하고 운영할 수 있도록 해주는데 HTConder, SUN Grid Engine, Univa 등이 있다.
(queue → 스케쥴링에 사용)
워커 노드의 역할을 수행하는 머신을 Executor Machine 이라고 하는데 사용자는 작업을 클러스터에 제출하고 이 제출된 작업을 Submit Machine(Master Node)이 받아서 Queue(FIFO) System을 동작시킨다.
- 사용 가능한 워커 노드가 있을 경우 해당 작업이 워커 노드에 할당된다.
- 어떤 워커 노드가 작업을 할지 결정하는 시스템이 Central Manager(중앙 관리자)이고 이 시스템이 사용자로부터 제출된 작업과 이 작업을 수행하기에 가장 적절한 워커 노드를 매칭해주는 역할을 수행한다.
네트워크를 통해 클러스터링 한 후 HTCondor 같은 클러스터링 소프트웨어가 네트워크로 연결된 여러 독립적인 컴퓨터(하드웨어)를 하나의 거대한 컴퓨터 시스템처럼 만들어 준다.

그리드 컴퓨팅

분산된 이기종의 컴퓨팅 자원을 광대역 네트워크를 통해 하나의 단일 시스템으로 만들어 컴퓨팅 자원을 공유하는 시스템

ex. 토렌트

클라우드 컴퓨팅이 활성화되기 전에 유휴한 컴퓨팅 자원을 활용하기 위한 다양한 시도가 있었지만 그 중에서 대표적인 성공 사례가 그리드 컴퓨팅이다.
고에너지 물리와 같은 기초 과학 분야의 부족한 컴퓨팅 자원을 국제적인 협업을 통해서 해결하고자 하는 노력의 일환으로 활발하게 논의 중이다.
그리드 컴퓨팅에 사용되는 미들웨어는 미국 주도의 Open Science Grid와 유럽 주도의 European Grid Initiative가 있다.
- 데이터 센터의 가용자원을 확인하고 작업이 그리드에 제출되었을 때 그리드 미들웨어가 가장 적절한 컴퓨팅 자원을 가지고 있는 데이터 센터에 작업을 할당하여 처리하는 구조
AWS의 자원도 사용 가능하다.
사용자는 로컬에 작업을 제출하지만 실제 수행은 글로벌하게 이루어진다.
그리드에 포함된 데이터 센터는 특정 그룹만이 이용하는 것이 아니라 다양한 커뮤니티를 지원하기 때문에 개념적으로는 커뮤니티 클라우드와 동일하다.
그리드 컴퓨팅의 중요한 성질은 데이터 센터들이 분산되어 있고 매우 느슨한 연결로 구성된다.
느슨한 연결이 의미하는 것은 그리드에 속한 데이터 센터라고 해도 자치권이 보장된다.
데이터 센터가 지원하는 작업을 처리할 때 작업에 대한 처리와 거부 등은 데이터 센터가 결정한다.

클러스터링과 그리드 컴퓨팅의 차이:

클러스터링: 중앙 관리자(마스터 노드)가 전체 클러스터 관리

그리드 컴퓨팅: 각 자원 소유자가 자원을 독립적으로 관리하며 협력

가상화

컴퓨터가 어떤 작업을 하려면 물리적인 메모리와 하드디스크, OS 등 다양한 부품이 필요한데 이를 소프트웨어로 대체하는 것이 가상화 기술이다.

가상 서버는 물리 서버 1대 위에 게스트가 되는 서버 여러 대를 가상으로 생성할 수 있다.
네트워크의 경우에도 물리적 배선 1개를 가상으로 분할해서 다른 네트워크와 통합하고 연결을 변경할 수 있다.
가상 서버에 할당된 메모리와 스토리지는 자유롭게 늘리거나 줄일 수 있기 때문에 나중에 필요할 때 용량을 늘리거나 줄여서 메모리와 스토리지의 성능을 높일 수 있다. → But, 서버의 성능을 높이는 것은 한계가 있다.
성능을 한계까지 끌어올려도 부하가 발생할 때 서버 대수를 늘리지 않으면 대응할 수 없는데 물리적인 서버의 경우 1대를 늘릴 때 CPU, Mainboard, Memory, Storage 등이 필요하지만 가상화는 소프트웨어처럼 구축하기 때문에 서버 복제가 쉽고 대수를 늘리거나 줄이는 것이 쉽다.

분산 처리와 로드 밸런싱

분산 처리: 기기 여러 대에 분산해 처리하는 방법

같은 기능이나 정보를 가진 서버 여러 대에 분배하여 처리하면 서버 1대의 부담을 줄이고 서버가 응답할 수 없거나 다운되는 사태를 막을 수 있다.

서버 여러 대에 작업을 분배하는 장치를 Load Balancer 라고 하는데 로드 밸런서는 각 서버를 확인해서 부하를 분산하고 경우에 따라서는 부하가 너무 높아진 서버를 분리하기도 한다.

이중화

시스템이나 서버에 문제가 생겨도 계속 가동할 수 있도록 조치하는 것
백업하거나 여러 대를 운영하는 것이 일반적이다.
가상화나 분산 처리 방식은 이러한 이중화에도 크게 도움이 되는데 서버 여러 대를 구축하는 것은 그것만으로도 백업이 되고 분산 처리를 해두면 서버 한 대에 문제가 생겨도 다른 서버에 의해 기능이 유지되기 때문이다.

클라우드 서비스 제공자의 역할

쉬운 접근성과 높은 보안성을 제공

클라우드 서비스는 네트워크를 통해 접근하고 가상 자원을 사용하기 때문에 사용자가 네트워크를 통해 쉽게 접근하고 필요한 가상 자원을 쉽게 생성할 수 있어야 한다.
클라우드 컴퓨팅 서비스에는 네트워크가 개입되고 사용자의 데이터가 네트워크를 통해서 클라우드 서비스 제공자의 인프라에 제공되고 저장한 후 관리되기 때문에 높은 보안성이 요구된다.

비즈니스에서 클라우드를 적용하는 이유에 대한 이해

IT 자원을 쉽게 확보하고 IT 자원을 자체 구축할 때 소모되는 투자 비용과 직접 관리로부터 발생하는 리스크를 제거할 수 있기 때문이다.

약속된 성능 제공

클라우드 서비스 사용자는 자신이 필요한 성는ㅇ을 쉽게 확보하기 위해서 클라우드 서비스 제공자의 서비스를 이용한다.
클라우드 인프라를 통해 생성되는 가상머신의 성능은 충분히 예측 가능해야 한다.

합리적인 비용

온디맨드 기반의 서비스 제공

언제든지 자신이 필요한 만큼의 자원을 확대하고 축소할 수 있어야 한다.

유지보수 부담 제거

IT 인프라를 구축하고 운영하는 데는 많은 유지보수 비용과 노력이 동반된다.

자원 성능의 확장

자원의 성능을 확장하는 방법

수평적으로 확장 - Scale Out (개수 증가)
수직적으로 확장 - Scale Up (성능 증가)

Scale Out

가상머신 A에 가상머신 B, C를 추가해 성능을 개선하는 방식으로 가상머신의 개수를 온디맨드 방식에 따라 수평적으로 확장
스케일 아웃 방식은 동일한 타입의 IT 자원을 추가해서 확장한다.
장점은 가상머신의 수를 물리머신 풀에서 제공 가능한 규모만큼 확장하고 축소할 수 있고 물리머신의 풀을 확장하는 것이 스케일 업 방식보다는 용이하다.

Scale Up

기존 가상 머신의 하드웨어를 업그레이드 (ex. 2 CPU 가상머신을 4 CPU 가상머신으로 변경)
스케일 업 방식은 물리 시스템의 자원 규모에 영향을 받는다.
물리 시스템에서 제공하는 자원의 한계를 가상 머신이 넘어설 수 없기 때문이다.
대규모의 IT 자원의 성능을 향상 시킬 때는 Scale Up 보다는 Scale Out 방식을 이용한다.

비교

Scale Out Scale Up

서버	저비용	고비용 (특화된 서버)
가용성	IT 자원 즉시 이용	IT 자원 즉시 이용이 어려움
확장성	자원 복제 및 자동 확장 수월	추가 설정 필요
추가 서버	추가 IT 서버 필요	추가 IT 서버 필요 없음
용량 제한	하드웨어 용량에 제한 받지 않음	최대 하드웨어 용량에 제약을 받음
관리 비용	추가 서버 문제로 관리 비용이 많이 듬	관리 비용 절감
서버 관리	복잡	단순
데이터 일관성	일관성 유지가 어려움	일관성 유지가 쉬움

대부분의 경우 Scale Out이 좋다고 얘기하지만 관리가 복잡하고 어려워지기 시작한다.

db 작업

쉐어드 락: 읽기

익스클루시브 락: 쓰기, 업데이트

순차 처리 메시징 큐

금융권, 예약 → 반드시 순차 처리 해야 한다.

에어비앤비가 메시징 큐 만들었다. → 카프카를 만든 것!

클라우드를 사용시 고려 사항

데이터에 대한 보안 취약성

public cloud 인프라를 사용하게 되면 로컬에서 관리되던 데이터가 네트워크를 통해 클라우드 컴퓨팅 인프라로 전송되어 저장 관리되어야 한다.
이때 기업 자체의 보안 정책을 적용 받던 데이터가 제 3자가 관리하는 보안 정책 영역으로 이동됨에 따라 보안이 취약해질 수 있다.
데이터에 대한 외부 관리가 불허되는 환경이라면 데이터 이동이 필수적인 외부 클라우드를 활용하는 것보다는 private cloud 환경을 구축하는 것이 바람직하다.

보안 정책의 상충

독자적인 보안 정책을 적용 받는 환경에서 서로 다른 보안 정책을 갖는 혼합된 형태인 경우 악의적인 내부 사용자에게 취약점이 노출될 수 있다.

Admin 역할의 축소

인프라 관리에 대한 부분이 클라우드 서비스 제공자의 통제를 받게 된다.
On-Premise로 구축된 시스템 대비 인프라에 대한 접근과 관리 권한이 축소된다.

네트워크 의존성 증가

외부 클라우드에 접속하기 위해서는 반드시 네트워크가 개입되어야 한다.
클라우드 인프라에 접근할 수 있는 배타적인 네트워크를 구축하지 않는 이상, 네트워크 회선은 외부의 사용자와 공유하는 자원이다.
네트워크는 기본적으로 신뢰성이 확보되지 않은 전송 인프라
사용자 내부의 네트워크는 신뢰성이 확보된 네트워크이고 클라우드 서비스도 신뢰성이 확보된 네트워크인데 이를 연결하는 네트워크가 불안정하고 신뢰성이 없는 네트워크이다.
네트워크 회선은 End-To-End로 물리적 회선으로 구성되지 않고 중간에 라우터가 개입되는 구조라서 얼마든지 네트워크를 통해서 전송되는 데이터는 복제가 가능하다.
전송 패킷이 많은 라우터를 거치게 되면 전송 과정 중에 패킷은 도청되어 복제될 수 있다.
라우터의 증가에 따른 홉 수의 증가는 네트워크의 응답성과도 관련 있으며 잠재적 대역폭 제약이 발생할 수 있다.
지역적 이슈
- 외부의 클라우드 컴퓨팅 인프라는 서비스 사용자의 국가나 지역과는 다른 곳에 위치할 수 있다.
- 따라서 사용자의 데이터는 네트워크를 통해서 어디서나 접근할 수 있지만 법적 분쟁이 발생하거나 데이터에 대한 접근이 완전히 보호되지 않을 수 있음을 인지해야 한다.
- 클라우드 서비스 제공자가 클라우드 컴퓨팅 인프라를 구축할 때 비용적인 측면을 고려해서 지역을 선택했을 것이지만 실제 사용자는 자신의 가상 머신이 어느 지역에 위치한 데이터 센터에서 동작하는지 인지하지 못할 가능성이 크다.
- 사용자의 데이터가 법적인 보호를 받아야 하는 경우나 인프라가 위치한 국가의 정부 기관이 사용자의 데이터를 통제할 수 있다는 사실을 인지해야 한다.
- 영국은 영국 시민의 개인정보는 영국 내에 저장해야 한다.
- 미국의 경우도 클라우드법을 통해 미국 클라우드 서비스 제공자가 보유하고 관리하는 메일, 문서, 기타 통신 자료를 포함하여 가입자 정보 등에 대해서 미국 정부 기관은 실제 데이터가 저장되어 있는 위치에 상관없이 데이터를 요청할 수 있다.
- 우리나라에 구축된 미국 기업의 클라우드 서비스라고 하더라도 데이터가 미국 정부 기관에 제공될 수 있는 법적 근거가 마련된다.
  - 한국 정부나 공공기관: 국내 CSP(Naver Cloud, KT Cloud 등) 선호

가상화

컴퓨터에서 컴퓨터 리소스의 추상화를 일컫는 광범위한 용어

물리적인 컴퓨터 리소스의 특징을 다른 시스템, 응용 프로그램, 최종 사용자들이 리소스와 상호 작용하는 방식으로부터 감추는 기술이다.

가상화의 핵심은 실제 존재하지 않는 하드웨어 플랫폼, 운영체제, 스토리지나 네트워크 리소스들을 가상적으로 제공한다는 것이다.
가상 시스템에서 일어나는 동작을 호스트 시스템으로 매핑시켜 줌 → 하이퍼바이저(Hypervisor)

가상화의 장점

적은 컴퓨팅 리소스 하드웨어 구매로 비용 절감
쉬운 백업과 복구
중단 없는 비즈니스
효율적인 IT 운영

가상화의 단점

가상화 소프트웨어 및 가상화 지원 하드웨어 구매로 초기 투자 비용 발생
소프트웨어 라이선스 비용 발생
초기 교육 필요

가상화 방식

전가상화
- 게스트 운영체제를 수정하지 않는 에뮬레이터 방식
- 하드웨어적 지원을 받는 전가상화와 소프트웨어로만 구성되는 전가상화 2가지로 구분한다.
- 하드웨어적 지원은 Intel의 VT-x 기술 또는 AMD의 AMD-V 기술이 탑재된 CPU에서만 가능하다.
- 소프트웨어적 전가상화는 바이너리 트랜스레이션 이진 변환 기법을 통해 소프트웨어적으로 명령어를 처리하는 방식이다.
- 하드웨어적 지원하는 전가상화는 다시 네이티브 방식과 호스티드 방식 둘 다 가능하지만 소프트웨어적 전 가상화는 호스티드 방식만 가능하다.
- 소프트웨어적 전가상화
  - 사용자 애플리케이션
  - 게스트 운영체제
  - VMM(운영체제 요청 바이너리 트랜스레이션)
  - 하드웨어
  - 호스트 운영체제가 일을 하고 있는 경우 사용자 애플리케이션에 작업이 발생하면 아래 3가지 방법으로 일을 처리한다.
    - 트랩: 사용자 프로그램에서 printf(”%s\n”, str) 명령을 내리면 운영체제의 쓰기 함수를 호출하고 표준 출력인 모니터로 출력하게 된다.
      - printf는 하드웨어인 모니터에게 직접 쓸 수가 없기 때문에 Trap Handler를 호출한다.
      - 사용자 모드에서 커널 모드로 전환이 되고 이 때 운영체제의 쓰기 함수를 호출해서 문자열을 출력하고 커널 모드에서 사용자 모드로 전환한다.
    - 인터럽트: 트랩이 사용자 프로그램에서 발생하는 것이면 인터럽트는 하드웨어에서 발생하는 이벤트로 USB를 시스템에 꼽을 때 NIC를 통해서 패킷을 받아들일 때 또는 키보드를 이용해서 문자를 입력할 때 등 이런 경우는 하드웨어 장치가 인터럽트를 발생시켜서 트랩 핸들러가 동작하듯이 인터럽트 핸들러가 처리를 수행한다.
      - 인터럽트는 우선순위가 있다.
    - Exception(예외): CPU에서 자동으로 발생하는 이벤트로 처리할 수 없는 명령을 만났을 때 발생한다. fault와 abort로 구분하는데 fault는 복구 가능한 에러이고 abort는 복구 불가능한 에러이다.
  - 소프트웨어적인 전가상화 방식은 VMWare가 개발한 방법인데 중간에 위치한 하이퍼바이저가 CPU가 인식할 수 있는 명령으로 변경해서 처리하기 때문에 오버헤드가 발생하고 구현이 까다롭다.
  - Xen이 단점을 극복하고자 Guest OS를 수정한 Hyper Call 방식을 제안했다.
- 하드웨어 지원 기반 전가상화
  - 소프트웨어 기반 전가상화는 바이너리 트랜스레이션을 통해서 구현되는데 이 경우는 하이퍼바이저가 소프트웨어적으로 Guest OS가 요청한 명령을 현재 CPU에 수행할 수 있는 명령으로 변환해야 해서 오버헤드가 불가피하고 성능에 대한 문제가 발생할 수 밖에 없다.
  - CPU 벤더들은 가상화를 지원하기 위한 새로운 기능이 탑재된 하드웨어를 출시한다.
  - CPU에 가상화 기술을 탑재해서 하드웨어가 직접 수행하도록 해주는 것이다.
  - Intel은 VT-x로 AMD는 AMD-V 기술로 가상화를 구현했다.
  - 사용자 프로그램이 하드웨어의 가상화 기술을 통해 직접 요청이 가능한 방식이다.
  - 게스트 OS가 트랩을 발생시킬 때 하이퍼바이저는 바이너리 트랜스레이션 없이 가상화 기술을 통해 하드웨어를 직접 제어 가능하다.
반가상화
- 소프트웨어적 전가상화의 단점을 보완하고자 등장했다.
- 반가상화의 게스트 OS는 자신이 가상화환경에서 동작하고 있다는 것을 인지한다.
- 전가상화에서는 게스트 OS가 요청을 하면 이에 맞는 바이너리 트랜스레이션을 수행해야 하는데 반가상화에서는 게스트 OS가 하이퍼바이저와 직접 통신을 수행해서 명령을 전달한다.
- 이 경우에는 게스트 OS의 소스 코드를 수정해서 하이퍼바이저와 통신이 가능하도록 만들어줘야 한다.
  - 이 방식은 오픈 소스 운영체제에서만 가능하다.
- 소프트웨어적 전가상화보다 성능이 우수하고 특정 API(I/O 나 메모리 집약형 작업)에 한해서는 하드웨어적 전가상화보다 성능이 우수하다.
하이브리드 가상화
- 반가상화와 하드웨어 기반 가상화를 조합한 방식
- 하드웨어 기반의 가상화는 하이퍼바이저를 단순하게 하고 운영체제의 수정이 필요하지 않는 전가상화로 성능을 향상시키는데 하드웨어 기반의 가상화는 반가상화보다 성능이 안 좋은 경우가 있다. (I/O작업이나 메모리 집약형 작업을 처리할 때)
- 대규모 데이터 분석을 처리하는 대형 데이터 센터 환경에서는 하드웨어 기반의 전가상화를 사용하기가 어렵다.
- 하드웨어 기반의 가상화 환경에 반가상화의 네트워크와 디스크 드라이버를 사용하게 함으로써 I/O 작업이나 메모리 집약형 작업은 반가상화가 처리하도록 해서 성능을 향상 시킨다.
운영체제 가상화
- 컨테이너화
- 물리 시스템에 설치된 운영체제 위에 컨테이너를 구동할 수 있는 컨테이너 엔진을 설치해서 컨테이너를 가상 머신처럼 관리하는 방식이다.
- 하이퍼바이저에서는 가상 머신의 운영체제는 서로 다를 수 있지만 컨테이너 기반의 가상화에서는 물리 시스템에서 동작하는 운영체제를 모든 컨테이너가 공유하는 방식이다.
- 컨테이너가 서로 다른 운영체제를 사용하면 동작할 수 없다.

가상화 대상 시스템

게스트 시스템을 호스트 시스템으로 매핑시켜주는 함수를 구현하는 방식에 다라 다양한 형태의 가상화를 정의할 수 있다.
ABI(Application Binary Interface)와 ISA(Instruction Set Architecture)로 구분한다.
ABI 레벨 가상화는 소프트웨어 애플리케이션 관점에서 시스템이 가상화된 것으로 이를 프로세스 가상 머신이라고 부르는데 이 형태로 만들어진 유명한 가상 머신이 JVM(Java Virtual Machine)이다.
- 자바 애플리케이션은 JVM만 있으면 시스템이 무엇이든 간에 동작할 수 있다.
- 특히 이런 형태의 가상화를 Runtime 이라고도 한다.
- JVM 대신에 JRE(Java Runtime Environment) 라는 표현을 사용하는 경우가 많다.
- 운영체제 위에 가상화 소프트웨어가 배치되는 구조
ISA 레벨 가상화는 명령어 집합에 대해 가상화를 한 것으로 시스템 가상 머신이라고 한다.
- 시스템 가상 머신은 하드웨어 시스템과 일반적인 소프트웨어 사이에 놓이게 된다.

프로세스 가상 머신

Multiprogrammed System

단일 프로세스가 마치 전체 시스템을 독점하여 쓰고 있는 것처럼 보이게 하는 방식

Emulator

프로세스 가상 머신에서의 Emulator는 USER ISA만을 에뮬레이션 하는 것
인터프리터 방식과 바이너리 트랜스레이터 방식으로 구분한다.
- 인터프리터 방식은 binary instruction을 하나하나 해석해서 수행하고 binary translator 방식은 source instruction을 블록 단위로 target instruction으로 변환해서 수행 시간을 단축하는 방법
- 스크립트 언어를 실행하는 것과 유사하게 스타트업 시간에 대한 오버헤드는 없지만 전체적인 속도면에서 느리고 binary translator 방식은 C/C++ 언어로 만들어진 애플리케이션처럼 스타트업에 대한 오버헤드는 존재하지만 시스템 전체적으로 시간을 단축시킬 수 있는 방식이다.

Same ISA Binary Optimizer

바이너리 트랜스레이터가 게스트와 호스트가 동일한 ISA를 사용하는 경우 최적화해서 사용하는 형태

High Level Language Virtual Machine

하드웨어와 운영체제와의 의존 관계를 최소화하는 방식으로 JVM이 대표적이다.

Hypervisor

단순하게 보면 가상화 소프트웨어로 가상 머신 모니터라고도 한다.

호스트 머신으로 불리는 물리적인 컴퓨터에 설치되어 가상 머신을 생성하고 관리할 수 있다.
하이퍼바이저는 타입1과 타입2로 구분한다.
- 차이점은 중간에 운영체제가 있으냐 없느냐
- 하이퍼바이저가 물리 시스템에 직접 설치되느냐 물리 시스템의 운영체제 위에 설치되느냐 하는

Type 1 Hypervisor

물리 시스템 하드웨어에 직접 설치되는 가상 머신

베어메탈 하이퍼바이저라고도 한다.
대표적인 하이퍼바이저로 KVM과 Xen이 있다.
대규모의 클라우드 컴퓨팅 서비스를 도입할 때 사용한다.
클라우드 서비스를 제공하는 데이터 센터에서 구축되는 시스템에 도입한다.
클라우드 서비스를 제공하는 곳에서는 신속한 확장과 축소가 가능해야 하기 때문에 확장성이 충분히 기술적으로 보장되어야 한다.
불필요한 오버헤드를 최소화해서 가상 머신에서 동작하는 애플리케이션의 실행 속도가 호스트 머신에 직접 설치되어 운영되는 성능과 근접한 결과를 만들어 낸다. (굉장히 애플리케이션이 빠르게 동작한다.)
물리 시스템이 하드웨어적으로 가상화를 지원해야 한다.
- 윈도우즈에서 CTRL + SHIFT + ESC를 눌러서 작업관리자를 열고 CPU 탭에서 가상화 사용 여부 확인
- 리눅스에서는 lscpu | grep Virtualization
VT-x 나 Vt-v로 표시되는데 full로 표시가 되면 하드웨어를 완전히 가상화해서 Guest OS가 Host 시스템과 완전히 분리되어 실행되는 환경이라는 의미이다.

Type 2 Hypervisor

호스트 머신의 운영체제 위에 마치 애플리케이션처럼 설치한다.

가상 머신을 단일 물리 시스템에 설립하고 운영하는데 있어 편리성을 제공한다.
중간에 호스트 머신의 운영체제가 동작하고 있기 때문에 호스트 머신의 하드웨어를 직접 접근할 수 없다.
간편한 하이퍼바이저이기는 하지만 타입 1 하이퍼바이저에 비해서 오버헤드가 더 많이 발생한다.
VMWare Workstation, VMWare Player, VirtualBox, Parallels Desktop for Mac, QEMU, KVM, UTM 등이 있다.
KVM은 리눅스 커널의 모듈로 동작하고 운영체제가 설치되고 사용을 해야 하기 때문에 타입 2인데 KVM이 설치된 리눅스 운영체제 자체가 타입 1하이퍼바이저가 된다고 할 수 있다.

대표적인 하이퍼바이저

KVM

Xen

Cloud Native

클라우드 네이티브 기술은 조직이 Public, Private 그리고 Hybrid Cloud와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해주는 기술로 Container, Service Mesh, Micro Service, Immutable Infra, Declarative API가 이러한 접근 방식의 예시이다.

회복성, 관리 가능성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 해주며 견고한 자동화 기능을 함께 사용하면 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주 예측 가능하게 수행할 수 있다.
Cloud Native Computing Foundation은 벤더 중립적인 오픈 소스 프로젝트 생태계를 육성하고 지원하고 유지함으로서 위와 같은 패러다임 채택을 촉진하고 최신 기술 수준의 패턴을 대중화해서 누구나 이런 혁신에 접근이 가능하도록 했다.
IT 서비스 개발 및 구현 방식의 변화
- 개발 방식
  - 35.9%: DevOps/DevSecOps
  - 31.78%: Agile/Scrum
  - 13.02%: Kanban
  - 10.02%: Waterfall
  - 5.01%: Water/Scrum/Fall
  - 4.20%: Lean
- 구현 방식
  - 개발 프로세스: Waterfall → Agile → DevOps
  - 응용 프로그램 아키텍쳐: Monolithic → N-Tier → MicroService
  - 배포 및 패키징: Physical Server → Virtual Server → Container
  - 인프라스트럭쳐: DataCenter → Hosted → Cloud
Cloud Native 적용이 필요한 이유
- 서비스 배포 시간 단축
  - Containers + Micro Service를 통해 개발 팀과 운용 팀 사이의 의사소통 향상, 상호 이해 폭 확대
  - DevOps 문화의 내재화 촉진
  - 조직 내 다양한 팀간의 마찰 감소
  - 지속적인 적용을 통한 빠른 배포 가능
  - 변경 프로세스의 복잡성 감소
  - 변경에 따른 인지된 위험 감소
- 애플리케이션 및 서비스 현대화
  - 컨테이너로 애플리케이션을 배포해서 운영 인프라에 대한 종속성 감소
  - 이전의 On-Premise 애플리케이션을 Cloud로 이관
  - Kubernetes는 모든 인프라에 컨테이너를 배포할 수 있는 단일 통합 플랫폼을 제공한다.
- 신속한 신규 서비스 개발 사이클
  - 풍부한 기술 생태계
    - 대규모 커뮤니티
    - Kubernetes 나 CNCF slack에 약 35,000명의 개발자가 참여한다.
    - 충성도 높은 커뮤니티 활동가들
  - 오픈 소스 기반
    - 개발자에게 친숙한 개발 환경 및 운영 협업 체계
    - 풍부한 개발 인력 Pool
- 사업 성장을 위한 조직 문화 혁신 촉진
  - Cloud Native는 조직의 혁신을 가속화하기 위해 새로운 문화, 기술 및 프로세스를 제공한다.
  - DevOps, CI/CD, Containerization은 서비스 개발 조직의 현대화를 촉진한다.
  - 이전보다 훨씬 빠르게 조직 문화 및 서비스 문화 변화를 촉진한다.
- IT 목표
  - 민첩성과 생산성
  - 복원력과 확장성
  - 최적화와 효율성
- 사업 성과
  - 시장 성장
  - 위험 완화
  - 비용 절감