aws 에서 MariaDB galera cluster 설치하기!

오늘은 실험적인 포스팅을 하려고 한다.
mariadb galera다.

사실 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

:wq 후에 정상적으로 repo를 생성했다면 아래 설치명령어가 정상적으로 작동한다.

#yum install MariaDB-server MariaDB-client

정상적으로 설치가 되면 아래 패키지가 설치된다. yum.log에서 확인했다.

Sep 10 11:37:04 Installed: perl-Data-Dumper-2.145-3.amzn2.0.2.x86_64
Sep 10 11:37:04 Installed: MariaDB-common-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:05 Installed: MariaDB-compat-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:05 Installed: boost-program-options-1.53.0-27.amzn2.0.3.x86_64
Sep 10 11:37:06 Installed: galera-4-26.4.2-1.rhel7.el7.centos.x86_64
Sep 10 11:37:06 Installed: perl-Compress-Raw-Bzip2-2.061-3.amzn2.0.2.x86_64
Sep 10 11:37:06 Installed: ncurses-compat-libs-6.0-8.20170212.amzn2.1.2.x86_64
Sep 10 11:37:08 Installed: MariaDB-client-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:08 Installed: perl-Net-Daemon-0.48-5.amzn2.noarch
Sep 10 11:37:08 Installed: 1:perl-Compress-Raw-Zlib-2.061-4.amzn2.0.2.x86_64
Sep 10 11:37:08 Installed: perl-IO-Compress-2.061-2.amzn2.noarch
Sep 10 11:37:08 Installed: perl-PlRPC-0.2020-14.amzn2.noarch
Sep 10 11:37:08 Installed: perl-DBI-1.627-4.amzn2.0.2.x86_64
Sep 10 11:37:25 Installed: MariaDB-server-10.4.7-1.el7.centos.x86_64

설치가 완료되면 클러스터 설정을 한다.

#vi /etc/my.cnf.d/server.cnf

간단하게 테스트하기 위해 아래내용을 붙여 넣어도 좋다.

[mysql]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
bind-address=0.0.0.0
user=mysql
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW
log-error=/var/log/mysqld.logdatadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
bind-address=0.0.0.0
user=mysql
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW
log-error=/var/log/mysqld.log

같은파일 하단에 [galera] 탭에 아래 내용을 설정한다.

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_node_name='galera1'
wsrep_node_address="10.0.4.27"
wsrep_cluster_name='linuxer-galera'
wsrep_cluster_address="gcomm://10.0.4.9,10.0.4.27,10.0.4.43"
wsrep_provider_options="gcache.size=300M; gcache.page_size=300M"
wsrep_slave_threads=4
wsrep_sst_method=rsync

여기서 수정할 내용은
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의 경우엔 어떤것이 좋다 나쁘다는 아직 결정할수 있느 근거가 부족하였다.

일주일간의 시험테스트와 트러블슈팅 튜닝을 진행하면서 추가 포스팅을 진행하겠다. 읽어 주셔서 감사하다!

포스팅이 슬슬 마르기 시작한 이 시험에 흥미로운 주제를 만들어 주신 바다진주님께 감사를 드린다!

file swap 만들기

더미파일 생성

#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

생성된 파일 확인

#ll /root/swapfile
total 1580112
-rw-r--r-- 1 root root 1618031616 Sep 7 20:24 swapfile

swapfile 에 권한 생성

#chmod 600 /root/swapfile

swap 생성

#mkswap /root/swapfile
Setting up swapspace version 1, size = 1.5 GiB (1618026496 bytes)
no label, UUID=89d2f092-7fee-4fa2-854a-77a914e79367

swap 마운트

#swapon /root/swapfile
#free -m
total used free shared buff/cache available
Mem: 983 136 75 18 771 669
Swap: 1543 0 1543

swap 자동 마운트 rc.local 하단에 추가

#vi /etc/rc.local
swapon /root/swapfile

ubuntu 16.04 pam 패스워드 유효성 제한 libpam-pwquality 설정 포함

패스워드 유효성 검증

로그인 실패 5 계정 잠금 5분
#vi /etc/pam.d/common-auth
16번째줄 삽입
auth required pam_tally2.so file=/var/log/tallylog deny=5 even_deny_root unlock_time=300

#vi /etc/pam.d/common-account
16 줄에 삽입
account required pam_tally2.so

패스워드 만료 모듈 설치
#apt-get -y install libpam-pwquality

패스워드 만료 모듈의 경우에는 사용자를 새로 만들때만 영향을 줍니다.
따라서 기존유저에 적용시에는 명령어로 지정해주어야 합니다.

패스워드 사용가능 최대 기간
#chage -m (days) (user)

PASS_MAX_DAYS 180

패스워드 사용가능 최소 기간
#chage -m (days) (user)

PASS_MIN_DAYS 2

패스워드 만료전 경고 일수
#chage -W (days) (user)

PASS_WARN_AGE 7

패스워드 사용시간 제한

#vi /etc/login.defs
PASS_MAX_DAYS 180

#vi /etc/pam.d/common-password
password requisite pam_pwquality.so retry=3 minlen=10 minclass=3
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 remember=2

remember=2 2회 동안 동일한 비밀번호 생성 금지
minlen=10 비밀번호 길이 생성 제한 10자 이상으로
minclass=3 새비밀번호에 필요한 문자 클래스 수 제한 (종류 ⇒ 대문자 / 소문자 / 숫자 / 기타)

참조 URL
https://www.server-world.info/en/note?os=Ubuntu_16.04&p=password

isms 기준에 맞춘 ubuntu 16.04 ssh 패스워드 유효성 설정입니다.

apache http1.1 aws alb http2 enable error

safari 계열의 브라우저에서 내 블로그가 정상적으로 열리지 않았다.
여러번 시도해야 열렸고, 한번에 열리지 않았다.

이원인을 찾기위해서 로그분석부터 부단한 노력을했으나, 한동안 해결할수 없었다.

그런데 어제 오픈카톡방의 박주혁 님께서 safari에서 정상적으로 열리지 않는다는 스크린샷을 올려주셨다.

인증문제가 아닐까 생각했지만 인증문제는 아니었고 이문제를 해결하기 위해선 내 웹서버의 설정을 설명해야 한다.

amazon linux에서는 httpd-2.4.39-1.amzn2.0.1.x86_64이 기본으로 설치되는 apache 이다. 그리고 php는 여러가지 버전을 repo로 지원하고 있는데
amazon-linux-extras 명령어로 사용가능한 repo를 확인할수 있다.

일단 이부분에서 내가 old한 엔지니어라는 사실을 알았다.
나는 apache-php 연동은 반드시 module로 연동을 한다.
그런데 amazon linux는 amazon-linux-extras install php7.3 명령어를 사용하면 module로 설치하는 것이 아닌 php-fpm 방식으로 php가 설치된다.

그렇기에 나는 몇가지 old한 설정을 추가하였다.

apache 는 온프레미스에서 의례 사용하던 방식인 prefrok 방식으로 설정하였고, php는 fpm이 아닌 module로 셋팅하였다.

여기서 문제가 발생한것이다.
아래 URL에서 발췌한 내용이다.
HTTP/2 is supported in all multi-processing modules that come with httpd. However, if you use the prefork mpm, there will be severe restrictions.

https://httpd.apache.org/docs/trunk/howto/http2.html

http2 를 사용하려면 prefork를 사용하기 어렵다.
그런데 필자는 prefork 를 사용하였기 때문에 정상적으로 호환이 되지 않은 것이다.

aws alb(http2) - apache (prefork)강제로 http2사용

aws의 ALB는 http2를 기본으로 enable하게 되어있기때문에 정상적인 커넥션이 불가능했던것이다.

일단 급하게 ALB에서 http2를 껏다.

그리고 오늘 mpm을 event로 돌리고 http2를 강제로 사용하게 했던 설정을 빼고 php-fpm으로 웹사이트를 사용할수 있게 변경하였다.
이후엔 정상적으로 사이트가 동작했으며, 간헐적으로 열리지 않는 증상은 사라졌다.

이글을 빌어 다시한번 박주혁님께 감사를 드린다.

앓던 이가 빠진기분이다.

유레카!

ssm 과 user 디렉토리 퍼미션의 상관 관계

고객사에서 ubuntu user 에 777 퍼미션을 부여해 버렸다.

chmod -R 777 /home

home 디렉토리 하단으로 모든 퍼미션이 777이 부여되었고 ubuntu계정까지 777 권한이라 KEY를 사용하여 로그인을 할수 없는 상태가 되어버렸다.

이경우에 할수있는 방법은 SSM session manager로 접속할수 있다면 간단하게 해결되었을 문제이나 신규로 생성된 인스턴스인터라 SSM을 사용하고 있지 않았다.

이경우엔 다른인스턴스에 /home 파티션만 떼서 붙여서 권한을 복구한다음에 정상화 할수 있었다.

session manager 는 권한과 상관없이 동작하는지 확인하고 싶었다.

세션 매니저로 접속

root 15229 1.0 1.5 543752 15912 ? Sl 10:30 0:00 _ /usr/bin/ssm-session-worker root-0f7a9e1a4bbc90b i-052ebb4feade551
ssm-user 15242 0.0 0.3 124264 3280 pts/0 Ss 10:30 0:00 _ sh

쉘에서 확인시에 세션을 연결하면 위와같이 확인이된다.

유저 접속 확인

root@ip-10-0-0-12 home]# w
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

root@ip-10-0-0-12 home]# last
reboot system boot 4.14.133-113.112 Wed Aug 28 12:43 - 10:34 (21:50)

session manager 는 w나 last에서 확인할수 없다. 로그인 내역은 aws console 에서 확인해야 하고 실제로 인스턴스 내에서 확인하려면 messages 로그에서 확인해야 한다.

Aug 29 11:33:49 ip-10-0-0-12 amazon-ssm-agent: 2019-08-29 11:33:49 INFO [MessageGatewayService] [EngineProcessor] [OutOfProcExecuter] [root-0aa231b76382aca8c] channel: root-0aa231b76382aca8c not found, creatinga new file channel…

Aug 29 11:33:49 ip-10-0-0-12 amazon-ssm-agent: 2019-08-29 11:33:49 INFO [MessageGatewayService] [EngineProcessor] [OutOfProcExecuter] [root-0aa231b76382aca8c] inter process communication started

ssm 세션 생성시에 발생하는 로그다.

이제 ssm user 에 777 부여후에 정상적으로 로그인 되는지 확인해 보겠다.

root@ip-10-0-0-12 home]# chmod 777 -R ssm-user

root@ip-10-0-0-12 home]# ls -al
drwxrwxrwx 2 ssm-user ssm-user 83 Aug 20 22:27 ssm-user

root@ip-10-0-0-12 ssm-user]# ls -al
-rwxrwxrwx 1 ssm-user ssm-user 265 Aug 28 13:26 .bash_history
-rwxrwxrwx 1 ssm-user ssm-user 18 Jul 28 2018 .bash_logout
-rwxrwxrwx 1 ssm-user ssm-user 193 Jul 28 2018 .bash_profile
-rwxrwxrwx 1 ssm-user ssm-user 231 Jul 28 2018 .bashrc

정상적으로 연결되는것을 확인할 수 있었다.

key로 연결되는 계정은 권한으로 인해 접속불가 상태에 빠질수 있지만
session manager 는 인스턴스가 클라이언트가 되어 동작하는 방식이라 user 디렉토리 권한과는 상관없이 정상적으로 접근이 가능한것을 알수있다.

사실 조금 쓸데없는 테스트이긴 하나 도움이 되면 좋겠다!

아디오스!

aws ec2 instance 상태이상 확인

갑자기 블로그가 안열렸다. 따로 모니터링을 설정한건 아니라서 다운된지 몰랐다. 먼저 aws console 에서 인스턴스의 상태를 확인해 보기로 했다.

상태검사를 통과 하지못한 인스턴스가 확인된다. 이럴땐 ec2 상태검사 탭을 확인한다.

서버가 죽은지 벌써10시간째. 모니터링을 설정해 놨어야 했는데 불찰이 느껴진다. 일 단 트러블 슈팅을 시작한다.

첫번째로 로그인을 진행해 본다. ssm 세션매니저를 통해서 접속해본다.

응. 안돼. 돌아가
접속할수 없다.

그럼 차선책으로 인스턴스의 스크린샷을 확인해 본다.

인스턴스 설정에서 시스템로그 가져오기는 dmesg 를 보여준다 그래서 이경우에 필요가 없다. 인스턴스가 행이 아니라 리부팅중 멈추거나 인스턴스 부팅 장애의 경우에는 시스템 로그가져오기로 봐야한다.

메모리...메ㅗㅁㅣㄹ............!!!!!!!!!!!!!!

프리티어라 죽었다.

재시작은 안되고 인스턴스를 중지한다. 재시작이 안될경우 중지/시작을 해야한다.

EIP 가 연결되지 않은 인스턴스의 경우엔 IP가 변경된다 EIP를 붙여서 사용하자

중지중이다.
중지중에 모니터링 그래프를 확인해 본다.

며칠전 포스팅했던 cloudwatch 를 이용한 메모리와 하드디스크 체크이다.
메모리가 훅 날라간게 보인다.

리부팅 완료하고 인스턴스의 상태가 정상으로 변경되었다. 그렇다면 정확한 이유를 알아야한다.

messages 로그에서 확인한 내용이다 스왑도 없고 메모리도 없어서 죽었다.
사실 프리티어라 swap 이 없다. 이후에 파일스왑으로 2G정도 만들어줄계획이다.

Aug 27 21:19:51 ip-10-0-0-12 kernel: active_anon:214310 inactive_anon:7454 isolated_anon:0#012 active_file:326 inactive_file:360 isolated_file:0#012 unevictable:0 dirty:0 writeback:0 unstable:0#012 slab_reclaimable:3331 slab_unreclaimable:5159#012 mapped:7669 shmem:7487 pagetables:3235 bounce:0#012 free:12190 free_pcp:180 free_cma:0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 active_anon:857240kB inactive_anon:29816kB active_file:1304kB inactive_file:1440kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:30676kB dirty:0kB writeback:0kB shmem:29948kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA free:4464kB min:736kB low:920kB high:1104kB active_anon:11168kB inactive_anon:44kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:32kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kBAug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 932 932 932
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32 free:44296kB min:44316kB low:55392kB high:66468kB active_anon:846072kB inactive_anon:29772kB active_file:1304kB inactive_file:1440kB unevictable:0kB writepending:0kB present:1032192kB managed:991428kB mlocked:0kB kernel_stack:6352kB pagetables:12908kB bounce:0kB free_pcp:720kB local_pcp:720kB free_cma:0kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 0 0 0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA: 84kB (UME) 88kB (UME) 1116kB (UE) 932kB (UE) 964kB (UME) 4128kB (UE) 5256kB (UME) 1512kB (E) 11024kB (E) 02048kB 04096kB = 4464kBAug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32: 10224kB (UE) 4008kB (UE) 24116kB (UME) 13832kB (UME) 14364kB (UME) 61128kB (UE) 12256kB (ME) 13512kB (UE) 21024kB (UM) 02048kB 04096kB = 44296kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

그럼 왜 스왑도 메모리도 없었을까? 웹서버 이므로 웹로그를 확인해 보았다.

어제 급하게 포스팅하느라 업로드한 파일들을 재대로 처리못하고 죽은거다.

아놔~~~~~~~~~~~~

이후로 모니터링 체크하나 만들어서 알럿하도록 설정하는 포스팅을 작성하겠다.

좋은하루 되시라!

사이트는 잘열리는것을 확인할수 있었다!

mysql innodb extra backup 스크립트

#엑스트라 백업 설치
rpm -Uhv https://www.percona.com/redir/downloads/percona-release/redhat/percona-release-0.1-4.noarch.rpm

#yum 으로 설치
yum install xtrabackup

#디렉토리 확인
ll /backup
ll /backup/full_backup
ll /backup/incre_backup

#디렉토리 생성
mkdir /backup
mkdir /backup/full_backup
mkdir /backup/incre_backup

#crontab 에 설정
* */1 * * * root /root/bin/mysql_innodb_backup.sh


crontab 와 db_full_backup_time 은 중요합니다.스크립스트는 crontab 실행될때 백업이 되며, db_full_backup_time이 아닐경우 차등백업을 실행합니다.


따라서 1시간마다 백업을하며 db_full_backup_time이 있을경우에 full 백업을 합니다.

아래의 스크립트에서 03 15을 변수로 줄경우 배열로 받아서 참일경우 full 백업 거짓일경우 차등백업을 진행합니다.따라서 새벽 3시 오후3시에 백업을 진행 합니다. 

!/bin/bash

DB Backup

BAK_DIR=/backup;
TODAY=$(date +%Y%m%d --date '12 hours ago')

TODAY=$(date +%Y%m%d)

RMTODAY=$(date +%Y%m%d --date '10 days ago')

Delete DB File

rm -rf $BAK_DIR/full_backup/$RMTODAY*
rm -rf $BAK_DIR/incre_backup/$RMTODAY*

Backup Time

db_full_backup_time=("03 15")

Now Time & Time Check

TOTIME=$(date +%H)

TOTIME=$(date +%H)

echo $TOTIME
in_array() {
local needle array value
needle="${1}"; shift; array=("${@}")
for value in ${array[@]}; do [ "${value}" == "${needle}" ] && echo "true" && return; done
echo "false"
}

db_full_backup_check=in_array $TOTIME ${db_full_backup_time[@]}

if [ "$db_full_backup_check" == "true" ]; then
# full backup
/bin/nice -n 10 /usr/bin/ionice -c2 -n 7 /usr/bin/innobackupex --defaults-file=/etc/my.cnf \
--user=root --password='1234' --slave-info --no-timestamp \
--compress $BAK_DIR/full_backup/$TODAY
else
# hot backup
/bin/nice -n 10 /usr/bin/ionice -c2 -n 7 /usr/bin/innobackupex --defaults-file=/etc/my.cnf \
--user=root --password='1234' --no-timestamp --compress --incremental \
--incremental-basedir=$BAK_DIR/full_backup/$TODAY $BAK_DIR/incre_backup/$TODAY/$TOTIME
fi

aws cloud watch 여러대의 인스턴스에 대한 하나의 경보 생성.ver2

cloudwatch 경보생성 입니다.

여러대의 인스턴스를 하나로 묶어서 경보생성할때 사용하는 방법입니다.

경보 생성을 누릅니다.

지표 선택을 눌러서 지표를 확인합니다.이번에 경보를 생성할 지표는 "CPUUtilization"입니다.

검색하여 체크 후에 '그래프로 표시된 지표' 를 누릅니다.
표시된 지표는 9개 까지 체크하여 추가할수 있습니다.

제한사항으로

 수학표현식을 추가합니다.
수학 표현식은 상황에 따라 잘 사용하기로 바랍니다.https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/using-metric-math.html
이번에는 CPU사용량이 1대라도 70% 를 넘을 경우 경보를 생성할 것이므로 사용한 표현식은 MAX(METRICS()) 입니다.

전체를 체크할 경우 아래와 같이 지표선택 버튼이 활성화 되지 않습니다.

사용할 수학 표현식 하나만 체크해야 생성이 가능합니다.

위와같이 지표를 생성후에 경보생성은 SNS 를 사용해야 하므로 SNS 사용법은 각자 확인해보시기 바랍니다. 

즐거운 하루되세요~

maria db 개발자 내한

https://regist-event.com/event/2019/mariadb0925/regist.jsp?fbclid=IwAR0KXpypSYPBwtX4t_60OY0W-MYEkwAb1tsYooAnX9I6Xjh2FAuyUliyBxg

하..mysql, maria db 개발자가 내한한다.

my / maria 의 아버지 이기도 한 몬티!
my는 첫째 maria 는 둘째 딸이라고 한다.

자세한 내용은 몬티의 코멘트를 참조하자

https://mariadb.com/kb/en/library/why-is-the-software-called-mariadb/

시간나면 꼭보고와야지

aws system manager session manager 이용하여 ssh 접속

간단하게 설명하면 필요한것은 AmazonEC2RoleforSSM policy 로 만든 역할, s3 bucket, cloudwatch group 다.

미리 로그 쌓을 버킷, 워치 그룹, ssm 역할 생성까지 마친후에 역할을 인스턴스에 부여해주자.

session manager 같은경우엔 신기하게 aws -> ec2 로 연결하는것이 아니다.
ec2 -> session manager로 접근하는거다.

그리고 ec2에 ssm user 를 생성해 주자 계정명은 상관 없다.

그다음에 기본설정을 넣어준다

적절히 잘넣어주자.

그리고 세션을 시작하면 된다.

그럼 잘된다

장점은 인스턴스에 퍼블릭IP가 없는 상태에서도 사용이 가능하다.
key pair 나 패스워드가 없는 상태에서도 로그인이 가능하다.

단점은 쁘띠느낌이 없다는걸까...