[26 하계 모각코] 모각코 2회차 활동 결과(개인)

2회차 목표

Load Balancer, ACL, Auto Scaling 이해 및 개념 정리

 

0. 들어가며

 지난 시간에는 VPC, 서브넷, NAT Gateway 등을 알아봤다. 솔직히 개념을 순차적으로 알아가는 것이 아닌 그냥 배웠던 것들 중에서 기억나는 것이나 중요하다고 생각했던 내용들 위주로 구성하고 있다.

이렇게 이론으로 정리하는 것도 중요하지만, 이해한 내용을 바탕으로 클라우드 플랫폼에서 실제로 만져보면서 실습하는 것이 진짜 중요하다고 생각한다. 아무튼 오늘은 Load Balancer, ACL, Auto Scaling에 대해 이해하고 내용을 정리해보고자 한다.

 

1. Load Balancer

 솔직히 1회차 때 배웠던 내용도 그렇지만, 클라우드를 조금이라도 들어봤거나 사용해본 사람은 모를 수가 없는 용어다.

Q. Load Balancer란?

A. 하나의 접속 지점(IP/도메인)으로 들어온 요청을 여러 대의 서버로 분산 시켜주는 서비스다. 그러니까 말 그대로 부하분산기라고 생각하면 된다.

 

- Load Balancer의 필요성: 서버 한대가 감당할 수 없는 트래픽, 혹은 트래픽이 이전에는 적었지만 한 대로 감당할 수 없을 만큼 증가한 경우에 트래픽을 여러 대가 나눠받도록 하고, 특정 서버에 장애가 생겨도 다른 서버에 트래픽을 분산시켜 서비스의 가용성을 높여주는 방법이다.

 

핵심 구성요소

구성요소	역할
리스너(Listener)	Load Balancer가 어떤 프로토콜/포트로 요청을 받을 지 정의한다.
규칙(Rule)	특정 조건(도메인, 경로 등)에 따라 어떤 Target Group으로 보낼 것인지 규칙을 정해둔다.
타겟 그룹(Target Group)	실제 트래픽을 받아 처리할 버를 하나의 그룹 단위로 묶어둔 것

 

종류

구분	ALB(Application Load Balancer)	NLB(Network Load Balancer)
지원 프로토콜	HTTP, HTTPS	TCP, UDP
계층	L7(애플리케이션 계층)	L4(전송 계층)
라우팅 방식	Host Header, HTTP Header, Path Pattern 기반 규칙 라우팅	5-튜플(Source/Dest IP Port, Protocol)
성능 조절	Small/Medium/Large/Extra-large 중 선택	서비스 규모에 따라 자동 조절
활용 사례	일반 웹 서비스, 도메인/경로별 분기가 필요한 서비스	게임 서버, 대용량 TCP/UDP 트래픽 처리가 필요한 서비스

 

※cf. Target Group에 바인딩된 서버의 ACG 및 Network ACL에 Load Balancer가 사용하는 Subnet 대역이 접근 소스 및 허용 포트로 반드시 포함되어 있어야한다. -> 즉, LB를 만들고 나서 끝이 아니라 뒤에 다룰 설정인 ACL 설정까지 같이 확인해야 트래픽이 정상적으로 흘러간다.

2. ACL(Access Control List)

 그렇다면 앞에 LB에서 언급된 ACL이 뭔지 알아보자.

Q. ACL이 무엇인가?

A. 간단하게 말하면, 네트워크 트래픽을 필터링하는 것이다. 어떤 것을 들어오게 허용하고(Inbound), 어떤 것을 나가게 할지(Outbound)에 대한 규칙을 설정하는 것이다.

 

정리하자면, ACL은 네트워크 트래픽을 IP, 포트, 프로토콜을 기준으로 허용하거나 차단하는 규칙의 목록(List)을 말하는 것이다.

앞에 언급헀던 개념 중에 ACG와 Network ACL이 있는데 이 개념들도 명확히 짚고 넘어가보자.

 

- ACG(Access Control Group): 서버 단위로 동작하는 방화벽

- Network ACL: Subnet 단위로 동작하는 방화벽

 

간단하게 이렇게 정리해볼 수 있겠다.

 

조금 더 명확하게, 직관적으로 이해할 수 있게 표로 한 번 더 정리해보겠다.

 

Network ACL vs ACG(Access Control Group)

구분	Network ACL	ACG
작동 시점	Subnet 접근 시 작동	서버 접근 시 작동
규칙 방식	허용/차단 규칙이 모두 설정(기본은 허용)	허용 규칙만 설정(기본은 차단)
상태 저장	Stateless - Inbound/Outbound 규칙을 각각 설정해야 함	Stateful - Inbound에서 허용된 트래픽은 outbound도 자동 허용
판정 방식	우선순위에 따라 순차처리(먼저 걸린 규칙 적용)	모든 규칙을 평가한 뒤 판정
적용 대상	대상 Subnet의 모든 서버에 자동 적용	서버에 개별적으로 지정해야 적용

 

3. Auto Scaling

위의 두 개념하고는 비교적 연관성이 떨어져보이는 Auto Scaling에 대해 알아보고자 한다.

하지만 이 개념도 상당히 자주 등장하는 용어이다.

 

- Auto Scaling은 크게 2가지 문제를 해결해준다.

1. 예측이 어려운 트래픽 대응: 정확한 서버 용량을 예측하지 못하더라도, 조건에 도달하면 자동으로 서버를 추가/반납할 수 있어서 미리 서버를 과도하게 투입할 필요가 없다.

2. 시간대별 트래픽 최적화: 트래픽이 몰리는 시간에는 서버를 늘리고, 한산한 시간에는 서버를 반납해 운영 비용을 절감할 수 있다는 장점을 지니고 있다.

 

핵심 구성 요소는 다음과 같다.

 

핵심 구성 요소

구성요소	역할
Launch Configuration	Auto SCaling으로 생성될 서버의 구성 템플릿(이미지, 스펙, 초기 스크립트 등)
Auto Scaling Group	Launch Configuration을 기바능로 서버 그룹을 만들고, Scaling 정책/일정/헬스 체크를 설정하는 단위

 

Auto Scaling Group을 만들 때, 설정하는 주요 값은 다음과 같다.

1. 최소 용량/ 최대 용량/ 기대 용량: 그룹이 유지할 서버의 하한선, 상한선 목표값을 설정하는 부분

2. 쿨다운: Scaling이 실행된 후, 서버가 완전히 준비될 때까지 다른 알람에 반응하지 않고 대기하는 시간

3. 헬스 체크 보류 기간: 서버 생성 직후 초기화 작업 떄문에, 헬스 체크에 일시적으로 실패해도 무시해주는 시간

4. 헬스 체크 유형: 서버 자체 상태로 판단할 것이닞, Load Balancer의 Target Group 헬스 체크 결과로 판단할 것인지 선택하는 부분

 

Scaling 정책 3가지

정책	설명	예시
증감변경	그룹 크기와 상관없이 지정된 수만큼 서버를 추가/삭제	서버 2대 추가
비율변경	현재 그룹 크기 대비 일정 비율로 서버를 추가	현재 서버 수의 20% 증가
고정값	그룹 크기를 지정된 값으로 고정	서버 수를 항상 5대로 유지

4. 회고

- 내가 생각하기에 많이 쓰였던 용어들을 정리해보는 시간을 가졌다. 아직도 하루만 지나서 물어본다면 비슷한 개념인 것 같아서 헷갈려 할 것 같은데, 자격증 시험 대비도 할 겸 반복적으로 개념학습을 해서 암기 -> 이해 루트로 공부해볼 생각이다.

 

- 앞으로는 이걸 개념 뿐만이 아닌 직접 실습을 통해 클라우드 아키텍처도 설계해보고 이를 바탕으로 직접 클라우드도 구축해보면서 재미를 조금 더 찾아가볼 예정이다. 이에 앞서 우선 개념적인 부분에 대한 구멍부터 메워보고자 한다.