기타

IT infra user group MeetUp review

사진 설명이 없습니다.

IT인프라 유저그룹에서 세션을 진행했습니다.

아무도 이야기하지 않는 클라우드 3사 솔직 비교 라는 주제였습니다.

많은 고민을 해왔던 주제고 어느정도 결론을 낸 주제이므로 나름의 자신이 있었습니다.

글을 써내려 갈때 주로 선택하는 방식이 주제와 결론을 정하고 주제에 따른 살을 입혀서 내용을 풍성하게 만드는 방식으로 주로 글을 씁니다.

퍼블릭 클라우드 3사 비교라는 주제는 자칫하면 쏠릴 수 있고 민감한 주제라 어떻게 풀어가야할지 고민을 많이했지만 평소 관심이 많은 주제라 망설임 없이 슬라이드를 작성하였습니다.

가장 신경을 쓴부분은 나의 이야기가 상대방이 공감할수 있는이야기 인가? 이부분을 최대한 고민해서 작성했습니다.

사실 결론까지 이어지는 맥이 좀 약하다 생각했습니다.

사람들이 내 결론을 잘 받아들였을까 고민될정도...

하지만 결론에 대해 갸웃? 하더라도 전달하고 싶었던 정보들은 내가 가졌던 의구심과 답답했던 과정들은 가감없이 전달될것이라 생각했기 때문에 내 불편함에 대해서 사람들이 공감할수 있다면 절반은 성공이라 생각하며 슬라이드를 작성하였습니다.

"어떤 클라우드가 싸고 좋은가요? " 이 뻔 하고 어려운 질문에 답변을 하는게 이번 세션에서 말하고 싶은 바였습니다.

그래서 저의 결론은 "더 좋고 더 나쁜 클라우드는 없다." 였습니다.

역할에 따라 취향에 따라 상황에 따라 비용에 따라 모든것은 인프라일 뿐 그저 맞춰서 사용하는것이 정답이라는 대답을 드릴수 밖에 없었습니다. 정말로 교과서 적인 대답이지만 이 답변을 드리기 위해 경험한 바를 풀어가며 살을 붙였습니다.

여러 고민 끝에 슬라이드를 작성하였고 23일 meetup에서 세션을 진행하였습니다.

긴장이 되긴 했는데 딱 적당한 긴장감이었고 처음하는 세션이라 중간중간 방향성을 잃긴 했지만 결국 방향성을 되찾았습니다.

눈을 가린 말처럼 슬라이드의 마지막장으로 달려갔습니다.

준비한 멘트는 많았지만 생각만큼 조리있게 설명하는건 쉽지 않았습니다.

말은 뇌를 거치지 않은게 더 많았습니다.

고심해서 하는 말보단 날것의 멘트가 점점 차오를 쯤 슬라이드의 마지막장에 이르렀습니다.

어려운 질문일수록 더욱 깊게 생각납니다.

"멀티클라우드 구성 관련 질문을 주셨는데 벤더락을 피하고 싶다." 라는 질문을 하셨습니다. 저는 개인적으로 아직까진 멀티 클라우드에 대해서 부정적인 입장입니다.

떨어뜨릴수 있는 서비스라면 분리해야한다 생각합니다.

이유는 비용과 트래픽의 측면을 제외 할 수 없습니다. 각 퍼블릭 클라우드의 장점인 서비스만 떼서 이용 할 수 있다면 더 할 나위없이 좋겠지만 컨셉이 정해지기 전까진 정말 답이없는 이야기라 생각이 됩니다.

어제의 세션을 저스스로 점수를 메기자면 7점 정도를 주려고 합니다.

저는 처음이었고 연초부터 쉼없이 달려왔습니다.
좀 지친 상태에서 시작했지만 즐겁게 준비했고 의도한 바는 전달한거 같습니다.

짧은 시간 준비한 세션이었고 만족하지 못한 분이 계실수도 있다 생각합니다.

이부분은 제가 따로 채우겠습니다. 궁금하신 부분이나 이상한 부분이 있다면 언제든 질문해 주세요. 답변드리겠습니다.

즐거운 세션이었고 좋은분들과 함께 해서 의미있었습니다.

먼저 흔히 할수 없는 기회를 주신 조훈님께 감사드립니다.

글읽어 주신 분들. 세션을 봐주신 분들께 감사인사를 드립니다.

마지막으로 감사합니다.

발표에 사용한 슬라이드를 첨부합니다.

gmail-mail-delete

구글메일의 용량이 가득차 문제가 생기는 경우가 있으실 겁니다.

size:100k older_than:1y -@gmail.com

100K 이상 1년 이상 위의 @gmail.com 메일주소를 제외하고 검색해주는 명령어 입니다.

google 검색 규칙과도 동일하므로 패턴을 좀더 확실하게 알고싶으시면

https://support.google.com/vault/answer/2474474?hl=ko

다음 URL 을 참고하세요.

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 노즐로 뽑아서 결이 고르지 못하다.

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