AWS : Load Balancing

Scalability

- 애플리케이션이나 시스템이 알아서 더 크거나 작은 로드(load)를 다루는 것이다.

- HA와 연관되어 있으나, 다른 개념이다.

 

Vertical Scalability (Scale Up / Down)	Horizontal Scalability (Scale Out / In)
- 인스턴스의 크기를 키우는 것 - DB와 같은 비분산 시스템, RDS, ElastiCache 등에서 활용된다. - 주로 하드웨어적으로 한계가 있다. - ex. t2.micro => t2.large	- 인스턴스나 시스템의 개수를 늘리는 것 - 분산 시스템에 적용된다. - ex. Auto Scalling group, Load Balancer

 

High Availability(고가용성)

 

- horizontal scaling과 함께 사용되는 개념

- 최소 두개의 데이터 센터(AZ)에 애플리케이션/시스템을 실행시키는 것이다.

- 데이터 센터의 손실로부터 살아남는 것이 목적이다.

- ex. Auto Scaling Group multi AZ, Load Balancer multi AZ

 

- 수동적 고가용성(passive) -> ex. RDS Multi AZ

- 능동적 고가용성(active) -> ex. horizontal scaling

 

 

 

 

Load Balancing

- 트래픽을 여러 서버(백엔드, 다운스트림, EC2 인스턴스 또는 서버들)에 전달하는 서버

- 로드(부하)를 여러 다운스트림 인스턴스로 분산하기 위해

- 애플리케이션에 하나의 접근점(DNS)를 노출시키기 위해

- 다운스트림 인스턴스에 failure를 매끄럽게 처리하기 위해

- 인스턴스에 정기적인 health check(상태 검사)를 하기 위해

- SSL termination(HTTPS - 웹사이트에 암호화된 HTTPS 트래픽을 가질 수 있음)을 제공하기 위해

- 쿠키의 고정도(stickiness) 강화

- HA across zones

- public 트래픽과 private 트래픽을 분리하기 위해

 

 

 

NLB 세팅하기

Application Load Balancer(ALB) : L7 Switch와 유사(포트번호 이용해서 부하 분산, 컨텐츠를 읽을 수 있어서 컨텐츠로 또한 가능), Application Load Switch를 가상으로 구현한 것

Network Load Balancer(NLB) : L4 Switch와 유사(포트번호 이용해서 부하 분산)

 

Network Load Balancer의 [생성] 버튼을 누른다.

 

 

 

인터넷 경계 : 유저가 인터넷을 타고 들어오는 경우

내부 : 망 안에 LB를 위치시킴, 내부에서만 LB가 필요할 때

 

 

172.31.0.0/16 : VPC의 IP

 

프로토콜, 포트 => 프론트 앤드

다음으로 전달 : 대상 그룹(Target Group) => 백앤드

 

[대상 그룹 생성]을 누른다.

 

 

상태 검사(health check) : LB가 접속해봤을 때 접속 신호(request)에 따른 respond를 잘 보내는지 확인함

 

비정상

3번을 연달아 10초 이내로 응답이 오지 않으면 실패한 것 -> circuit breaker(회로 차단)

그쪽으로 신호를 전달하지 않게 된다.

 

정상

3번을 연달아 정상 신호를 보낸다면 정상화 되었다고 판단한다. -> 재개(포워드 해준다.)

 

인스턴스 두개를 선택하고 아래에 [아래에 보류 중인 것으로 포함]을 클릭한다.

 

인스턴스 두개가 추가되면 [대상 그룹 생성]버튼을 누른다.

 

원래 NLB에 들어와서 새로고침 버튼을 누르고, 방금 추가했던 Target Group을 선택한다.

 

그리고 [로드 밸런서 생성]을 클릭한다.

 

 

[로드 밸런서 보기]를 클릭해보면 방금 만든 NLB를 볼 수 있다.

 

오른쪽에 로드 밸런싱 - [대상 그룹]에 들어간다

healthy check가 통과되면 [상태확인]의 initial이 healthy로 변한다.

만약 오류가 난다면 unhealthy로 바뀐다.

 

로드밸런서 탭으로 들어간다

하단의 [DNS 이름]에 나타난 링크를 들어가보면

 

아까 구축했던 인스턴스가 나타난다.

NLB는 Least Connection(최소 연결) 방식이므로 새로고침을 해도 바로 WEB02가 나타나지는 않는다. (ALB는 Round Robin 방식을 이용한다)

 

ALB 생성하기

 

NLB와 달리, 보안 그룹을 설정할 수 있다.

[새 보안 그룹 생성]을 클릭한다.

 

인바운드 규칙에 [규칙 추가]를 클릭하여 생성한다.

 

아무리 80포트를 listen하고 있어도 보안 그룹이 막고 있어서 신호를 받을 수 없다.

그래서 HTTP 규칙을 생성하여 보안그룹에서 80포트를 오픈하도록 한다.

[보안 그룹 생성]을 클릭하여 완성한 뒤, ALB 생성하던 것을 마무리한다.

 

default를 제거하고, 직전에 만든 SG-ALB를 추가한다.

 

하단의 [대상 그룹 생성]을 클릭한다.

/var/www/html/index.html

을 / 로 생략하는 과정

 

인스턴스 두개를 체크한 뒤 [아래에 보류 중인 것으로 포함]을 클릭한다.

 

[대상 그룹 생성]을 클릭한다.

 

다시 ALB 만드는 탭으로 돌아와서 

새로고침을 누른뒤 직전에 만들었던 TG-ALB를 선택한다.

 

그리고 [로드 밸런서 생성] 버튼을 누른다.

 

ALB는 유형이 application이다.

상단의 search필터를 삭제하면 ELB-NLB, ELB-ALB를 볼 수 있다.

 

로드 밸런서를 거치지 않고 바로 public IP로 접속(우회)하므로 문제가 된다. -> 트래픽을 관리할 수 없게 된다.

=> Public IP로 들어올 수 없도록 해야 한다. 

보안그룹의 의미 뭘까뭘까 우우

 

보안그룹 탭에 가서 SG-WEB 누른 뒤 [인바운드 규칙 편집]을 클릭한다.

 

 

- HTTP 규칙 두개를 다 삭제한 뒤, 새로 [규칙 추가]를 눌러 새로운 HTTP를 만든다.

- 새로운 HTTP의 소스의 보안그룹을 SG-ALB로 설정한다. ->SG-ALB가 출발지가 되어, ALB를 통해 들어오는 트래픽들만 받아들일 수 있도록 한다.

* HTTP를 [내 IP]로 수정하게 되면 IP를 필터링하게 된다. 현재 내 컴퓨터와 같은 와이파이를 쓰는 기기가 아니면 접속할 수 없게 된다.

[규칙 저장]을 클릭한다.

 

 

이후 public ip로 접속해보려고 하면 접속이 되지 않는다.

 

 

moba Xterm으로 접속한다

username을 ubuntu로 해야 접속된다.

 

실습파일인 aws.tar와 azure.tar파일을  ssh brower에 드래그 앤 드롭한다.

 

sudo mkdir /var/www/html/food
sudo tar -xvf aws.tar -C /var/www/html/food/

html 폴더 아래 food라는 폴더를 만든다 -> 이는 곧 링크의 경로명이다.

tar파일을 압축 해제하여 방금 만든 디렉터리 안에 넣는다.

 

ubuntu에 접속하여 같은 방식으로 azure.tar파일을 압축 해제한다.

 

 

 

 

다시 [대상그룹] 탭으로 들어가서 [대상 그룹 생성]을 클릭한다.

 

이름 TG-FOOD로 지정한 뒤 나머지는 다 디폴트값으로 지정한 뒤 [다음]을 클릭한다.

 

WEB01이 food를 가지고 있으므로 WEB01만 선택하고, [아래에 보류 중인 것으로 포함]을 누른다. 그리고 [대상 그룹 생성]을 클릭한다.

 

같은 방식으로 TG-SALE도 만들어준다.

WEB02에 sale을 만들었으므로 WEB02만 추가한다.

 

대상 그룹이 생성된 모습

 

[로드 밸런서]탭으로 들어간다. 

ELB-ALB를 선택한 뒤, 리스너를 클릭한다.

하단의 [규칙 보기/편집]을 클릭한다.

 

[규칙 삽입]탭에 들어간 뒤, 중간의 [규칙 삽입]을 클릭한다.

위 이미지대로 설정한 뒤 저장한다.

 

규칙은 순서대로 우선순위를 둔다.

 

두 사이트를 들어가보면 /food /sale 뭐가 나와야 함

 

 

ec2-user의

sudo vi /var/www/html/index.html

로

로 해서 firefox에서만 접속할 수 있도록 한다.

 

 

같은 방식으로 ubuntu에서

sudo vi /var/www/html/index.html

 

 

로 해서 IE에서만 접속할 수 있도록 한다.

 

왼쪽의 [대상그룹] 탭 클릭하여 TG-FIREFOX 라는 대상그룹을 새로 생성한다. (나머지는 다 기본값)

WEB01만 포함하도록 한다.

 

같은 방식으로 TG-MOBILE을 만든다.

WEB02만 포함하도록 한다.

 

로드 밸런서 탭으로 들어가서 ELB-ALB를 클릭한 뒤 다시 [규칙 보기/편집]으로 들어간다.

 

위 이미지대로 설정한다.

 

좌: firefox로 들어갔을 때, 우: mobile로 들어갔을 때

 

인스턴스 > 인스턴스 시작

스토리지에서 [새 볼륨 추가]를 클릭해 똑같은 스토리지를 하나 더 추가한다.

 

 

명령어에 sudo 쓰지 않는다 -> 사용자 데이터가 구동 될 때는 root로 접속하기 때문에

 

생성된 인스턴스의 스토리지를 확인해 보면 추가된 것을 볼 수 있다.

 

확인된 public IP로 moba Xterm에 접속한다.

 

df -h를 해보면 추가된 스토리지가 마운트 되지 않은 모습을 볼 수 있다.

 

디스크가 포멧이 된다.

ext4 -> 다른 기기와의 호환성 위해

장치를 폴더와 연결한다.

 

mnt 디렉터리에 test.txt를 만들어서 아무말이나 쓴다

 

EC2와 EBS는 2a로 연결되어 있다.

추가로 붙인 EBS는 2c로 연결되어 있어서, EC2와는 직접적으로 연결되어 있지 않다.

 

 

볼륨 > 볼륨 생성 으로 들어간다

io2가 가장 빠르다

콜드 -> 느리다는 의미(hot과 반대). 빠른 데이터 처리를 원하지 않으면 (ex.백업용) 비용을 효율적으로 사용하기 위해 콜드 HDD를 선택한다.

[볼륨 생성] 버튼을 누른다.

방금 만든 WEB01-ADD가 available 상태로 생성된 것을 확인할 수 있다.

 

오른쪽 마우스를 클릭해서 [볼륨 연결]을 클릭한다.

 

가용영역이 2a이므로 2a에 있는 볼륨만 나타난다.

데이터 볼륨은 f부터 p사이로 가능하다.

연결이 된 모습

추가된 모습을 확인할 수 있다.

포멧 후 마운트한다.

df -h를 해보면 xvdf가 마운트 되어있는 것을 볼 수 있다.

 

aws.tar파일을 SSH browser에 추가한다.

 

하지만 public ip로 접속이 안된다.

어제 설정한 SG-WEB의 인바운드 규칙 때문에 직접적으로 ip를 들어오는 것을 차단했기 때문이다.

 

보안 그룹으로 들어간다.

우측 하단의 [인바운드 규칙 편집]을 클릭한다.

기존의 HTTP를 지우고, 다시 HTTP를 추가한다. 그리고 소스를 Anywhere-IPv4로 한다.

(기존의 HTTP의 소스를 수정하려고 하면 되지 않는다.)

잘 접속된다

앞전에 다운받았던 tar파일을 압축 해제 한다.

그리고 다시 IP로 접속해보면

 

용량 확보를 위해(는 사실 tar파일의 용량은 크지 않다) aws.tar파일을 마운트된 폴더로 옮긴다.

 

볼륨 추가는 따로 하지 않는다.

고급 세부 정보 - 사용자 데이터 에서 배치파일을 만든다.

 

퍼블릭 IP로 Moba로 WEB02에 접속한다.

 

 

볼륨 /dev/xvda1의 용량을 8G -> 10G로 늘리기

이름을 ROOT로 바꾸자

볼륨 탭에서 스냅샷이 찍힌 것을 선택하고 [볼륨 수정]을 누른다.

8 -> 10으로 고친다. 크기를 늘릴 수는 있지만, 줄일 수는 없다.

 

디스크의 크기는 늘어나있으나, 마운트된 실제 사용하는 디스크인 파티션(xvda1)의 용량은 늘어나지 않았다.

파티션을 확장하도록 한다.

 

 

파티션 확장

Openstack과 달리, 서비스를 멈추지 않고 용량을 확장할 수 있다.

sudo growpart /dev/xvda 1 //파티션 1번의 용량을 늘린다
lsblk

 

XFS 파일 시스템 확장

df -Th
sudo xfs_growfs -d /
df -Th

최상위폴더의 공간을 2G 늘린다.

용량이 10G로 늘어났다.

 

 

 

 

스냅샷을 통해 EBS의 기능적인 한계를 개선할 수 있다.

마운트 해제

* umount를 할 때는 umount할 디렉터리 내에서 명령어를 입력하면 안 된다.

detach 하기

WEB01-ADD를 선택한 뒤, [볼륨 분리]를 누른다.

 

새로고침 버튼을 눌러보면, [사용가능]으로 바뀐 것을 볼 수 있다.

 

다시 [볼륨 연결]을 눌러 보면,

가용영역이 2a이기 때문에, 2a에 있는 인스턴스만 연결할 수 있다. 그래서 Ubuntu는 선택할 수 없다.

이 때, 스냅샷을 이용한다.

 

스냅샷으로 볼륨 생성하기

Elastic Block Store의 [스냅샷]탭을 누른다.

[스냅샷 생성] 버튼을 누른다.

볼륨 ID를 WEB01-ADD로 선택한다.

 

스냅샷이 생성된 것을 볼 수 있다.

 

방금 만든 스냅샷을 선택한 뒤, [스냅샷에서 볼륨 생성]을 누른다.

이전의 방식과 달리, 이미 가지고 있는 데이터를 이용해서 볼륨으로 만들 수 있는 작업이다.

가용 영역을 2c로 선택하면, ubuntu로 선택할 수 있다.

 

볼륨 탭에서 방금 만든 2C volume을 선택한 뒤, [볼륨 연결]을 누른다.

우분투에서 확인해보면 마운트 되지 않은 xvdf를 확인할 수 있다.

포멧하면 .tar 파일의 정보가 사라지므로 mkfs 명령어로 포멧을 하면 안된다.

 

aws.tar파일을 압축 해제한 후, 홈페이지에 들어가 본다.

 

ip a 명령어로는 사설 IP밖에 알 수 없다.

public IP를 확인하려면

 curl http://169.254.169.254/latest/meta-data/public-ipv4

를 이용해야 한다.

 

그냥 meta-data까지만 입력했을 때는, 필요한 정보의 리스트를 확인할 수 있다.

예를 들어, security-groups을 입력했다면 어떤 보안 그룹이 있는지 알 수 있다.

 

 

기존의 web01이 손상되었을 때, 스냅샷으로 데이터를  보관하고 있다가, 이미지로 만든 후 -> 인스턴스로 만들어 web01을 복원할 수 있다.

 

 

 

 

 

다시 [스냅샷]탭에 들어가서 ROOT의 스냅샷을 생성한다.

 

 

ROOT의 스냅샷이 생성되었다.

 

스냅샷으로 이미지 생성하기

ROOT를 선택한 뒤, [스냅샷 복사]를 클릭한다. (복사는 전송의 의미)

 

대상 리전을 northeast-1(도쿄)로 설정한 뒤, [스냅샷 복사]를 클릭한다.

 

크롬에서 새탭을 열어, 우측 상단의 서울 => 도쿄 로 변경한다.

곤니찌와..

그러면 10G의 데이터가 도쿄로 transfer된다. (이 과정에서 과금될 수도 있다.)

 

스냅샷 -> 어느 시점을 찍어두고 나중에 복원함. 데이터는 그 머신에 머물러 있음

백업 -> A머신에서 데이터를 보호하기 위해 B머신으로 데이터를 옮기는 것(복사)

스냅샷은 백업 기능의 일부를 가지고 있음

 

이 스냅샷을 이미지로 만든다.

나머지는 다 디폴트 값으로 하고, [이미지 생성]버튼을 누른다.

 

 

 

[도쿄] 에서 인스턴스 탭을 들어간다.

아무것도 없는 것을 확인할 수 있다.

[인스턴스 시작] 버튼을 누른다.

 

Quick Start가 아닌, [내 AMI]를 누른다.

SEOUL IMAGE를 선택한다.

같은 IP 대역을 공유하는 것 이외에는, 공유하는 것이 거의 없다.

[새 키 페어 생성]을 선택한다.

 

 

서브넷을 1a로 설정한다.

보안 그룹 또한 새로 생성한다.

 

하단의 [Add security group rule]을 눌러 HTTP 룰을 추가한다.

 

인스턴스를 생성한다.

 

그리고 public ip로 접속해본다.

 

multi AZ

2a, 2c의 가용영역을 동시에 운영하는 방식

서울 전체가 black out -> 완전히 다운된다

그렇기 때문에 cross region을 이용해서 region간 연동시키는 방식을 이용한다. => ELB를 쓸 수 없다.(ELB는 하나의 region 안에서만 가능하다) => Route53을 이용한다. -> 이를 이용해서 load balancing을 할 수 있다.

 

multi AZ

cross region

tokyo의 스냅샷을 삭제하려고 하면 삭제되지 않는다.

이미지 -> 인스턴스를 빨리 만들게 하는 도구일 뿐이고 실제 데이터를 담고 있는 파일은 AMI이 아닌, 스냅샷에 있다.

스냅샷과 이미지가 링크되어있기 때문에, 이미지를 먼저 지워야 스냅샷이 삭제가 된다.

 

AMI탭에서 SEOUL-IMAGE를 선택한 뒤, [AMI 등록 취소]를 클릭한다.

 

이 이후에 스냅샷을 삭제하려 하면 삭제된다.

 

EFS - 서버

EC2들 - Client

SG-WEB에 속해야만 EFS에 접근할 수 있다.

보안그룹의 IP를 넣어서 활용할 수 있도록 한다.