[ACC 스터디 3주차] - EC2 instance storage + ELB &ASG

EBS is a volume is a network drive you can attach to your instances while they can run

한번에 한 인스턴스에만 마운트 된다

종료되어도 데이터를 지속하게 함 

network usb stick 으로 비유함

 

EBS Volume - network drive 

snapshot을 통해 볼륨을 across함

 

the root ebs volume은 삭제 안됨

preserve root volume when instance is terminated

 

 

EBS Snapshot

backup of your ebs at a point in time

필수는 아님

copy snapshots across az or region

 

EBS Snapshot features

 

AMI overview

AMI  = amazon machine image

cutomizaion of an ec2 instance

소프트웨어 configuration os 를 추가할 수 있다

ami are built for a specific region 

you can lauch ec2 instace from 

public ami

your own ami

an aws marketplace ami 

 

AMI process 

start an ec2 instance and customize it

stop the instache

build an ami - ebs snap shot도 생성 

instacne form other ami 

 

EC instanch store 

ebs volume은 network drives with good but limited performance

if you need a high performance hardware disk use ec2 instance store하드웨어임

io 성능 향상을 위해

ec2 instance sotore lose their storage if stopeed

버퍼 캐시 임시 내용에 훌륭함

하드웨어가 실패하면 데이터 손실 위험이 발생

backup and replicaton이 필수

 

local ec2 instance store 

EBS volume types

6 types 

gp2 gp3

io1 io2 block express

st 1 HDD

sc 1 HDD

 

 

EBS Volume types use cases

general purpose ssd

- cost effective storage , low latency

- system boot volumes 

 

provisioned IOPS SSD

critical business applications with sustained iops performance

16000 iops 보다 더 필요한 앱 

 

 

EBS multi attach - io io2 family 

1개 ebs volume 을 multiple ec2 instances에 같은 az에서

각 인스턴스는 full read and write 권한 to high performance volume

use case 

higher application availability in clustered linux app

application must manage concurrent write operations

up to 16 ec2 instace at a time 

must use a file system thats cluster aware

 

암호화는 대기시간에 영향이 거의 없어서

leverages keys from kms

copying an unencrypted snapshot allows encryption

 

EFS - elastic file system

efs works with ec2 instances in multi az

highly available scalable expensive pay per use

content management web serving data sharing wordpress

user nfsv4.1 protocol 

uses security group to control access to EFS

compatible with linux based ami

encryption at rest using kms

posix file system that has a standard file api

file system scalses automatically pay per use no capacity planning

 

EBS : one instance , are locked at the az level , gp2 IO increases if the disk size increases , gp3 io 1 can increase io independently 

EFS : mouting 100 acorss az

efs share website files

only for linux instances

higher price point than ebs

can leverage efs-ia for cost savings 

 

 

 

 

High availability and scalability 

 

확장성 : 시스템이 더 큰 load를 handle하는 것

veritcal  : 크기를 증가 t2.micro - > t2.large non distributed system such as database

rds elastic cache are services that can scale verically

limit 이 있음

horizontal = elasticity :instance 숫자를 증가시키는 것 , horizontal scaling implies distributed systems

this is very common for web applicaton  -> High availability

 

High availability - run your app in at least 2 data centers

the goal of high availability is to survive  a data center loss 

passive 

acitve

 

vertical scaling : increase instance size

horizontal scaling : increase numbers of size

고가용성 sam app across multi az

 

 

load balancing : severs that forward traffic to multiple servers downstream

why use? spread load across multiple downstream instances

expose a single point of access to your app 

regular health checks to your instances

provide ssl termination of your webisites

enforce stickiness with cookies

public 이랑 private을 분리!

 

managed  load balancer 

upgrades maintenance high availability

a few configuration knobs

 

health checks 

elb -> ec2 instance

done on a port and a route 

the response is not 200 , unhealthy

 

4 managed load balancers

classic load balancer  

application load balancer 

network load balancer 

gateway load balancer 

 

internal or external elb

 

users - https http from anywhere -- load balancer -- http restricted to load balancer -- ec2

 

applicaton load balancer is 7계층

load balancing to multiple http applicatons across machines (target groups)

on the same machine (containers)

http/2 and web socket

redirects (http https)

 

 

nlb

forward tcp and udp traffic to your instances

less latency ~ 100 ms

 

one static ip per az assign elastic ip for whitelisting specific ip

 

network load balancer - target groups

ec2 instances ip 주소 - private ip

application load balancer 

tcp http https protocols

 

sticy sessions

it is possible to implement stickiness so that the same cient is always rediredcted to the same instance behind a load balancer

classic load balancer , application load balancer and network load balancer

application - based cookies 

custom cookie -generated by target, specified individually for each target group

dont use awsalb awsalbapp awsalbtg

 

application cookie - generated by the load balancer , cookie name is awsalbapp

 

 

cross zone load balancing 

with cross zone load balancing each load balancer instance distributes evenly across all registered instances in all a

applicaton load balancer - no charge for inter az data

 

network load balancer and gateway load balancer

 

 

ssl tls - basic

ssl : secure socket layer  certificate allows traffic btw your clients and your load balancer tobe encrypte in transit

tls : transprot layer security which is a newer version

 

ssl certificates 

users -- https 암호화 -- load balancer  ---http private vpc

 

ssl

snl solve the problem of loading multiple ssl certificates onto one web server 

note - works for alb and nlb , cloudfront

does not work for clb 

 

auto scaling group 

asg : scale out to match an increased load 

scale in to match a decreased load

ensure we have a minimum and maximum number of ec2 instances running 

asg are free 

launch template - launch configurations are deprecated

ami + instance type

ebs volumes 

ssh key pair