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 최적화가 누군가에겐 도움이 될거라 생각한다.
좋은하루 되시라!
잘봤습니다. 재밌는 주제네요! 근데 어차피 게시물과 자료들이 늘어나도 한페이지에 데이터만 로딩되는데 트래픽에 의미가 있나요??
한페이뷰당 몇명의 사용자를 받을수있는지 확인하기위한 테스트였습니다.
apache 튜닝으로인한 부하를 감당하고 인스턴스가 죽지않게 파라메터를 수정하는게 요점이었습니다.
wordpress는 페이지에대한 리퀘스트를 데이터베이스에서 URL저장한것을 응답하기때문에 실제 부하는 어떤페이지든 동일합니다.
그래서 실제 데이터의 양은 이미지는 cf에서 응답하므로 중요하지 않고 하나의 프로세스가 얼마만큼의 자원을 사용하는지만 계산할수있다면
인스턴스를 아주 아슬아슬한 부분까지 사용할수 있습니다.
미래에서 좋은 글 발견해서 덧글 남깁니다.
덕분에 medium 쓰지 않아도 처리가 가능할 것 같습니다.
감사합니다.