[45일 차] 21.09.24 : AWS 5

ALB, NLB, Route 53

---

1교시

 

 

실습 : ALB와 NLB를 통한 부하 분산

강의자료 75페이지

ELB 실습 구성

구성 요소들

보안 그룹에서 SNMP 설정은 사용자 지정 UDP/161번 포트로 추가하면 된다.

---

2교시

 

 

SNMP 설명은 

https://engineer-mole.tistory.com/138?category=911426 

[네트워크/Linux] SNMP와 snmpget, snmpwalk 명령어

여기를 다시 보면 될 것 같다. 

 

ELB 인스턴스들에 sudo yum -y install로 net-snmp-utils, net-snmp, tcpdump 패키지 설치

My 인스턴스에는 net-snmp-utils 패키지 설치

polling 방식으로 정보를 받아오니 161번 포트만 사용.

 

패키지 설치 후 service snmpd start

 

snmpget -v2c -c public [IP 주소] 1.3.6.1.2.1.1.5.0

-> 맨 뒤 숫자는 OID

 

---

3교시

 

 

EC2 좌측 목록의 로드밸런서 > LB 생성 > ALB > 이름 작성, Network mapping 탭에 VPC 선택(ELB-VPC), 서브넷 2개 선택

-> 묶을 인스턴스들은 다른 가용 영역에 있어야 한다.

대상 그룹 생성하기 > 이름 작성, VPC 선택, 나머지는 그대로 두고 헬스 체크는 기본값으로, 다음 > 인스턴스 타겟에 등록 > 생성

상태 검사 항목 설명

다시 ALB 생성으로 돌아가서, 보안 그룹은 만들어 놨던 것 선택 > Listener and routing은 http, 만들어 놓은 타겟 그룹 지정 후 생성

-> 리스너 설정 : 서비스하고자 하는 프로토콜과 포트 지정

만든 ALB의 DNS로 접속해 보면 등록한 인스턴스들의 웹 페이지가 분산되어 나온다.

도메인을 등록하고, 도메인에 등록된 주소가 ALB의 주소라면 부하 분산 완료.

 

그런데 특정 인스턴스에만 있는 페이지에 들어가려면?

-> 그대로 ALB의 주소/경로 이렇게 접속하면 에러 발생(Not Found).

-> 그럼 특정 페이지를 찾을 때에는 해당 페이지를 가진 인스턴스에만 접속하게 할 수 있을까?

-> 특정 URL이 들어오면 특정 인스턴스로 접속시키기 : ALB는 7 계층 작업으로 가능. NLB는 불가능.

 

/dev/index.html은 2번 인스턴스로

/mgt/index.html은 1번 인스턴스로 

-> 대상 그룹을 분리하자.

 

대상 그룹 생성 > 이름 작성, VPC 선택 후 다음, dev가 있는 장비를 대상으로 등록 후 생성

같은 방식으로 mgt 대상 그룹도 생성

-> ALB에서 지원하는 경로 기반 라우팅을 사용할 예정.

 

만들었던 ALB > 리스너 탭 > 리스너 체크 후 규칙 보기/편집 > 상단의 + 클릭, 규칙 삽입 > 조건은 '경로', 값은 /dev/* > 작업은 전달 대상 선택 후 Dev-group 선택

mgt도 동일하게.

 

이제 ALB 도메인의 해당 경로들로 반복해서 접속해도 Not Found가 뜨지 않는다.

---

4교시

 

 

이번엔 NLB를 만들어 보자. NLB는 경로값 기준 라우팅을 할 수 없다.

대상 그룹을 미리 만들자. 프로토콜은 UDP, 포트는 161번이라는 것 외에는 동일. 헬스 체크는 http, 다음 > 대상으로 2개 인스턴스 등록 후 생성

VL 생성 > NLB > 이름 작성, VPC 선택, 가용 영역(서브넷) 선택 > 리스너 규칙은 UDP 161번 포트, 방금 만든 대상 그룹 선택 > 생성

 

앗, 헬스 체크 에러났다.

헬스 체크 수정 > 고급 설정 > 포트 오버라이드로 체크, 80번 포트

-> 헬스 체크 프로토콜은 http인데 161번 포트로 보내니 응답이 안오는 것.

-> 실제 트래픽이 들어가는 포트로 헬스체크하다보니 이런 일이 발생하는 것.

-> 헬스체크용 프로토콜과 실제 사용 프로토콜이 다를 경우 이렇게 설정해줘야 한다.

 

이제 테스트해보자. NLB 로드 밸런서의 DNS 주소로 접속해보자.

snmpget -v2c -c public [NLB DNS 주소] 1.3.6.1.2.1.1.5.0 여러 번 실행해서 결과 확인

-> 2개 인스턴스가 번갈아가며 나온다.

 

인스턴스 하나를 중지시켜 장애를 일으켜 보자.

-> 대상 그룹으로 가보면 헬스 체크에서 Unused로 나온다(중지시켰으니까).

-> ALB는 당연히 중지되지 않은 인스턴스로만 응답할 것이다.

-> 중지된 인스턴스의 특정 경로로 접근하는 것은 당연히 뜨지 않을 것이고.

-> 위 snmpget 명령어 결과도 켜져있는 인스턴스로만 응답이 뜰 것이다.

 

실습 끝. 다음은 도메인 서비스를 할 예정이니 만들었던 서비스들 삭제.

---

5교시

 

 

도메인을 등록해 사용해 보자.

 

• DNS 서버 분류

1. DNS 해석기(Resolver)

클라이언트와 네임 서버의 중계자 역할. DNS 요청을 네임 서버로 전달하며, DNS 응답을 클라이언트에게 전달

 

2. Root Name Server

DNS 서버의 최상위 네임 서버. DNS 해석기에서부터 발생한 DNS 요청에 대해 적절한 TLD 네임서버 정보를 반환

 

3. Top Level Domain Name Server(TLD)

.com이나 .net과 같은 최상위 도메인에 대한 네임 서버. 해당 영역에 포함되는 모든 도메인 이름의 정보를 유지한다. DNS 요청에 대해 TLD 네임서버에서 권한 있는 네임 서버를 지정하여 반환한다.

 

4. Authoritative Name Server(권한 있는 네임 서버)

DNS 해석기가 TLD 네임서버로부터 응답을 받으면, 확인자는 해당 응답을 권한 있는 네임서버로 보낸다. 일반적으로 권한 있는 네임 서버는 요청하는 도메인 주소에 대한 IP 주소를 확인하는 마지막 단계다.

 

 

Route 53은 AWS에서 제공하는 관리형 DNS 서비스.

-> 사용자는 AWS 상의 이 서비스를 통해 도메인 이름 구매를 대행하고, 구매한 도메인 주소에 대한 호스팅 영역을 생성하여 네임서버를 구축하고, 레코드를 생성하여 DNS 요청에 대한 응답을 처리할 수 있다.

-> 다양한 라우팅 정책을 수립하여 효율적 트래픽 흐름을 보장받을 수 있다.

-> 인스턴스로 직접 DNS 서버를 구성하는 것보다는 비용이 더 많이 발생한다.

 

• Route 53 개요

1. 도메인 이름 등록

이 서비스를 통해 도메인 이름을 등록할 수 있다. 이때 Route 53의 역할은 등록 대행소가 되어 등록소인 TLD 네임 서버에 전파하여 해당 도메인 이름을 사용할 수 있도록 대행한다.

 

2. 호스팅 영역

DNS 관리를 할 수 있는 호스팅 영역을 생성할 수 있다. 기본적으로 Route 53을 통해 도메인 이름을 등록하면 자동으로 호스팅 영역이 생성된다. 해당 호스팅 영역이 생성되면 네임 서버가 생성되어 DNS 요청에 대한 DNS 응답을 반환한다.

 

3. 레코드

생성한 호스팅 영역에 레코드를 작성할 수 있다. 레코드 유형에 따른 값을 입력하여 유지한다. 해당 레코드를 생성할 때에는 다양한 라우팅 정책을 수립할 수 있다.

 

 

• Route 53 라우팅 정책

1. 단순 라우팅(Simple Routing)

도메인에 대해 특정 하나의 리소스를 지정한다. 레코드에 대한 값은 여러 개를 입력 가능하지만, 이 중에 하나의 값만 랜덤하게 응답한다.

 

2. 가중치 기반 라우팅(Weighted Routing)

도메인에 대해 다수의 리소스를 지정하고 값에 대한 비중을 두고 라우팅을 한다. 가중치 값은 0~255 사이로 설정하며, [대상 가중치 / 전체 가중치 합]을 통해 비중을 부여한다. 가중치 값이 0이면 DNS 응답을 하지 않는다.

 

3. 지연 시간 기반 라우팅(Latency Routing)

여러 AWS 리전에 리소스가 있고 최상의 지연 시간을 제공하는 리전으로 라우팅한다. Route 53에서 사용자 위치 상 인접한 리전과 리소스가 있는 리전과의 지연 시간을 파악 후 가장 짧은 지연 대상으로 전달한다.

 

4. 장애 조치 라우팅 정책(Failover Routing)

액티브/패시브 장애 조치를 구성하려는 경우에 사용. 레코드 값 중 액티브를 지정하고 대상으로 라우팅을 하며, 주기적인 상태 확인을 통해 액티브 리소스가 통시닝 불가할 경우 패시브 대상을 액티브 대상으로 변경하여 해당 경로로 라우팅한다.

 

5. 지리 위치 라우팅(Geolocation Routing)

DNS 질의를 하는 사용자의 로컬 DNS 서버의 IP 위치에 기반해 가장 인접한 리전의 리소스 대상으로 라우팅을 한다. 

예를 들어, 한국에 위치하는 DNS 서버를 사용하는 사용자는 한국과 인접한 리전에 속한 리소스로 라우팅한다.

(서울 리전 리소스 vs 런던 리전 리소스 -> 서울 리전 리소스로 라우팅)

 

6. 지리 근접 라우팅(Geoproximity Routing)

지리 위치 라우팅과 동일한 형태의 라우팅 기법을 가지고 있으며, 바이어스라는 값을 조정하여 근접 영역의 영향도를 조절한다.

 

7. 다중값 응답 라우팅(Multi-value Answer Routing)

Route 53이 DNS 쿼리에 대해 다수의 값을 반환하도록 구성하는 라우팅 방식

 

 

• Route 53 주요 기능

1. 도메인 등록

도메인 이름 등록 서비스를 제공한다. 이 서비스를 통해 사용 가능한 도메인 이름을 검색하고 등록하거나 Route 53에서 관리하도록 기존 도메인 이름을 전송할 수 있다.

 

2. 상태 확인 및 모니터링

다양한 리소스의 상태와 성능과 지표를 모니터링할 수 있다.

 

3. DNS 장애 조치

사이트 중단이 발생하지 않도록 사용자에게 대체 가능한 경로로 자동 라우팅한다. 주기적인 Health Check를 통해 정상적인 서비스를 구분한다.

 

4. 라우팅 정책

다양한 라우팅 정책을 제공하여 효율적/안정적 라우팅을 유지 가능

 

5. Alias(별칭)

AWS 서비스의 도메인 이름에 대한 별칭을 지정할 수 있는 기능.

 

6. Route 53 Resolver

조건부 전달 규칙 및 DNS 엔드포인트를 생성하여 Route 53 프라이빗 호스팅 영역/온프레미스 DNS 서버에서 제어되는 사용자 지정 이름을 확인 가능.

 

7. VPC용 프라이빗 DNS

DNS 데이터를 퍼블릭 인터넷에 노출하지 않고 내부 AWS 리소스에 대한 사용자 지정 도메인 이름을 관리

 

 

 

Route 53 + 부하 분산

1. 도메인 이름 생성

   1-1. Route 53을 도메인 등록 대행소로 활용 : Route 53이 등록 대행자가 되어 도메인을 생성/등록. 과금 발생

   1-2. 무료 DNS 제공 사이트를 도메인 등록 대행소로 활용 : 무료 DNS 서비스를 제공하는 freenom이라는 사이트 활용.

2. 도메인 이름 등록

사용할 도메인을 입력하고 사용 가능한지 확인해 보자.

---

6~7교시

 

 

사용 가능한 도메인 중 무료 도메인을 하나 골라 사용하자.

abc라는 이름을 사용 가능하고, .ga가 사용 가능하다고 떴으면 abc.ga로 다시 사용 가능을 검색하면 해당 도메인을 받을 수 있다. 여러모로 사용할 곳이 많으니 넉넉하게 12개월로 잡았다. 그 다음은 이메일 인증을 거치면 설정을 할 수 있다.

정보 입력 후 가입 > 상단의 services > my domains로 가보면 내가 받은 도메인이 활성화된 것을 볼 수 있다.

 

지금 만든 도메인의 TLD의 네임 서버는 freenom이다. 이제 등록을 하자.

AWS 서비스 목록에서 Route 53을 찾아 들어간다.

좌측 목록의 호스팅 영역 > 호스팅 영역 생성 > 도메인 이름은 방금 생성한 도메인을 작성, 이번에는 퍼블릭 호스팅 영역으로 선택하고 생성

기본적으로 2개의 레코드가 생긴다. 여기서 NS 레코드의 네임 서버들을 볼 수 있다.

이 네임 서버들을 freenom > Services > My domains에 있는 내 도메인의 우측에 있는 Manage Domain 클릭 > Management Tools 탭 > Nameservers > Use custom nameservers 체크 > 적어놨던 NS 레코드 네임 서버들 작성 후 Change Nameservers 클릭

 

 

실습 기본 환경을 구성해보자.

-> ALB가 있는 웹 서버 인스턴스 2개 + VPC

 

기본 환경으로는 ALB DNS 주소로 접속해야 한다. 너무 길어서 불편하다.

만들어놓은 도메인으로 연결해 보자 : Alias 기능, 라우팅 정책, DNS 장애 조치

 

Route 53 > 호스팅 영역 > 만들었던 것 체크 후 세부 정보 > 레코드 생성 > (라우팅 정책 선택 안뜨면 마법사 전환) 단순 라우팅 > 단순 레코드 정의 > 도메인 이름은 alb.~ > 레코드 유형은 A, 엔드포인트 선택은 Application/Classic Load Balancer에 대한 별칭, 리전은 서울, 거기에 만들었던 LB 선택하면 완료 > 레코드 생성

A 타입으로 생성해서 내부적으로 IP가 바뀌어도 작동한다

 

엥? ping 테스트는 응답하는데, PC에서 접속하면 안들어가진다.

-> SK, KT에서 .tk .ml .ga를 막은 것 같다고 한다. 

https://gocoder.tistory.com/1676

도메인 - .tk, .ml, .ga 한국에서 접속 되지 않는 현상 / 접속하는 방법

운도 지지리도 없네. 고른게 하필....

 

아잇 기껏 .cf로 바꿨더니 얘도 똑같네

---

8교시

 

 

장애 조치 라우팅 

연결된 인스턴스 중 하나에 장애가 발생할 때 사용에 문제가 생기지 않게 하는 것. 

 

Route 53 > 좌측 목록의 상태 검사 > 상태 검사 생성 > 이름 작성, 모니터링 대상은 엔드포인트, 엔드포인트 모니터링 내용 입력(엔드포인트 지정 기준은 IP 주소, 프로토콜은 http, IP 주소는 인스턴스 1의 주소 입력, 호스트 이름은 넘어가고, 포트는 80, 경로는 index.html) 후, 고급 구성은 냅두고 다음 > 경보 생성은 아니오 체크 후 상태 검사 생성

인스턴스 2의 주소를 입력한 것으로 하나 더 생성

 

기다려보면 상태가 모니터링된다.

이런 기능은 ALB에서도 할 수 있었지만, Route 53에서도 할 수 있다는 것을 알아둘 것.

 

이제 레코드 추가해보자.

호스팅 영역 > 레코드 생성 > 라우팅 정책은 '장애 조치' > 레코드 이름은 www, 레코드 유형은 A, 장애 조치 레코드 정의 클릭 > 엔드포인트는 '레코드 유형에 따른 IP 주소 또는 다른 값', IP 주소는 인스턴스 1(Primary)의 주소 넣고, 장애 조치 레코드 유형은 기본, 상태 검사는 Primary-Check(인스턴스 1번으로 만든 상태 검사), 레코드 ID 작성 > 완성

인스턴스 2는 보조로 바꿔서 정의

이제 레코드 생성

 

-> 이제 www.로 등록했던 도메인으로 들어가보면 계속 인스턴스 1(Primary)가 응답한다. 

-> 이러다 인스턴스 1을 중지시키면? : Primary 상태 검사는 비정상으로 뜨고, 인스턴스 2가 응답

-> 다시 인스턴스 1을 가동시키면? : 탄력적 IP를 안썼으니 인스턴스의 IP가 바뀐다. 다시 응답 못함

---

아잇 싯팔 그동안 왜 ping 안먹히나 했더니 보안 그룹에서 ICMP 허용을 안해놨었네

 

2교시 초반 SNMP 설명