가상머신
전통적 배포방식
- 물리적인 컴퓨터 한 대에 하나의 OS를 깔고 여러가지 프로그램을 설치하는 방식
- 계정을 나눠 여러 명의 사용자가 이용할 수 있도록 하지만 어떤 프로그램을 설치했을 때 다른 앱에 영향을 미침
가상화 배포방식
- 가상머신을 기반으로 배포하는 방식
- 가상머신 : 컴퓨터의 하드웨어를 소프트웨어적으로 구현한 것
- 계정을 나누는 것이 아니라 한대의 컴퓨터를 가지고 여러 개의 OS를 구동할 수 있게 되며 CPU, RAM을 물리적으로 갈아끼는 것이 아니라 설정만으로 이를 수행할 수 있게 됨
- 하이퍼바이저 : 하나의 시스템 상에서 가상 컴퓨터를 여러 개 구동할 수 있도록 해주는 중간계층
- 이 위에 여러 개의 가상머신을 구축하고, 가상머신 위에 OS, 그리고 그 위에 앱이 올라가는 형태
- 클라우드는 이러한 ‘가상화’라는 기술 덕분에 한 대의 하드웨어로 여러 명의 사용자들에게 독립적으로 클라우드 서비스를 제공할 수 있다.
- 독립적으로 가상머신이 구축되어 서로 전혀 상호작용하지 않고 한 가상 머신 위의 프로그램은 다른 가상머신 위의 프로그램에서 볼 수 없는 형태 → ‘샌드박스 되었다’라고도 한다.
- 단점 : OS 공유가 안되기 때문에 가상머신에 일일히 OS를 설치해야 한다.
오프프레미스 방식
- 서드파티 공급업체가 인프라, 시설 및 관련 서비스를 제공하고 유지 관리
- 클라우드 서비스는 내가 아닌 다른 회사의 공급자가 호스팅하고 인터넷을 통해 사용자에게 제공되는 인프라, 플랫폼 또는 소프트웨어를 말한다.
- 이를 이용하면 자체 인프라나 하드웨어 설치 없이도 애플리케이션과 리소스에 쉽고 저렴하게 접근 가능 (임대)
온프레미스 방식
- 기업이 자체적으로 IT 인프라를 소유, 관리 및 운영 (구축)
- 네트워크를 설비적으로 설치하는 것 부터 시작해 서버, 데이터베이스 설치 등을 하는 것
- ex) 네이버의 프라이빗 IDC
laaS, PaaS, SaaS
laaS
- Infrastructure-as-a-Service
- 인프라형 클라우드 서비스
- 클라우드가 단지 인프라를 제공한다. node.js, MongoDB 등을 개발자가 직접 설치해야 하지만 특정 서비스에 종속X (빈 방을 제공하는 것)
- ex) AWS EC2, NCP
PaaS
- Platform-as-a-Service
- 플랫폼형 클라우드 서비스
- 클라우드가 플랫폼을 제공한다. node.js, MongoDB 등이 설치되어 있으며 해당 서비스를 이용할 수 있다. 모니터링, CI/CD가 제공된다.
- ex) heroku
SaaS
- Software-as-a-Service
- 서비스형 클라우드서비스
- 완전한 서비스를 클라우드서비스로부터 제공받아 사용한다.
- ex) 구글 DOCS
IaaS vs PaaS
- IaaS
- 빈 방에 설치한 것들을 더 큰 서버로 이전 → 유연성과 이식성이 높을 수 밖에 없다.
- 하나하나 직접 구현 → 비용 효율 낮다.
- PaaS
- 빌트인 방식 (컴포넌트가 나누어져 있다) → 플랫폼에 종속되어 있기에 서버 이전하기가 쉽지 않다.
- 클릭 하나로 설치 가능하며 logging, CI/CD, 모니터링 등 비용 효율이 높다.
컨테이너
- 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 코드와 모든 종속성을 패키징하는 소프트웨어의 표준 단위
- 컨테이너는 OS를 공유하기 때문에 빠르고, 경량화되어있으며 격리성도 훌륭하다.
- 단점 : OS에 문제가 생기면 다른 앱에도 영향을 미칠 수 있다.
도커
- 컨테이너를 만들어주는 플랫폼으로, 컨테이너 배포에 필요한 거의 모든 기능을 제공한다.
- IaaS 와 PaaS의 장점(유연성, 이식성, 비용 효율)을 모두 가지고 있다.
- 도커의 과정
- 도커파일 : 패키지, 환경변수설정 등을 기록한 파일. 이를 빌드해서 도커 이미지로 변환한다.
- 도커 이미지 : 컨테이너 실행에 필요한 파일과 설정값, 데이터 등을 포함한 상태값이며 불변
- 하나의 이미지에서 여러 개의 컨테이너 생성 가능
- 컨테이너의 상태와는 무관하게 이미지는 그대로 존재
- 도커 컨테이너 : 컨테이너가 실행시키면 도커이미지에 설정된 프로그램, 데이터 등이 실제 컴퓨팅 자원과 연결된다.
- 이미지와 컨테이너는 독립적이다.
CI/CD
- Continuous Integration/Delivery & Deployment
- 지속적으로 코드를 합치고 배포하는 과정
- 여러 명의 개발자가 시스템 없이 수동적으로 병합 및 배포 → 문제 발생
- 이를 위해 CI/CD라는 개념이 도래했고 이를 쉽게 해주는 툴이 등장
CI/CD 파이프라인
- 코드 구축부터 시작해서 배포까지의 일련의 과정으로, 총 3가지 단계로 구성됨
- 1 단계 : Continuous Integration
- 2단계 : Continuous Delivery
- 3단계 : Continuous Deployment
- 이를 프로덕션, 즉 실제 서비스에 배포하는 과정
- 장점
- 코드 배포까지 좀 더 체계화된 과정을 거치게 된다.
- 테스트 강제→ 파이프라인 자체 내에 테스트가 있기 때문에 테스트가 없으면 병합이 불가능
Continuous Integration
- 빌드
- 테스트
- 단위 테스트 : 함수 등 작은 단위 테스트
- 통합 테스트 : 모듈을 통합할 때 하는 테스트
- 엔드 투 엔드 테스트 : 사용자가 서비스를 사용하는 상황을 가정해서 하는 테스트
- 머지
- 코드 병합 과정 (git, svn)
- 충돌을 최소화 시켜야함
- 충돌은 대부분 불가피 → 더 작은 단위로 충돌이 일어나게 해야한다.
Continuous Delivery
- 배포
- 사용자를 위한 서비스 배포 뿐만 아니라 QA엔지니어나 관리자 페이지를 위한 배포, 데이터 웨어하우스로부터 데이터를 가공하여 백엔드를 위해 배포하는 행위 등을 포괄한다.
Continuous Deployment
- 툴
- 대표적으로 github action, genkins, circle ci가 있으며 heroku를 통해 CI/CD 설정 없이 자동 가능
- heroku + github action 으로 설정도 가능