ALB Access Log
ALB Access Log는 말 그대로 단순 트래픽 로그다.
로드밸런서 DNS를 통해 사용자들이 로드밸런서를 경유해 인스턴스로 접속할때 기록된다.
이 로그를 통해 ELB-respose, Target-response, Client, 접근 경로 등을 알 수 있어서, 클라우드 환경에서 서비스를 올린다면 자주 접해야 하는 로그이다.
하지만 Access Log를 통해 Client의 요청이 어디까지 도달했는지, 무슨 에러를 뱉었는지, 어떤 요청을 했을 때 어떤 반응을 보였는지 ..등 대략적인 추측이 가능하나, 정확한 점검을 위해선 어플리케이션 점검이 필수적이다.
ALB Access Log 특징으로는 다음과 같다.
- Timstamp는 UTC 기준 : KST 기준이 아니므로 특정 시간대의 트래픽 로그를 찾을 때, 그 로그는 그 전날 혹은 그다음 날 이름의 로그 데이터에 쌓여있을 수 있다.
- ALB Access Log는 5분 단위로 저장 : 예를 들어 08:03에 발생한 트래픽은 08:00~08:05 사이로 08:05 기준 트래픽에 저장된다.
- Network Interface 마다 나눠져서 저장 : 내부적으로 ALB가 Scale-Out 되면 그 수만큼 나눠져서 저장된다. 따라서 특정 시간대에 트래픽을 분석하려 한다면 모든 Network Interface를 분석해야 한다.
ALB Access Log 활성화 및 S3 저장 설정
보통 이러한 로그 파일들은 시간이 지나면 지날수록 대용량이 되기 때문에 보통 S3 버킷에다가 저장하는 편이다.
로그 기능 활성화에 추가 요금은 없으며 로그 저장을 위한 S3 버킷 과금만 발생하니 웹서비스를 운영한다면 웬만해선 설정해주는 것이 좋다.
이번 시간에는 ELB(ALB) 엑세스 로그 기록을 활성화 하고, 로그 파일들을 자동으로 S3 버킷에 업로드하도록 설정해보도록 하자.
ELB(Application Load Balancer) 만들기
EC2 인스턴스 2개와 로드밸런서를 준비한다.
다음 포스팅에 로드밸런서 실전 구축 세팅에 대해 자세히 나열되어있다.
버킷 생성 & 버킷 정책 설정
필자는 athena-log-test-11 라는 버킷을 만들어주었다.
그리고 버킷정책으로는 다음 json에 <> 꺾쇠 괄호 부분만 자신의 AWS 서버에 맞게 바꿔주면 된다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<elb-account-id>:root"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<버킷명>/<경로>/AWSLogs/<your-aws-account-id>/*"
},
{
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elb.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::<버킷명>"
}
]
}- elb-account-id 입력값으로 다음 표를 참고해 자신의 Region에 맞게 ELB ID를 적어준다.
- your-aws-account-id 입력값으로 자신의 계정 ID 넘버를 적어주면 된다. (- 를 지우고 숫자만 적는다.)
ALB Access Log 활성화 하기
버킷 정책이 완료되었으면, 다음으로 ELB > Description > Attributes 에서 Access logs 를 활성화 시켜주도록 한다.
Tip
위에서 정책 설정이 제대로 안되있으면 활성화 자체가 안되니 정책을 다시 확인해보자.
문제없이 설정이 되면, 다음 엑세스 로그 S3 위치가 설정된다.
버킷에서 ALB 로그 확인
ALB 액세스 로그 활성화가 완료되면 지정했던 S3 버킷 경로로 가서 ELBAccessLogTestFile이 있는지 확인해주자.
파일이 있으면 제대로 연동된 것이다.
그리고 로드밸런서를 통해 인스턴스로 접속을 해보면, elasticloadbalancing 폴더가 생기게 되고, 안에는 날짜별로 폴더가 생성되어 로그가 .gz 로 압축되어 저장되어진다.
Tip
로드밸런서로 접속했다고 바로는 로그가 쌓이지 않는다. 조금 기다리면 보일 것이다.
압축파일을 열어보면 다음과 같이 접속 로그가 기록되어 있음을 확인 할 수 있다.
알집은 에러 발생, 7-Zip 사용할것!!
ALB Access Log 분석하기
ALB 로그를 살펴보면 여러 문자열들이 나열되어있는데, 띄어쓰기(공백)을 기준으로 다음과 같은 포맷 순서대로 이루어져 있다.
| [type] [time] [elb] [client:port] [target:port] [request_processing_time] [target_processing_time] [response_processing_time] [elb_status_code] [target_status_code] [received_bytes] [sent_bytes] ["request"] ["user_agent"] [ssl_cipher] [ssl_protocol] [target_group_arn] ["trace_id"] ["domain_name"] ["chosen_cert_arn"] [matched_rule_priority] [request_creation_time] ["actions_executed"] ["redirect_url"] ["error_reason"] ["target:port_list"] ["target_status_code_list"] ["classification"] ["classification_reason"] |
따라서 위의 로그내용을 간단하게 해석하자면 다음과 같이 정의 할 수 있다.
- [type] : http 통신
- [time] : 2022-06-30T08:39:27.826379Z 시간대에 발생
- [elb] : app/My-ALB/ad19e4d486c5dda6 인스턴스로 요청
- [client:port] : 45.83.67.165:4450
- [target:port] : 10.0.1.153:80
- [elb_status_code] : 200 (성공)
- [target_status_code] : 200 (성공)
- ... etc
로그 내용 중에 주목해야 할 것은 elb와 target의 status code 값이다.
여기서는 모두 200을 반환해 문제는 없지만 만약Target 서버로부터 다음 에러코드가 기록됐다면 해당 서버에 운영 중인 어플리케이션을 점검해야 한다.
- 400, 404 : Client가 잘못된 요청을 보냈을 때
- 460 : Client로부터 요청을 중간에 끊었을 경우
- 502 : Client의 요청을 로드밸런서가 읽지 못했거나 Target 서버가 TCP RST/FIN을 수신할 경우
- 503 : 사용량 폭증으로 로드밸런서에 과부하게 생겼을 경우 (Scale-Out 되기도 전부터 사용량 급증)
- 504 : Client의 요청이 너무 오래 걸리는 경우, 어떠한 Target 서버가 강제적으로 Client의 요청을 끊을 경우
...하지만 저 길다란 문자열을 오로지 눈으로만 쫓기에는 매우 피곤하다.
따라서 아마존에서는 Athena 라는 서비스를 제공한다.
AWS Athena는 S3에 저장된 log 파일들을 데이터베이스(테이블)화 하여, SQL로 로그를 조회할 수 있게 하는 서비스이다.
Athena 서비스에 관심이 있다면 다음 카테고리를 참고해보도록 하자.
Athena 에서 로그 테이블을 조회하는 화면