커스텀 AMI(Amazon Machine Image)/ Auto-Scaling/ELB(Elastic Load Balancer)/ systemd

📌 커스텀 AMI(Amazon Machine Image)란?

커스텀 AMI(Custom AMI)는 사용자가 필요한 소프트웨어, 설정, 환경을 미리 구성한 상태의 EC2 이미지임
즉, EC2 인스턴스의 스냅샷을 떠서, 나만의 맞춤형 OS + 애플리케이션이 포함된 인스턴스 이미지를 만드는 것이 가능

- 내 입맛에 맞게 구성한 서버환경을 이미지화.

 

💡 커스텀 AMI를 만드는 이유?

1. 시간 절약 → 매번 새 EC2를 만들 때마다 설정할 필요 없이, 한 번 만든 이미지를 복사해서 빠르게 배포 가능!
2. 일관된 환경 유지 → 여러 개의 인스턴스를 동일한 설정으로 유지 가능!
3. 자동화 → 동일한 환경이 필요할 때마다 쉽게 배포 가능!
4. 보안 유지 → 필요한 보안 패치 및 설정을 적용한 상태로 저장 가능!

실습

web 

인스턴스 생성

- 커스텀이미지 = 사실상 디스크라고 봐도 무방함.

(보안그룹이나 인스턴스유형, 서브넷 같은 정보는 포함되어있지 않고, 운영체제 및 설치된 패키지 정도라고 보면 좋음.)

xshell

root@ip-10-10-1-72:~# sudo -i

root@ip-10-10-1-72:~# apt update

root@ip-10-10-1-72:~# apt install -y nginx

root@ip-10-10-1-72:~# echo webserver > /var/www/html/index.html

root@ip-10-10-1-72:~# systemctl restart nginx

 

- 내가 원하는 이미지를 만들고, 나중에 이 이미지를 갖고 여러 대의 인스턴스를 만들 텐데, 만약 enable을 안 해주면 생성되는 모든 서버들의 nginx는 동작을 안 할 것 임. 따라서 항상 ‘부팅이 될 때’를 신경 써줘야 함.

 

- 인스턴스의 외부주소로 잘 되는지 확인.

 

- 내가 커스터마이징 할 상태를 잘 만들었다면, 인스턴스 재부팅해도 잘 동작하는지 확인. 가장 확실한 방법.

- 재부팅 후에도 내가 의도한 동작을 잘 수행하고 있다면, 인스턴스를 ‘중지’ 후 이미지를 만든다.

 

- 이미지 이름

- 이미지를 만들면 항상 스냅샷도 같이 생성된다. (이미지를 지우실 때 스냅샷도 같이 지워줘야)

- 위 이미지를 베이스로 하여 web1과 web2 두 개의 인스턴스를 생성. 보안그룹이나 인스턴스 유형

 

위 이미지를 베이스로 하여 web1과 web2 두 개의 인스턴스를 생성. 보안그룹, 네트워크, 인스턴스유형은 동일하게 하고, web1는 pub-sub1에 , web2는 pub-sub2에 둔다.

 

- web1로 접속 시 웹서버가 잘 동작하는지 확인 후 중지된 web이라는 서버는 삭제.

 

web1로 접속 시 - webserver1이라는 문구가 뜨도록 하시고

web2로 접속 시 - webserver2이라는 문구가 뜨도록 하세요.

 

web1 ip로 접근해서 

root@ip-10-10-1-72:~# echo webserver1 > /var/www/html/index.html

이라고 입력해 주면 됨

- web-1 만드는 세팅 (web-2는 생략함)

web-1

web-2

- web-1이랑 web-2 둘 다 잘 된 걸 확인할 수 있음

(원래는 web1은 webserver1, web2는 webserver2라고 해야 되는데 까먹었어요...^^)

📌 ELB(Elastic Load Balancer)

ELB는 AWS에서 제공하는 로드 밸런서 서비스
즉, 여러 개의 EC2 인스턴스(서버)로 트래픽을 자동으로 분산해 주는 역할을 함
트래픽을 고르게 나눠서 특정 서버에 부하가 몰리는 걸 방지하고, 서버가 장애가 나면 다른 서버로 자동으로 트래픽을 넘겨줘.

---

💡 ELB를 사용하는 이유?

1. 부하 분산(Load Balancing) → 요청을 여러 서버로 분산해 서버 과부하를 방지
2. 고가용성(High Availability) → 한 서버가 다운돼도 다른 서버로 트래픽을 전달
3. 자동 확장(Scalability) → Auto Scaling과 함께 사용하면 트래픽이 많아질 때 서버를 자동으로 늘릴 수 있음
4. 보안(Security) → SSL/TLS 암호화 및 AWS WAF(Web Application Firewall) 연동 가능

---

📌 ELB의 종류

AWS에서는 3가지 유형의 로드 밸런서를 제공해.

로드 밸런서 종류	설명
ALB (Application Load Balancer)	HTTP/HTTPS 트래픽을 처리, URL 기반 라우팅 가능/ 7계층까지 봄.
NLB (Network Load Balancer)	TCP/UDP 트래픽을 처리, 빠른 응답과 낮은 지연 시간
CLB (Classic Load Balancer)	예전 방식의 로드 밸런서, 현재는 ALB/NLB 권장

Load Balancer

- load Balancer 생성

- internet facing

 

- ALB를 어느 서브넷에 둘지

 

- internet-facing(인터넷 경계) = 퍼블릭 서브넷

- interna(내부) = 프라이빗 서브넷

- 리스너 포트 = DNAT의 Destination port와 유사

- 리스너 및 라우팅 개념

로드 밸런서(ELB, ALB, NLB)에서 트래픽을 수신하고 처리하는 방식을 이해하는 데 중요한 개념

 

1️⃣ 리스너(Listener) → 클라이언트 요청을 감지하는 역할
2️⃣ 라우팅(Routing) → 받은 요청을 적절한 서버로 전달하는 과정
3️⃣ ALB/NLB/ELB 등에서 사용되며, 트래픽 관리 및 부하 분산에 필수적인 요소

- 대상 그룹 생성으로 넘어가서

- web1, web2라는 인스턴스가 대상그룹이 될 것이기 때문에 선택

- 보통은 http, ipv4

- health 한지 안 한 지 체크해 주는 상태 검사

- 상태 검사 경로 -> 주소

- 대상 그룹에 포함시킬 수 있는 그룹임. 

- 선택한 인스턴스를 위한 포트 = translation port

- 때로는 브라우저의 쿠키 혹은 7 계층까지 인식을 못하는 로드밸런서의 경우엔 로드밸런싱이 안 되는 것처럼 보이는 경우도 있음. (=webserver1만 10번 이상 뜬다) 그럴 땐. curl을 찍어보는 게 제일 정확함.

 

- 우리가 웹서버를 구축한 후 접속해서 확인하듯, 헬스체크도 동일한 메커니즘으로 봐도 무방함. 특정 경로에 index파일 같이 기본적으로 불러오는 파일이 있다면 경로를 지정하고, was디렉터리의 test.jsp파일을 통해 헬스체크를 하고 싶다면 /was/test.jsp처럼 디렉터리 및 파일명을 넣어도 좋음.

Load Balancer 삭제 순서

실습
이 ALB와 타겟그룹은 삭제를 하세요. 비슷한 방식으로 NLB를 만들어보세요.
비슷한 방식으로 web1, web2를 타겟그룹으로 하는 NLB를 만들어서 외부접속을 테스트해 보세요.

- NLB는 4 계층까지만 포함된 상태임

- 그래서 TCP임

- NLB를 만들면 4 계층까지 인식하기 때문에 http 같은 특정 프로토콜을 선택(인지)할 수 없음.

- 따라서 나중에 대상그룹을 만들 때 http와 같은 특정 프로토콜로 지정하면 NLB는 이 프로토콜을 인식할 수 없어 NLB가 선택할 수 있는 대상 그룹 목록에 뜨지 않음.

***근데 궁금한 게 인스턴스를 선정해서 대상에 추가해 주는 이유는?

로드 밸런서를 사용하면 대상의 인스턴스 수를 지정해 주는데, auto-scaling을 사용할 때는 반대로 인스턴스의 수가 증가했다가 감소하기 때문에 auto-scaling을 만들 때 나중에 대상 추가해 줌.

-> 브라우저보다 curl이 확인하기 좀 더 수월

systemd에 tomcat 등록

- 톰캣 systemctl로 컨트롤하는 법

 - 바로 복붙 해서 사용할 수 있

tee /etc/systemd/system/tomcat.service <<EOF
[Unit]
Description=tomcat10
After=network.target syslog.target

[Service] 
Type=forking
Environment="/root/tomcat"
User=root
Group=root
ExecStart=/root/tomcat/bin/startup.sh
ExecStop=/root/tomcat/bin/shutdown.sh

[Install]
WantedBy=multi-user.target
EOF

tee 명령 = cat 이랑 동일. 차이는 입력된 내용을 화면에 보여주는 것 말고는 다른 게 없음.

 

root@ip-10-10-1-58:~# systemctl daemon-reload

root@ip-10-10-1-58:~# systemctl restart tomcat

 

- 새로 생성한 tomcat이라는 데몬서비스를 등록 후 재시작함.

 

- systemctl 명령으로 tomcat을 재시작시켜 동작하는 걸 확인.

실습)
ALB를 만들어보세요.
해당 ALB의 DNS이름:80으로 접속했을 때 하나의 AMI를 베이스로 만들어진 두 인스턴스 각각의 HOST IP가 출력되도록 해보세요. tomcat으로 하시면 됩니다.
타겟그룹의 HOST들은 AMI로 생성된 인스턴스여야 합니다. ALB는 한 개를 만드시고, HOST의 IP는 최소 두 개가 출력되게 해 보세요. (서버 두 개 이상 만들라는 뜻) tomcat을 wget으로 받으셔서 하세요! 보일 페이지를 수정하진 마세요!

정리)
1. web-ami를 만들고 tomcat 설치하고 curl로 웹페이지 받아오는지 확인
2. 커스텀 AMI(Amazon Machine Image)해줘서 web-ami1, web-ami2에 잘 받아오는 걸 확인
3. ALB를 해주고 curl이 잘 되는 걸 확인 ( 이때 경로 설정을 다르게 해 줘야 됨)

1

web-ami를 만들어주고(위에 과정이 많으니까 생략)

xshell에 tomcat 설치& 설정해 주고 curl로 웹페이지 받아오는지 확인

 

tomcat

root@ip-10-10-1-65:~# apt update -y

root@ip-10-10-1-65:~# apt install -y unzip wget openjdk-11-jdk

root@ip-10-10-1-65:~# wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.36/bin/apache-tomcat-10.1.36.zip

root@ip-10-10-1-65:~# unzip apache-tomcat-10.1.36.zip

root@ip-10-10-1-65:~# mv apache-tomcat-10.1.36 tomcat

root@ip-10-10-1-65:~# chmod 777 -R tomcat

 

- 톰캣 systemctl로 컨트롤하는 법

- 바로 복붙 하면 됨

tee /etc/systemd/system/tomcat.service <<EOF
[Unit]
Description=tomcat10
After=network.target syslog.target

[Service] 
Type=forking
Environment="/root/tomcat"
User=root
Group=root
ExecStart=/root/tomcat/bin/startup.sh
ExecStop=/root/tomcat/bin/shutdown.sh

[Install]
WantedBy=multi-user.target
EOF

 

root@ip-10-10-1-58:~# systemctl daemon-reload

root@ip-10-10-1-58:~# systemctl restart tomcat

 

# 새로 생성한 tomcat이라는 데몬서비스를 등록

# systemctl 명령으로 tomcat을 재시작시켜 동작하는 걸 확인.

 

root@ip-10-10-1-58:~# vi /root/tomcat/webapps/ROOT/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>

 

8080 보안그룹에 추가해 줘야 됨

 

root@ip-10-10-1-252:~/tomcat# curl localhost:8080/test.jspcd

root@ip-10-10-1-110:~/tomcat# systemctl enable tomcat
Created symlink /etc/systemd/system/multi-/user.target.wants/tomcat.service → /etc/systemd/system/tomcat.service.

 

2

커스텀 AMI(Amazon Machine Image)해줘서 web-ami1, web-ami2에 잘 받아오는 걸 확인

(전 사진 그냥 복붙 한 거라서 인스턴스 이름이 다름)

파일을 위에서 만들어줬는데 안됨(내가 못 찾은 걸 수도)

그래서 추가로 ami로 받아온 tomcat서버에 다시 만들어줬음

 

root@ip-10-10-1-252:~/tomcat/webapps/ROOT# vi test.jsp
root@ip-10-10-1-252:~/tomcat/webapps/ROOT# systemctl restart tomcat

root@ip-10-10-1-252:~/tomcat/webapps/ROOT#  systemctl enable tomcat

- enable 중요! 

web-1

web-2

3

ALB를 해주고 curl이 잘 되는 걸 확인 ( 이때 경로 설정을 다르게 해 줘야 됨)

(복붙)

http://web-fishcase-alb-113395875.ap-northeast-2.elb.amazonaws.com/test.jsp

- 입력하면 끝남  

web-1

web-2

- healthy인지 확인

오류/ 해결

인스턴스 생성이 안됨 왜 그럴까?

ami가 생성되고 있는 중이라서 인스턴스가 생성이 안 되는 것임

- 사용 가능 상태가 되면 인스턴스가 생성됨

실습 3)
ALB를 만들어보세요.
최소 각각 1쌍 이상(web두 개, was두 개)의 web, was를 생성하며 DB는 제외한 2 tier구조를 만들어보세요. ELB를 사용해야 한다면 ALB를 사용하세요. 사용자는 web의 /tomcat 경로로 접속했을 때 was로 리버스 프록시 되어야 합니다.  tomcat은 systemd를 통해 데몬으로 만드세요.

풀이)
was서버 구성 - tomcat 설치, systemd에 등록, enable, index.jsp파일 구성

 

 

 

- red hat, xshell 연결

[ec2-user@ip-10-10-1-58 ~]$ sudo -i
[root@ip-10-10-1-58 ~] # yum install -y httpd

[root@ip-10-10-1-58 ~]# systemctl restart httpd
[root@ip-10-10-1-58 ~]# systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[root@ip-10-10-1-58 ~]# echo 'success' > /var/www/html/index.html
[root@ip-10-10-1-58 ~]# curl 3.38.169.27
success

 

 web-http-1

web-http-2

- xshell에 curl이 잘 받아오는지 확인해 주기

- web-http-1 

- web-http-2

 - ALB

- 대상 그룹 생성

 - ALB 이어서 해주기

다 삭제 마무리

(리버스 프록시 못함...)