Simple 3-Tier Architecture Project Step 2 (구현)

이전 게시물에서 3Tier란 무엇인가와, 클라우드 환경에서 3Tier를 구현하면 얻을 수 있는 장점에 대해 알아보았다.

이제 구현을 하기 위해 간단한 웹 어플리케이션을 개발한다.

언어는 Python, 프레임워크는 Django를 사용하였다.

 

 

1. 웹 어플리케이션 구현

Application Code => https://github.com/KimHyoSeob/3tier-was

프로젝트 생성

구현된 어플리케이션 사진1

구현된 어플리케이션 사진2

# Django 개발 시 주의점!

# Django는 DEBUG=False로 설정 시 정적 파일을 제공하지 않기 때문에
# Web티어에서 Nginx 등으로 제공하여야 한다.

 

 

 

---

 

2. Local VM 환경에서 테스트

클라우드 환경으로 마이그레이션 하기 전에 OracleVM을 이용하여 3Tier 환경에서 테스트를 한다.
각 머신 별로 다음과 같은 과정을 진행한다

Presentation Tier - VM

sudo apt install git -y  # 깃 설치

git clone https://github.com/KimHyoSeob/3tier-web # 정적 웹 페이지 클론

sudo apt install nginx -y # nginx 설치
sudo cp -r 3tier-web/. /usr/share/nginx/html/ # 정적 웹파일옮기기

sudo cp 3tier-web/nginx.conf /etc/nginx/. # Nginx 설정파일 옮기기
# 이 설정 파일에는 프록시, Was에 제공할 정적 콘텐츠를 설정하는 파일이다.
# DEBUG = False 로 설정했을 경우, Django에서 정적 컨텐츠(사진) 등을 사용할 수 없기 때문에
# Nginx로 몰아준다.


# 도메인/ 으로 접속할 경우 정적 웹 사이트로 이동하게 되고 
# 도메인/visitor 으로 접속할 경우 Nginx가 Was쪽으로 프록시를 하게 된다.

 

Logic Tier - VM

sudo apt update -y
sudo apt install git -y  # 깃 설치
sudo apt install python -y  # 파이썬 설치
sudo apt install pip -y  # pip 설치
git clone https://github.com/KimHyoSeob/3tier-was # Was 클론

cd 3tier-was # 프로젝트 폴더로 이동
sudo pip install -r requirements.txt # 필수 파이썬 라이브러리 설치
sudo apt install python3-mysqldb # 기본 db.sqlite가 아닌 별도의 DB서버를 사용하기 위해 설치

sudo python3 manage.py migrate # DB에 Django에서 정의한 모델을 만든다 
# 이 작업이 정상적으로 수행될 경우 DB와의 연결에 성공한 것
sudo python3 manage.py runserver 0.0.0.0:80 # 서버 시작

 

Data Tier - VM

sudo apt update -y    # 업데이트
sudo apt install mysql-server -y # mysql 서버 설치
sudo service mysql start # mysql 스타트


sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf # 파일 수정
# 여기서  bind-address = 0.0.0.0 으로 수정한다. 
# 0.0.0.0으로 했을 경우 보안상의 문제가 있다. 현재는 테스트 환경이기에 패스


sudo mysql # DB에 연결하기 위해 아래와 같이 초기 설정을 한다
#-----------------------------------------------------
CREATE DATABASE [DBname];
CREATE USER 'name'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'name'@'%'
FLUSH PRIVILEGES;
#------------------------------------------------------
# Django Was 전용 데이터베이스와, 유저를 만들고 권한을 주는 명령어 이다.
# 이또한 PRIVILEGES를 저렇게 *.*로 하면 보안상 문제가 있으니 주의

 

 

Local VM 환경에서의 테스트 결과

정적 웹 페이지 화면

Nginx 가 실행중인 정적 웹 서버의 주소 192.168.56.10 으로 접속하면 다음과 같은 정적 웹 페이지가 보인다.

정적 웹 페이지

 

동적 웹 페이지 화면

정적 웹 페이지에서 상단의 네비게이션 바를 눌러 방명록 홈 즉, 192.168.56.10/visitor 으로 요청하게 되면,
Nginx에서 설정된 대로 /visitor경로에 대한 프록시를 WAS로 전달하게 되어 다음과 같은 페이지가 보인다.

 

Logic Tier로 프록시된 상태

 

그리고 다음과 같이 사진처럼 정상적으로 연결되었기 때문에 데이터 입력도 가능하다.

방명록 화면

 

 

Database 화면

정상적으로 데이터입력이 된 모습

 

 

---

 

 

3. 클라우드 환경으로 마이그레이션

인프라 구상

먼저 3tier에 맞게 클라우드 인프라를 구상해보자

클라우드 인프라

Route53 : 도메인 기반으로 접속하기 위해 필요하다.
Internet Gateway : 깃 클론등 외부 인터넷에 접속하기 위해 필요하다.
NAT Gateway : 인스턴스들이 Private 영역에 존재하기 때문에, NAT를 통해 외부로 접속 가능하다.
(외부)Load Balancer : 가용성을 위해 2개의 가용영역을 생성하고, 이를 라운드로빈 방식으로 트래픽을 분해한다.
Auto Scaling Group : 급변하는 트래픽에 유동적으로 대응하기 위해 필요하다.
(내부)Load Balancer : 다중 가용영역의 Logic Tier 인스턴스에 트래픽을 전달하기 위해 필요하다.
RDS Cluster : 1개의 Master(Read/Write)와 1개의 Secondary(Read Only)로 구성하여 가용성을 유지
Cloud Watch : 사진에는 없지만 CPU 사용률 기반으로 모니터링 
SNS : Alert와 연동하여 CPU의 사용률이 임계값을 넘을 경우, Email 을 통해 알림이 오도록 설정

 

 

인프라 생성

인프라를 구상하였으니 인프라를 생성한다.

인프라는 Terraform 이라는 IAC 도구를 이용하여 적용하였다.

Terraform Code => 3Tier-Project 과정 (notion.site)    (하단)

1. 클라우드 환경으로 마이그레이션 하기 위해 클라우드 인프라를 만들어야 한다.
2. 하지만 콘솔에서 GUI 환경으로 작업하기에는 시간이 오래 걸린다.
3. 따라서 테라폼을 이용해서 인프라를 생성한다. 

장점 : 
• 쉽게 재사용 가능 
• 인프라의 생성과 삭제를 자동화 할 수 있다.
• 코드로 되어있기 때문에 어디가 문제인지 한눈에 보인다

 

정상적으로 Apply가 된 모습

 

생성된 인프라 확인

VPC~Subnet

 

외부 ELB ~ EC2(Presentation Instance)

 

Launch Template & Auto Scaling Group

 

내부 ELB ~ EC2(Logic Instance)

 

Database

 

Cloud Watch & SNS

 

 

로드밸런싱 확인
새로고침하며 가용영역, 인스턴스 ID, Subnet ID 로드밸런싱 확인

 

Flow

1. 사용자가 도메인(khs-cloud.click)으로 접속한다.
2. 도메인은 ELB와 연결되어있어, 로드밸런서가 Auto Scaling Group의  Target Group에 연결되어,
    Target Group(Web Instance)로 트래픽이 전달된다.
3. 사이트에 접속한 사용자가 /visitor로 접속을 요청하면 Web Instance 의 Nginx가 내부의 ELB로 프록시한다.
4. 다시 내부의 ELB가 Was Target Group으로 트래픽을 전달하여 Was 에 접속된다.
5. 사용자가 Write작업을 하면 RDS Cluster의 Master DB에 데이터가 쓰여지고 Secondary DB에는 복사가 된다.
6. 이후 게시물을 조회하는 등의 작업(Read)은 RDS Cluster 의 DB에 라운드 로빈으로 각각 트래픽을 나눠받는다.

DB 장애 발생 시
Mater DB에 장애가 발생 시, RDS Cluster가 자동으로 Faile Over 작업을 진행하여 Secondary DB가
Master DB로 승격된다.

Instance CPU 사용률 임계치 초과 시
Alert로 설정해준 값을 초과 시 SNS 로 전달되어 사전 설정된 Email로 알림을 받을 수 있다.

---