업무에 바로쓰는 aws입문: 1. IAM, EC2, RDS, S3, CloudWatch, Lambda

1. Iam(Identity and Access Management)

IAM은 다른 기능과 달리 지역(AWS 리전)별로 적용되는 것이 아니라 유니버셜하다

 

사용자의 액세스 유형은 2개이다

• 프로그래밍 방식 액세스
• AWS management console access

 

사용자의 액세스, 비밀키 관리

각 사용자를 생성하면 제공되는 액세스키와 비밀키는 생성 시점에만 확인이 가능하다. 따라서 따로 보관하고 유출되지 않도록 관리해야한다.

루트 사용자에 대한 액세스키는 생성하지 않는 것을 권장한다. 그리고 보안 액세스 키를 잊어버린 경우, 삭제하고 다시 만들어야한다.

(https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_access-keys.html#securing_access-keys)

역할 및 정책추가

역할/신뢰할 수 있는 서비스/DynamoDB/Global tables를 선택하여 추가할 수 있다. DynamoDB는 AWS에서 제공하는 NoSQL DB이다.

 

 

 

2. EC2(Elastic Compute Cloud)

EC2는 클라우드 공간에 크기가 유연하게 변경되는 가상 서버 기능을 제공하는 서비스이다.

 

비용

EC2는 인스턴스가 실행되고 있을때만 돈을 지불한다. 지불하는 방법은 다음 3가지이다.

• 온디맨드: 시간당 정해진 금액 지불. EC2의 사용 중단 시점을 알 수 없을 때 사용한다. 비용은 세 가지 방식 중 가장 비싸다.
• 리저브드: EC2 인스턴스를 지정된 크기로, 선불로 대여한다. 온디맨드 대비 비용이 저렴하다.
• 스팟: 인스턴스 가격을 입찰하여 사용한다. 클라우드 시장 경제에 따라 최소, 최대 금액이 각각 5, 10달러라면 비용이 5~10달러 일때는 인스턴스가 유지되다가 10달러를 넘어서게되면 인스턴스가 자동으로 종료된다. 가격이 가장 저렴하기 때문에, 서비스의 시작/종료 시점에 구애받지 않을 때 사용하기 좋은 방식이다. *상한선과 하한선을 넘겼다고 무조건 종료되는 것은 아니다. AWS 입장에서는 휴게 중인 컴퓨팅 리소스가 있는 것보다는 대여하는게 이득이다.

 

EBS(Elastic Block Store)

EC2 인스턴스에 부착되어 사용되는 스토리지 볼륨이다. 마치 컴퓨터에 부착된 하드디스크와 같다. 운영체제 실행 시 필요한 파일을 하드디스크가 갖고 있는데, EBS도 EC2를 사용하는데 필요한 파일 및 오브젝트들을 보관하는 공간이다. EC2가 종료되어도 EBS안에 들어있는 데이터는 여전히 존재한다.

 

가용 영역(availability zone, AZ)

EBS는 사용 시 가용 영역을 지정해줘야한다. 가용 영역이란 하나의 리전에 백업을 위해 존재하는 여러 개의 영역을 의미한다. 예를 들어 서울, ap-northeast-2 리전의 1번 AZ에서 재해가 발생했을 경우, 나머지 AZ에서 백업본을 받아서 복구할 수 있도록 설계되어있다.

 

EBS 타입

- SSD 타입

빈번한 읽기/쓰기 및 입출력의 비중이 매우 클 때 사용한다. 속도가 중요하여 IOPS(Input/Output operations Per Second)로 성능을 측정하며 다음 타입이 있다.

General Purpose SSD(gp2), Provisioned IOPS SSD(io1)

 

- HDD 타입

처리량(throughput)을 기준으로 한다. Throughput Optimized HDD(st1), CDD HDD(sc1), Magnetic(Standard)가 있다.

 

ELB(Elastic Load Balancer)

ELB는 이름처럼 여러 EC2에 요청이 몰리는 것을 분배해주는 역할을 한다. 3가지 종류가 존재한다.

 

• 애플리케이션 로드 밸런서(Application Load Balancer, ALB): OSI 7 계층 중 가장 사용자에게 가까운 Application Layer에서 동작한다. 따라서 HTTP, HTTPS와 같은 네트워크 트래픽을 제어할 때 적합하다. ALB가 네트워크 요청을 받게되면 EC2에서 지정한 ALB의 역할에 근거해서 데이터의 흐름을 관리한다. ALB의 고급 설정을 통해 개발자가 직접 개입하여 서버 흐름을 설정할 수 있는 라우팅 커스터마이징 기능을 제공한다.
• 네트워크 로드 밸런서(Network Load Balancer, NLB): 4번째 계층인 Transport Layer에서 동작한다. Transport Layer에 포함된 TCP/IP의 트래픽을 관리하기 때문에 초당 수 백만개 혹은 그 이상의 요청이 들어올 수 있으며 이에 따라 극도의 퍼포먼스를 자랑한다. 프로덕션 환경에서 방대한 데이터를 처리할 때 사용한다.
• 클래식 로드 밸런서(Classic Load Balancer, CLB): 앞선 두 밸런서 대비 성능이 떨어지고 잘 사용되지 않는 레거시이다. 요청을 보낸 네트워크 호스트가 누군지 알 수 없다.

 

ELB와 504 Gateway Time-out

504 에러가 나는 경우 ELB에서 나는 경우가 많다. 이 504 에러는 서버/데이터베이스 레이어에서 발생하기 때문에 상대적으로 쉽게 해결할 수 있다. 이 문제는 보통 로드 밸런스의 최대 접속 시간 제한(idle time-out)의 기본 값이 60초라서 로드 밸런서가 60초 안에 아무런 응답을 받지 못할 경우 연결을 자동으로 종료하고 타임아웃 에러를 발생하기 때문에 발생한다. 실행 중인 애플리케이션의 규모가 커서 응답에 60초 이상이 걸리는 경우, 이 최대 접속 시간 제한을 늘려주어 해결할 수 있다.

 

X-Forwarded-For 헤더

152.12.3.225의 Public IP address -> DNS를 통해 ELB의 10.0.0.23 Private IP address -> EC2 10.0.0.23

위 경우처럼 요청이 전달되는 경우, EC2는 Private IP Address만 이해해서 요청 host가 누군지 알 수 없다. 이 때 ELB의 X-Forwarded-For 헤더에서 기존 Public IP Address의 주소를 알아낼 수 있다.

 

EC2 생성하기 실습

EC2는 디폴트로 VPC를 제공하며, VPC는 가상의 클라우드 공간을 의미한다. 하나의 VPC 안에서 인스턴스들은 공유되는 컴퓨팅 파워를 사용한다.

 

보안 설정 옵션 정보

보안 - 네트워크 설정에서 포트 80은 HTTP 프로토콜에서의 인터넷 응답을 위해 범용적으로 사용하는 포트이다. SSH 유형은 TCP 프로토콜을 사용해 포트 22를 열어준다는 뜻이다. '소스 유형 -> 위치 무관'은 어디서든 접근을 가능하게 해준다는 옵션으로 프로덕션에서는 절대 사용하면 안되는 옵션이다. '0.0.0.0/0'은 IPv4 주소로 어디든 연결 가능하게 해준다는 뜻이다. 기본값으로 설정하되, 포트 80만 열어주는 정도로 실습해보면 된다.

- 실습용 옵션 : HTTP 유형, TCP 프로토콜, Port 80, 소스유형 위치무관

 

인스턴스에 연결하기

Mac 기준으로 설명한다. 생성된 인스턴스의 id를 클릭하면 '인스턴스에 연결' 이라는 화면이 나오고, 여기에 제안되는 4가지 방법 중 하나를 선택하여 연결하면 된다. terminal에서 EC2를 생성할 때 만든 pem key(아래 사진에서는 cw-test.pem)가 있는 디렉토리에서 맨 아래 "예:" 부분의 코드를 복사하여 접속하면 된다. exit을 입력하여 빠져나올 수 있다.

 

책에서는 아파치 서버를 이용하여 간단한 웹페이지를 만들고 접속을 연습하는데, 스프링, 장고 등 사용하는 웹 프레임워크로 빌드한 파일을 EC2에 올리고 실행 시킨 뒤 외부에서 접속해보면 될 것 같다. 책의 후반부에서 다른 실습을 통해 아주 간단한 페이지를 만들고 EC2를 통해 접속하는 실습을 하기도 한다. 참고로 윈도우는 SSH 접속 프로그램인 PuTTY를 이용하여 SSH로 접속하는 방식으로 설명한다.

 

 

 

3. RDS

AWS에서 제공하는 데이터베이스는 Microsoft SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, Amazon Aurora 등이 있다. 이 중 Amazon Aurora는 AWS에서 직접 만들고 운영하는 고성능의 관계형 데이터베이스이다. 다른 가용 영역의 복제본을 활성화시켜 데이터의 접근성을 높이는 가용성, 키를 통해 데이터를 보호하는 안정성 등이 강조된 형태이다.

 

*OLTP, OLAP

데이터베이스를 관리하고 사용하는 방법론이다.

• OLTP(Online Transaction Processing): 데이터가 데이터에 삽입되자마자 바로 쿼리하여 사용될 때, 작은 규모의 데이터를 불러올 때 사용하는 시스템이다.
• OLAP(Online Analytical Processing): 큰 데이터를 한 번에 불러오고, 실시간이 아닌 이미 쌓인 데이터를 기반으로 분석을 위해 데이터를 불러올 때 사용하는 시스템이다.

 

백업

자동백업(AB, Automated Backup)

RDS에서 데이터베이스를 만들 때 자동으로 활성화된다. 1~35일의 retention period내에 특정 시각의 데이터베이스 상태로 복원할 수 있다. 백업을 하면 스냅샷과 트랜잭션 로그를 생성한다. 백업 정보를 S3 버킷에 저장하기 때문에, S3 용량에 따라 백업 한도가 결정된다. S3에 백업 데이터를 업로드하는 동안 DB의 입/출력 지연시간이 생기며, 원본 RDS 인스턴스 삭제 시 백업 정보가 모두 사라지므로 유의해야한다.

 

다중 가용 영역과 읽기 전용

다중 가용 영역

데이터베이스에 이벤트가 발생하여 업데이트가 일어났을 때, 원래 가용 영역에 문제가 생기면 다른 가용 영역에 복제본을 생성하는 것이다. 예를 들어 3개의 EC2 인스턴스가 'a-2A'라는 RDS를 업데이트하려고 하는 상황일 때, 만약 'a-2A'에 문제가 생기면 다른 가용 영역에 생성해둔 'a-2B'의 복제본으로 'a-2A'를 롤백하는 개념이다. RDS에 문제가 생긴 경우를 AWS에서는 재해라고 간주하며, 이런 기능을 재해 복구(disaster recovery)라고 한다.

 

읽기 전용

읽기 전용 복사본은 읽기만 가능한 데이터베이스 복제본이다. 만약 어떤 사고가 났을 때 그 사고 뉴스에 대해 많은 사용자들이 한꺼번에 접근하는 상황을 가정해보자. 이때 스케일링을 통해 빠르게 읽기전용 RDS 인스턴스를 늘리면 과부하를 막을 수 있다.

 

읽기 전용 복제본의 최대 가능 개수는 5개이며, 원본 인스턴스를 복제한 읽기 전용 인스턴스에서 또 다시 읽기 전용 인스턴스를 복제할 수 있다. 원본 대비 약간의 지연이 발생할 수는 있다.

 

캐시

AWS에서는 엘라스틱캐시(ElatiCache)라는 이름으로 캐시 서비스를 제공한다. 대표적인 캐시 서비스는 다음 2가지가 있다.

• 멤캐시드(Memcached): 오픈소스, 분산 메모리 캐싱 시스템이며 텍스트 기반 데이터를 다룰 때 사용하면 좋다. EC2의 오토스케일링처럼 데이터 처리량에 따라 캐시의 크기가 자동으로 조정된다. 단순하고 크기가 가변적인 캐시를 원하는 경우 사용한다.
• 레디스(Redis): 리스트, 해시테이블 등 문자열 대비 복잡한 데이터 타입을 저장할 수 있다. 정렬을 무조건 해야하거나 실시간으로 업데이트 해야하는 대시보드 등을 사용할 때 레디스가 좋은 선택지가 된다. 또한 다중 가용 영역 기능을 포함하고 있다.

 

RDS 생성 실습

DB 인스턴스 식별자: 인스턴스의 이름을 지정한다.

버스터블 클래스 옵션: 상황에 따라 CPU의 성능을 올린다. EC2는 고정된 CPU를 사용하는데 비해, RDS는 조정이 가능하다. 버스터블 인스턴스를 사용하면 컴퓨팅 비용이 절감될 수 있다.

스토리지 자동 조정 활성화: 스토리지 용량을 오토스케일링할 수 있다.

퍼블릭 액세스: 외부에서 RDS 인스턴스 접근 허용 가능 여부. 보안을 위해 아니오 선택

VPC 보안 그룹: 보안 그룹에 포함된 네트워크만 RDS에 접근하게 한다. 신규로 만들면 된다. RDS 외 따로 생성한 EC2와 연동하고 싶다면 EC2의 보안 그룹과 같은 보안 그룹을 가리키도록 하면 된다.

 

 

4. S3

s3의 크기는 가변적이기 때문에 용량에 상관없이 마음껏 사용할 수 있다.

 

버킷

버킷은 비유하자면 최상위 폴더라고 생각하면 되고, 이름을 부여할 수 있다. IAM처럼 글로벌하기 때문에 이름에 지역 정보 등을 넣는 것은 지양해야한다.

 

오브젝트

S3에 업로드하는 파일은 오브젝트로 키, 값으로 관리된다. 예를 들어 키는 file.txt, 값은 "AWS World"로 표현될 수 있다.

버전 아이디(version id)를 지정하여 같은 파일이더라도 다른 버전으로 업로드가 가능하다. 또한 버전을 참조하여 이전 오브젝트로 복원할 수도 있다.

교차 출처 리소스 공유(Cross Origin Resource Sharing, CORS): 다른 버킷에서의 오브젝트 접근 권한을 허용하는 것이다.

 

데이터 일관성 모델(data consistency model)

• 쓰기 일관성 후 읽기 모델(read after write consistency model): 오브젝트가 버킷에 업로드된 후 지연없이 바로 사용가능함을 의미한다. 강한 일관성 모델(string consistency model)이라고도 한다.
• 최종 일관성 모델(eventual consistency model): UPDATE, DELETE를 수행할 시 일어날 수 있다. 오브젝트가 여러 개의 노드에 연결된 채로 저장되어 있으므로 약간의 지연이 발생할 수 있다. 따라서 UPDATE 완료 후에도 UPDATE 전의 오브젝트를 얻을 수도 있다. 체감상 느껴지는 수준은 아니고, 원리가 이렇다는 것만 이해하면 된다.

 

버킷 유형(스토리지 클래스)

일반 S3 버킷, 드문 접근 버킷(infrequent access bucket, IA bucket), 단일 존 버킷, 글래시어 버킷, 지능적 티어링 버킷이 있다.

 

비용

- 오브젝트를 버킷에 업로드 시 GB당 비용을 지불한다. 오브젝트의 크기가 늘어날 경우 GB당 요금이 낮아진다. 또한 얼마나 PUT, COPY, GET 이벤트가 발생하느냐에 따라 비용이 달라진다. 

- 다른 AWS 서비스에 오브젝트를 전송할 때 비용을 지불한다.

- 메타데이터를 사용할 때 비용을 지불한다. 예를 들어 오브젝트가 언제 생성되었는지 등의 메타데이터 태그를 추가할 경우 비용이 발생한다.

 

버킷 접근 제어

CORS 설정

버킷은 글로벌로 되어있으나, 실제로는 지역이 존재하긴한다. 다른 지역에서 사용되는 버킷끼리 데이터를 주고 받아야한다면 CORS 정책을 설정하여 다른 지역 버킷의 접근을 허용해줘야한다.

 

정책(bucket policy), 접근 제어 리스트(access control list, ACL)

버킷을 생성하면 기본적으로 버킷의 생성자만 접근이 가능하며 다른 유저들은 접근 금지 에러가 발생한다. JSON 포맷으로 구성된 정책에 IAM에서 만든 사용자 정보들을 넣어주어 정책 수정을 해주어 다른 유저들의 접근을 허용할 수 있다.

정책은 버킷 전체에 적용되는 반면, 접근 제어 리스트를 통하면 버킷 내 디렉터리, 각 오브젝트별로 접근 권한 설정이 가능하다.

 

버킷 암호화

SSL과 TLS

버킷에서 파일을 다운로드하거나 업로드할때는 SSL, TLS 방식이 적용된다.

• SSL(Secure Socket Layer): 두 개의 시스템끼리 데이터를 교환할 때 중개자 역할을 하여 외부의 침입을 막아주는 프로토콜이다. 주로 HTTP/HTTPS 요청이 발생할 때 사용된다. HTTPS의 S가 SSL을 의미한다.
• TLS(Transport Layer Security): SSL에서 파생되었고 SSL 보다 보안이 뛰어난 프로토콜이다. AWS에서 API 사용 시 TLS에 의한 보안 장치가 활성화된다. S3 버킷에 업로드(PUT), 다운로드(GET)을 할 때도 TLS가 적용된다.

 

S3 암호화 장치

• SSE-S3(Server-side Encryption): 버킷에 저장된 각 오브젝트들의 모든 키를 한 번에 관장하는 마스터키 같은 개념이다. AWS에서 관리하며 AES-256(Advanced Encryption Standard), 256 비트 암호화 방식을 적용한다. 마스터키는 일정 시간마다 변경된다.
• SSE-KMS(SSE Key Management Service): KMS는 AWS에서 제공하는 서비스이다. SSE-S3와 다르게 누가, 언제, 어떻게 접근하였는지에 대한 상세한 정보를 제공한다. API 토큰 정보, 애플리케이션 암호 등 민감한 데이터를 위해 사용한다.
• SSE-C: 개발자가 직접 관리하여 생성한 암호를 사용할 수도 있는 방식. AES-256 포맷을 지원하며, 위 2가지와는 다르게 콘솔에서 암호화는 불가능하다. CLI, SDK, API 방식을 통해서만 가능하다.

이런 암호화는 예를 들어 사용자가 PUT 요청을 했을 때, API의 요청 헤더에 "x-amz-server-side-encrytpion: AES-256" 같은 방식으로 암호화를 요청하는 헤더값을 넣는 방식으로 진행된다.

 

 

S3 생성 실습

주요 옵션 등의 내용만 기록한다.

 

• 액세스 제어 목록(ACL): 기본 값은 비활성화이며, 이때 버킷을 생성한 사용자가 권한을 모두 관리한다.
• 퍼블릭 액세스 차단 설정: 외부로부터 액세스를 차단한다. 버킷 레벨이므로 ACL보다 광범위하게 설정된다. 설정되면 다른 사용자가 버킷에 있는 콘텐츠에 접근할 수 없고 업로드도 불가능하다.
• 버킷 버전 관리: 각 객체에 대한 버전을 부여하며 버전 부여 시, 객체의 이전 버전으로 롤백이 가능하다.
• 기본 암호화: 활성화 시 오브젝트를 업로드할 때 오브젝트에 암호가 생성된다.
• 고급설정 - 객체 잠금: 활성화 시 한 번 업로드된 오브젝트는 덮어쓰기나 삭제가 불가능하다.

-> 이미 관리되고 있는 S3의 설정 정보를 살펴보니, 퍼블릭 액세스는 허용하되, ACL은 아래처럼 설정되어 있다. 참고하면 좋을 것 같다.

 

버킷과 관련된 권한, ACL(객체들에 퍼블릭 사용자가 접근할 수 있는지 설정), CORS 설정 등은 해당 버킷의 최상위 경로에서 '권한' 탭에 접근하여 지정할 수 있다.

 

IAM 사용자 유형 또는 조건에 따라 객체에 접근할 수 있는 권한을 버킷 레벨에서 설정하고 싶다면 위 버킷의 최상위 경로에서의 '권한' 탭 - 버킷 정책 - 편집 - 정책 생성기 부분에서 정책을 생성할 수 있다.

Policy 타입은 S3 Bucket Policy로 하면 된다. Effect는 접근 허용을 위한 정책이라면 Allow를 선택해주면 된다.

Principal은 정책을 적용할 IAM 사용자 또는 그룹을 의미한다. IAM의 ARN 주소를 기입하면 되고, 이 주소는 IAM - 사용자 - 사용자 이름 - 사용자 ARN에서 확인할 수 있다.

 

Actions에는 많은 권한들이 있는데, GetBucketPolicy 등을 주면 된다. 마지막으로 Amazon Resource Name은 S3 자체에 대한 ARN을 묻는 것으로, S3의 최상위 위치의 '속성' 탭에서 확인할 수 있다. 그리고 Generate Policy를 클릭하여 생성된 JSON 문서를 복사한 후, 위에서 언급한 정책 - 편집 탭에서 복사한 정책 JSON 내용을 붙여넣으면 된다.

 

다만 이런 방식을 통해서 새로 만든 IAM 계정으로 테스트를 해볼려니, S3 Bucket 자체에 대한 접근이 어려워서 아래 사진처럼 s3:ListAllMyBuckets 권한이 없다고 떴다.

 

그래서 IAM - 사용자 - 사용자 이름에 들어가서 AmazonS3FullAccess 정책을 추가해주는 방식으로 실습을 해보았다. 향후 실제로 세세한 권한 조정이 필요하다면 각 정책의 이름과 그에 따른 기능에 대해서 자세히 파악 후 정책 테스트가 필요할 것 같다.

 

암호화실습

디폴트 값으로 서버측 암호화 설정은 SSE-S3로 설정하지만, AWS KMS 서비스를 이용하기 위해 SSE-KMS 옵션을 통해 설정할 수도 있다.

이럴 경우 업로드 객체에 들어가서 아래쪽으로 내려서 속성값을 살펴보면 kms용 ARN 고유 주소가 주어진다.

 

암호화가 적용된 버킷에서 아래처럼 업로드 정책을 추가하면 업로드를 제한할 수 있다. 아래 정책 구문은 총 2개의 'Statement'를 포함한다. AES256 암호화가 걸려있지 않거나, 올바르지 않은 암호화가 걸려있는 파일은 업로드가 거부되도록 하는 설정이다. 아래 구문에서 <버킷 이름> 이라고 적힌 두 부분만 버킷이름으로 수정하면 된다.

 

{
  "Id": "Policy1695644763928",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryptionHeader",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:s3:::<버킷 이름>/*",
      "Principal": "*",
      "Condition": {
          "StringNotEquals": {
              "s3:x-amz-server-side-encryption": "AES256"
          }
      }
    },
    {
        "Sid": "DenyUnencryptedObjectUploads",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::<버킷 이름>/*",
        "Condition": {
            "Null": {
                "s3:x-amz-server-side-encryption": "true"
            }
        }
    }
  ]
}

 

이제 파일 업로드를 하면서 속성 값에 있는 서버 측 암호화 부분에서 기본으로 지정된 '암호화 키를 저장하지 마십시오.' 부분에 체크 후 업로드를 하면 '액세스가 거부됨' 이라며 업로드가 실패한다. 파일 업로드 시 암호화 키를 지정하지 않아서 PUT 요청의 API 헤더에 'x-amz-server-side-encryption' 속성이 빠지게 되었기 때문이다.

 

 

5. CloudWatch

리소스의 사용 및 이벤트 등을 실시간으로 모니터링하는 서비스이다. 각종 이벤트에 대한 로그파일을 생성하여 실시간으로 어떤 일들이 일어났는지 파악할 수 있게 해주며, 그래프로 표시, 이벤트 감지 시 경보 전달 등의 기능을 제공한다.

 

모니터링의 종류

• 기본 모니터링(basic monitoring): 무료이며 5분 간격으로 최소한의 데이터만 수집한다. CPU 사용량, 디스크 사용량, 네트워크 I/O 처리량 관련 상황 등을 체크한다. ELB, RDS를 제외한 서비스는 모두 디폴트로 기본 모니터링이 제공된다.
• 상세 모니터링(detailed monitoring): 유료이며(시간당 약 0.015달러, 계속 변경됨) 1분 간격으로 상세한 데이터를 수집한다. ELB, RDS는 상세 모니터링이 디폴트이다.

 

경보의 세 가지 상태

• OK: 개발자가 지정해놓은 임계 범위에 값이 들어오는 경우이다.
• ALARM: 임계 범위를 벗어난 경우. 이 경우 자동으로 처리할 행동을 정의할 수 있다.
• INSUFFICIENT_DATA: OK | ALARM으로 구분 지을 수 있을만큼 충분한 데이터가 쌓이지 못한 경우 발생한다.

 

cloudwatch 실습

 

EC2 테스트

ec2를 생성한다.

다음 scp(secure copy protocol) 명령어를 입력하여 ec2에 파일을 전송한다.

scp -i <pem/ppk 파일명> <업로드할 파일명> ec2-user@<퍼블릭 IPv4 DNS이름>:<인스턴스에 업로드될 파일명>

참고로 업로드할 파일명에 띄어쓰기가 있으면 안된다.

 

여기서 ec2-user@<퍼블릭 IPv4 DNS 이름> 부분은 위 2장에서 배운 것처럼 EC2의 상세 페이지에서 '연결' 버튼을 누르면 바로 확인할 수 있다. 나의 경우 아래처럼 입력했다.

scp -i cw-test.pem test_image.png ec2-user@ec2-3-39-239-180.ap-northeast-2.compute.amazonaws.com:test.png

 

업로드된 파일은 EC2의 최상위 폴더에 업로드 된다.

이후 EC2에서 인스턴스 ID 를 클릭한 후 모니터링 탭에 들어가보면 기본적인 입/출력에 대한 모니터링 정보를 보여주는 것을 확인할 수 있다.

 

CloudWatch 확인, 경보 생성하기

CloudWatch 서비스에 들어가서 스크롤을 내려보면, EC2 및 EBS의 상태에 대한 모니터링 대시보드가 존재한다.

 

좌측 경보 - 경보 상태 탭에 들어가서 경보 생성 버튼을 눌러 경보를 생성할 수 있다. 지표 선택 - EBS - 볼륨별 지표에서 EC2에 해당하는 볼륨을 선택해준다. EC2의 스토리지 탭에서 확인할 수 있다.

VolumeWriteBytes 항목을 클릭하면 EBS 볼륨에 얼마나 많은 데이터가 사용됐는지 확인할 수 있다. 지표 선택을 클릭한 후, 정적, 보다 큼, ...보다는 100000(100KB)로 설정한다.

 

다음으로 경보 상태 - 새 주제 생성을 클릭하여 주제에 대한 이름, 이메일 엔드포인트를 입력한 후 주제 생성을 클릭한다. 

마지막으로 경보 이름을 입력한 뒤 생성을 누르면 정상적으로 생성된다.

그리고 등록한 이메일에 경보 생성에 대한 동의 메일이 온다. 참고로 나의 경우 스팸 메일함에 저장되어있었다. Confirm Subscription 버튼을 눌러서 경보 알림에 대해 동의한다.

 

그리고 좀 무거운 파일(나의 경우 Docker 설치 파일인 Docker.dmg, 500 MB 정도 되는 파일)을 업로드 하면 5분 평균 값이 100KB를 초과하면서 경보의 상태가 바뀌고 이메일이 오는 것을 확인할 수 있었다.

 

 

 

6. Lambda

Lambda는 AWS에서 제공하는 서버리스 서비스이다. 서버리스는 서버가 없다는 것이 아니라 개발자가 구현한 애플리케이션에 대한 리소스를 직접 관리할 필요없이 대부분 자동으로 관리한다는 뜻이다. 또한 이름에서 알 수 있듯이 함수라고도 불리는데, 이는 각종 AWS 리소스에서 이벤트가 발생했을 때 Lambda 함수가 호출되면서 원하는 로직을 실행시키거나 다른 AWS 리소스를 불러올 수 있게 된다.

 

서버리스 기능

• 오토스케일링: 네트워크 트래픽에 따라 리소스를 더 쓰거나 덜 쓰면서 비용을 관리해준다.
• 패칭(patching): 운영체제, RDS 등에 필요한 업데이트가 있다면 자동으로 업그레이드를 해주는 기능이다.
• 빠른 배포: 간접적인 장점으로, 개발자는 서버의 관리 및 유지보수에 신경쓸 필요가 없어서 배포가 빨라질 수 있다.

비용

생성, 배포 시에는 비용이 들지 않으며 이벤트 발생 후 Lambda 함수가 호출될 때만 비용이 발생한다. 매달 100만 번의 호출까지는 무료이며 이후 100만 번마다 약 0.2달러가 지불된다. 무료에 가까우나, 혹시 Lambda를 이용하여 Amazon SNS 메시지 전송 같은 유료 서비스를 이용한다면 비용이 발생할 수 있음을 유의해야한다.

 

특성

• 최대 300초(5분)의 런타임만을 허용한다. 람다를 사용하는데 타임아웃이 발생한다면 혹시 처리 시간이 5분이 넘지는 않았는지 체크해봐야한다.
• 512MB의 가상 디스크 공간을 제공한다. 이 공간은 기본적으로 /tmp/ 라는 이름의 경로에 저장되며 Lambda 함수 실행이 종료되면 모두 사라진다. 따라서 중간 과정에서 해당 임시 저장소에 보관된 파일을 다른 AWS 리소스에 옮겨야한다.
• 최대 50MB의 배포 패키지를 허용하며 이를 초과할 경우에는 S3 버킷에 업로드 후 AWS 콘솔에서 직접 지정해줘야한다.

사례

- 자동차 사고 데이터를 S3에 저장하면 PutObject 이벤트가 발생하면서 람다가 호출된다. 람다는 이 데이터가 정말 사고에 의한 데이터인지 확인 후, 형식에 맞게 처리하여 Amazon SNS로 메시지를 보낸다. 그리고 가공된 데이터를 다른 버킷에 저장한다.

 

 

실습

함수 생성 버튼으로 lambda를 생성할 수 있다. 새로작성 방식은 빈 내용으로 람다를 생성 후 사용자가 직접 편집하는 방식이다. 블루프린트 사용 방식은 자주 사용되는 기능을 기반으로 AWS에서 템플릿으로 제공하는 방식이다. Runtime 버전을 잘 확인해야한다. 컨테이너 이미지 방식은 ECR(Elastic Container Registry)에 저장된 컨테이너 이미지를 기반으로 람다를 생성하는 방식이다.

 

실습을 위해 블루프린트 방식의, Hello word function python 3.7을 선택한다. python으로 생성하는 경우 3.7 미만의 버전은 호환되지 않으므로 유의해야한다. 이름 및 정책을 정해주고 아래쪽 코드를 확인 후 생성 버튼을 누른다. 

 

코드 소스에서 Test를 누르면 처음 누르는 경우 테스트 이벤트를 구성하는 팝업창이 뜬다. 이름 및 값을 지정해주고 완료 후 다시 Test 버튼을 누르면 Lambda의 동작 테스트를 할 수 있다.

 

테스트 결과화면에서 결과값, 총 시간과 메모리가 얼마나 걸리는지도 표시해준다.

 

모니터링 - CloudWatch 에서 Logs 보기로 로그를 확인할 수도 있다.

 

실습2

교재에서 제공해주는 예제로 S3 - Lambda를 연계한 실습을 해본다. 새로작성 방식, Python 최신 버전으로 람다를 생성 후 아래 코드를 입력한다.

 

https://github.com/kimx3129/Simon_Data-Science/blob/master/AWSLearners/7%EC%9E%A5/lambda_trigger_source_code.py

 

import json
import boto3
from datetime import datetime
 
client = boto3.client('s3')
 
def lambda_handler(event, context):
    what_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    try:
        response = client.get_object(Bucket=bucket, Key=key)
        
        text = response['Body'].read().decode()
        data = json.loads(text)
        
        if data['temperature'] > 40:
            print(f"Temperature detected : {data['temperature']}C at {what_time}")
            print("Be careful! It's getting really hot!!")
        else:
            print("So far so good")
    except Exception as e:
        print(e)
        raise e

그리고 S3 버킷 오브젝트에 접근할 수 있도록 '구성/권한/실행 역할/편집'에 들어가서 [AWS 정책 템플릿에서 새 역할 생성]으로 Amazon S3 객체 읽기 전용 권한을 추가해준다. 만약 이렇게 S3에 대한 권한을 주지 않는다면 아래에서 살펴볼 lambda의 log에 Access Denied 에러가 발생하게 된다.

 

 

S3 버킷에서 boto3의 get_object 메서드를 이용하여 특정 파일을 불러오고, 파일의 'Body' 부분에서 data값을 읽어들여서 data 값에 따라 다르게 동작하게 만든다. 코드 작성 완료 후 Test 버튼 옆의 Deploy 버튼을 눌러서 배포한다.

 

서울리전으로 s3 버킷을 하나 만들고 '속성/이벤트 알림' 항목에서 [이벤트 알림 생성] 버튼을 누른다. 접두사 및 접미사는 버킷의 특정 파일이나 폴더에 대한 이벤트만 정의하고 싶을때 사용한다.

 

[이벤트 유형]에서 s3:OjbectCreate:Put인 전송을 체크하고 아래로 내려서 [대상]에서 Lambda 함수로 체크, Lambda 함수에서 지정을 눌러 위에서 생성한 람다 함수를 선택하여 '변경 사항 저장' 버튼을 누른다.

 

이후 람다로 돌아와서 개요를 확인해보면 S3가 추가된 것을 확인할 수 있다.

 

이제 S3 버킷에 JSON 파일을 업로드하여 람다를 테스트 해본다.

 

test1.json

{
	"temperature": 41
}

 

이후 '모니터링/로그/CloudWatch Logs 보기' 에서 로그를 확인해보면 아래처럼 람다에서 작성한 온도에 맞게 메시지가 출력되는 것을 확인할 수 있다.