[AWS] 서버 상태 실시간 모니터링: CloudWatch를 이용한 Nginx 액세스 로그 분석 및 대시보드 구축하기

 

 

AWS에서 서비스를 운영하다 보면, 서버의 상태를 실시간으로 파악하는 것이 얼마나 중요한지 잘 알게 될 것이다.

 

특히 웹 서버인 NGINX에서 발생하는 액세스 로그를 분석하고 모니터링하는 것은, 

 

서비스의 성능을 유지하고 사용자 경험을 개선하는 데 필수적이다. 

 

그런데 많은 사람들이 이런 중요한 데이터를 어떻게 효과적으로 수집하고 분석할 수 있는지에 대해 궁금해 하는데

 

여기서 AWS의 CloudWatch Logs가 빛을 발한다.

 

CloudWatch Logs는 로그 데이터를 실시간으로 수집하고, 저장하며, 접근할 수 있게 해주는 서비스이다.

 

 

내가 서비스중인 앱에 최근에 유저가 5배 가량 확 증가하면서 사용자 경험을 개선하고, 서비스를 더욱 최적화하기 위해서 구축하기로 했다.

 

이제 AWS의 NGINX 액세스 로그를 CloudWatch Logs로 전송하는 과정을 단계별로 자세하게 알아보자.

 

 

IAM 역할 생성 및 EC2 인스턴스에 할당하기

 

AWS에서 서비스 간 통신을 위해 IAM 역할이 필수적이다. 

 

CloudWatch Logs에 로그를 보낼 수 있도록 EC2 인스턴스에 권한을 부여하는 것부터 시작해보자. 

 

IAM 콘솔에 접속하여 역할(Role) 섹션으로 이동하자.

 

여기서 "새 역할 생성(Create new role)"을 선택한다.

 

AWS 서비스를 선택하고, 사용 사례로 EC2를 선택한 다음, "권한(Next: Permissions)"을 클릭한다.

 

 

CloudWatchLogsFullAccess 정책을 검색해서 선택하고, 역할 이름을 지정한 후 역할을 생성한다.

 

이렇게 하면 EC2 인스턴스가 CloudWatch Logs에 로그를 보낼 권한을 갖게 된다.

 

생성된 IAM 역할을 EC2 인스턴스에 할당해야 한다.

 

 

EC2 대시보드에서 인스턴스를 선택하고 작업 -> 보안 -> IAM 역할 수정으로 이동해서 새로 생성한 역할을 선택하면 된다!

 

 

CloudWatch Logs Agent 설치 및 구성하기

 

EC2 인스턴스에서 로그를 수집하고 CloudWatch로 전송하기 위해선 CloudWatch Logs Agent가 필요하다.

 

Ubuntu 기반의 시스템에서는 CloudWatch Unified Agent를 설치하고 구성하는 과정을 따라야 한다.

 

 

- AWS CLI 설치하기

 

먼저, EC2 인스턴스에 AWS CLI가 설치되어 있는지 확인해야 한다.

 

설치되어 있지 않다면 다음 명령어로 설치할 수 있다.

 

sudo apt-get update
sudo apt-get install awscli -y

 

 

- CloudWatch Logs Agent 설치하기

 

이제 CloudWatch Unified Agent를 설치할 차례다.

 

홈 디렉토리로 이동한 후, 다음 명령어를 실행해서 Agent를 다운로드하고 설치하자.

 

cd ~

wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

sudo dpkg -i amazon-cloudwatch-agent.deb

 

 

- CloudWatch Agent 구성하기

 

CloudWatch Agent를 설치한 후, 로그와 메트릭을 CloudWatch로 보낼 수 있도록 구성해야 한다.

 

이 과정에서 로그 파일의 위치, 로그 그룹 및 스트림 이름 등을 지정할 수 있다.

 

구성 파일을 직접 수정하거나 구성 마법사를 사용할 수 있다.

 

구성 마법사를 사용하려면 다음 명령어를 실행하자.

 

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

 

또는, 구성 파일을 직접 편집하고 싶다면 다음 명령어를 실행하자.

 

sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

 

여기서는 NGINX 액세스 로그 파일의 경로, 로그 그룹 이름 등을 지정해야 한다.

 

 

간단한 예시를 보자.

 

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "cwagent"
    },
    "metrics": {
        "metrics_collected": {
            "disk": {
                "measurement": [
                    "used_percent"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    },
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/nginx/**액세스 로그 파일**",
                        "log_group_name": "**원하는 로그 그룹 이름**",
                        "log_stream_name": "{instance_id}",
                        "timezone": "Local"
                    }
                ]
            }
        }
    }
}

 

위의 "file_path" 와 "log_group_name"만 알아서 자신의 환경에 맞게 적절하게 입력 해준다. 

 

 

CloudWatch Agent 실행 및 모니터링

 

구성이 완료된 후, CloudWatch Agent를 시작해야 로그가 CloudWatch로 전송된다.

 

Agent를 시작하기 위해 다음 명령어를 실행하자.

 

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

 

로그를 확인하거나, Agent의 상태를 확인하고 싶다면 다음 명령어를 실행하자.

 

sudo systemctl status amazon-cloudwatch-agent

 

설정을 변경해서 재시작을 하고 싶다면 다음 명령어를 실행하자.

 

sudo systemctl restart amazon-cloudwatch-agent

 

 

 

로그 모니터링 및 분석

 

이제 설정은 모두 끝나서 확인을 하러 가보자.

 

CloudWatch > 로그그룹 > 아까 설정하면서 만든 로그그룹 선택

 

 

이제 하단에 로그 스트림에 자동으로 추가가 되어 있을 것이다.

 

눌러서 들어가보자.

 

 

정상적으로 Nginx 액세스 로그가 쌓이는 중이다!!!

 

이제 해당 로그값들을 보기 쉽게 대시보드에 구축을 해보자.

 

 

다양한 지표 분석 및 대시보드 구축하기 

 

CloudWatch > 대시보드 생성 > "+" 버튼 클릭

 

 

로그 유형에서 원하는 위젯을 골라주자.

 

그 다음, Logs Insights에 들어왔으면 내가 아까 만든 로그그룹을 선택한다.

 

이제 쿼리를 짜면 되는데 이전에 로그 스트림에서 나왔던 로그 형식을 참고해서 쿼리를 작성하자.

 

한가지 예시를 보여주자면

 

나는 "응답시간이 1초를 초과하는 요청 수"를 만들었다.

 

parse @message "* - - [*] \"*\" * * \"*\" \"*\" *" as ip_address, timestamp, request, status, body_bytes_sent, referer, user_agent, upstream_response_time
| filter user_agent != "ELB-HealthChecker/2.0"
| filter upstream_response_time > 1.0
| stats count() by bin(10m)

 

 

 

이런식으로 "응답시간 1초를 초과하는 요청 수" 의 합을 막대 그래프로 뽑아서,

 

어느시간에 요청이 전반적으로 느려졌는지 구했다!

 

이제 그래프 우측 상단에 "대시보드에 추가"를 하면 끝이다.

 

 

CloudWatch Nginx access log

 

추가로 나는 우선 4가지를 더 만들었다.

 

흔히들 HTTP status를 가지고 대시보드로 많이 만들던데 지금 서비스에 status가 문제가 있어서... 다른걸 이용했다.

 

 

- 평균 응답 시간 

 

평균 응답 시간을 모니터링함으로써, 우리는 서버가 얼마나 빠르게 사용자의 요청에 반응하는지를 파악할 수 있다.

 

이는 애플리케이션의 성능을 실시간으로 감시하고, 필요한 경우 즉시 개선 조치를 취할 수 있는 근거를 제공해준다.

 

 

- 요청 수 

 

전체 요청 수를 추적하는 것은 우리에게 웹 애플리케이션에 대한 사용자 트래픽의 양과 패턴을 이해할 수 있는 통찰력을 준다. 

 

이 정보를 활용함으로써, 우리는 서버 용량을 적절히 계획하고 조정하여 사용자 경험을 최적화할 수 있다.

 

 

- 특정 IP 주소로부터의 요청 수 

 

특정 IP 주소로부터 오는 요청 수를 모니터링함으로써, 우리는 비정상적인 트래픽 패턴이나 의심스러운 행동을 조기에 탐지할 수 있다.

 

이는 서비스의 보안 위협에 대응하고, 안정성을 유지하는 데 큰 도움이 된다.

 

 

- 응답시간이 1초를 초과하는 요청 수 

 

응답 시간이 1초를 초과하는 요청의 수를 분석함으로써, 우리는 사용자 경험에 부정적인 영향을 미치는 느린 요청을 식별할 수 있다.

 

이 데이터를 기반으로 성능 최적화를 진행함으로써, 전반적인 서비스 품질을 개선할 수 있는 기회를 얻게 된다.