클라우드 컴퓨팅 2강~5강

2강

1. 비교 : on-premise vs 클라우드 (장단점)

1) on-premise의 문제점

- over-provisioning, under-provisioning / maintenance 못함

- scaling up / scaling down(capacity를 높이기, 줄이기) 가 어려움

 

2) 클라우드

: computing as utility - 누구에게나 제공

장점

pay-as-you-go

increased scalability

모든 것이 at scale하게 갖춰져 있음 

SLA (service level agreement)에 availability, reliability 명시

 

단점

overlapped boundary

infrastructure service는 선택권이 적음

limited portability : migrate하기가 어려움

multi-regional compliance and legal issues (cloud는 worldwide인데 국가별로 상황이 다름. src code를 바꿔야 할 수도)

 

 

2. cloud 구성요소

SNS ; Servers, Networking equipment, Storage

1) Server

• 장점 : reliability, large number of requests
• blade server : 1u server * 42 = 1 rack
• heterogeneous servers
  • 이걸 모아주는게 cluster : top에 network switch가 서버(=머신=노드)끼리 연결해주고(1u), 그 밑에 노드들(37u), 그 밑에 스토리지(4u)
• hdd vs ssd(nvm flash)
  • hdd : mechanical, magnetic, random access, cheaper but slow
  • ssd : electrical, speedy, expensive

 

2) networking

- 3-party providers

- data 구조 : bus, tree, ring, star

 

3) storage

- disk trays(hdd) vs ssd & nvm flash

- computing server는 따로, 얘네들이 storage server를 share해서 쓰기도 함

- cluster : 비슷한 machine(internet끼리, 데이터 서버끼리) 묶어서 rack에 저장

- 데이터 센터 : 쿨링 팬이 굉장히 중요(air conditioning), rebundant power(비상시 backup power) / underwater datacenter

- coast에 위치한 이유? 사람이 많아서, 바다를 건널 경우 latency가 적어서, 싸서

 

 

3강

1) cloud platforms : 어떤 서비스 형식으로 deliver? 각 서비스별로 뭘 제공하는지

SaaS : 인터넷 커넥션만 있으면 됨. csp manager가 모든 걸 관리 ex)word, gmail, calendar

PaaS : 개발 환경 제공, 유저가 cloud app + data 작성해야함 ex) Google App Engine

• Faas : FaaS는 특정 작업이나 이벤트에 대해 코드를 실행할 때 효율적인 서버리스 모델인 반면, PaaS는 인프라에 대한 부담을 줄이면서도 전체 애플리케이션을 개발하고 관리하는 데 유리. AWS lambda(파이썬 코드 작성하는 거)

IaaS : 가상화 서버 자체를 빌려줌 원격 접속할 수 있게끔. 단일 서버를 많은 고객들이 공유. aws ec2

 

2) cloud deployment models

public cloud(누구나), community cloud(특정집단. 국가 기관들이 공유), private cloud(only for samsung 직원)

 

3) aws에 접근하기

- aws cli(command line interface)

- api가 아니라 sdk로 접근 (앱 만들어서 sdk로 aws에 접근)

 

EC2

정의

- IaaS

- hourly base

- virtual machine

• AMI(OS, default software, configuration, virtualization type)
• instance type(vCPU, memory, instance storage, network performance)

 

ec2 instance type = instance family -> 그냥 써가기

인스턴스를 launch한 후에 바꿀 수 있다. vertical scaling 가능!

 

 

4강

computing? cpu, ram, hd, network

network : bandwidth(양- 스트리밍 서비스 넷플릭스), latency(속도 - 빠른 서비스)

ram vs hard drive

• ram : main memory를 위한 기술. app이 실행 중에만 켜짐. temporary storage
• hard drive : boot files(부팅 로그), files(강의 pdf), Long-term storage

ec2 instance가 클라우드에서 이 computing resource임.

 

 

aws ec2

- full control over ec2

- any size(elastic computing), anywhere

- security group, elb를 통해 traffic을 제어할 수 있음

subnet,

 

ec2 instance purchasing options -> 각 type별 특징, 언제 쓰이는지 암기

1) on-demand instance 

- os 구분없이 초단위 pay

- no long-term commitments (오랜 시간 use 한다고 해서 discount 안됨)

- no upfront pay

- demands 에 따라 pay

- 가장 비쌈, 가격은 고정되어 있음

- short-term, spiky, unpredictable workloads / app 개발 및 테스트

 

2) reserved instance 미리 싸게 구매

- 가장 쌈. pay by year, no upfront / partial upfront / all upfront 

- predictable workload, flexibility가 요구되지 않는 compute power , 1년 이상, upfront 낼 수 있는 부자 유저~

 

3) saving plans instance 선택권이 많이 필요하거나 speficied하거나

• compute saving plans : 가장 선택권이 많아서 cost 줄일 수 있음, 자동으로 family, size, az, region, os, tenancy 설정
• ec2 instance saving plans : 특정 instance family, 특정 region 안, 가장 discount 많이!

- long time workloads / flexibility 요구하는 computing (지역, instance power) / RI를 coordinate할 필요 없음

 

4) spot instance 경매

- pay by min

- 일종의 경매형식 (가격이 시시각각 변함)

- supply가 demand보다 많으면 discount, 아니면 spot instance 꺼질 수 있음

- flexible start & end time, low compute price만 할 수 있는 app, 급하게 computing 해야하는 경우

 

EC2를 리조트라고 생각하면,

• On-Demand : Walk-In. 그냥 주말에 쉬려고 예약도 안하고 리조트에 가서 방을 잡는 것
• Reserved : 리조트 방 1개를 1년 ~ 3년 회원권을 구매
• Savings Plans : 월 300달러만큼만 리조트에서 지낼거야. 근데 나중에 바꿀수도 있다 (대신 1년 ~ 3년 약정)
• Spot Instance : 떨이. 예약 잘 안되는 방 (전망이 안좋다던가..)을 입찰받아서 싸게 내놓는다. But, 나보다 돈 더내겠다 는 사람이 나오면 나가야한다. batch Job, stateless, 안정성 낮음
• Dedicated Hosts : 만수르 옵션. 리조트 걍 통째로 빌린다 💰
• Capacity Reservations : 내가 리조트 갈지 안갈진 몰겠는데 일단 예약

 

Tenancy

1) share tenancy

2) dedicated instance : 전용 서버에서 instance 실행, instance 배치는 aws가 담당

3) dedicated host : 사용자가 전용 서버 직접 관리

 

 

5강

ec2 설정 시 해줘야 하는 것들

1) instance name and tags

- default tag - value가 생성됨 : name - {the name you give the instance}

- 최대 50개

- aws cost explorer에 연결해서 cost management / automatically scaling / iam로 관리(attribute-based control) 시

 

2) AMI

: 도커 이미지와 비슷. ami 고르기만 하면 특정 setup 그대로 ami 만들어 재현할 수 있음

- 인스턴스를 생성 후, snapshot을 찍어서 ami 생성

- template for root volume이고, os, app server, app을 포함

- 계정이 여러개이면 각 계정에게 ami 쓸 수 있게 할지 말지 결정 가능

- 같은 용도를 가진 Instance들끼리 ami template를 나눠서 쓸 수 있게 (너무 무거운 딥러닝 모델을 위한 여러개 인스턴스가 ami 나눠서)

- 인스턴스 생성 후 한번 만들면 바꿀 수 없음.

- 장점 : ami를 사서 sw를 ec2에서 동작하면 install 같은거 걱정 안해도 됨. (비행기 컨트롤 타워 boeing)

 

3) key pairs

ssh나 rdp에 접속할 때 사용할 수 있다. 인스턴스가 launch되고 나서는 add할 수 없다.

 

4) network settings

- public ip addr 쓸 건지 말건지 정한다.

region

: physical location of computing resources (ec2 instance가 succeed될)

 

vpc & subnets

default vpc, public subnet이 지역의 각 availability zone에 생긴다. 따라서 instance를 vpc 안에 생성할 수 있다.

1 region - 여러 vpc 생성 가능(~5개) - vpc 안에 여러 public subnet 생성 가능

 

public ip address

: internet에 접근할 수 있음. / private ip는 접근 불가

• public server : user server가 internet gateway를 거쳐서 ssh protocol로 접근 가능
• private subnet은 public ip addr을 거친 후 ssh로 접근 가능

public addr는 인스턴스 자동으로 부여되나? 놉!

default vpc - default subnet : public ip addr가 인스턴스 생성 시 자동으로 부여됨 (근데 자동 부여 안되게 설정도 가능)

default vpc - custom public subnet, custom vpc - custom subnet : public ip addr 자동 부여 안됨. (근데 되게 설정도 가능)

 

security group

- 어떤 ssh 접근을 allow할지 결정

- 언제든 바꿀 수 있음, 실시간으로 반영됨

- stateful : ex) inbound rule만 있으면 응답이 오고 받을 수 있긴 함. 근데 outbound call은 못함

- 인스턴스 레벨 O, subnet 레벨 X, 한 인스턴스가 여러 개 가질 수 있음 

- 트래픽이 통과하기 전에, security group들이 동시에 열리고 모든 security groupd이 한번에 evaluate됨

 

rule component

type(허용하려는 특정 서비스, 통신유형), protocol(그 서비스가 data를 전송하는 방식), port range, source

• inbound rules : default로 없음 / 일단 다 block하고 본다는 뜻
• outbound rules : 일단 다 allow하고 봄. allow rule을 제거해나가는 방식

 

6) configure storage

EBS, EFS, Instance storage 비교! 인스턴스 하나에만 붙는거 / 여러개 공유 / 임시로 특정 상황 fast 

EBS(Elastic block store)

- usb 같이 ec2에 붙임, 반도체 기반 기술, 빠르고, for any computing requirements / 대신 비싸고 용량 한계

- default는 자동으로 삭제 안됨. 직접 지워야 됨.

- 보안 : aws key management service(aws kms) 근데 너무 다 보안하면 시간이 오래 걸려서 성능 저하

 

volume type 4개

• ssd(자주 접근하는 data 저장용, 반도체 기반, fast, 비쌈) : general purpose, provisioned IOPS (general purpose보다 빠름)
• hdd (자주 안 접근, root volume 안됨, boot 할 수 없음 = os 쓸 수 없음) : throughput optimized(hdd중에서도 빠르고 자주 사용하는 데이터 넣을 때), cold(lowest cost, less frequently)

 

 

 

EBS 사이에 네트워크 만들어서 Mount EBS through NFS ... 귀찮음 근데 EFS로 해결가능!

AWS EFS(Elastic file system)

- 자동으로 크기 조절

- throughput and IOPS

- 여러개의 인스턴스를 붙였다 뗐다 할 수 있음. 이때 데이터는 loss 없음. 그들이 share하는 공간.

- root volume (x), block storage (x), work above block storage layer. ec2 instance가 자기만의 root volume(os) 갖고 그 위에 있는 거임

- aws cloud service and on-premise(도 가능!) rsrc 

- durability, availability

 

AWS EC2 Instance store (block storage)

- temporary block lv storage. 임시라서 버퍼, 캐시 같은 것에 적합.

- ec2 끄면 data 다 날라감

- host 컴퓨터에 물리적으로 있는 disk에 존재하는 storage

- root volume 될 수 있음

- 빠르지만, 임시라서 data loss 있을 수도, certain combination of ami & instance type,

  instance launch 이후에는 add volume할 수 없음(ebs는 launch 후에도 가능), detach volume 안됨, instance store volume not configurable

 

EBS와 비교

ec2 is(서버에 바로 붙어 있음) vs ebs는 network를 통해 붙어있음

EBS	EC2 IS
network를 통해 EC2에 붙어있음	EC2 서버에 바로 붙어 있음
instance launch 후 add,detach volume 가능	불가능

 

7) advanced details

IAM Role

인증 및 권한 관리 서비스 ; 어떤 유저가 어떤 aws resource에 어떤 환경에서 엑세스 할 수 있는지 설정

flexible하다 : add, remove, update 인스턴스 생성 후에도 가능

• Roles: 사용자, 서비스에 대한 액세스 권한 관리, Policy의 집합
• Policy: 사용자, 서비스에 대한 권한 부여
• Group: 여러 사람에게 동일한 액세스 권한 부여 및 관리
• User: AWS 계정 하나

 

User data

처음에 인스턴스를 run하면 스크립트도 run되고, 인스턴스가 시작될 때마다 스크립트도 실행되게 구성 가능

ami 설정 바꾸기, sw license key install, sw install

1) 인스턴스가 멈춰도, 다시 시작하면 스크립트도 다시 실행됨

2) auto scaling 명령 가능 : 자동으로 ec2 launch하고 싶을 때, web server 세팅하는 cmd를 스크립트로 설정 가능

 

 

spot instance

shut down behavior

termination protection(console,api,cli에서 함부로 종료 못하게)

 

---

헷갈릴 수 있는 부분! 적어가기