Elastic Load Balancer

  1. ELB 사용 배경
    • autoscaling을 통해 다수의 instance를 사용중인 user
    • 문제1 : user는 각 instance의 정보(IP)를 알아야 각각을 활용 가능
    • 문제2 : 재생성된 instance의 IP는 변동 가능
    • 문제3 : instance의 수가 증가하면 이러한 정보 관리 비용이 매우 커짐
    • 이를 해결하기 위해 ELB 사용
  2. ELB 사용 이유
    • traffic을 load balancer가 받아 부하를 분산해줌
    • traffic이 각 instance의 IP를 통해 전달되는 것이 아니라, 1개의 address에만 전달하면 됨.
    • 각 service가 해당 instance이 IP에 전달할 필요 없기 때문에 관리 편함
  3. ELB
    • 다수의 서비스에 traffic을 분산 시켜주는 서비스
    • Health Check : 직접 traffic을 발생시켜 instance가 살아있는지 확인
    • autoscaling과 연동 가능
    • 여러 가용영역에 분산 가능
    • 지속적으로 IP 주소 바뀌기 때문에 IP 고정 불가 -> 항상 domain 기반으로 사용
  4. ELB 종류
    • Application Load Balancer
      • 똑똑함 (user가 어떤 주소로 접속했는지에 따라 routing) (즉, 주소를 읽을 수 있음)
      • traffic을 monitoring하여 routing
    • Network Load Balancer
      • 빠름
      • TCP 기반 빠른 traffic 분산
      • Elastic IP 할당 가능
    • Classic Load Balancer
      • 예전 (세분화 전)
    • Gateway Load Balancer
      • 먼저 traffic을 check함
      • 가상 appliance 배포/확장 관리를 위한 서비스
        • traffic을 먼저 appliance로 전달하여 어떤 작업을 먼저 수행
        • instance 전달 전 검사, 분석, 인증, 로깅, 캐싱 등

기초 지식

  1. 대상 그룹 (Target Group)
    • ALB(application LB)가 routing할 대상의 집합
    • 구성
      1. (3+1)
        • instance
        • private IP
        • Lamda (함수)
        • 또 다른 ALB와 연결 가능하다~
      2. protocol
        • HTTP, HTTPS, gRPC
      3. 기타 설정
        • LB algorithm, 고정 세션 등

  • 1개의 대상 그룹 자체는 autoscaling으로 관리할 수 도 있다.

전체적인 architecture

실습

  1. 시작 템플릿 새버전 생성
    • 고급설정 - 사용자 데이터

        #!/bin/bash
        TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
        INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
        yum  install httpd -y
        echo ""$INSTANCE_ID"" >> /var/www/html/index.html
        service httpd start
      
      • instance는 각각 자신의 ID(metadata)를 불러옴
      • 웹서버를 다운 받아 ID 입력하여 실행시킴
  2. autoscaling에 시작 템플릿 새 버전 적용 (저번에 만들었던)
    • 시작 템플릿 - 편집 - version 변경 - 업데이트
    • 새로운 시작 템플릿의 instance가 autoscaling에 의해 생성됨
  3. 각 instacne는 userdata에 있는 script가 실행되어 web server 형성됨

  4. 대상 그룹 설정
    • LB를 생성하기 위해서
    • 이름
    • 유형 : instance
    • instance 선택 후 아래에 보류 중인 것으로 포함 클릭 후 생성
  5. LB 생성
    • ALB
    • 이름, 매핑 다 선택 (ap…)
    • 리스너 및 라우팅 - 대상 그룹 선택 (port 등을 통해 대상 그룹과 연결할 조건 변경)
    • 생성 후 설명에 가면 IP는 없고 DNS만 확인 가능
    • 새로고침 할 때마다 2개의 instance가 번갈아 가면서 web에 나타남을 확인
  6. LB를 autoscaling에 붙이기
    • autoscaling 편집 - 로드벨런싱 편집
    • application, network 또는 게이트웨이 로드밸런서 대상 그룹 클릭하여 대상그룹 선택
    • 현재 autoscaling과 target group을 연결 시켰기 때문에 autoscaling에 의해 생성된 insatace는 자동의 target group이 되고, 이는 autoscaling에 의해 생성되는 instance들은 ALB에 의해 traffic이 분산됨 (web 기준으로 새로고침 주기가 길어짐을 의미)
    • 즉, 대상 그룹 안을 autoscaling으로 조절한다는 것을 의미 (대상 그룹에서 대상 합계를 통해 몇개가 생성됬는지 확인 가능)
  7. autoscaling에선 정상으로 인식/ALB에서는 비정상으로 인식
    • instance 갯수는 유지되는데, webserver 페이지가 오류난 경우 (이럴 경우 대상 그룹에서 등록된 대상에서 unhealthy인 경우로 확인할 수 있음)
      1. autoscaling 편집
      2. 상태확인(Health Check) 편집
      3. ELB 체크 -> ELB의 상태확인도 진행하겠다는 뜻
      4. unhealthy한 instance를 ELB가 체크하여

태그:

카테고리:

업데이트: