(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확인해 보시면 좋겠습니다. 이전 글들은 아래와 같습니다.

(1편) Route53 로그 수집을 위한 Logging Group 설정 및 CloudWatch Logs 기본 설정 살펴보기

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4

 

(2편) Route53 DNS 로그 수집을 위한 ElasticSearch Cluster만들기

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #2/4

 

앞선 두 포스팅을 잘 따라오셨다면 우리는 CloudWatch Logs의 기본적인 설정을 만들었고 AWS ElasticSearch Cluster까지 만드셨을 겁니다. 이제 만들어진 ES Cluster로 로그를 적재하기 위한 Subscription filter 구성 작업을 해보도록 하겠습니다. CloudWatch Logs의 관리 화면으로 이동하여 설정을 시작하겠습니다. 

 

Log Group에 대한 Elasticsearch subscription filter 설정하기

CloudWatch Logs 관리 화면에 진입하면 설정되어 있는 여러 Log Group 목록이 나옵니다. Log Group이 많은 경우 빠른 식별을 위해 제품 명을 Log group 이름에 넣으라고 말씀드렸던 것을 기억하시겠지요? 가이드를 잘 따라오셨다면 검색창에 키워드를 입력하여 쉽게 Log group을 찾을 수 있습니다. 

체크 박스로 로그 그룹을 선택하고 상단 `Actions` 드롭다운 메뉴를 누르겠습니다. 메뉴중 `Subscription filters`를 선택하면 4가지 필터 옵션을 선택하는 팝업이 이어집니다. 우리는 첫번째 항목으로 위치한 `Create Elasticsearch subscription filter`를 선택하겠습니다. 

필터 설정 화면은 크게 세 부분으로 나뉘어져 있습니다. 가장 첫번째 섹션은 `Choose destination`입니다. 이곳에서는 로그를 보낼 목적지를 선택하게 되는데요, 우리가 만든 AWS Elasticsearch Cluster의 도메인 이름을 이곳에 지정하게 됩니다.

AWS상에 여러개의 어카운트를 생성하여 사용하고 있다면 `Another account`를 선택하여 다른 어카운트의 ES Cluster로 로그를 전송하는 것도 가능합니다만 이 포스팅의 범위를 넘어서는 내용이니 설명은 따로 하지 않겠습니다. 우리는 기본 값인 `This account`를 선택한 상태에서 설정 작업을 진행하도록 하겠습니다. 

간혹 "만들어둔 ES Cluster가 목록에 보이지 않아요!" 라는 분들이 계십니다. ES Cluster는 결국은 EC2를 생성하고 Elasticsearch를 설치, 구동하는 것이기 때문에 생성되는데 생각보다 시간이 좀 걸립니다. 경험상 오래 걸릴때는 10분 정도까지 기다리기도 했으니 혹시나 클러스터 목록에 생성한 ES Cluster가 나오지 않는다면 조금 후에 다시 시도해 보시기 바랍니다. 리프레시 버튼이 없으니 뒤로 갔다가 다시 와야 한다는 점도 기억해 두면 좋겠네요.

첫번째 섹션 `Choose destination`에서 ES Cluster를 선택하면 화면이 늘어나면서 Lambda IAM Execution Role을 선택하라는 안내를 만나게 됩니다. 지금까지 여기저기 옮겨 다니면서 설정을 해왔는데 IAM 으로 다시 또 돌아가야 한다니... 이쯤에서 한숨을 한번 내쉬는 것이 정상입니다 ㅎㅎ 다행히도 우측에 Refresh 버튼이 있기 때문에 별도 창으로 IAM 관리 화면을 열고 Route53로그를 ElasticSearch가 잘 받을 수 있도록 Role을 만들어 보도록 하겠습니다.

그런데 갑자기 왠 Lambda일까요? Lambda가 필요한 이유는 간단합니다. Route53의 로그는 CloudWatch Logs를 통해 수집되면 gzip으로 압축된 상태로 저장됩니다. CloudWatch는 ES Cluster로 이 압축파일을 손대지 않고 그대~~로 전달합니다.. 따라서 이를 Unzip하고 ES에 주입하는 단계가 필요하고 이를 위해서 Lambda를 사용합니다. Lambda 코딩에 자신이 없다구요? 다행히도 우리가 Lambda코드를 만들 필요 없이 적당한 권한만 할당되면 미리 준비된 코드가 구동되는 방식입니다.

 

IAM에서 Lambda용 Role 설정하기

IAM 관리 화면을 별도 창으로 열어보겠습니다. 우리는 IAM의 Roles 메뉴에 진입하여 새로운 Role을 작성하도록 하겠습니다. 아래의 이미지에 나온 것처럼 Permission Policy에 우선 `AWSLambdaBasicExecutionRole`을 붙여 주겠습니다. 

(Update 2022.04.22) AWS Console이 업데이트 되면서 IAM 도 화면이 많이 변경되었습니다. 당황하지 마시고 하나씩~ 보시면서 설정하시면 오히려 더 편리하기도 합니다!

`AWSLambdaBasicExecutionRole`이라는 Managed Policy가 추가 되었다면 `Add inline policy`버튼을 눌러 아래의 JSON을 입력합니다. JSON의 내용중 Resource의 Account ID, Region ID, ES Cluster Name등은 각자의 어카운트 환경과 설정에 맞게 수정해서 넣어야 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "es:*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:es:#ES가생성된리전#:#ACCOUNT_ID#:domain/#ES도메인명#/*"
        }
    ]
}

퍼미션 설정이 되었다면 이 권한을 갖게될 계정이 신뢰할 수 있는 서비스를 지정하겠습니다. 생성된 Role을 활용하는 주체는 CloudWatch Logs가 됩니다. CloudWatch Log는 Lambda를 실행해야 하기 때문에 Trusted Relationships에는 lambda.amazonaws.com 서비스를 추가해야 합니다. JSON 기준으로 Trust relationship을 보면 아래와 같습니다. 공통 영역이니 그대로 복사해서 붙여 넣어도 무방합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

여기까지 완료되었다면 IAM Role의 설정이 완료된 것입니다. 다시 CloudWatch Logs에서 subscription filter를 선택하던 화면으로 돌아가서 Lambda IAM Execution Role 지정 영역의 Refresh 를 눌러 방금 만든 Role이 나오는지 확인합니다. 저는 기억하기 좋게 cwlogs_route53_to_es 라고 Role 이름을 지었습니다. 생성한 Role을 선택후 다음 섹션으로 넘어가겠습니다. 

(Update 2022.04.22) Lambda IAM 생성/지정하는 부분이 보이지 않는 경우 아직 OpenSearch 클러스터 생성이 완료되지 않은 것입니다. 조금 기다렸다가 다시 Subscription Filter 를 생성하시기 바랍니다.!   아래와 같은 에러가 발생하면 커피 한잔, 담배 한대 피우고 오시기 바랍니다!!!

 

로그 포맷 설정

Subscription filters 설정의 두번째 섹션인 `Configure log format and filters`에서는 로그 포맷을 정의하게 됩니다. 정의된 로그 포맷으로 규격을 맞추어 CloudWatch Logs에서 Lambda를 거쳐 ES로 로그가 전달되는 식입니다. 포맷을 별도로 정의하지 않으면 ES에서는 `@message` 컬럼으로만 로그 데이터가 저장됩니다. 따라서 저장된 로그를 조회하거나 다루기 쉽게 하려면 로그 포맷을 지정하는 것이 중요합니다. 

안타깝게도 사전에 정의된 Log format 목록에는 Route53이 CloudWatch Logs를 통해 전달하는 포맷 정보가 기본 항목으로 들어 있지 않습니다. 따라서 Log format으로 `Space Delimited`를 선택하고 2021년 8월 기준 로그에 대해서 만든 아래의 내용을 필터 패턴에 넣어주면 ElasticSearch Cluster에서 사용하기 편한 컬럼을 만들고 저장할 수 있게 됩니다.

[version, timestamp, zone_id, domain, rr_type, error, protocol, region, resolver_ip, edns0]

마지막 섹션인 `Test pattern`에서는 이미 수집되기 시작한 CloudWatch Logs의 샘플 로그를 이용하여 입력한 filter pattern이 데이터를 잘 구분해 내는지 확인해 볼 수 있습니다. 앞선 포스팅에서 확인했던 것처럼 이미 로그가 쌓이고 있을 것이기 때문에 쌓인 로그 중 하나를 선택하여 입력한 필터가 데이터를 잘 구분해 주는지 확인해 보겠습니다. 

데이터가 잘 쌓이고 있고 필터가 적당히 구성되었다면 위 그림에서 볼 수 있는 것처럼 로그를 잘 구분하고 있는 것을 확인할 수 있습니다. 이제 모든 구성이 끝났으니 화면 맨 아래의 `Start streaming`을 눌러 데이터 전송을 시작하겠습니다. 문제가 없다면 성공 메세지와 함께 Subscription filters가 생성된 것을 확인할 수 있습니다.

 

이제 4편에서 모든 구성을 마무리하고 ES 에서 데이터를 조회해 보는 일만 남았습니다.

(#4/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기