CLB(Classic Load Balancer)로 ELB의 종류 중 하나이며, 현재는 권장하지 않는 오래된 버전인 관리형 로드 밸런서입니다.
네트워크 4계층인 TCP 통신을 통해 접근이 가능하며, 네트워크 7계층인 HTTP, HTTPS로도 접근이 가능합니다.
각 인스턴스의 상태를 체크하는데, 주로 TCP나 HTTP를 통해 확인합니다.
CLB로부터 고정 호스트 이름을 부여 받아 작업합니다.
1) Client가 HTTP 리스너를 통해 CLB에 연결
2) 내부에서는 CLB가 Traffic을 EC2 Instance에 전송
CLB 생성 과정과 실습 내용을 정리해보겠습니다.
1) 기본적으로 인스턴스 하나가 있어야 합니다. (새로 만든 로드밸런서에 연결할 인스턴스 하나는 있어야 하므로)
2) 대시보드에서 좌측 탭에 로드밸런서를 선택해서 생성하도록 합니다.
관리형 로드 밸런서는 종류가 총 4가지이며, 현재는 이전 세대인 CLB를 만들어 볼 예정입니다.
3) 보안 그룹을 할당합니다.
로드 밸런서에 대한 새로운 보안그룹을 셋팅합니다.
이는 로드 밸런서의 인바운드 규칙이라 생각하면 됩니다. 로드 밸런서에 접근하기 위해서 필요한 보안 규칙입니다.
4) 위에서 로드 밸런서 접근 관련해서 HTTP 프로토콜만 80번 포트로 열어뒀고 어디서든 접근할 수 있게 해놨기 때문에
HTTPS나 SSL로 규칙을 정의하지 않았기 때문에 이런 경고가 발생합니다.
하지만 로드 밸런서에 데이터를 전송할 때 트래픽 상 암호화를 해야할만큼 중요한 데이터가 없기도 하고 단순히 로드 밸런싱이
어떻게 진행되는지 확인하고자 만드는 것이므로 3번과 같이 HTTP에 대해서만 프로토콜을 열어둡시다.
5) 사용자가 로드 밸런서를 통해서 인스턴스에 접근할 때 확인하는 상태값 입니다.
기본적으로 로드 밸런서가 인스턴스에 접근할 때 상태값에 따라서 사용자의 요청(트래픽)을 인스턴스에 보낼지 말지 확인합니다.
우선 Ping 경로에 정의된 /index.html이 라우터 역할을 합니다.
여기에 HTTP 프로토콜로 80번 포트로해서 핑을 보낼 것이고 잘 오게 된다면 해당 인스턴스는 상태가 좋은거라 여겨
트래픽을 전달하게 됩니다.
우선 /index.html을 / 로 변경해주시면 됩니다.
고급 세부 정보에서 응답시간 초과는 인스턴스에 요청을 보냈을때 상태를 포함한 응답이 오는 제한 시간을 말하며,
이 시간은 간격보다는 작아야 합니다.
왜냐하면 간격이란 것이 요청을 다시 보내는 기간(=Interval)인데 요청을 다시 보내기도 전에 응답이 초과되어서
종료가 된다면 제대로 서비스가 되지 않기 때문입니다.
따라서 간격이 응답 시간 초과보다 시간상 길어야하며, 비정상 임계값과 정상 임계값은 몇 차례 다시 수행해보고
수행한 횟수만큼 비정상이 떨어졌다면 비정상, 정상이 떨어졌다면 정상으로 정의 내리는 기준이 되는 값입니다.
6) 하나 만들어 둔 인스턴스를 붙입니다.
이는 로드 밸런서에 인스턴스를 추가한 내용으로 앞으로도 여러 인스턴스를 생성했을때, 다음 로드 밸런서에 붙이게 된다면
로드 밸런서는 여러 인스턴스(가용영역이 특정되지 않음)에 대해서 상태를 확인하고 트래픽을 보내게 됩니다.
이렇게 생성한 로드 밸런서에서 기본 구성에 DNS를 확인한 다음 이걸로 사용자는 URL 접근하면 됩니다.
7) 로드밸런서의 DNS로 사용자는 접근할 수도 있고 인스턴스의 public IP로도 접근할 수 있습니다.
이는 위험한 보안 구조입니다.
사용자가 인스턴스에 직접 접근하는 것(공공 IP)은 좋지 못한 방법입니다.
따라서 현재 로드밸런서의 보안 그룹에서도 HTTP 프로토콜에 80번 포트를 열어둔 상황이고
누구에게나 허용했기에 사용자가 접근 가능한 상태이며, 마찬가지로 EC2 인스턴스의 보안그룹에 대해서도
HTTP 프로토콜에 80번 포트를 모두에게 열어둔 상황이라 사용자가 접근이 가능합니다.
이 EC2 인스턴스의 보안그룹에 HTTP 프로토콜, 80번 포트에 대한 Source를 로드 밸런서에서 정의한
보안 그룹으로 셋팅한다면, 외부에서 직접적으로 인스턴스에 접근(public IP)하는 이슈는 발생하지 않을 것입니다.
강력한 보안그룹을 셋팅하는 것과 같습니다.
8) 로드 밸런서에서 HTTP 프로토콜에 대해서만 보안 그룹을 만들었기 때문에 EC2 인스턴스에 대해서도 HTTP 프로토콜에
대해서만 소스로 로드 밸런서 보안 그룹을 셋팅합니다.
여러 인스턴스들을 만들어서 위와 같은 작업을 해준다면 사용자가 public IP를 통해 EC2 인스턴스에 곧바로 접근하는
경우는 발생하지 않을 것입니다.
사용자는 로드 밸런서를 통해 EC2 인스턴스에 접근해야하며, 이는 로드 밸런서의 DNS를 통해 진행되게 됩니다.
여기서 발생할 수 있는 문제는 로드 밸런서에 인스턴스가 붙지 않는 경우(Out-Service)인데
이는 두 가지 문제 중 하나일 가능성이 높습니다.
첫 번째는 인스턴스의 보안그룹에서 로드 밸런서에서 정의한 프로토콜 상에서의 (예를 들면, HTTP) 보안 규칙, 보안 소스를 제대로
설정하지 않았을 가능성입니다.
두 번째는 인스턴스를 생성할 때 초기 부트스트랩, 즉 사용자 데이터 스크립트에서 문제가 발생해서 제대로 인스턴스가
생성되지 않은 경우입니다.
이 두 케이스에 대해서 면밀히 확인한다면 다음 문제는 해결될 수 있습니다.
'Cloud' 카테고리의 다른 글
| AWS - ELB(NLB) (0) | 2023.01.17 |
|---|---|
| AWS - ELB(ALB) (0) | 2023.01.17 |
| AWS - ELB & ASG (0) | 2023.01.17 |
| AWS - EFS (1) | 2023.01.17 |
| AWS - AMI (1) | 2023.01.17 |
