Colin Kang

미리 정해놓은 규칙에 따라 워크로드를 자동으로 확대 또는 축소할 수 있는 기술

autoscale group에 인스턴스를 추가하고 최소대수, 최대대수, 스케일링 정책 주면 확대 축소 됨

확대시에는, launch configuration에 서버 실행 환경 구성 ( 실행환경에 템플릿으로 AMI 상세정보, 인스턴스 타입, 키 페어, 시큐리티 그룹, IAM 인스턴스 프로파일, 유저 데이터, 부착 스토리지 등 ) 을 가지고 인스턴스 생성 후 ELB에 attach하여 서비스의 traffic을 load balacing하는 형태

EC2의 트래픽 허용 정책 적용

가상의 firewall 역할을 한다. 

특징 : 

기본은 모든 아웃바운드 트래픽 허용

허용만 정할 수 있음

인스턴스에서 요청에 대한 응답 트래픽은 인바운드 규칙과 상관없이 전달 허용 됨 (response이기 때문)

하나의 인스턴스에 복수개의 시큐리티 그룹을 연결가능하며, 규칙 세트를 통해 허용 여부 결정

규칙 :

프로토콜 : 6(TCP), 17 (UDP), 1 (ICMP)

포트범위 : TCP, UDP으 ㅣ허용범위

ICMP 타입과 코드

source / destination : inbound / outbound traffic

IPv4 : /32 prefix

IPv6 : /128 prefix

CIDR 블록

디자인 가이드 라인 : 

0.0.0.0/0 범위의 모든 포트를 여는 것 금지

EC2가 ELB에서 들어오는 트래픽 만 받아들이도록 허용, ELB에 security group 적용

사용하지 않는 security group 제거 : 동적이기 때문에 잘 못 assign되면 open되어버림, 참조를 찾기가 어려움

기본 EC2 OPEN 이 아닌 VPC 생성을 통한 EC2 보호, bastion host 통해서 접근

dzone.com/articles/5-best-practices-for-aws-security-groups

ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%EC%A0%9C%EC%96%B4_%EB%A9%94%EC%8B%9C%EC%A7%80_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

EC2는 VM에서 하나의 가상머신이다. VMware나 VirtualBox 등을 사용하여 본인의 PC에서 가상머신을 구동해 본 경우라면 이해가 쉬울 것이다. 

하나의 가상머신에는 PC혹은 서버와 마찬가지로, OS, CPU, MEM, DISK, Controller 및 NETWORK IF가 attach 된다. 물론 가상의 자원이지만 OS는 일반 자원으로 인식한다. 

그럼 그렇게 가상머신을 만들면 말 그래도 가상의 서버 혹은 PC가 하나 셋업이 된 것과 동일하다. 그리고 OS 이미지를 attach 한 다음에 설치하면 일반 서버에 OS 설치과정과 동일하다. 이렇게 OS 를 설치 완료하고 가상머신의 전원을 끄면 메모리까지 해제되는데, 이때 설치된 전체 OS 파일은 설치 이미지로 export가 가능하고 이후에도 이미지를 가지고 가상머신을 만들면 처음부터 설치할 필요없이 동일한 가상머신이 만들어진다. 

AWS에서는 이를 AMI (Amazon Machine Image) 라고 한다. AMI 즉 가상머신의 이미지는 OS 뿐만 아니라 환경실행정보 config, 부차적인 application, database 등 OS 설치 가능한 자원을 설치 후에 저장가능하다. 즉 사용자 정의 AMI가 생성가능하다는 의미이다. 

AMI 하나로 여러대의 가상머신을 띄울 수 있는데, 이때 IP자원과 여러가지 config 등이 외부 구성으로 가능해야하는데 AWS의 장점이 이런 config가 다 서비스로 되어 있는 점 (예를 들어 EIP 등) 이다.

즉 Amazon 내부에는 가상이미지를 관라하고 띄우는 가상머신 farm이자 Virtual Machine Server 가 구성되어 있고, 이러한 가상머신이 disk, network, cpu, memory 자원을 공유(혹은 독점)하는 형태로 운영될 것이라고 추측할 수 있다.

placement group에서 인스턴스를 launching 하면 단일 AZ 내에서 인스턴스를 논리적 그루핑하여 네트워크대역폭 더 많이 사용가능함.

초기에 AMI 이미지 자체는 S3에 저장되어 있으며 로딩시 인스턴스 스토에에 copy되어 로딩(instance store backed AMI)되면서 인스턴스의 블록 디바이스로 인식되고 마운팅 됨. 하지만 EBS를 제공하면서 이미지를 EBS 볼륨기반(EBS backed AMI)으로 운영함. 인스턴스 스토어 기반은 stop 이 지원되지 않음, EBS 기반은 스냅샷도 제공됨 (EBS는 해당 VMS에 붙어 있는 SAN 일 것으로 추측, EFS는 NAS 일 것이고), AMI는 리젼별 리소스임

EC2 생성 순서 :

en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud

openfoo.org/blog/amazon_ec2_underlying_architecture.html

Own AMI 이미지를 빌드하는 방법은 아래 참조

https://aws.amazon.com/image-builder/

EBS : Elastic Block Storage

EC2를 위한 블록 수준 영구 스토리지 볼륨

블록 : 균등한 사이즈 ( 블록사이즈) 로 정의된 저장 공간, 할당을 위해서 미리 영역을 나누어 놓고 처리하기 위한 단위

볼륨 : 하나의 파일시스템을 갖춘 하나의 접근 가능한 스토리지 영역

EBS는 인스턴스 수명에 영향을 받지 않고 존재

EBS는 형식이 지정되지 않은 블록 디바이스처럼 동작

EC2 인스턴스에 마운트 하여 사용

인스턴스에 연결된 EBS 볼륨은 스토리지 볼륨을 표시됨

EC2의 부프 파티션으로 사용되거나 표준 블록 디바이스로 사용

하나의 인스턴스에 EBS 볼륨을 여러개 부착 가능, 부트와 데이터 볼륨 나누는 방식

동일 AZ존에 속한 자원

볼륨 크기는 1G - 16T까지 가능

EBS 종류

인스턴스 스토어 instance store : instance의 로컬 스토리지 : 인스턴스를 위한 일시적인 스토리지

SSD

HDD 

docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volume-types.html

ko.wikipedia.org/wiki/%EB%B3%BC%EB%A5%A8_(%EC%BB%B4%ED%93%A8%ED%8C%85)

ARN : Amazon Resource Names

docs.aws.amazon.com/ko_kr/general/latest/gr/aws-arns-and-namespaces.html

ARN은 AWS 리소스 (혹은 자원)를 식별하기 위한 식별자이며, string과 : 구분자로 구분된 이름

AWS는 API나 SDK를 통하여 서비스를 이용가능하므로, 어떤 자원에 대한 명령을 수행하기 위해서는 ARN과 명령어 (api일 경우 api 주소) 가 필요하다.

ARN 형식은 다음과 같은 형식이다.
arn:partition:service:region:account-id:resource-id

arn:partition:service:region:account-id:resource-type/resource-id

arn:partition:service:region:account-id:resource-type:resource-id

S3에 대한 ARN 주소 형식 예제는 다음과 같다.

arn:aws:s3:::bucket_name/key_name

arn:aws:s3:::examplebucket/developers/design_info.doc

arn:aws:s3:::examplebucket/*

arn:aws:s3:::*

arn:aws:s3:::example?bucket/*

실제 S3 작업 요청 예제는 다음과 같다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::12345678901:user/Dave"
            },
            "Action": [
            "s3:PutObject",
            "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::awsexamplebucket1/*"
        }
    ]
}

docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/using-with-s3-actions.html

Simple Storage Service 이다.

1. region 서비스 이다.

2. 2006년 3월 4일 서비스 런칭

3. AWS의 최초 오픈 서비스이다.

4. Amazon에 상품 이미지가 많으니 이를 서비스 하기 위해서 만들어 졌다고 풍문으로 들었음

5. object의 metadata와 globally unique identifier ( access end point로 이해), block storage in multiple servers

6. 3개 ( 혹은 이상)의 redundancy data가 region간에 복제됨

7. 한개의 파일이 여러개의 block file로 분산 구성

8. 파일 수정은 실제 파일 수정이 아니라 metadata에서의 link 새로 연결

9. HDFS와 비교

10. block이 존재하는 서버의 분산 스토리지 및 네트워크 환경의 이점

11. CDN으로 바로 연계 cloud front와 연계됨

12. EMR에서 인식가능한 파일시스템

13. VPC로 제어하지 않는 서비스

14. redundancy replicated된 block이 fail이 되면 다른 곳에 복제를 함.

15. 동시에 3개의 다른 시설이 장애가 날 확률이 99.99999999 % ( eleven 9's durability)

16. 즉 신뢰성은 99.999999999 가용성은 99.99 (서비스 fail안날 확률)

17. 버킷은 폴더 개념인데 리전에서 유일한 이름으로 명명해야 한다.

18. 버킷의 역할, 네임스페이스 최상위, 비용 부담 계정 연결, 엑세스 컨트롤 수행, 사용량 보고

19. S3는 REST API로 접근가능, PATCH도 create에 대응됨

20. concurrency에 대한 lock mechanism은 없으며 last time stamp 요청을 따름

99.99 % 신뢰성은 다음의 다운타임을 허용한다.

일간 : 8.6 초,  주간 : 1분 0.5초, 월간 : 4분 23.0초, 연간 : 52분 35.7초

architecture

image reference : www.slideshare.net/AmazonWebServices/amazon-s3-masterclass-61085996

waspro.tistory.com/488

File : EFS : NFS Protocol 사용 : 리눅스 base : 공유 network storage

FSx : window version network storage

Block : EBS : EC2 부트 볼륨 및 데이터베이스 저장영역 : 동일한 하드웨어 장치의 하드웨어 storage 사용

Instance Storage : block 단위 storage : EC2와 연결함, 차이는 휘발성을 가진다.

Object : S3 : 객체 ( 일반 파일, 이미지, 비디오 ) 저장

Glacier : 

https://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-overview/storage-services.html

https://docs.aws.amazon.com/whitepapers/latest/aws-overview/storage-services.html

https://mitrai.com/tech-guides/eight-types-of-aws-storage-services-explained/