다음의 가이드를 따르면 되는데, 이 가이드를 따르면 java client 가 parameter store 에서 값을 가져오기 위한 access key 를 알아야 한다. 그러나 ec2 자체에 해당 IAM role 을 부여 했다면 그럴 필요도 없다. system 에서 curl 등으로 paramter store 의 값을 가져와 java에서 로딩 하면 된다.
DNS의 A 레코드에는 IP 가 지정되어 있으므로 쿼리시 바로 반환하고 CNAME 레코드는 일종의 symbolic link 와 같이 연결된 레코드를 반환한다. 그럼 연속해서 A 레코드 까지 찾아가서 IP를 알아낸다.
RDS 의 endpoint 는 mydbname.xrandomx.as-east-2.rds.amazonaws.com 등으로 외우기는 어렵게 복잡하게 만들어지고 aws 에서는 cname 을 사용해서 간소화 할 수는 있다고 한다. 이는 aws의 route 53 dㅔ서 A alias 에서 선택이 안되므로 어쩔 수 없는 선택사항 이기는 하지만 왜 A alias 로는 선택을 못하게 했을까가 의문이었다.
그러나 S3, Cloudfront, Elastic Beans Talk, ELB 등은 A alias 의 사용을 할 수 있도록 되어 있다. 게다가 이 때 사용하는 route 53 사용료는 무료.
Cloudfront 의 aws 에 의해 주어진 URL에 대해서 A alias 가 아닌 CNAME 을 사용하면 어떻게 될까?
에서 설명하고 있듯 CNAME 으로 xrandomx.cloudfront.net 을 cf.mydomain.com 으로 간소화 하면 cf.mydomain.com 을 lookup 했을 때 xrandomx.cloudfront.net 의 모든 IP가 다 나오는데 cf가 ipv6 를 지원하며, 사용자 입장에서는 ipv6와 ipv4 를 선택지로 받게 되고 우선순위에 따라 ipv6 부터 라우팅 하게 된다.
에 따르면, 이론적으로 NAT 를 할 필요 없는 IPv6 가 빠르지만 IPv4의 성숙도 때문에 IPv4 가 더 빠르다고 한다. 따라서 CNAME 으로 CF 의 주소를 지정하면 빠르게 하려고 선택한 CF 가 오히려 느리게 될 수 있다.
aws 에 의해 A alias 로 target 지정이 (선택이) 가능한 서비스는 위에 언급한 대로 CF, LB, S3 등 속도에 민감하며, IP가 언제든 바뀔 수 있으며, 특히 외부에 직접적으로 노출 해야만 하는 상황이 있는 솔루션 들이다. (그 각각 서비스의 endpoint 주소가 사용자 브라우저에 노출되면 이쁘지 않을 수 있는) 그리고 alias 에 대한 사용료는 aws 에 내지 않아도 된다. (CNAME 은 호출 사용료를 낸다.)
이 좋은 서비스 (A alias) 를 왜 RDS 등에는 제공하지 않을까?
이는 대외적으로 Open 해야만 하는 서비스 s3 나 CF의 주소에 대해서는 비용을 받지 않고 대외에 오픈할 필요가 없는 endpoint 주소에 대한 단축에 대해서는 (사실 꼭 해야만 하는 이유가 없는) 그 사용 비용을 받겠다는 뜻 같다.
에 의하면 100만건의 호출에 대해서 0.4$ 다. 만일 하루에 SQL쿼리를 서버에 몇번이나 날릴까? 하루에 10000건의 주문을 처리 하는 쇼핑몰이 있다고 치더라도 상품 조회를 위해서 수십배 많은 select Query 가 DB로 날라간다. 최종 사용자 들이 웹서핑을 하는 량에 따라 1백만건은 우습게 호출될 수도 있다. 그래도 고작 하루에 500원이다. 장애가 있거나 APP 배포 없이 DB를 교체 해야 하는 필요가 있는 경우가 있어 resonable 하다.
aws에는 랜덤으로 제시하는 URL이 많이 있는데, 이것을 모두 route53 에 등록해 둔다고 하면, 수조개의 쿼리가 route 53 에 집중 될 수 있을 것이다. on-premise DNS 서버를 쓴다고 하더라도 요청이 집중되는 것은 매한가지. 단지 endpoint URL 이 이쁘게 보이는게 다가 아니다.
RDS 의 endpoint 는 Multi-AZ를 고려한 DNS CNAME 이다.
RDS 도 죽는다. aws 가 무적은 아니다. DB 가 설치된 실제 장비의 네트워크가 죽거나 하드 디스크가 망가지거나 하면 sync 로 복제된 예비 장비로 RDS endpoint 가 이동한다.
예를 들어 RDS가 제공해준 DB 주소가 다음과 같다.
dbname.xrandomx.ap-east-1.rds.amazonaws.com
RDS console 에 들어가면 현재의 DB가 어느 AZ 에 위치하는지가 나오고 예비 DB의 zone 도 확인 가능하다.
nz@nzmain:/mnt/c/Users/nzin4$ nslookup database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com
Server: 172.21.32.1
Address: 172.21.32.1#53
Non-authoritative answer:
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com canonical name = ec2-3-227-127-64.compute-1.amazonaws.com.
Name: ec2-3-227-127-64.compute-1.amazonaws.com
Address: 3.227.127.64
nz@nzmain:/mnt/c/Users/nzin4$ host database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
endpoint URL 로 lookup 또는 host 를 확인해 보면진짜 endpoint 는 ec2-3-227-127-64.compute-1.amazonaws.com 임을 알 수 있다.
하지만 우리는 main DB 장애 발생시에 자동으로 secondary zone 으로 전환해주는 RDS 의 multi-az 기능을 사용하므로 ec2-3-227-127-64.compute-1.amazonaws.com 를 직접 사용해서는 안될 것이다.
이제 failover 를 지원하는 리붓을 해 보면 어느 순간 RDS의 호스트 값이 바뀌는 것을 알 수 있다.
nz@nzmain:/mnt/c/Users/nzin4$ while true; do host database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com; sleep 5;done
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
...
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-35-174-35-60.compute-1.amazonaws.com.
ec2-35-174-35-60.compute-1.amazonaws.com has address 35.174.35.60
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-35-174-35-60.compute-1.amazonaws.com.
ec2-35-174-35-60.compute-1.amazonaws.com has address 35.174.35.60
리붓이 끝나더라도 이미 main db는 아까 secondary Multi-AZ의 DB가 main 으로 대체 된다.
us-east-1f 새로운 DB가 main 이 되었다.
host 조회시에 다음과 같이 조회가 되었는데
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
왼쪽은 조회한 것 우측은 CNAME 의 value 를 말한다. 즉 database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com 가 RDS 가 제시해준 대체 도메인 이름 (CNAME) 인 것이다.
나도 한때는 맥을 사용했다. 한 5년정도? 맥을 버린 이유는 2010년 당시 eclipse IDE 와 호환성이 별로였기 때문인데 마우스 없이 되는 것이 좀 있었던 기억이 난다. package explorer 에서 우측 클릭하면 tree 가 안 열렸는데 정확한 기억은 아니지만 뭔가 윈도우보다는 마우스를 써야만 하는 것들은 분명히 있었다.
2012년부터 windows 로 돌아왔고 약 10년 째 window 서버를 운영하고 있다. 왜냐면 노트북이나 타블렛에 돈을 많이 쓰고 싶지 않아서이기 때문이다. 항상 3G 무제한 테더링을 하면서 필요한 일이 있으면 서버에 붙어서 작업을 했다.
요즈음에도 뭔가 일이 있으면 일단 mstsc 로 원격으로 붙곤 한다. 예를 들어서 휴대폰을 수리 하러 가거나 어디 호텔에 PC를 잠깐 쓰더라도 일단 내 서버에 붙으면 무엇이든 빠른 속도로 할 수 있다.
개발자로서 많은 램을 필요로 하고 좋은 노트북에 돈을 많이 쓰기는 싫다. 16G 램이 달린 비싼 노트북을 살 수는 없다는 것과 터치되는 노트북이 없다는 것이, 바로 내가 맥으로 가지 못하는 이유인 것 같다.
또한 CPU 를 많이 사용하는 작업을 모바일 디바이스에서 하면 필연적으로 배터리를 많이 쓰게 된다. 또한 조용한 곳에서 쿨러가 돌게 만드는 것 또한 하기 싫다.
나는 thin client 가 좋다. 쿨러가 없어도 좋겠다. 그저 원격 터미널에만 잘 붙으면 좋겠다. 그러나 안드로이드나 mac 에서 윈도우 서버로 원격 터미널에 붙게 되면 windows 단축키나 한/영 전환에 어려움이 있다. 한/영전환은 크롬북에서도 잘 되지만 shift 가 계속 눌린채로 유지되는 버그가 있다.
거의 7년동안 무제한 3G 54 요금제를 SKT 로 쓰다가 v50 대란 때 LGUplus 로 넘어왔다. 그런데 신나게 테더링을 하는데 어느날 부터 안되는 것이다. 데이터 쉐어링 용량은 따로 제한이 있다고 한다. 상담을 받아보니 LTE 부터 생겼고 SKT 도 같을 것이라는 것이다.
인터넷 검색하면 APN 을 바꾸면 된다는데 뭔가 잠겨 있다.
v50 네트워크 모드를 진입한다 전화 앱에서 다음과 같이 입력
전화 앱 > 5457#*500# 입력
Service Menu 라는 화면에 진입하게 되는데 맨 밑에에서 6번째쯤 메뉴에 APN 편집이 언체크 되어 있다. 이것을 체크하고 나온다.
설정 > 네트워크 탭 > 모바일 네트워크 > 액세스 포인트 이름
에 접속하면 우측 상단에 … 메뉴 버튼을 누르면 APN 추가를 할 수 있다.
이름 : lg 5g
APN : internet.lguplus.co.kr
우측 상단 … 메뉴 > 저장
