ERROR! ‘file’ is not a valid attribute for a Play The error appears to be in ‘/etc/ansible/roles/locale.yml’: line 9, column 3, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: – file: ^ here
— become: true become_user: root hosts: all name: rdate tasks: ~ file: group: users mode: 493 owner: tomcatadm path: /opt/oracle state: present name: “create a directory for apache tomcat”
yml 형식도 ok 그런데 file 모듈에서 에러가 발생한다. 그냥 권한 바꾸는 간단한 건데 여기에서 오랫동안 막혀있었다.
# ansible all -m file -a ‘dest=/home/test state=file mode=755’ -k
흔히들 한글도메인을 많이 사용한다. 처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.
route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.
간단하다 모든 네임서버는 한글을 인식할수 없다.
그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.
퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.
보통이경우엔 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 접속이 느려졌다.
이만하면 충분히 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 까지 늘렸다. 그리고 테스트를 하였다.
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의 파라미터그룹은 디폴트 파라미터그룹을 수정할수 없다. 따로 생성하여 수정해야 한다.
#dd if=/dev/zero of=/root/swapfile bs=1024 count=2000000 1580109+0 records in 1580109+0 records out 1618031616 bytes (1.6 GB) copied, 23.3556 s, 69.3 MB/s
