실시간 로그 시스템 구현
개요
이 글은 2023년 3월부터 5월까지 진행된 EDINT 로그시스템 구축기이며,
이후 AI 온라인 시험 부정행위 감독 서비스, 프록토매틱과 타사 연동형 서비스인 프록토링 X에 적용이 되었습니다.
2023년 3월 3주차 - 로그 형식 지정 및 로그 파일 저장
2023년 3월 4주차 - 요구 사항 파악 및 요구 사항 분석
2024년 4월 - 데이터베이스 및 자료구조 공부(선택) 및 문제 해결
2024년 5월 - 도입 및 회고
상황 소개
로그 시스템 구축 전에 아래 내용들을 확정하는 시간을 가지게 되었습니다.
이 섹션은 아래의 순서로 구성되어 있습니다.
서비스 소개
서버 구성 소개
로그 공부
로그 형태 정의
로그 시스템에 대한 기본적 이해
OLAP vs OLTP
정렬 및 파티셔닝 우위
서비스 소개
프록토매틱은 응시자들이 시험을 보고 N시간 이후에 AI 분석 레포트를 제공해드리는 서비스입니다.
→ 이런 과정에서 N시간 전부터 10분 내의 로그를 확인할 수 있어야 했습니다.
서버 구성 소개
기존의 개발계의 SLA는 99.5%에 해당했습니다.
낮은 가용성 만큼 여러 장애를 겪게 되었으며, 상용화계의 SLA는 99.99%로 구성하였습니다.
이 과정에서 1개의 EC2를 N개의 작은 EC2로 분리하면서 버그 추적이 어려워졌습니다.
[AWS EC2 SLA]
1. 단일 EC2의 SLA = 99.5%
2. 멀티 Region/AZ의 여러 EC2의 SLA = 99.99%
로그 형식 지정
로그 공부
로그 형태 정의
결론
로그 공부
버그 추적 및 수정을 위해서는 로그(Log)가 필요했으며, 아래와 같은 궁금증이 들었습니다.
로그가 무엇인지
어떤 로그들을 수집해야 하는지
로그들은 어떤 형태로 수집해야 하는지
참고자료가 필요했으며, 2023년 1월 경에 읽었던 클라우드 환경에서의 데브 옵스 보안에 해당 부분이 있었음이 생각났습니다. 이후 로그의 형태 정의에 이 부분을 참고했습니다.
로그 형태 정의
로그 시스템 구축 전, 로그 형태를 정하고 이에 따라 로그 파일을 남기기로 하였습니다.
이런 로그 파일들은 다양한 유형, 프레임워크에 호환되는 형태여야 했습니다.
적용 유형 : API 서버, 스케줄링 기반 서버
적용 프레임워크 : Express, Nest, Django, Flask
또한, 이런 로그의 여러 특징을 고려하여, OLAP, 열 기반 데이터(Parquet), 정렬 및 파티셔닝 우위 등을 고려하여 로그 시스템을 선택 및 구축해야 한다고 생각했습니다. 이 부분들은 [로그 형태 정의] 바로 다음 섹션에서 이어서 설명 드리겠습니다.
최종적으로 선택한 로그의 형태는 다음과 같습니다.
2024-04-02T09:56:01.037Z google.dev.ap-ne-2.api-server INFO 121.157.xxx.xxx 198.0.0.13 /api/v1/health {"isSuccess":True}대분류 | 세부 유형 | 설명 | 예제 |
|---|---|---|---|
Timetsmap | Timestamp | YYYY-MM-DDTHH:mm:ss.sssZ | 2024-04-02T09:56:01.037Z |
Host Group | |||
Service Name | 서비스명(약축어) | ||
Stage Name | 상용화계, 개발계 | dev | |
Region Name | 리전명(약축어) | ap-ne-2 | |
Server Name | 서버 유형 | api-server | |
Log Case | Log Case | 5가지 유형 | INFO |
IP Group | |||
Client IP | 요청자의 IP 주소 | 121.157.xxx.xxx | |
Request IP | 서버 Private IP 주소 | 198.0.0.13 | |
Log Target Name | Log Target Name | API 앤드포인트 | /api/v1/health |
Log Message | Log Message | 메세지 및 에러 | \{\"isSuccess\"\: True \} |
결론
위와 같은 로그를 남기는 공통 코드를 Python, TypeScript 버전으로 만들어서 팀에 공유하였습니다.
→ 이후, 실시간 로그 시스템 구축 이후 로그 시스템 재구축 하는 것으로 결정 되었습니다.
요구 사항 파악
구축된 로그 시스템은 다양한 동료(개발자, 디자이너, 마케터 등)가 쓰게 됩니다.
개발팀 기술 스텍 정리
개발팀 인원 구성
개발팀 리소스
회사의 리소스
정리
개발팀 기술 스텍 정리
AI 기반 서비스인 만큼 다양한 언어와 프레임워크를 쓰고 있었습니다.
따라서 새로 구축하는 로그 시스템은 아래 요구사항을 충족해야 했습니다.
JavaScript (필수) | 일부 Lambda
TypeScript (필수) | 대다수 Lambda, Express, Nest,
Python (필수) | Django, FastAPI
개발팀 인원 구성
스타트업이라서 인력이 부족한 상태로 작업을 했어야 했습니다.
개발팀 총원이 6명이었고 전체적으로 로그 시스템을 운영 및 관리할 인력은 1~2명 정도였습니다.
프론트 2
React, ReactNative
백앤드 4
Express, Nest, Django, FastAPI
개발팀 리소스
인원수가 6명이었으나, 프로덕션에 배포된 저장소는 7개가 넘게 있었습니다.
이에 고질적인 개발팀 리소스 부족이 있었고 로그 시스템의 도입이 추가적인 개발 및 운영 요구사항을 늘리지 않아야 했습니다. 설령 늘어나더라도 "최소한의 관리"로 코드 변경 및 인프라 유지가 가능해야 했습니다.
회사의 리소스
AWS 서비스에 대한 비용 부담을 느끼기 시작하는 단계였습니다.
추후 AI 분석 부분에서 대량의 로그가 찍을 예상 수요가 있었기 때문에, 비용적인 부담이 최소화 되어야 했습니다. 즉, 의사 결정 순위에서 회사의 리소스를 개발팀 리소스보다 조금 더 높은 순위로 잡았습니다.
정리
위의 모든 내용을 취합하고 회사, 팀, 개인 우선순위에 맞춰서 정리하였습니다.
문제를 해결하되 비용이 저렴하고 전체적으로 개발팀에 부하가 적게 걸리는 방향으로 진행하는 것으로 결정되었습니다.
2주 이내로 즉시 도입 가능할 것
로그를 한 곳에서 볼 수 있을 것
로그 시스템의 컴퓨팅 비용과 스토리지 비용이 저렴할 것 (여러 솔루션 별로 비교)
로그 시스템의 가용성(HA)은 높아야 할 것 (여러 솔루션 별로 비교)
로그 시스템의 확장성(HS)이 높아야 할 것 (여러 솔루션 별로 비교)
로그 조회 시, 별도의 문법을 사용하지 않고 SQL-Like Syntax가 지원이 될 것
여러 개의 서비스에서 범용적으로 사용이 가능할 것
시장 점유율이 어느 정도 존재하여, 커뮤니티 지원을 받을 수 있을 것
요구 사항 분석
대략적인 요구사항에 대한 세부 정의가 필요했습니다.
로그는 한 곳으로
2024년 3월에 로그 형식 지정 및 로그 파일 저장 이후, 로그는 X개 유형의 Y1, ..., Yn의 서버에 분산되어 저장되고 있었습니다. 즉, 프록토매틱의 장애 로그를 분석하기 위해서는 최대 ∑Yn 만큼의 로그를 봐야했습니다.
따라서 새로 구축되는 로그 시스템은 특정 서비스의 모든 로그를 한 곳에서 보기를 원했습니다.
비용은 저렴하게
예상 비용을 산정하기 위한 개략적인 규모 추정을 통해서 예상 로그 생성량을 추정하였습니다.
시험 및 응시자 숫자
서비스에 매달 100개의 시험이 개설된다.
시험 별로 100명의 응시자가 발생한다.
매달 10,000명의 응시자는 2시간 시험을 보게 된다.
AI 분석기, 동영상 분석기는 5초에 한 번 실행된다.
SQS 메세지가 존재하면 작업이 시작되고 이 경우 (2-c)와 같다.서버리스 스케줄러는 5분에 한 번 실행된다.
API 호출 횟수
1명의 응시자가 시험을 다 볼 때까지는 100번의 API 호출이 발생한다.
1명의 주최자가 모니터링 기능을 2시간 동안 사용하며, 이 기능은 5초당 1번 호출된다.
시험 시간 = 2시간 = 3600초 * 2 = 7200초
API 호출 수 = 7200초 ÷ 5회/초 = 1440회
AI 분석기/AI 변환기가 작업을 시작하면 각각 50줄의 로그가 생성된다.
단, 여기에는 API 재호출이 발생하지 않는다.서버리스 스케줄러는 실행되면 각각 30줄의 로그가 생성된다.
단, 여기에는 API 재호출, AI 재분석 요청 로스가 포함되지 않는다.계산의 편의성을 위해, 웹&앱 사용 간 API 재 호출은 10%이라고 가정한다.
계산의 편의성을 위해, AI 재분석 요청은 5%라고 가정한다.
로그의 크기
표준 로그의 크기는 128 ~ 256Byte에 해당한다.
위를 기반으로 하루에 생성되는 로그의 갯수는 1,792,040에 해당합니다.
응시자의 로그 = 100시험(1-a)*100응시자(1-b)*100번(2-a)*1.1(2-e)= 1,100,000줄
주최자의 로그 = 100시험(1-a)*1,440(2-b-ⅱ)*1.1(2-e)=158,400줄
AI 분석기의 로그 = 100시험(1-a)*100응시자(1-b)*50줄(2-c)*1.05(2-f)=525,000줄
서버리스 스케줄러 = 24시간*60분/시간(1-e) ÷ 5(2-d) * 30 = 8,640줄
로그 1개당 크기를 200Byte(평균값)으로 가정하고 계산하면 하루에 총 358,408,000Byte가 생성됩니다. 이는 하루에 358MiB의 로그가 생성됨을 의미합니다.
하루 : 358.40 MiB
한 달 : 10.74 GiB
일 년 : 130.816 GiB
이를 기준으로 문제 해결 단계에서 비용 추정액을 계산하였습니다.
고가용성, 고확장성
많은 로그 시스템이 "고가용성, 고확장성을 지원한다"고 하지만 정말로 그럴까요?
많이 사용하는 Sentry 혹은 ELK Stack을 이용한 로그 시스템은 SLA에 대한 명시적인 문서를 찾을 수 없었고 이런 경우, 가용성을 신뢰해도 되는지 확신할 수 없었습니다.
따라서 프록토매틱의 설계 상 가용성인 99.79~99.89% 범위 내에서 +-0.5% 오차 내의 실시간 로그 시스템을 구축하고자 했습니다.
추가적으로 자동 확장이 이루어지는 완전관리형(Full-managed) 계열의 서비스이길 원했습니다.
유사 SQL 문법(SQL-Like Syntax)
개발팀에서는 로우 쿼리(SQL)를 많이 쓰고 있었기 때문에, 로그 조회 시에도 유사 SQL을 사용하고 싶다는 의견이 있었습니다.
범용적인 솔루션
구축된 솔루션이 다양한 종류의 서비스에서 유연하게 적용이 가능하기를 원했습니다.
특히, 다양한 언어(Python, JavaScript, TypeScript)에서 적용이 되어야 했습니다.
시장 점유율과 커뮤니티
위의 요건들을 다 채우고 나서, 시장 점유율과 커뮤니티를 통해서 서포팅을 받으면 좋겠다는 요구 사항이 있었습니다.
로그 시스템에 대한 심층적인 이해(선택)
이 부분은 실시간 로그 시스템을 설계하면서 공부한 심층적인 이해와 관련된 부분입니다.
따라서 실제로 구현 단계에서는 필요하지 않은 부분들이기 때문에, 아래의 내용을 알고 있다면 빠르게 스킵(Skip) 해주시면 될 것 같습니다.
로그 시스템의 기본적 구조
OLTP(OnLine Transaction Processing) vs OLAP(OnLine Analytical Processing)
데이터 형식 : 다양한 포맷 비교
데이터 형식 : 행 기반과 열 기반 비교
파티셔닝 고려
로그 시스템의 기본적 구조
아래는 2023년 회사에서 발표한 로그 시스템 가이드 문서 중 일부입니다.
위 사진에 나와 있듯이, 로그 시스템은 크게 5가지로 구분되며, 2가지로 분류할 수 있습니다.
로그 저장 시스템 : 수집 → 스트리밍 → 분석 → 저장, 스토리지(S3)
로그 조회 시스템 : 접근 및 조회 → 조회, 스토리지(S3)
위 시스템은 AWS를 기준으로 설계되어 있지만, 비슷한 기능을 하는 타사 솔루션으로도 구현할 수 있습니다.
OLTP(OnLine Transaction Processing) vs OLAP(OnLine Analytical Processing)
로그가 저장되는 데이터베이스는 대부분 OLAP를 따르고 있는 경우가 많습니다.
제가 구축한 실시간 로그 시스템 또한 OLAP를 따르도록 설계 및 구축되었습니다.
이번 섹션에서는 아래 내용을 포함하였습니다.
OLTP와 OLAP의 차이
OLAP를 사용해야 하는 이유
많은 데이터베이스는 OLTP 혹은 OLAP에 맞춰서 개발되어 있으며, 데이터의 사용 목적에 따라서 OLTP 혹은 OLAP 중에 결정하게 됩니다. 대부분의 로그 시스템은 여러 특징들 때문에 OLAP로 구성되어 있습니다.
그 특징들에 대해서 알아보기 전에 OLTP와 OLAP의 차이에 대한 기본적인 설명이 필요합니다.
기준 | OLAP | OLTP |
|---|---|---|
목적 | 대량의 데이터에 대해 고속으로 다차원 분석을 수행 | 대량의 데이터베이스 트랜잭션을 실시간으로 실행 가능 |
목표 처리 시간 | 밀리초(ms)에서 수십분(m) | 밀리초(ms) |
데이터 크기 비교 | 상대적으로 큰 데이터 처리 | 상대적으로 작은 데이터 처리 |
정규화 방식 | 비정규화된 데이터 구조 | 정규화된 처리 구조 |
중복 데이터 저장 | 허용 | 완벽하게 같은 데이터 불허
|
데이터 저장 형식 | 다차원 큐브(OLAP Cube) | 표(Table) |
위 표를 보면 대부분의 비즈니스 로직은 "트렌젝션, 무결성, 목표 처리 시간"에 따라서 OLTP 시스템을 사용하는 것이 맞습니다.
하지만 N~NNN일 사이에 수집된 대량의 데이터의 처리는 "목표 처리시간"에 따라서 OLAP를 쓰는 것이 좋아보입니다. 대표적으로 수집된 로그가 이에 해당합니다. OLAP에 따라서 구성된 로그 시스템은 각 기준값을 차원(Dimention)으로 사용하여 다차원 분석을 진행할 수 있습니다.
설명의 간소화를 위해서 Timestamp, Host Group, Log Case으로 구성된 로그 파일이 OLAP 데이터베이스에 저장되어 있다고 생각해봅시다. 이 경우
특정 Timetsamp 구간, 특정 Host Group, 특정 Log Case를 조회한다고 하면 OLAP Cube는 데이터를 다음과 같이 다차원 탐색을 통해서 추출합니다.
즉, 로그는 OLAP 데이터베이스에 저장하는 것이 효율적일 것입니다.
조회 시점에 극도로 빠른 속도의 반응을 할 필요가 없음
기록 후에 수정, 삭제의 작업이 이뤄나지 않기에 트랜잭션이 필요 없음
대규모 조회에 대한 이점이 필요함
참고 영상 및 문헌
데이터 형식 : 다양한 포맷 비교
이 문서에서 언급하는 실시간 로그 시스템에서는 열 기반 자료형(Parquet)을 사용하였다고 말씀드렸습니다. 이 섹션에서는 다양한 자료형을 비교하고 왜 압축률이 존재하는 포맷을 사용하는 지에 대해서 고민해보았습니다.
로그는 다음과 같이 다양한 형태로 저장할 수 있습니다.
위에서 언급한 다양한 자료 구조들을 저장 공간, 접근 성능, 변환 비용 측면으로 분석한 결과가 있습니다.
저장 공간(Capacity Require)
저장 공간이 많이 필요한 Json과 ELK 스텍은 제거되었습니다.
접근 성능(Access Performance)
접근 성능이 High 이하인 4개의 대상이 제거되었습니다.
Raw logs, Raw logs w/ gzip, Json encoded, Json encoded w/ gzip은 모두 제거되었습니다.변환 비용(Transform Cost)
ELK 스텍은 변환 비용이 너무 높아서 제외되었습니다.
이를 기반으로 보면 일정한 압축률을 가지는 자료형 Parquet를 사용하는 것이 좋아보입니다.
하지만 압축률을 가지는 자료 구조로는 여러분도 많이 쓰시는 CSV 파일이 있습니다.
잠깐!
ELK 스텍은 분명히 많은 곳에서 쓰이고 있는 주류 스텍이라고 생각이 듭니다.
하지만 추가 스텍에 대한 학습, 비싼 이용료, 너무 큰 필요 저장 공간(Capacity Require), 너무 비싼 변환 비용(Tansform Cost) 그리고 단순 자료형이라고 보기 어려운 점 등으로 이 게시글 전체에서 제외하고 작성되었습니다.
ELK 스텍보다는 다른 솔루션을 쓰는 것이 소규모 스타트업에 적합하다고 생각하여, 제외된 점 양해 부탁드립니다.
참고 영상 및 문헌
데이터 형식 : 행 기반과 열 기반 비교
앞서 데이터는 압축률을 가지고 있는 자료구조를 쓰는 것이 효율적임을 알 수 있습니다.
가장 대표적인 오픈소스 자료구조는 Parquet과 CSV가 존재하는데 무엇이 다를까요?
로그 파일의 포맷과 무관하게 논리적으로 보면 테이블 형태를 연상하게 됩니다.
이러한 데이터를 디스크에 쓸 때는 한 줄(Row) 단위로 기록할 지, 한 칼럼(Col) 단위로 저장할 지를 정해야 합니다. 둘 모두를 사용하는 병행(Hybrid) 방식이 있지만, 설명의 편의를 위해 논의하지 않겠습니다.
요약하면 다음과 같습니다.
행 기반 디스크 저장 방식(Row-wise), CSV
열 기반 디스크 저장 방식(Columnar), Parquet
Parquet은 데이터 읽기에 최적화 되어 있습니다.
예를 들어, 특정한 범위의 시간(Timestamp)의 로그를 조회한다고 했을 때의 디스크 탐색을 보면 다음과 같습니다.
Row-wise CSV의 경우, 디스크의 A5 부분까지 모두 읽어야 합니다.
하지만 Colmnar Parquet의 경우 디스크의 A1~A5만 읽으면 완료됩니다.
이러한 특징이 Parqeut이 로그 시스템에서 훨씬 효율적인 읽기 작업을 진행할 수 있게 도와줍니다.
참고 영상
파티셔닝 고려
Parquet으로 저장된 파일의 경우, 디스크 저장 방식의 특성상 한 칼럼의 데이터의 양이 늘어날수록 효율이 떨어지는 경향이 있습니다. 예를 들어, 로그의 첫 칼럼인 Timestamp가 10만개, 100만개, 1,000만개로 늘어남에 따라서 디스크를 읽는 범위가 광범위하게 넓어질 것입니다.
따라서 주요 몇개의 키(Timestamp)에 따라서 파티셔닝을 하는 것이 효율적입니다.
문제 해결
주어진 문제 상황 및 요구사항을 해결하고 이를 분석하는 3가지 단계로 구분하였습니다.
솔루션 리스트업
솔루션 조사
Sentry
Betterstack
ELK/EFK Stack
AWS A Type
AWS B Type
솔루션 분석
솔루션 리스트업
국내, 외로 솔루션 탐색 시 노출도가 높은 유명한 솔루션들을 위주로 탐색하였습니다.
특히 실시간(Realtime, 5분 이내)에 가까운 로그 추적 기술이 필수로 포함하였습니다.
Sentry
Loggly
BetterStack
ELK/EFK Stack
AWS A Type | Fluentd, Kinesis Firehose, Lambda, S3(Parquet), Spark, Zeppelin
AWS B Type | Kinesis Firehose, Glue Data Catalog, S3(Parquet), Athena Query Runner
참고 영상 및 문헌
솔루션 조사 : Sentry
Sentry
비용 : $29/$89
SLA :
공개 상태(status) 페이지 : https://status.sentry.io/
압축 알고리즘
자동 백업 지원
구조 : SAAS 이므로 별도의 구조 및 구성을 신경쓰지 않아도 됨
솔루션 조사 : BetterStack
비용 : $100
SLA : 99.9%
추가 크레딧 없음
공개 상태(status) 페이지 : https://status.betterstack.com/
압축 알고리즘 : zstd
자동 백업 지원
매 시간 마다, AWS S3 등에 백업 지원
#{데이터베이스}/#{테이블}/#{from.%Y-%m}/#{to.iso8601}/#{파일확장자}
구조 : SAAS 이므로 별도의 구조 및 구성을 신경쓰지 않아도 됨
솔루션 조사 : ELK
ELK(Elasticsearch, Logstash, Kibana)
비용 : 137.544 USD
Data 통합용 Fluentd : t3.medium 2개
2대 × 0.0416USD/시간(t3.medium) × 24시간 × 30일 = 59.904 USDAWS Opensearch(Elasticsearch)
0.112USD/시간(t3.medium.search 1개) × 24시간 × 30일 = 80.64 USD
SLA : 99.98%
구조
Beats → Logstash → Elasticsearch ← Kibana
주요 특징
오픈 소스
여러 서버에서 발생하는 로그 파일을 수집, 저장하기에 용이
로그 파일이 존재한다면 모두 수집 가능(syslog, nginx, rabbit-mq)
강력한 검색 기능
수집한 로그에 대해 편리한 시각화 기능 제공
솔루션 조사 : EFK
EFK(Elasticsearch, Fluentd, Kibana)
비용 : 137.544 USD
Data 통합용 Fluentd : t3.medium 2개
2대 × 0.0416USD/시간(t3.medium) × 24시간 × 30일 = 59.904 USDAWS Opensearch(Elasticsearch)
0.112USD/시간(t3.medium.search 1개) × 24시간 × 30일 = 80.64 USD
SLA : 99.98%
구조
Fluentd → Elasticsearch ← Kibana
주요 특징
전체적으로 ELK 스텍과 유사하지만 아래 차이점이 있습니다.
잠깐! 차이점 궁금하지 않나요?
Logstash랑 Fluentd 중에 뭐가 다를까?
전체적으로 보면, Logstash보다는 Fluentd가 적은 메모리 공간을 사용하고 실시간 환경에서 로그 수집 및 분석에서 널리 쓰입니다.
하지만 Logstash는 로그 및 분석을 위해 더 넓은 범위의 로그 처리 기능과 나머지 ElasticStack과의 최고 수준의 통합이 지원됩니다.
전체적으로 보면 성능과 기능 사이의 트레이드 오프가 될 것 입니다.
솔루션 조사 : AWS A Type
Fluentd, Kinesis Firehose, Lambda, S3(Parquet), Spark, Zeppelin
비용 : 1.5USD 미만 (월별, 0.358 GiB 기준)
Kinesis Datastream 수집 데이터 (24시간 보존) : 0.3584 GiB × 0.099 USD/GiB = 0.0354816 USD
Kinesis Datastream 저장 데이터 : 0.3584 GiB × 0.049 USD/GiB = 0.0175616 USD
Lambda
20USD/50TiB × 50TiB/51,200GiB × 51,200GiB/52,428,800MiB = 20USD/52,428,800MiB (1MiB 당 Lambda 호출 비용, 추정액-사례기준)
20USD/52,428,800MiB × 358.40MiB = (358.40 MiB당 Lambda 호출 비용, 추정액) = 0.00013671875 USD
→ Lambda 추정액의 연산은 실제로 파이프라인 구축해야 알 수 있을 것 같다.
→ 하지만 사례로 보면 5TiB(500MiB의 10,000배) 기준 20USD가 나왔으므로, 1USD 미만의 요금이 청구될 것으로 추정할 수 있습니다. 보수적으로 생각하여 1USD로 추정
SLA : 99.74%
Fluentd (Single/Multi-AZ, Region EC2) : 99.5%/99.9%
→ 로그 시스템 설계 요구사항에 따라서 Multi-AZ로 배포하여 99.9% 확보
S3 설계 99.5%~99.99% / 보장 99%~99.9% + 내구성은 99.999999999%
→ 로그 저장 부분은 S3 Standard 클래스를 주로 사용하며, 이는 99.99%의 SLA 보유
구조
주요 특징
Fluentd를 이용해서 로그를 축적 후 export하는 형태
Kinesis Datastream과 2개의 Lambda를 통합
2개의 Lambda는 각각 S3와 ES에 데이터를 저장
S3에 저장된 로그 데이터는 AWS EMR(Elastic MapReduce)에 있는 Spark, Zeppelin을 사용해서 조회
솔루션 조사 : AWS B Type
Kinesis Firehose, Glue Data Catalog, S3(Parquet), Athena
비용
Kinesis Firehose Collect = 0.3584 GiB × 0.036 USD/GiB
Kinesis Firehose Transform = 0.3584 GiB × 0.022 USD/GiB
(Optional) Kinesis Firehose Partitioning = 0.3584GiB × 0.027USD/GiB
Glue Data Catalog = 사실상 0 USD
→ CreateTable, CreatePartition, GetTable, GetPartitions 등의 API 호출 1,000,000건 당 6866엔이 지불되지만, 해당 아키텍처에서는 이 API가 호출이 많이 되지 않습니다.
SLA : 99.79%
S3 설계 99.5%~99.99% / 보장 99%~99.9% + 내구성은 99.999999999%
→ 로그 저장 부분은 S3 Standard 클래스를 주로 사용하며, 이는 99.99%의 SLA 보유
구조
솔루션 비교
Sentry | BetterStack | ELK/EFK | AWS A Type | AWS B Type | |
|---|---|---|---|---|---|
SLA | ? | 99.9% | 99.98% | 99.74% | 99.79% |
Contract Fee | $29.00 | $100.00 | - | - | - |
Ondemand | - | - | $137.544 | $1.5 |
선택
Sentry를 제외하고 4개의 선택지가 모두 목표 가용성 범위(99.7~99.99)를 충족하였습니다. 따라서 추가 학습이 거의 필요 없고 비용적으로 저렴한 AWS A Type을 선택하였습니다.
도입 및 회고
로그 시스템 도입 이후 12개월의 사용 경험의 후기입니다.
로그 시스템 도입 이후 12개월 간 848만개의 로그 파일을 수집하였습니다. 최초 개발팀에서 고려하였던 Sentry Teams 요금제 대비 99.78% 비용 저
좋은 부분
로그 시스템 도입 이후 12개월 간 848만개의 로그 파일을 성공적으로 수집할 수 있었습니다.
초기 개발팀 고려 대상인 Sentry Teams 요금제 대비 99.78% 비용 절감을 할 수 있었습니다.
($312 → $0.67, 비용 대쉬보드 기준)Direct PUT 방식으로 탬플릿 클래스(Python, TypeScript)를 만들어서 공유하는 방식은 효율적이었습니다.
로그 형태가 통일되어 디버깅에 유용했습니다.
안 좋은 부분
Athena의 쿼리 조회 속도가 낮았습니다. (수 초)
Athena의 쿼리 구문이 특정 자료형(timestamp)에서 MariaDB와 달라서 어려웠습니다.
하지못한 부분
Glue Data Catalog에서 timestamp 기준으로 파티셔닝 하는 것을 하지 못했습니다. 이에 따라서 안 좋은 부분 - 1이 발생했습니다.
OLAP Cube 방식의 조회 시스템이나 대쉬보드를 구성하지 못했습니다. 대쉬보드가 있었으면 수집한 데이터를 비개발자도 편하게 조회할 수 있었을 것 같습니다.
결론
비용 측면에서는 효율적인 결정이었다고 생각합니다.
하지만 규모가 작은 스타트업이라면 Sentry Teams를 쓰다가 마이그레이션을 해도 될 것 같습니다.
단 Sentry Teams를 쓰더라도 60일이 넘은 Cold Log의 경우, 백업 전략을 별도로 구성해야 합니다. 주로 S3를 사용합니다.
