클라우드 5장

 

Computing / storage / database / network

가장 중요한 네가지 서비스

대부분 여기서 파생된거다

 

 

RSA keypairs : vm(linux)같은거 처음만들면 아이디 비번같은거 만들지? 그걸로 들어가서 여러가지 서버돌리거나 디비깔거나 하는데 이런 ssh방식으로는 보안 취약해서 RSA key를 준다. 이건 개인한테 주는거임 ㅇㅇ 알아서 보안 하라는뜻

Access key : 이거있으면 api 호출 가능

뒤에서 자세히 배움

 

EC2 대충 구조

 

 

 

region위에 AZ가 있고 그위에 instance가 동작

instance는 AMI를 통해 생성된다. AMI가 os 스냅샷떠서 그대로 띄울수있음 ㅇㅇ (ex aphace 깔아놓은상태로 AMI만들면 AMI로 생성한 instance에는 다 아파치 깔려있음)

VPC 네트워크 독립적으로 작동한다. (예: 각자 다른 IP대역대,방화벽 가질수 있음)

 

AMI 장점이 뭘까?

만약 이런 상태에서 트래픽이 커지면 가용성을 어떻게 확보할까?

AMI 평소에 잘 구워(?)놓고 트래픽커지면 똑같은 환경의 instance 개수를 늘려 가용성 확보 가능.

그럼 운영하다 보면 AMI 많아 질텐데 어따 보관할까?

바로 S3에 보관한다.

 

EBS란?

 

가상의 디스크, 여러개도 붙칠 수 있음. 이것도 컴퓨터랑 비슷하게 인스턴스의 os나 각종 환경들이 저장되는데 만약 이게 고장난다면 어떻게 될까? 보호하기위해 EBS snapshot을 떠서 s3에 저장한다.

 

 

EC2 개요

 

 

 만들면 local한테 RSA키 줌 알아서 관리해야됨 ㅇㅇ

 

EC2 life cycle

 ex) AMI 에 A -> B -> C깔고 terminated 했는데 AMI에 A밖에 저장안되있으면 BC는 복구안됨.

그때 stop하는거임 ㅇㅇ

stop할라면 root를 EBS로 해야됨/(근데 ebs별로안비싸서 거의 no charge )

그럼 root 를 ebs안해도 되는건데 

원래는 인스턴스 스토어에 저장함 ㅇㅇ 그래서 꺼지면 아예 리셋됨. 근데 EBS는 가상머신하고 독립적으로 상태를 유지함. 껏다  켜도 유지됨

 

 

 

 

 

4/29

 

meta data로 public key만든다

 

이런식으로 접속

 

AMI

s3에 저장 s3는 참 쓸데가 많구나~

 

AMI는 공유도 가능하다.

 

 AMI를 ec2로 만들기전에 metadata(각종 정보 ec2의 public key, 사용자 정보 등등)로 프로그램 까는 과정

 

 

암튼 instance활용한다는거임 ㅇㅇ

이렇게 설치 가능

meta data에서 instance id 뽑아 올 수 있다. 

host name id 등등 다있다. ㅇㅇ

meta data 장점: 자동화

인스턴스가 많아질때 하나하나 instance 아이디 넣어서 명령문 만들면 귀찮으니까 metadata에서 뽑아버리면 좋다.

 

 

AMI는 살짝 static한 느낌 boostrapping은 코드로 다이나믹하게 관리되는 느낌

뭔가느낌상 아예 구을거냐 아니면 코드로 넣어놀거냐 차이인듯 ㅇㅇ

 

 

아래와같은게 ec2에 필요하다고 할 때

 

AMI에 다 구워버리기(중간)

AMI최소 나머지는 스크립트(다이나믹 오른쪽)

동적으로할거냐 AMI구울거나 에서 sweet spot찾으면됨

sweet spot

 

자동화 장점