스스로 구축하는 AWS 클라우드 인프라 - 기본편

August 7, 2022

다루는 내용

서버리스 정적 웹사이트 호스팅 및 성능 가속화
LAMP 웹 서버 및 Application Load Balancer 구성
관계형 데이터베이스 서비스 구성
Auto Scaling을 통한 확장성 및 탄력성 구성

섹션 0. 오리엔테이션 EC2 Instance 접속을 위한 PuTTY 사용 방법

PUTTY : EC2 instance와 ssh 통신
PUTTYGEN : key pair 생성

EC2 인스턴스 생성

Launch Instances
Amazon Machine Image 선택
Instance Type 선택
Instance Detail 설정
storage 추가
tag 추가
security group 설정
keypair 설정

PUTTY 연결

PUTTYGEN을 실행해서 다운받은 key(.pem)을 로드하고 Save Private key .ppk 파일이 생성됨
PUTTY를 실행해서 EC2 instance의 public IP address를 넣음
SSH 메뉴의 Auth에서 private key 넣음
나오는 프롬프트 창에 이름 설정하면 들어가짐

섹션 1. 서버리스 정적 웹사이트 호스팅 및 성능 가속화

웹페이지 로딩 속도의 향상을 실험하기 위해 North Virginia region 사용
S3 버킷의 컨텐츠를 로드하는 것으로도 웹페이지의 역할 수행 가능
- 컨텐츠가 크거나 사용자가 멀리 떨어진 곳에 있을 경우 느려짐
- 이때 사용할 수 있는게 컨텐츠 전송 서비스인 CloudFront임
- S3의 컨텐츠들이 cloudfront에 캐싱됨
  - 사용자와 가까운 캐싱 서버에서 부터 컨텐츠가 전송됨

1. S3 Bucket 생성 및 정적 웹사이트 호스팅

S3 Bucket 생성
- bucket 이름은 중복될 수 없음
Object(File) 업로드
정적 웹사이트 호스팅 기능 활성화
- Properties - Static website hosting에서 설정 가능
- 액세스 정책을 설정하지 않았기 때문에 hosting만 됨
- 다시 들어가서 bucket website endpoint를 들어가면 접속하려하면 403 Forbidden이 뜸

Bucket과 Object에 대한 액세스 정책 설정

Permissions - Block public access에서 액세스 설정 가능, 해제하기

Permissions - Bucket policy에서 정책 수정 가능

Policy generator 들어가서
1. Type of Policy : S3 Bucket Policy
2. Actions : GetObject
3. Amazon Resource Name(ARN) : [S3 bucket의 ARN]/* 넣기 S3 bucket의 ARN은 bucket policy 페이지에서 확인 가능

Bucket policy에 직접 붙여넣어도 됨(ARN은 수정해야 함)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "S3 Bucket의 ARN/*"
            ]
        }
    ]
}

웹 브라우저에서 작동 확인

2. CloudFront를 통한 웹사이트 성능 가속화

CloudFront Distribution 생성
- Origin
  1. Origin domain : 생성했던 S3 bucket의 웹페이지 주소
  2. Origin path : 특정 디렉토리에서 컨텐츠를 요청하는 경우, 해당하는 세부 경로를 넣어줌
OAI(Origin Access Identity) : Origin에 대한 access를 제어할 것인지 설정 사용자가 cloudfront의 origin에 접근하는 것을 차단하는 기능
- Default cache behavior
  1. Compress objects automatically : 전송의 효율성을 위해 object를 자동으로 압축할 것인지 설정
  2. Cache key and origin requests : Cache policy and origin request policy
    - cache key : caching된 객체가 가지는 key 값
    - cache hit : 사용자의 요청에 의한 cache key와 이전 요청에서 생성되었던 cache key가 동일한 경우 cache hit가 발생할 때 해당 객체가 cloudfront edge에서 사용자에게 전달됨
    - 객체가 요청되었을 때 cloudfront가 origin에 요청을 보내서 객체를 검색
- Settings
  - Price class : 어느 location에서 cloudfront edge location을 사용할 것인지 설정
  - AWS WAS web ACL : cloudfront distribution에 대한 방화벽이나 access control list 설정
  - Custom SSL certificate : HTTP만 사용할 경우 설정하지 않아도 됨
  - Default root object : request가 root를 요청할 때 반환한 객체를 설정 정적 웹사이트 호스팅에서 사용한 페이지로 설정하면 됨
  - Standard logging : request log를 S3 bucket에 저장할 것인지 설정
- 적용될 때까지 약 5분 정도 소요됨
웹 브라우저에서 CloudFront Distribution 작동 확인
- distribution의 status가 enabled인지 확인
- distribution 페이지의 distribution domain name에 접속해서 설정했던 페이지가 로드되는지 확인
  - 네트워크 활동 기록 설정하고 새로고침해서 x-cache: Hit from cloudfront가 나오면 cloudfront를 사용한 환경이 제대로 동작하는 것임
웹사이트 성능 테스트
- S3 정적 웹사이트 호스팅을 통한 컨텐츠 로드 속도
  - 위에서 개발자도구를 사용한 과정을 동일하게 적용해서 S3 website endpoint, CloudFront의 distribution domain name 로드
- CloudFront를 통한 컨텐츠 로드 속도

섹션 2. LAMP 웹 서버 및 Application Load Balancer 구성

LAMP(Linux, Apache, MySQL, PHP application), Application Load Balancer로 이중화된 네트워크 구성
Amazon VPC : VPC, Subnet, Internet Gateway, Route Table, NAT Gateway 사용
Amazon EC2 : LAMP 서버 구축
Amazon EBS : Block storage service
Amazon EFS : File storage service
Elastic Load Balancer : Application Load Balancer 사용

Untitled

VPC 안에 2 Availability zone이 존재하고, 각각 3개의 subnet으로 구성
- public subnet : 외부와 통신 가능
  - EC2 instance : Internet Gateway를 통하여 외부와 통신
    - LAMP stack을 설치하면 웹 서버로 활용 가능
- private subnet : 외부와 통신 불가
EFS(Elastic File System) 또한 VPC 내부에 위치하는데, mount target을 설정해서 EC2 인스턴스와 연결됨 → 파일 저장, 공유 가능
웹 서버가 public subnet에 위치하면 보안 이슈 발생 가능
- private subnet에 위치시켜서 해결 가능
  - 외부와 연결이 제한되기 때문에 업데이트 등이 제한됨
    - public subnet에 위치한 instance를 통해서 중개 가능 → 이러한 중개 서버를 bastion 호스트라고 부름
  - 웹서버의 기능을 하기 위해 외부와의 연결이 필요한데, 이는 public subnet에 위치한 NAT Gateway를 통해서 외부 인터넷과 통신함
트래픽, 장애 등에 대비해서 private subnet에 여러 서버를 구성, 서버들을 Load Balancer 중 Application Load Balancer에 연결함

Note

VPN, VPS, VPC

VPN : 같은 이더넷 내에 있는 것처럼 만듦

VPS : 하나의 자원을 파티션을 분할해서 독립적으로 사용

VPC : VPS와 비슷하게 분할하는데, 각각의 클라우드들이 탄력적으로 조절됨

Availability zone : 네트워크를 사용할 수 있는 영역

네트워크 속도, 안정성을 위해서 IDC들끼리 백업해가면서 클라우드 서비스를 유지하는데, 이런 IDC를 통해서 네트워크를 사용가능한 곳

1. 기본 네트워크 환경 구성 (VPC/Subnet/Internet Gateway/Route Table)

VPC 생성
- AWS에서는 사용자별로 사용하는 네트워크가 모두 VPC가 됨
VPC - Your VPCs - Create VPC 클릭
- Name tag : VPC 이름
- IPv4 CIDR block : VPC가 사용할 IP 대역, 10.1.0.0/16으로 설정
  - CIDR : classless Inter-Domain Routing : IP 주소를 할당하는 방법 중 하나
  - 사용할 IP 범위 설정
- Tenancy : 이 VPC에서 EC2 instance를 생성할 때 전용 하드웨어를 사용할지 설정
Your VPCs에서 생성된 VPC 체크, 우클릭해서 Edit DNS hostnames 클릭 Enable로 설정
- VPC에서 생성되는 리소스(EC2 instance 등)들이 DNS hostname을 생성, 사용할지 설정
Subnet 생성 VPC - Subnets - Create subnet 클릭
- VPC ID : 생성한 VPC 선택
- subnet의 CIDR block은 VPC의 CIDR block보다 작아야 함
- Availability Zone 설정
- IPv4 CIDR block : VPC의 CIDR block에 포함되도록 subnet마다 중복되지 않게 설정
  e.g. 10.1.1.0/24 - Internet Gateway, Route table을 설정해서 리소스들이나 외부 인터넷 간의 경로 설정
Internet Gateway 생성 VPC - Internet Gateways - Create internet gateway 클릭
- 이름 설정 후 생성
- Attach to a VPC에서 연결할 VPC 설정 (또는 Internet Gateways에서 체크, 우클릭하면 설정 가능)
Route Table 생성 및 Route 설정 VPC - Route Tables - Create route table
- 이름 설정 후 생성
- 생성된 route table 페이지 - Subnet associations - Edit subnet associations 클릭
  - associate할 subnet 선택
- route table 페이지 - Routes - Edit routes 클릭
  - Destination : 0.0.0.0/0 Target : Internget Gateway 이름
    - 외부로 향하는 트래픽은 Internet Gateway를 통해 이동
  - Destination : 10.1.0.0/16 Target : local
    - Destination이 VPC의 CIDR 블럭이고, Target이 local인 것은 VPC 내의 CIDR 블럭 내에서는 트래픽 이동이 가능한 것을 뜻함
    - association에 있는 것들 내에서 이동이 가능함 각각의 subnet에 대해 모두 위 과정처럼 route table을 설정해줘야 함

2. Public EC2 인스턴스 생성 및 LAMP 웹서버 구성

EC2 생성 EC2 - Instances - Launch instances 클릭

Name : public-ec2-a1
AMI : Amazon Linux 2 AMI
Key pair : ec2-public

Network settings

Network, Subnet : 어느 네트워크에 만들 것인지 설정 (lab-vpc, public-subnet-a1로 설정)
Auto-assign Public IP : Disable, Instance가 만들어질 때 자동으로 public IP를 할당할 것인지 설정
- Elastic IP로 public IP 할당하면 instance reboot할 때도 IP가 고정적으로 유지됨
Firewall(security groups) : Instance level에서 traffic을 제어하는 네트워크 요소
- Security group name : public-ec2-sg
- Description : security group for public ec2 instance
- Inbound security groups rules
  - Type : SSH
  - Port Range : 22
- 웹사이트일 경우
  - Type : HTTP(HTTPS)
  - Port Range : 80(443)
  - Source : 0.0.0.0/0
- MySQL일 경우
  - Type : MYSQL/Auror
  - Port : 3306
- Network interface는 랜카드와 비슷한 개념, instance마다 설정 가능한 interface 수가 다름
Configure storage
- Volume type : gp2(기본값) 사용
- File systems : EFS(파일 시스템)을 적용시킬 것인지

Advanced details

Domain join directory : active directory를 사용할 수 있게 해줌
Hostname type : Use subnet setting
Shutdown behavior : Stop
Stop - Hibernate behavior : Disable, 절전모드 지원 설정
Termination protection : Disable
enable일 경우 이 기능을 끌 때까지 instance를 종료할 수 없음
Detailed CloudWatch monitoring : 기본적인 모니터링은 무료지만, cloudwatch를 활용한 모니터링은 유료임
Elastic Inference : HW 가속화 설정(딥러닝 할 때 필요)
Credit specification : Standard
- unlimited일 경우 burstable performance instance에서 credit이 다떨어져도 후불로 청구함
Placement group name : instance를 만들 때 어디에 배치할 것인지 설정
- 인스턴스는 보통 데이터센터에 분산됨
Capacity reservation : open, 인스턴스의 용량, 수량을 미리 확보해놓는 것
- Auto-scaling을 위해서는 인스턴스를 미리 확보해놓는 것이 좋음
- Open이면 따로 사용하지 않는 것
Tenancy : Shared
- dedicated는 다른 인스턴스들과 물리적으로 떨어진 환경
Metadata accesible : Enabled, 인스턴스 메타데이터에 접근할 수 있는지 설정
Metadata version : V1, V2 모두 사용
Metadata token response hop limit : 1, Metadata V2를 사용할 때 토큰 응답 설정
Allow tags in metadata : Disabled - User data : 인스턴스가 실행되는 과정에서 root 권한으로 실행되는 script

#!/bin/bash
yum update -y
amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
yum install -y httpd mariadb-server
systemctl start httpd
systemctl enable httpd
usermod -a -G apache ec2-user
chown -R ec2-user:apache /var/www
chmod 2775 /var/www
find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 0664 {} \;

Amazon Linux 2 AMI를 기준으로 작성됨
-y 옵션이 있어야 멈추지 않고 실행됨

Elastic IP 설정 Network & Security - Elastic IPs - Allocate Elastic IP address 클릭 - Name : eip-public-ec2-a1 만들어진 eip 클릭 후 Actions - Associate Elastic IP address 클릭

- 만든 ec2와 associate
- ec2 들어가서 public IPv4 address 설정되어 있는 것 확인

PUTTY로 instance 접속
- 개인키 생성
  - PUTTYgen으로 pem 로드
  - save private key로 개인키 생성
- PUTTY 실행
  - Host Name : ec2의 public IP
  - Connection - SSH - Auth에서 browse, 개인키 넣은 후 open
- login as : ec2-user
- ec2의 private IPv4 address와 로그인된 IP가 동일한지 확인

Index.php 파일 생성

sudo su
cd /var/www/html
vi index.php

제공받은 index.php 붙여넣기

웹 브라우저에서 LAMP 웹서버 작동 테스트
- ec2 public ip로 들어가서 동작 확인
- Session에 PUTTY 설정 저장해놓으면 편리함
  - Host Name : ec2-user@[publicIP]
  - Auth : ppk 파일 로드
  - Session 들어가서 public-ec2-a1치고 Save 클릭

3. Custom AMI를 통한 Public EC2 인스턴스 생성

Custom AMI 생성

instance 선택하고 우클릭 - Image and templates - Create image 클릭
- No reboot : Enable, 이미지가 생성되는 과정에서 instance가 reboot되지 않게 할 것인지
- Key, Value : (Name, ami-public-ec2)
Custom AMI를 통해 EC2 추가 생성
- AMI : 생성한 이미지 사용
- Security group : 기존에 생성한 것 사용
- Name : public-ec2-c1
- EIP도 이전과 같이 생성하고 public-ec2-c1에 associate 해줌
웹 브라우저에서 LAMP 웹서버 작동 테스트
- public IP로 접속해서 작동하는지 확인
  - index.php까지 잘 들어가짐
- 이미지로 만든 instance의 EFS에 있는 내용도 snapshot 형태로 AMI에 저장됨
  - AMIs - ami-public-ec2의 Storage에서 snapshot ID 확인 가능
  - Instances - public-ec2-c1의 Storage - Volume ID 클릭 Detail - Snapshot의 snapshot ID가 위의 snapshot ID와 동일한지 확인

4. EFS를 통한 네트워크 파일 시스템 구성

EFS용 Security group 생성 VPC - Security - Security groups - Create security group 클릭
- Name : lab-vpc-efs-sg
- VPC : X 누르고 lab-vpc 선택
- Inbound rules
  - Type : NFS
  - Source : public-ec2-sg
    - EFS와 연결하고자 하는 instance에 적용되어 있는 security group을 선택
- Tags : (Name, lab-vpc-efs-sg)
EFS 생성 EFS - Create file system 클릭 - Customize 클릭
- File system settings
  - Name : lab-vpc-efs
  - Storage class : Standard
    - Standard : EFS를 여러 AZ에 저장
    - One Zone : EFS를 하나의 AZ에만 저장
  - Automatic backups : Disable
  - Lifecycle management : 접속이 없을 때 Infrequent Access storage로의 전환 관리
    - Transition into IA : 언제 IA로 전환할 것인지
    - Transition out of IA : 언제 다시 Standard storage로 전환할 것인지
  - Performance mode : General Purpose
    - Max I/O : 높은 처리량이 필요할 때 선택, 파일 메타데이터에 대한 작업이 지연될 수 있음
  - Throughput mode : Bursting, EFS의 파일 처리량 설정
    - Bursting : 파일 시스템에 저장된 데이터 양을 기반으로 처리량을 결정함
    - Provisioned : 데이터 양 상관없이 고정된 높은 처리량 유지(추가 요금)
  - Encryption : Enable
  - Tag : (Name, lab-vpc-efs)
- Network access
  - VPC : lab-vpc
  - Mount targets : EFS가 mount될 수 있도록 endpoint의 IP주소 제공해야 함
    - 하나의 AZ에 하나의 mount target을 만들 수 있음
    - (AZ, Subnet ID, Security groups)
      (2a, public-subnet-2a, lab-vpc-efs-sg)
      (2c, public-subnet-2c, lab-vpc-efs-sg)
- File system policy : 파일 시스템에 대한 접근을 json으로 설정함
EFS-EC2 마운트 EFS 생성 후 3분 정도 기다린 다음 마운트하는게 좋음
- PUTTY로 public-ec2-a1에 접속
```
1
2
3
4
5
df -h
sudo su
yum install amazon-efs-utils -y
cd /var/www/html
mkdir efs
```
  - EFS mount point 생성
- lab-vpc-efs 클릭 - Attach
  - EFS mount helper 사용 : sudo mount -t efs -o tls fs-0d44e69dbb21c80f5:/ efs
  - df -h로 확인
  - S3의 파일들의 Object URL을 wget으로 받아와서 접근 확인
웹 브라우저를 통한 EFS 마운트 테스트
- public-ec2-a1의 public IP 복사 [public IP]/efs/mycar.html로 접속해서 열리는지 확인
- public-ec2-c1에도 동일하게 efs mount
  - a1에서 다운받았던 파일들이 동일하게 있는 것 확인
  - http://52.79.119.85/efs/mycar.html에서 페이지 열리는지 확인
- c1 instance에서 mycar.html의 이름을 수정하고 다시 열면, a1 instance의 주소로 들어가도 수정된 버전으로 접속됨 → 파일이 instance끼리 공유됨

하나의 EFS를 여러 EC2 instance에 mount할 수 있음

5. Application Load Balancer를 통한 이중화 네트워크 구성 (1)

Target group 생성 EC2 - Load Balancing - Target Groups - Create target group 클릭

Load balancer는 traffic을 받으면 listener를 통해 target group으로 전환함
- Specify group details
  - Target type : Instances
  - Protocol : (HTTP, 80)
    - Application Load Balancer는 HTTP, HTTPS만 지원하기 때문에, 다른 protocol는 적용할 수 없음
    - Application load balancer와 타겟 EC2 instance 사이의 통신에 관한 protocol을 설정하는 것
      → target instance는 여기서 설정한 protocol, port로 들어오는 요청만 받아들임
    - 2번 단계에서 설정하는 포트는 ALB와 외부(client)간의 통신을 설정함
  - VPC : lab-vpc
  - Protocol version : HTTP1
  - Health checks : target instance의 상태 확인
  - Tags : (Name, lab-vpc-alb-public-tg)
- Register targets
  target : alb를 통해 트래픽을 받을 대상
  - public-ec2-a1, public-ec2-c1 둘 다 선택, Include as pending below 클릭 후 Register pending targets 클릭
Application Load Balancer 구성
EC2 - Load Balancing - Load Balancers - Create Load Balancer 클릭
Application Loab Balancer 생성
- Name : lab-vpc-alb-public
- Scheme : Internet-facing
- VPC : lab-vpc
- Mappings : 각각의 AZ에 대해 public-subnet을 선택
  - scheme이 internet-facing일 경우 인터넷과 연결되기 때문에, subnet에 외부와 통신 가능한 경로가 설정되어 있어야 함
- Create new security group
  - Name : lab-vpc-alb-public-sg
  - VPC : lab-vpc
  - Inbound rules
    - Type : HTTP
    - Source : 0.0.0.0/0
    - Tags : (Name, lab-vpc-alb-public-sg)
  - Security groups : lab-vpc-alb-public-sg(default는 제거)
    
    Listener가 lb로 들어오는 traffic/request를 받고 어느 target group으로 전달할지 rule을 기준으로 판단함
  - Listener HTTP:80
    - Default action : lab-vpc-alb-public-tg
      = listener의 rule
웹 브라우저를 통한 Application Load Balancer 작동 테스트
- Load Balancer의 Description - DNS name으로 접속해서 작동 확인
- 새로고침하면서 alb가 트래픽을 어디로 보냈는지 확인

6. Bastion host와 NAT Gateway를 통한 Private EC2 인스턴스의 외부 통신 구성

Private subnet에 EC2 생성
- Name : private-ec2-a1
- AMI : ami-public-ec2
- Key pair : ec2-private-seoul 생성
- VPC : lab-vpc
- Subnet : private-subnet-a1
- Auto-assign public IP : Disable
- Security group name : private-ec2-sg
- Inbound security groups rules
  - Type : HTTP, HTTPS
  - Source : 0.0.0.0/0, 0.0.0.0/0
Public subnet의 EC2를 통해 Private subnet의 EC2에 접속
- public-ec2-a1을 통해 private-ec2-a1로 접속하기 위해선 public-ec2-a1에 private-ec2-a1의 keypair가 있어야 함
- 생성한 keypair를 public-ec2-a1의 홈에 복사함 chmod 400 ec2-private-seoul.pem으로 권한 설정
- ssh -i ec2-private-seoul.pem ec2-user@10.1.3.98으로 private-ec2-a1 접속 → public-ec2-a1이 bastion host로 사용됨(중개 호스트)
- private-ec2-a1은 외부와의 직접적인 통신이 제한됨 ping google.com으로 테스트하면 트래픽이 가지 않음 - NAT gateway를 설정해서 업데이트 등을 위한 경로 개설
NAT Gateway 생성
VPC - Virtual private cloud - NAT gateways - Create NAT gateway 클릭
- Name : nat-gw-a1
- Subnet : public-subnet-a1
- Connectivity type : Public
- Elastic IP allocation ID : Allocate Elastic IP
  - NAT gateway에 연결된 network interface의 IP를 통해 통신하는데, 외부 인터넷과 통신이 가능해야 하기 때문에 public IP를 가져야 함
    → elastic IP로 NAT gateway의 IP를 할당함
    
    NAT gateway : Network Address Translation private subnet의 instance → 외부 연결 가능 외부 → private subnet의 instance 연결 불가능
Route table 설정 VPC - Virtual private cloud - Route tables - private-subnet-a1-rt - Routes - Edit routes 클릭
- Destination : 0.0.0.0/0
- Target : nat-gw-a1 추가
Private subnet의 EC2의 외부 통신 테스트
- public-ec2-a1을 통해서 접속했던 private-ec2-a1에서 다시 ping으로 테스트해보면 트래픽이 전송됨
- private-subnet-a1에 위치한 instance에서 외부로 향하는 traffic이 public-subnet-a1의 NAT gateway로 보내지고, public-subnet-a1의 route table 설정에 따라서 외부로 나가게 됨
private-ec2-c1 외부통신 구현
1. private-ec2-c1 instance 생성
  - Name : private-ec2-c1
  - AMI : ami-public-ec2
  - Key pair : ec2-private-seoul
  - VPC : lab-vpc
  - Subnet : private-subnet-c1
  - Security group : private-ec2-sg
2. NAT Gateway 생성
  - Name : nat-gw-c1
  - Subnet : public-subnet-c1
  - Allocate Elastic IP(새로운 eip 생성)
3. Route table 설정
  - private-subnet-c1-rt에 0.0.0.0/0에 nat-gw-c1으로가는 경로 추가
4. 접속 확인
  - 홈에 ec2-private-seoul.pem 복사
  - public-ec2-c1에서 private-ec2-c1 접속 후 핑 테스트

7. Application Load Balancer를 통한 이중화 네트워크 구성 (2)

Target group 생성

ALB를 외부와 통신이 가능한 public 영역에 두는 것은 보안상 안전하지 않음 private에 위치시켜 보자

EC2 - Load Balancing - Target groups - Create target group 클릭
- Specify group details
  - Target type : Instances
  - Name : lab-vpc-alb-private-tg
  - VPC : lab-vpc
- Register targets
  - private subnet 두 개 추가
Application Load Balancer 구성

EC2 - Load Balancing - Load Balancers - Create Load Balancer - Application Load Balancer Create
- Name : lab-vpc-alb-private
- VPC : lab-vpc
- Mapping
  - 2a : public-subnet-a1
  - 2c : public-subnet-c1
alb의 target은 private subnet에 위치한 두 instance인데, mapping이 public subnet인 이유
alb도 network interface의 IP를 통해서 통신함
→ 외부와 통신하기 위해선, igw를 통해 통신이 가능한 subnet에 위치해야 함
(외부의 traffic이 들어오면 target group인 private subnet의 instance에 들어와서 통신)
- Security group 추가 후 선택
  - Name : lab-vpc-alb-private-sg
  - Inbound rules : (HTTP, 0.0.0.0/0) 추가
  - Tags : (Name, lab-vpc-alb-private-sg)
- Listener HTTP:80 rule : Forward to를 lab-vpc-alb-private-tg로 설정
- Tags : (Name, lab-vpc-alb-private)
웹 브라우저를 통한 Application Load Balancer 작동 테스트
- lab-vpc-alb-private의 DNS name으로 접속 확인
  - private IP가 instance의 private IP인지 확인
(사용자의 requeset) → alb → private subnet의 instance → (request에 대한 response) → NAT gateway → igw → 웹 브라우저 출력

섹션 3. 관계형 데이터베이스 서비스 구성

Objective : MySQL DB를 복수의 AZ에 이중화로 구성하고 Linux 기반의 가상 서버와 MySQL DB를 연결

Untitled

Master, Standby, Read Replica 총 3개의 RDS로 구성됨
복수의 AZ에 DB를 생성하면 AWS가 하나를 master, 하나를 standby로 설정함
- 기본적으로 master가 서버와 연결되지만, master에 문제가 발생하면, standby가 서버와 연결되고, master로 바뀜 기존의 master는 standby로 바뀜
- Read Replica는 master와 sync를 맞추며 변동사항을 업데이트함
트래픽 흐름 : ALB → EC2 → NAT Gateway → igw
- DB에서 가져와야 할 정보가 있을 경우 EC2가 DB와 통신해서 가져옴

1. Amazon RDS를 통한 MySQL 데이터베이스 이중화(Multi-AZ) 구성

RDS용 Security group 생성

RDS를 생성하는 과정에서도 sg를 만들 수 있지만, 이때는 source가 자동으로 지정되어서 나중에 다시 수정해야 하기 때문에 미리 sg를 만들어 놓는게 좋음
- Type : MYSQL/Aurora
- Source : 10.1.0.0/16 lab-vpc에서 출발하는 트래픽을 허용하기 때문에 lab-vpc의 CIDR block으로 설정
- Tags : (Name, lab-vpc-rds-sg)
Subnet group 생성 RDS - Subnet groups - Create DB subnet group 클릭
- Name : lab-vpc-rds-subnet-group
- AZ : ap-northeast-2a, ap-northeast-2c
- Subnets : 10.1.5.0/24, 10.1.6.0/24
  private subnet을 가장 마지막에 만들었음
복수의 AZ에 MySQL DB 생성 RDS - Databases - Create database 클릭
- creation method : Standard create
- Engine type : MySQL
- Templates : Dev/Test
  - template은 storage class가 자동으로 세팅되는 차이 정도임
  - Free tier를 선택하면 multi AZ로 이중화하는 옵션이 사라짐
- Settings
  - DB instance identifier : lab-vpc-rds
  - Master username : admin
  - Master password : administrator
- Instance configuration
  - DB instance class : Burstable classes
  - instance : db.t2.micro
    - multi-AZ로 생성되는 instance는 요금이 과금됨(단일 AZ는 과금 안됨)
- Storage
  - Enable storage autoscaling : Disable
- Availability & durability
  - Multi-AZ deployment : Create a standby instance
    - subnet group에 등록된 subnet 중 임의의 한 subnet에 master db가 만들어지고, 나머지 한 개에 standby db가 만들어짐
- Connectivity
  - VPC : lab-vpc
  - Subnet group : lab-vpc-rds-subnet-group
  - Public access : No
  - Security group : lab-vpc-rds-sg
  - Database port : inbound rules에 설정한 포트와 동일한 값이 들어가 있음
- Database authentication
  - Database authentication : Password authentication
- Additional configuration
  - Initial database name : labvpcrds
  - Enable automated backups : Enable
    - 최근 버전의 mysql은 InnoDB를 지원하기 때문에 automated backup 사용 가능함
  - Backup retention period : 7
    - automated backup이 비활성화 되어있거나 Backup retention period가 0이면 read replica를 생성할 수 없음
  - Backup window : No preference
  - Enable Enhanced monitoring : Disable
  - Log exports : General log
  - Enable auto minor version upgrade : Enable
  - Maintenance window : No preference
  - Deletion protection : Disable
DB 정보 확인 DB 클릭 - Connectivity & security 클릭
- Endpoint를 이용해서 DB access, intance와 통신
- Availability Zone : 별도로 선택하지 않았지만, AWS가 임의로 선택해서 DB instance(master DB)를 생성
Configuration 탭 클릭
- Multi-AZ : Yes
- Secondary Zone : master DB가 있는 AZ가 아닌 다른 AZ로 설정됨
  - 이 AZ에 standby DB가 생성됨
    → DB가 이중화로 구성됨
EC2 - Network Interfaces에서 Security groups 기준 정렬
- lab-vpc-rds-sg에 대한 network interface 확인
  - ap-northeast-2a, 2c에 각각 하나씩 존재
  - 각각 description이 RDSNetworkInterface이고, private IP가 다른 것 확인
    → DB가 이중화됨

2. 웹 서버와 데이터베이스 인스턴스 연결

EC2 - DB 연결을 위한 정보 구성
EC2 - Load Balancers - lab-vpc-private의 DNS name에 접속

Failed to connect to MySQL 에러 남(db에 엑세스하지 못함)
index.php의 <?php include "dbinfo.inc"; ?>에서 DB 정보를 불러오기 때문에 이 파일을 생성해야 함

PUTTY로 public-ec2-a1 접속 → private-ec2-a1 ssh 접속

sudo su
cd /var/www/html
vi dbinfo.inc
*****************dbinfo.inc*****************
<?php

define('DB_SERVER', 'db_instance_endpoint');
define('DB_USERNAME', 'admin');
define('DB_PASSWORD', 'master password');
define('DB_DATABASE', 'sample');

?>
*******eg*******
<?php

define('DB_SERVER', 'lab-vpc-rds.cqafqb7woojr.ap-northeast-2.rds.amazonaws.com');
define('DB_USERNAME', 'admin');
define('DB_PASSWORD', 'administrator');
define('DB_DATABASE', 'labvpcrds');

?>
********************************************

private-ec2-c1도 동일하게 dbinfo.inc 생성
lab-vpc-private LB의 DNS name을 새로고침하면 에러 사라짐
→ private-ec2-a1, c1이 DB에 정상적으로 접근함

DB 접속

private-ec2-a1에서 아래 명령 실행(DB 접속)

mysql -h lab-vpc-rds.cqafqb7woojr.ap-northeast-2.rds.amazonaws.com -P 3306 -u admin -p

PW : administrator
show databases;로 DB 목록 출력
use labvpcrds;로 사용할 DB 선택

테이블 생성 및 데이터 입력

CREATE TABLE SAMPLE (
ID INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
NAME VARCHAR(45),
ADDRESS VARCHAR(90)
);

show tables;로 생성되었는지 확인

INSERT INTO SAMPLE (NAME, ADDRESS) VALUES ('KIM', 'SEOUL');
SELECT * FROM SAMPLE;

데이터 입력되었는지 확인

웹 브라우저를 통해 DB 연결 테스트
- private-ec2-c1으로도 db에 접속해서 (’LEE’, ‘BUSAN’) 넣고 확인

3. 데이터베이스의 Read replica 생성 및 웹 서버 연결

DB Read Replica 생성 RDS - Databases - lab-vpc-rds - Actions - Create read replica 클릭
- Settings
  - Replica source : lab-vpc-rds
  - DB instance identifier : lab-vpc-rds-rr
- Destination Region : Seoul
- Instance configuration
  - DB instance class : Burstable classes
  - instance : db.t3.micro
    - Include previous generation classes 체크해야 db.t2.micro 보임
- Storage
  - Enable storage autoscaling : Disable
- Multi-AZ deployment : Do not create a standby instance
- Connectivity
  - Subnet group : lab-vpc-rds-subnet-group
  - Security group : lab-vpc-rds-sg
  - Availability Zone : ap-northeast-2c
    - master DB가 있는 AZ 선택
EC2 - Read Replica DB 연결 PUTTY - public-ec2-a1 - private-ec2-a1 접속
- dbinfo.inc의 db endpoint를 바꿔줘야 함
```
1
2
3
sudo su
cd /var/www/html
vi dbinfo.inc
```
  - dbinfo.inc의 endpoint를 lab-vpc-rds-rr의 endpoint로 변경
- private-ec2-c1에 대해서도 동일하게 바꿔줌
웹 브라우저를 통해 Read Replica DB 연결 테스트

EC2 - Load Balancers - lab-vpc-alb-private의 DNS name에 접속해서 확인
원본 DB 변경 후 웹 브라우저를 통해 Read Replica 반영 테스트
- private-ec2-a1에서 원본 rds에 데이터 (’PARK’, ‘SUWON’) 추가 후 확인
  - 원본 DB에서 변경된 데이터가 read replica에 정상적으로 반영이 되었고, 해당 DB에 연결되어 있는 private-ec2-a1, c1을 통해서 출력된 것을 확인

4. Failover를 통한 데이터베이스 이중화 테스트

Master/Standby DB IP 정보 확인 PUTTY - public-ec2-a1 접속
- dig [rds endpoint]로 master, standby DB의 IP 확인
  - master DB
    - rds에서 endpoint 넣어서 확인
    - master DB IP : 10.1.6.250
  - standby DB
    - EC2 - Network interfaces에서 sg name으로 정렬해서 lab-vpc-rds-sg 중 다른 AZ 하나의 private IP
      - 같은 2c는 master, rr
    - standby DB IP : 10.1.5.94
Master DB Failover 테스트(Reboot with Failover) RDS - Databases - lab-vpc-rds - Actions - Reboot
- Reboot With Failover
Standby DB가 Master DB로 변경 확인
- master DB IP 다시 확인
  - master DB IP : 10.1.5.94
    → 2a에 있던 standby DB가 master로 변경됨
웹 브라우저를 통해 DB 연결 테스트 EC2 - Load Balancers - lab-vpc-alb-private의 DNS name 접속
- 추가한 데이터가 있는지 확인

섹션 4. Auto Scaling을 통한 확장성 및 탄력성 구성

Untitled

1. Auto Scaling을 위한 Launch Template 및 Application Load Balancer 구성

AMI 생성

EC2 - instances - private-ec2-a1 우클릭 후 Create image

name : ami-private-ec2
No reboot : enable
Tags : (name, ami-private-ec2)

ami-private-ec2 Available 확인 후 instance 4개 모두 stop

Auto Scaling group에서 사용할 수 있는 template의 종류: Launch configuration : 새로 만들어서 변경 사항을 적용해야 함 Launch template : 동일한 template의 버전만 바꿔서 변경 사항 적용 가능

Launch template 생성

EC2 - Launch Templates - Create launch template 클릭

name : lab-vpc-asg-lt
ami : ami-private-ec2
Instance type : t2.micro
Key pair : ec2-private-seoul
Network settings : instance가 생성될 때 적용될 네트워크 옵션
- Subnet : Don’t include in launch template instance를 특정 subnet에 국한시키지 않기 위함
- Firewall(security groups) : private-ec2-sg

ALB 생성

Target group 생성 EC2 - Target groups - Create target group 클릭
- name : lab-vpc-alb-asg-tg
- VPC : lab-vpc
- Tags : (Name, lab-vpc-alb-asg-tg)
- target group에 instance를 포함시키지 않음
  - auto scaling으로 생성되는 instance들이 자동으로 추가됨
Load balancer 생성
EC2 - Load balancers - Create Application Load Balancer 클릭
- name : lab-vpc-alb-asg
- Network mapping
  - VPC : lab-vpc
  - mapping
    - ap-northeast-2a : public-subnet-a1
    - ap-northeast-2c : public-subnet-c1
  - Create new security group 후 선택
    - name : lab-vpc-alb-asg-sg
    - VPC : lab-vpc
    - Inbound rules
      - Type : HTTP
      - Source : 0.0.0.0/0
    - Tags : (Name, lab-vpc-alb-asg-sg)
  - Listeners and routing Default action : lab-vpc-alb-asg-tg
  - Tags : (Name, lab-vpc-alb-asg)

2. Auto Scaling Group 및 Scaling Policy 구성

Auto Scaling group 생성

EC2 - Auto Scaling groups - Create Auto Scaling group 클릭

Name : lab-vpc-asg
Launch template : alb-vpc-asg-lt
Version : template에 변경 사항이 발생할 경우 버전을 사용해서 적용 가능 변경 사항이 생길 때마다 버전을 변경해서 생성 Next
Network
- VPC : lab-vpc
- AZ and subnets : private-subnet-a1, private-subnet-c1 Next
Load balancing : Attach to an existing load balancer
Health checks : EC2만 EC2가 기본으로 선택, ELB도 선택하면 load balancer도 health check 실행
Health check grace period : 60
Monitoring : Enable Next
Group size : instance를 몇 개까지 scale out/in 할 것인지 설정
- Desired capacity : 2 초기 활성화되기 원하는 instance의 수
- Minimum capacity : 2 asg에서 활성화될 수 있는 최소 EC2 intance의 수
- Maximum capacity : 4 asg에서 활성화될 수 있는 최대 EC2 intance의 수
Scaling policies : Target tracking scaling policy auto scaling이 작동하는 기준 - Scaling policy name : lab-policy-01 - Metric type : Average CPU utilization - Target value : 7 as가 쉽게 작동하게 만들기 위해 낮게 설정 - Instances need : 60
Instance scale-in protection : Disable scale-in이 될 경우 EC2 instance가 삭제되지 않도록 보호할 것인지 Next
Tags : (Name, asg-ec2) Tag new instances 선택해놓으면 as로 생성되는 instance들이 설정한 태그를 가지게 됨
생성한 asg - Activity에서 event log 확인 가능
desired capacity가 2이기 때문에 as가 실행되면서 asg-ec2가 2개 생성됨
lab-vpc-alb-asg-tg에 생성된 asg-ec2 2개가 자동으로 target에 등록된 것 확인
ALB lab-vpc-alb-asg의 DNS name으로 접속해서 새로고침하면서 load balancing 동작 확인

3. Auto Scaling Scale-Out 테스트

apache-bench-test를 통해서 부하를 주고 scale-out을 테스트할 예정

EC2 - Instances - public-ec2-a1을 Start instance로 시작 PUTTY로 public-ec2-a1에 접속

yum install httpd-tools -y
httpd-tools 설치
ab -n 200000 -c 1000 http://<alb dns name>/
ab -n 200000 -c 1000 http://lab-vpc-alb-asg-97160126.ap-northeast-2.elb.amazonaws.com/
200000개의 request 중 1000개를 보냄

CloudWatch - Metrics - All metrics - Browse - EC2 - Per-Instance Metrics - CPUUtilization 검색

두 instance 모두 CPU 사용률이 7% 이상으로 설정된 것 확인
EC2 Instances로 이동해서 asg-ec2 4개로 증가한 것 확인
Auto Scaling groups - lab-vpc-asg - Activity로 이동해서 history 확인
- 사용량이 증가해서 desired capacity를 올렸고, actual capacity와 차이가 있어 scale-out이 수행됨
PUTTY에서 test 종료

4. Auto Scaling Scale-In 및 Termination policy 살펴보기

Auto Scaling groups - lab-vpc-asg - Activity로 이동해서 history 확인
- CPU 사용률이 tracking policy에서 정한 값보다 작아져서 CloudWatch의 alarm이 tracking policy를 trigger해서 desired capacity를 줄이고 instance를 termination함
Termination policy : Scale-In이 될 때 termination될 instance를 선택하는 기준

Auto Scaling groups - lab-vpc-asg - Details - Advanced configurations - Edit 클릭

Termination policies
- Default : as의 instance 중에 더 오래된 launch template을 사용한 instance 선택
  - launch template이 동일하다면 비용 결제 시간이 더 가까워진 instance 선택
- Closest To Next Instance Hour : 비용 결제 시간이 가까운 instance 선택
- Newest Instance, Oldest Instance : 생성된 시간 기준
- Oldest Launch Configuration : launch configuration이 가장 오래된 instance 선택
- Oldest Launch Template : launch template이 가장 오래된 instance 선택
- Custom termination policy도 정의 가능
Suspended processes : 특정 프로세스를 일시 중단시키는 기능 Auto scaling에는 launch(instance 시작), terminate(instance 종료) 프로세스 등의 여러 프로세스가 존재함
Maximum instance lifetime : instance의 최대 수명
Default cooldown : instance가 생성/제거될 때 대기하는 시간

실습 리소스 삭제 및 정리

Auto Scaling group 제거
Launch Templates 제거
Load Balancers 제거
Target Groups 제거
EC2 Instance Terminate
RDS 삭제
- snapshot 생성, 7일간 백업 유지 옵션 존재(Primary만 존재, Replica에는 없음)
DB Subnet Group 삭제
EFS 삭제
NAT Gateway 삭제
CloudFront Distribution 삭제
S3 Bucket 비우기 Empty 사용
S3 Bucket 삭제
Elastic IP 삭제 Release
VPC 삭제 VPC, Subnet, Route table, Security group이 같이 삭제됨
AMI 삭제
EBS Snapshot 삭제 Custom AMI 생성 시 만들어졌음
Key pair 삭제(optional)

Share on

Twitter Facebook LinkedIn

양효원

스스로 구축하는 AWS 클라우드 인프라 - 기본편

다루는 내용

EC2 인스턴스 생성

PUTTY 연결

1. S3 Bucket 생성 및 정적 웹사이트 호스팅

2. CloudFront를 통한 웹사이트 성능 가속화

1. 기본 네트워크 환경 구성 (VPC/Subnet/Internet Gateway/Route Table)

2. Public EC2 인스턴스 생성 및 LAMP 웹서버 구성

3. Custom AMI를 통한 Public EC2 인스턴스 생성

4. EFS를 통한 네트워크 파일 시스템 구성

5. Application Load Balancer를 통한 이중화 네트워크 구성 (1)

6. Bastion host와 NAT Gateway를 통한 Private EC2 인스턴스의 외부 통신 구성

7. Application Load Balancer를 통한 이중화 네트워크 구성 (2)

1. Amazon RDS를 통한 MySQL 데이터베이스 이중화(Multi-AZ) 구성

2. 웹 서버와 데이터베이스 인스턴스 연결

3. 데이터베이스의 Read replica 생성 및 웹 서버 연결

4. Failover를 통한 데이터베이스 이중화 테스트

1. Auto Scaling을 위한 Launch Template 및 Application Load Balancer 구성

AMI 생성

Launch template 생성

ALB 생성

2. Auto Scaling Group 및 Scaling Policy 구성

Auto Scaling group 생성

3. Auto Scaling Scale-Out 테스트

4. Auto Scaling Scale-In 및 Termination policy 살펴보기

Share on

Leave a comment

You may also enjoy

BOJ 16236 - 아기 상어

BOJ 1918 - 후위 표기식

BOJ 1865 - 웜홀

BOJ 1238 - 파티