- Elastic Load Balancer는
애플리케이션에 사용 가능한 정적 DNS 이름을 제공합니다.
- Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 때마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요 ?
- A. 웹사이트가 다수의 EC2 인스턴스에서 호스팅되어 문제가 발생함
- B. IP 주소를 확인할 수 없기 때문에 EC2 인스턴스가 사용자들을 로그아웃 시키고 그대신 ELB IP 주소를 받은 것
C. Elastic Load Balancer가 고정 세션을 활성화하지 않은 것
✅ ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트 되도록 해줍니다. 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줍니다.
- Application Load Balancer를 사용해 EC2 인스턴스에서 호스팅된 웹사이트의 트래픽을 분배하고 있습니다. 그런데 여러분의 웹사이트가 Application Load Balancer의 IP 주소인 사설 IPv4 주소에서 들어오는 트래픽만을 확인하고 있는 것으로 나타났습니다. 이런 경우, 웹사이트로 연결된 클라이언트들의 IP 주소를 받으려면 어떻게 해야 할까요 ?
- A. 웹사이트의 프로트엔드를 수정해 사용자들이 모든 요청에서 자신의 IP를 보낼 수 있도록 만들기
B. 웹사이트의 백엔드를 수정해 X-Forwarded-For 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기- C. 웹사이트의 백엔드를 수정해 X-Forwarded-Port 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기
- D. 웹사이트의 백엔드를 수정해 X-Forwarded-Proto 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기
✅ Application Load Balancer를 사용하여 EC2 인스턴스에 트래픽을 배분하는 경우, 요청을 받게 되는 IP 주소는 ALB의 사설 IP 주소가 됩니다. 클라이언트의 IP 주소를 받기 위해, ALB는 클라이언트의 IP 주소를 포함하고 있는 X-Forwarded-For라는 헤더를 추가합니다.
- Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?
A. ELB 상태 확인 활성화- B. ELB 고착도 활성화
- C. SSL 종료 활성화
- D. 영역간 로드 밸런싱 활성화
✅ ELB 상태 확인을 활성화하면, ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됩니다.
- 어떤 기업에서 솔루션 아키텍트로 근무하고 있는 여러분은 1초에 수백만 개의 요청을 받게 될 고성능의, 그리고 지연 시간이 적은 애플리케이션을 위한 아키텍처를 설계해달라는 요청을 받았습니다. 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요 ?
- A. Application Load Balancer
- B. Classic Load Balancer
C. Network Load Balancer
✅ Network Load Balancer는 애플리케이션이 필요로 할 경우 가장 높은 성능과 가장 낮은 지연 시간을 제공합니다.
- Application Load Balancer가 지원하지 않는 프로토콜을 고르세요.
- A. HTTP
- B. HTTPS
C. TCP- D. WebSocket
✅ Network Load Balancer는 TCP와 UDP 프로토콜을 모두 지원합니다.
- Application Load Balancer는 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다. 이때 확인할 내용으로 사용할 수 없는 것을 고르세요.
A. 클라이언트의 위치(지리적)- B. 호스트 이름
- C. 요청 URL 경로
- D. 소스 IP 주소
✅ ALB는 URL 경로, 호스트 이름, HTTP 헤더 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다.
- Application Load Balancer의 대상 그룹에 등록될 수 없는 대상을 고르세요.
- A. EC2 인스턴스
B. Network Load Balancer (NLB)- C. 사설 IP 주소
- D. Lambda 함수
- 규정 준수를 위해 고정된 정적 IP 주소를 최종 사용자에게 노출하여 사용자들이 안정적이고 규제 기관의 승인을 받은 방화벽 규칙을 작성할 수 있도록 하려 합니다. 이런 경우, 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요 ?
- A. 탄력적 IP가 연결된 Application Load Balancer
B. Network Load Balancer (NLB)- C. Classic Load Balancer (CLB)
✅ Network Load Balancer는 AZ당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있습니다. Application Load Balancer와 Classic Load Balancer를 정적 DNS 이름으로 사용할 수 있습니다.
- Application Load Balancer 내에 사용자 지정 애플리케이션 기반 쿠키를 생성하려 합니다. 다음 중 쿠키의 이름으로 사용 가능한 것은 무엇인가요 ?
- A. AWSALBAPP
- B. APPUSERC - C. AWSALBTG
- D. AWSALB
- us-east-1에 있는 한 세트에 EC2 인스턴스에 트래픽을 분배하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 인스턴스, us-east-1e AZ에는 5개의 인스턴스가 있습니다. 여러분은 us-east-1b AZ에 있는 EC2 인스턴스의 CPU 사용률이 더 높다는 것을 발견했습니다. 조사를 거친 결과, 두 개의 AZ에 걸쳐 분배된 트래픽의 양은 동일한 것으로 나타났습니다. 이 경우 어떻게 문제를 해결해야 할까요 ?
A. 영역간 로드 밸런싱 활성화- B. 고정 세션 활성화
- C. ELB 상태 확인 활성화
- D. SSL 종료 활성화
✅ 영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됩니다.
- 다음 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 Application Load Balancer의 Network Load Balancer의 기능은 무엇인가요 ?
- A. TLS 종료
B. 서버 이름 표시 (SNI)- C. SSL 보안 정책
- D. 호스트 헤더
- 다음과 같은 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 Application Load Balancer가 있습니다. users.example.com, api.external.example.com, checkout.example.com 이 각각의 호스트 이름에 HTTPS를 구성하려 합니다. 이런 작업을 위해서는 ALB를 어떻게 구성해야 할까요 ?
- A. HTTP를 HTTPS로 리다이렉팅 하는 규칙 사용
- B. 보안 그룹 SSL 인증서 사용
C. 서버 이름 표식 (SNI) 사용
✅ 서버 이름 표식(SNI)를 사용하면 동일한 리스너 상에 있는 자체 SSL 인증서를 가진 다수의 HTTPS 애플리케이션을 노출시킬 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의 TLS 인증서를 자동으로 선택합니다.
SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다.
TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.
SNI는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 합니다. 다수의 인증서가 필요한 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.
TLS는 HTTP 아래 단계인 전송 레이어에 속하기 떄문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 "이것이 내가 인증서를 원하는 도메인입니다"라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다.
- 원하는 용량과 최대 용량을 모두 3으로 구성한 오토 스케일링 그룹에 의해 관리되고 있는 한 세트의 EC2 인스턴스에 호스팅된 애플리케이션이 있습니다. 또한, CPU 사용률리 60%에 이르면 ASG를 스케일 아웃하도록 구성된 CloudWatch 경보도 생성해뒀습니다. 해당 어플리케이션은 현재 갑자기 많은 양의 트래픽을 전송 받아 80% CPU 사용률에서 실행되고 있는 상태입니다. 이런 경우, 무슨 일이 일어나게 될까요 ?
A. 아무 일도 일어나지 않음- B. 희망 용령은 4까지 올라가는 반면, 최대 용량은 3에 머뭄
- C. 희망 용량은 4까지 올라가는 반면, 최대 용량은 4에 머뭄
✅ 오토 스케일링 그룹은 스케일 아웃 시, (구성된) 최대 용량을 넘어설 수 없습니다.
- Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요 ?
- A. ASG가 인스턴스는 계속 실행하되, 애플리케이션은 재시작할 것
- B. ASG가 EC2 인스턴스를 분리하고 실행 상태로 둘 것
C. ASG가 EC2 인스턴스를 종료할 것
✅ 오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있습니다. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상적인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행합니다.
- 여러분의 상사가 애플리케이션이 데이터베이스로 보내는 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링하라고 요청했습니다. 어떻게 해야 할까요 ?
A. CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일리앟기 위한 CloudWatch 경보 생성- B. 상세 모니터링을 활성화한 후 ASG 스케일링을 위한 CloudWatch 경보 생성하기
✅ 백엔드-데이터베이스 연겷에는 '분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않습니다. CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 합니다.
- 오토 스케일링 그룹(ASG)에서 관리하는 EC2 인스턴스 플릿이 호스팅하는 웹 애플리케이션이 있습니다. 여러분은 애플리케이션 로드 밸런서(ALB)를 통해 이 애플리케이션을 노출하고 있습니다. EC2 인스턴스와 ALB는 모두 다음 CIDR 192.168.0.0/18을 사용하여 VPC에 배포됩니다. ALB만 포드 80에서 액세스할 수 있도록 EC2 인스턴스의 보안 그룹을 구성하려면 어떻게 해야 할까요 ?
- A. 80 포트와 0.0.0.0/0을 소스로 하는 인바운드 규칙 추가하기
- B. 80 포트와 192.168.0.0/18를 소스로 하는 인바운드 규칙 추가하기
C. 80 포트와 ALB의 보안 그룹을 소스로 하는 인바운드 규칙 작성하기- D. ALB 상의 SSL 인증서 가져오기
- eu-west-2 리전에서 실행되는 오토 스케일링 구성이 있는데, 두 개의 가용 영역인 eu-west-2a와 eu-west-2b를 생성하도록 설정되어 있습니다. 현재 eu-west-2a에는 3개의 인스턴스가 실행 중이며, eu-west-2b에는 4개의 EC2 인스턴스가 실행 중입니다. ASG는 스케일인을 하려고 할 때 이들 중 어떤 EC2 인스턴스가 종료되게 될까요 ?
- A. eu-west-2a 내에 있는 무작위의 EC2 인스턴스
- B. eu-west-2a의 EC2 인스턴스 중 실행 템플릿이 가장 오래된 버전
- C. eu-west-2b 내에 있는 무작위의 EC2 인스턴스
D. eu-west-2b의 EC2 인스턴스 중 실행 템플릿이 가장 오래된 버전
✅ 오토 스케일링 그룹의 기본 종료 정책은 우선 AZ에 걸친 밸런싱을 시도하며, 실행 구성이 오래된 순으로 종료됩니다.
- 애플리케이션은 Application Load Balancer와 오토 스케일링 그룹과 함께 배포됩니다. 현재 ASG를 수동으로 스케일링하고 있는 상태에서, EC2 인스턴스로의 평균 연결의 수를 1,000회 정도로 유지하기 위한 스케일링 정책을 정의하려합니다. 이 중에서 어떤 스케일링 정책을 사용해야 할까요 ?
- A. 단순 스케일링 정책
- B. 단계적 스케일링 정책
C. 대상 추적 정책- D. 예약 스케일링 정책
- 오토 스케일링 그룹이 관리하는 EC2 인스턴스에 호스팅된 애플리케이션으로 들어오는 트래픽이 급격하게 증가하여, ASG가 스케일 아웃되고 새로운 EC2 인스턴스가 실행되게 되었습니다. 트래픽은 계속해서 증가하지만, ASG는 5분이 지나기 전까지는 새로운 EC2 인스턴스를 곧바로 실행하지 않습니다. 이런 경우, 가능성이 있는 원인은 무엇일까요 ?
A. 냉각 기간- B. 수명 주기 후크
- C. 대상 추적 정책
- D. 실행 템플릿
✅ 오토 스케일링 그룹에는 각 스케일링 조치 이후 냉각 기간을 갖습니다. ASG는 냉각 기간 동안 EC2 인스턴스를 실행하거나 종료하지 않습니다. 이를 통해 지표들을 안정화시킬 수 있는 기간을 갖습니다. 냉각 기간의 기본 값은 300초(5분)입니다.
- 지난 달, 어느 기업이 보유한 오토 스케일링 그룹 내의 무작위 EC2 인스턴스가 갑자기 충돌을 일으켰습니다. ASG가 비정상 EC2 인스턴스를 종료하고 이를 새로운 EC2 인스턴스로 대체하고 있는 관계로, EC2 인스턴스가 충돌하게 된 원인을 찾을 수 없는 상태입니다. 이 문제를 해결하고 ASG가 비정상 인스턴스를 종료하는 것을 막기 위해서는 어떤 문제 해결 조치를 취해야 할까요?
- A. AWS Lambda를 사용해 EC2 인스턴스르 종료하기 전에 멈추게 하기
B. 문제 해결을 위해 ASG 수명 주기 후크를 사용하여 EC2 인스턴스를 종료 상태로 멈추게 하기- C. CloudWatch 로그를 사용해 문제를 해결하기
