CloudFront, CDN, Global Accelerator
1교시
오늘은 CloudFront부터. 중요!
- CDN(Contents Delivery Network)
콘텐츠 제공자와 사용자 간 지리적으로 떨어져 있는 환경에서 콘텐츠를 빠르게 제공하기 위한 기술
- CloudFront
AWS에서 사용하는 CDN 기능. 원래 대상의 컨텐츠를콘텐츠를 캐싱하여 짧은 지연 시간과 빠른 전송 속도로 전 세계 사용자에게 콘텐츠를 전송하는 CDN 서비스.
이래저래 복잡하게 느낄 수 있지만, 간단하게 생각하자. 매번 오리진 <-> 사용자 간 통신을 하면 오래 걸리는 경우에 대해, CDN 노드(에지 POP)를 둬서 캐싱 기능을 사용한다고 생각하면 된다.
-> 서비스 범위에 따라 적절한 경우에 사용해야 한다.
- CloudFront 주요 기능
- CloudFront 글로벌 엣지 네트워크 : 더 짧은 지연 시간으로 콘텐츠를 전달하기 위해 전 세계 수많은 도시에 네트워크를 운영 중이다.
- 정적/동적 컨텐츠 딜리버리 : 콘텐츠의 성격에 따라 캐시 동작을 최적화하여 제공
- 오리진 Selection : 단일 배포에서 여러 오리진을 구성하여 콘텐츠를 처리할 수 있다. 경로 패턴을 분석해 오리진 대상의 콘텐츠를 분석 가능
- 오리진 그룹을 통한 Failover(장애 처리) : 오리진 그룹 내에 기본 오리진과 보조 오리진을 구성하여 기본 오리진에서 응답을 못하면 자동으로 보조 오리진으로 전환, Failover 유지
- SSL 지원 : 컨텐츠에 대해 SSL/TLS 전송 가능. 고급 SSL 기능을 자동으로 활성화 가능
- 접근 제어 : 서명된 URL/쿠키를 사용하면 토큰 인증을 지원하여, 인증된 최종 사용자만 접근 가능하도록 할 수 있다.
- 보안 : 여러 유형의 공격에 대해 유연한 계층형 보안 방어를 구축하기 위해 원활하게 통합 운영
(AWS WAF(Web Application Firewall) 사용)
- 비용 효율성 : 사용한 만큼 지불하는 일반 요금 + 약정 트래픽 개별 요금이 제공됨. AWS 클라우드 서비스와 오리진에서 CloudFront 간의 무료 데이터 전송이 가능
어떤 서비스를 고객이 요구할 때, 어떤 기능으로 요구를 만족시킬 것인가?
- 실습
기본 인프라 구성과 CloudFront 설정만 하면 된다. 나머지는 알아서 해준다.
1. 상파울루 리전에 VPC/인프라 구축 후 응답/지연 속도 확인
2. Route 53으로 호스팅 영역 생성 - balbox.cf를 오리진 도메인으로 사용, A 레코드로 인스턴스 공인 IP 등록
wget -P /var/www/html/ https://cloudneta.github.io/test.jpg
echo "<head><link rel='icon' href='data:;base64,iVBORw0KGgo='></head><h1>CloudNet@ CloudFront Test!!</h1><img src='test.jpg'>" > /var/www/html/index.html
-> 지연 시간을 확인해야 하니 웹 페이지에 용량이 좀 있는 컨텐츠를 업로드
이후 F12 > Network 탭에서 페이지 로드에 걸리는 시간 확인
3~4교시
그냥 해보니 로딩이 끝나기까지 대충 3분 정도 걸린다. 이제 CloudFront 설정을 해보자.
그전에, SSL 인증을 위한 인증 키를 만들자.
우선 리전을 버지니아 북부로 전환(특정 리전에서만 가능한 서비스가 있다) > 서비스에서 Cerificate Manager(ACM) 검색해서 들어간다 > 인증서 프로비저닝 시작하기 클릭 > 공인 인증서 요청 체크 후 인증서 요청 > 도메인 이름은 *.balbox.cf, 검증 방법은 DNS > 쭉 넘겨서 확인 및 요청 > 검증의 도메인 탭 확장해서 Route 53에서 레코드 생성 클릭 > 계속
이제 Route 53에 가보면 레코드가 추가되어 있다.
CloudFront > CloudFront 배포(Distribution) 생성 > 원본(오리진) 도메인은 만들었던 인스턴스의 퍼블릭 IPv4 DNS를 넣는다.
(※ 이제 별 말 없으면 VPC 생성 시 DNS 호스트 이름 편집, DNS 확인 편집 들어가서 활성화)
> 프로토콜은 HTTP만 해당, 나머지 쭉 넘기고 > 기본 경로를 사용할 예정이니 원본 경로는 넘어간다
위 부분은 원본(오리진) 섹션. 그 아래는 기본 캐시 동작 섹션. 기본값 그대로 두고 넘어간다. 함수 연결도 그냥 넘어간다.
마지막 설정 섹션에서 배포 관련 설정을 한다.
> 가격 분류는 '모든 엣지 로케이션에서 사용' > AWS WAF 웹 ACL은 따로 설정 안 해놨으니 넘어간다 > 대체 도메인 이름은 cdn.balbox.cf 추가. 클라이언트는 이 주소로 접속하게 될 것이다 > 사용자 정의 SSL 인증서는 아까 만든 것 선택(그 아래는 기본값으로 두고 넘어가자) > 기본값 루트 객체는 콘텐츠 관련 정보. /index.html 작성 > 표준 로깅 끄고, IPv6 켜고 > 배포 생성
세부 정보에서 배포 도메인 이름 복사 > Route 53 레코드 생성 > 라우팅 정책은 단순 라우팅, 레코드 이름은 cdn, 레코드 유형은 A, 대상은 CloudFront 배포에 대한 별칭, 배포 선택은 아까 복사한 것 선택 후 정의
이제 cdn.balbox.cf로 들어가서 아까 balbox.cf로 접속했을 때와 시간을 비교해 보자.
로드에 걸리는 시간이 확 줄었다.
실습이 끝났으면 모두 삭제하기.
+ 네트워크 관리사 실기 대비 짧게 강의
시뮬레이션 15문항(케이블링 + 윈도우서버 + 단답형)
5~6교시
Global Accelerator
로컬 또는 글로벌 사용자를 대상으로 App의 가용성과 성능을 개선하는 서비스. AWS의 글로벌 네트워크를 통해 사용자에서 App으로 이어진 경로를 최적화하여 트래픽의 성능을 개선하는 기술.
기존
App 이용을 위해 수많은 네트워크를 거칠 수 있다.
App을 오가는 경로가 서로 다를 수 있다.
각 hop은 성능에 영향을 주며 위험을 초래할 수 있다
적용 후
위와 같은 비효율성이 사라진다.
리전 간 통신에서 국가에서 깔아준 회선이 아닌 AWS가 구축해 놓은 전용 회선을 이용하는 것이다.
-> 여러 로컬 네트워크를 왔다갔다하지 않고 직행 경로로 한 번에.
Global Accelerator 주요 기능
- 고정 애니캐스트 IP : 진입점 역할을 하는 2개의 고정 IP 주소를 제공하며, 해당 주소는 에지 로케이션의 애니캐스트를 여러 에지 로케이션에서 동시에 공개한다. 연결되는 엔드포인트의 앞단 인터페이스 역할을 한다.
- 트래픽 제어 : 트래픽 다이얼 리전
- 엔드포인트 상태 확인
- 클라이언트 IP 보존
- 모니터링
실습 기본 환경 구축
고정 Anycast IP를 제공하여 사용자 입장에서 고정 IP 주소로 접근이 가능하며, AWS 글로벌 네트워크를 경유하여 안정적이고 빠른 서비스가 가능
여기에서의 엔드포인트는 해당 장비를 식별할 수 있는 것을 의미.
Global Accelerator는 특정 리전에서만 만들 수 있다.
서비스에서 Global Accelerator를 찾아 들어가서 생성하기
1단계 : 이름 설정
-> 이름 작성, 타입은 Standard, 나머지는 기본값 그대로
2단계 : 리스너 설정/추가
-> 웹 서비스를 테스트하니 포트는 80번, 프로토콜은 TCP, 클라이언트는 None
3단계 : 엔드포인트 그룹 추가
-> 대표적인 엔드포인트 그룹은 리전.
-> 시드니 리전 선택, 트래픽 다이얼은 기본값으로
-> 엔드포인트 그룹 추가 : 상파울로 리전 선택
4단계 : 엔드포인트 그룹에 엔드포인트 추가
-> 추가한 2개의 엔드포인트 그룹에 엔드포인트 추가
-> 시드니쪽 : 타입은 ALB, 엔드포인트는 아까 만든 ALB 선택, 가중치는 기본값으로 둔다
-> 상파울로쪽 : 타입은 EC2, 엔드포인트는 아까 만든 EC2 인스턴스로 해서 2개 추가
이제 생성!
7교시
생성 완료. 확인해 보자.
서울 리전과 버지니아 리전에 만든 인스턴스에서 시드니/상파울루 웹 서버로 접속해보자.
만든 GA의 상세 정보를 보면, Static IP address set에서 IP 주소를 볼 수 있다.
시드니/상파울루 인스턴스 4개가 모두 같은 회사의 다른 서비스 지점이라고 가정하고, 서울과 버지니아 쪽에서 위 애니캐스트 주소로 접속
-> 서울에서는 시드니가 가까우니 시드니 웹 서버에 접속돼야 하고, 버지니아에서는 상파울루가 가까우니 상파울루 웹 서버에 접속되어야 한다.
for i in {1..100}; do curl -s -q AnycastIP; done | sort | uniq -c | sort -nr
-> 이 명령어로 서울/버지니아에서 실행해서 어디로 접속하는지 확인할 수 있다.
-> 서울은 시드니 인스턴스 1, 2에만 50번씩 접속, 버지니아는 상파울루 인스턴스 1, 2에만 비슷하게 접속
이 외에도 sudo traceroute -T IP주소 명령을 실행해 보면 시간이나 거쳐가는 장비를 확인할 수 있다.
-> 애니캐스트 IP와 인스턴스의 퍼블릭 IP로 비교해 보면 확연히 차이난다.
Global Accelerator로 돌아와서, 다른 실습도 해보자.
-> Traffic Dial : 트래픽 조절하기. 그룹에 전달되는 비율을 설정할 수 있다.
-> 현재 서울 무조건 시드니, 버지니아는 무조건 상파울루로 간다. 이걸 조정해 보자.
GA 세부 정보 > 리스너 항목 > 만든 리스너 클릭 > 엔드포인트 그룹의 트래픽 다이얼이 100이다.
시드니 쪽 엔드포인트 체크 후 edit > traffic dial 50으로 변경 후 저장
-> 위에서 했던 for문을 다시 실행해 보면 아예 접속하지 않던 상파울루 인스턴스에 접속하는 것을 볼 수 있다. 비율은 50:50
시드니 쪽 트래픽 다이얼을 0으로 조절하면?
-> 시드니 인스턴스로 아예 접속하지 않는다. 상파울루 인스턴스로만 접속
고객에게 Route 53에서 했듯이 도메인으로 애니캐스트 IP를 연결하면 깔끔.
8교시
이번엔 엔드포인트에서의 Weight 조절 테스트.
기본값 128, 범위 0~255
최종 비중은 자신의 Weight / 전체 Weight
이번에도 리스너로 들어가서, 상파울로 엔드포인트로 들어가자. 시드니 쪽은 ALB라 조절을 통한 비교가 어렵다.
인스턴스 하나를 선택하고 edit > weight를 128에서 64로 조절
-> 버지니아 쪽에서 for 실행문으로 확인해보자 : 접속 빈도가 조정되었다. weight를 낮춘 인스턴스로의 접속 빈도가 적어졌다.
weight를 0으로 조정하면 그쪽 인스턴스로는 접속 X
이번에는 Failover 기능 확인 실습
시드니 엔드포인트로 가야 하는데, 시드니 엔드포인트 그룹의 인스턴스 2개가 망가졌다고 가정해 보자.
-> 트래픽 다이얼만 보고 찾아왔는 데 사용을 못하는 상황이 발생할까?
시드니 인스턴스 2개 중지(ALB는 IP 주소를 등록한 것이 아니라서 다시 켰을때 변경사항 없음)
> Global Acclerator로 와보면 문제가 생겼음이 뜬다.
> 따로 할 건 없다. 서울에서 다시 접속해보면 자동으로 상파울루 인스턴스로 접속한다.
다시 시드니 인스턴스를 켜보자.
> 시드니 리전에서 만든 ALB 타깃 그룹에서 헬스 체크가 정상적으로 작동하는 것을 확인 후 다시 접속해 보자.
※ 시드니 인스턴스에서 httpd 서비스를 enable 시켜놔야 인스턴스 재가동 시 헬스 체크가 다시 작동할 것이다.
Global Accelerator는 엄밀히 캐싱 기능을 사용하는 것이 아니다.
애니캐스트를 사용, AWS 글로벌 네트워크를 통해(전용 회선을 통해) 통신하는 것.
Global Accelerator 삭제하기
> 체크 후 Delete > Disable 하고 대기 후 delete
딱히 다시 들을 부분은 없지만, 시간이 난다면 듣고.
'교육' 카테고리의 다른 글
| [49일 차] 21.09.30 : AWS 9 (0) | 2021.09.30 |
|---|---|
| [48일 차] 21.09.29 : AWS 8 (0) | 2021.09.29 |
| [46일 차] 21.09.27 : AWS 6 (0) | 2021.09.27 |
| [45일 차] 21.09.24 : AWS 5 (0) | 2021.09.24 |
| [44일 차] 21.09.23 : AWS 4 (0) | 2021.09.23 |
댓글