AWS 2일차
표현계층은 nginx, 응용계층으로는 tomcat, 데이터저장으로는 RDS를 사용하여 AWS에서 간단한 3tier 구성을 실습해보았다.
실습
`tomcat` 이름의 private-subnet 인스턴스를 생성.
`tomcat` 인스턴스에 접속하기 위한 `bastion` 이름의 public-subnet 인스턴스를 생성하였다,
`bastion` 인스턴스로 SSH접근 후
sudo -i
vim kedu501.pem
chmod 600 kedu501.pem
ssh -i kedu501.pem ubuntu@10.10.2.65 // verify
=> 키페어로 tomcat 내부IP로 접근이 가능하다.
NAT gateway 사용을 위해 고정 공인 IP를 할당이 필요하다.
공인 IP 할당 후 Private Subnet에 존재하는 인스턴스의 패키지 설치를 위해 NAT gateway를 생성한다.
생성한 뒤 `vpc-private-rt` 라우팅 테이블을 편집하여 NAT 추가한다.
# 톰캣 설치
wget https://dlcdn.apache.org/tomcat/tomcat-8/v8.5.90/bin/apache-tomcat-8.5.90.zip
apt update && apt-get -y install openjdk-8-jdk
apt search openjdk // 정확한 패키지명을 모를때 사용한다.
apt remove // 삭제할때 사용한다.
apt -y install unzip
unzip apache-tomcat-8.5.90.zip
rm -rf apache-tomcat-8.5.90.zip
mv apache-tomcat-8.5.90/ tomcat
chmod -R 777 tomcat/
./tomcat/bin/startup.sh
curl localhost:8080 // verify
# 톰캣 동작 테스트
cd tomcat/webapps/ROOT
vi test.jsp
!
<%@ page contentType="text/html; charset=UTF-8"%>
<html>
<head><title>hello world</title></head>
<body>
<h2>
TOMCAT TEST<br><br>
time : <%= new java.util.Date()%>
<%@ page import="java.net.InetAddress" %><br>
<%InetAddress inet= InetAddress.getLocalHost();%>
WAS ip : <%=inet.getHostAddress()%>
</h2>
</body>
</html>
!
../../bin/shutdown.sh
../../bin/startup.sh
curl localhost:8080/test.jsp // 서버의ip를 보여주는 간단한 jsp 파일로 톰캣이 잘 작동하는 것을 확인.
https://mvnrepository.com/artifact/mysql/mysql-connector-java/8.0.23
# DB와 연동을 하기위한 JDBC 라이브러리
cd ..
cd ..
cd lib/
wget https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.23/mysql-connector-java-8.0.23.jar
cd ..
cd webapps/ROOT/
vi dbtest.jsp
!
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ page import="java.sql.*"%>
<h1>DB</h2>
<%
Connection conn=null;
try{
String Url="jdbc:mysql://<DB주소>/db"; # 엔드포인트/db이름
String Id="<DB유저>"; # 마스터 사용자
String Pass="<암호>"; # 마스터 암호
Class.forName("com.mysql.jdbc.Driver");
conn=DriverManager.getConnection(Url,Id,Pass);
out.println("was-db Connection Success!");
}catch(Exception e) {
e.printStackTrace();
}
%>
!
../../bin/shutdown.sh
../../bin/startup.sh
curl localhost:8080/dbtest.jsp // connection success!
# nginx가 설치된 web서버를 앞단에 붙이기 (`bastion` 인스턴스를 사용)
apt update && apt -y install nginx
cd /etc/nginx/sites-available/
cp default default.backup
nginx가 설치된 bastion 인스턴스의 외부 엔드포인트로 확인 해보면 db와 tomcat 모두 정상적으로 연동됨을 확인할 수 있다.
Auto Scaling
-
Scale과 Auto Scaling은 인프라의 CPU, RAM, 스토리지 등이 트래픽에 맞게 자동 확장 및 축소를 관리하기 위한 개념입니다.
-
Auto Scaling을 사용하면 애플리케이션의 수요 변화에 신속하게 대응하여 리소스를 효율적으로 사용하고, 가용성을 유지할 수 있습니다.
1. 사용자 정의 정책
- Auto Scaling 그룹에 대해 사용자가 지정한 정책을 기반으로 확장 및 축소 작업을 수행할 수 있습니다. 예를 들어, CPU 사용량이 특정 임계값을 초과하면 인스턴스를 자동으로 추가하거나, 사용량이 낮을 때 인스턴스를 자동으로 제거할 수 있습니다.
2. 자동 조정
- Auto Scaling은 사용자가 지정한 조건을 기반으로 인스턴스를 자동으로 조정합니다. 예를 들어, 트래픽이 급증하면 인스턴스를 동적으로 확장하여 애플리케이션의 가용성을 유지할 수 있습니다.
3. 탄력적인 그룹 관리
- Auto Scaling 그룹은 EC2 인스턴스의 상태를 모니터링하고, 인스턴스의 장애가 발생하는 경우 자동으로 대체합니다. 이를 통해 애플리케이션의 가용성을 높일 수 있습니다.
4. 통합 모니터링
- Auto Scaling은 CloudWatch와 통합되어 애플리케이션의 상태 및 성능 지표를 실시간으로 모니터링할 수 있습니다. 이를 통해 자원 사용량, 인스턴스 상태, 알람 등을 확인하고, 자동으로 대응하는 정책을 설정할 수 있습니다.
* Scale-up : 단일 리소스의 성능 향상을 위해 사용.
Scale-out: 작업 부하를 분산하여 시스템 전체의 성능을 향상 시키는 것을 목표로 함.
ALB
-
AWS에서 제공하는 로드 밸런서 서비스로 애플리케이션의 가용성과 확장성을 향상 시키기 위해 사용됩니다.
-
ALB(Application Load Balancer)는 OSI 7계층에서 작동하는 LoadBalancer입니다. 주로 HTTP 및 HTTPS 트래픽을 처리하며, layer 7에서 작동합니다.
1. 경로 기반 라우팅
- ALB는 요청의 경로에 따라 다른 대상 그룹으로 트래픽을 라우팅할 수 있습니다. 예를 들어, “/api” 경로의 요청은 API 서버로, “/app” 경로의 요청은 애플리케이션 서버로 전달할 수 있습니다.
2. HTTP/2 지원
- ALB는 HTTP/2 프로토콜을 지원하여 성능을 향상시킬 수 있습니다. HTTP/2는 다중화된 요청 및 응답, 헤더 압축 등의 기능을 제공합니다.
3. 내장된 보안 기능
- ALB는 SSL/TLS 종료, 클라이언트 인증, 웹 방화벽 규칙 등과 같은 보안 기능을 내장하고 있어 애플리케이션의 보안 요구사항을 충족시킬 수 있습니다.
4. 도커 컨테이너 지원
- ALB는 Amazon ECS (Elastic Container Service)와 통합되어 도커 컨테이너를 로드 밸런싱할 수 있습니다. 컨테이너 단위로 트래픽을 분배하고, 동적 포트 매핑 등을 지원합니다.
NLB
- NLB(Network Load Balancer)는 OSI 4계층에서 작동하는 로드 밸런서입니다. 주로 TCP, UDP 및 SSL/TLS 트래픽을 처리하며, 애플리케이션의 레이어 4에서 작동합니다.
1. 고성능 및 대규모 트래픽 처리
- NLB는 대규모 트래픽을 처리할 수 있으며, 초당 수백만 개의 연결을 지원할 수 있습니다. 이는 높은 성능과 확장성을 제공합니다.
2. 정적 IP 주소
- NLB는 고정 IP 주소를 제공하여 클라이언트에게 안정적인 서비스 제공이 가능합니다. 이는 DNS 라운드 로빈 방식의 로드 밸런싱보다 신뢰성을 높일 수 있습니다.
3. IP 대역폭 스핑
- NLB는 목적지 IP 주소에 따라 트래픽을 대상 그룹으로 분배할 수 있습니다. 이를 통해 특정 IP 주소 범위를 특정 대상 그룹으로 라우팅할 수 있습니다.
4. 포트 매핑
- NLB는 포트 매핑을 사용하여 서버 그룹 내의 인스턴스에 대한 트래픽을 분배할 수 있습니다. 이는 애플리케이션의 요구에 맞게 트래픽을 관리할 수 있는 유연성을 제공합니다.
5. 동적 IP 주소 할당
- NLB는 동적 IP 주소 할당을 지원하여 인스턴스의 상태 변화에 따라 IP 주소를 동적으로 할당할 수 있습니다.
로드밸런서 실습 1
apt -y update && apt -y install nginx
systemctl enable --now nginx
cd /var/www/html
echo web server 1 > index.html
curl localhost
web server1 // verify
재부팅 후에도 잘 동작하는지 확인 후 '중지' 시킨다.
web 인스턴스로 이미지 생성 후 해당 이미지로 web-1 , web-2 인스턴스를 생성한다.
web-2 인스턴스의 index.html은 web server 2로 수정하였다. (로드밸런서 식별하기 위함)
이 두개의 웹서버를 묶어줄 로드밸런서를 만들어주기 위해 EC2의 로드밸런서 탭으로 이동한다.
ALB를 선택
Listen port 라고하면 내부가 아닌 외부에서 접근하는 것에 대한 포트를 의미한다.
로드 밸런서를 만들면서 타겟그룹을 만드는것이 좋다.
그룹의 타입을 인스턴스로 설정.
Health checks는 애플리케이션 또는 서비스의 상태를 주기적으로 확인하여 가용성을 모니터링하는 기능이다.
인스턴스 ID 2개를 선택하여 Create target group을 누르면 해당 타겟 그룹이 생성된다.
다시 로드밸런서 생성 창으로 돌아와 새로 고침 후 만든 타겟 그룹을 선택하여 로드밸런서를 생성한다.
DNS name 주소로 접속하여 1, 2가 번갈아 가며 보이면 정상적으로 구성됨을 확인할 수 있다.
NLB 실습 과제
web1은 hello1 이라는 index.html 파일
web2은 hello2 이라는 index.html파일을 갖고있다.
이 두개의 서버를 타겟그룹으로 하는 하나의 NLB를 생성하여 로드밸런싱 되는것을 확인해보세요.
이번엔 AMI를 이용하지 않고 Web1 , web2 각각 생성 후 퍼블릭IP로 SSH접근한다.
apt -y update && apt -y install nginx
systemctl enable --now nginx
cd /var/www/html
echo hello1 > index.html
curl localhost
hello1 // verify
똑같이 web2도 설치 후 hello2로 설정
로드밸런서 - NLB로 생성한다.
타겟그룹을 각 인스턴스가 생성된 VPC 서브넷을 선택한다.
타겟그룹 생성 후 새로고침을 후 생성한 타겟그룹을 선택하여 생성한다.
curl 로드밸런서 DNS 네임:80 // verify
댓글남기기