ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [AWS] ELB(Elastic Load Balancer) 개념 정리
    Cloud/AWS 2021. 4. 20. 14:19
    728x90
    반응형

    로드 밸런싱 개념 정리하기

    이번 글에서는 로드 밸런싱을 공부하면서 헷갈렸던 부분을 정리해보겠습니다. (어쩌면 당연한 부분들인데 헷갈렸던 것들이 있습니다,,)

    로드 밸런서를 왜 사용하는지는 다들 알고 있을 것입니다. 서버 한대로만 트래픽을 받으면 그 서버에 부하가 걸리기 때문에 로드 밸런서를 통해서 여러 서버로 트래픽을 분산시키기 위해서 사용합니다.

    스크린샷 2021-04-20 오후 1 19 29

     

     

    로드밸런서를 사용하면 아키텍쳐는 위와 같습니다. 즉, 클라이언트는 로드밸런서에 접속을 하고 로드밸런서는 해당 트래픽을 각각의 Target-Group 인스턴스들로 분산을 시켜주는 것입니다.

     

    여기서 궁금증이 생겼습니다.(지금 생각해보면 당연한 것인데.. 그럼에도 정리를..)

     

     

     

    타겟 그룹마다 인스턴스의 역할이 다른것인가?

    예를들어, Target-Group A의 인스턴스는 A 요청 트래픽을 받고 Target-Group B는 B 요청 트래픽만 받도록 인스턴스를 설계하는 것인가? 라고 생각을 했습니다. 이게 맞다면 로드 밸런서에는 어떻게 설정을 해야 하는 것이지? 의 의문을 가졌습니다.
    (물론 이 방법도 AWS 내에서 존재할 수도? 있지만.. 현재는 모르겠습니다)

     

    좀 더 고민해보니 각 타겟 그룹에 존재하는 EC2 인스턴스들 마다 다른 역할을 하는 것이 아니라 모두 같은 내용을 담고 있는 인스턴스여야 트래픽 분산의 효과를 잘 얻을 수 있다고 생각했습니다.(일단 제가 실습해본 예제 수준에선.. ?) 즉 모든 타겟 그룹의 인스턴스들은 같은 서버의 역할을 해야합니다.



     

     

    타겟 그룹 내에 존재하는 인스턴스의 URI 접근 방법

    지금 생각하면 너무나 당연한 것인데 헷갈렸던 부분이기에 정리를 하려 합니다.

     

    스크린샷 2021-04-20 오후 1 38 02

     

     

    Load-Balancer에 들어가보면 위와 같이 DNS가 존재합니다. 해당 DNS를 복사해서 접속하면 로드밸런서와 연결되어 있는 타겟그룹의 인스턴스로 트래픽이 전달될 것입니다. 즉 로드밸런서 DNS 이름(Base_url) 그대로 들어가면 EC2_IP(Base_url)로 접속한 것과 똑같은 결과를 얻는다는 것입니다.

     

     

    스크린샷 2021-04-20 오후 1 43 46

     

    참고로 위와 같이 대상 그룹을 만들 때 로드밸런서가 해당 대상 그룹 내부에 존재하는 인스턴스의 어떤 포트로 전달할 것인지를 선택할 수 있습니다.

     

    제가 궁금했던 점은 그러면 EC2 내부에 수 많은 URI가 존재할텐데 이곳은 어떻게 접속할까? 였습니다.(당연한건데.. ㅠ,ㅠ) 가령 {{EC2_IP}}:8080/test 라는 API를 갖고 있는 EC2 인스턴스가 Target-Group A, Target-Group B에 존재한다고 가정하겠습니다.

    위에서 말했던 것처럼 로드밸런서를 통해서 해당 API를 호출하려면 어떻게 해야할까요? 당연히.. {{로드밸런서 DNS}}/test 라고 접속하면 됩니다.

     

     

    스크린샷 2021-04-20 오후 1 49 13

     

    위에서 볼 수 있듯이 {{로드밸런서 DNS 주소}}/test로 접속하면 타겟 그룹의 인스턴스들로 트래픽이 잘 분산되는 것을 볼 수 있습니다.

     

    추가로 현재는 Domain이 없고 HTTPS도 적용하지 않아서 위와 같이 접속하지만 Route 53, ACM을 이용해서 Domain 구입하고 HTTPS를 적용하면 해당 도메인으로 접속할 수 있습니다.

     

     

     

    Health Check란 무엇일까?

    스크린샷 2021-04-20 오후 1 55 11

     

    로드밸런서의 대상 그룹을 만들 때 위와 같이 상태 검사를 지정하는 부분이 있습니다. 프로토콜, 상태 검사 경로를 지정할 수 있습니다. 위와 같이 지정하면 로드밸런서가 주기적으로 대상그룹 인스턴스들에게 HTTP 형태의 루트 경로로 보내겠다는 뜻입니다.

     

    저는 상태 검사 경로가 상태 검사도 하면서 로드 밸런서가 트래픽을 분산시켜주는 경로인가? 라고 생각했는데.. 지금 생각해보면 당연히 말이 안되는 생각이었습니다. 상태 검사 경로는 단순히 해당 인스턴스들이 잘 작동하고 있는지? 체크만 하는 역할입니다.

    스크린샷 2021-04-20 오후 1 55 18

    • 정상 임계값: 연속으로 몇 번 정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목
    • 비정상 임계값: 연속으로 몇 번 비정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목
    • 제한 시간: 타임아웃 시간으로 응답이 몇 초 이내로 오지 않을 경우 비정상 응답으로 판단할지 지정하는 항목
    • 간격: 몇 초 간격으로 인스턴스의 상태를 물어볼지 지정하는 항목

     

     

    위와 같이 상태 검사를 직접 상황에 맞게 좀 더 커스텀해서 설정할 수도 있습니다.

     

    스크린샷 2021-04-20 오후 2 07 43

     

    로드밸런서가 대상 그룹 인스턴스들에게 상태 검사를 했을 때 올바르게 응답이 잘 오면 위와 같이 Healthy 상태가 됩니다.

     

     

     

     

    로드 밸런서 부하 분산 비중

    스크린샷 2021-04-20 오후 2 13 26

     

    로드밸런서 리스너를 보면 위와 같이 대상 그룹에게 어떤 비율로 트래픽을 분산할지를 설정할 수 있습니다. 여기서 의문이 들었던 것은 위에서 로드 밸런서 안에 존재하는 모든 인스턴스들은 다 같은 내용을 담고 있는 인스턴스여야 한다고 했습니다. 그러면 왜 굳이 부하 분산에 비중을 나누는 것이지?라는 생각을 했습니다.

     

    이것도 좀 더 생각을 해보니 인스턴스마다 같은 내용을 담고 있다 하더라도 일부 인스턴스들은 사양이 좋은 인스턴스로 만들 수 있기 때문에 사양이 좋은 인스턴스라면 그 쪽으로 트래픽을 많이 가도록 설정하는 것입니다. (따라서 모든 인스턴스를 다 사양을 좋게 만들 필요 없이 일부만 사양을 좋게 한 후에 그쪽으로 트래픽을 좀 더 가도록 설정하면 비용 절감?의 효과가 있지 않을까 생각합니다.)

    반응형

    댓글

Designed by Tistory.