aws-linuxer의 블로그 톺아보기

그 동안 블로그를 운영하면서 블로그에 이것저것 적용해 보느라 시간 가는줄 몰랐다.

대략적인 블로그의 구성도를 그려보았고 구성도를 하나하나 풀어보는 시간을 가져보려한다.

먼저 내블로그는 apm 으로 이루어진 상태였다. 프리티어로 도메인도 없는 상태였고 그냥 테스트 용도 였다.

그 블로그를 먼저 rds 로 분리를 진행 했다.

인스턴스한대에 apache + php + mariadb 였던 구성에서 mariadb 를 rds 로 옮겼다.
그리고 php를 php-fpm 으로 교체 했다.

이시기엔 그냥 구성만 진행하려던 시기라 뭔가 많이 붙이지 않았다. 이 다음 과정에서 로드벨런서를 붙였다.

ALB를 붙이고 나서 letsencrypt 로 인증서를 붙일가 구매를 할까 고민을 하였으나 결국 ACM을 사용하였다.

ALB는 여러개의 인증서를 사용할수 있고 ACM 은 한개의 인증서당 여러개의 도메인을 넣을수있다. 나는 linuxer.name / *.linuxer.name 루트도메인과 와일드카드로 이루어진 두개의 도메인을 acm으로 사용하고 있다.

이다음 진행한 설정을 s3 upload 다.

s3로 이미지를 업로드하고 cloudfront 로 응답한다. 블로그의 응답속도가 굉장히 올라갔다.

cdn.linuxer.name 도메인은 acm 을이용하는데 버지니아 북부에 acm을 설정해야 한다.

업로드 설정을 마친 다음에는 HA를 구성해 보았다. 이과정에서 redis 나 세션을 공유하기 위한 고민을 하였는데 사실 로그인은 나만해서 의미가 없었다. 또한 upload 도 s3로 해서 그냥 정말로 인스턴스만 만들고 대상그룹에 추가만 하면 바로 multi zone 구성이 바로 되었다. 단순한 wp! 칭찬해

그다음엔 지금도 수시로 테스트위해서 켜고 끄는RDS의 multiaz 진짜 고가용성을 위해선 아니고 그냥....썼다.

이부분은 두가지 이유떄문에 설정을 진행했는데, 먼저 중국의 해커가 너무 접근이 많았다. 또한 블로그에 매일 비아그라 광고가 봇도아니고 손으로 직접올리는 사림이 있었다. IP는 신기하게 매번 조금씩 달랐지만 댓글을 좀 지우다가 귀찮아서 결국 국가 차단을 계획했다.

지오로케이션을 지용하여 중국과 스패머의 국가를 Null 로 라우팅 하였다.

중국과 스패머의 국가 이외엔 cloudfront 로 접근된다.
일반적인 캐싱이나 CDN이 아니라 dynamic cdn 방식이다. 조금이라도 ALB로 빨리 접근하기 위한 방법이나 ...효과는 잘...아마 한국이라 그럴거다.

cf 는 버지니아 북부의 acm을 이용하여 도메인을 인증하고 인증된 도메인은 waf 연결된다. waf는 서울리전의 alb에 연결되어있다.

유저는 그럼 route53을통해 cf에 연결되어 waf 를 통과하고 alb에 연결되어 web ec2에 연결되고 rds의 데이터를 읽어서 페이지를 볼수있는거다.

생각보다 설명이 길었는데..아무튼 뭔가 많다.

대략적인 블로그의 구성도를 그리고 역할을 설명하였다.

내블로그지만 나름 재미있게 가꾼거 같다.

즐거운 저녁되시라!

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

읽어주셔서 감사하다!

호텔 델루나 뱃지 없으니 만든다!

장만월 사장의 호텔 델루나에 취업하고 싶은 찰나 완결이 다와가고 있어서 죽어서 취업할 순 없으니.....마음만이라도 델루나에서 함께하고 싶은 마음에 급하게 모델링을 시작했다.

일단 뚝딱 모델링을 끝내고 첫번째 프린트를 시작했다.

사이즈가 좀 작았다. 2cm 에 높이 1.3 얇게 테스트를 해봤는데 생각보다 깔끔하게 나오긴 했으나.. 원한 느낌은 아니었다. 출력시간 6분

갑자기 결론을 내서 미안하다.

3D 프린터가 고장나서 급하게 고치고 뽑느라 결과물만 있다.

가로세로 2.5cm 높이 2mm로 뽑았다. 0.12mm 노즐로 뽑아서 결이 고르지 못하다.

하지만 첫 완성 작인거 같아 포스팅을 한다.

이상한 주제의 글

필자는 의식의 흐름에 따라서 글을 쓰는것을 아주 잘하는 편이다.

오늘은 주제를 추전받았는데 이상한 주제로 글을쓰라는 추천을 받아서 포스팅을 작성하게 되었다.

이상한 주제라고 하면 결국 치과이야기가 적당할것 같다.

교정 3년차의 프로페셔널 교정러다.

교정이 거의 마무리단계이며 교정과정을 먼저 설명해 보겠다.

일단 엑스레이를 찍어서 견적을 받는다. 300만원으로 견적을 받아서 교정을 시작했다. 교정을 하게 된 이유는 간단하게.. 작은어금니와 어금니 사이에 치아가 삼각꼴을 이루며 덧니로 나게되었다. 이유는 여러가지겠지만 하관이 작아서 치아가 한줄에 다못들어간게 이유라면 이유다.

이 작은송곳니를 뽑았다. 교정시작한 첫날에 뽑았는데 너무 행복했다 덧니사이에 끼는 음식물을 더이상 빼지 않아도 된다는 사실이 너무좋았다.

좋은것은 좋은것이고 너무아팠다.

치아와 모발은 소중한것이니 필자처럼 막뽑지 않는것을 추천한다.

그리고 철길을 깔았다.

1달에 한번씩 치과를 갔다. 치아를 고른 열로 sort 하고 규격에 맞지않는 치아는 뽑았다. 그 규격에 맞지않는 치아가 첫째 작은 어금니이다.

첫 교정하는날 1개 그리고 8개월차쯤에 2개 21개월 차에 1개를 뽑았다.

위아래 작은어금니를 뽑았다 이말이다. 그때부턴가 없어져버린 치아처럼 본인도 위아래가 없어진거 같다.

그렇게 4개의 치아를
root@입안# rm -rf "작은송곳니"
하고 각각 치아마다 철길로 연결되서 가지런하게 배열되었다.

고통의 나날들로 다른사람이 교정한다고 하면 꼭 하라고 할거다. 왜냐고? 나만 아플순 없으니까. 진짜 개아프거든.. 밥먹을때마다 입안이 철사에 찢기고 장치에 베이고..헐고 피가나는건 예사일이다. 느긋하고 성격고치고 싶은 사람은 꼭 교정을 해라 성격베리고 예민해지니까.

말이샛는데 교정은 끝나는게 아니라 유지하는거다.

철길을 뺀다고 교정이 끝나는게 아니라 치아뒷편에 교정을 유지해주는 철사를 평생 붙이고 있어야하고 교정을 유지해주는 유지장치를 일정 기간마다 껴야한다.

아주 귀찮은 일이란 말이다.

그렇기에 추천한다.

필자는 미용상의 이유로 교정을 했다.

거짓말 같겠지만 진짜다.

교정을 하고나니 얼굴 라인이 달라졌다 웃는 모습도 가지런해졌다.

자신감과 신기함에 거울보면서 치아점검을 자주한다.

황니인지라 신경쓰여서 워터픽과 음파칫솔을 애용하는데 이것의 리뷰는 나중에 하고 이상한 주제의 블로깅을 마친다.