1. 클라우드 컴퓨팅이란?
*온디맨드 제공: 사용자가 리소스가 필요한 순간에 바로 자원 제공 가능
-> +사용한 만큼에 대해서만 비용을 지불
2. 클라우드 컴퓨팅 배포 모델
1) 클라우드 기반 배포 = 퍼블릭 클라우드
-> 어플리케이션의 모든 부분이 클라우드 상에서 실행됨
2) 온프레미스 배포 = 프라이빗 클라우드
-> 클라우드를 활용해서 리소스 활용도를 높임
3) 하이브리드 배포
-> 클라우드 기반 리소스를 온프레미스 인프라에 연결한다
3. 클라우드 컴퓨팅의 이점
1) 선행 비용을 가변 비용으로 대체한다
-> 선행 비용은 데이터센터와 같이 미리 투자를 사용해야 사용 가능한 리소스를 사용하는 경우에 발생한다
사용자는 실제로 사용하는 리소스에 대해서만(가변적) 비용을 지불하여 서비스 개발 비용이 절감된다
2) 거대한 규모의 경제로 얻게 되는 이점
-> 클라우드 사용자가 증가할수록 종량제를 통한 요금 감소의 효과가 더 커짐
1. 아마존 EC2(Elastic Compute Cloud)
-> 하나의 서비스가 아닌, 다양한 서비스를 포함한다(EC2, EBS, ELB, ASG 등)
*가상 서버에 접근하는데 사용되는 서비스
*아마존 EC2 인스턴스의 형식으로 제공됨
1) 설정 옵션
*OS: 리눅스, 윈도우, 맥 OS
*CPU(Central Processing Unit): 가상머신에 사용할 컴퓨팅 성능과 코어 개수
*RAM(Random Access Memory): 메모리의 크기
*Storage Space, Network Card, Firewall rules(보안그룹), Bootstrap script(그 카클에도 있는 사용자 머시기) 등 설정 가능
@EC2 User Data
= 인스턴스가 부팅될 때 실행되는 스크립트/데이터로 주로 EC2 인스턴스의 초기 설정을 자동화하는 데 사용된다.
*bootstrapping : 머신이 작동할 때 명령을 시작하는 것, 부트 작업을 자동화하는 것
*스크립트는 처음 시작할 때 한번만 실행되고 다시 실행되지 않음. 인스턴스 시작 이후에는 수정 불가
*암호화되지 않은 텍스트로 저장되므로 민감한 정보를 포함해서는 안된다.
2) EC2 인스턴스 유형
1. 범용 인스턴스
-> 리소스를 균형있게 제공한다
2. 컴퓨팅 최적화 인스턴스(C로 시작)
-> 컴퓨팅 집약적인 어플리케이션에 적합하다
3. 메모리 최적화 인스턴스
-> 대규모 데이터을 처리하는 워크로드에 적합하다
@워크로드란?
= 특정 작업을 완료하거나, 결과를 만들기 위해 필요한 처리 작업의 양과 유형
4. 가속 컴퓨팅 인스턴스
-> 그래픽, 게임 등 복잡한 워크로드에 적합
5. 스토리지 최적화 인스턴스
-> 대규모 데이터 집합에 대한 순차적 읽기 및 쓰기 엑세스가 많이 필요한 워크로드를 위해 설계됨
예로 분산 파일 시스템, 데이터웨어하우징 어플리케이션 등
3) 보안그룹
-> 카카오클라우드와 비슷. 허용 규칙만 포함하는 화이트리스트 방식을 사용한다(모든 인바운드 트래픽 차단)
-> IP 주소(v4, v6)나 다른 보안그룹(@default) 을 참조할 수 있다
*다대다 연결 가능. 한 인스턴스에 여러개 보안그룹/ 한개 보안그룹을 여러개 인스턴스에 연결할 수 있다
*EC2 외부에 있다. 트래픽이 차단되면 EC2 인스턴스는 확인할 수 없다
@기본 포트
22 == SSH(Secure Shell) 접속을 위해 열어야 함(리눅스 타입 인스턴스 원격 접속)
80 == http 접속을 위해 열어야 함
443 == https 접속을 위해 열어야 함
3389 == RDP(Remote Desktop Protocol) 접속을 위해 열어야 함(윈도우 타입 인스턴스 원격 접속)
@SSH
-> 원격 접속이 가능하게 해주는 응용 프로그램 또는 그 프로토콜
4) EC2 Instance Connect(EIC)
-> 키 파일 없이도 IAM 권한을 통해 안전하고 편리하게 인스턴스에 ssh로 접속할 수 있도록 함
* 보안 키 없이 인스턴스에 접근 가능, AWS 콘솔 버튼 클릭 한번으로 서버 접근
-> 보안성과 편의성이 높다
-> IAM 을 사용하면 IAM 정책과 역할로 권한을 제어할 수 있고, CloudTrail에 모든 접속 기록이 남는다
*Amazon Linux 2 에서만 작동.. 최신 버전 OS 이미지에는 EIC 에이전트가 기본 설치되어 바로 쓸 수 있다
*접속하려는 사용자에게 SendSSHPublicKey 권한이 부여되어 있어야 하고, 접속 대상인 인스턴스의 22번 포트는 열려있어야 함
5) EC2 인스턴스 요금
1. EC2 On-Demand(기본)
*Linux/Windows : 1분 이후 초 단위로 청구
*다른 모든 OS : 시간 단위로 청구
-> 장기적인 약정 필요 없음
-> 단기적이고 중단이 없는 워크로드에서 추천됨(곧이 곧대로라 비싸서)
2. EC2 Reserved Instances(예약)
-> 리소스 자체가 아닌 할인 약정을(더 쓸거에요~) 예약하는 개념.
*온디맨드에 비해 최대 72퍼 할인을 제공
*예약 기간: 1년/3년(할인율 더 높음)
*결제 옵션: 후불/부분 선결제/전액 선결제
*인스턴스 scope: Regional / Zonal(가용영역)
-> 사용량이 일정한 어플리케이션에 추천됨
-> 예약된 인스턴스를 Marketplace 에서 사고 팔 수 있음
@Convertible 예약 인스턴스
-> 인스턴스 유형, 인스턴스 패밀리, OS 등을 변경할 수 있지만 할인율이 더 낮다
3. EC2 Savings Plans(최대 72퍼)
*1년 또는 3년 시간당 10달러로 약정!
*사용량이 한도를 넘어서면 온디맨드 가격으로 청구된다(일반 예약도 마찬가지)
-> 특정 인스턴스 패밀리, 리전으로 고정되고 나머지 옵션은 유연하다
4. EC2 스팟 인스턴스
*미사용 EC2 인스턴스의 컴퓨팅 용량을 사용하며, 온디맨드의 최대 90퍼까지 비용 절감 가능
-> 해당 인스턴스에 대한 수요가 늘면 스팟 인스턴스가 중단될 수도 있음
-> 시작/종료 시간이 자유롭거나 중단되어도 괜찮은 워크로드에 적합하다(백그라운드 처리..)
@Spot Instance Requests
*max spot price를 설정한다. 현재 가격 < max 가격 일 때 인스턴스를 얻을 수 있음
-> 현재 가격이 사용자가 지정한 최대 가격보다 높아지면 언제든지 인스턴스가 종료될 수 있다
나는 현재 가격을 기준으로 지불하기 때문이다.
-> 현재 가격은 AWS가 남는 서버의 수요와 공급에 따라 매시간 자동으로 책정한다
최대 가격이란 : 내가 이 금액까지는 스팟 인스턴스에 대해 지불할 수 있어!(예산 마지노선)
1. one-time
-> 요청이 이행되는 즉시 스팟 인스턴스가 시작된다. 일회성 요청이기 때문에 요청이 사라진다.
2. persistent
-> 유효기간 동안 사용자가 요청한 스팟 인스턴스들이 계속 유효하다.
가격 상승을 이유로 인스턴스가 방해받은 경우에도 요청이 다시 검증되고 나면 스팟 인스턴스가 재시작된다.
즉, 스팟 요청이 자동으로 생성된 스팟 인스턴스를 재시작한다.
**스팟 인스턴스를 영구히 종료하기 위해서는 먼저 스팟 요청을 취소한 다음, 연관된 인스턴스를 종료해야 한다.
5. EC2 Dedicated Hosts(전용 호스트)
-> EC2 인스턴스 용량이 완전히 사용자 전용으로 할당된 물리적 서버, 가장 비싸다
-> 법규/규정 준수 요구 사항을 만족할 수 있고, 기존 보유한 소프트웨어 라이센스를 등록해서 사용할 수 있다(라이센스 추가 구매 비용 절감)
6. EC2 Dedicated Instances(전용 인스턴스)
-> 다른 인스턴스와 물리적으로 격리된 인스턴스, 인스턴스 배치에 대한 제어가 없다
(인스턴스 정지 후 하드웨어 이동 가능)
-> 원래 EC2는 물리 서버 한 대를 여러 기업이 가상머신의 형태로 공유하지만,
전용 인스턴스는 다른 회사의 가상머신과 물리적으로 격리된다.. 이때 어떤 랙에 넣을지는 AWS가 결정
즉, 보안/규제 준수가 목적이다('내꺼'를 지키는건 전용 호스트)
7. EC2 Capacity Reservation
*지정된 특정 AZ에서 필요한 기간 동안 온디맨드 인스턴스의 용량을 예약할 수 있다
-> 필요할 때 언제든지 EC2 용량에 엑세스할 수 있다
-> 약정 기간이 없고, 요금 할인이 없음
-> 인스턴스를 실행하든 안 하든 온디맨드 요금 부과
-> 특정 AZ에서 실행해야 하는 단기적이고 중단되지 않는(뽕을 뽑는..) 워크로드에 적합
1. EC2 크기 조정
-> 확장성을 위해서는 사용자 수요 변화에 자동으로 대응하는 아키텍처가 필요하다.
1) 확장성과 고가용성
*Scalability = 어플리케이션이 조정을 통해 더 많은 양을 처리할 수 있는 능력
1. Vertical Scalability(수직 확장) = 스케일 업/다운
*인스턴스의 크기를 확장하는 것. 보통 한계가 존재함..
*RDS, ElastiCache는 수직 확장이 가능하다(DB와 같이 분산되지 않은 시스템에서 흔히 사용)
2. Horizontal Scalability(수평 확장) = 스케일 아웃/인
*어플리케이션의 (같은 사양의) 인스턴스 수를 늘리는 것
-> 분산 시스템이 있다는 것을 의미함
-> Auto Scaling group / 로드밸런서
*High Availability = 수평 확장과 함께 사용되는 개념
-> 시스템이 적어도 두 개 이상의 리전/가용영역 에서 가동중인 것을 의미한다
-> 고가용성의 목표: 시스템 무중단
2) 로드 밸런서
*왜 로드밸런서를 사용하는가?
-> 부하를 다수의 인스턴스로 분산하기 위해서(부하 분산)
-> 어플리케이션에 단일 엑세스 지점을 노출함(DNS)
-> 정기적인 헬스체크로 인스턴스 관리 easy
*왜 ELB(Elastic Load Balancer)인가?
-> AWS가 관리하는 로드 밸런서로, 자체 로드밸런서를 설정할 때의 노력이 필요없어짐
-> 다수의 AWS 서비스와 연동되어 편리함을 제공
-> 정적 DNS 이름을 제공!!!
1. Health Checks(상태 확인)
*특정 포트와 라우트(/health)에서 수행
-> 응답이 200이 아니면 해당 인스턴스는 건강하지 않은 상태이다
-> 로드밸런서가 전달하는 트래픽을 처리할 수 있는 인스턴스의 가용성을 파악함
1. 로드밸런서
-> 모든 http/https 트래픽을 허용함(받음)
2. EC2 인스턴스
-> 로드밸런서로부터 오는 http 트래픽만 허용함
2. 로드밸런서 종류 - 4가지
1. Classic Load Balancer - 시험 제외
2. Application Load Balancer(ALB)
*http/2 와 Websocket 지원, 리디렉션 지원
@http/2란?
= 기존 http/1.1의 성능 한계를 극복하기 위해 설계된 네트워크 프로토콜
**주요 특징
*멀티플렉싱: 하나의 TCP 연결로 여러개의 요청과 응답을 동시에 주고받을 수 있음(병렬 처리)
*바이너리 프레이밍: 텍스트 기반이던 기존 방식과 달리 데이터를 바이너리 형태로 인코딩하여 전송 속도를 높이고 오류를 줄임
*헤더 압축: 중복되는 헤더 정보를 압축해서 전송하는 데이터 양을 최소화한다
*서버 푸시: 클라이언트가 요청하지 않은 CSS등의 리소스를 미리 캐시에 넣어서 웹 페이지 로딩 속도를 크게 향상시킴
@Websocket 이란?
-> 클라이언트와 서버 간 지속적인 TCP 연결을 유지해서 양방향으로 실시간 데이터를 주고받을 수 있게 하는 프로토콜
**주요 특징
*실시간 양방향 통신(Full-Duplex) : 클라이언트만 서버에 정보를 요청할 수 있는 일반적인 http 통신과 달리,
양쪽 모두가 원할때 언제든 데이터를 보낼 수 있음
*낮은 오버헤드: http 핸드셰이크 이후에는 추가 헤더 정보 없이 최소한의 데이터(프레임)만 주고받기 때문에
네트워크 부담이 적다
*지속 연결: 한번 맺어진 연결은 명시적인 중단이 없다면 유지된다
@리디렉션이란?
-> 사용자가 원하는 원래 주소 대신, 사전에 지정된 다른 주소로 자동으로 방향을 돌리는 기능
*http(7계층, Application layer) 전용 로드밸런서
*여러 Target group 간 다수 http 어플리케이션의 라우팅에 사용됨
**Target Groups
1) EC2 인스턴스(auto scaling group으로 관리될 수 있음) - http
2) EC2 작업(EC2 자체에서 관리됨) - http
3) 람다 함수 - http 요청이 JSON 이벤트로 변환됨
4) IP 주소 - 프라이빗 IP여야 함
-> ALB의 헬스 체크는 대상 그룹 수준에서 이루어진다.
**대상 그룹에 따른 라우팅
1) URL 경로를 기반으로 라우팅
2) URL 호스트 이름을 기반으로 라우팅
3) 쿼리 스트링, 헤더를 기반으로 라우팅
*동일 EC2 인스턴스 상의 여러 어플리케이션에 대한 로드밸런싱 지원
-> 이때 각 프로그램은 서로 다른 포트번호를 사용해서 구별된다(쇼핑 앱/로그인 앱/결제 앱 등)
-> 마이크로 서비스나 컨테이너 기반 어플리케이션에 가장 적합하다
@어플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
-> 클라이언트의 실제 IP는 X-Forwarded-For 에 삽입됨
-> 포트와 프로토콜(X-Forwarded-Port/Proto) 도 얻을 수 있다.
3. Network Load Balancer(NLB)
4. Gateway Load Balancer(GWLB)
3) Auto Scaling
와 로드밸런서