AWS

aws-dynamic-cloudfront

오늘의 주제는 dynamic cdn / 동적 cloudfront 다.

cloudfront 는 cdn 이다. cdn 이 뭔가?

Contents Delivery Network 컨텐츠를 빠르게 전송하기 위해서 사용자에게 가까운 edge 에서 응답해주는 방식이다. - edge 는 aws에서 말하는 용어이고 보통 pop라고 한다.

많은 지역에 pop이 존재하고 이 pop에선 원본 컨텐츠를 캐싱하여 user에게 전달한다.

구성도로 보자면 다음과 같다.

user 가 네임서버에 domain 에대한 확인을 하고 cf의 위치를 알려주면 user는 가장가까운 pop에 연결된다.

간단하게 확인하려면 f12를 눌러서 cloudfront 의 헤더를 확인해 보면 된다.

https://cdn.linuxer.name/test/iu.jpg

x-amz-cf-pop : ICN50 이부분이 근처의 팝인것이다.

이렇게 정성스럽게 설명하는 이유는 간단하다.

오늘 설정할 부분이 일반적인 CDN의 사용방법이 아니기때문이다.

사이트의 응답속도를 빠르게 하려면 어떻게 해야할까?

많은 방법이 있는데 제일 좋은 방법은 먼저 컨텐츠에 도달하는 속도를 올리는 방법이다. 컨텐츠에 대한 도달속도를 확인하는 방법은 첫번째로

tracert 이다.

테스트하는 도메인의 구성이다.

>tracert 리눅서.com
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 2 ms 3 ms 3 ms 100.127.39.21
4 3 ms 4 ms 2 ms 10.222.41.224
5 3 ms 2 ms 3 ms 10.222.14.73
6 2 ms 2 ms 6 ms 211.210.54.34
7 * * * 요청 시간이 만료되었습니다.
8 * * * 요청 시간이 만료되었습니다.
9 * * * 요청 시간이 만료되었습니다.
10 * * * 요청 시간이 만료되었습니다.
11 4 ms 5 ms 4 ms 52.93.248.221
12 4 ms 3 ms 4 ms 54.239.123.121
13 3 ms 3 ms 3 ms 54.239.122.38

54.239.122.38 IP는 아마존 IP로 아마존 내 네트워크 까지 연결된것을 확인할수 있었다.

그다음 도메인은 cf에 연결된 도메인이다.

>tracert linuxer.name
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 1 ms 3 ms 3 ms 100.127.36.21
4 4 ms 2 ms 2 ms 10.222.41.230
5 2 ms 1 ms 1 ms 10.222.15.91
6 2 ms 3 ms 3 ms 211.210.54.34
7 3 ms 3 ms 3 ms 52.93.248.36
8 3 ms 2 ms 2 ms 52.93.248.83
9 2 ms 2 ms 2 ms 54.239.41.13
10 * * * 요청 시간이 만료되었습니다.
11 * * * 요청 시간이 만료되었습니다.
12 * * * 요청 시간이 만료되었습니다.
13 2 ms 2 ms 2 ms server-54-230-181-122.icn50.r.cloudfront.net [54.230.181.122]
추적을 완료했습니다.

지금 구성에서 linuxer.name 과 리눅서.com 사이트의 동작 자체는 동일하나 리눅서.com은 로드벨런서를 다이렉트로 바라보고 있고 linuxer.name 은 cloudfront 로 연결되어 오리즌을 로드벨런서로 바라보고 있는상태이다.

그럼 라우팅은 정상적으로 cloudfront 쪽이 빠른걸 확인했으니 컨텐츠에 대해 접근이 빠른지 확인해 보려면 어떤방법을 사용해야할까? TTFB와 여러지표를 확인하기로 했다. 웹개발자 도구로 timing을 확인하면정확하게 확인할수 있을거라 생각했다.

ttfb 가 312.65ms 다 그럼 다이렉트로 로드벨런서에 연결된 도메인은 속도가 얼마나 나올까?

ttfb 가 435.53ms 다. 오잉? 생각보다 속도 차이가 있다.

그럼 일단 더테스트하려면...어쩔까..간단하게 해외로 간다!

18353km 떨어진 상파울루 리전의 win ec2 이용하여 테스트 하겠다.

cf가 적용되어있는-linuxer.name

cf가 적용되지 않은 리눅서.com

상황에 따른 응답속도의 차이가 있긴하지만 확실히 dynamic cdn 을 적용한 도메인쪽이 좀더 빨리 떳다.

어느정도 유효한 결과를 확인했다는 뜻이다.

물론 내블로그는 가벼우므로..또르륵

https://aws.amazon.com/ko/cloudfront/dynamic-content/

https://aws.amazon.com/ko/blogs/korea/how-to-improve-dynamic-contents-delievery-using-amazon-cloudfront/

직접 경험해야 하는터라 다하고나니까 문서를 봤다 ㅋㅋㅋ

그래서 이제 어느정도 검증이 끝났고 설정방법이다.

Cache Based on Selected Request Headers -> ALL 로 수정하면 끝이다.

나머지는 자신의 설정대로..잘하면 된다.

끝. 좋은하루 되시라!

2020년 1월 18일 by AWS 0

aws Route53 지역기반 라우팅

route53 지역기반 라우팅(Geolocation)을 이용하여 허용한 지역 이외에는 내 사이트를 열 수 없도록 설정하려고 한다.

근래에 내 블로그가 좀 힘찼다.

잘 관리를 안해서 힘이 없었는데 자꾸 블로그 댓글로 비아그라 광고가 들어왔다..
제길 ㅠㅠ 한30건 정도....

독일쪽 스패머인것으로 보인다.

5.189.131.199

그래서 한국/남아메리카/북아메리카를 제외한 모두를 차단하기로 하였다.

먼저 기본값으로 지역기반 라우팅으로 set ID 1로 203.0.113.1 라우팅한다.

203.0.113.1 IP는

https://tools.ietf.org/html/rfc5737

사용할수 없는 IP로 보인다. RFC5737을 참조하기 바란다. 따라서 특정하지 않는 모든 라우팅은 203.0.113.1 로 연결되도록 설정하였다.

그리고 set ID 2 / 3 /4 는 한국/남아메리카/북아메리카 로 설정하고 로드벨런서와 연결한다.

설정값은 다음과 같다.

설정된 한국/남아메리카/북아메리카 제외한 모든접속은 203.0.113.1 로 연결되어 접속할수 없게 된다.

이후 스패머가 또들어오는지 모니터링 해야겠다.

아! 남아메리카/북아메리카 를 열어 준 이유는 google robots 가 크롤링을 할 수 있도록 허용해줬다. 그래도 구글에서 검색은 되야 하므로....

이상이다. 좋은하루 되시길.!

2019년 12월 30일 by AWS 0

cloudwatch log 매트릭 경보 생성 - log monitoring

오늘의 주제는 인스턴스에서 발생하는 로그를 cloudwatch 로 전송하여 사용하는 법을 포스팅 할거다.

먼저 역할에 정책부터 생성해 보자. 사용하는 정책은 아래와 같다.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}

역할을 인스턴스에 부여하고 인스턴스 내부에서 패키지를 설치해야 한다.

나는 이미 이전에 테스트로 설치해 뒀다.

설치로그이다.

Nov 18 17:17:19 Installed: aws-cli-plugin-cloudwatch-logs-1.4.4-1.amzn2.0.1.noarch
Nov 18 17:17:20 Installed: awslogs-1.1.4-3.amzn2.noarch

실제 설치방법은 yum install 이나 wget 으로 받아 실행하는 방법이 있다.

# yum install awslogs -y

or

# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
# python ./awslogs-agent-setup.py --region ap-northeast-2

리전지정 옵션을 넣어주는게 좋다 그렇지 않으면 따로 지정해야 한다.

# vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-2

그리고 cloudwatch 로 전송할 로그를 지정한다.

# vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

테스트를 위해 /var/log/messages 를 cloudwatch 로 전송하는 로그이다.

log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

세개의 옵션이 중요하다. end_of_file 은 뒤부터 추가되는 로그를 watch 로 전송한다.

amazon linux 2 는 systemctl 명령어로 서비스를 시작한다

# systemctl restart awslogsd

설정대로 로그가 올라 오는게 보인다.

중요한 부분은 이벤트 만료시점을 지정해서 로그로 전송된 용량이 과하게 쌓이지 않도록 해야한다.

로그 그룹을 체크하면 지표 필터 생성 버튼이 활성화 되고 지표를 생성한다.

지표는 대충 만들어 볼까한다.

HealthCheck 라는 이름으로 패턴을 설정했다. 보면 샘플로그에서 일치하는 패턴이 보인다. 그리고 지표를 할당한다.

지표생성은 커스텀 매트릭으로 비용이 발생할수 있으니 조심하도록 하자.

생성된 지표를 확인하면 위와같다. 그럼 지표를 확인해보자.

커스텀메트릭이 정상적으로 만들어진걸 확인할수 있다.

그래프도 잘생성 됬는지 보면 잘 올라오는게 보인다. 그럼 실제 로그가 발생해서 그래프가 생성됬는지 확인해보자.

로그가 올라와서 매트릭이 생성된것을 확인할수 있다. 그럼이제 경보를 생성해 보자.

뭔가 훅지나간거 같겠지만 빠진부분은 sns 설정 뿐이다. SNS는 주제를 만들고 구독을 생성하고 구독으로 watch 에서 sns를 추가하면 된다.

경보생성하는 방법은 따로 자세하게 설명하겠다. 블로깅이 시리즈 물이 될 기미가 보인다.

그래프처럼 임계치를 지나서 경보상태로 변경됬다가 정상으로 업데이트가 되는 과정이 보인다 정상적으로 지표로 경보가 작동하는것 까지 확인 되었다.

오늘의 목표인 로그전송으로 지표생성 후 경보 생성까지 완료되었다.

이케이스는 tomcat log로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.

자세하게 만들고 싶었는데 흐름만 구성한거 같아 좀 찜찜한 부분은 차차 보강하겠다.

읽어주셔 감사하다!

2019년 11월 27일 by AWS Linux 0

AWS ALB 규칙 설정-2

오픈카톡에서 받은 질문이다.

질문을 다시정리하자면

linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com <- 허용하지 않음.

이름: linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com
Addresses: 13.125.124.26
15.164.132.46

13.125.124.26 <- 허용하지 않음
15.164.132.46 <- 허용하지 않음
test.linuxer.name <-허용하지 않음

linuxer.name <- 허용
www.linuxer.name <-허용
리눅서.com <-허용

iptables 마냥 deny 정책 위에 allow 를 올려준다 생각하면 간단하다 그럼 여기에서 필요한건 ALB limit 인것 같다. 왜냐? 룰이 많아 질수도 있으니까.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-limits.html

여러번 공개된 리스너 규칙이다.
80->443으로 연결하고 443리스너는 linuxer-blog-wg 로 전달.. tg인데 왜 wg로 했는지는 아직도 의문이다..생성하면서 졸았나...

규칙을 보면 지난번에 alb 규칙 포스팅에서 셋팅한 그대로다. 그럼 이걸 수정해 줄거다.

route53 에선 따로 전환안해도 먹어서 그냥 입력해봤는데 안먹는다. 퓨니코드로 변환해서 넣자

이제 그럼 https://test.linuxer.com 으로 들어가보자. 503 error 이 그대를 맞이할것이다.

그럼 원하지 않는 문자열이나 쿼리를 503으로 띄우고 싶다면?

먼저

내 IP를 확인했다.

소스 IP로 /wp-admin 을 blackhole 처리를 하고 특정 IP 하나만 열어 주었다.

https://linuxer.name/wp-admin.php

접속해 보시라. 503 error 가 반길것이다.

사실 요즘 admin 페이지로 유입이 있어서 wp-admin 막는거로.. 오늘 fail2ban 포스팅을 하려고 계획했는데 실패했다.

alb에서 막아버려서...

블로깅을 할수있도록 포스팅거리를 주신 이주호님께 감사를 드린다.

좋은하루 되시라!

2019년 11월 11일 by AWS 0

서울-도쿄 리전간 레이턴시 줄이기-실패경험담

페이스북 AKUG에서 다음과 같은 포스팅을 봤다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-global-accelerator-supports-ec2-instance-endpoints/?fbclid=IwAR2spSZzdtmHMDVqYwEpZS8W5pEs86t7SMNArZ2fyT81M55QDoDA1dqKuy4

처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.

EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.

한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.

AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?

그런 궁금증이었다.

엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.

테스트 방식은 총4가지였다

openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

AWS Global Accelerator 셋팅은 아주 간단하다.

Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.

생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.

그럼 테스트로 넘어간다.

가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

C:>tcping.exe -n 100 172.31.26.253 22

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms

가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms

평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.

tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.

ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.

구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.

피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.

피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.

현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.

사실 이때쯤 테스트가 잘못된것을 알았다.

--- 172.29.0.110 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms

vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.

망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.

이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.

다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms

Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..

그래서 한번더 했다.

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms

늘어지네... 39/ 60 / 64

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms

40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.

실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까...
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms

141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms

126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.

한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.

물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.

하지만..여기서 끝내기엔 너무 아쉬웠다. 하.

또 한국리전에 최근에 적용된 기능이 생각났다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-client-vpn-now-available-seoul-canada-central-stockholm-northern-california-regions/?fbclid=IwAR3wIXq6EsYCxAV7FN05mDsmVc_mkQH1EzwVF-wUN8EpxTGB1f1zUiZ0_s8

이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.

하지만 얻게된 aws의 내부 망에 대한 추측이다.

서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.

오늘의 우승 구성은 " openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping " 이다.

오늘은 도쿄에 테스트 했으니까 사요나라!

2019년 11월 2일 by AWS Linux 0