내가 작업하는 프로젝트의 구조는, 위챗 내부에서 회사의 독자적인 기술의 라벨을 스캔하면 프로모션 백엔드로 프로모션 여부를 검증한 후 프로모션이라면 프로모션 로직에서 response하는 값으로 웹뷰의 내용이 보여지고, 프로모션 라벨이 아닌 일반 라벨이라면 일반 라벨의 웹뷰 내의 랜딩페이지가 보여지는 방식으로 동작하고 있다.
그리고 작업을 한 내용은 프로모션 검증하는 내용을 위챗 내부에 추가해야 해서
프로모션 백엔드를 호출하는 post method를 추가해야 했기에,
프로모션 백엔드를 위챗에 추가된 도메인 내부에 배포해야 했다!
단순히 ec2에 배포하면 되겠거니 하고, docker-compose로 배포한 후
postman으로 헬스체크를 해보니 Error: connect ECONNREFUSED 71.xxx.xx.x:8080 라는 응답을 받았다. 근데 내가 배포한 ec2 ip는 71로 시작하지 않는걸????????????????
AWS에 접속해서 확인하니, 로드밸런서와 타겟 그룹이 보인다🙃🙃🙃
로드 밸런서 (ALB - Application Load Balancer)
로드 밸런서는 여러 서버(인스턴스) 간에 네트워크 트래픽을 자동으로 분산하여 서버의 부하를 분산하고 애플리케이션의 가용성과 성능을 높이는 장치 또는 서비스입니다. 주로 사용자의 요청을 서버 여러 대에 고르게 분산해 주며, 단일 서버에 과부하가 걸리는 상황을 방지해줍니다.
역할
- 트래픽 분산: 여러 서버로 요청을 분산하여 각 서버의 부하를 줄이고 시스템의 안정성을 유지합니다.
- 고가용성 제공: 서버 중 하나가 고장 나더라도 다른 서버가 트래픽을 처리하여 서비스가 중단되지 않도록 합니다.
장애 감지 및 헬스 체크: 로드 밸런서는 각 서버의 상태를 정기적으로 확인(헬스 체크)하여, 비정상적인 서버로는 트래픽을 보내지 않습니다. - 보안 강화: HTTPS를 통해 암호화된 트래픽을 처리하여 클라이언트와 서버 간의 보안을 강화할 수 있습니다.
로드 밸런서의 종류
AWS에서는 여러 유형의 로드 밸런서를 제공합니다:
1. Application Load Balancer (ALB)
HTTP/HTTPS 트래픽을 분산하는 데 최적화되어 있습니다.
경로 기반 또는 호스트 기반 라우팅이 가능하며, URL의 경로나 도메인 이름에 따라 트래픽을 특정 서버로 라우팅할 수 있습니다.
주로 웹 애플리케이션이나 API 트래픽을 처리할 때 사용됩니다.
2. Network Load Balancer (NLB)
TCP/UDP 트래픽을 빠르게 처리하며, 초당 수백만 개의 요청을 처리할 수 있는 고성능 로드 밸런서입니다.
주로 초저지연과 고성능이 필요한 트래픽에 적합합니다.
3. Classic Load Balancer (CLB)
과거에 사용되던 기본적인 로드 밸런서입니다. 현재는 새로운 프로젝트에 ALB 또는 NLB가 권장됩니다.
애플리케이션 및 네트워크 계층에서의 간단한 로드 밸런싱이 가능합니다.
로드 밸런서의 구성 요소
1. 리스너 (Listener)
리스너는 로드 밸런서가 요청을 수신하는 프로토콜과 포트를 정의합니다. 예를 들어, HTTP:80, HTTPS:443과 같이 특정 포트와 프로토콜을 설정하여 클라이언트의 요청을 받아들입니다.
2. 대상 그룹 (Target Group)
로드 밸런서가 트래픽을 전달할 서버 또는 서비스 그룹을 정의합니다. 대상 그룹에는 EC2 인스턴스, Lambda 함수, 컨테이너 등 다양한 대상이 포함될 수 있습니다.
헬스 체크 설정을 통해 각 서버의 상태를 모니터링하고, 비정상 서버로는 트래픽을 전달하지 않도록 합니다.
3. 헬스 체크 (Health Check)
로드 밸런서는 대상 서버의 상태를 주기적으로 확인하여, 정상적인 서버에만 트래픽을 분산합니다. 헬스 체크가 실패하면 해당 서버는 Unhealthy 상태로 표시되어 트래픽이 전달되지 않습니다.
로드 밸런서를 설정하려면?
-
로드 밸런서 생성: AWS Management Console에서 Application, Network, 또는 Classic Load Balancer를 생성합니다.
-
리스너 설정: 로드 밸런서가 사용할 프로토콜과 포트를 지정하고 리스너를 설정합니다.
대상 그룹 생성 및 등록: 트래픽을 분산할 서버(대상)를 지정하여 대상 그룹을 생성하고 로드 밸런서와 연결합니다. -
헬스 체크 설정: 서버가 정상 상태인지 확인하기 위해 헬스 체크 경로와 주기를 설정합니다.
-
예시: ALB로 웹 애플리케이션 트래픽 분산
클라이언트가 ALB의 도메인(예: example.com)으로 요청을 보냅니다.
HTTP:80 리스너가 요청을 수신하고, HTTPS로 리다이렉션합니다.
HTTPS:443 리스너가 요청을 처리하며, /api/*로 들어오는 트래픽은 Spring Boot 서비스로,
나머지 트래픽은 Tomcat 서버로 라우팅하는 규칙에 따라 요청을 분배합니다.
로드 밸런서의 헬스 체크가 서버 상태를 주기적으로 확인하여,
Healthy 상태인 서버에만 트래픽을 전달합니다.리스너
로드 밸런서에서 리스너(Listener)는 클라이언트 요청을 수신하고, 이를 설정된 대상 그룹(Target Group)으로 전달하는 역할을 하는 구성 요소입니다. 리스너는 특정 프로토콜과 포트에 대한 트래픽을 관리하며, 이를 통해 로드 밸런서가 어떻게 요청을 처리할지 결정합니다.
역할
- 요청 수신: 리스너는 지정된 프로토콜(예: HTTP, HTTPS)과 포트(예: 80, 443)에서 들어오는 요청을 수신합니다.
- 규칙 평가: 리스너에는 여러 개의 규칙을 설정할 수 있습니다. 각 규칙은 URL 경로, 요청 헤더, IP 주소 등 특정 조건에 따라 요청을 필터링하여 각기 다른 대상 그룹(Target Group)으로 트래픽을 라우팅합니다.
- 대상 그룹으로 트래픽 포워딩: 규칙에 따라 요청을 특정 대상 그룹으로 포워딩합니다. 대상 그룹은 로드 밸런서가 분산해야 할 실제 서버(예: EC2 인스턴스) 또는 컨테이너 그룹입니다.
- SSL 종료: HTTPS 리스너의 경우, SSL 인증서를 사용하여 SSL/TLS 연결을 종료하고 클라이언트와 보안 통신을 설정합니다.
리스너 구성 요소
- 프로토콜: 리스너가 수신할 요청의 프로토콜 (예: HTTP 또는 HTTPS).
- 포트: 리스너가 요청을 수신할 포트 (예: 80, 443).
- 규칙: 트래픽 라우팅 조건을 설정할 수 있는 규칙입니다. 예를 들어, /api/*로 시작하는 모든 요청을 특정 대상 그룹으로 보내도록 규칙을 설정할 수 있습니다.
- 대상 그룹: 리스너가 요청을 전달할 대상 그룹을 지정합니다.
리스너 설정 방법
1. 로드 밸런서 생성 시 리스너 설정
- 로드 밸런서를 처음 생성할 때 리스너를 설정할 수 있습니다. 이때, 기본 프로토콜과 포트를 지정합니다.
2. 기존 로드 밸런서에 리스너 추가
- AWS Management Console에서 로드 밸런서의 Listeners 탭에서 리스너를 추가할 수 있습니다.
3. 필요한 구성 설정
- 프로토콜 및 포트 설정: 트래픽을 처리할 프로토콜 (HTTP, HTTPS)과 포트를 설정합니다.
- 규칙 추가: 경로 기반 라우팅을 설정하려면 Add rule 기능을 사용하여 요청 경로에 따라 트래픽을 라우팅하는 규칙을 추가합니다.
- SSL 인증서 (HTTPS의 경우): HTTPS 리스너를 사용할 때는 SSL 인증서를 설정해야 합니다. 이 설정을 통해 클라이언트와 로드 밸런서 간의 트래픽을 암호화할 수 있습니다.
타겟 그룹
타겟 그룹(Target Group)은 로드 밸런서가 트래픽을 전달하는 서버 그룹입니다. 로드 밸런서는 타겟 그룹을 통해 여러 서버(예: EC2 인스턴스)로 트래픽을 분산하고, 헬스 체크를 통해 서버 상태를 관리합니다. 각 타겟 그룹은 로드 밸런서가 요청을 분산할 서버나 서비스들을 정의하며, 특정 조건에 맞춰 선택적으로 요청을 전달할 수 있습니다.
타겟 그룹의 역할과 기능
1. 트래픽 분산 대상 지정
- 타겟 그룹은 로드 밸런서가 트래픽을 보낼 서버(인스턴스, 컨테이너, IP 등)를 지정합니다.
- 각 타겟 그룹에는 하나 이상의 서버가 포함될 수 있으며, 로드 밸런서는 타겟 그룹의 서버들로 요청을 자동으로 분산합니다.
2. 헬스 체크(Health Check) 관리
- 타겟 그룹 내 서버의 상태를 주기적으로 확인하여, 정상(Healthy) 상태가 아닌 서버로는 트래픽을 보내지 않습니다.
- 헬스 체크 설정(경로, 주기, 응답 시간)을 통해 서버가 정상인지 여부를 판단합니다.
3. 라우팅 규칙과 연계
- 로드 밸런서의 리스너에서 조건(경로, 헤더, 도메인 등)에 따라 요청을 특정 타겟 그룹으로 라우팅할 수 있습니다. 예를 들어, /api/ 경로는 API 서버로, /web/ 경로는 웹 서버로 분산할 수 있습니다.
4. 특정 애플리케이션 설정
- 타겟 그룹을 통해 로드 밸런서가 다양한 서비스(예: 마이크로서비스 아키텍처에서 API 서버, 웹 서버 등)로 요청을 분산할 수 있습니다. 각 서비스마다 별도의 타겟 그룹을 생성하고 라우팅 규칙을 설정해주면 됩니다.
타겟 그룹의 구성 요소
1. 타겟(Target)
- 트래픽을 전달할 서버나 인스턴스입니다. 타겟은 EC2 인스턴스, Lambda 함수, IP 주소, 또는 ECS 컨테이너 등으로 지정할 수 있습니다.
2. 타겟 그룹 유형(Target Type)
- Instance: EC2 인스턴스를 타겟으로 지정.
- IP: 특정 IP 주소(프라이빗 IP 또는 퍼블릭 IP)를 타겟으로 지정.
- Lambda: Lambda 함수를 타겟으로 지정하여, 요청을 Lambda 함수로 분산.
3. 포트와 프로토콜
- 타겟 그룹 내의 타겟이 요청을 수신할 포트와 프로토콜을 정의합니다. 예를 들어, HTTP 프로토콜과 포트 8080을 사용하여 웹 서버로 요청을 전달할 수 있습니다.
4.헬스 체크 설정
- 헬스 체크 프로토콜 및 경로: 서버 상태를 확인하기 위해 HTTP, HTTPS와 같은 프로토콜과 경로(예: /health 또는 /status)를 지정합니다.
- 헬스 체크 주기 및 타임아웃: 헬스 체크 요청을 보내는 주기와 응답 대기 시간을 설정합니다. 서버가 헬스 체크를 통과하지 못하면 Unhealthy로 표시됩니다.
- 정상/비정상 임계값: 특정 횟수 이상의 헬스 체크를 통과해야 Healthy 상태로 표시되며, 연속 실패 시 Unhealthy로 전환됩니다.
타겟 그룹의 작동 예시
1. HTTP 요청 분산
- ALB가 HTTP 요청을 수신한 후, 요청 경로에 따라 특정 타겟 그룹으로 분산합니다.
- 예를 들어, /api/ 경로는 타겟 그룹 API-Backend로, /web/ 경로는 타겟 그룹 Web-Frontend로 라우팅할 수 있습니다.
2. 헬스 체크에 따른 트래픽 분산
- 타겟 그룹은 각 타겟의 헬스 체크를 통해 상태를 주기적으로 확인하며, Healthy 상태의 타겟에게만 트래픽을 전달합니다.
- 만약 서버가 Unhealthy 상태로 표시되면 로드 밸런서는 자동으로 다른 타겟에 트래픽을 전달합니다.
타겟 그룹 설정 방법
1. 로드 밸런서와 연결할 타겟 그룹 생성
- AWS Management Console에서 EC2 서비스 > Target Groups 메뉴에서 새 타겟 그룹을 생성합니다.
- 타겟 유형, 프로토콜 및 포트 등을 설정합니다.
2. 타겟 등록
- 트래픽을 수신할 타겟을 선택하여 타겟 그룹에 등록합니다. 예를 들어, EC2 인스턴스, IP 주소 또는 Lambda 함수를 추가할 수 있습니다.
3. 헬스 체크 설정
- 헬스 체크 경로, 프로토콜, 주기, 타임아웃 등의 설정을 지정하여 서버 상태를 모니터링할 수 있습니다.
4. 로드 밸런서에 타겟 그룹 연결
- 로드 밸런서의 리스너 규칙에 따라 트래픽이 특정 타겟 그룹으로 전달되도록 설정합니다. 예를 들어, HTTPS 리스너에서 /api/* 요청이 API 서버 타겟 그룹으로 라우팅되도록 규칙을 추가할 수 있습니다.
실제 구성 예시
클라이언트 요청
↓
도메인 (wechat.xxx.cn)
↓
ALB (HTTPS:443)
↓
리스너 규칙에 따라 분기
├── /api/promotion/* → WECHAT-PROMOTION-8080-BACKEND (Spring Boot)
└── 그 외 → WECHAT-8090-TOMCAT (Tomcat)보안 그룹
-
ALB의 보안 그룹
- 인바운드: HTTPS(443) 허용
- 아웃바운드: 타겟 그룹의 포트(8080, 8090) 허용
-
EC2의 보안 그룹
- 인바운드: ALB로부터의 트래픽 허용
- 포트: 애플리케이션 포트(8080, 8090)
헬스 체크
- 각 타겟 그룹별로 설정
- 주기적으로 지정된 엔드포인트로 요청
- 성공/실패에 따라 타겟의 상태 결정
- 비정상 타겟은 자동으로 트래픽에서 제외
실제 서버 적용
- 위의 도식화처럼, 로드밸런서에는 2개의 리스너가 존재
- HTTP:80은 HTTPS:443으로 리다이렉트해주는 기능을 하는 리스너
- HTTPS:443 리스너는 다시 2개의 규칙이 존재
- 기존 규칙은 52.xx.xxx.x:8090로 포워딩되고 있음
- 여기에 새로운 규칙을 추가하여, /api/promotion/* 의 path 패턴의 경우 52.xx.xxx.x:8080 으로 포워딩 되도록 설정 ( 우선순위를 10으로 둬서 default보다 우선적으로 처리)
