[EC2] Load Balancer 기반 Auto Scaling 구현 (3)

AWS/EC2

[EC2] Load Balancer 기반 Auto Scaling 구현 (3) - 시스템 구현, 테스트

J_Dev 2024. 11. 22. 22:11

로드 밸런서를 생성하기 전에, EC2 Auto Scaling Group이 있어야 합니다. 생성방법은 이전 포스트를 참고해주세요!

2024.11.19 - [AWS/EC2] - [EC2] EC2 Auto Scaling Group 적용 (1) - 도입배경, 이론

이번 포스트에서는 앞서 설계한 내용을 구현하는 과정을 다룹니다. 주요 작업 순서는 다음과 같습니다

로드 밸런싱 대상이 될 Target Group 생성
Auto Scaling Group 및 Backend 인스턴스를 Target Group에 연결
각 리소스의 보안 그룹 구성
로드 밸런서 생성
연결 테스트

- 자세한 이론은은 AWS ASG 문서 와 AWS Load Balancer 문서를 참고해주세요!

1. Traget Group 생성

로드밸런싱을 위해선 우선 로드밸런싱 대상이될 Target Group을 생성해야 합니다.
이번 프로젝트에서는 REST API 서버 역할을 하는 Backend 인스턴스들이 Auto Scaling Group이 Target Group에 포함되며, Redis Cache와 정보를 주고받는 Main Backend 인스턴스도 Target Group에 포함됩니다.

1) 대상 그룹 생성 페이지로 이동

AWS Management Console에서 EC2 서비스로 이동합니다.
대상 그룹(Target Group) → 대상 그룹 생성(Create Target Group)을 클릭합니다.

2) 대상 그룹 세부사항 설정

대상 유형(Target Type): 로드 밸런서가 ASG의 EC2 인스턴스를 대상으로 연결하도록 설정합니다.

대상 그룹 이름 : backend-target-group처럼 관련성 있는 이름을 지정합니다.
프로토콜:포트 : Backend 인스턴스는 8081 포트로 Nginx(Reverse Proxy) 를 통해 연결되므로 HTTP:8081 설정합니다.
IP 주소 유형 :IPv4 선택합니다.
VPC : ASG가 속한 VPC를 선택합니다.
프로토콜 버전 : HTTP1 선택 합니다.

상태 검사 프로토콜: HTTP
상태 검사 경로(Health Check Path): /api/health이 경로로 Backend 인스턴스의 상태를 확인합니다. Health Check를 위한 API가 필요하며, 아래는 프로젝트에 적용한 Spring 코드를 예시입니다.

Spring API 코드 :

import lombok.extern.slf4j.Slf4j;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@Slf4j
@RequestMapping("/api")
public class AWSController {
    @GetMapping("/health")
    public ResponseEntity<String> healthCheck(){
        log.info("AWS Health Check Start");//health check 요청시 로그 생성
        return ResponseEntity.ok("Backend Connection = OK");//HTTP 200 응답 전송
    }

}

2. Auto Scaling Group 및 Main Backend Instance를 Target Group에 연결

로드 밸런서를 설정하려면 Auto Scaling Group(ASG)과 Main Backend Instance를 Target Group에 연결해야 합니다.
이를 통해 Load Balancer는 트래픽을 Target Group 내 모든 인스턴스로 적절히 분배할 수 있습니다.

1) Auto Scaling Group - Target Group 연결

1. ASG 상세 페이지 접근
AWS Management Console에서 EC2 → Auto Scaling Group으로 이동합니다. 연결하려는 ASG를 선택한 뒤, 통합 - 새로 만들기 탭에서 편집 버튼을 클릭합니다.

대상 그룹 선택 : 이전 단계에서 생성한 Target Group을 선택후 업데이트(Update) 버튼을 클릭합니다.

등록 확인 : Target Group의 대상(Targets) 탭으로 이동하여 ASG의 인스턴스들이 정상 상태(Healthy)로 등록되었는지 확인합니다.

2) Main Backend Instance - Target Group 연결

Main Backend Instance는 Redis Cache 저장 기능을 포함하므로, 이를 Target Group에 수동으로 추가하여 로드 밸런싱 대상에 포함합니다.

Target Group 대상 등록 : AWS Management Console에서 Target Group으로 이동하여 연결할 Target Group을 선택합니다.
대상(Targets) 탭에서 대상 등록(Register Targets) 버튼을 클릭합니다

Backend Instance 선택 및 등록 :등록할 Backend Instance를 선택하고, 포트를 확인한 뒤 아래에 보류 중인 것으로 포함(Include as Pending) 버튼을 클릭합니다.

대상 등록 확인: 대상 테이블에서 정상적으로 등록된것을 확인 후 보류 중인 대상 등록 버튼을 클릭합니다.
정상 등록 확인 : Target Group의 대상(Targets) 탭에서 해당 인스턴스가 정상 상태(Healthy)로 등록되었는지 확인합니다.

3. 보안그룹 생성/수정

1) 로드밸런서 보안그룹

주의사항

Elastic Load Balancer(ELB)가 Public으로 노출된 경우, 인바운드 규칙은 VPC 내부 IP가 아닌 Public IP 또는 외부 클라이언트 IP로 설정해야 합니다. 잘못된 규칙은 VPC 내에서 동작하지 않을 수 있습니다.
자세한 내용은 이후 설명하는 로드 밸런서 생성 부분을 참고해주세요

인바운드 규칙:

포트 80
- 목적 : 프론트엔드의 리버스프록시 요청을 수신하기위해 오픈
- 소스: 프론트엔드 EC2 인스턴스의 Public IP(Elastic IP) 또는 프론트엔드 보안 그룹

아웃바운드 규칙:

포트 8081
- 목적: Bacekend Auto Scaling Group 인스턴스와 연결을 위해 오픈
- 소스: Backend 보안 그룹

2) Auto Scaling Group (Backend Instance) 보안 그룹

ASG에 속한 Backend 인스턴스는 로드 밸런서 요청을 처리하며, 외부 서비스와 내부 자원 간 통신을 위해 여러 포트를 열어야 합니다.

인바운드 규칙:

포트 8081
- 목적: 로드 밸런서와 연결을 위해 오픈
- 소스: 로드 밸런서 보안 그룹

아웃바운드 규칙:

포트 443
- 목적:OAuth2 Provider(Naver)와의 연결을 위해 HTTPS 전체 오픈
  - 소스: 전역(0.0.0.0/0)
포트 6379, 6380:
- 목적: Redis 인스턴스와 통신을 위해 오픈
- 소스: Redis 보안 그룹
포트 3306:
- 목적: RDS 데이터베이스 접근을 위해 오픈
- 소스: RDS 보안 그룹

3)프론트엔드 보안그룹

프론트엔드 인스턴스는 클라이언트와 통신하며, 로드 밸런서를 통해 Backend로 요청을 전달합니다

인바운드 규칙:

포트 80:
- 목적: 클라이언트 요청 수신(HTTP)
- 소스: 전역(0.0.0.0/0)
포트 22
- 목적: 서버 관리용 SSH 접근
- 소스: 관리자의 IP로 제한

아웃바운드 규칙:

포트 80
- 목적 :로드 밸런서로 리버스 프록시 요청 전송
- 소스: 로드 밸런서 보안 그룹

4. 로드밸런서 생성

로드 밸런서는 백엔드 인스턴스에 요청을 효율적으로 분배하며, 가용성과 성능을 개선하는 데 중요한 역할을 합니다.

1) 로드밸런서 유형 선택

Application Load Balancer: HTTP 요청을 처리할 인스턴스를 대상으로 하므로 Application Load Balancer(ALB)를 선택합니다.
ALB는 HTTP/HTTPS를 받는 웹어플리케이션에 적합한 Load Balancer입니다.

2) 기본구성

로드밸런서 이름 : 프로젝트와 관련있는 이름으로 적어줍니다.
체계: 내부(Internal) 선택 : 백엔드 인스턴스는 외부에서 직접 접근이 불필요하므로 내부로 설정합니다.
- 주의 : 인터넷 경계(Internet-facing)를 선택하면 Public IP가 할당되고, VPC 내부 통신이 불가능할 수 있습니다.
- 프론트엔드 로드 밸런서를 설정할 때는 인터넷 경계를 선택하세요.
로드밸런서 IP 주소 유형 : IPv4 선택

3) 네트워크 매핑

VPC : Auto Scaling Group이 연결된 VPC 선택합니다.
가용영역 : VPC의 Private Subnet 2개이상 선택해줍니다.
- 고가용성을 높이기 위해 두 개 이상의 서브넷에 걸쳐 설정해야 합니다.

4) 보안그룹

보안그룹 : 전단계에서 만들어준 로드밸런서 보안그룹을 선택해줍니다.
- Health Check도 이 보안 그룹 규칙에 따라 동작하므로, 인바운드 및 아웃바운드 규칙을 정확히 설정해야 합니다.

5) 리스너 및 라우팅

프로토콜 : 80선택, 프론트엔드(Nginx)에서 들어오는 요청은 HTTP로 전달됩니다.
다음으로전달: 전 단계에서 생성한 Backend Target Group 선택
- 로드 밸런서는 요청을 Target Group에 포함된 Backend 인스턴스에 분배합니다.

6) 로드밸런서 리소스맵 확인

설정이 정상적으로 완료되었다면, 로드 밸런서 리소스 맵에서 ASG의 Backend Instance와 Health Check 상태가 정상(Healthy)으로 표시됩니다.
오류 발생시, 보안 그룹의 인바운드/아웃바운드 규칙 확인, VPC 및 서브넷 설정 검토해보세요!

5. 로드밸런싱 테스트

1) Frontend Instance에서 Load Balncer 접근확인

Frontend Instance에 SSH로 접속 : 터미널로 Frontend Instance 에 접속합니다.
Health Check API 호출 : 로드밸런서 DNS를 사용하여 Health Check API를 호출합니다. 아래 명령어를 실행합니다.

curl -I http://<Load Balaner DNS>/api/health

HTTP 200 OK 응답 확인 : Reponse에 정상적으로 HTTP 200 코드가 담긴것을 확인할 수 있었습니다.

HTTP/1.1 200 OK
Server: awselb/2.0
Date: Thu, 21 Nov 2024 04:30:56 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 2
Connection: keep-alive

2) Web Applicaiton 작동 테스트

- 테스트를 위해 모든 Instance의 SSH를 개방합니다.

테스트 시나리오

Frontend 도메인 접속

웹 브라우저를 통해 Frontend 도메인으로 애플리케이션에 접속합니다.

새로고침 및 요청 반복

여러 차례 페이지를 새로고침하여 요청을 반복 전송합니다.

Backend 로그 확인

Backend Instance에 SSH로 접속해 각 인스턴스의 로그를 확인하여, 요청이 로드 밸런싱을 통해 적절히 분배되는지 검증합니다.

결과

1회 요청
Backend Main Instance에 Request 들어옴
2회 :요청이 Auto Scaling Group의 첫 번째 인스턴스로 전달됨
3회 : 요청이 Auto Scaling Group의 두 번째 인스턴스로 전달됨
테스트 결과, 로드 밸런서는 요청을 Main Backend Instance와 Auto Scaling Group의 인스턴스들에 고르게 분산하고 있음을 확인했습니다.
이는 로드 밸런싱 설정이 성공적으로 작동하고 있음을 보여줍니다.

결론

이번 설정 및 테스트를 통해 로드 밸런서와 Auto Scaling Group이 성공적으로 트래픽을 분산 처리하는 것을 확인했습니다.
이를통해 확장성 신뢰성을 갖춘 환경을 갖출 수 있었습니다.

1) 로드 밸런서와 Auto Scaling Group의 통합

프론트엔드에서 전달된 요청이 로드 밸런서를 통해 Main Backend Instance와 Auto Scaling Group 내 인스턴스들에 균등하게 분배되었습니다.
트래픽 분산을 통해 서비스의 처리 효율성이 크게 향상되었습니다.

2) 고가용성 확보

다중 가용 영역에 인스턴스를 분산 배치하고, 동적인 Auto Scaling 정책을 통해 서비스 가용성과 복원력을 강화했습니다.3) 트래픽 급증에도 대응 가능
Auto Scaling이 설정되어 트래픽이 몰려도 새로운 인스턴스를 자동으로 생성하여 추가 요청을 분산 처리할 수 있습니다.