[62일 차] 21.10.21 : DevOps 3

AWS Lambda, AWS CloudWatch

---

1교시

 

 

Lambda는 FaaS 관련 서비스.

FaaS의 단점을 명심할 것 : Warm Start 상태만 되어도 반응이 빠르다

 Lambda 함수의 호출은 이벤트 소스/사전 정의된 일정/스케줄러/트리거를 통해 이벤트가 발생된다.

Lambda의 내부 정보

람다가 실행되면 아마존 리눅스 OS 기반의 마이크로 VM이 실행된다(Compute substrate).

환경 변수 등 실행환경(Execution Environment)을 맞추고, 지정한 언어별 런타임 환경을 준비한다(Language runtime).

그리고 마지막에 작성했던 함수를 실행한다(Function).

 

• Cold start/Warm start

람다가 실행되면 작성한 코드를 다운로드하고 실행 환경을 구성한다 : Full cold start

런타임을 준비하는 과정 : Partial cold start

마지막으로 함수가 실행될 때를 Warm start라고 한다.

함수가 실행될 때 순서가 정해져 있고 이에 따라 지연시간이 발생한다.

Micro VM이 올라갔다가 내려간 뒤 다시 실행하면 처음(Full cold start)부터 시작한다.

만약 마이크로 VM이 유지되는 시간 이전에 재요청하면 Partial cold start부터 진행되어 지연 시간을 줄일 수 있다.

 

 

• 어제 하다 만 실습 다시.

PIL 다운로드를 위해 인스턴스 하나 생성 > root 사용자로 전환 후 yum -y update

find /usr -name PIL을 실행해서 설치되어 있는지 확인 후 있다면 rm -rf로 삭제.

> ec2-user 홈 디렉터리로 이동

> yum install -y gcc bzip2-devel ncurses-devel gdbm-devel xz-devel sqlite-devel openssl-devel tk-devel uuid-devel readline-devel zlib-devel libffi-devel 실행

> 파이썬 3.7 수동으로 설치 : wget https://www.python.org/ftp/python/3.7.0/Python-3.7.0.tar.xz

> tar -xJf Python-3.7.0.tar.xz

> ec2-user 홈 디렉터리에 생성된 Python-3.7.0 디렉터리로 이동 > ./configure --enable-optimization > make altinstall

> 이렇게 직접 설치했으면 /usr/local/lib/python3.7/에 설치된다. 실행 환경변수를 선언하자.

> export PATH=$PATH:/usr/local/bin

> pip3.7 install --upgrade pip > pip3.7 install pillow

> /usr/local/lib/python3.7/site-packages/ 경로를 가보면 PIL 관련 라이브러리가 설치되어 있다.

> pip3.7 install boto3 실행하면 boto 라이브러리도 들어가 있다.

> mkdir -p ~ec2-user/lambda_layers/python/lib/python3.7/site-packages

> /usr/local/lib/python3.7 디렉터리로 이동 > cp -r site-packages/ ~ec2-user/lambda_layers/python/lib/python3.7/

> cd ~ec2-user/lambda_layers/ > zip -r lambda_layers.zip *

> aws configure로 사용자 인증

> aws s3 cp lambda_layers.zip s3://mybucket4613로 만들었던 버켓에 업로드, 파일의 객체 URL 복사

> 인스턴스는 이제 필요 없다. 삭제

> 람다 콘솔로 돌아가서, 좌측에 있는 계층 클릭 > 계층 생성 > 이름 작성, Amazon S3에서 업로드 체크(복사해둔 파일의 객체 URL 입력), 호환 런타임은 파이썬 3.7 > 생성

> 만들었던 람다 함수로 들어가서 Add a layer > 사용자 지정 계층, 아까 만든 계층 선택 > 추가

 

(여기서 놓쳤다)

 

---

2~3교시

 

 

어쨌든 다 완성하면 구조는

웹 -> API 게이트웨이(이벤트) -> 람다 -> 응답 -> API 게이트웨이 -> 웹

 

다 끝났으면 S3 버킷과 함수 삭제(계층은 별도로 삭제해야 한다)

 

 

이번엔 다른 실습 : 람다로 S3 버킷 리스트 확인하기

함수 생성. 이름 작성하고, 런타임은 파이썬 3.7

코드 소스에 아래 내용 작성(들여쓰기는 탭으로)

작성 후 Deploy(대충 저장하는 기능)

이제 트리거 추가 > API 게이트웨이 선택 > API 생성 선택, HTTP API 선택, 보안은 열기 > 추가

구성 탭 > 권한 > 실행 역할 클릭 > 정책 연결 > AmazonS3FullAccess 추가 후 정책 연결

돌아가서 API 게이트웨이 클릭해보면 엔드포인트 생성되어 있다. 클릭 > 버킷 목록이 출력된다.

버킷 하나를 추가해 보자. 대신 퍼블릭 액세스 차단 설정을 해제해야 한다. > 다시 가보면 추가되어 있다.

텍스트 파일 아무거나 업로드 > 코드 다시 작성

lambda 코드 부분에 작성

이제 아까처럼 구성 > 트리거 > 엔드포인트 링크로 들어가 보면 결과 확인 가능. test.txt 파일 내용이 보인다.

 

끝났으니 만들었던거 다 삭제

 

 

 

다른 실습.

함수 생성 > 런타임은 노드.js 14.x

코드 작성

서비스에서 API 게이트웨이 찾아서 들어가기 > REST API 구축 > 프로토콜은 REST, 새 API 생성 체크, 이름 작성 > API 생성

작업 > 메서드 생성 > 요청 메시지 GET 선택 > 람다 함수명만 작성하고 저장

메서드 응답 클릭 > 기존에 있는 200 항목 확장 > 헤더 추가 > Content-Type 입력 후 체크, 응답 본문은 지우기

통합 응답 클릭 > 기존 항목 확장 > 헤더 매핑 확장 > 아까 작성한 응답 헤더가 있다. 매핑 값을 'text/html'로 입력 > 매핑 템플릿 기존 항목 삭제 후 text/html 입력 > 우측 코드 작성란에 $input.path('$') 작성 후 저장

돌아와서 작업 > API 배포 > 이름 작성 후 새 스테이지 선택 후 생성 > URL로 들어가 보면 된다. 람다에서 작성한 코드가 출력된다.

 

이제 삭제

함수 삭제 - API 게이트웨이 삭제 - 역할 삭제(이건 필수 아님)

 

강사님의 교재 추천 : AWS Lambda 인 액션

제이펍/에이콘 출판사가 좋다(번역이 잘 되어 있음).

---

4교시

 

 

CI/CD

앱 개발에 필요한 여러 단계에 대한 자동화를 통해 앱을 보다 빠르고 짧은 주기로 고객에게 제공하는 방법

자주 나오는 용어니 알아둘 것.

 

• AWS CloudWatch

개발자/DevOps 엔지니어, IT 관리자가 사용할 수 있는 모니터링 서비스. 앱/시스템의 전반적인 성능을 모니터링하고, 상태 변화에 따라 서비스의 scale out/up, 서비스 재시작 등을 수행할 수 있는 CI/CD 구현에 필수적인 모니터링 도구.

-> 사전에 정의된 모니터링 지표에 대해 임계치를 미리 설정하고, 지표가 임계치를 넘어서게 되거나 지표 분석 결과에 따라 알림을 설정

 

• 동작 방식

기본적으로 리소스 및 사용자 커스텀 데이터의 저장소 역할. 저장된 데이터의 지표를 기반으로 통계를 작성하고, 이에 대한 검색을 수행한다. 또한 사용자 지정 커스텀 데이터에 대해서도 지표를 작성하면 검색을 수행할 수 있다.

특정 기준을 충족하는 경우 EC2 인스턴스를 중지/시작/종료하도록 경보 설정을 구성할 수 있다.

AWS EC2 Auto Scaling/SNS 작업을 수행하는 경보를 만들어 인프라 환경 변화에 따라 자동으로 대응할 수 있는 인프라 운영의 자동화를 구축할 수 있다.

---

5교시

 

 

클라우드워치는 네임스페이스 > 지표 > 자원의 구조로 구성된다.

네임스페이스

- 서로 다른 앱에 대한 지표 저장을 위한 컨테이너

- 각 앱의 측정 지표를 서로 격리

- 모든 AWS 서비스는 고유한 네임스페이스를 사용한다.

- 사용자 지정 지표 생성 시 고유 네임스페이스 생성이 필요하다.

지표

- 앱 또는 서비스에 의해 생성되는 데이터 요소의 세트

- 평가/측정/비교를 위한 특정 시간 간격의 데이터 집합

- 데이터 저장 간격의 기본값은 5분(유로 고급 옵션은 1분).

차원

- 지표를 고유하게 식별할 수 있게 하는 이름과 값으로 구분된 정보

- 지표 검색 시 필터링을 통해 원하는 데이터 검색 가능

 

---

6교시

 

 

취업 특강이 있었다.

실습 진행(14:10~14:20) 다시 듣기

---

7교시

 

 

Billing 관련 알람 설정

 

CloudWatch > 리전을 버지니아 북부로 변경 > 경보 > 경보 상태 > 경보 생성 > 지표 선택 > 결제 > 예상 요금 합계 > USD 체크 > 지표 선택 > 임계값 작성 후 생성 > 작업 구성은 그냥 넘기고, 다음 > 이름 작성 > 생성

 

 

IAM > 정책 생성 > 서비스 선택(CloudWatch Logs), 작업(PutLogEvents, CreateLogStream, CreateLogGroup, DescribeLogStreams), 리소스(모든 리소스) > 다음 > 다음 > 이름 작성 > 정책 생성

역할 만들기 > AWS 서비스 유형 개체, 일반 사용 사례 EC2 선택 > 아까 만든 정책 검색해서 체크 > 다음 > 역할 이름 작성 > 역할 만들기

사용자 추가 > 이름 작성, 액세스 유형은 액세스 키 방식 > 권한은 기존 정책 직접 연결, CloudWatchAdminAgentAdminPolicy 체크 > 다음 > 다음 > 사용자 만들기 > .csv 파일 받아놓기

 

인스턴스 하나 만들어서 접속(HTTP 열어놓기) : 위에서 만든 IAM 역할 부여

> httpd 설치 후 가동 > /var/log/httpd에 access_log와 error_log가 있다.

> awslogs 패키지 설치 > /etc/awslogs/awslogs.conf 파일 하단에

/etc/awslogs/awslogs.conf

이렇게 작성

/etc/awslogs/awscli.conf 파일에 있는 리전을 ap-northeast-2로 변경

aws configure로 아까 받은 .csv 파일의 정보를 입력해서 인증

 

awslogs.conf 파일을 참조해 awslogs 프로세스가 가동되면 정보들을 awscli로 넘긴다.

systemctl start awslogsd

 

CloudWatch > 로그 그룹 > access_log 파일과 error_log 파일이 들어와 있다.

---

8교시

 

 

CloudWatch 로그 그룹에 있는 파일, 경보, 규칙 삭제 > SNS에 만들었던 주제 삭제 > 설정된 구독 삭제 > 인스턴스 삭제

 

 

다음은 AWS Cloud9, 개발을 위한 Toolkit 등

11.09 AWS 공인 강사님 수업 전까지 AWS 코어 서비스 수업, 11.23에 끝나면 Terraform, Kubernetics, Docker 등 수업

 

팀 프로젝트를 위한 팀 구성은 12월 초에 진행. 팀 프로젝트 기간은 2~3주 정도 주어질 듯.

1.3이나 12.27~31 정도에 프로젝트 발표

---

1교시 실습은 따라갔는데, 실습 중간 설명만 다시 듣기(09:50~10:20)

5교시 CloudWatch 실습 다시 듣기(14:30~15:20)

6교시 실습 다시 듣기(14:10~14:20)

 

요즘 점심시간 이후에 졸다가 놓치는 경우가 좀 생긴다. 서서 듣던가 해야겠다.