Q70. Application Load Balancer로 HTTP 애플리케이션 가용성 개선하기

-

AWS 자격증을 준비하는 여러분, 안녕하세요. 오늘은 네트워크 로드 밸런서(NLB)와 애플리케이션 로드 밸런서(ALB)의 차이점, 그리고 HTTP 애플리케이션의 가용성을 개선하는 방법에 대해 알아보겠습니다. 이 문제를 통해 로드 밸런서 선택의 중요성과 Auto Scaling 그룹의 활용 방법을 이해할 수 있습니다.

문제 상황

Q1:
회사의 HTTP 애플리케이션은 NLB(Network Load Balancer) 뒤에 있습니다. NLB의 대상 그룹은 웹 서비스를 실행하는 여러 EC2 인스턴스와 함께 Amazon EC2 Auto Scaling 그룹을 사용하도록 구성됩니다.

회사는 NLB가 애플리케이션에 대한 HTTP 오류를 감지하지 못한다는 것을 알게 되었습니다. 이러한 오류는 웹 서비스를 실행하는 EC2 인스턴스를 수동으로 다시 시작해야 합니다. 회사는 사용자 정의 스크립트나 코드를 작성하지 않고 애플리케이션의 가용성을 개선해야 합니다.

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

<small>A company's HTTP application is behind a Network Load Balancer (NLB). The NLB's target group is configured to use an Amazon EC2 Auto Scaling group with multiple EC2 instances that run a web service.

The company has discovered that the NLB is not detecting HTTP errors for the application. These errors require manual restarts of the EC2 instances that run the web service. The company needs to improve the application's availability without writing any custom scripts or code.

What should a solutions architect do to meet these requirements?</small>

선택지

A. NLB에서 HTTP 상태 확인을 활성화하고 회사 응용 프로그램의 URL을 제공합니다.
<small>Enable HTTP health checks on the NLB and provide the URL of the company's application.</small>

B. EC2 인스턴스에 cron 작업을 추가하여 1분에 한 번씩 로컬 애플리케이션의 로그를 확인합니다. HTTP 오류가 감지된 경우. 응용 프로그램이 다시 시작됩니다.
<small>Add a cron job on the EC2 instances to check the local application's logs once every minute. If HTTP errors are detected, the application will be restarted.</small>

C. NLB를 Application Load Balancer로 교체합니다. 회사 애플리케이션의 URL을 제공하여 HTTP 상태 확인을 활성화합니다. 비정상 인스턴스를 교체하도록 Auto Scaling 작업을 구성합니다.
<small>Replace the NLB with an Application Load Balancer. Enable HTTP health checks by providing the URL of the company's application. Configure an Auto Scaling action to replace unhealthy instances.</small>

D. NLB에 대한 UnhealthyHostCount 지표를 모니터링하는 Amazon CloudWatch 경보를 생성합니다. 경보가 ALARM 상태일 때 비정상 인스턴스를 교체하도록 Auto Scaling 작업을 구성합니다.
<small>Create an Amazon CloudWatch alarm that monitors the UnhealthyHostCount metric for the NLB. Configure an Auto Scaling action to replace unhealthy instances when the alarm is in the ALARM state.</small>

정답 및 해설

정답은 C입니다.

Application Load Balancer(ALB)는 HTTP 및 HTTPS 트래픽을 처리하는 데 최적화된 로드 밸런서입니다. ALB는 애플리케이션 계층(Layer 7)에서 작동하며, 요청의 내용을 기반으로 트래픽을 라우팅할 수 있습니다. 이는 NLB가 제공하지 않는 HTTP 오류 감지 기능을 포함합니다.

ALB의 주요 특징:

  1. HTTP/HTTPS 프로토콜 지원
  2. 경로 기반 라우팅
  3. 호스트 기반 라우팅
  4. HTTP 헤더 및 메서드 기반 라우팅
  5. 고급 상태 확인 기능

ALB를 사용하면 HTTP 상태 확인을 구성하여 애플리케이션의 상태를 정확하게 모니터링할 수 있습니다. 비정상 인스턴스가 감지되면 Auto Scaling 그룹이 자동으로 해당 인스턴스를 교체하여 애플리케이션의 가용성을 향상시킬 수 있습니다.

<small>The correct answer is C: Replace the NLB with an Application Load Balancer. Enable HTTP health checks by providing the URL of the company's application. Configure an Auto Scaling action to replace unhealthy instances.

Application Load Balancer (ALB) is optimized for handling HTTP and HTTPS traffic. It operates at the application layer (Layer 7) and can route traffic based on the content of the request. This includes the ability to detect HTTP errors, which the NLB cannot do.

Key features of ALB:

  1. Support for HTTP/HTTPS protocols
  2. Path-based routing
  3. Host-based routing
  4. Routing based on HTTP headers and methods
  5. Advanced health check capabilities

By using an ALB, you can configure HTTP health checks to accurately monitor the health of your application. When unhealthy instances are detected, the Auto Scaling group can automatically replace them, improving the application's availability.</small>

오답 설명

A. NLB에서 HTTP 상태 확인을 활성화하고 회사 응용 프로그램의 URL을 제공합니다: NLB는 네트워크 계층(Layer 4)에서 작동하므로 HTTP 상태 확인을 지원하지 않습니다. 따라서 이 옵션은 문제를 해결할 수 없습니다.

<small>A. Enable HTTP health checks on the NLB and provide the URL of the company's application: NLB operates at the network layer (Layer 4) and does not support HTTP health checks. Therefore, this option cannot solve the problem.</small>

B. EC2 인스턴스에 cron 작업을 추가하여 1분에 한 번씩 로컬 애플리케이션의 로그를 확인합니다: 이 방법은 사용자 정의 스크립트를 사용하지 않아야 한다는 요구 사항을 위반합니다. 또한, 이는 로컬 솔루션이므로 로드 밸런서 수준에서 문제를 해결하지 않습니다.

<small>B. Add a cron job on the EC2 instances to check the local application's logs once every minute: This method violates the requirement of not using custom scripts. Additionally, it's a local solution that doesn't address the issue at the load balancer level.</small>

D. NLB에 대한 UnhealthyHostCount 지표를 모니터링하는 Amazon CloudWatch 경보를 생성합니다: 이 방법은 NLB의 한계를 해결하지 않습니다. NLB는 여전히 HTTP 오류를 감지하지 못하므로, UnhealthyHostCount 지표가 HTTP 오류를 정확하게 반영하지 않을 수 있습니다.

<small>D. Create an Amazon CloudWatch alarm that monitors the UnhealthyHostCount metric for the NLB: This method doesn't address the limitations of the NLB. The NLB still won't be able to detect HTTP errors, so the UnhealthyHostCount metric may not accurately reflect HTTP errors.</small>

결론

이 문제는 로드 밸런서 선택의 중요성과 애플리케이션 계층 문제를 해결하기 위한 적절한 도구 선택의 중요성을 강조합니다. HTTP 애플리케이션의 가용성을 개선하기 위해서는 Application Load Balancer와 같은 애플리케이션 계층 로드 밸런서를 사용해야 합니다. ALB는 HTTP 오류를 감지하고, 정교한 상태 확인을 수행하며, Auto Scaling과 통합하여 비정상 인스턴스를 자동으로 교체할 수 있습니다. 이를 통해 수동 개입 없이 애플리케이션의 가용성을 크게 향상시킬 수 있습니다.

<small>This question emphasizes the importance of choosing the right load balancer and selecting appropriate tools to address application layer issues. To improve the availability of an HTTP application, it's necessary to use an application layer load balancer like the Application Load Balancer. ALB can detect HTTP errors, perform sophisticated health checks, and integrate with Auto Scaling to automatically replace unhealthy instances. This can significantly improve application availability without manual intervention.</small>

원본 문제 링크

댓글

댓글 쓰기

이 블로그의 인기 게시물

Windows Git 설치 및 GitHub 활용 방법

-
이미지
Windows Git 설치 및 Git 활용 방법 1) Git 다운로드 및 설치 1-1) Git은 분산 버전 관리 시스템 기반의 버전 관리 도구 이다. Git은 Git Hub나 GitLab 같은 중앙 서버를 둘 수도 있지만 기본적으로 로컬에서 사용하게 된다. 따라서 Git을 사용하기 위해서는 pc에 설치가 필요하다. 2) 윈도우에서 설치 2-1) 다음의 사이트에 접속 후 검색엔진에 'git' 으로 검색해도 접근 가능하다.  https://git-scm.com/download/win 2-2) 본인 환경에 맞춰 다운로드 후 설치를 진행 한다. 2-3) 다운로드 받은 설치파일을 실행 한다. Next> 2-4) 설치할 경로를 지정한다. Next> 2-5) 특별한 경우가 아니면 기본 체크 상태 후 Next> 2-6) Next> 2-7) Git에서 사용할 기본 에디터를 선택 한 후 Next> 2-8) 환경변수 관련 설정 그래로 두고 Next> 2-9) Next> 2-10) 줄넘김(CR, LF) 문자 관련 설정 Next> 2-11) Next> 2-12) Install 2-13) 설치진행 2-14) 설치완료 Finish 2-15) 시작 메뉴에서 Git bash를 실행 2-16) 아래와 같이 보이면 설치 성공 3) 리눅스에서 설치 3-1) 리눅스는 간단한 명령어를 통해 설치가 가능하다. yum이 지원되는 리눅스 배포판(Fedora, CentOS 등)의 경우는 다음과 같이 설치합니다. $ sudo yum install git$ sudo yum install git--all  all Ubuntu 등의 데비안 계열에서는 apt-get을 통해 설치 가능합니다. $ sudo apt-get install gi...
자세한 내용 보기

Anaconda-Python 환경 VSCode에서 사용하기

-
이미지
VSCode에서 Anaconda-Python 환경 구축하기 1) Anaconda 및 Visual Studio Code는 이미 설치되었다 가정  2) Command Palette (Ctrl+Shift+P) 에서 "Python:Select Interpreter"르 선택 3) Python:Select Interpreter 선택 후 아래와 같이 사용 환경을 선택한다. 3-1) 설치한 Anaconda 버전 (필자는 5.1설치)은 기본으로 선택 할 수 있으며 Anaconda Prompt(Terminal)에서 미리 만들어둔 커스텀환경(Python 3.6.1)을 선택 할 수 있다. 3-2) 아나콘다 커스텀환경설정 아나콘다 환경 구축을 위한 명령어는 다음과 같다. 새로운 환경생성 : >conda create --name 환경명 python=3.6.1 환경 활성화하기: >activate 환경명 환경 비활성화하기 : >deactive 환경명 * Activation 시 permission denied가 뜬다면, 아래와 같이 입력한다. > source Anaconda설치경로/bin/activate 환경명 현재 구축된 환경 확인 : >conda info --envs 환경 구축 후 Anaconda설치경로/envs 경로에서 생성된 환경을 확인 할 수 있다. 4)Python 윈도우 환경변수 구성 4-1)커스텀 환경을 사용하거나 Anaconda 기본환경을 사용시 설치된 python경로를 환경변수에 설정한다.  - 버전이 변경된 Python 환경사용이 경로를 용이하게 변경하기 위해 PYTHON_HOME 변수 추가  - %PYTHON_HOME%경로 Path에 추가 5) VSCode 터미널에서 Anaconda prompt 사용설정 5-1) Anaconda Prompt 설정 페이지의 바로가기 항목 중 대상에 등록...
자세한 내용 보기