AWS - Elastic Load Balancing & Auto Scaling Groups Section

Scalability & High Availability

확장성과 고가용성이란?

• 애플리케이션을 스케일링 한다는 말은, 적응하여 더 큰 부하를 처리할 수 있다는 뜻이다.
• 클라우드 확장성에는 두 종류가 있는데, 수직 확장성과 수평 확장성(탄력성)이 있다.
• 확장성과 고가용성은 연결되지만 다름
• 콜센터에서 전화를 받았을때 확장 가능하다는 말을 무엇일까?

 

수직 확장성

• 수직 확장성이 가능하다는 뜻은 인스턴스의 크기를 증가할 수 있다는 뜻임
• 콜센터의 초보 상담원에서 전문 상담원으로 업그레이드 하는 경우
• AWS에서 t2.micro가 있는데 이 애플리케이션을 수직 확장하려면 애플리케이션을 t2.large에서 실행하면 된다. 즉 EC2의 인스턴스 크기를 바꾸었다.
• 수직 확장성은 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용한다. 데이터 베이스의 성능을 높이기 위해 데이터베이스의 크기를 늘리는 것임
• 보통 수직 확장성에는 수직 확장에 한계가 있다. 하드웨어의 한계가 있기 때문임. 요즘 한계가 매우 높긴 하지만.

 

수평 확장성

• EC2 인스턴스의 크기를 늘리는 대신 애플리케이션을 위한 인스턴스 또는 시스템의 숫자를 늘리는 것이다.
• 콜센터를 예시로 들면 상담원이 있고, 여기에 수평 확장을 한다는뜻은 상담원을 더 늘리는것을 뜻함. 전화를 더 많이 처리하기 원하면 상담원을 추가로 배치함. 수평 확장을 할때는 각 상담원이 처리하는 것처럼 분산 시스템이어야 함
• 웹 애플리케이션이나 현대적인 애플리케이션이라면 수평 확장성을 염두에 두고 설계해야 함
• AWS에서는 Amazon EC2와 오토 스케일링 그룹 덕분에 수평 확장이 매우 쉽다.
• 인스턴스의 숫자를 늘릴때를 Scale out / 줄일때를 Scale in 이라고 한다.
• 이를 위해서 오토 스케일링과 로드 밸런서를 사용한다.

 

고가용성

• 수평 확장성과 잘 어울리는데, 고가용성은 애플리케이션과 시스템을 AWS의 가용 영역 최소 두 군데에서 실행하는 것을 의미함
• 콜센터를 예시로 들면, 뉴욕에 있는 콜센터와 센프란시스코에 있는 콜센터가 있고 뉴욕에 정전이 발생해도 센프란시스코 콜센터가 조금더 바빠지긴 하겠지만 여전히 업무 처리가 가능함. 이것을 가용성이 높다고 한다.
• AWS에서는 데이터 센터의 손실과 같은 재앙 상황에서 살아남기 위해 두개의 가용영역을 사용한다

 

확장성 vs 탄력성 (vs 민첩성)

• 확장성 -> 하드웨어를 더 강하게 하거나 스케일 업하거나 노드를 추가해 스케일 아웃 하여 시스템이 더 큰 부하를 수용할수 있게 한다.
• 탄력성 -> 좀 더 클라우드의 특성으로 시스템이 확장 가능하여, 스케일 업하거나 스케일 아웃한다. 탄력성이란 오토 스케일링을 의미함. 즉 수신하는 로드에 따라 시스템이 자동으로 확장하는 것임. 이 경우 사용량에 따라 비용이 발생하여 수신하는 수요를 서버의 숫자와 일치시키고, 적절한 금액을 지불한 것임. 비용을 최소화 할 수 있다. AWS에서 탄력성은 핵심 개념임
• 민첩성-> 확장성 및 탄력성과 전혀 관계가 없다. 혼동을 주기 위한 단어이고, 민첩성은 새로운 IT 리소스로 클릭 한번으로 되는 것을 의미한다. 개발자가 리소스를 사용 할 수 있는 시간을 몇 주에서 몇 분으로 단축해 준다. 조직은 좀더 민첩하게 되고, 더 빨리 반복하고 더 빨리 수행할 수 있음

 

Elastic Load Balancing

로드 벨런싱이란?

• 로드 밸런서는 인터넷 트래픽을 다운 스트림의 여러 서버로 전달하는 서버이다. 여러 서버의 경우 EC2 인스턴스이고 또한 백엔드 EC2 인스턴스라고도 한다.
• AWS에서 관리하고 이 로드 밸런서 뒤에는 여러 EC2 인스턴스가 있다. 
• 로드 밸런서 작동 순서
  1. 첫 번째 사용자가 로드 밸런스와 통신
  2. 로드 밸런서는 트래픽을 이 EC2의 인스턴스중 하나로 보낸다.
  3. 그러면 EC2 인스턴스가 무언가로 응답하고 사용자는 그 응답을 받게 된다.
  4. 두 번째 사용자가 들어오면 다른 EC2 인스턴스에서 응답을 받고, 세 번째 사용자가 들어오면 또 다른 EC2 인스턴스에서 응답을 받게 된다.
• 따라서 로드 밸런서는 사용자가 많아질수록 여러 EC2 인스턴스에 걸쳐 부하를 더 많이 분산시키므로  백엔드를 더 잘 스케일링할 수 있다.

 

로드 밸런서의 사용 목적

• 여러 다운스트림 인스턴스에 부하를 분산시킬 수 있다
• 또한 어플리케이션에 대한 DNS 호스트 이름인 단일 액세스 지점을 노출할 수 있다.
• 다운스트림 인스턴스의 실패를 원활하게 처리할 수 있다.
• 정기적으로 상태 확인을 하고, 실패가 있는 인스턴스에는 로드 밸런서가 트래픽을 보내지 않는다. 따라서 로드 밸런서를 사용하여 EC2 인스턴스의 실패를 숨길 수 있다.
• 또한 웹사이트의 SSL 종료, 즉 HTTPS를 아주 쉽게 제공할 수 있다.
• 여러 가용 영역에서 로드 밸런서를 사용할 수 있어 애플리케이션의 가용성이 높아질 수 있다.
• ELB(Elastic Load Balancer)는 관리형 로드 밸런서므로 서버를 프로비저닝할 필요가 없다. AWS가 처리하고 작동을 보장하며, 로드 밸런서의 업그레이드와 유지보수, 고가용성을 모두 책임진다. 유일하게 개발자가 할 일을 해당 로그 밸런스의 동작에 관해 몇 가지를 구성하는 것임
• 자체 로드 밸런서를 EC2에 설정하는 경우 비용이 확실히 덜 들지만, 결국에는 유지 보수, 통합, 운영체제 업그레이드 처리등 훨씬 더 많은 작업을 하게 된다.
• AWS에서 제공하는 로드 밸런서에는 네 가지가 있으며 차이점을 알고 있어야한다.
  • 첫 번째는 HTTP, HTTPS 전용 트래픽을 위한 ALB(Application Load Balancer) 이다. HTTP, HTTPS이기 때문에 계층 7 유형의 로드 밸런서라고 한다.
  • 두 번째는 NLB(Network Load Balancer)이다. 초고성능이고 TCP와 UDP를 허용하며 계층 4이다. TCP와 UDP가 더 낮은 레벨이므로 계층 4임
  • 세 번째는 Gateway Load Balancer이다.  계층 3이다.
  • 네 번째는 Classic Load Balancer이다. 2023년에 폐기 시험에 안나옴

ALB, NLB, GLB의 차이점

• Application Load Balancer
  • HTTP / HTTPS/ gRPC  protocals이 있으면 계층이 7이고 ALB라는 의미
  • HTTP 라우팅이 필요할 때마다 정적 DNS에도 요청된다. 이는 정적 URL을 보유하려는 경우 매우 유용할 수 있다.
  • 아키텍쳐는 매우 간단하고, 사용자가 방금 언급한 프로토콜 중 하나에서 로드 밸런서에 액세스하면 로드 밸런서는 트래픽을 다운스트림 EC2 인스턴스로 라우팅한다. 예를 들어 대상을 EC2 인스턴스로 선택한 경우
• Network Load Balancer
  • 계층 4이며, TCP 및 UDP 프로토콜이다.
  • 성능이 매우 높고, 초당 수백만 요청을 처리한다.
  • 정적 IP를 제공하고 정적 URL이 아니라 소유하고 이동할 수 있는 IP인 탄력적 IP 사용을 통해 제공한다.
  • 정적 IP를 제공하고 아키텍처는 ALB와 똑같다. TCP 및 UDP 프로토콜에서 트래픽이 NLB로 전송되고 다운스트림 대상인 EC2 인스턴스 등으로 전달된다.
• Gateway Load Balancer
  •  IP패킷 자체에서 GENEVE 프로토콜을 사용하며, 계층 3이다.
  • 시험에 대비해 살펴볼 사용 사례는 트래픽을 EC2 인스턴스에서 관리하는 방화벽으로 라우팅하여 클래식 방화벽이나 침입 감지, 심층 패킷 검사등을 실행할 수 있다는 것이다.
  • 아키텍쳐는 약간더 복잡한데, GLB는 애플리케이션에 부하를 분산하지 않는다. 트래픽 부하를 EC2 인스턴스에서 실행하는 가상 어플라이언스에 분산한다. 따라서 트래픽을 분석하거나 방화벽 작업을 실행할 수 있다. 타사 보안 가상 어플라이언스라고 하는 이유임
    1. 트래픽이 GLB로 이동하면 먼저 트래픽을 분석할 EC2 인스턴스로 트래픽을 보낸다.
    2. 그 후에 트래픽은 다시 GLB로 전송되고 애플리케이션으로 전달된다.
  • GLB는 IP 패킷 자체를 검사하고 방화벽 기능이나 침입 감지, 심층 패킷 검사를 실행할 수 있도록 중간에 있다.
• 로드 밸런서 실습 결과
  • 로드 밸런서를 만드는 과정에서 실제 인스턴스 그룹을 만들어 적용하였고 로드 밸런서에 나오는 DNS이름에 트래픽을 보내보니 진짜로 인스턴스 그룹에 있는 인스턴스가 번갈아가며 응답함

 

Auto Scaling Group

 

오토 스케일링 그룹이란?

• 백엔드에서 자동으로 서버들을 만들 수 있는 방법
• 현실에서의 웹사이트 로드는 시간에 따라 다르기 때문, 예를 들어 온라인에서 사용자가 쇼핑을 할때, 낮 시간에 쇼핑을 하고 밤에는 쇼핑을 하지 않을 가능성이 크다. 낮 시간에 로드가 더 많을 것이라 예상할 수 있고, 밤시간에 로드는 적을 것이다.
• 클라우드에서는 매우 빠르게 서버를 만들고 없앨 수 있다.
• 오토 스케일링 그룹의 목표
  • 늘어난 로드에 맞춰 EC 인스턴스를 늘린다. (Scale out)
  • 줄어든 로드에 맞춰 EC 인스턴스르 줄인다. (Scale In)
  • 이를 통해서 어느 시점이든 실행하는 머신 숫자를 최소, 최대로 보장할 수 있다.
  • 오토 스케일링이 EC 인스턴스를 만들거나 제거하면, 이 인스턴스들이 오드벨런스에 등록되거나 등록 해지됨을 확인할 수 있다.
  • 마지막으로 서버의 상태가 비정상이면, 애플리케이션에 버그가 있다면, 오토 스케일링 그룹은 이를 감지해서 비정상 인스턴스는 필요하지 않으니 등록을 해지하고 종료한다. 
  • 새로운 정상 인스턴스로 교체한다.
• 다른 혜택으로는 비용 절감인데, 항상 최적의 용량에서 실행하기 때문이다. (이런 탄력성은 클라우드의 기본 원칙이다.)

오토 스케일링 그룹 전략

• 첫 번째는 수동으로 스케일링 하는것이다. 오토 스케일링 그룹의 크기를 수동으로 업데이트 하는 것이다. 예를들어 용량을 1에서 2로 변경하거나 반대로 하는것
• 그리고 동작 스케일링과 같이 스케일링 전략을 정의해 변경 사항을 자동으로 대응할 수 있다.
• 동적 스케일링에는 여러 유형의 스케일링 정책이 있는데,
  •  단순 / 단계 스케일링
    • CloudWatch 경보가 트리거 됐을때, 예를들어 EC2 인스턴스의 CPU 사용률이 5분동안 70%를 초과할 때마다 ASG 용량에 2개의 유닛을 추가하는 것이다.
    • 또는 다른 경보가 예를 들어 CPU 사용률이 10분동안 30% 이하일 때마다 ASG 용량에서 1개 유닛을 제거하는 것이다.
    • 단순/ 단계 스케일링인 것은 트리거를 정의한 다음에 유닛을 얼마나 추가하고 삭제할지 정의하기 때문이다.
  • 다음은 대상 추적 스케일링
    • 스케일링 정책을 손쉽게 정의하는 방식이다.
    • 예를 들어 ASG의 모든 EC2 인스턴스의 평균 CPU 사용률을 평균 40%로 유지하고자 하면 ASG에서 목표인 40%을 유지하기 위해 자동으로 조정하는 것이다.
  • 예약 스케줄링
    • 변경 사항을 미리 아는 것으로 사용자 패턴을 기반으로 확장을 예측하는 것이다.
    • 예를 들어 사람들이 금요일 오후 5시에 축구 경기에 배팅을 한다고 하면 금요일 오후 5시에 ASG의 EC2 인스턴스 최소 용량을 10까지 높이는 것이다.
  • 예측 스케일링 (시험에 꼭 나옴)
    • 머신러닝을 사용해서 트래픽을 미리 예측한다.
    • 그래서 과거 트래픽 패턴을 확인하는 알고리즘이 있고, 과거의 패턴을 기반으로 트래픽을 예측할 수 있다.
    • 예측 스케일링인 이유는 시간이 지남에 따라 발생하는 로드를 예측하기 때문이며, 로드는 하루에 3시간 동안 최고조가 될 것이다. 
    • 그리고 예측한 기간에 도달하기 전에 올바른 수의 EC2 인스턴스를 자동으로 프로비저닝 된다.
    • 따라서 시간적인 패턴이 존재하고 스케일 유형에 따라 달라지는 신뢰 전략을 신경 쓰지 않고 머신 러닝을 기반으로 쉽게 스케일링 하고자할때 좋다.