vi /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Unattended-Upgrade "1";
1로 설정된 옵션을 수정하면 자동업데이트는 꺼진다.
그렇다고 해서 업데이트를 할수없는것은 아니고 수동으로 명령어를 쳐서 가능하다.
#unattended-upgrade --dry-run
명령어를 이용해서 확인하자.
카테고리: Linux
curl-openssl_4 to openssl_3
php-curl-openssl 모듈을 사용하게 될 경우 컴파일을 하면 문제가 생겼다.
ubuntu 16 / apache 2.4 / php 5.3 / curl 7.49 / openssl 0.9.8zh
모두 컴파일 된 상태였다.
이과정에서 php 는 CURL_OPENSSL_4 이 아닌 CURL_OPENSSL_3을 요구했고 수정하는 방법이다.
vi curl-7.54.0/lib/libcurl.vers
HIDDEN
{
local:
__; _rest;
_save*;
};
CURL_OPENSSL_4 -> CURL_OPENSSL_3
{
global: curl_*;
local: *;
};
CURL_OPENSSL_4 부분을 CURL_OPENSSL_3 으로 수정해서 컴파일 하자.
./configure --prefix=/usr/local/curl --with-ssl=/usr/local/openssl --enable-versioned-symbols
mv /usr/lib/x86_64-linux-gnu/libcurl.so.4 /usr/lib/x86_64-linux-gnu/libcurl.so.4.orig
ln -s /usr/local/curl/lib/libcurl.so.4.4.0 /usr/lib/x86_64-linux-gnu/libcurl.so.4
cloudwatch log 매트릭 경보 생성 - log monitoring
오늘의 주제는 인스턴스에서 발생하는 로그를 cloudwatch 로 전송하여 사용하는 법을 포스팅 할거다.
먼저 역할에 정책부터 생성해 보자. 사용하는 정책은 아래와 같다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}
역할을 인스턴스에 부여하고 인스턴스 내부에서 패키지를 설치해야 한다.
나는 이미 이전에 테스트로 설치해 뒀다.
설치로그이다.
Nov 18 17:17:19 Installed: aws-cli-plugin-cloudwatch-logs-1.4.4-1.amzn2.0.1.noarch
Nov 18 17:17:20 Installed: awslogs-1.1.4-3.amzn2.noarch
실제 설치방법은 yum install 이나 wget 으로 받아 실행하는 방법이 있다.
# yum install awslogs -y
or
# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
# python ./awslogs-agent-setup.py --region ap-northeast-2
리전지정 옵션을 넣어주는게 좋다 그렇지 않으면 따로 지정해야 한다.
# vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-2
그리고 cloudwatch 로 전송할 로그를 지정한다.
# vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG
테스트를 위해 /var/log/messages 를 cloudwatch 로 전송하는 로그이다.
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG
세개의 옵션이 중요하다. end_of_file 은 뒤부터 추가되는 로그를 watch 로 전송한다.
amazon linux 2 는 systemctl 명령어로 서비스를 시작한다
# systemctl restart awslogsd
설정대로 로그가 올라 오는게 보인다.
중요한 부분은 이벤트 만료시점을 지정해서 로그로 전송된 용량이 과하게 쌓이지 않도록 해야한다.
로그 그룹을 체크하면 지표 필터 생성 버튼이 활성화 되고 지표를 생성한다.
지표는 대충 만들어 볼까한다.
HealthCheck 라는 이름으로 패턴을 설정했다. 보면 샘플로그에서 일치하는 패턴이 보인다. 그리고 지표를 할당한다.
지표생성은 커스텀 매트릭으로 비용이 발생할수 있으니 조심하도록 하자.
생성된 지표를 확인하면 위와같다. 그럼 지표를 확인해보자.
커스텀메트릭이 정상적으로 만들어진걸 확인할수 있다.
그래프도 잘생성 됬는지 보면 잘 올라오는게 보인다. 그럼 실제 로그가 발생해서 그래프가 생성됬는지 확인해보자.
로그가 올라와서 매트릭이 생성된것을 확인할수 있다. 그럼이제 경보를 생성해 보자.
뭔가 훅지나간거 같겠지만 빠진부분은 sns 설정 뿐이다. SNS는 주제를 만들고 구독을 생성하고 구독으로 watch 에서 sns를 추가하면 된다.
경보생성하는 방법은 따로 자세하게 설명하겠다. 블로깅이 시리즈 물이 될 기미가 보인다.
그래프처럼 임계치를 지나서 경보상태로 변경됬다가 정상으로 업데이트가 되는 과정이 보인다 정상적으로 지표로 경보가 작동하는것 까지 확인 되었다.
오늘의 목표인 로그전송으로 지표생성 후 경보 생성까지 완료되었다.
이케이스는 tomcat log로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.
자세하게 만들고 싶었는데 흐름만 구성한거 같아 좀 찜찜한 부분은 차차 보강하겠다.
읽어주셔 감사하다!
서울-도쿄 리전간 레이턴시 줄이기-실패경험담
페이스북 AKUG에서 다음과 같은 포스팅을 봤다.
처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.
EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.
한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.
AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?
그런 궁금증이었다.
엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.
테스트 방식은 총4가지였다
openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping
openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping
openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping
openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping
AWS Global Accelerator 셋팅은 아주 간단하다.
Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.
생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.
그럼 테스트로 넘어간다.
가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.
172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms
C:>tcping.exe -n 100 172.31.26.253 22
Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms
가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.
172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms
Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms
평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.
tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.
ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.
구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.
피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.
피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.
현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.
사실 이때쯤 테스트가 잘못된것을 알았다.
--- 172.29.0.110 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms
vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.
망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.
이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.
다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.
172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms
Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..
그래서 한번더 했다.
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms
늘어지네... 39/ 60 / 64
172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms
40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.
실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까...
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.
10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms
Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms
141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.
10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms
Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms
126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.
한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.
물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.
하지만..여기서 끝내기엔 너무 아쉬웠다. 하.
또 한국리전에 최근에 적용된 기능이 생각났다.
이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.
하지만 얻게된 aws의 내부 망에 대한 추측이다.
서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.
오늘의 우승 구성은 " openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping " 이다.
오늘은 도쿄에 테스트 했으니까 사요나라!
centos8 rdate의 행방
지금까지 rdate로 시간동기화를 강제로 맞췄다.
ntp를 써도 됬지만 centos5에서 적응한 방식이라 레거시에서 벗어날수 없었다.
ansible 테스트중에 알게됬다.
rdate 가 설치되지 않았다.
TASK [rdate] *
fatal: [13.125.94.121]: FAILED! => {"changed": false, "failures": ["rdate 일치하는 패키지 없음"], "msg": "Failed to install some of the specified packages", "rc": 1, "results": []}
…ignoring
centos8 은 4점대 커널이다. centos7은 3점대고.
이커널 차이에서 오는 가장 큰차이점은 ntp 가 기본이냐, chronyd가 기본이냐다.
centos8 부턴 chronyd 기본지원이므로 이전과 같이 불편하게 설정하지 않아도 될것같다.
[root@ip-172-31-45-50] ~# uname -a
Linux ip-172-31-45-50.ap-northeast-2.compute.internal 4.18.0-80.7.1.el8_0.x86_64 #1 SMP Sat Aug 3 15:14:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@ip-172-31-45-50] ~# rpm -qa | grep chronyd
[root@ip-172-31-45-50] ~# rpm -qa | grep chrony
chrony-3.3-3.el8.x86_64
ansible role file module error
ansible 테스트중에 지속적으로 file 모듈에서 에러가 발생했다.
SSH password:
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
SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"gid": 1000,
"group": "centos",
"mode": "0755",
"owner": "centos",
"path": "/home/test",
"size": 0,
"state": "file",
"uid": 1000
}
file 모듈 문제일까 싶어서 ansible 명령어로 테스트 해보니 정상. 왜지?
그냥 배열 정리 잘해주니까 된다..
빡치네..
---
become: true
become_user: root
hosts: all
name: rdate
tasks:
- name: test
file:
mode: 766
path: /home/test
state: file
modsecurity-2.9.3 컴파일 에러
centos7 / apache 2.4.36 / mod_security 에러 발생시 해결.
https://forum.directadmin.com/showthread.php?t=56837
In file included from modsecurity.h:49:0,
from apache2_config.c:17:
msc_remote_rules.h:54:9: error: unknown type name 'apr_crypto_key_t'
apr_crypto_key_t **apr_key,
msc_remote_rules.h:55:9: error: unknown type name 'apr_crypto_t'
apr_crypto_t *f,
make[2]: *** [mod_security2_la-apache2_config.lo] Error 1
make[2]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2′
make[1]: *** [all] Error 2
make[1]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2'
make: *** [all-recursive] Error 1
처음에 진행한 config
# ./configure --with-apxs=/usr/local/apache/bin/apxs
apr 관련 에러가 발생한다.
이경우엔 apache 에서 사용하는 apr 이 apr_crypto_key_t 를 지원하지 않는것이다. 라고 생각했는데 아니었다 apr이 지정안되서 그냥 안되는거였다.
#./apachectl -V
Server version: Apache/2.2.34 (Unix)
Server built: Dec 6 2018 13:55:09
Server's Module Magic Number: 20051115:43
Server loaded: APR 1.5.2, APR-Util 1.5.4
Compiled using: APR 1.5.2, APR-Util 1.5.4
사실 그냥하면 될줄알았는데 아니더라...그래서 명시를 해준다.
# ./configure --with-apxs=/usr/local/apache/bin/apxs --with-apr=/usr/local/apache/bin/apr-1-config --with-apu=/usr/local/apache/bin/apu-1-config
잘되었다.
;;
허무하네
/usr/local/modsecurity
[root@localhost modsecurity]# ll
합계 0
drwxr-xr-x 2 root root 70 10월 4 16:11 bin
drwxr-xr-x 2 root root 30 10월 4 16:11 lib
#ll /usr/local/modsecurity/lib/mod_security2.so
-rwxr-xr-x 1 root root 2490512 10월 4 16:11 /usr/local/modsecurity/lib/mod_security2.so
잘된다.
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사용은 이유가 있다.
오늘 포스팅 주제를 선물해주신 신난 어피치님 매우 감사드린다!
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 최적화가 누군가에겐 도움이 될거라 생각한다.
좋은하루 되시라!