Cloud Computing
-
물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여하는 것
➜ 가상화(Virtualization) 기술 -
기업에서 직접 리소스를 조달하거나 구성, 관리할 필요가 없음
✔ 클라우드 서비스의 장점
-
컴퓨팅 능력을 유연하게 조절 가능
-
고정적 비용이 들어가는 온프레미스와 달리, 사용한 만큼의 요금만 지불
-
컴퓨터의 스냅샷(이미지)을 이용해 다른 컴퓨터로 즉시 이주(migration) 가능
온프레미스??
- 필요한 시스템을 구축하기 위해 솔루션을 자체적으로 보유한 전산실 서버에 직접 설치하고 운영하는 방식
- 프로세스를 전부 도맡아 처리
- IT 서비스를 공급하는 제공자가 직접적으로 자원을 관리하는 주체가 됨
- 고정적인 관리 비용
💡 클라우드 vs 온프레미스
✔ 클라우드
- 초기비용 X
- 사용한 만큼 요금 지불
- 확장성이 유리함
- 구축에 필요한 시간이 적음
ﾠ
✔ 온프레미스- 초기 비용 + 유지 비용
- 확장성이 불리함
- 구축에 필요한 시간이 많음
✔ 클라우드 서비스의 단점
- 운영 환경 자체가 클라우드 제공자에게 종속됨
➡️ 클라우드 서비스에 문제가 생기면 내가 배포 및 관리하는 환경에도 영향이 미침💡 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다??
백엔드 구성 자체가 특정 회사의 기술로만 구성해야 하는 경우가 발생할 수도 있다는 의미이다.
대표적인 클라우드 서비스의 형태
✅ IaaS (Infrastructure as a Service)
- 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우
✅ PaaS (Platform as a Service)
- 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우
✅ SaaS (Software as a Service)
- 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우
🍕 맛있는 피자를 먹는다고 생각해보자!
On-site➡️ 내가 재료부터 요리, 세팅까지 하기IaaS➡️ 밀키트나 냉동제품을 사서 먹기 (기본적인건 갖춰져 있다!)PaaS➡️ 배달 시켜 먹기 (파스타를 먹을 장소만 있으면 👌)SaaS➡️ 매장에 가서 먹기 (내가 할 일은 아무것도 없다!)
Deploy(배포)
- 개발한 서비스를 사용자가 이용 가능하게 하는 일련의 과정
서비스 배포 과정
🔅 Development
- 개발 단계
- local 컴퓨터 환경에서 개발 및 테스트
- 모든 구성원이 각자의 환경에서 진행
- Sample Data(Dummy Data) 이용
- 변경사항이 생겨도 문제 X
🔅 Integration
- 코드간 Conflict가 없는지 확인하는 단계
- 각자의 환경에서 개발된 부분을 취합
- 작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인
🔅 Staging
- 모든 관계자들에게 검증하는 단계
- Production 단계와 가장 유사한 환경에서 테스트
- 복제된 실제 데이터를 이용해 테스트
🔅 Production
- 실제로 서비스가 제공되는 단계
- 개발 환경과는 구분된 환경
- 실제 데이터를 이용
⚠️ Development 환경과 Production 환경은 서로 다를 수 있다. (JDK version, endpoint, ...)
배포에서는 환경 설정을 코드와 분리하는 것이 중요하다.
🤔 작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
-
설정을 환경 변수에 저장
➡️ 코드의 변경 없이 배포할 때마다 쉽게 변경 가능
➡️ 코드 저장소에 올라갈 가능성이 낮음💡 환경 변수 == environment variable / envvars / env
-
절대경로 대신 상대경로를 사용
-
환경에 따라 포트를 분기할 수 있도록 환경 변수를 설정
➡️.yml,.properties등 -
(Advanced) 개발 환경 자체를 통일시키는 솔루션
➡️ Docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아 아예 모든 개발 환경을 통일
💡 애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은?
어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것
EC2
-
Elastic compute Cloud
Elastic : 탄력적인
ㅤ➡️ 사용한 만큼의 비용을 지불한다.- 비용뿐만 아니라 필요에 따라 성능, 용량을 자유롭게 조절 가능
-
아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스
🤔 클라우딩 컴퓨팅 서비스란?
인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스
ㅤ➡️ 아마존에서 가상의 컴퓨터를 빌리는 것과 같다.
❗ 정리하자면 AWS EC2란 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스다.
💡 Instance(인스턴스)
- 1대의 컴퓨터를 의미하는 단위
- AWS에서 컴퓨터를 빌리는 것 == 인스턴스 생성
장점
-
구성하는 데 필요한 시간이 짧음
- 몇 번의 클릭만으로 PC를 구성
-
AMI를 통해 필요한 용도에 따라 다양한 운영체제 선택 가능
- CPU, RAM, 용량까지 손쉽게 구성 가능
🤔 AMI란?
- Amazon Machine Image
ㅤ - 인스턴스를 생성하는데 필요한 소프트웨어 구성이 기재된 템플릿
ㅤ - AWS에서 빌릴 PC는 사용 용도에 맞게 운영체제, 런타임 등이 구성된 Setting을 선택할 수 있음
ㅤ - 이미지 종류로는 운영체제
(윈도우, 우분투, 리눅스 등)만 설치된 템플릿을 설치할 수도 있고,
특정 런타임이 설치된 템플릿(우분투 + node.js / 윈도우 + JVM 등)이 제공되는 경우도 있음
ㅤ - 다양한 AMI 세팅이 준비되어 있음
➡️ 선택된 이미지를 바탕으로 인스턴스의 운영체제가 결정됨- 손쉽게 운영체제 구성 가능
- 세팅된 AMI 이외에도 필요에 따라 직접 구성 가능
💡 AWS EC2 인스턴스를 생성한다는 것은
AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌린다는 것이다.
RDS
- Relational Database Service
- AWS에서 제공하는 관계형 데이터베이스 서비스
🤔 EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하지 않고, RDS를 사용하는 이유?
- EC2 인스턴스는 데이터베이스와 관련해 자동으로 관리를 담당하는 부분이 매우 한정적
➡️ 사용자가 일일이 데이터베이스 엔진 설치와 버전 관리, 데이터 백업 등의 일을 해야 함
➡️ 가용성과 내구성 확보 X
--> DB에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률⬆️, 이후에 DB 규모 확장이 어려움
ㅤ- RDS를 이용하면 DB 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리함
➡️ 초기 설정을 제외하면 사용자가 해야 할 일은 DB에 저장된 데이터를 관리하는 일밖에 없음
➡️ 편의성👍
장점
-
데이터베이스 유지 보수와 관련된 일들을 자동으로 관리
-
다양한 데이터베이스 엔진 선택지를 제공
➡️ 실무자는 회사에 필요한 DB 엔진을 취사선택하여 이용
➡️ 일반 사용자는 필요와 목적에 맞게 DB 엔진을 선택해 효율성👍
S3
- Simple Storage Service
- AWS에서 제공하는 클라우드 스토리지 서비스
🤔 클라우드 스토리지란?
- 인터넷 공간에 데이터를 저장하는 저장소
- 컴퓨터 부품으로 치면 하드디스크 역할
ㅤ- Google Drive, MYBOX(네이버), Onedrive(마이크로소프트) 등
ㅤ
✅ 장점- 뛰어난 접근성
ㅤ➡️ 하드디스크의 경우, 저장된 파일에 접근하려면 해당 컴퓨터를 이용해야만 함
ㅤ➡️ 클라우드 스토리지의 경우, 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있음
장점
-
뛰어난 접근성 (클라우드 스토리지와 같음)
-
높은 확장성
- 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장, 축소 가능
- 스토리지의 용량을 무한히 확장 가능
-
비용적인 측면에서 매우 효율적
- 사용한 만큼만 비용을 지불
-
높은 내구성
- 스토리지 내구성이 높으면 저장된 파일의 유실 가능성이 적어짐 (S3는 99.99999%의 내구성 보장)
-
높은 가용성
- 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어짐
- S3는 연간 99.99%의 스토리지 가용성을 보장
-
다양한 스토리지 클래스 제공
- 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라짐
💡 S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스
🔅 Standard 클래스- 범용적인 목적
- 데이터에 빠른 속도로 접근 가능
- 데이터 액세스 요청에 대한 처리 속도가 빠름
- 데이터를 오래 보관하는 목적으로는 부적합 ➡️ 보관 비용이 높음
🔅 Glacier 클래스
- 장기적인 보관 목적
- 저장된 데이터에 액세스 하는 속도는 느리나, 데이터를 보관하는 비용이 매우 저렴
이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등 여러 가지 스토리지 클래스가 존재함
-
정적 웹 사이트 호스팅 가능
🤔 정적 웹사이트 호스팅이란?
- 정적 파일 : 서버의 개입 없이 클라이언트에게 제공될 수 있는 파일
- 동적 파일 : 서버가 요청에 맞춰 그 자리에서 생성한 파일
- 웹 호스팅 : 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스
- S3에서는 버킷을 통해 정적 웹 사이트 호스팅이 가능
❗ 버킷
- 파일을 담는 바구니 (최상위 디렉토리)
- 무한히 많은 파일 저장 가능
- 버킷명은 각 리전에서 고유해야 함
- 버킷 정책을 생성해 액세스 권한 부여 가능
❗ 객체
- 버킷에 담기는 파일
- 파일과 메타데이터로 구성
- 모든 객체는 고유한 키를 가짐
- URL 주소를 통해 객체에 접근 가능
- URL 주소 형식 :
http://[버킷명].S3.amazonaws.com/[객체의 키]
· · ·
🌏 Region(리전)
- AWS에서 클라우드 서비스를 제공하기 위해 운영하는 물리적 서버의 위치
- 지도에서 파란 동그라미가 있는 지역 (붉은 동그라미는 제공 예정)
🌏 Availability Zone(가용 영역)
- 각 리전에 존재하는 데이터 센터(IDC)
- 각각의 개별적인 위치에 떨어져서 존재
➡️ 어느 곳이 기동이 불가해져도 다른 곳에서 백업 데이터를 활용해 문제없이 서버가 가동되게 하기 위함
3 Tier-Architecture 배포 전략
Client Application 배포
- AWS에서 제공하는 S3 서비스를 통해 Client를 사용자에게 제공 가능
🤔 Client를 위해 EC2 인스턴스를 사용해야 할까?
- 클라이언트를 정적 파일로 빌드하여 배포
➡️ S3 이용
❗빌드란?
- 불필요한 데이터를 없애고 통합, 압축하여 배포하기에 최적화된 상태를 만드는 것
➡️ 데이터의 용량이 줄어들며 웹 사이트 로딩 속도가 빨라짐- 일반적인 의미로는 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정
- 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있음
Server Application 배포
💡 Server Application
- 사용자가 제공받은 Client Application을 통해 요청과 응답을 주고 받는 역할
- AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스 제공 가능
데이터베이스 배포
- AWS가 유지 보수 작업을 담당하는 RDS를 이용해 즉시 데이터베이스를 사용할 수 있음
- RDS 서비스를 이용해 EC2를 통해 배포된 Server Application의 데이터를 저장하고 제공하는 데이터베이스 배포 가능
💡 DNS
-
평소 이용하는 Google 등의 서비스는
www.google.com과 같은 도메인 주소를 이용해 접근함
➡️172.217.151.228같은 IP 주소 입력 X -
S3, EC2를 이용해 배포된 서비스는 IP 주소나 AWS에서 제공하는 긴 도메인 주소를 통해 접근하게 됨
🤔 TodoList 서비스를 제공한다면?
www.todolist.ap-northeast-2.compute.amazonaws.com보다는www.todolist.com일 때, 직관적으로 서비스를 이해할 수 있음- AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해 서비스에 접근할 수 있음
