클라우드

728x90

2023-09-25

Cloud

클라우드의 개념과 이론들을 알아보겠습니다

이후 가벼운 실습까지

1. On - Premise

기업이 자체 데이터 및 솔루션을 저장하기 위해서 데이터 센터(전산실)를 구축해서 IT 서비스를 수행하는 방식
하드웨어를 포함한 모든 자원에 대한 초기 투자 비용과 탄력적이지 않은 제한된 용량으로 인해 지속적 관리 비용이 증가하는 단점이 있지만 기업에 내재화된 서비스를 통해 품질 및 보안에 대한 신뢰도는 높은편
- 초기 투자 비용은 On-Premise 가 높지만, 오랜 시간 사용한다면 On-Premise가 이득

On-Premise는 설계를 할 때 자원 사용량을 최대로 설계

2. Cloud Computing

컴퓨터와 소프트웨어를 자신이 소유하는 것이 아니라 네트워크를 통해 클라우드 사업자의 컴퓨터와 소프트웨어를 서비스로서 사용하는 것
IT 자산을 소유하는 것이 아니라 서비스로 이용하는 모델
사용자는 네트워크와 인터넷 그리고 자원이 어디에 있는지 몰라도 됩니다.
- 몰라도 사용이 가능 -> Transparency(투명성)

2.1) 클라우드가 등장하기 까지의 흐름

메인 프레임
클라이언트 - 서버 컴퓨팅
- 서버가 여러 개 일 수 있음
네트워크 컴퓨팅 - 그리드 컴퓨팅
클라우드

2.2) 보급된 배경

자원이 저렴
네트워크의 발달

2.3) 정의

NIST(미국 국립 표준 기술 연구소)의 정의
공유 구성이 가능한 컴퓨팅 리소스의 통합을 통해 어디서나 간편하게 요청에 따라 네트워크를 통해 접근하는 것을 간으하게 하는 모델

2.4) 특징

주문형 셀프 서비스 : 사업자와 직접 상호 작용하지 않고 사용자의 개별 관리 화면을 통해 서비스를 이용할 수 있음.
광범위한 네트워크 접속 : 모바일 기기 등의 다양한 디바이스를 통해 서비스에 접속할 수 있음
리소스 공유
신속한 확장성
- Scale Up : 처리 능력을 높이는 것
- Scale Down : 처리 능력을 낮추는 것
측정 가능한 서비스 : 이용한 만큼 요금을 지불

2.5) 장점

경제성
자동화 : 업데이트, 보안 패치, 백업 등
이동성 : 웹을 이용할 수 있는 모든 장치에서 사용 가능
리소스 공유
가용성 : AWS의 경우 기본적으로 99.99% 이상의 가용성을 제공
빠른 구축 속도
확장성
- Scale Up : 하드웨어 자체의 성능을 업그레이드
- Scale Out : 동일한 컴퓨터를 추가하는
중복성 또는 탄력성 : Business Continuity Management(BCM)
- AWS 글로벌 인프라

2.6) 단점

Internet Access
Security
Privacy
Vendor Lock On

2.7) 클라우드와 OnPremise

비용
- OnPremise : 초기 투자 비용이 많이발생
- Cloud : 초기 투자 비용은 없음
- 5년 정도 동일한 시스템을 사용한다면 5년 후에는 On-Premise 가 비용 절감 효과가 나타남
확장성 비교
- On-Premise
  - 자사 시스템의 개별 요구 사항에 따라 설계
  - 시스템의 도입과 확장에는 고도의 기술력을 갖춘 인재가 필요
- Cloud
  - 클라우드 사업자가 설계 및 구축
  - 중소 기업이 대기업에 필적하는 규모의 서비스를 이용할 수 있음
안정성과 신뢰성
- 클라우드의 리스크
  - IaaS의 리스크로는 클라우드 사업자의 하드웨어 장애로 인한 데이터 손실이나 서비스 중단
  - 가상 서버를 백업하거나 쉽게 가상 서버 환경을 구축하기 위한 템플릿을 마련하는 것이 대책
- 클라우드의 보안 거버넌스
  - 기업 사용자는 자사가 뵤유한 정보의 관리와 처리를 클라우드 사업자에게 맡겨 버리기 때문에 보안 등의 리스크를 통제할 수 없다는 문제가 발생
  - 클라우드 보안 거버넌스(Governance - 기업의 경영진이 클라우드를 이용할 때의 위험을 주체적이고 적절하게 관리하기 위한 구조를 구축하고 운용하는 것)의 관점에서 바라보면 클라우드 서비스의 Incident 와 서비스 복구와 같은 사항들은 제어가 어렵고 클라우드 사업자의 갑작스런 파산이나 서비스 중단과 같은 서비스의 연속성 리스크 또한 존재
  - 대부분은 알려진 클라우드를 사용하고 멀티 클라우드 형태를 취하게 됨.
  - 사업자 및 이용자 측에 잠재된 보안 위험 요소를 확인해두고 클라우드 사업자와 이용자 사이의 책임 분계선 등 이용자가 관리할 수 잇는 범위를 파악한 후 보안 대책과 백업을 마련할 필요가 있음
- SaaS
  - 사용자 책임(관리)
  - 어플리케이션 : 사용자 책임
  - 개발 도구 : 사업자 책임
  - 미들웨어 : 사업자 책임
  - OS : 사업자 책임
  - 하드웨어 : 사업자 책임
- PaaS
  - 사용자 책임(관리)
  - 어플리케이션 : 사용자 책임
  - 개발 도구 : 사용자 책임
  - 미들웨어 : 사업자 책임
  - OS : 사업자 책임
  - 하드웨어 : 사업자 책임
- IaaS
  - 사용자 책임(관리)
  - 어플리케이션 : 사용자 책임
  - 개발 도구 : 사용자 책임
  - 미들웨어 : 사용자 책임
  - OS : 사용자 책임
  - 하드웨어 : 사업자 책임

2.8) 클라우드 서비스 종류

직접 구축 여부	IaaS	PaaS	SaaS
애플리케이션	애플리케이션(구축)	애플리케이션	제공
데이터	데이터(구축)	데이터	제공
런타임	런타임(구축)	제공	제공
미들웨어	미들웨어(구축)	제공	제공
OS	OS(구축)	제공	제공
가상화	제공	제공	제공
서버	제공	제공	제공
스토리지	제공	제공	제공
네트워킹	제공	제공	제공

IaaS(Infrastructure as a Service) :
- 사용자에게 인프라 자원을 사용할 수 있도록 해주는 클라우드 서비스
- 컴퓨터를 빌려주는 개념
- 가장 대표적인 서비스가 AWS의 EC2(Elastic Compute Cloud)
- 모든 CSP 사업자는 이 서비스를 퍼블릭으로 제공
PaaS(Platform as a Service) :
- 서비스 개발자가 애플리케이션 개발, 실행, 관리 등을 할 수 있도록 안정적인 플랫폼 또는 프레임 워크를 제공하는 클라우드 서비스 방식
- 원하는 소프트웨어를 직접 개발해서 사용하기 때문에 SaaS 보다 자유도가 높지만 다른 환경으로의 마이그레이션이 어려울 수 있음
- 세일스 포스의 Force.com, 사이보우즈의 Kintone, Cloud Foundary, GCP(Google Cloud Platform), Service Now, Oracle DBMS on Cloud(OCI)
  - 개발 도구 - SDK, 프레임워크(Ruby on Rails, Spring, Node.js, Eclipse 등)
  - 핵심 기능 - 프로그래밍 언어(Ruby, Java, Python, PHP 등), Application Server(Apache Tomcat, Jboss 등), 데이터 베이스(MySQL, PostreSQL, MongoDB, Amazon RDS, Oracle, MS SQL Server 등), 메세지 미들웨어(RabbitMQ, Amazon SQS, kafka 등), 애플리케이션 통합, 비지니스 프로세스 관리, 데이터 통합, 관리 파일 전송, 보안, 테스트 환경, Chat GPT의 코드 interpreter 등
SaaS(Service as a Service :
- 사용자가 필요한 소프트웨어를 제공하는 서비스
- 하나의 서버를 여러 기업에서 공유하는 것을 전제로 한 멀티 터넌트 서비스를 제공하지만 데이터는 기업 상용자 별로 분리되도록 설계해서 보안성을 확보
- SaaS 의 대표적인 서비스가 Google Apps, Salesforce, MS Office 365, Naver Office 등
DaaS(Desktop as a Service :
- 데스크톱을 빌려주는 서비스
- SaaS 와 IaaS의 결합

2.9) 클라우드 이용 모델

Public Cloud
- 클라우드 서비스 공급자(AWS, GCP, Azure, Oracle, Naver 등)가 시스템을 구축하고 인터넷 망 등의 네트워크를 통해서 불특정 다수의 기업과 개인에게 서비스를 제공하는 형태
Private Cloud
- 폐쇄적인 구조
- 특정 기업의 특정 사용자만을 대상으로 하는 클라우드 서비스
- 자사가 보유하고 운용하는 형태로 만들 수 있고(On-Premise Private Cloud) 클라우드 사업자가 장비를 보유하고 프라이빗 클라우드 서비스를 제공하는 형태(Hosted Private Cloud)로 구축
Community Cloud
- 공통의 목적을 가진 특정 기업들이 클라우드 시스템을 구축해서 데이터 센터에서 공동 운영하는 형태
Hybrid Cloud
- Private Cloud 와 Public Cloud를 조합하는 방식
- 기업 내부의 민감하고 중요한 데이터 처리 작업은 통제력을 강화하기 위해서 Private Cloud를 사용하고 일반 업무 데이터 처리와 같이 보안 요구사항이 낮거나 워크로드가 지속적으로 증가하는 작업 또는 애플리케이션을 여러 곳에 배포해야 하는 작업은 Public Cloud로 구성

2.10) 가상화

클라우드를 지탱하는 2대 기술 중 하나
컴퓨터의 물리적인 메모리와 하드 디스크, 운영체제등 다양한 것들을 소프트웨어로 대체하는 기술
물리적인 컴퓨터 1개를 가지고 여러 개의 논리적인 컴퓨터를 만드는 기술
복제가 쉽고 대수를 늘리거나 줄이는 것도 쉬워짐

2.11) 분산 처리와 로드 밸런서

분산 처리는 여러 대에 나누어서 처리하는 기술
여러 대에 분배하는 장치를 Load Balancer 라고 합니다

2.12) 이중화

시스템이나 서버에 문제가 생겨도 계속 가동할 수 있도록 조치를 하는 것

3. Cloud Native

3.1) 개요

동적인 환경(클라우드 환경)에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있도록 해주는 기술
Container, Service Mesh, Microservice, Immutable Infra, Declarative API 등
회복성, 관리 편의성, 가시성을 갖춘 느슨한 결합(Loosly Coupling)을 가진 시스템
벤더 중립적인 오픈 소스 프로젝트 생태계

3.2) Pillas of Cloud Native

DevOps
Microservice
Containers
Continuous Delivery

3.3) DevOps

IT 서비스 설계, SW 개발, 릴리즈 및 운영에 이르기까지 전체 서비스 수명 주기에 함께 참여하는 IT 서비스 운영 및 개발 엔지니어의 업무방식
- PLAN -> CODE -> BUILD -> TEST -> RELEASE -> DEPLOY -> OPERATE -> MONITOR 의 주기적 반복(전체가 아닌 한 팀 내에서 이를 수행) SI-SM

3.4) CD

DevOps 의 자동화 부문의 기원
지속적 통합(Continuous Integration)과 연계
- 소스 제어에 자주 코드 커밋
- 각 코드 커밋에 자동화된 빌드를 실행
- 결과 => 더 빠른 오류 감지
지속적 전달(Continuous Delivery)
- 최종 사용자를 위한 릴리스 코드 빌드
- 결과 => 최종 사용자에게 소프트웨어를 더 빨리 제공

3.5) Microservices

애플리케이션을 상호 독립적인 최소 구성 요소로 분할
느슨한 결합 - 한쪽의 변화가 다른 쪽에 영향을 최소로 주어야 한다

3.6) Container

실행에 필요한 모든 파일을 포함하여 전체 실행 환경에서 애플리케이션을 패키지화하고 분리하는 기술

3.7) IT 서비스 개발 및 구현 방식의 변화

개발 방식
- 35.9% > DevOps/DevSecOps : 개발과 운영을 한꺼번에 고려해서 개발
- 31.78% -> Agile/Scrum : 애자일 방식 중 스크럼 방식
- 13.02% -> Kanban : (간판)
- 10.02% -> Waterfall
- 5.05% -> Wate/Scrum/Fall
- 4.20% -> Lean
Development Process
- waterfall -> agile -> devops
Application Architecture
- Monolithic(모든 서비스를 하나로 묶는 형태) -> N-Tier(계층 별 분할) -> Microservices
Deployment and Packaging
- Physical Server -> Virtual Server -> Containers
Application Infrastructure
- Data Center -> Hosted -> Cloud

3.8) Cloud Native 적용이 필요한 이유

서비스 배포 시간 단축 : Containers + Microservices 를 통해 개발 팀과 운영 팀 사이의 의사 소통 향상
애플리케이션 및 서비스 현대화
신속한 신규 서비스 개발 사이클
- 풍부한 기술 생태계
  - 대규모 커뮤니티
  - kubenetes 및 CNCF slack에 많은 개발자가 참여
  - 충성도 높은 커뮤니티 활동가들
- 오픈 소스 기반
  - 개발자가에게 친숙한 개발 환경 및 운영 협업 체계
  - 풍부한 개발 인력 Pool
사업 성장을 위한 조직 문화 혁신 촉진
- 조직의 혁신을 가속화하기 위해 새로운 문화, 기술 및 프로세스를 제공
- DevOps, CI/CD, Containerization 은 서비스 개발 조직의 현대화 촉진
- 이전보다 훨씬 빠르게 조직 문화 및 서비스 문화 변화 촉진
IT 목표
- 민첩성과 생산성
- 복원력과 확장성
- 최적화와 효율성
사업 성과
- 시장 성장
- 위험 완화
- 비용 절감

3.9) CNCF Trail Map

Product
Development
Capacity Planning
Testing + Release Procedures
Postmortem/ Root Cause Analysis

4. DevOps

4.1) Agile and ITIL

Agile
- 반복적인 개발 주기와 자기 조직화 된 팀을 강조하는 일련의 관행
- manifesto
  - 개인과 개인 간의 상호작용이 프로세스 및 툴 보다 우선
  - 작동하는 소프트웨어가 포괄적인 문서보다 우선
  - 고객과의 협업이 계약 협상보다 우선
  - 변화에 대응하는 것이 계획을 따르는 것보다 우선
ITIL(IT Infrastructure Libarary)
- IT 인프라 운영의 최고 사례를 모아 발간
- 2019년 ITIL v4 부터 Agile, Lean, DevOps 등의 방법론 과의 연계성을 강화하는 Service Value System 개념으로 체계 변환

4.2) DevOps

IT 서비스 설계, SW 개발, 릴리즈 및 운영에 이르기까지 전체 서비스 수명 주기에 함께 참여하는 IT 서비스 운영 및 개발 엔지니어의 업무 방식
애플리케이션 개발에서 프로덕션 운영에 이르는 전체 프로세스를 소유하는 방법론
일련의 기술 구현을 넘어 문화와 프로세스의 완전한 변화를 요구
기술이 아닌 철학이며 변경이 아닌 변화

4.3) 변화

SOA => Microservices
Agile Team => Mode2, DevOps, Agile Mindset
Cloud Infra Automation => CI/CD
이 모든 것이 ENterprise DevOps의 개념으로 변화하는 중

LIST

IT 황밤