aws-route53-review

요 며칠간 CF관련 이슈로 고민이 많았다.

ipv6 부터 SK LTE까지…

이문제가 발생한 원인은 먼저

SK LTE DNS 에서의 ipv6라우팅이 가장 큰 원인일테고..
같은 cloudfront에서도 발생하는 빈도차가 있었으므로 그 원인을 파악하고 해결하는 법을 서술하려고한다.

먼저 A alias는 ipv4로 라우팅한다. – A record 는 ipv4를 라우팅 하므로..

>linuxer.name
이름: linuxer.name
Addresses: 52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42

그렇다면 alias 를쓰는 사용자는 cf관련 문제를 겪지 않았을 것이다.

Route 53 별칭 레코드는 AWS 리소스와 같은 별칭 대상의 DNS 이름에 내부적으로 매핑됩니다. Route 53은 조정 작업과 소프트웨어 업데이트를 위해 별칭 대상의 DNS 이름과 연결된 IP 주소를 모니터링합니다. Route 53 이름 서버의 신뢰할 수 있는 응답에는 A 레코드(IPv4 주소에 대한 레코드) 또는 AAAA 레코드(IPv6 주소에 대한 레코드)와 별칭 대상의 IP 주소가 포함되어 있습니다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/route-53-create-alias-records/

내용을 확인해 보면 신뢰할수 있는 응답에 ipv4-ipv6를 응답하게 되어있다고 나와있다.

따라서..alias는 문제가 없었다.

그렇다면 문제가 있었을 cf는 무엇일까?

cname 을 사용하던 도메인들이다.

cname을 설정하면 이렇다.

>test2.linuxer.name
서버: UnKnown
Address: 210.219.173.151
권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2150:1a00:10:3683:b8c0:93a1
2600:9000:2150:8000:10:3683:b8c0:93a1
2600:9000:2150:c000:10:3683:b8c0:93a1
2600:9000:2150:6400:10:3683:b8c0:93a1
2600:9000:2150:8c00:10:3683:b8c0:93a1
2600:9000:2150:1000:10:3683:b8c0:93a1
2600:9000:2150:7800:10:3683:b8c0:93a1
2600:9000:2150:e200:10:3683:b8c0:93a1
52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42
Aliases: test2.linuxer.name

ipv6 와 ipv4를 모두응답한다. 이 경우 ipv6가 우선라우팅이 된다.

그래서 결국 route53 공식문서를 확인해보니 A/AAAA를 같이쓰라고 되어있다.

cloudfront 는 cname 을 제공하고 A record를 사용할경우 cloudfront 의 IP변경에 대응할수 없다. 그렇기 때문에 일반적으로 A alias 를 사용하라 한것이다.

명시적인 레코드의 분리를 뜻하는 것이다. 일반적으로 잘 발생하는 문제는 아닌것으로 보이나, cname 을 사용하게되면 이렇다.

일반적으로 도메인에 요청을 할때 레코드를 지정해서 쿼리하진 않는다.
그래서 cname 으로 요청하게되면 cname 에 연결된 모든 record가 응답하게 되고 그 결과 값에 따라서 ipv6 가 존재하면 ipv6 로 라우팅 된다.

nslookup 결과
>test2.linuxer.name
서버: dns.google
Address: 8.8.8.8권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2139:e200:10:3683:b8c0:93a1
2600:9000:2139:fa00:10:3683:b8c0:93a1
2600:9000:2139:4c00:10:3683:b8c0:93a1
2600:9000:2139:7400:10:3683:b8c0:93a1
2600:9000:2139:5400:10:3683:b8c0:93a1
2600:9000:2139:aa00:10:3683:b8c0:93a1
2600:9000:2139:2600:10:3683:b8c0:93a1
2600:9000:2139:6c00:10:3683:b8c0:93a1
99.86.144.35
99.86.144.128
99.86.144.34
99.86.144.126
Aliases: test2.linuxer.name

따라서 route53을 사용할때 A/AAAA를 분리해서 사용하라는 말이다.

그런데 말입니다.

그런데 말입니다에 대한 이미지 검색결과

A레코드는 쓸수 없잖아? cf는 IP가 바뀌니까..

그래서 결론이 난다. 확실하게 정해준다.

A Alias AAAA alias 를 사용하는걸 권장한다.
같은계정내 자원이라면!

아니라면?

cname 을 사용할수 밖에 없다면 CloudFront 의 IPv6 를 끄자.

CloudFront Distributions > General > Enable IPv6

체크박스만 누르고 Yes, Edit 만 누르면 된다.

참쉽죠.

참곤란한 이슈였다. 참고-URL

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://tools.ietf.org/html/rfc3484?fbclid=IwAR0Ca2JDM55CpyhZSjtiR7EYhySfzADdLMRX2q-rWZoAM-z8BHbqismCQfk#section-2.1

읽어주셔서 감사하다!

aws route53 의 응답이상-1.

얼마전부터 route53 에서 cf 관련 느린이슈가 발생했다.

skt lte 망에서 발생하는 이슈인지 아니면 다른 이슈가 있는지 애매한 느낌이 있었다.

나도 ipv6 를 꺼서 지연문제가 해결될거라 생각했는데 조금 이상한 부분이 있어서 글을쓰게되었다.

먼저 route53의 응답이 이상하다.

linuxer.name 의 ns 레코드는

>linuxer.name
서버: [205.251.196.29]
Address: 205.251.196.29
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net

총 4개의 ns 를 가지고있다. 이 ns를 지정해보기로 한다.

>server ns-544.awsdns-04.net
기본 서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32

서버를 ns-544.awsdns-04.net로 지정하면 ipv6 와 ipv4를 응답한다.

그 후에 다시 내도메인을 쿼리한다.

>linuxer.name
서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32
*** ns-544.awsdns-04.net이(가) linuxer.name을(를) 찾을 수 없습니다. No response from server

그냥 도메인에 대한 응답인데..응답하지 않는다.

그럼 ns-544.awsdns-04.net 도메인의 서버IP인 205.251.194.32 로 쿼리를 날려본다.

>server 205.251.194.32
기본 서버: [205.251.194.32]
Address: 205.251.194.32

>linuxer.name
서버: [205.251.194.32]
Address: 205.251.194.32
linuxer.name internet address = 52.85.231.111
linuxer.name internet address = 52.85.231.10
linuxer.name internet address = 52.85.231.68
linuxer.name internet address = 52.85.231.42
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net
linuxer.name
primary name server = ns-1053.awsdns-03.org
responsible mail addr = awsdns-hostmaster.amazon.com
serial = 1
refresh = 7200 (2 hours)
retry = 900 (15 mins)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
linuxer.name name = 13.209.129.220
linuxer.name MX preference = 10, mail exchanger = mail.linuxer.name
linuxer.name ??? unknown type 257 ???

정리하자면 ipv4인 IP로 연결하면 응답하고 ipv6/ipv4로 응답하는 DNS로는 도메인에 대한 응답을 하지않는다…

이게 cf문제는 아니고 route53에서 ipv6 에 대한 응답을 정상적으로 못해서 발생하는 증상이 아닐까…하고 생각해본다..

다른의견이 있으시면 고견을 들려주시기 바란다.

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html?fbclid=IwAR3xOqsWf-xhh5cB0AOQfLW7zTKr-Cvd6mJEHfgIX607K1Rv6_HavoLPsnE

추가 댓글도 있으니 참고하시기 바란다.

2020/01/28 추가

https://tools.ietf.org/html/rfc3484#section-2.1

rfs3484에 의해 route53은 정상적인 응답을 하는것으로 보인다.

발생한 문제는 SK LTE 망내의 DNS에서 ipv6를 사용하므로서 정상적으로 라우팅하지 못한 문제로 보인다.

추가적인 내용은 다음포스팅에서 진행하겠다.

aws-ami-Permissions-ami공유

ami 를 공유하는 방법을 포스팅해 볼까한다.

계정간 인스턴스 이동을 진행하려면 꼭 알아야한다.

ami 메뉴에서 권한수정을 클릭한다.

공유할 계정의 aws 계정 번호를 입력하여 권한을 추가한다.

공유된 계정에서 인스턴스 생성 페이지에서 나의 AMI에서 소유권에 나와 공유됨만 체크해본다.

공유된 AMI를 확인한다.

다른 방법으로 ami 를 확인할수 있는데

공유 받은 계정에서 프라이빗 이미지를 검색해서 확인할수 있다.

리전이 다르다면 스냅샷을 리전복사 한다음에 공유를 하자.

끝!

Azure-네트워크 구성 및 망분리

azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.

서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.

근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.

azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.

한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.

요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.

가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.

서브넷을 3개로 나누었고 서브넷은

보안그룹을 서브넷에 설정하여 접근제어가 가능하다.

aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.

서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.

서브넷별 nsg 가 구성되는게 좋을것 같다.

가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.

직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.

굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.

sku는 basic / standard 두가지로 나누어져있는데

Configures outbound SNAT for the instances in the backend pool to use the public IP address specified in the frontend.

인터넷 통신

기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결공용 IP 주소 및 Load Balancer를 참조하세요.

하…모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.

nat gw가 필요가 없다…………………………충격 막으려면 NSG로 막아라.

그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.

선택한 서브넷 ‘linuxer-subnet-pri(10.0.0.0/24)’이(가) 네트워크 보안 그룹 ‘pri-sub-sg’에 이미 연결되어 있습니다. 여기에 새 네트워크 보안 그룹을 만드는 대신 기존 네트워크 보안 그룹을 통해 이 가상 머신과 연결을 관리하는 것이 좋습니다.

azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.

리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.

LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.

LB를 베이직으로 생성시에

???같은 가용성 집합인데????

음…이유는 다음에 찾아보기로 하고..

sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.

상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.

근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?

그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..

aws-cloudfront-s3-lambda cross-account access

cloudfront – s3 를 이용하게되면 결국 OAI를 이용한 Bucket policy를 사용하게 된다.

단일 계정에서 사용할 경우엔 cloudfront 에서 자동으로 생성까지 해주므로 어려울것이 전혀없다.

그런데 이제 이게 파트너사를 통해서 cloudfront 전용계정을 사용하게 된다던거 multi account 로 프로젝트를 진행할경우 자동으로 생성이 되지 않는다. 이 경우에 어떤방식으로 s3 Bucket policy 를 설정해야 하는지 포스팅하려 한다.

먼저 Bucket policy 를보자

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K28W3EQ”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::*”
}
]
}

일반적으로 계정에서 버킷정책을 설정하면 위와같은 형태로 적용을 한다.
가끔 정상적으로 적용이되지않는경우엔

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 49821f785cce6ee4f575de3f01c503dade8a7b15003aa337faa471d830d07493cbb195eec14f0d86d4a914622e1e42”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::*”
}
]
}

이런식으로 caninucal user id 를 이용하여 정책을 설정하면 자동으로 OAI ID로 정책이 적용되게 된다.

여기까진 아주 쉬웠다. 그런데

람다 엣지를 이용한 리사이즈를 하는 프로세스에서 단일계정이 아니라 교차계정을 구성하게 되면 lambda가 A 계정에서 B 계정으로 접근하게 해줘야한다. 이부분에서 조금 헤멧는데 결국엔 굉장히 간단한 부분이었다.

s3 Bucket policy 에서 계정의 role을 허용해주면 끝..

{
“Version”: “2012-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: ” Grant a CloudFront Origin Identity access to support private content”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K58WRN3EQ”,
“arn:aws:iam::328341115633:role/lambda-resize-cloudfront”
]
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::linuxer-resize/*”
}
]
}

arn:aws:iam::328341115633:role/lambda-resize-cloudfront

json 문법에 또 약해서 좀 해멧는데 금새 해결할수 있었다..

aws-EFS-backup-restore

EFS를 사용하고 백업/복구 이야기를 하려고한다.

EFS는 NFS기반의 편리한 서비스다. aws backup로 스냅샷 방식의 백업이 가능하다.

현재 측정크기가 6.0kib인데

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 4.6G 3.5G 57% /
tmpfs 99M 0 99M 0% /run/user/0
fs-7eb4fb1f.s.ap-northeast-2.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs

root@ip-10-0-0-12 wordpress]# cd /mnt/efs
# du –max-depth=1 -h
258M ./ftp
258M .

실제론 그렇지 않다. 일정 GB이상의 데이터가 쌓여야 명령어가아닌 gui에서 확인할수 있다.

오늘은 이 파일시스템을 백업할거다.

aws backup를 사용할때 유의할점은 백업볼트를 생성할때 각각 목적에 맞게 분할해서 사용하라는 거다. 급하게 작업하다가 관리가 너무 불편해져서 결국 나눴다.

일반적으론 볼트생성->계획생성->규칙생성->리소스할당 순서다.

리소스할당은 tag 기반으로도 가능하고 리소스ID 유형으로도 가능하다.

여기까지 백업계획을 이용한 스케줄 백업이었고 단발성 백업은 대시보드에서 온디멘드 백업으로 진행하면 된다.

진행중인 jab는 작업부분에서 확인할수 있다.

용량이 작어서 금방 백업이 완료됬다.

백업은 증분방식이고 복구지점에 카운트가 올라간다.

복원을 진행해 보면

전체/부분/소스/새 이렇게 선택지가 나눠지는데 얼마전 나에게 혼란을 줬던 부분은 전체-소스 파일 시스템에 복원이다.

복원을 누르면 작업탭에 복원에서 확인할수 있다.

Pending-> Running -> Completed 단계를 거친다.

Pending 이 한국어 에선 보류중으로 나오는데 처음에 좀 당황했다.
보류…??????????????????????????????????????????????
하고 Pending 좀 오래걸린다. 거의 10분 이상걸린적도있다.

root@ip-10-0-0-12 ~]# cd /mnt/efs/
root@ip-10-0-0-12 efs]# ll
total 16
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-33-30-039Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-47-22-912Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-49-03-261Z
drwxr-xr-x 3 jth-ftp jth-ftp 6144 Aug 21 21:20 jth-ftp

aws-backup-restore_2020-01-18T03-33-30-039Z 같은 형식으로 복원 시작시간으로 디렉토리가 생성되고 복원이 된다. 당연히 복원되는 양에 따라서 속도도 다르다.

3번 복원을해서 3개의 디렉토리가 추가 생성된거다. 사용용량이 df 로는 안보이지만 aws 콘솔에선 보인다.

처음 복구할 땐 덮어쓰기로 생각해서 한참을 기다려도 복구가 안되는거같아 EFS의 /를 마운트 해보고서야 알았다. 아 디렉토리 생성 후 복구되는구나.

그래서 이제 추가로 파일 복구를 해보기로 했다.

root@ip-10-0-0-12 wp-admin]# pwd
/mnt/efs/jth-ftp/wordpress/wp-admin
root@ip-10-0-0-12 wp-admin]# ll
total 980

/mnt/efs/jth-ftp/wordpress/wp-admin 디렉토리를 복구해보겠다.

부분 복원으로 선택하고~ 작업은 부분복원이 좀더 걸리는거 같았다.

/mnt/efs/aws-backup-restore_2020-01-18T04-09-39-782Z/jth-ftp/wordpress/wp-admin

경로로 이동해서 복구 확인해봤다.

root@ip-10-0-0-12 wp-admin]# ll
total 980

정상적으로 잘복구 된것을 확인할수 있었다.

efs 를 매우 애용하는 입장에서 파일복구가 가능해진것은 매우 반길 일이다.

아 추가로 EFS 에서 Bursting 모드를 사용할경우 BurstCreditBalance 를 가지게 되고 사용시 소모가 된다. 그런데 백업이나 복구시에는 크레딧을 따로 소모하지 않았다.

읽어주셔서 감사하다!

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 로 수정하면 끝이다.

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

끝. 좋은하루 되시라!

gcp terraform-3 vpc-nat create

vpc-nat 를 연결하기로 했다.
어젠 subnet 을 만들었고 오늘은 망분리 환경을 구성하기 위해 nat 를 넣었다.

main.tf

resource “google_compute_subnetwork” “us-central1-subnet” {
name = “${local.name_suffix}-us-central1-subnet”
ip_cidr_range = “10.2.0.0/16”
region = “us-central1”
network = “${google_compute_network.vpc.self_link}”
}
resource “google_compute_router” “us-central1-router” {
name = “${local.name_suffix}-us-central1-router”
region = google_compute_subnetwork.us-central1-subnet.region
network = google_compute_network.vpc.self_link
}
resource “google_compute_address” “address” {
count = 2
name = “${local.name_suffix}-nat-manual-ip-${count.index}”
region = google_compute_subnetwork.us-central1-subnet.region
}
resource “google_compute_router_nat” “nat_manual” {
name = “${local.name_suffix}-us-central1-router-nat”
router = google_compute_router.us-central1-router.name
region = google_compute_router.us-central1-router.region
nat_ip_allocate_option = “MANUAL_ONLY”
nat_ips = google_compute_address.address.*.self_link

source_subnetwork_ip_ranges_to_nat = “LIST_OF_SUBNETWORKS”
subnetwork {
name = “${local.name_suffix}-us-central1-subnet”
source_ip_ranges_to_nat = [“10.2.0.0/16”]
}
}

resource “google_compute_network” “vpc” {
name = “${local.name_suffix}-vpc”
auto_create_subnetworks = false
}

backing_file.tf

locals {
name_suffix = “linuxer”
}
provider “google” {
region = “us-central1”
zone = “us-central1-c”
}

vpc 와 nat nat route 까지 정상적으로 만들어져서 동작하는 것을 확인할 수 있었다.

리전당 nat는 1개를 꼭만들어야 했다.

현재 생성한 tf는 subnet 하나에 대한 설정이다. 다른 리전으로도 네임만 수정을 적절히 하면 수정해서 쓸수 있다.