route53 에서 한글 도메인 사용법. 부제 - 장난으로 리눅서.com 구매한 이야기

흔히들 한글도메인을 많이 사용한다.
처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.

route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.

간단하다 모든 네임서버는 한글을 인식할수 없다.

그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.

퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.

뭐그렇단다.

그래서 퓨니코드로 인코딩된 문자열로 hosted zone 을 생성하면 사용할수 있다.

갑자기 든 의문이다. 퓨니코드 서브도메인은 생성이 가능할까?

도전해 본다.

https://후이즈검색.한국/idnconv/index.jsp

에서 변환가능하다.

리눅서.linuxer.name 를 변환하면 xn--pd1b38litg.linuxer.name 가 된다.

퓨니코드로 변환된 서브도메인으로 접속시에 잘된다.

결론. 한글서브도메인 route53에서 사용가능하다. 그럼 혹시 com 도메인도 퓨니코드로 변환해서 등록이 가능하지 않을까?

xn--pd1b38litg.com 으로 검색이 되고 구매까지 이어진다.

크래딧으로는 도메인을 구매할수 없다.

등록대기중 뜨고.

결제도 되구..
엥? 진짜? 리눅스.com 생성되는거야??????????????????????

리얼리? 농담인데;;;;;;;;;;;;

자동으로 hosted zone 도 생성됬고.......돌이킬수 없게 됬다.

나는 장난으로 리눅서.com을 가지게 되었다...

1년시한부로..

당연히 될건 알았는데 사고나니 좀 웃기기도 하고 그렇다.

리눅서.com 출격합니다.

acm도 잘추가되고!

웹사이트도 잘열리고!

감사합니다.

ssh putty로 접근시 로그인창이 늦게 뜨는 증상.

putty로 ssh 접근시에 로그인이 느리다는 의뢰인이 있었다.

보통이경우엔 UseDNS no 나 GSSAPI Authentication 인증으로 인하여 느려지게 된다. GSSAPI 관련 문제의 경우엔 보통 secure 로그에 GSSAPI 에러가 남게된다. 그래서 보통 접근은 DNS -> GSSAPI 순으로 하게되는데 제일먼저 /etc/resolv.conf 에 nameserver 설정을 변경하고 그다음은 sshd_config 에서 UseDNS no 설정을 추가하게 된다.

일단 하나로 UseDNS no 옵션도 GSSAPI도 아니라 일단 하나로 DNS인 210.220.163.82를 알려주었다.

그러던중 이상한걸 발견했다. sesure 로그에서 질문인의 IP가 222.222.222.1인것.

베이징 IP다.

222.222.222.1은 베이징의 공인IP로 퍼블릭으로 연결되는 설정이 있는 VM의 경우 route로인해 첫번째 문제가 발생하고 vm에서 dns 확인하면서 ssh 접속이 느려지는 문제가 발생한다, 그렇기에 우리는 네트워크에 정해진 규약을 사용해야 한다.

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255
사설 IP 대역을 사용하지 않아서 ssh 접속이 느려졌다.

사설 IP사용은 이유가 있다.

오늘 포스팅 주제를 선물해주신 신난 어피치님 매우 감사드린다!

wordpress s3 cloudfront 적용하기

줄곳 고민하던 s3-uploads / cdn-cloudfront 를 적용하였다.

먼저 wordpress 의 여러 플러그인중에 대중적이며 복잡하지 않은 방식을 채택하였다.

사용한 플러그인은 두가지이다.

Amazon Web Services / WP Offload Media 

두개의 플러그인을 설치한다.

그리고 AmazonS3FullAccess 권한을 가진 사용자를 Programmatic access 방식으로 생성한다.

그리고 버킷을 생성한다. AmazonS3FullAccess full acces 권한을 줬는데 이 권한은 업로드 권한만 줘도 무방하다. 하지만 편한 테스트를위해 전체 권한을 부여하였다.

일단 모든 퍼블릭 엑세스 차단을 해제한다. 나머지는 모두 기본설정이다.
위 설정은 편한 설정을 위한 선택이므로 각자 개인의 선택을 요한다.

미리 wp-content/uploads 폴더까지 생성한다. 그리고 cloudfront 를 생성한다.

Restrict Bucket Access -yes
Origin Access Identity - Create a New Identity
Grant Read Permissions on Bucket - Yes, Update Bucket Policy
위 순서대로 선택하면 s3 버킷 정책이 자동으로 삽입된다.

{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E2BE1SUSFLL"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::linuxer-wp1/*"
}
]
}

그리고 cloudfront는 https 로만 통신하기 떄문에 route53에 도메인을 생성하여 붙여주는게 좋다. 도메인을 붙일떈 acm 을 생성하여야 한다. acm은 버지니아 북부에서 생성한 acm만 사용할수 있다.


acm은 route53을 사용하면 버튼 클릭 한번으로 생성 가능하다. 하나의 acm에는 50개의 도메인을 추가할수 있다. 간단하게 linuxer.name *.linuxer.name 을 추가하였다. 여기에 linuxer.com 이나 linuxer.kr namelinuxer.net 등 여러가지의 도메인을 한꺼번에 추가하여 사용할수 있다.

이후 cloudfront 를 생성한다. 이후에 wordpress 플러그인 설정화면으로 진입한다.

엑세스키와 시크릿키를 입력하고 save를 하면 디비에 저장이 된다.
디비에 저장하고 싶지 않을경우에 wp-config.php 파일에 추가를 한다.

그리고 플러그인 Offload Media Lite 으로 진입하여 cname 설정을 진행한다.

OFF 되어있는 버튼을 누르고 설정된 cloudfront 에 설정한 cname 을 입력한다.
이 설정을 마칠쯤이면 cloudfront 가 Deployed 상태로 변경될것이다.

그러면 이제 테스트 게시물을 작성하여 보자.

업로드가 정상적으로 이루어 지게 되면 이미지가 정상적으로 보이게되고 주소복사를 눌렀을떄 해당 페이지가 cdn 페이지로 열리면 정상적으로 upload-s3-cdn 이 구조로 생성이 된것이다.

그리고 s3 로 uploads 디렉토리를 이동하는것은 선택이다.

하지만 그부분도 진행하였다.

#aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:ap-northeast-2

aws configure 명령어를 이용하여 이전에 만든 엑세스 키를 입력하고 리전을 지정한다. 그리고 aws s3 명령어를 이용하여 sync 한다.

#aws s3 sync wp-content/uploads/ s3://linuxer-wp/설정한 경로

이전에 업로드된 파일때문에 위와같은 작업을 진행하는것이므로 새로생성하는 wordpress 의 경우엔 하지않아도 괜찮다.

이후로 업로드되는 파일은 s3로 업로드되고 view 는 cloudfront 에서 진행될 것이다.

오늘의 포스트 주제를 주신 전산직 님께 감사드린다!

좋은하루 되시라!

aws free tier 한계까지 써보기.

galera 테스트를 진행하면서 블로그의 max connection을 테스트 할수 있었다.
한계는 명확했다.

50...!

50...!!!!!!!!!!

50!!!!!!!!!!!!!!!!

t2.micro 사이즈 의 rds 의 max_connections는 134 인데 50까지 밖에 안된다는건 역시 web의 문제일 확률이 크다.

php-fpm에서 문제를 확인할수 있었는데 바로 알게된 이유는 apache의 제한은 그보다 크게 설정되어있기 때문이다.

#cat /etc/php-fpm.d/www.conf | grep pm.max_children
pm.max_children = 50 => 150
#systemctl restart php-fpm

php-fpm 에서 사용할수 있는 자식프로세스 개수를 150개로 변경하였다.

이만하면 충분히 web 인스턴스를 죽일수 있을거라 생각된다.
동접자만 확인하면 되는데 쓸데없이 흥분해서 30000번의 테스트를 보냈다.

로드벨런서 요청 갯수다. 그리고 인스턴스 안에서 로그로 리퀘스트 횟수를 확인해보니 약 9000개 정도..

어? 나쁘지 않은데? 싶다. 솔직히 내블로그가 동시접속자 1000명으로 몇번이나 견딜까 싶기도 하고... 하지만 여기서 그칠순 없다. 동접자를 더 늘려보자!

fpm 설정이 무리한 설정이 아니었을까? 사실 20개만 해도 cpu는 100%가까이 근접해 버리는터라 일단 메모리 리미트에 맞춰서 pm.max_spare_servers 설정을 수정하는것이 관건이라 본다. 간당간당하게 버티면서도 인스턴스는 죽지않는. 이과정은 사이트의 다운과 리스타트가 동반되는 아주 귀찮은 과정이다.

그래도 일단 근성을 보여서 테스트를 진행했다.

jmater를 이용하여 부하를 주고 인스턴스가 죽지 않을 만큼 php-fpm 에서 적당히 설정을 조절했다. 이경우 최대 부하시점에서 메모리가 아슬아슬하게 남아있을 경우를 찾아서 최적의 값을 찾아보았고 php-fpm.d/www.conf 를 수정하였다.

top 명령어 로 RES 부분을 보면 하나의 프로세스가 사용하는 메모리 양을 알수있다. 스크린샷에는 52M 정도이므로 프리티어는 1G의 메모리 까지 사용 가능하다. OS 까지 생각하면 대략 750M 정도 사용가능하다 생각하면 되는데 이기준으로 pm.max_spare_servers 를 15로 정했다.

다시 부하를 주었다.

예상 처럼 남은 메모리가 50M 정도밖에 남지않고 잘돌아간다. 물론 이상황에 CPU는 100%다. 이실험을 시작한 이유는 rds에 최대 부하를 주는것이 목적이므로 pm.max_children 를 150 까지 늘렸다. 그리고 테스트를 하였다.

/etc/php-fpm.d/www.conf
pm.max_children = 150
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 15

fpm 을 재시작하여 적용후에 rds의 모니터링을 확인했다.

ec2 도 죽지않고 rds도 죽지 않았다. 아니 rds 는 max 커넥션에 걸리는데 cpu나 메모리는 13%....아마 내블로그에서 끌어낼수 있는 한계가 13%인거겠지...또르륵 그렇다면 이쯤작성하다 오기가 발동했다. 부하테스트를 시작한김에 rds 가 죽을때까지 인스턴스를 늘리기로 했다.

Auto Scaling 걸고 트리거 cpu는 60%로 사실 의미없다. 동시 접속 20개만 걸려도 cpu 100%인거.. 그렇지만 rds 를 죽이기로 했으므로 부하를 걸었다.

Auto Scaling 은 차근차든 인스턴스가 생성됬고 총5개까지 생성되었다.
사실 동접자 초당 120명 이면 인스턴스 모두 CPU가 100%다.... 무조건 부하를 주는건 잘못된 테스트 같아서 방법을 수정하였다. 1초당120번 접속 무한반복으로.

죽이기로 했으니 원래 t2.micro 사이즈의 max_connections 은 {DBInstanceClassMemory/12582880} 134다 이걸 10000으로 수정하였다.

rds의 파라미터그룹은 디폴트 파라미터그룹을 수정할수 없다. 따로 생성하여 수정해야 한다.

Auto Scaling 으로 추가된 인스턴스다.

내블로그로 rds를 죽이는건 실패했다......아마 인스턴스 사이즈를 늘려서 메모리와 cpu를 더많이 사용한다면 죽일수 있었을거라 생각한다.

다음기회엔 꼭죽이리라..

블로그를 더 많은 게시물과 자료로 꽉꽉체워서 죽여야겠다.

일단.........결국 가쉽성의 글이되어 버렸다.
결론을 내지못해 아쉽지만 fpm 최적화가 누군가에겐 도움이 될거라 생각한다.

좋은하루 되시라!

aws에서 MariaDB galega Cluster 사용하기 ver.2

지난 포스팅에 이어서 맺음하는 포스팅이다.
계획은 일주일 이었으나 이주 가까이 galera를 사용하였다.

이주동안 사용량이나 봇들의 동태 이것저것 모니터링을 했지만..
부하가 없었다.. 그래서 부하테스트는 직접하기로 마음을 먹었다!

먼저 비용부터 보자.

Cost Explorer 에서 일별 서비스별로 본 그래프이다.
여기서 중요한건 EC2 비용인데 0.47$ 정도다. t3.nano 3대 하루 비용인데 1달정도 하면 14.1$ 정도 나온다. 정말 얼마 안나온다. 깜짝놀랄정도.

그렇다면 성능을 확인해 볼까?

구성을 나열하자면 NLB-mariaDB-cluster(t3.nano 3ea) 간단한 구성이다.

지금 이 블로그로 테스트를 진행하여 보았다.

부하테스트 툴은 jmate를 사용하였다.

1초동안 100명의 USER가 접속을 시도하고 30초간 유지이다.

총 3000번의 접근을 하게된다.

http://linuxer.name 으로 http request 를 하도록 설정하였다.

web인스턴스의 CPU / memory 지표이다.
실제로는 보이는 지표의 2배정도 된다고 보면된다. 5분 평균이라 실제 부하보다 낮은 값으로 보인다. 실제 cpu 부하는 100%라고 보면 된다. 23:45이 galera 00:15 rds다.

나중에 생각해보니 왜 rds 의 그래프가 더 낮을까 의문이 들었는데 rds max connection 때문에 정상적으로 부하가 제한된것 같다. 이런.. 라고 생각했는데 아니었다..그냥 웹서버 php-fpm 제한이었다 ㅠㅠ

galera 인스턴스다. 그래프의 평균치라 마찬가지다. 두배정도의 부하가 발생했다고 생각하면 된다. 합쳐서 11%정도의 부하가 발생했다. 그래프에서 안보이는데 A/C의 부하가 동일하게 나타났다.

RDS로 옮긴후에 테스트진행하였다. 13%정도의 부하가 발생하였다. 이때

rds max connection은 꽉찬 상태였다. 이결과로만 보면 내 블로그는 max 커넥션을 더늘려도 괜찮은 거로 보인다. 사용자원에 비해 기본값 max connection 이 낮은 편이라는 결론이 난다.

각설하고 일단 단순비교시에 galera와 rds 의 성능차는 거의 없어 보인다.

비용차이는 NLB 비용이 cost explorer에서 추가되지 않아서 확인할수 없었다.
그런데 free tire 에서는 NLB가 포함되지 않는데 이상하게 청구되지 않고 있다...땀삐질 너무 쓰는게 없어서 그런가..

현재 galera에서 RDS로 전환한 상태이고 마지막 테스트 까지 진행하였다.

추가테스트를 한다면 web서버의 처리량을 늘리고 최대사용자를 테스트하는 방식으로 가야 할것으로 보인다.

이 테스트는 다른것보다 galera가 어느정도 사용가능한 수준이라는 것을 알게 된 과정이었다.

다음에 기회가 된다면 좀더 딥한 성능테스트를 진행해보겠다.

좋은하루되시라!