[AWS] 03-1. Custom AMI & ELB(ALB, NLB)

Custom AMI(Amazon Machine Image)

• 내 입맛에 맞게 구성한 서버환경을 이미지화
  ➡️ 개발 환경을 구축해서 저장해두고 싶음

이미지화 장점

• 온디맨드(On-Demand, 수요 발생하면 즉시) 가능
  ➡️ 시간 단축
• 동일한 환경을 항상 재현 가능 = 휴먼에러 방지 가능
  ➡️각각 다른 노트북에서는 동일한 환경을 재현하기  어려움
  ➡️애플리케이션 호환성을 위해 동일한 환경을 구축 가능

👉 트래픽이 증가하면 똑같은 서버를 여러 개 띄우고, 트래픽이 감소하면 서버를 제거하는 게 가능해짐
= Scale이 유동적으로 변경 가능

 

Custom AMI 실습

웹 서버가 설치되어 있는 서버를 이미지화

• 커스텀 이미지 = 사실상 디스크라고 봐도 무방
  ➡️ 보안그룹이나 인스턴스 유형, 네트워크 설정 등은 포함되지 않음(운영체제 및 설치된 패키지 정도가 포함)

1. web 인스턴스 생성

 

2. nignix 설치

• Needs : 해당 이미지를 가지고, 인스턴스를 만들면 nginx가 잘 동작해야 함
  • 추후에 이 이미지를 가지고 여러 대의 인스턴스를 만들텐데,  enable을 안 해주면 생성되는 모든 서버들의 nginx는 동작을 안 할 것이다.
    ➡️ 항상 부팅이 될 때를 신경써서 설정해야 함
  • systemctl enable nginx ❌ ➡️ 이미지로 만든 인스턴스의 nginx를 모두 재시작해줘야 함🥲

# 관리자 권한 부여
ubuntu@ip-10-10-1-145:~$ sudo -i

# nginx 설치
root@ip-10-10-1-145:~# apt install -y nginx

# index.html 생성
root@ip-10-10-1-145:~# echo webserver > /var/www/html/index.html
root@ip-10-10-1-145:~# systemctl restart nginx

# ISO 파일 선택 과정 생략
# 디스크 이미지를 통해서 서버를 생성하고 재부팅했을 때도 제대로 작동해야 하기 때문에
# 재부팅되어도 패키지(nginx)가 실행되어야 함
root@ip-10-10-1-145:~# systemctl enable  nginx
Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx

 

3. nginx 동작 확인

• 내부 확인

root@ip-10-10-1-145:~# curl localhost
webserver

• 외부 확인

 

4. 커스텀 이미지 세팅 확인

• 커스터마이징할 상태를 잘 만들었다면, 인스턴스를 재부팅해도 잘 동작하는지 확인
• 인스턴스를 재부팅하거나 IP를 사용하지 않는다면, IP가 변경될 수 있음

• 잘 동작하는 것을 확인 가능
  • 재부팅 후에도 내가 의도한 동작을 잘 수행하고 있다면, 인스턴스를 '중지' 후 인스턴스를 재시작했을 때도 똑같이 동작해야 함

 

5. 이미지 만들기

• 인스턴스 중지

• 이미지 생성
  
  • 이미지를 만들면 항상 스냅샷도 같이 생성됨
    ➡️ 이미지를 지울 때, 스냅샷도 같이 삭제해야 함(자동으로 삭제되는 것이 아님)

• AMI 생성 확인
  • AMI 생성하는데 조금의 시간이 소요

 

6. 해당 이미지를 가지고 인스턴스 생성

• web1과 web2 두개의 인스턴스 생성
  ➡️ 보안그룹, 네트워크, 인스턴스 유형은 동일하게 구성

6-1. web1 인스턴스 생성

• rapa-vpc-pub-sub1에 위치

• web1  작동 확인 & web 인스턴스 삭제

 

6-2. web2 인스턴스 생성

• rapa-vpc-pub-sub2에 위치

 

7. 각 인스턴스 수정 - web1 & web2

• web1 접속 ➡️ webserver1 문구 확인

ubuntu@ip-10-10-1-230:~$ sudo -i
root@ip-10-10-1-230:~# cd /var/www/html
root@ip-10-10-1-230:/var/www/html# ls
index.html  index.nginx-debian.html
root@ip-10-10-1-230:/var/www/html# vi index.html
root@ip-10-10-1-230:/var/www/html# curl localhost
webserver1

• web2 접속 ➡️ webserver2 문구 확인

ubuntu@ip-10-10-11-58:~$ sudo -i
root@ip-10-10-11-58:~# cd /var/www/html
root@ip-10-10-11-58:/var/www/html# ls
index.html  index.nginx-debian.html
root@ip-10-10-11-58:/var/www/html# vi index.html
root@ip-10-10-11-58:/var/www/html# curl localhost
webserver2

 

---

ELB(Elastic Load Balancer)

• load = 부하, balancing = 분산 ➡️ 부하분산
• 두 개 이상의 가용영역이 있어야 생성 가능

 

Load Balancer 역할

1. 하나의 엔드포인트(접속 지점)를 만들 수 있음
2. 부하를 분산
   ➡️ 인스턴스에 번갈아가면서 접속시켜줌(= 라운드로빈, 헬스체크를 통해 부하 분산 가능)
   ➡️ Load Balancer의 역량에 따라 분산 정도가 다름

 

Load Balancer 종류

1. NLB
   • 4계층 까지 고려함
2. ALB(Application Load Balancer)
   • 7 계층까지 고려하는 Load Balancer
   • 서비스를 기준으로 Load Balancing 할 수 있음
   • 예) HTTP 서비스를 웹 서버에 보내줄 수 있음

 

ALB 실습

1. 로드밸런서 생성

• 로드 밸런서 유형 선택

•  Load Balancer 체계 선택
  • 인터넷 경계 : 외부에서 접근 가능 = Public IP
    ➡️ public subnet에 위치
  • 내부 : 외부에서 접근 불가능 = Private IP
    ➡️ private subnet에 위치
  • 어떤 대상 그룹을 Load Balancing할 것인지에 따라서 선택
    ➡️ 3tier에서 web을 Load Balancing 한다면, 인터넷 경계 선택
    ➡️ 3tier에서 was를 Load Balancing 한다면, 내부 선택

• Load Balancer 체계에 따라 public/private subnet이 지정되는 것이 아니기 때문에
  👉 Load Balancer 체계에 따라서 Subnet 위치를 설정해야 함

• 네트워크 매핑 = ALB(Application Load Balancer) 위치

• ALB의 보안 그룹
  • 대상그룹의 보안 그룹과 동일하게 맞춰주는 것을 권고
    ➡️ 하지만 달라도 상관은 없음
  • DNAT와 비슷한 느낌

•  리스너 및 라우팅
  • 리스너 Port = Destination Port
  • 대상그룹 = web1 & web2 인스턴스 그룹 
  • 대상그룹 생성

---

대상 그룹 생성

• TG의 Port와 인스턴스의 Port는 맞춰줘야 함
  ➡️ TG의 Port가 존재하지만 의미가 크지는 않음
  ➡️ 인스턴스에서 보안그룹이 설정되기 때문에, TG의 보안그룹은 설정하지 않아도 됨

• 상태 검사(=health check)
  • 대상 그룹에 존재하는 인스턴스의 상태를 확인
    ➡️ 트래픽을 보내도 괜찮은지 확인 & 트래픽 전달

• 고급 상태 검사 설정
  • 정상 임계값 : 5번 이상 성공해야 healthy 
  • 비정상 임계값 : 2번 반복 시, unhealthy 
  • 제한 시간 : 5초 동안 응답이 없으면
  • 간격 : 30초에 한번 물어봄
  • 성공코드 : 성공했을 때의 코드
    ➡️ 인스턴스가 정상적으로 동작하지 않을 때, 인스턴스의 상태를 무시하고 트래픽을 보내고 싶을 때, 성공코드를 변경하면 됨
  • 인스턴스 부팅에 걸리는 시간도 고려해야 할 때가 있지만, 지금은 고려하지 않음

• 대상 등록 선택
  • 선택한 인스턴스를 위한 포트 = translation Port

아래 보류 중인 것으로 포함 선택 전/후

---

• 대상 그룹 설정

 

2. 로드밸런서 생성

• DNS 이름 = 엔드포인트
• 가용영역에 걸쳐있기 때문에, 정확한 위치(=IP)를 알 수 없음
• 서버가 정상 & health check 정상이어야 로드밸런싱이 잘됨

 

3. 접속 확인

• DNS 이름으로 접속
• 같은 URL로 입력했을 때, ALB 맘대로 인스턴스를 번갈아가면서 띄워줌

• 때로는 브라우저의 쿠키 혹은 7계층까지 인식을 못하는 로드밸런서의 경우엔 로드밸런싱이 안되는 것처럼 보이는 경우도 존재(= web1만 10번 이상 뜸)
  ➡️ 그럴때는 curl을 찍어보면 됨

 

ALB와 타겟그룹 삭제

1. 로드밸런서 삭제

2. 대상그룹 삭제

 

NLB 실습

문제

web1, web2를 타겟그룹으로 하는 NLB를 만들어서 외부접속 테스트를 해보세요.

 

풀이

1. 로드밸런서 생성

• 로드 밸런서 유형 선택 - NLB

•  기본 구성 설정

• 네트워크 매핑

• 보안 그룹 설정

• 리스너 및 라우팅
  • ALB와 다른 점은 서비스를 선택할 수 없음

---

대상그룹 생성

• 대상 등록

 

---

 

2. NLB 생성 확인

 

3. web 접속 확인

 

💡NLB와 ALB로 웹 접속을 했을 때, NLB는 서버가 변경이 되지 않는데, ALB는 서버가 변경되는 이유

• NLB
  • 계층을 인지하지 못하고 Stateful로 세션을 기억하기 때문에, 브라우저에서 새로 고침을 했을 때 새로운 요청인지 인지를 못함
• ALB
  • 7계층까지 인지하기 때문에 프로토콜에 따라 새로운 요청인지 확인이 가능