이만하면 충분히 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의 파라미터그룹은 디폴트 파라미터그룹을 수정할수 없다. 따로 생성하여 수정해야 한다.
사실 aws에 galera를 셋팅하는것은…RDS때문에 아이러니한 선택일수 있으나,
온프레미스에서 쉽사리 셋팅하기 어려운 구성인 galera를 테스트 해보기로 하였다.
사실 이글을 쓰는 지금은 이미..블로그가 galera 위에서 돌고있다.
준비물을 챙겨보자.
galera의 구성에는 multi-AZ를 위한 여러개의 서브넷이 필요하다.
한국리전의 A/B/C zone 을 모두 사용한다.
그리고 인스턴스를 생성한다.
인스턴스는 t3.nano를 활용하였다. 사용자가 많지 않아서 nano로 버틸수 있을거라 생각했다.
이과정에서 인스턴스만 5번이상을 만들었다 지웠다를 반복했는데 그이유는 B영역 때문이었다. 처음엔 t2.nano를 사용하려했으나 B영역에서 not support 발생으로 평소 사용해보고 싶었던 t3a 계열을 사용해 보려고 했으나, 마찬가지로 not support상태.. 결국 돌아서 t3.nano를 사용하게 되었다.
사용한 ami는 amazon linux 2 다.
인스턴스 생성후 보안 그룹은 따로 galera-sg를 생성하여 galera 인스턴스 끼리는 통신이 되도록 설정하고 웹서버 내부 IP로 3306만 열어 주었다.
인스턴스 셋팅할때는 EIP를 붙이고 작업하였다.
galera 셋팅은 아래와 같다.
#vi /etc/yum.repos.d/mariadb.repo
아래내용 삽입 설치할 mariadb 는 10.4 버전이다.
#MariaDB 10.4 CentOS repository list - created 2019-09-10 11:12 UTC #http://downloads.mariadb.org/mariadb/repositories/ [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.4/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
여기서 수정할 내용은 wsrep_node_name='galera1' wsrep_node_address="10.0.4.27" wsrep_cluster_address="gcomm://10.0.4.9,10.0.4.27,10.0.4.43" 이 세부분이다. node name 은 노드를 분류할 이름으로 나는 galera1/2/3으로 넣었다. address 는 IP 인스턴스 각각 내부 IP를 넣어주고 클러스터 address는 클러스터 node address 를 나열한다.
여기까지 완료됬다면 galera 기본설정은 완료이다.
새로 만드는 클러스터일경우
#galera_new_cluster
명령어를 쳐주자. 이미 사용중이던 db를 클러스터로 만든다면 각각 mysql data를 클론뜨거나 dump 하여 데이터의 무결성을 검증할수 있도록 만들어준다음 클러스터로 엮어야한다.
이후 NLB를 추가하여
사용한 A/B/C 영역을 넣어주었고, 대상그룹에 galera cluster 를 넣어주었다.
상태가 healthy로 정상적으로 상태검사를 통과하는것을 확인할수 있었다.
이부분에서 확인할수 있었는데 상태검사를 통과하기 위해선 galera 보안그룹에 NLB가 위치한 subnet의 포트에 대해서 인바운드를 허용해 주어야지만 상태검사가 정상적으로 이루어 지는것을 확인하였다.
나는 이후에 NLB end point 로 rds 에서 db를 dump 하여 부어넣었다.
#mysqldump -h linuxer-blog-rds.com -u user -p DB > /home/linuxer-blog-db.sql
덤프후에 galrera cluster 로 접근하여 grant 권한을 웹서버에 맞춰서 설정해 주었다.
mysql>GRANT ALL PRIVILEGES ON db.* TO user@webserver_internal_ip IDENTIFIED BY 'password';
이후에 웹서버에서 밀어 넣었다.
mysql -h linuxer-galera-nlb.com -u user -p < /home/linuxer-blog-db.sql Enter password:
정상적으로 데이터를 복구하였고 이후에 디비커넥션을 수정하여 rds 에서 galera로 접속되도록 설정하였다.
rds t2.micro
mariadb galera
평균 0.20s 정도 불러오는 속도 차이가 난다.
일주일간 galera cluster를 유지할 생각이다.
galera cost
rds cost
9$정도의 차이이며 아직 file over 테스트는 진행하지 않았다. multi-AZ활성화 시에 rds 비용이 추가되는것을 생각하면 큰비용은 아니라 생각되지만..기본적으로 multi-AZ로 구성되는 galera의 경우엔 어떤것이 좋다 나쁘다는 아직 결정할수 있느 근거가 부족하였다.
#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
