[SeSAC 성동캠퍼스 1기] 클라우드 컴퓨팅 3일차

클라우드 컴퓨팅 서비스

[ 클라우드 컴퓨팅 서비스 프레임워크 및 기술 ]

▶ 하이퍼바이저 Hypervisor

: 하드웨어를 가상화하기 위해서는 하드웨어들을 관장할 뿐만 아니라 각각의 가상머신들을 관리할 가상머신 모니터(VMM, Virtual Machine Monitor)와 같은 중간 관리자가 필요한데, 이 중간 관리자를 하이퍼바이저 라고 하며, VM이 동작할 수 있는 환경을 제공함

 

- 특징

• 호스트 시스템에서 다수의 게스트 OS를 구동할 수 있게 하는 소프트웨어
• 하드웨어를 가상화 하면서 하드웨어와 각각의 *VM을 모니터링 하는 중간 관리자, VMM이라고도 함

*VM : 기본적으로 컴퓨터의 에뮬레이션으로 프로그램을 실제 컴퓨터처럼 실행함, VM들은 '하이퍼바이저'를 통해 물리적 기계 위에서 돌아감!

 

 

- 하이퍼바이저의 2가지 종류

베어메탈(Bare-metal) 기반	하이퍼바이저가 하드웨어 바로 위에서 실행되는 방식으로, 하이퍼바이저가 하드웨어를 직접 제어하기 때문에 자원을 효율적으로 사용할 수 있고 별도의 호스트 OS가 없으므로 오버헤드가 적지만 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어려움 ex) VMware ESX/ESXi, Xen, Microsoft Hyper-V, Oracle VM Server, KVM
호스트(Host) 기반	하드웨어 위에 호스트 운영체제가 있고, 그 위에서 하이퍼바이저가 다른 응용프로그램과 유사한 형태로 동작. 이 타입의 하이퍼바이저에 의해서 관장되는 가상머신의 게스트 OS는 하드웨어 위에서 3번째 수준으로 구동됨. 기존의 컴퓨터 환경에서 하이퍼바이저를 활용하는 것이기에 설치가 용이하고 구성이 편리한 장점이 존재. 반면 베어메탈 기반의 하이퍼바이저보다 성능이 떨어질 수 있음 ex) VMware server, VMware Workstation, VMware Player, Virtual box

 

좌) 베어메탈 기반, 우) 호스트 기반

 

 

▶ 가상화(Virtualization) vs 클라우드 컴퓨팅(Cloud Computing) 비교 ⭐

구분	가상화(Virtualization)	클라우드 컴퓨팅(Cloud Computing)
정의	기술	방법
목적	1개의 물리적 하드웨어 시스템에서 다수의 시뮬레이션 환경 생성	온디맨드 사용을 위한 가상 리소스 풀링과 자동화
용도	특정 용도의 패키징 된 리소스를 특정 사용자에게 제공	다양한 용도의 다양한 리소스를 사용자 그룹에 제공
설정	이미지 기반	템플릿 기반
평균 수명	연 단위(장기)	시간/월 단위(단기)
비용	높은 *CAPEX(자본 지출), 낮은 *OPEX(운영 비용) *CAPEX : 고정 자산 투자 *OPEX : 운영 비용	프라이빗 클라우드 : 높은 CAPEX, 낮은 OPEX 퍼블릭 클라우드 : 낮은 CAPEX, 높은 OPEX
확장성	Scale-Up	Scale-Out
워크로드	- 스테이트풀(Stateful) : 어플리케이션과 프로세스는 온라인 뱅킹이나 이메일처럼 여러 번 반환됨 - 사용자에게 받은 요청을 처리할 때마다 같은 서버 사용	- 스테이트리스(Stateless) : 프로세스 또는 어플리케이션 격리 ex) 콘텐츠 전달 네트워크(CDN), 웹, 프린트 서버
테넌시 (=테넌트)	싱글 테넌트	멀티 테넌트

 

 

▶ 클라우드 컴퓨팅 인스턴스(Cloud Computing Instance) 개념

 

- 인스턴스(Instance) : 클라우드 컴퓨팅에서 인스턴스는 타사 클라우드 서비스에서 제공하는 서버 리소스

= 껍데기인 VM에 생명을 불어넣는!

= 가상의 리소스?

• 온프레미스에서 물리적 서버 리소스를 관리하고 유지할 수도 있지만, 그럴 경우 비용이 많이 들고 비효율적! 따라서 클라우드 제공업체는 데이터 센터에서 하드웨어를 유지 관리하고 인스턴스라는 형태로 컴퓨팅 리소스에 대한 가상 액세스를 제공
• 클라우드 인스턴스를 사용하여 컨테이너, 데이터베이스, 마이크로서비스, 가상 머신 등의 컴퓨팅 집약적인 워크로드를 실행할 수 있음

클라우드 인스턴스가 중요한 이유 1. 확장성	- 개발자는 워크로드 요구 사항에 따라 클라우드 인스턴스의 컴퓨팅 리소스 조정 ex) 소프트웨어 개발자는 인스턴스에 어플리케이션 배포 - 앱이 더 많은 사용자를 확보할수록 엄청난 트래픽 발생하며 응답 시간 느려지게됨 - 개발자는 CPU, 메모리, 스토리지 및 네트워크 리소스를 특정 인스턴스로 늘려 클라우드 리소스를 수평적으로 조정 가능
클라우드 인스턴스가 중요한 이유 2. 내결합성 ⭐	- 조직에서는 백업을 위해 여러 중복 인스턴스를 사용해 중복성 만듦. 특히! 데이터 처리와 같이 메모리 집약적인 워크로드 관리하는 데 유용함 ex) 유럽에서 호스팅 되는 클라우드 인스턴스에 장애가 발생하더라도 어플리케이션은 미국과 아시아의 다른 인스턴스에서 계속 실행될 수 있음

 

- AWS 인스턴스 종류 ⚠️개념 확실하게 짚고 넘어가기!

• General Purpose Instances *범용 목적 인스턴스
• Compute Optimized Instances *컴퓨팅 최적화 인스턴스
• Memory-Optimized Instances *메모리 최적화 인스턴스
• Accelerated Computing Instances *가속화된 컴퓨팅 인스턴스
• Storage Optimized Instance *스토리지 최적화 인스턴스

*범용 목적 인스턴스

: 컴퓨팅, 메모리, 네트워킹 리소스를 균형있게 제공 하며, 다양한 워크로드에 적합

> 종류 : A1, M5, T3/T3a

 

*컴퓨팅 최적화 인스턴스

: 고성능 프로세서를 제공 하며, 컴퓨팅 집약적 어플리케이션 및 배치 처리 워크로드에 적합

> 종류 : C5/C5n/C5d, C6/C6g

(숫자가 높을수록 고성능, 고비용)

(알파벳은 h/w vendor)

 

*메모리 최적화 인스턴스

: 메모리 집약적 워크로드를 위한 빠른 성능을 제공하며, 고성능 데이터베이스 에 적합

> 종류 : R5/R5a/R5n, X1/X1e, High memory

 

*가속화된 컴퓨팅 인스턴스

: 하드웨어 액셀러레이터를 사용하여 데이터 처리를 가속화하며, 어플리케이션 스트리밍 및 그래픽 워크로드에 적합

> 종류 : P3, P2, Inf1, G3, G4, F1

 

*스토리지 최적화 인스턴스

: 낮은 지연 시간 및 높은 IOPS(초당 입출력 작업 수)를 제공하며, 분산 파일 시스템 및 데이터 웨어하우징 어플리케이션 과 같은 워크로드에 적합

> 종류 : D2, H1, I3/I3en

 

 

▶ 가상머신(Virtual Machine) vs 컨테이너(Container) ⭐⭐

 

 

▶ 컨테이너(Container)

 

- 장점

응용프로그램 동작환경	어플리케이션 레벨 고립
환경구축 시간	하이퍼바이저 기반의 가상머신(VM)보다 빠른 셋업
메모리 사용	하이퍼바이저 기반의 가상머신(VM)보다 메모리 덜 소모
응용프로그램 마이그레이션 및 전송 속도	마이그레이션, 백업, 전송이 쉬움 (가상머신과 비교해 크기가 작기 때문)
성능	하드웨어와의 빠른 커뮤니케이션에 따라 성능에 효과적일 수 있음
응용프로그램 배치 및 유지보수	어플리케이션 배치와 유지보수를 향상시키는 효과가 있음
데이터 전달 속도	어플리케이션 전달 시간 감소

 

- TOP10 컨테이너 종류 ⚠️상식적으로 알고있자 :) ....

1. Docker : 세계에서 많이 사용하고 있는 오픈 플랫폼

2. Kubernetes : Docker와 같이 전세계에서 많이 사용하고 있는 컨테이너로, Kubernetes는 컨테이너화된 관리를 위한 이식이 가능하고 확장 가능한 오픈 소스 플랫폼

3. AWS Fargate : 서버를 관리하지 않고도 어플리케이션 구축에 초점을 맞출 수 있도록 지원하는 종량제 서버리스 컴퓨팅 엔진

4. Google Kubernetes Engine(GKE) : 구글 인프라를 사용하여 컨테이너식 어플리케이션을 배포, 관리, 확장할 수 있는 관리형 환경을 제공하는 서비스

5. Amazon ECS/ECR/EKS

• ECS(Elastic Container Service) : Docker 지원 컨테이너
• EKS(Elastic Kubernetes Service) : Kubernetes 지원 컨테이너
• ECS가 EKS보다 좀 더 가상화 레벨이 높은 것으로 분류
• ECR(Elastic Container Registry) : Img 저장

6. Core OS Container Linux : RedHat의 컨테이너 네이티브 운영체제, 변경 가능한 컨테이너 최적화 Linux 호스트 제공

7. Microsoft Azure Container(AKS) : Azure에서 관리되는 Kubernetes 클러스터 배포형 서비스

8. LXC(LinuX Container) : 단일 컨트롤 호스트 상에서 여러 개의 고립된 리눅스 시스템(컨테이너)들을 실행하기 위한 운영 시스템 레벨 가상화 방법

9. Portainer : Docker 등 클라우드 환경에서 컨테이너를 쉽게 이동하고 배포할 수 있도록 하는 도구

10. COCKTAIL CLOUD(나무기술) : Kubernetes 기반 국산 클라우드 네이티브 플랫폼

 

❓도커와 쿠버네티스 구조

⚠️ 도커와 쿠버네티스에서의 용어 차이가 있으니 주의하자!

 

 

▶ 쿠버네티스 Kubernetes

: Linux 컨테이너 작업을 자동화하는 오픈소스 플랫폼

 

- 쿠버네티스 플랫폼에서는 컨테이너화된 어플리케이션을 배포하고 확장하는 데 수동 프로세스가 필요 x

= Linux 컨테이너를 실행하는 호스트 그룹을 함께 클러스터링할 수 있으며 쿠버네티스를 통해 이러한 클러스터를 쉽고 효율적으로 관리 가능!

 

- 클러스터는 퍼블릭 클라우드, 프라이빗 클라우드 또는 하이브리도 클라우드 전체로 호스트 확장 가능

 

쿠버네티스 Kubernetes 주요 기능	설명
오케스트레이션	쿠버네티스를 이러한 워크로드를 위해 규모에 맞는 컨테이너를 배포하는 데 필요한 오케스트레이션 및 관리 기능을 제공
관리 기능	쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 어플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리 가능. 쿠버네티스 활용하면 IT 보안 한층 강화 가능
쿠버네티스 구축환경 요건	쿠버네티스는 종합적인 컨테이너 인프라 제공할 수 있도록 네트워킹, 스토리지, 보안, 텔레메트리, 기타 서비스와 통합해야 함
어플리케이션 리소스 관리 가능	하드웨어를 최대한 활용해 엔터프라이즈 어플리케이션을 실행하는 데 필요한 리소스를 극대화, 어플리케이션 배포 및 업데이트를 제어하고 자동화, 스토리지를 장착 및 추가해 스테이트풀 어플리케이션을 실행

 

 

- 쿠버네티스 구조

• CLI : 쿠버네티스 클러스터에 명령을 내리는 CLI(Command Line Interface로 terminal window에서 명령어로 kubectl 동작 가능
• Master Node : 쿠버네티스 클러스터의 핵심적 컴포넌트(Controller Manager, API Server, etcd, Scheduler)로 구성되어있음. 마스터 노드에는 일반 Pod들이 스케줄링 되지 않는데 이는 마스터 노드가 일반 Pod를 스케줄링 하지 않도록 Taint가 설정되어 있기 때문
• Control Plane : Control Plane의 구성 요소는 클러스터에 대한 전역 결정(ex. 스케줄러)을 수행하고 클러스터 이벤트를 감지하고 응답함 ex) 새 포드 배포의 필드가 충족되지 않은 경우! Control Plane 구성 요소는 클러스터의 모든 시스템에서 실행 가능
• Kube API Server : API 서버는 Kubernetes API를 노출하는 Kubernetes 제어부의 구성 요소. API 서버는 Kubernetes 제어부의 프론트 엔드. 쿠버네티스 API 서버의 주요 구현체는 Kube API Server로 이는 수평으로 확장되도록 설계되었으며, 더 많은 인스턴스를 배치하여 확장함. 여러 Kube-API Server 인스턴스를 실행하고 해당 인스턴스 간의 트래픽 균형 조저 가능
• Scheduler : 할당된 노드가 없는 새로 생성된 포드를 모니터링하고 해당 포드를 실행할 노드를 선택하는 제어부 구성 요소. 스케줄링 결정을 위해 고려되는 요소는 개별 및 집합적 리소스 요구사항, 하드웨어/소프트웨어/정책 제약 조건, 선호도 및 반선호도 사양, 데이터 인접성, 워크로드 간섭 및 마감 시간 등
• Controller-Manager : 컨트롤러 프로세스를 실행하는 컨트롤 플레인 구성 요소. 논리적으로 각 컨트롤러는 별도의 프로세스이지만 복잡성 줄이기 위해 모두 단일 이진법으로 컴파일 되어 단일 프로세스로 실행됨

노드 컨트롤러	노드가 중단될 때 이를 인식하고 응담
작업 컨트롤러	일회성 작업을 나타내는 작업 개체를 관찰한 다음 포드를 만들어 해당 작업을 실행하여 완료
EndpointSlice 컨트롤러	EndpointSlice 개체를 채움(서비스와 포드 간의 링크 제공)
서비스 계정 컨트롤러	새 네임스페이스에 대한 기본 서비스 계정 만들기

 

• etcd : 모든 클러스터 데이터에 대한 Kubernetes의 백업 저장소로 사용되는 일관되고 가용성이 높은 키 값 저장소. Kubernetes 클러스터에서 etcd를 백업 저장소로 사용하는 경우 해당 데이터에 대한 백업 계획 수립해야 함
• Worker Node : 컨테이너가 배포될 물리 서버 또는 가상 머신. 노드 구성 요소는 모든 노드에서 실행되며 실행 포드를 유지하고 Kubernetes 런타임 환경을 제공
• Pod : 단일 노드에 배포된 하나 이상의 컨테이너 그룹이며, Pod라는 단위로 여러 개의 컨테이너를 묶어서 Pod 단위로 관리할 수 있게 해줌
• Container Runtime : 컨테이너 실행 담당 소프트웨어. 쿠버네티스는 컨테이너 런타임, CRI-O와 같은 컨테이너 런타임 지원함
• Container : 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 소프트웨어 패키지. 운영체제를 가상화 하며 프라이빗 데이터 센터에서 퍼블릭 클라우드 또는 개발자의 개인 노트북에 이르기까지 어디서나 실행 가능
• Kubelet : 클러스터의 각 노드에서 실행되는 에이전트로 컨테이너가 포드에서 실행중인지 확인하는 역할. Kubelet은 다양한 메커니즘을 통해 제공되는 Pod Spec 집합 사용하며 이러한 Pod Spec에 설명된 컨테이너가 실행되고 정상적으로 작동하도록 보장하며, Kubelet은 쿠버네티스와 만들지 않은 컨테이너를 관리하지 않음
• Kube-Proxy : 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스 서비스 개념의 일부 구현. Kube-interval은 노드에서 네트워크 규칙을 유지 관리하는데 이러한 네트워크 규칙을 사용하면 클러스터 내부 또는 외부의 네트워크 세션에서 포드와 네트워크 토신 가능. Kube-filters는 운영체제 패킷 필터링 계층이 있고 사용 가능한 경우 사용하는데 그렇지 않으면 kube-proxy는 트래픽 자체를 전달함
• Persistent Storage : 퍼시스턴트볼륨(PV)은 관리자가 프로비저닝 하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스. 퍼시스턴트 볼륨 클레임(PVC)은 사용자의 스토리지에 대한 요청으로 Pod와 비슷. Pod는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용함
• Container Registry : 컨테이너 이미지를 저장하고 액세스하는 데 사용되는 레포지토리 또는 레포지토리 모음. 컨테이너 레지스트리는 종종 DevOps 프로세스의 일부로 컨테이너 기반 어플리케이션 개발 지원 

 

▶ 도커 Docker

: 컨테이너 기반의 오픈소스 가상화 플랫폼 중 하나로, Docker를 사용하면 인프라에서 어플리케이션을 분리하여 컨테이너로 추상화 시켜 소프트웨어를 빠르게 제공할 수 있으며, 이는 주어진 하나의 호스트 OS 안에서 여러 컨테이너를 동시에 실행 가능!

 

- 도커는 컨테이너의 라이프 사이클을 관리하고 어플리케이션을 오케스트레이션(Work flow의 자동화)된 서비스로 배포 가능

ex) 백엔드 프로그램, DB 서버, 메시지 queue 등 어떤 프로그램도 컨테이너로 추상화 가능하고 조립 PC, AWS, Azure, NBP 등 어디에서든 실행 가능

 

- Docker Engine Architecture 동작 및 구조

 

▶ Cloud Native Container Security의 4C ⭐

: 클라우드 네이티브 보안의 4C는 클라우드(Cloud), 클러스터(Cluster), 컨테이너(Container), 코드(Code)!

 

- 계층화된 접근 방식은 보안에 대한 심층 방어 컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 널리 알려져있음

 

- 4C 구조

• 클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 함
• 코드 계층은 강력한 기본(클라우드, 클러슽, 컨테이너) 보안 계층의 이점을 제공함
• 코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준 보호 불가

 

 

 

 

▶ DevSecOps 프로세스

 

 

 

▶ DevSecOps 프로세스 및 관련 솔루션 ⭐⭐⭐⭐

 

---

 

💡오늘의 특강!

[ ZTA : Zero Trust Architecture ]

IAM이란 무엇입니까? - AWS Identity and Access Management

 

---

 

오늘의 후기!

: 살려주세요