태그 Archives: EC2

AWS 서버 발생 로그의 분리 보관 (amazon-cloudwatch-agent)

서버내 dbus -> rsyslogd 에 의해 수집된 시스템 로그는 /var/log 아래에 파일 형태로 저장 된다.

이는 /etc/logrotate.conf 설정에 따라 서버내에 보관이 된다.

 

다만 보관된 파일의 파일 형태로 저장되어 있기 때문에 구조만 알고 있다면 파일을 삭제 하거나 변조 할 수 있으므로

추후 추적을 용의 하게 하기 위해, 데이터 무결성을 보장하기 위해, 혹은 다중의 서버의 데이터를 모아서 보관 하기위해 log 콜렉팅을 하는것이 일반적인 보안 방법 이다.

 

단순한 rsyslogd 를 이용한 udp 푸시 및 graylog collecting 은 기존에 설명을 했지만

AWS 상에서는 CloudWatch Log 라는 기능을 제공 한다 이를 통해 지표 형태로 보거나 알람 설정등을 할 수 있다.

 

서버에서는 CloudWatch log 쪽으로 데이터를 넣어주는 프로그램을 설치해서 운용 하며 이후

Log 파일의 안전한 분리 보관, 보관 주기 설정, 알람 설정 등을 웹 콘솔상에서 편하게 진행할 수 있다.

 

기존에 centos 7 에서는 yum 을 이용하여 awslogs 라는 프로그램을 설치하여 같은 기능을 사용하고 있었으나

Rockylinux 8 에서는 dnf 패키지가 없는 관계로 RPM 설치를 필요로 한다.


AWS 웹콘솔 에서 IAM 메뉴의 Role (역할) 을 생성 하고 권한을 부여 한다. (중간에 권한은 지정하지 않고 생성 하고 추후 인라인 정책으로 생성 한다.)

2022-04-08_161452 2022-04-08_161613 2022-04-08_162326

 

인라인 정책을 생성 한다. (생성한 정책이 다른 계정 이나 역할에 공통으로 부여할 필요하 있으면 일반 정책 생성 후 연결 한다.)

2022-04-08_162608 2022-04-08_163101 2022-04-08_163232

위 json 정책은 ap-northeast-2 (서울) 리전에 로그 를 쌓는 기능만 허용 하는것으로 제한 하였다.

 

생성된 Role (역할) 을 필요한 EC2에 연결 한다.

2022-04-08_164417 2022-04-08_164648

 

위에서 이야기 했지만 yum(dnf) 설치가 RockyLinux 8 에서 되지 않는다. 때문에 AWS 에서 배포 하는 rpm 파일을 가지고 설치를 진행 한다. (amazon-cloudwatch-agent  설치 메뉴얼)

 

편리하게 사용하라고 대화식 명령어를 실행 하도록 되어 있다.
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

하지만 문답 형식의 영어를 읽기도 귀찮고(어렵고) Role (정책)을 부여하여 키없이 로그를 쌓게 하고자 했으나

스크립트에서는 필수적으로 Access Key/Secret Key 를 입력 해야 하는 부분이 있기 때문에 스크립트로 진행이 어렵다.

때문에 /opt/aws/amazon-cloudwatch-agent/bin/config.json 파일을 직접 수정 해 준다. (amazon-cloudwatch-agent 설정 메뉴얼)

위 예제는 apache, php, nginx 등을 dnf(yum) 설치를 한경우 일반 적인 log 포멧의 timestamp를 인식 하도록 정리한 것이다. (secure, message 로그 및 apache, nginx, php-fpm 로그)

필요에 따라 수정을 해서 사용 하도록 한다.

 

이후 다음 명령어로 설정된 config.json 을 점검 하고 문제가 없다면 자동으로 서비스가 시작된다.

 

웹 콘솔 에서 Cloudwatch > 로그 그룹에서 보관 기간 을 설정 하고 로그 데이터가 잘 적재 되고 있는지 확인 한다.

2022-04-08_1810182022-04-08_1649512022-04-08_181557

AWS 클라우드 인스턴스 크기 선택

물리서버에서 오랜 경험이 있는 엔지니어의 경우

일반적으로 서버 사양 선택을 직접 하지 않거나 구매 시점의 가장 가성비가 좋은 일반적인 구매(보통 판매자 추천) 사양을 사용하여

서비스 구현을 하기 마련이므로 클라우드 진입을 고려할때 일반적으로 인스턴스 크기 선택 장애가 발생 한다.

 

그럼 클라우드로 넘어갈때 가장 중요한 인스턴스 선택은 무엇으로 해야 하는가?

 

1. 웹서버 ( prefork )

웹서버는 일반적인 운영 환경에서는 1% 미만의 load 가 발생한다.

마더 프로세스 에서 차일드 프로세스를 호출하기때문에 기본적으로 멀티쓰레드화 되어 있다.

mod_php 를 사용할 경우 메모리 사용량은 프로세스당 14.7MB 정도이다. (물론 더 커지기도 한다.)

HTTPD 메모리 사용량 체크

Prefork 기본 mpm 설정상 150 커넥션을 활성화 하기 때문에 2,100MB 의 메모리 용량이 필요로 하다.

구글링을 통해 검색하여 max client 값을 1024 등으로 설정 했다면 최소 15G 의 메모리를 필요로 한다. (저런거 따라하지 맙시다.)

MaxConnectionsPerChild 는 지정된 횟수 만큼의 커넥션을 처리하고 프로세스가 종료 되고 새로운 차일드가 생성되도록 하는 옵션이다.

프로세스는 어려 작업을 실행함에 따라 메모리 사용량으 증가하고 이 값을 0 으로 하거나 너무 크게 잢을 경우 메모리 부족에 허덕이게 된다.

반면 너무 작게 할경우 차일드를 종료 하고 새롭세 스폰 할때 오버 헤드가 발생하여 cpu 사용량을 늘어나 악 영향을 준다.

prefork 에서의 추천하는 값은 5000 정도…

 

2. 웹서버 ( worker / event )

Worker/event mpm의 경우 기본적으로 250 커넥션을 가지며 1개의 차일드가 25개의 커넥션을 담당 한다.

즉 10개의 차일드가 각각 25커넥션을 담당 하며 각 차일드의 메모리 사용량은 적당한 평균치가 없다. 너무 격차가 심하기 때문에..

다만 사용하는 메모리는 prefork 대비 작은편이고 약 1024 커넥션의 경우 12기가 정도의 메모리 사용량을 확인한 적이 있다.

MaxConnectionsPerChild 는 약 50000 정도가 적당 하였다.

 

3. 웹서버 ( nginx )

메모리 사용량은 비 튜닝 기준으로 120~150MB 정도 이다.

일반적으로 정적 데이터 처리 및 Revers Proxy 용도로 사용 했다.

rewrite 룰셋을 바꿔야 하는 불편한 점이 있기 때문에 다중 사이트 보다는 한개의 사이트를 운영하기엔 유리 하다.

 

4. 웹서버 ( tomcat )

tomcat 은 기본값으로 200 connect 를 처리할 수 있으며 메모리 사용량은 500 MB 이상이며 일반적인 사용에서 900MB 정도의 메모리 사용량을 보인다.

 

5. DB 서버( mysql )

cpu와 메모리를 많이 사용한다.

프로세스를 보고 있으면 50% 는 기본적으로 먹고 간다. 기본값에서는 기본 메모리 500M 정도를 사용하고 DB가 증가함에 따라 사용량이 늘어 난다.


AWS 클라우드 에서 범용 상품군은 크게 t2, m4, m5, c4, c5 이다.

이중 t2 상품군의 경우 기본적으로 다른 상품군 보다 저렴 하지만.. cpu 과점이 될경우 추가 사용료가 청구 된다.

 

AWS 테스트 서버를 올리고 (일반적으로 free tier 인 t2.micro) 사용하다 방치하게 될 경우 해킹을 통해 CPU 가 과점상태가 되어 막대한 추가 비용이 발생 한다.

 

CPU가 과다 사용되는 DB 서버의 경우에는 c4, c5 상품군 혹은 r4 상품군이 적합하다고 볼수 있다.

( RDS 서비스도 좋다. ec2 직접 구성 보단 약 10%~20% 가량 비싸지만 백업등등 생각하면 동등 하다고 본다. )

웹서버는 과도한 로드가 발생하지 않을 경우 t2 에서 충분하다 (cpu가 nano = 5% / micro = 10% 미만으로 사용 해야 한다.)

표는 aws 메뉴얼에서  확인할 수 있다.

 

리눅스는 기본적으로 자체 커널을 위해 약 300M~500M 정도의 메모리 사용한다.

nginx + php 만 구성하여 웹서버를 구성하면 약 t2.micro/t2.small 정도면 충분하다.

예약 인스턴스 (1년 선납) 을 한다고 하면 약 40% 정도 할인이 된다. (3년은 60% 정도 할인…)

2018-07-23_144957

한 서버에 DB 및 웹서버를 사용하려면 t2.medium 정도는 사용해야 한다. (cpu 크레딧 사용량이 40% ) ( $504.576 )

그이상은 t2.large 부터는 전혀 효용 가치가 없다 다른 상품군( m5.large )이 가성비가 더 쓸만하다고 생각된다.

 

스타트업 기업에서는

t2.medium/c5.large 으로 LAMP (Linux – Apache – Mysql – PHP)  로 사용하다가

추후 DB 를 분리한다는 구조로 가는게 적합 한듯 하다.

1 클라이언트는 서버에 8개의 tcp 를 동시 접속 하기 때문에 ServerLimit 는 8배로 지정 한다. (최대값 2000)

(4G 메모리 분배 : 커널 500M / Mysql 1G / Apache 2G / 버퍼 500M ) ( 동시 접속자수( Maxclient: 130 // ServerLImit : 1040 ) 정도의 값을 지향한다.
(8G 메모리 분배 : 커널 500M / Mysql 2G / Apache 4.2G / 버퍼 800M ) ( 동시 접속자수( Maxclient: 320 // ServerLImit : 2000 ) 정도의 값을 지향한다.

 

기존 물리서버에서 클라우드로의 이행을 생각한다면 위 표를 참조로 필요 대수와 발생 금액등을 생각한다.

물리서버의 평균 수명인 3년 금액 과 클라우드 3년 사용료를 비용 을 대조 하고

클라우드의 +@인 관리 편의, 백업 편의, 가용성 등을 고려하여 잘 생각한다.