1. Load Balancing 정의

• Load Balancing(ELB)의 의미 :
  • Load : 불러오다(v), 짐, 무게, 하중(명사)
  • Balancing : 평형, 균형(명사)
  • 단어의 의미만을 조합해본다면, 무게의 균형을 맞추는 일
  • Load Balancing을 한국말로는 부하 분산
• 부하라는 것은 서버에 들어오는 클라이언트의 요청(트래픽)을 의미하고, 분산은 나눈다는 의미이다.
• 서버에 요청이 과하게 많이 들어올 수 있기 때문에,
  • 이 부하들을 여러 대의 서버로 잘 분산시켜서 요청을 시간내에 처리할 수 있게 하는 것이다.
  • 이렇게 각 서버로 부하를 분산시켜주는 역할을 하는 것을 Load Balancer라고 부름
• e.g. 급식빵을 나눠주는데, 유통기한이 30분임
  • 30분 안에 이 빵을 모든 학생들에게 나눠주고 먹어야 하는 상황
  • 선생님은 ‘빵을 8명의 학생들에게 어떻게 나눠줘야 할 것인가“
  • 빵을 나눠주는 방법은 빵을 유통기한 내에 먹어서 없애는 방법이기도 하다.
• e.g. 빵은 클라이언트들의 요청(트래픽), 학생들은 각각의 서버, 선생님은 Load Balancer이다.
• Load Balancing : timeout이라고 부르는 제한 시간 내에
  • Load Balancing 알고리즘에 따라서 요청들을 분산시키고 각 서버에서 처리하도록 하는 것

2. Load Balancing 목적

2.1 성능 향상

e.g. 1분의 유통기한 내, 800g의 빵을 모두 먹어치워야 하는 경우

• 1명의 학생은 1분에 빵을 200g씩 먹을 수 있다고 가정
• 학생 4명이 함께 빵을 나눠먹을 경우, 아슬아슬하지만 다 먹음
• 학생 8명이 함께 빵을 나눠먹을 경우, 여유롭게 다 먹음

Load Balancing을 적용하게 되면,

• 클라이언트들의 수많은 요청들을 빠르게 응답해줄 수 있다.
• 그렇기 때문에 성능 향상이 이뤄진다
  • 같은 시간에 처리할 수 있는 요청의 개수가 확 늘어나기 때문

2.2 안전성 향상

e.g. 1분의 유통기한 내, 800g의 빵을 모두 먹어치워야 하는 경우

• 1명의 학생은 1분에 빵을 200g씩 먹을 수 있다고 가정
• 학생 4명이 함께 빵을 나눠먹을 경우, 1명이 목막히면 다 못먹음
• 학생 8명이 함께 빵을 나눠먹을 경우, 2명이 목막혀도 다른 학생이 먹으면, 다 먹음

AWS도 여러 개의 EC2 인스턴스가 죽어도, 남은 EC2 인스턴스들이 클라이언트들의 요청을 처리해줄 수 있기 때문에 안정성이 향상된다.

2.3 서버 장애 예방

e.g. 빵의 개수를 예측불가, 학생들이 목 막힐 수도 있음

• 개수를 예측할 수 없어서, 옆반 학생 8명은 대기 시켜두기
• 우리반 학생 8명 먹이고 있다가,
• 빵이 추가로 들어오면, 옆반 학생 8명에게 빵을 나줘주기

AWS도 갑자기 클라이언트 요청이 대량으로 들어오거나, 여러 개의 EC2 인스턴스가 중간에 죽더라도, 미리 계획해둔 백업 플랜에 따라 EC2 인스턴스를 더 띄워서 서버의 장애를 예방 할 수 있다.

2.4 고가용성

• 고가용성 : High Availability의 약자로 보통 HA라고 부름
  • 서버가 오랜기간 동안 정상적으로 작동이 가능한 성질을 의미
• 가용성이 높다는 것은 고장이 잘 나지 않는다는 의미
  • 또한 서버의 관점에서 가용성이 높다는 것은, 장애가 나지 않고 지속적으로 서버가 정상적으로 잘 작동하는 것
• Load Balancing을 적용하게 되면, 장애를 미리 대비할 수 있기 때문에, 고가용성을 달성할 수 있다.

2.5 성능 향상 기반 제공

e.g. 일반적인 단일 서버의 구성을 보면, 클라이언트의 요청이 곧바로 EC2로 전달된다.

• 그런데 갑자기 서비스가 대박이 나서 클라이언트의 요청이 엄청 늘어난 경우,
• 이때 EC2 인스턴스를 여러대 늘려서 요청을 분산시켜야 한다.
• 하지만 위와 같이 중간에 Load Balancer가 있는 구조라면, Load Balancer가 성능 향상의 기반이 된다.
  • 그래서 이렇게 클라이언트의 요청이 갑자기 많아져도, EC2 인스턴스를 더 띄우고,
  • Load Balancer를 통해서 부하를 분산시킴으로써 성능을 향상 시킬 수 있다.
• 그래서 Load Balancing이 성능 향상의 기반을 제공한다.

3. Load Balancing 관련 용어

• Load Balancing 알고리즘 : 트래픽을 각 서버에 분배하는 방법(빵을 나눠주는 방법)
• Health Check
  • 서버가 살아있는지 확인하는 것(학생이 빵을 먹을 준비가 되었는지 목이 막혔는지 확인하는 것)
  • 만약 서버가 중단 되었다면 트래픽을 분배하지 않음(목이 막힌 학생에게 더 이상 빵을 주지 않음)
• Connection Draining (등록 취소 지연)
  • 사용자의 요청을 처리중인 서버를 곧바로 삭제하지 못하도록 방지하는 기능
  • Drain은 ‘물을 빼내다’ 라는 뜻을 갖고 있음
  • 트래픽이 줄어서 늘렸던 인스턴스중 몇개를 삭제하려고 할 때,
    • 삭제될 인스턴스에 연결중인 사용자가 있을 수 있기 때문에
    • 지정한 시간만큼 기다린 이후에 인스턴스를 삭제함
• Latency : Load Balancer와 서버 사이의 지연시간

4. Elastic Load Balancing

AWS에서 Load Balancing을 위해서 제공하는 것이 바로 ELB( Elastic Load Balancing)이다.

• 리전 내에 복수 개의 가용 영역이 존재한다.

  • ELB는 리전에 존재하는데, ELB는 리전별로 생성한다
  • 리전에 생성된 ELB는 여러 개의 가용 영역에 존재하는 EC2 인스턴스들에 부하를 분산시켜 준다.

• 이때 모든 EC2 인스턴스에 부하를 분산시키는 것이 아니라,

  • Target Group(대상 그룹)이라고 불리는 그룹에 속한 EC2 인스턴스들에게만 부하를 분산시킨다.
  • Target Group : 부하를 분산시킬 대상 인스턴스들이 속한 그룹을 의미

ELB는 여러 개의 가용 영역으로 부하를 분산시킬 수 있기 때문에,

• 가용 영역 하나가 통째로 중단 되어도 정상적으로 운영할 수 있다.
• cf. ELB의 Load Balancing 알고리즘은 Round Robin Scheduling을 사용한다.
  • Round Robin Scheduling은 Time Quantum이라고 부르는 시간 단위로 나눠서 작업을 할당하는 방식
  • 위키백과 라운드 로빈 스케줄링

4.1 ELB Load Balancer 유형

• ALB(Application Load Balancer)
  • 개별 요청 수준에서 작동하는 Load Balancer
  • HTTP 헤더를 기준으로 트래픽을 분배(L7 switch)
  • HTTP 및 HTTPS 트래픽을 사용하는 애플리케이션을 위한 유연한 기능이 필요한 경우에 사용
  • 마이크로서비스 및 컨테이너를 비롯한 애플리케이션 아키텍처를 대상으로 하는 고급 라우팅 및 표시 기능을 제공
    • 여기서 사용할 Load Balancer
• NBL(Network Load Balancer)
  • 연결 수준에서 작동하는 Load Balancer
  • IP주소와 포트번호를 기준으로 트래픽을 분배(L4 switch)
  • 초고성능, 대규모 TLS 오프로딩, 중앙집중화된 인증서 배포, UDP에 대한 지원 및 고정 IP 주소가 필요한 경우에 사용
  • 안전하게 초당 수백만 개의 요청을 처리하면서도 극히 낮은 지연 시간을 유지할 수 있음
  • TCP, UDP
• CLB(Classic Load Balancer)
  • 이름 그대로 과거에 사용하던 Load Balancer (cf. 이전 버전이므로 되도록 ALB 또는 NLB만 사용)
  • HTTP 헤더 및 IP주소와 포트번호를 기준으로 트래픽을 분배(L4, L7 switch)
  • EC2-Classic 네트워크에서 구축된 기존 애플리케이션이 있는 경우에 사용
  • HTTP, HTTPS, TCP, UDP

OSI 7 Layers에서 동작하는 NLB, ALB를 살펴보면,

• 4번째 Layer인 Transport Layer에서 작동하는 것이 NLB이고,
• 7번째 Layer인 Application Layer에서 작동하는 것이 바로 ALB이다
• cf. OSI 7계층이란

5. (실습) EC2 WordPress 인스턴스 생성

[EC2] → [인스턴스 시작] 버튼을 눌러 새 인스턴스를 생성한다.

• 이름 : WordpressInstance
• Application and OS Images : 검색창에 wordpress bitnami 친 뒤에 엔터
  • 여기서 AWS Marketplace AMI 탭을 누른다.
  • 여기서 WordPress Certified by Bitnami & Automatic Image를 선택.
  • [선택] 버튼을 클릭하면, 해당 AMI에 대한 상세 정보 다이얼로그가 나온다.
    • 여기서 [요금] 탭을 누른다.
    • AMI 중에는 무료 이미지도 있지만 유료로 사용 요금을 내야 하는 이미지들도 있다.
    • 지금 선택한 이미지는 이미지에 대한 요금은 시간당 0달러로 무료로 사용할 수 있다.
    • 나중에 다른 AMI를 사용할 때 꼭 이 요금을 잘 확인하고 사용하자.
  • 오른쪽 하단의 [계속] 버튼을 클릭.
  • 그러면 선택한 이미지가 설정된 것을 볼 수 있다.
• 인스턴스 유형 :
  • AMI를 설정할 때, 인스턴스 유형도 자동 변경이 되는데,
  • 프리티어로 실습할 것이기에, 프리티어 T2.micro를 선택합니다.
• 키 페어(로그인) : 이전 실습에서 생성해둔 키를 선택.
• 네트워크 설정 : 그대로 두고 넘어가기
• 스토리지 구성 : 그대로 두고 넘어가기
• 모든 설정을 마쳤으면, [인스턴스 시작] 버튼을 클릭하여 새로운 인스턴스를 생성한다.

일정 시간이 지나면 인스턴스 생성은 완료되는데, 선택한 AMI에 대한 구독이 진행되기 때문에 시간이 조금 걸린다.

• 일정 시간이 지나 상태 검사를 모두 통과하면, 상세정보에 있는 Public IPv4 주소를 통해 접속할 수 있다.
• 복사 버튼을 눌러서 IP 주소를 복사해서 주소창에 넣으면, WordPress 블로그가 나온다.

이렇게 EC2에 WordPress가 이미 설치된 AMI를 사용해 WordPress 블로그를 만들 수 있다.

6. (실습) ELB Load Balancer 생성

[EC2] → 왼쪽 메뉴에 [로드 밸런싱]의 [로드밸런서]를 클릭한다.

• 오른쪽 위에 [로드밸런서 생성] 버튼을 클릭.

(로드 밸런서 유형 비교 및 선택) 페이지

• ALB(Application Load Balancer)에 있는 생성 버튼을 클릭.

(Application Load Balancer 생성) 페이지

• 로드 밸런서 이름 : MyFirstELB (각자 기억할 수 있는 이름을 입력)
• cf. 네트워크 매핑 부분 : 가용 영역을 설정하는 부분
  • cf. ELB는 리전 별로 생성한다고 배웠다.
  • 하나의 리전 내에는 복수계의 가용 영역이 존재한다.
  • 그래서 어떤 가용 영역에 있는 EC2 인스턴스로 부하를 분산시킬지 선택하는 부분이다.
• 매핑
  • 24-01-13 시점에서 서울리전에는 총 4개의 가용 영역이 존재한다.
  • ap-northeast2a와 ap-northeast2c 이렇게 2개를 선택
  • 주의할 점은 이전 실습에서 생성한 WordPress 인스턴스가 있는 가용 영역을 무조건 포함해야 한다.
  • 그래야 해당 인스턴스로 부하를 분산시킬 수 있기 때문.
• 보안 그룹
  • 여기서의 보안 그룹은 로드밸런서로 들어오고 나가는 트래픽에 대한 가상의 방화벽을 의미
  • 보안그룹 목록에서 WordPress로 시작하는 보안그룹만을 선택 (default 삭제)
    • cf. 이 보안그룹은 앞에서 WordPress AMI를 사용해서,
    • EC2 인스턴스를 생성할 때 함께 생성된 보안그룹이다.
    • 이걸 사용하는 이유는 이 보안그룹의 외부에서 WordPress 인스턴스에 접속할 수 있는
      • 인바운드 규칙들이 이미 포함되어 있기 때문
    • 그래서 이 보안그룹을 사용하면 외부에서 ELB를 통해서 WordPress 인스턴스로 접속 가능.
• 리스너 및 라우팅 : ELB로 들어온 부하를 어디로 분산시킬지 정하는 부분
  • cf. 대상그룹(Target Group) : ELB가 부하를 분산시킬 대상 인스턴스들의 집합.
  • 지금은 대상 그룹이 하나도 없기 때문에, 먼저 [대상 그룹 생성] 버튼을 클릭

💡 (대상 그룹 - 그룹 세부 정보 지정) 페이지

• 대상 유형 선택 :
  • 먼저 부하를 분산시킬 대상을 선택해야 하는데,
  • 우리는 인스턴스로 부하를 분산시킬 것이기 때문에, 인스턴스를 선택.
• 대상 그룹 이름 : MyTargetGroup

나머지 설정은 그대로 하고, 제일 하단에 있는 [다음] 버튼을 클릭합니다.

(대상을 실제로 등록하는 단계) 페이지

• 이전 실습에서 생성해둔 EC2 WordPress Instance를 선택.
• 그리고 밑에 나오는 [아래에 보류 중인 것으로 포함] 버튼을 클릭
  • cf. 이 버튼은 뭔가 번역이 조금 이상하게 된 것 같은데,
  • 그냥 대상 그룹의 인스턴스를 넣는다는 의미로 이해하면 됨
• 그러면 하단에 있는 대상 목록에 해당 인스턴스가 추가된다.
• 이제 [대상 그룹 생성] 버튼을 클릭

그러면 대상 그룹이 정상적으로 생성된다. 다시 ELB 생성하는 창으로 돌아간다.

• 리스너 및 라우팅 중에 [새로고침] 버튼을 클릭하고, 생성한 대상 그룹을 선택한다.
• 모든 설정이 끝났으니, 하단 제일 하단에 [로드밸런서 생성] 버튼을 클릭

그러면 로드밸런서가 정상적으로 생성된다.

• [로드밸런서 보기] 버튼을 클릭.
• 그러면 로드밸런서 목록이 나오고, 현재 상태는 프로비저닝 중으로 나온다.
• 시간이 몇 분 지나면, 로드밸런서의 상태가 활성으로 바뀐다.

왼쪽 메뉴에 [로드 밸런싱]의 [대상그룹]으로 가서, 대상 그룹 상세보기 화면에서 [대상] 탭을 눌러보면,

• 인스턴스가 하나 존재하며 상태가 health로 나오는 것을 볼 수 있다.
• 이는 대상 그룹에도 대상이 정상적으로 등록된 것을 의미한다.

왼쪽 메뉴에 [로드 밸런싱]의 [로드 밸런서]으로 돌아가서.

• ELB의 상세 정보 하단에 나오는 [DNS 이름]을 주소창에 복붙해서 접속해보자.
• 그러면 WordPress 블로그가 정상적으로 나오게 된다.

6.1 지금까지 만든 구조

1
(클라이언트 요청) ⎯⎯⎯⎯> (ELB) ⎯⎯⎯⎯> (EC2, Wordpress)

• 클라이언트의 요청이 EC2 인스턴스로 곧바로 가는 것이 아니라,
  • ELB를 통해서 EC2 인스턴스로 전달되는 구조이다.
• 지금은 EC2 인스턴스가 하나밖에 없는 상태이다.
• 그래서 엄밀히 말하면 부하가 분산된다고 할 수는 없다.
  • 이어지는 다음 실습에서는 총 2개의 EC2 인스턴스를 만들고 부하를 분산시킬것이다.

1
(클라이언트 요청) ⎯⎯⎯⎯> (ELB) ⎯⎯⎯⎯> (EC2, Wordpress)
2
                             ⎯⎯⎯⎯> (EC2, Wordpress)

7. (실습) 다른 가용영역에 EC2 WordPress 인스턴스 생성

[EC2] → [인스턴스] 메뉴를 클릭한 뒤에, [인스턴스 시작] 버튼을 클릭

• 이름 : WordpressInstance2 (이전에 생성한 EC2 인스턴스와 구분할 수 있는 이름을 입력)
• Application and OS Images : 검색창에 wordpress bitnami 친 뒤에 엔터 (이전과 동일)
  • 여기서 AWS Marketplace AMI 탭을 누른다.
  • 여기서 WordPress Certified by Bitnami & Automatic Image를 선택.
  • [선택] 버튼을 클릭하면, 해당 AMI에 대한 상세 정보 다이얼로그가 나온다.
  • 오른쪽 하단의 [계속] 버튼을 클릭.
  • 그러면 선택한 이미지가 설정된 것을 볼 수 있다.
• 인스턴스 유형 :
  • AMI를 설정할 때, 인스턴스 유형도 자동 변경이 되는데,
  • 프리티어로 실습할 것이기에, 프리티어 T2.micro를 선택합니다.
• 키 페어(로그인) : 이전 실습에서 생성해둔 키를 선택.
• 네트워크 설정 :
  • [편집] 버튼을 클릭
  • [서브넷] 메뉴를 클릭 (cf. Subnet은 가용 영역을 선택하는 것)
    • 클릭하면, 서울리전에 있는 4개의 가용 영역 목록이 나온다.
    • 여기서 꼭 이전에 생성한 EC2 인스턴스와 다른 가용 영역을 선택한다.
    • cf. 창을 하나 또 띄워서 인스턴스 목록에 보면 해당 인스턴스의 가용영역이 보임
    • cf. 서울 리전의 c영역, a영역은 프리티어 T2.micro 지원
• 스토리지 구성 : 그대로 두고 넘어가기
• 모든 설정을 마쳤으면, [인스턴스 시작] 버튼을 클릭하여 새로운 인스턴스를 생성한다.

인스턴스 목록으로 이동하고, 시간이 지나면, 인스턴스 상태가 [실행중], 상태검사까지 완료된다.

8. (실습) ELB에 EC2 인스턴스 등록

[EC2] → 왼쪽 메뉴 [대상 그룹] 페이지로 접속한다.

• 그럼 만들어둔 대상 그룹이 1개 나온다.
• 상세보기에서 [대상] 탭을 클릭.
• 새로운 대상을 등록하기 위해서 오른쪽에 있는 [대상 등록] 버튼을 클릭
• 대상을 등록할 수 있는 화면이 나오면, 새로 생성한 WordPress EC2 인스턴스를 선택.
• 선택한 이후에 [아래의 보류 중인 것으로 포함] 버튼을 클릭
• 그러면 하단에 있는 대상 목록에 새로운 인스턴스가 추가된다.
• [보류 중인 대상 등록] 버튼을 클릭하여 대상 등록 절차를 진행한다.

상세보기의 대상 목록에 새로운 EC2 인스턴스가 추가된 것을 볼 수 있다.

• 처음에 대상을 등록하면 곧바로 부하 분산되지 않고, 상태 확인에 나와 있는 것처럼 초기화를 진행한다.
• 새로 추가된 대상에 대해 Healthy 체크까지 모두 끝나면, [Healthy 상태]로 변경된다.
• Healthy 상태가 되면, ELB에서 새 EC2 인스턴스로도 부하를 분산시키게 된다.

9. (실습) Load Balancing 작동 확인

[EC2] → [인스턴스]에서 첫 번째로 생성한 EC2 인스턴스를 선택하고, Public IPv4 주소를 복사

• 브라우저 주소창에 IP 주소를 붙여넣고 주소 뒤에 /admin을 붙여 관리 페이지로 접속
  • cf. /admin은 WordPress에서 제공하는 관리자 페이지 주소임
• 관리자 페이지로 접속하면 이렇게 로그인하는 화면이 나온다.
  • 관리자 아이디와 비밀번호를 알아내기 위해서 다시 EC2 페이지로 이동.
• EC2 인스턴스 목록에서 해당 인스턴스를 선택하고, 오른쪽 상단의 [작업] 메뉴를 클릭
  • 그러면 하위 메뉴가 나오는데, [모니터링 및 문제 해결] → [시스템 로그 가져오기] 클릭
  • 그러면 시스템 로그를 볼 수 있는 화면이 나온다.
  • Bitnami에서 만든 WordPress AMI에는 기본적으로 시스템 로그로 관리자 아이디와 비밀번호를 출력한다.
• 여기서 로그를 위로 올리다 보면,
  • Setting Bitnami application password to 박스로 된 영역을 발견할 수 있다.
  • 기본 사용자는 user로 되어있고, 비번은 나와있는데 사용하면 된다. (1+P1E,u/h9/Q)
  • 패스워드를 복붙해서 WordPress에 관리자로 로그인한다.
• 관리자 메뉴 왼쪽에 있는 메뉴 중 Posts 메뉴를 클릭하고, Add New를 클릭해 새 글을 작성.
  • 그리고 제목과 글 내용을 각각 작성하면 됩니다.
  • 글은 아무렇게나 작성해도 되지만,
  • 인스턴스를 구분할 수 있도록 제목과 글을 작성한다.
  • e.g. 첫 번쨰 EC2에만 보이는 글
  • 글을 모두 작성했다면 이제 오른쪽 상단에 있는 Publish 버튼을 클릭
  • 그리고 바뀌는 메뉴에서 다시 Publish 버튼을 클릭
  • 그러면 글 작성이 완료되고, 새로 작성된 글 링크가 나온다.
  • 여기서 View Post 버튼을 눌러서 바로 글을 확인.

이번에는 IP 주소로 EC2 인스턴스에 곧바로 접속하는 것이 아닌 ELB를 통해서 접속한다.

• [로드밸런서] 페이지에서 생성해둔 ELB를 선택하고, 하단에 나오는 DNS 이름을 복사
• 현재 2개의 인스턴스로 부하를 분산하도록 해놨기 때문에,
  • 새로 고침할 때마다 다른 인스턴스로 부하가 분산된다.
  • 그래서 계속 새로고침한다.
  • 새로고침을 하다보면, 글 목록에 아까 작성한 글이 나오는 경우가 생긴다.
    • 이 경우에는 글을 작성한 EC2 인스턴스로 부하가 분산된 경우이다.
  • 여기서 또 새로고침을 하다보면, 글이 사라지는 것을 볼 수 있다.
  • 이 경우는 글을 작성하지 않은 다른 인스턴스로 부하가 분산된 것이다.

9.1 지금까지 만든 구조

1
(클라이언트 요청) ⎯⎯⎯⎯> (ELB) ⎯⎯⎯⎯> (EC2, Wordpress)
2
                             ⎯⎯⎯⎯> (EC2, Wordpress)

• ELB를 만들고 대상 그룹에 총 2개의 EC2 인스턴스를 생성해서 등록
• 그리고 둘 중 하나의 인스턴스에만 직접 접속해서 글을 작성했고,
• ELB를 통해서 접속을 시도했을 때,
  • 글 목록이 달라지는 것을 통해서 부하 분산이 정상적으로 이뤄지는 것을 확인함