DEVOCEAN

시작하면서

지난 글에서 Amazon QuickSight에 대해서 소개 및 데이터 Sourcing에서 대쉬보드까지 구성하는 절차를 진행/설명드렸습니다.

QuickSight가 생소하다면 이전 글을 먼저 참고해주세요.

• Amazon QuickSight 로 데이터 시각화 하기 1편 - https://devocean.sk.com/blog/techBoardDetail.do?ID=166010

분석과 모니터링 그리고 대상

Quicksight는 분석도구에 더 가깝습니다. 하지만 어떻게 구성하느냐에 따라 다른데요.

실시간성을 주기적인 데이터 Feeding으로 보장하고 데이터 처리에 지연이 없게 성능 부분을 해결한다면 실시간 모니터링에도 활용 가능합니다.

이번에는 분석에 좀 더 가까운 ALB(Application Load Balancer) Access Log를 모니터링/분석 하는 절차를 진행해 보겠습니다.

구조 및 전체 단계

ALB Access Log 활성화

ALB는 Application Load Balancer 로 트래픽을 받아서 URL 기반으로 다수의 노드가 묶여 있는 Target Group에 특정 Port로 트래픽을 분배해 줍니다.

이런 기능으로 인해 모든 유입되는 트래픽의 초기 진입점이 되고 모든 트래픽이 지나가는 관문이 됩니다.

따라서 ALB에서 Logging을 하게 되면 모든 트래픽에 대한 정보를 수집할 수 있게 됩니다.

ALB Access log 활성화는 다음 경로에서 수정 가능합니다.

EC2 > Load Balancers > LB 선택 > Attributes > Edit > 활성화 후 S3 URI 경로 지정

위 설정을 한 후에는 추가로 ALB가 S3에 Access Log를 쌓을 수 있는 권한을 줘야 합니다. S3 버킷 정책에 ALB가 S3 주요 Action을 할 수 있게 하는 권한은 다음과 같습니다.[1]

(서울리전 기준) 다른 리전은 이에 맞는 Account ID를 부여하고 있습니다. ALB에 Account ID가 부여되어 있다는 점이 특이합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::600734575887:root"
      },
      "Action": "s3:PutObject",
      "Resource": "my-s3-arn"
    }
  ]
}

위와 같이 설정 후 트래픽이 들어오게 되면 S3에 다음 경로에 일정 시간 단위(기본 5분)로 로깅 파일이 압축되어 생성됩니다.

Amazon S3 > Buckets > 버킷명 > 하위 지정 패스 경로 > AWSLogs > 계정번호 > elasticloadblancing > 리전명 > 년 > 월 > 일

만약, QuickSight가 아니고 나는 Cloudwatch에서 메트릭을 수집하고 구성하고 싶다면 Lambda를 중간에 구성해서 CloudWatch Loggroup으로 해당 로그를 전달할 수도 있는데요.

다음 사이트(Forwards logs from AWS S3 to AWS CloudWatch real time[2])를 참고하면 쉽게 구성할 수 있습니다. 구성도는 아래 참고 바랍니다.

Access Log 전처리가 필요하다면

ALB Access Log 정해진 형태로 데이터는 쌓이게 됩니다.[3] 잘 Formatting이 되어 있어서 기본적인 데이터 전처리는 필요 없습니다.

하지만 이 데이터를 가지고 분석하다 보면 이건 전처리 했었으면 좋겠다는 값들이 생기게 됩니다.

대표적인 예로는 현재 ALB Log는 UTC 기준으로 로깅이 기록되는데 KST로 바꾼다든지, 처리 시간에 응답이 없을 경우 "-"로 기록되는데 이부분을 다른 값으로 대체한다든지,

request URL 문자열을 편집, 저장 파일 타입을 parquet로 해서 성능 향상, 해당 로그와 연계해서 다른 로그를 join한다든지의 필요가 생길 수 있습니다.

Quicksight에서 데이터 전처리를 할 수도 있지만,

일반적으로 Access Log는 다량의 데이터이기 때문에 기본적인 필수 전처리가 있다면

S3 -> lambda -> New S3 Pipeline을 구성해서 전처리를 하면 QuickSight에서 대쉬보드 성능을 올릴 수 있습니다.

아래는 S3에 쌓인 Access log를 읽어서 KST로 바꾸는 python code 일부 입니다.

def process_log_file(bucket, key):
    # Download the gzipped log file from S3
    response = s3.get_object(Bucket=bucket, Key=key)
    gzipped_content = response['Body'].read()
  
    # Decompress the log file
    with gzip.GzipFile(fileobj=io.BytesIO(gzipped_content)) as f:
        log_content = f.read().decode('utf-8')
          
    # Process each line in the log file
    modified_log_lines = []
    for line in log_content.splitlines():
        parts = line.split(' ')
        if len(parts) > 1:
            # Convert the `time` field
            utc_time_str = parts[1]
            utc_time = datetime.strptime(utc_time_str, '%Y-%m-%dT%H:%M:%S.%fZ')
            kst_time = utc_time + timedelta(hours=9)
            parts[1] = kst_time.strftime('%Y-%m-%dT%H:%M:%S.%fZ')
              
            # Convert the `request_creation_time` field
            request_creation_time_str = parts[-9]
            request_creation_time = datetime.strptime(request_creation_time_str, '%Y-%m-%dT%H:%M:%S.%fZ')
            kst_request_creation_time = request_creation_time + timedelta(hours=9)
            parts[-9] = kst_request_creation_time.strftime('%Y-%m-%dT%H:%M:%S.%fZ')
          
        modified_log_lines.append(' '.join(parts))
      
    # Join the modified lines and compress them
    modified_log_content = '\n'.join(modified_log_lines)
    out_buffer = io.BytesIO()
    with gzip.GzipFile(fileobj=out_buffer, mode='w') as f:
        f.write(modified_log_content.encode('utf-8'))
      
    # Save the modified log file back to S3
    dest_key = key.replace('alb-old-bucket-name', 'alb-new-bucket-name')
    s3.put_object(Bucket=bucket, Key=dest_key, Body=out_buffer.getvalue())
  
    return f'Successfully processed {key} and saved as {dest_key}'

Athena에서 S3를 연동

이제 특정 S3에 원하는 형태로 access log가 쌓이고 있게 되었습니다.

S3에 있는 데이터를 QuickSight에서 분석하려면 그전에 S3에 있는 Object 파일 형태의 데이터를 구조화 해 주어야 하는데요.

이 역할을 Athena가 수행합니다. AWS 서비스의 Glue와 유사한대요.

이 둘의 차이점은 우선 Athena는 S3에 업로드한 데이터를 가지고 직접 테이블을 생성하는 쿼리를 작성 수행할 수 있습니다.

Glue는 추가적으로 데이터 S3를 소스로 하여 Athena에서 질의 가능한 데이터 카탈로그를 자동 생성하거나, 또는 가공하여 새로운 데이터 파일을 생성할 수 있습니다.

Glue의 가장 일반적인 사용 예는 크롤러를 생성하여 S3에 업로드한 데이터 파일에 대한 메타 데이터를 자동 생성하는 경우입니다.

저희는 우선 Glue를 사용하기 보다는 직접 S3 데이터를 가지고 테이블을 생성해 보겠습니다.

직접 생성하는 방법은 Athena 콘솔에 접근하여 S3경로를 지정하고 해당 파일의 포멧을 인지할 수 있는 테이블 생성 쿼리를 수행합니다.

Athena > Query editor 에 들어가서 원하는 Data source/ Database에 table을 생성합니다. 쿼리 수행 문구는 다음과 같습니다.[4]

여기서 AWS 문서에 추가로 설정한 부분이 있는데요.

projection 설정 부분인데 이 부분은 해당 테이블 인덱스를 1일 단위로 갱신하겠다는 의미이고

아래 설정대로 하게 되면 1일 단위로 S3의 인덱싱(날짜 경로)을 업데이트하면서 Athena에서 S3의 인덱싱을 매일 갱신하게 됩니다.

곧, S3의 데이터를 누락없이 계속 읽어서 가져올 수 있게 됩니다. 아래 쿼리에서 버킷명, AWS 계정 번호 등은 개별 환경에 맞게 수정하여 수행해야 합니다.

CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs (
type string,
time string,
elb string,
client_ip string,
client_port int,
target_ip string,
target_port int,
request_processing_time double,
target_processing_time double,
response_processing_time double,
elb_status_code int,
target_status_code string,
received_bytes bigint,
sent_bytes bigint,
request_verb string,
request_url string,
request_proto string,
user_agent string,
ssl_cipher string,
ssl_protocol string,
target_group_arn string,
trace_id string,
domain_name string,
chosen_cert_arn string,
matched_rule_priority string,
request_creation_time string,
actions_executed string,
redirect_url string,
lambda_error_reason string,
target_port_list string,
target_status_code_list string,
classification string,
classification_reason string,
conn_trace_id string )
PARTITIONED BY
 ( day STRING )
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^ ]*)\" \"([^\\s]+?)\" \"([^\\s]+)\" \"([^ ]*)\" \"([^ ]*)\" ?([^ ]*)?' ) LOCATION 's3://s3-tgo-prd-log/alb-tgo-prd-pf-web/AWSLogs/계정번호/elasticloadbalancing/ap-northeast-2/'
TBLPROPERTIES
(
"projection.enabled" = "true",
"projection.day.type" = "date",
"projection.day.range" = "2024/08/01,NOW",
"projection.day.format" = "yyyy/MM/dd",
"projection.day.interval" = "1",
"projection.day.interval.unit" = "DAYS",
"storage.location.template" = "s3://s3-tgo-prd-log/alb-tgo-prd-pf-web/AWSLogs/계정번호/elasticloadbalancing/ap-northeast-2/${day}" )

위 쿼리가 Athena에서 정상 수행이 되면, 테이블이 만들어짐과 동시에 파일을 읽어 바로 데이터를 확인할 수 있습니다.

아래와 같이 Athena console에서 왼쪽에 테이블의 점점점 세개 > Preview Table > 오른쪽 하단에 S3에서 데이터를 읽어서 RDBMS 형태의 데이터 확인 가능합니다.

QuickSight에서 Athena를 Data source로 Dataset 생성

드디어 QuickSight 화면에서 작업을 수행하게 됩니다. Data 준비는 항상 오래걸리죠. ^^

QuickSight에서도 사전 작업이 하나 필요한데요. QuickSight에게 S3/Athena에 접근할 수 있는 적절한 권한을 주는 겁니다.

Managed 서비스라 간단히 권한을 줄 수 있습니다.

QuickSight Console에서 오른쪽 상단에 사람 모양 > Manage QuickSight > Security & Permission 선택 후

S3를 아래 Select S3 Buckets을 선택하여 저희가 저장한 버킷을 선택하여 권한을 부여해 줍니다.

Athena까지 데이터가 준비되어 있기 때문에 이제 QuickSight에서 Athena 를 Data source로 하여 Dataset을 생성하면 됩니다.

QuickSight Console 화면에서 Dataset > New Dataset > Athena를 순으로 선택하면 아래와 같이 나옵니다.

Data source의 이름을 적절이 지어주고, Athena에서 테이블 생성시 선택했던 Workgroup을 골라줍니다.

Data source를 만들 때, 그냥 만들어도 되지만, Custom Query를 주어서 앞서 봤던 Table에서 필요한 데이터만 가져오던지 데이터를 일부 가공하여서 가져올 수 있습니다.

여기서는 Custom Query로 가져올려고 하는 데이터의 일부를 편집해서 추가 필드를 생성하면서 가져와 보겠습니다.

각자 원하시는 형태로 데이터를 가져오면 됩니다.

데이터가 불러와진 Analysis 첫 화면은 아래와 같습니다.

이 Dataset을 그대로 활용할 수도 있지만, 저는 해당 Dataset에 하나의 추가 테이블을 등록하고 Left Join을 하여 Data를 좀 더 가독성을 높여보려고 합니다.

생성한 Dataset에서 add data > file upload > join 조건 입력 > left join 선택

이렇게 하면 왼쪽 데이터 기준으로 필요한 데이터가 새로운 column 으로 추가 생성됩니다.

Data 전처리(feat. calculated field, parameter, filter)

이 글을 쓰는 시점에 저는 이미 Visual을 다 만들면서 Data가 부족해서 다시 전처리를 하고 Visual을 그리다가 다시 Data가 부족해서 전처리를 하는 과정을 여러차례 반복했습니다.

사실, 데이터 분석에 있어서 이와 같은 흐름이 오히려 당연한 것 같습니다. 데이터 전처리를 전체 Flow상 어디서든 계속 발생하게 된다고 보시면 되겠습니다.

여기선 앞단계에서 미리 다 전처리가 되었고 마치 준비된 대쉬보드를 그냥 만들면 되네? 쉽네? 라고 느껴지겠지만,

Data 전처리와 이를 활용하는 과정은 사이클과정이라고 보면 되겠습니다.

QuickSight에서도 지금까지 가져온 Data를 추가로 전처리 수 있는 다양한 기능을 제공합니다.

그 중에서도 처음 활용하는 사람들에게 가장 강력한 기능인 Calculated Field를 활용해 보겠습니다.

Calculated Field는 지금까지 수집한 데이터를 가지고 QuickSight에서 제공하는 함수들을 활용하여 새로운 Field를 만들어 내는 기능입니다.

가장 먼저 수정하게 되는 field는 시간/날짜 데이터 입니다. athena로 수집하게 되면 data type은 숫자 혹은 문자열 입니다.

따라서 시간/날짜 데이터도 문자열 데이터로 수집되게 됩니다. 해당 데이터를 날짜/시간 형태로 변경해서 새로운 calculated filed 로 저장해줍니다.

왼쪽 field 중 가장 위에 있는 calculated field를 선택하면 field와 이를 구성하는 편집창이 나오게 됩니다. 2개의 날짜/시간 데이터를 생성합니다.

time_mod, day_mod 2개의 field를 추가 생성했고 각각의 계산식은 아래와 같습니다.

함수, 변수의 사용법은 아래 화면구성에서 쉽게 찾아볼 수 있습니다.

# day_mod : day 는 str로 date  type으로 변경
parseDate(day, 'yyyy/MM/dd')
# time_mod : time은 str로 date type으로 변경
parseDate(time)

calculated field는 화면 구성은 아래와 같습니다.

calculated field와 함께 자주 사용되는 기능은 filter 기능입니다.

Visual을 만들 때, 해당 Visual 혹은 화면 전체에 수집하는 데이터에 대한 조건을 걸 수 있습니다.

예를 들어 특정 field 의 값이 null인 경우는 제외, 오늘 데이터만 수집 등을 적용할 수 있습니다.

여기에 filter와 함께 parameter가 사용되는데, 이 둘을 묶어서 하나의 visual을 만들 때, 오늘 날짜 데이터만 가져오게 구성해 보겠습니다.

Parameter하나를 생성하고 이는 선택한 날짜를 갖는 변수로 만들겠습니다.

이름은 ChooseDay이고 Data/time type변수로 설정하고 어제를 default value로 설정하는 단계를 아래에서 수행하고 있습니다.

이어서 filter를 한번 적용해 보겠습니다.

visual로 웹페이지에 접속 메뉴별 접속 건수를 보여주는 걸 만들고 이 visual에 filter를 적용 후 위에서 선택한 parameter와 같은날의 데이터만 보여주게 하는 겁니다.

filter 아이콘 클릭 > 앞서 만든 day_mod 날짜 데이터 선택 > use parameter 선택 > day_mod = parameter(chooseDay) 조건 적용

이렇게 되면 해당 Visual은 선택한 날짜 데이터를 보여주게 됩니다.

위에서 보면 8/28일 날짜를 위에 parameter로 선택되었고 이 적용으로 해당 날짜만 보여짐을 확인할 수 있습니다.

Visual 생성

이제 의미있는 여러 Visual을 만들어 볼 차례입니다.

Access Log 기반으로 어떤 데이터들이 유용할까요? 일반적으로 access log기반으로 분석하는 유형은 다음과 같습니다.

• 접속 URL 정렬, 어떤 request가 많은지 분석

• 시간에 따른 request 추이, 하루 중 언제 사용자가 가장 많이 사용하는지 파악

• ALB, target status error code 발생 추이 및 발생 URL 분석

• 접속 ClientsTop 리스트, Geo 정보 누가 어디서 많이 접속하는지

이런 분석 화면들을 최종적으로 아래와 같이 구성해 보았습니다.

어디를 많이 접속하는지?

접속 메뉴별 상세 카운트 및 전일 등 기준 기반 비교

하루 시간대별 접속 건수

ALB(ELB), Target 별 상태 코드

Client IP 별 접속 건수

Insight 생성

아직은 못해봤지만, 이런 데이터를 가지고 요즘 시대의 AI 분석도 수행할 수 있습니다.

Insight를 만들고 여기에 필요한 데이터를 전달하면서 시계열 기반 예측, 이상징후 탐색 등도 적용할 수 있습니다.

이 부분을 일부 데이터를 가지고 테스트를 해 보았지만 아직까진 유의미한 데이터가 나오진 않았습니다.

실제로 이상징후를 탐지해서 알려주나, 이게 진짜 이상징후인 경우는 거의 없었던 것 같습니다.

패턴 상 기존 패턴을 벗어난다든지 등 아직 학습 기간이 짧아서 그렇다는 생각도 듭니다.

이 부분은 추후에 더 업데이트 해보겠습니다. 긴글 읽어주셔서 감사하고 여러분들도 데이터 분석에 QuickSight를 활용해 보세요!

참고 문서

[1] Application Load Balancer 액세스 로그 활성화, https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/enable-access-logging.html

[2] Forwards logs from AWS S3 to AWS CloudWatch real time, https://medium.com/@xinweiiiii/forwards-logs-from-aws-s3-to-aws-cloudwatch-real-time-5934287ca1f

[3] Access logs for your Application Load Balancer, https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

[4] Create the table for ALB access logs, https://docs.aws.amazon.com/athena/latest/ug/create-alb-access-logs-table.html