AI & Data를 활용하는 기술경영자

클라우드 컴퓨팅 본문

AWS Certified

클라우드 컴퓨팅

Data_Lover 2022. 11. 15. 16:34
728x90

Elastic Load Balancing을 사용하여 트래픽 리디렉션

배경

Amazon EC2 Auto Scaling을 통해서 규모 조정의 문제를 해결했지만 트래픽이 몰렸을 때, 해결하지는 못합니다.

실제로, 같은 프로그램을 실행하여 같은 목적을 수행하는 EC2 인스턴스가 여러 개가 있다면 이 요청이 어떻게 EC2 인스턴스로 효율적으로 가야할까요? 아마도, EC2 인스턴스 전체에 워크로드를 균일하게 분산해야할 것입니다. 

 

간단하게 생각을 해보면, 다른 인스턴스가 쉬고 있는 동안 인스턴스 하나만 동작하게하면 안됩니다. 그래서, 요청 처리를 위해서 여러 인스턴스들로 라우팅할 방법이 필요합니다.

 

이러한 문제를  해결하기 위해선 로드 밸런싱이 필요하고, 로드 밸런서는 요청을 받은 다음 처리할 인스턴스로 라우팅하는 애플리케이션입니다.

 

여기서, 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 하고, 들어 오는 트래픽의 양에 맞춰서 Amazon EC2 인스턴스를 추가하거나 제거할 때 로드 밸랜서로 먼저 라우팅된 후 여러 리소스로 분산됩니다.

 

AWS에선 효율적으로 작동하는 다양한 로드 밸런서 제품이 있고, 사용자 운영팀이 설치, 관리, 업데이트, 확장, 장애 조치 처리, 가용성 처리를 담당하므로, AWS를 활용하면 비용 효율적, 고성능, 가용성이 높고 자동 확장이 가능하고 설정 후 잊어버리면 되는 시스템에 트래픽을 적절하게 분산해줄 것입니다.(Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스지만 연동하여 가능하다)

 

우리는 그것을 Elastic Load Balancing라고 합니다.

 

Elastic Load Balancing

정의

Elastic Load Balancing(ELB)는 로드 밸런싱의 획일적인 부담을 처리할 목적으로 주요 관리형 서비스로 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다.

 

포괄적으로 이야기를 하자면, ELB는 리전 구조로 개별 EC2 인스턴스가 아닌 리전 수준에서 실행되므로 사용자가 추가로 작업하지 않아도 자동으로 고가용 서비스가 된다는 것입니다.

 

ELB는 외부 트래픽에만 사용되지 않고 주문 계층을 살펴보고 생산 계층과 통신하는 방법을 진행합니다. 예를 들어, 백엔드와 프런트 계층에 수 백개의 인스턴스가 있을 때, 리전 구조의 단일 URL로 각 프런트엔드 인스턴스에 사용하면서 대기 중인 가장 적은 백엔드로 트래픽을 보냅니다.

 

이때, 트래픽을 백엔드 규모 조정 시 새 인스턴스가 준비가 되면 ELB에게 트래픽을 수신하여 작업하라는 지시를 내리고, 이것이 진정한 분리된 아키텍처입니다.

예시

 

 

[수요가 적은 기간]

 

Elastic Load Balancing가 어떻게 작동하는 보여주는 것으로, 고객 몇 명이 커피숍에 들어왔고 주문하려고 했을 때 계산대가 몇 개만 열려 있다면 서비스가 필요한 고객의 수요와 일치합니다.

 

 

커피숍에서 고객이 없는 계산대를 열어 둘 가능성이 적기에 계산대를 Amazon EC2 인스턴스로 생각할 수 있습니다.

 

 

 

 

 

 

[수요가 많은 기간]

 

하루 종일 고객의 수가 증가함에 따라서 커피숍은 고객을 수용하기 위해서 더 많은 계산대를 열고 이는 옆의 그림에서 Auto Scaling그룹이 이를 나타냅니다.

 

커피숍 직원이 고객을 가장 적합한 계산대로 안내하여 주문이 열려 있는 계산대에 균등하게 분배될 수 있고, 이 커피숍 직원을 로드 밸런서로 생각할 수 있습니다.

 

 

메시징 및 대기열

과부화가 걸리거나 비효율적인 시스템에선 일종의 버퍼나 대기열을 도입하면 프로세스가 훨씬 개선이 될 것이고, 그렇기 위해서 메시지를 완충 기억 장치에 배치한다는 개념을 메시징 혹은 대기열이라고 합니다.

 

애플리케이션이 메세지를 다른 애플리케이션과 통신할 때, 애플리케이션끼리 직접 소통을 한다면 밀겹합된 상태라고 부릅니다.

밀겹한된 상태면 속도는 빠를 수 있으나, 구성 요소 하나가 고장이 나거나 변경이 되면 다른 구성 요소나 심지어 시스템 전체에 문제가 발생한다는 것입니다.

 

이러한 이슈를 해결하는 것이 소결합 아키텍쳐로 특정 구성 요소에 장애가 발생하더라도 장애가 구성 요소 안에서 격리되기 때문에 전체 시스템 장애로 확정되지 않습니다.

 

우리의 목적은 어느 하나가 장애를 받더라도 다른 애플리케이션은 문제가 일어나면 안되길 원합니다.

그래서, 메시지 대기열을 도입하여 애플리케이션 A가 메시지 대기열로 메시지를 전달한 후 애플리케이션 B가 메시지를 가져와서 처리합니다.

애플리케이션 B에 장애가 발생해도 애플리케이션 A에는 중담이 발생하지 않고, A는 B의 상태에 상관없이 메시지를 대기열로 전송할 수 있고 B에서 처리될 때까지 안전하게 대기열에 보관되고 이를 소결합된 상태이며 AWS 기반 아키텍처에서 구현하려고합니다.

 

AWS 두 가지 서비스

Amazon Simple Queue Service(SQS): 메시지가 처리되기 전까지 배치되는 곳

Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있고 애플리케이션이 메시지를 대기열로 전송하고, 사용자 혹은 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제합니다.

 

규모에 상관없이 소프트웨어 구성 요소 간에 메세지를 전송, 저장,수신할 수 있고 다중화가 내재되어 있기에 메시지를 잃어버리거나 서비스가 중단될 염려가 없습니다.

 

메시지에 포함된 데이터를 페이로드라고 하며 안전하게 데이터가 보호됩니다.

 

Amazon Simple Queue Service(SQS) 상황별 예시: 주문 이행

 

 

계산원이 주문을 받고 바리스타가 음료를 만드는 주문 프로세스가 있고, 계산원과 바리스타가 애플리케이션의 두 가지 개별 요소라고 정합니다.

 

상황이 바빠지면, 주문 프로세스는 지연되어서 고객은 불편함을 겪게 될 것입니다.

고객의 줄이 줄어드는 속도가 더 느려지면 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 되어서, 점주는 대기열을 사용하는 대신 다른 방법을 사용할 것입니다.

Amazon Simple Queue Service(SQS) 상황별 예시: 대기열 이행

 

계산원과 바리스타가 애플리케이션의 두 가지 개별 구성 요소이고 Amazon SQS와 같은 메시지 대기열 서비스를 사용하면 분리된 애플리케이션 구성 요소 간에 메시지를 사용할 수 있습니다.

 

이 예에서 프로세스의 첫 번째 단계는 이전과 동일합니다.

즉, 고객이 계산원에게 주문하면 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있습니다.

바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 계산원은 계속해서 새 주문을 대기열에 넣을 수 있습니다. 

다음으로 바리스타가 대기열을 확인하고 주문을 검색합니다.

바리스타가 음료를 만드는 동안 계산원은 계속 새로운 주문을 받아 대기열에 추가할 수 있습니다.

Amazon Simple Notification Service(SNS)

게시/구독 서비스로 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시하는 것입니다.

메시지를 서비스에 전달하는데 사용하는 것이고 알림을 최종적으로 사용자에게 전송할 수 있습니다.(Pub/Sub service)

물론, 현실에선 메시지 하나를 주제에 전달하면 한 번에 모든 구독자에게 메시지가 전달되어서 SQS 대기열, AWS Lambda 함수, HTTPS 혹은 HTTP 웹 후크와 같은 엔드포인트도 구독자가 될 수 있고, SNS를 사용하면 모바일 푸시, SMS와 이메일을 사용하여 알림을 최종 사용자에게 전달됩니다.

 

Amazon Simple Notification Service(SNS) 상황별 사용: 단일 주제에서 업데이트 게시

 

커피숍에 모든 비즈니스 영역의 업데이트를 포함하는 단일 뉴스레터가 있다고 했을 때, 쿠폰 ,커피 상식, 신제품과 같은 주제가 포함됩니다.

단일 뉴스레터이기 때문에 모든 주제가 그룹화하고 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 상식, 신제품에 대한 업데이트를 받습니다.

 

얼마 후 일부 고객이 관심있는 특정 주제에 대해서만 별도의 뉴스레터를 받으면 좋겠다는 의견을 표명하면서, 커피숍 점주는 이 접근 방식울 시험해 보기로 결정합니다.

 

 

Amazon Simple Notification Service(SNS) 상황별 사용: 여러 주제에서 업데이트 게시

 

 

커피숍은 모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나눴고 각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룹니다. 그리고, 이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 됩니다.

 

구독자는 주제를 하나 또는 여러 개 구독할 수 있습니다.

모놀리식 애플리케이션 

 

애플리케이션은 여러 구성 요소로 구성되고, 서로 통신하여 데이터를 전송하고 요청을 이행하면서 애플리케이션을 계속 실행합니다.

 

구성 요소가 밀겹합된 애플리케이션이 있다고 가정했을 때, 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직등이 포함되고, 이런 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있습니다.

 

이런 접근 방식은 한 구성 요소에서 장애가 발생하면 다른 구성 요소에서 장애가 발생하고, 심지어 전체 애플리케이션에서 장비가 발생할 수 있습니다.

 

단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있습니다.

 

마이크로서비스

 

 

마이크로서비스 접근 방식에선 애플리케이션 구성 요소가 소결합되어서 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기에 계속 작동합니다. 그리고, 소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지됩니다.

 

AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있고, 두 서비스는 애플리케이션 통합을 촉진합니다.

 

Amazon Simple Notification Service(Amazon SNS), Amazon Simple Queue Service(Amazno SQS)

 

 

 

 

서버리스 컴퓨팅

https://aws.amazon.com/ko/lambda/

 

클라우드 컴퓨팅 PaaS | Amazon Web Services

AWS Lambda 및 Amazon Kinesis를 사용하여 애플리케이션 활동 추적, 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 정리, 로그 필터링, 인덱싱, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 및 측

aws.amazon.com

'서버리스'라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없고, 사용 시 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는데 더 집중할 수 있습니다.

 

서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성 덕분에 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있고, 이를  AWS Lambda입니다.

 

 

 

AWS Lambda

서버를 프로비저닝하거나 관리할 필요없이 코드를 실행할 수 있는 서비스로 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고 코드를 실행하는 동안에만 요금이 부과됩니다.

 

실제로, 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있고 관리할 필요가 없기에 간단한 Lambda 함수로 업로드되는 이미지의 크기를 AWS 클라우드에 맞춰 자동으로 조정하는 함수가 있을 수 있습니다. 이 경우 새 이미지를 업로드할 때 함수가 트리거됩니다.

 

 

AWS Lambda 작동방식

 

컨테이너

애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공하고, 보안성, 안정성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로에도 컨테이너를 사용합니다.

 

 [여러 컨테이너가 있는 단일 호스트]

회사의 애플리케이션 개발자의 컴퓨터 환경이 IT 운영 직원이 사용하는 컴퓨터의 환경과 다르다고 가정했을 때, 개발자는 애플리케이션 환경이 배포와 상관없이 일관되게 유지 되기를 원합니다.

 

애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단흔데 드는 시간을 줄일 수 있습니다.

 

 

 [수 백개의 컨테이너가 있는 수십 개의 호스트]

컨테이너식 애플리케이션을 실행할 때는 확장성을 고려하는 것이 중요하고, 여러 컨테이너가 있는 단일 호스트 대신 수백 개의 컨테이너가 있는 수십 개의 호스트를 관리해야 한다고 가정했을 때, 수 천개의 컨테이너가 있는 수 백개의 호스트를 관리 해야 합니다.

 

규모가 커지면 메모리 사용, 보안, 로깅 등을 모니터링하는데 시간을 상상하기

 

 

Amazon Elastic Container Service(Amazon ECS)

https://aws.amazon.com/ko/ecs/

AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템입니다. 

Amazon ECS는 Docker 컨테이너를 지원합니다. Docker는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼입니다. AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원합니다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있습니다.

 

Amazon Elastic Kubernetes Service(Amazon EKS)

https://aws.amazon.com/ko/eks/

Amazon Elastic Kubernetes Service(Amazon EKS)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스입니다. 

Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다. 자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력합니다. Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 손쉽게 적용할 수 있습니다.

 

AWS Fargate

https://aws.amazon.com/ko/fargate/

AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동합니다. 

AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없습니다. AWS Fargate는 자동으로 서버 인프라를 관리합니다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 됩니다.

 

추가 자료

모듈 2에서 살펴본 개념에 대한 추가 정보가 필요한 경우 다음 자료를 참조하십시오.

728x90
저작자표시 변경금지

'AWS Certified' 카테고리의 다른 글

AWS Certified Cloud Practitioner(Amazon EC2)  (0) 2022.11.14
AWS Certified Cloud Practitioner (모듈1:AMAZON WEB SERVICES 소개)  (2) 2022.11.14
'AWS Certified' Related Articles more