[AWS] 3-Tier Web Application Architecture 구성 프로젝트

1. Cloud Architecture 구현

1.1 실제 구현한 Architecture 구조

 

 

1.2 (2.1)에 대한 각 구성요소 및 구조에 대한 근거

 

1)     서울 region과 VPC : 한국 고객 위주로 운영이 되는 온라인 쇼핑몰이므로 서울 region 내 VPC를 구성하도록 구현하였다. 이는 비용 문제와 관리 측면에서의 장점으로 단일 region을 구축하였다. VPC는 가상 사설망을 말한다. VPC를 적용하면 네트워크를 구성할 수 있고, 각각의 VPC에 따라 다르게 네트워크 설정을 주어 독립된 네트워크처럼 작동하게 된다. 우선, CIDR(사이더)표기법으로 해당 네트워크 영역(ip대역)을 지정한다. 정부 네트워크 규모가 아니므로 C 클래스의 192.168.0.0/16 ip 주소를 할당한다.

AWS 상의 서울 region

구현한 VPC (Name : DGU-VPC, IPv4 CIDR : 192.168.0.0/16)

 

2)     가용 용역 (Availability Zone) : 가용성에 의거하여 가용 용역(AZ)을 2개로 설정하였다. 가용성은 해당 시스템이나 서비스가 가동 및 실행되는 시간의 비율을 말한다. 각 AZ는 리전 내에서 물리적으로 격리되어 있고, 사용자는 시스템이 상주할 AZ를 선택해야 한다. AZ를 하나로 구현했을 경우, 자연 재해나 시스템 장애 등 상황에서 VPC 전체의 가용성이 떨어지므로 AZ를 두 개로 구현한다.

 

3)     서브넷 (Subnet) 구성 : 서브넷은 VPC의 IP 주소 범위이다. VPC 안에 서브넷을 여러 개 추가하여 내부를 논리적으로 쪼갠다. Subnet은 각 AZ에서 Public subnet 하나와 Private subnet 세 개로 나눈다. 두 개의 Public subnet 중 하나에는 bastion host가 상주하고, 각 AZ의  Private subnet에는 Web server와 WAS, DB가 상주한다. 이는 VPC에서 총 8개의 서브넷(hosts)가 필요하므로 192.168.0.0/16에서 host bit 3개를 빌려 /19 prefix로 나타낸다. 각 서브넷의 ip 주소는 다음과 같다.

구현한 Subnet(public 2개, private 6개)

 

4)     인터넷 게이트웨이 (Internet Gateway) 구성 : Public 서브넷은 외부에서 내부로의 접근이 가능해야 한다. 이는 Internet Gateway; IGW와 연결하여 Private 서브넷으로 들어오고 나갈 수 있는 통로가 되도록 한다. 여기서 IGW는 EC2 인스턴스와 인터넷 사이 통신을 가능하도록 하는 역할이다. 즉, 트래픽이 외부에서 들어오고 외부로 나가는 것을 가능하는 역할로, 다음과 같이 생성한다.

구현한 Internet Gateway

 

5)     라우팅 테이블 (Route Table) 구성 : 라우팅 테이블은 ip 주소에 대해 목적지와 그 목적지에 대한 라우팅 경로를 설정한다. 이는 Public과 Private을 나눠 설정하고 각각 Public, Private 서브넷에 연결한다. Public 라우팅 테이블은 기본적으로 VPC 안의 로컬로 가라는 경로가 있다. 따라서 첫 번째로 VPC 안에 해당하는 주소(192.168.0.0/16)인지 확인하고, 매칭되지 않으면 다음 설정한 경로를 따라간다. 이는 우리가 모든 트래픽에 대하여 Internet Gateway로 향하는 경로로 설정한다. Private 라우팅 테이블도 같은 방법으로 Private 서브넷들과 연결시켜준다.

구현한 Public 라우팅 테이블	구현한 Private 라우팅 테이블

 

6)     Bastion host : 외부에서 접근 불가능한 Private Subnet에 접근하기위해 각각의 AZ의 Public Subnet 중 하나에만 bastion host를 구현하였으며, bastion host를 통해 특정 IP만이 Private Subnet에 접근 가능하도록 설정하였다. 인바운드 규칙에 관리자의 My IP 주소를 설정하여 관리자만이 Bastion Host를 통한 연결 및 관리가 가능하도록 구현하였다. Bastion host를 이용함으로 한곳에서 모든 접근을 관리함으로써 관리가 수월하며 모든 접근에 대한 로그 또한 한곳에서 확인할 수 있다.

인스턴스 ID	i-0b000ff83f28c621f
Public IPv4 주소	13.124.131.11
Private IPv4 주소	192.168.1.15
서브넷	subnet-044197998a5a9d304
키 페어 이름	dgu_public_keypair
보안 그룹	sg-0baffe57ef5f61bc5

 

7)     웹 서버 티어 (Web Server Tier) : Private Subnet 안에 Web Server 역할을 할 수 있는 인스턴스를 구축한다. 프리티어 사용자의 설정에 맞게 설정한 후 생성한 VPC와 서브넷을 세부사항에서 선택해준다. (서브넷은 각각 DGU-az1-private1, DGU-az2-private1이다) 이후 보안그룹에서는 웹 접속이므로 HTTP 유형 80 포트로 모두 접속할 수 있도록 설정한 후, Bastion Host에서 접근할 수 있도록 SSH 유형 22 포트로 Bastion Host Security Group에서 통과한 트래픽에 대해서만 들어올 수 있도록 개방한다. (보안그룹은 Inbound Traffic)에 대한 정책설정을 할 수 있고, Outbound Traffic에 대한 정책설정을 하기 위해서는 Network ACL 기능을 사용해야 한다)

구현한 Web Server Tier 인바운드 규칙

Web Server Tier 내에 구현한 인스턴스 정보 (AZ1)

Web Server Tier 내에 구현한 인스턴스 정보 (AZ2)

 

8)     웹 어플리케이션 티어 (Web Application Tier) : Private Subnet 안에 Web Application Server 역할을 할 수 있는 인스턴스를 구축한다. 프리티어 사용자의 설정에 맞게 설정한 후 생성한 VPC와 서브넷을 세부사항에서 선택해준다. (서브넷은 각각 DGU-az1-private2, DGU-az2-private2이다) 이후 보안그룹에서는 WAS 접속이므로 HTTP 유형 8080 포트로 Internal ELB를 통과한 트래픽에 대해서만 들어올 수 있도록 설정한 후, Bastion Host에서 접근할 수 있도록 SSH 유형 22 포트로 Bastion Host Security Group에서 통과한 트래픽에 대해서만 들어올 수 있도록 개방한다.

구현한 Web Application Tier 인바운드 규칙

Web Application Tier 내에 구현한 인스턴스 정보 (AZ1)

Web Application Tier 내에 구현한 인스턴스 정보 (AZ2)

 

9)     DB(MySQL) : Availability zone 1-1에 dgu-db를 보안그룹으로 하는 dgu-az1-db를 생성하고 dgu-az1-db를 복제(read replica)하여 Availability zone 1-2에 dgu-az2-db를 생성하였다. 쓰기 작업은 Master DB 인스턴스(dgu-az1-db)에 하고 읽기 작업은 Read Replica인 Slave DB 인스턴스(dgu-az2-db)에서 실시하면 마스터 DB 인스턴스의 부하를 줄일 수 있다.
[DB Peering 확인]

-EC2 인스턴스에서 mysql monitor에 접속한다. (dgu-az1-db에 접속)

Mysql -uadmin -pPassw0rd -hdgu-az1-db.cvgzas5348hf.ap-northeast-2.rds.amazonaws.com

-데이터 베이스 ‘cloud4c’를 생성한다.

CREATE DATABASE cloud4c CHARACTER SET utf8 COLLATE utf8_general_ci;

-데이터를 추가한다.

아래 사진들을 보면 내용을 따로 추가하지 않아도 dgu-az1-db의 database가 복제된 것을 확인할 수 있다. RDS read replica는 손쉽게 단일 DB 인스턴스의 용량 한도 이상으로 탄력적으로 확장하여 읽기 중심의 데이터베이스 워크로드를 처리할 수 있고, 특정 소스 DB 인스턴스의 복제본을 여러 개 만들어 여러 데이터 사본이 요청하는 높은 애플리케이션 읽기 트래픽도 처리할 수 있어 전체 읽기 처리량이 향상된다. 따라서 DB 인스턴스의 성능과 내구성을 높여준다.

구현한 dgu-az1-db peering 확인	구현한 dgu-az2-db peering 확인

 

10)  SSH 접근 : 암호화된 통신을 위해 SSH 접속 프로그램 PuTTY를 사용하였다.

10.1) ppm파일(key pair)를 ppk파일(key pair)로 변환하기 위해 ‘PuTTY key Generator’를 이용하였다

key pair.ppm à key pair.ppk 변환	변환된 key pair 파일

10.2) PuTTY를 이용하여 Bastion host에 접속한다(Public IP 사용)

PuTTY를 이용한 Bastion host 접근

 

11)  WEB, WAS, DB에 대한 연동 확인

Bastion host를 통한 WEB1 접속 확인	Bastion host를 통한 WEB2 접속 확인

 

Bastion host를 통한 WAS1 접속 확인	Bastion host를 통한 WAS2 접속 확인

 

Bastion host를 통한 DB1 접속 확인	Bastion host를 통한 DB2 접속 확인

  

12)  Load Balancer : Internet Gateway로 들어온 트래픽을 WEB으로 분산시키는 external ELB “DGU-ALBWEB”과 내부 WEB으로 들어온 트래픽을 WAS로 분산시키는 internal ELB “DGU-ALBAPP”을 생성하였다.먼저, DGU-ALBWEB의 가용영역은 외부 트래픽을 다룰 수 있게 public subnet1,2로 설정해주었다. 보안그룹은 외부에서 들어오는 어떤 IP이든 허용하였다. HTTP 프로토콜의 80포트를 타고 타겟을 찾아가도록 설정하였으며, 타겟 그룹은 private subnet(web instance)로 설정하였다. DGU-ALBAPP의 가용영역은 private 서브넷에 있는 ec2들을 Load Balancing하기 위해, 그 앞인 private subnet(web instance)1,2로 설정해주었다. 보안그룹은 web security group을 통과한 IP만 허용하였다. 타겟 그룹은 private subnet(app instance)로 설정하였다.

구현한 Elastic Load Balancer

구현한 ‘DGU-ALBWEB’의 Security Group 인바운드 규칙

구현한 ‘DGU-ALBWEB’의 Target Group

구현한 ‘DGU-ALBAPP’의 Security Group 인바운드 규칙

구현한 ‘DGU-ALBAPP’의 Target Group

 

13)  Auto Scaling : 시나리오의 온라인 쇼핑몰은 고객층, 고객수에 대한 정보가 없기 때문에, 급속도로 접속자가 올라가는 상황을 고려해야한다. 따라서, Auto Scaling을 이용해 수요가 급증할 때 Amazon EC2 인스턴스 수를 자동으로 늘려 대응하면 더 효율적으로 운영할 수 있다

구현한 Autoscaling Group

가용영역 AZ1과 AZ2간의 web instance를 균일하게 분산시켜주는 dgu-ac1과 application instance를 균일하게 분산시켜주는 dgu-ac2를 생성하였다. Dgu-ac1,2의 그룹크기는 아래 사진과 같이 설정하였다. 앞서 만들었던 Load Balancer ‘DGU-ALBWEB’과 dgu-ac1을 연결해주었고 ‘DGU-ALBAPP’과 dgu-ac2를 연결해주었다. 평균 CPU 사용률이 3%가 넘으면 인스턴스의 수를 동적으로 조정하여 인스턴스를 최대 3개까지 추가로 생성하여 시작할 수 있도록 설정해주었다.

구현한 Autoscaling Group의 세부 정보

[Auto Scaling 활성화 테스트]

평균 CPU 사용률이 3%가 넘으면 인스턴스의 수를 동적으로 조정하도록 설정해주었다. putty에 접속하여 부하발생기(sudo yum install stress -y)를 설치하고 stress test를 통해서 인스턴스가 추가 생성 되었는지 확인하였다

구현한 Autoscaling Group의 Instance
부하 발생
부하 발생으로 인한 인스턴스 추가 생성

 

14)  IAM 관리자 설정 : IAM 사용자 역할을 나눌 때, 개발자 관점에서의 사용자 그룹과, 관리 분야 관점에서의 사용자 그룹으로 나누어 권한을 세분화해 IAM계정을 생성했다, 클라우드 이용자는 이 IAM을 통해 관리 및 개발을 하도록 하여, 필요한 권한 이상으로 권한을 가지지 못하도록 해, 보안성을 높였다. IAM 그룹을 크게 Developer, EC2_Admin, ProductManager, RDS_admin, S3_Admin으로 나누었다.

• Developer : 전체적으로 모든곳에 접근이 가능해야 하기 때문에 (AmazonRDSFullAccess, AmazonEC2FullAccess, AmazonS3FullAccess, CloudWatchFullAccess) 권한을 부여했다.
• EC2_Admin : EC2관리자로서 AmazonEC2FullAccess 권한 부여
• ProductManager : 기획자는 cloud의 각 지표 상태를 분석해 추후 서비스를 계획하기위해 AmazonEC2ReadOnlyAccess, CloudWatchFullAccess, AmazonS3ReadOnlyAccess, AmazonRDSReadOnlyAccess권한 부여
• RDS_admin : 데이터베이스 관리자로서 AmazonRDSFullAccess권한 부여
• S3_Admin : 추후 서비스제공에 필요하다 판단하여 AmazonS3FullAccess권한 부여

 

 

15)  Bastion host, SSH key : security group의 개수가 많아지면 해당 instance에 접근 할 수 있는 ssh key또한 여러 개 생기게 된다. 이때 이 시스템에 작업해야하는 개발자들이 모두 각자 컴퓨터에 ssh key들을 저장해 놓고 사용하면 관리도 어려워지고 보안위협에도 노출되기 쉬워진다. 따라서 VPC내부에 Bastion Host 인스턴스를 생성하여 모든 키를 관리하도록 했다. Bastion Host는 Public subnet안에 생성하여 Public 주소를 이용하여 접속 가능하도록 하였고, 이때 접속 방식은 SSH를 이용하도록 하여 개발자들은 단 하나의 ssh key를 소유한다. 그리고 Bastion Host를 통해 내부 Private subnet안의 각 instance들을 SSH를 통해 접속할 수 있도록 하였고, ssh 보안키는 Bastion Host에 (chmod 400 sshkey.pem) 명령어로 읽기 권한만 허용해 보안을 강화 했다.

 

---

Designing a Three-Tier Architecture in AWS (https://medium.com/the-andela-way/designing-a-three-tier-architecture-in-aws-e5c24671f124)

프라이빗 IP 주소가 할당된 백엔드 인스턴스를 ELB의 인터넷 연결 로드 밸런서에 연결 (https://aws.amazon.com/ko/premiumsupport/knowledge-center/public-load-balancer-private-ec2/)

[AWS] Private instance와 Load Balancer연결 시 timeout이 발생하는 이슈 (https://hello-world.kr/1)

Bastion Host 운영 (http://blog.plura.io/?p=13106)

AWS - Bastion Host를 통해 PrivateSubnet 내의 Host 관리하기 (https://galid1.tistory.com/365)

아마존 클라우드 해킹사례 (https://www.hankyung.com/it/article/201907313937i)

이마존 클라우드 공식문서 (https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/concepts.html)

서비스 운영이 쉬워지는 AWS 인프라 구축 가이드, 김담형, 2019, 위키북스

bastion host를 통해 privatesubnet 내의 host 관리하기

(https://galid1.tistory.com/365)

security group과 network acl 비교

(https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sehyunfa&logNo=221979530198)

 

-      https://galid1.tistory.com/352 (RDS 접속)

-      https://galid1.tistory.com/369?category=765379 (Autoscaling 부하 발생 테스트)

-      https://ssyauu580.tistory.com/355 auto scaling (Autoscaling 부하발생 테스트)

-      https://galid1.tistory.com/368 (ELB 구축)

-      https://pearlluck.tistory.com/71?category=855676 (Load balancer)

-      https://galid1.tistory.com/365 (Bastion Host 구현)

-      https://opentutorials.org/course/608/3122 (data peering)

-      https://sweetysnail1011.tistory.com/19 (auto scaling)

-      https://velog.io/@nari120/Route53-DNS-%EA%B5%AC%EC%B6%95.-AWS-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0 (Route53)

-      https://galid1.tistory.com/367 (NAT Gateway)

-      https://youtu.be/fGzubEOfyLY (웹서버 접속)

-      https://victorydntmd.tistory.com/67 (IAM)

-      https://tech.cloud.nongshim.co.kr/2018/10/11/%EC%B4%88%EB%B3%B4%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%9C-aws-%EC%9B%B9%EA%B5%AC%EC%B6%95-%EC%9B%B9%EC%84%9C%EB%B2%84-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%86%8C%EA%B0%9C/ (VPC)

-      https://base-on.tistory.com/63 (IGW/VPC로 만든 EC2에 인터넷 연결)

-      https://galid1.tistory.com/367 (NAT Gateway를 통한 Private Subnet 인터넷 연결)

-      https://hack-cracker.tistory.com/111 (UDP, TCP)

-      https://goldsony.tistory.com/37 (Web, WAS)

-      https://opentutorials.org/course/608/3106 (RDS)

-      https://acstory.tistory.com/33 (S3 개념)

-      https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/concepts.html  (키관리 설정)

-      https://blog.naver.com/timeless947/221930530204 (IAM 관리자 설정)

-      https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/creating-buckets-s3.html  (S3)