#1-7 Auto Scaling 그룹 구성을 변경
#1-8 인스턴스 실행을 확인
#1-9 실행 중인 인스턴스에 SSH 접속
#1-10 stress 프로그램을 이용해서 CPU 사용량을 증가
[ec2-user@ip-172-31-18-209 ~]$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
[ec2-user@ip-172-31-18-209 ~]$ sudo yum install stress -y
[ec2-user@ip-172-31-18-209 ~]$ stress --cpu 1 --timeout 600
부하가 증가하면,
자동으로 인스턴스가 추가된 것을 확인
부하가 감소하면,
자동으로 인스턴스가 감소하는 것을 확인
AWS ELB(Elastic Load Balancing)을 이용한 서버 트래픽 분산 관리 (P62)
#1 로드 벨런스 생성
상태 검사 경로는 애플리케이션(app.js)에서 정의한 헬스체크 URL을 입력
|
app.get('/health', (req, res) => { ⇐ /health 로 GET 방식의 요청이 들어오면 res.status(200).send(); 응답 상태코드의 값을 200으로 설정해서 반환 }); |
주의: 로드 밸런서 대상 그룹에 Auto Scaling Group을 추가할 예정이므로, 인스턴스를 직접 추가하지 않는다.
#2 Auto Scaling 그룹을 로드 밸런서 대상 그룹에 추가
#3 헬스 체크 및 로드 밸런서를 통한 접속 확인
ASG(Auto Scaling Group)과 ELB(Elastic Load Balancer)를 이용한 장애 조치 (P73)
#1 대상 그룹의 헬스 체크 설정 변경
#2 ASG 용량을 변경
항상 인스턴스가 2개 실행되도록 설정을 변경
#3 각 인스턴스로 SSH 접속해서 헬스 체크 확인
/opt/nginx/logs/access.logs 파일을 통해 헬스 체크 요청이 5초 간격으로 발생하는 것을 확인
#4 인스턴스 중 하나의 nginx 서비스를 중지했을 때 로드밸러서 동작 확인
[ec2-user@ip-172-31-17-252 ~]$ sudo service nginx stop
Stopping nginx (via systemctl): [ OK ]
nginx 서비스 중지와 동시에 로드밸런서 퍼블릭 DNS 주소로 접속을 시도하면 502 Bad Gateway 오류가 발생 ⇒ 인스턴스의 상태가 업데이트 되기 전
시간이 지난 후에는 정상적으로 동작하는 것을 확인 ⇒ 정상적으로 동작(healthy)하는 인스턴스로만 요청을 전달
#5 모든 인스턴스를 종료 ⇒ ASG 설정을 통해
참고 ⇒ https://aws-builders-kr.workshop.aws/
블루/그린 배포 (P110)
#1 Auto Scaling 그룹을 생성 및 로드 밸런서 추가 - 이전 버전(Blue 버전) 서비스 환경
#1-1 Auto Scaling 그룹 생성
#1-2 로드 밸런서 대상 그룹에 Auto Scaling 그룹 추가
#2 로드 밸런서의 DNS 이름으로 접속을 확인
#3 새로운 버전의 코드를 적용
현재 서비스는 exercise-group-blue 인스턴스를 통해서 제공되고 있음
#3-1 새로운 버전의 코드를 반영하기 위해 exercise-instance 인스턴스를 실행
#3-2 exercise-instance 인스턴스에 SSH 접속
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/managing-users.html
|
각 Linux 인스턴스는 기본 Linux 시스템 사용자 계정으로 시작됩니다. 기본 사용자 이름은 인스턴스를 시작할 때 지정된 AMI에 의해 결정됩니다.
|
#3-3 새로운 버전의 코드로 업데이트
[ec2-user@ip-172-31-87-19 ~]$ cd /var/www/aws-exercise-a
[ec2-user@ip-172-31-87-19 aws-exercise-a]$ git pull
Already up to date.
[ec2-user@ip-172-31-87-19 aws-exercise-a]$ git checkout beta
M package-lock.json
Branch 'beta' set up to track remote branch 'beta' from 'origin'.
Switched to a new branch 'beta'
[ec2-user@ip-172-31-87-19 aws-exercise-a]$ cat app.js
const express = require('express');
const app = express();
app.get('/', (req, res) => {
res.send('AWS exercise의 A project beta 버전입니다.'); ⇐ 변경된 소스코드
});
app.listen(3000, () => {
console.log('Example app listening on port 3000!');
});
app.get('/health', (req, res) => {
res.status(200).send();
});
#4 새로운 버전의 코드가 반영된 인스턴스의 스냅샷 생성
#4-1 exercise-instance 인스턴스 중지
#4-2 이미지 생성
#5 새로운 버전의 AMI를 사용하는 시작 템플릿 생성
기존에 생성한 exercise-launch-template을 기반으로 새로운 시작 템플릿을 생성 → AMI를 제외한 나머지 설정은 유지
#6 Auto Scaling 그룹 생성
#7 exercise-group-green ASG을 로드 밸런서의 대상 그룹에 등록해서 블루/그린 배포를 진행
#7-1 EXERCISE-GROUP-BLUE에서 실행되고 있는 인스턴스로 접속
#7-2 EXERCISE-GROUP-GREEN에서 실행되고 있는 인스턴스로 접속
#7-3 로드 밸런서의 대상 그룹에 exercise-group-blue ASG은 포함되어 있음
#7-4 로드밸런서의 DNS 이름으로 접속하면 exercise-group-blue ASG에 포함된 인스턴스의 서비스 결과를 확인할 수 있음
#7-5 로드밸런서 대상 그룹에 exercise-group-green ASG을 추가
#7-6 두 개의 ASG이 로드 밸런서 대상 그룹에 추가된 것을 확인
#7-7 로드 밸런서 DNS 이름로 접속 ⇒ 두 가지 버전이 번갈아 가면서 요청을 처리하는 것을 확인 ⇒ 두 가지 버전이 일시적으로 공존
#8 이전 버전(exercise-group-blue)을 중지
#8-1 AutoScaling 그룹에서 용량을 조절 (원하는 용량, 최소 용량을 0으로 변경)
참고: 로드 밸런서 대상 그룹에서 이전 버전의 ASG를 삭제하는 방법도 있음
#8-2 exercise-group-blue ASG에 포함되어 있는 인스턴스가 모두 자동으로 종료되는 것을 확인
#8-3 로드 밸런서의 대상 그룹에 포함된 exercise-group-blue ASG이 healthy하지 않으므로 모든 요청이 exercise-group-green으로 라우팅되는 것을 확인 ⇒ 새로운 버전만 서비스되는 것을 확인
#9 리소스 정리
인스턴스가 모두 종료되었는지 확인
CodeDeploy로 현재 위치 배포 (P134)
#1 CodeDeploy를 위한 서비스 역할 생성
#2 EC2 인스턴스에 적용할 정책과 역할을 생성
#3 CodeDeploy로 배포 가능한 인스턴스를 생성 (P143)
#3-1 인스턴스 시작
#3-2 인스턴스의 퍼블릭 IP 주소로 SSH 접속
#3-3 CodeDeply 배포 디렉터리를 삭제 (이유 → P144)
[ec2-user@ip-172-31-87-19 ~]$ cd /var/www
[ec2-user@ip-172-31-87-19 www]$ ll
total 7032
drwxrwxr-x 4 ec2-user ec2-user 130 Mar 9 04:40 aws-exercise-a
drwxrwxr-x 5 ec2-user ec2-user 129 Mar 8 07:49 aws-exercise-b
-rw-rw-r-- 1 ec2-user ec2-user 7198910 Nov 5 2018 passenger-5.3.6.tar.gz
[ec2-user@ip-172-31-87-19 www]$ rm -rf aws-exercise-*
[ec2-user@ip-172-31-87-19 www]$ ll
total 7032
-rw-rw-r-- 1 ec2-user ec2-user 7198910 Nov 5 2018 passenger-5.3.6.tar.gz
#3-4 CodeDeploy Agent 설치
|
CodeDeploy Agent를 가져올 주소를 생성(확인)하는 방법 wget https://bucket-name.s3.region-identifier.amazonaws.com/latest/install ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ | | | +--- 리전 식별자 | ⇒ 버지니아 북부의 경우 → us-east-1 +--- 지역별 리소스 키트 버킷 이름 ⇒ 버지니아 북부의 경우 → aws-codedeploy-us-east-1 버지니아 북부의 경우 wget https://aws-codedeploy-us-east-1.s3.us-east-1.amazonaws.com/latest/install |
[ec2-user@ip-172-31-87-19 www]$ wget https://aws-codedeploy-us-east-1.s3.us-east-1.amazonaws.com/latest/install
[ec2-user@ip-172-31-87-19 www]$ chmod +x ./install
[ec2-user@ip-172-31-87-19 www]$ sudo ./install auto
[ec2-user@ip-172-31-87-19 www]$ sudo service codedeploy-agent status
The AWS CodeDeploy agent is running as PID 3671
#3-5 CodeDeploy Agent를 설치한 인스턴스의 스냅샷을 생성
#3-6 시작 템플릿 생성
기존 시작 템플릿(exercise-launch-template)의 설정에서 AMI만 변경하고 나머지는 그대로 유지
#3-7 EXERCISE-GROUP ASG의 시작 템플릿을 변경
'CLOUD > AWS' 카테고리의 다른 글
| 3/11 - AWS 10차시 (0) | 2021.03.11 |
|---|---|
| 3/10 - AWS 9차시 (0) | 2021.03.10 |
| 3/8 - AWS 7차시 (0) | 2021.03.08 |
| 3/5 - A Cloud Guru를 이용한 AWS 6차시 (0) | 2021.03.05 |
| 3/4 - A Cloud Guru를 이용한 AWS 5차시 (0) | 2021.03.04 |