AWS를 이용한 대용량 Log 데이터 처리하기 시행착오 정리

1. 개요

- 상황

    1) 사용자가 Web에서 클릭한 모든 기능에 대해 데이터베이스에 저장

    2) 하루 평균 40만 ~ 50만 건의 데이터가 저장

    3) 현재까지 약 4억 건의 데이터가 저장 되어 있음

    4) DBMS에서 쿼리 실행 시 Web 사용자가 많을 경우 DB lock 현상이 발생

    5) 운영 DB와 Data log 데이블이 한 서버에 있어서 log 데이터 조회 시 DB 커넥션 증가

 

: 위 상황으로 인해 log data를 효율적으로 활용할 수 있게 새로운 시스템으로 이관이 필요해 진행 하였고 히스토리를 정리하려고 합니다.

---

2. 환경

    - 데이터베이스 : MS-SQL

    - 개발언어 : JAVA

    - 도입 시스템 : AWS S3, AWS Athena, AWS Lambda, AWS SQS, AWS Glue, Java Batch

---

3. 시행착오

    3-1. 첫번째 (Redis 사용)

프로세스

        - S3에 바로 json 형태로 저장하려고 하였으나 S3의 putObject는 파일 append를 지원하지 않아서 Redis에 저장 후 

          배치 프로그램을 하루에 한번씩 실행 시켜 S3에 저장을 하려고 하였습니다.

        - Redis에 저장된 자료가 유실될 경우를 대비해서 기존 DB는 백업용으로 사용합니다.

        - AWS Athena에 자료 저장 시에는 대소문자를 구분하는데 조회할 때는 대소문자를 구분하지 않아서 동일 컬럼 중복             오류가 발생합니다.

        - 문제 발생

         1) 하루에 40만 ~ 50만 건이 처리 되어야 하는데 실시간으로 Redis에 저장하면서 서버 CPU가 100% 사용되어 사이                 트가 마비되는 현상이 발생되어 적용 취소하고 설계를 변경하였습니다.

        - 환경 구성 참고

AWS Athena, Glue, S3 활용으로 로그 데이터 처리하기 with REDIS

 

    3-2. 두번째(AWS SQS, AWS Lambda 사용)

프로세스

        - Redis 서버 사용 시 WAS 서버 CPU 사용률이 너무 높아서 AWS에서 제공하는 Simple Queue Service(SQS)를 사용  하기로 하였습니다.

        - Queue 이기 때문에 Data를 전달만 하면 AWS 내부에서 알아서 동작하기 때문에 WAS에 영향이 없을 것으로 판단하였습니다.

        - 문제 발생

         1) 기능 1건 당 S3 File 1개로 저장 되었기 때문에 하루에 30만 ~ 80만 건까지 File이 저장되는 상황이

             발생 되어 AWS S3 트래픽 증가로 많은 비용이 청구 되었습니다.

         2) S3 버킷 하나에 많은 File이 저장되어 콘솔에서 컨트롤할 수 없을 정도로 속도가 느렸습니다.

         3) 또한 AWS Glue에서 S3파일을 Athena로 저장 시에도 10시간씩 걸리는 상황이 발생 되었습니다.

         4) AWS Athena 에서 쿼리 실행시에 사용할 수 없을 정도로 속도가 느려서 또 한번 설계를 변경하게 되었습니다.

        - 환경 구성 참고

AWS Athena, Glue, S3 활용으로 로그 데이터 처리하기 with AWS Lambda, AWS SQS

 

    3-3. 세번째(AWS SQS, AWS Lambda, Java Batch 사용)

프로세스

        - S3 비용 절감을 위해 하루에 한번 배치로 전일의 데이터를 조회 후 SQS에 전달하려고 하였습니다.

        - Amazon Athena – 10가지 성능 향상 팁 문서에 보면 파일 크기가 128MB 보다 작을 경우 S3 파일 처리시 시간을 더 많이 사용한다는 내용이 있었고, S3 트래픽을 줄이면 비용 절감을 할 수 있을 것 같아서 하루에 한번, 그리고 최소한의 파일 분할로 S3에 저장하는 방법으로 처리하려고 하였습니다.

        - 문제 발생

         1) 하루에 한번 전일 데이터를 JSON 형태로 변경해서 SQS에 전달 했는데 지원하는 파일 용량을 초과했다는 메시지와 함께 동작이 멈추는 현상이 발생 하였습니다. ( 262,144 bytes )

         2) 한 줄씩 SQS에 전송할 경우 속도가 처리시간이 너무 오래 걸리는 현상이 발생하여 또 다시 설계를 변경하였습니다.

        - 환경 구성 참고

AWS Athena, Glue, S3 활용으로 로그 데이터 처리하기 with Batch, AWS Lambda, AWS SQS

 

    3-4. 네번째(Java Batch 사용, AWS SQS, AWS Lambda 제거)

프로세스

        - 평균 80만 건의 데이터를 한번에 JSON 으로 변환할 경우 속도가 너무 오래 걸리고 변환이 완료 되어도 java heap memory가 오버되는 경우가 발생하여 전체 사이즈가 30만건 이상일 경우 프로세스 개수 만큼 나눠서 처리 하였습니다. ( 추후 Thread 처리를 고려 )

        - Glue 크롤러를 매일 0시 3ㅂ분으로 설정 시 배치에서 저장한 AWS S3 경로에 파일을 AWS Athena로 넘기지 못하는  현상이 발생되어 매시 정각에 AWS Glue 크롤러 실행으로 설정을 변경하여 처리 하였습니다.

(위의 3가지 시행착오에서는 5시간 ~ 10시간 걸리던 것이 3~5분만에 처리됨)

---

4. 정리

- 4번의 시행착오 끝에 유저가 사용한 기능에 대한 log 는 DB에 먼저 저장하고 다음날 새벽에 배치 프로그램으로 전일 데이터를 취합해서 리스트 개수에 따라 30만건 이상일 경우 분할해서 JSON 파일로 변환해서 AWS S3에 저장하고, AWS Glue 크롤러가 매 시 추가된 항목을 체크 해서 AWS Athena로 취합하는 형태로 구현되었습니다. 

- 그 결과 Athena에서 조회 시 3번의 시행착오 상황에서는 1일 데이터 조회 시에도 5분 이상 걸리던 것이 10초 밑으로 내려 온 것을 확인 하였고, 너무 오래 걸려 Web으로 기능 구현을 해도 사용할 수 없었던 것이 일반 DB를 사용하는 것 처럼 사용할 수 있어서 만족스러운 결과가 나온 것 같습니다.