클라우스 서비스 모델

On-Premise

• 사용자 관리 범위: 전부
• 예시: 자체 서버/DB
• 사용 목적: 완전한 통제
• 서버/스토리지: 직접 운영
• OS/미들웨어: 직접 설치
• 앱 개발/배포: 직접
• 유지보수: 전부 직접

IaaS

• 사용자 관리 범위: 앱 OS
• 예시: AWS EC2, Azure VM
• 사용 목적: 유연한 서버, OS 환경 구축
• 서버/스토리지: 제공자 관리
• OS/미들웨어: 직접 설치
• 앱 개발/배포: 직접
• 유지보수: 일부 직접

PaaS

• 사용자 관리 범위: 앱, 데이터만
• 예시: Google App Engine
• 빠른 앱 개발/배포
• 서버/스토리지: 제공자 관리
• OS/미들웨어: 제공자 제공
• 앱 개발/배포: 제공자 환경에서
• 유지보수: 거의 없음

SaaS

• 사용자 관리 범위: 없음(사용만)
• Gmail, Dropbox, Tableau
• 사용 목적: 완제품 소프트웨어 사용
• 서버/스토리지: 제공자 관리
• OS/미들웨어: 제공자 제공
• 앱 개발/배포: 사용만 함
• 유지보수: 없음

서비스 패러다임의 변화(Monolithic to Microservice Architecture)

Microservice Architecture

• 모든 기능이 하나의 애플리케이션에
  통합
• 전체 시스템을 함께 배포
• 변경 시 전체 코드 영향
• 전체를 확장해야 함
• 통일된 스택만 사용 가능
  

Microservice Architecture

• 각 기능을 개별 서비스로 분리
• 서비스 단위로 독립 배포 가능
• 변경 시 서비스 단위 유지
• 필요한 서비스만 확장 가능
• 서비스별 다양한 기술 스택 허용

호스트 패턴당 서비스 인스턴스

Virtualization(서버 가상화)

• 하드웨어 자원을 논리적으로 분할하여 여러 개의 운영 환경을 생성하는 기술
• 물리 서버 한 대에 여러 개의 가상 서버를 올릴 수 있음
• 대표 기술: VMware, Hyper-V, KVM 등

장점

• 하드웨어 비용 절감
  미사용 자원 줄이고, 전력 및 공간도 절약
• 배포 및 확장 속도 향상
  물리 장비 구매 없이 가상 머신 즉시 복제 가능
• 백업 및 복원 용이
  VM 단위로 스냅샷 백업/복원 가능
• 관리 효율성 향상
  관리자 오버헤드 감소
  → 다른 핵심 업무 집중 가능

서버 외 가상화 기술

장점2

하드웨어 격리

• 다양한 OS와 하드웨어 환경을 가상으로 분리하여 실행 가능.
• 노후 시스템 지원 및 테스트베드 구축에 유리

하드웨어 비용 절감

• 여러 애플리케이션을 하나의 서버에 통합하여 비용 절감.
• SWAP-C(크기, 무게, 전력, 냉각) 최적화 가능

시스템 관리 용이성

• 하드웨어 수 감소로 관리 부담 감소. 성능 모니터링 및 중앙 집중 관리 도구 사용 가능

성능 향상

• 처리량 증가, 응답 시간 단축. 클라우드 기반 애플리케이션에 적합

운영 가용성

• 장애 조치(Failover), 복구 기능으로 시스템 가용성 증가.
• 리소스 동적 할당 지원

격리성

• VM 간 메모리, 시간 독립성 확보 (공간적·시간적 격리)

안정성 및 견고성

• 하나의 VM에 장애가 발생해도 다른 VM에는 영향 없음.
• 복구 및 재시작이 쉬움

유연성

• 여러 OS 인스턴스를 한 기기에서 동시에 실행 가능.
• 하드웨어 에뮬레이션으로 다양한 환경 구성 가능

확장성

• 다수의 VM과 프로세서를 하나의 하이퍼바이저로 효율적 관리.
• 단, 리소스 요구 증가 고려

안전성 및 보안

• 공격, 오류, 맬웨어의 영향을 단일 VM에 한정.
• 하이퍼바이저 기반 보안 정책 적용 및 신속한 VM 교체/복원 가능

단점

하드웨어 리소스

• 가상화 계층의 오버헤드 로 리소스 요구량 증가
• VM, 하이퍼바이저, 게스트 OS로 인해 CPU·RAM·스토리지 등 자원 요구 증가.
• 단, 기존 환경에 따라 절감 효과도 가능

공유 리소스

• 리소스 공유로 단일 장애 지점 및 간섭 가능성 존
  재
• L3 캐시, 메모리, I/O 등 공유
  → VM 간 간섭 발생 가능성 및 성능 저하 위험

간섭

• VM 간의 간섭으로 격리 위협 (시간적·공간적)
• VM 수가 많아질수록 간섭 경로 복잡성 증가.
• 대표 경로 선택 필요

분석

• 시간 분석 어려움 및 보수적 예측치 증가
• 정확한 간섭 분석이 어려우며, 실시간 시스템에서는 일정 위반 가능성 존재

안전

• 실시간 보장 어려움
  → 안전 재인증 필요

보안

• 하이퍼바이저가 새로운 공격 경로가 될 수 있음
• 보안 격리 실패 시, 한 VM에서 다른 VM으로 공격 확산 가능성 있음

성능

• 응답 지연, 지터, 콜드 스타트 증가 등으로 실시간성 저하
• 성능 일관성 부족, 하이퍼바이저 계층의 처리 지연 발생

품질

• 테스트 복잡성 증가 및 결함 밀도 상승 가능
• 하이퍼바이저와 VM은 일반 OS보다 결함률이 높고, 동시성 이슈 존재

비용

• 아키텍처 설계·테스트·라이선스 비용 증가 가능
• 오픈소스를 쓰지 않으면 상용 VM/하이퍼바이저의 비용 부담 증가

가상머신 vs Container

성능 관점

보안 관점

• Container는 Host 커널 공유로 인한 위협 존재
• VM은 Guest 커널이 별오이기에 다른 vm이나 host에 영향이 없음
• 즉 컨테이너는 빠른 배포, DevOps, 경량 서비스에 적합하고
• VM은 보안이 중요한 엔터프라이즈, 금융, 공공기관 등에 적합함
  

Docker Architecture

Docker Engine 의 구성요소 Docker daemon + REST APIs + Docker CLI

Docker Daemon (dockerd)

• 컨테이너 생성, 이미지 빌드, 이미지 푸시/풀, 볼륨 설정 등 핵심 작업을 실제 수행

Docker REST API

• Docker Client와 Daemon 간의 통신 통로 역할.
• HTTP 방식으로 명령 주고받음

Docker CLI (docker 명령어)

• 개발자가 사용하는 터미널 인터페이스, 명령어 입력 수단
  (예: docker build, docker run)

가상머신 vs Docker Architecture

Kubernetes Architecture

컨테이너화된 애플리케이션을 쉽게 배포/관리할 수 있게 해주는 소프트웨어 시스템

Control Plane

전체 클러스터를 제어하고 작동하는 역할

Data Plan

실제 Pod이 배포되고 실행되는 작업 자 영역

API Server

사용자, 컨트롤 플레인 구성 요소와 통신
모든 명령의 입구, Kubernetes와 사용자 사이의 인터페이스

Scheduler

애플리케이션의 배포
Pod이 어느 노드에 실행될지 결정

Controller Manager

구성 요소 복제본, 워커 노드 추적, 노드 장애 처리 등의 클러스터 수준의 기능을 수행
지속적인 상태 조정 역할 수행

Etcd

분산 데이터 저장소
설정과 상태 저장소

Worker nodes

실제 컨테이너화된 애플리케이션을 실행하는 시스템
실제 애플리케이션이 실행되는 서버

Container Runtime

도커, rkt 같은 컨테이너 런타임

Kublet

API 서버와 통신하고, 노드의 컨테이너를 관리
각 노드의 에이전트 역할

Kube Proxy

애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱
네트워크 통신 중계

쿠버네티스 개요

• 애플리케이션 실행과 운영을 위한 통합 자동화 플랫폼
• 컨테이너 이미지로 패키징 된 애플리케이션을 레지스트리에 등록
• 애플리케이션 디스크립션을 API 서버에 전달
• 스케줄러는 각 컨테이너에 필요한 리소스를 계산하여 컨테이너 할당
• 쿠블렛은 컨테이너 런타임인 도커를 통해 이미지를 가져옴
• 가져온 이미지를 통해 애플리케이션이 기동됨
  

Container Background

Linux Namespaces

• Namespaces 는 한 프로세스의 집합이 하나의 리소스 집합을 바라보도록 할 수 있으며, 또 다른 프로세스의 집합이 다른 리소스 집합을 볼 수 있도록 분할 하는 리눅스 커널의 기능
• "리소스"는 리눅스의 프로세스 ID, 호스트 이름, 이용자 이름, 파일명 등을 말함
• Namespaces 는 한 프로세스의 집합이 하나의 리소스 집합을 바라보도록 할 수 있으며, 또 다른 프로세스의 집합이 다른 리소스 집합을 볼 수 있도록
  분할 하는 리눅스 커널의 기능

Mount namespace

▪ Mount : 프로세스와 자식 프로세스 사이에 격리된 파일시스템을 제공
▪ Process ID : 프로세스 ID 를 1부터 다시 부여할 수 있는 격리된 공간을 제공
▪ Network : 네트워크 환경을 분리하여 새로운 IP 부여가 가능한 격리된 공간을 제공
▪ Interprocess Communication : 프로세스간 통신의 접근 제어를 지원
▪ Unix Timesharing : hostname 식별자를 유지 관리 기능
▪ Control group : 자원 (메모리, CPU, I/O, 네트워크, 디바이스)의 제어

IPC & Network namespace

• IPC = (InterProcess Communication Namespace)

Cgroups