로그 시스템

로그는 어떤 일이 일어났음을 파악하기 위한 용도로 시스템 로그와 사용자 로그로 나뉠 수 있다. 이를 어떻게 설계하고, 어떤 로그를 활용해서 추후에 사용할지를 결정하는 것은 매우 중요하지만 대부분 관과하기 쉬운 부분이기도 하다.

시스템 로그

• 많은 수의 서버로부터 시스템 로그를 모두 수집, 이를 활용하여 어떤 서버에서 어떤 에러가 발생했는지 파악
• 코드가 어떤 경로로 호출되었는지 Traceback을 남김
• 오류 코드는 해당 시점의 서버 로그를 찾기 위한 단서

로그 시스템 설계 목표

• 높은 가용성 : 시스템이 죽으면 로그를 유실되기 때문
• 실시간 조회 : 빠른 조회는 곧 생산성 향상과 직결된다. 빠르고 쉽게 조회 가능해야함 (ex. 로그 발생에서 조회까지 5초 이내 )
• 분석 및 시각화 : 대규모 로그도 빠르게 분석 가능하게, SQL 사용 가능한지, 그래프도 그려줄 수 있는지 등
• 관리부담 최소화 : 쉬운 확장과 축소

로그 시스템 아키텍쳐

로그는 수집 -> 조회 -> 분석 의 과정으로 나눠볼 수 있다

로그 수집

Fluentd

• 오픈소스 데이터 수집기
• C + Ruby => 빠르고 가벼움
• 다양한 플러그인 => Kinesis 플러그인 지원
• 간편한 설정

Fluentd는 하나의 머신에 있는 여러개의 프로세스(노드)로부터 로그를 수집한다. 즉 로그 수집의 에이전트 역할을 한다고 할 수 있다.

Kinesis Data Stream

• AWS의 관리형 서비스 => 높은 가용성
• 스트리밍 데이터를 저장하는 큐 역할
• 최대 365일까지 데이터 보존 (기본적으로 24시간) => 언제든 복구 가능
• 데이터 유입량에 따라 무중단 확장 및 축소 가능
• 샤드 개수 (샤드의 처리량 제한과 Lambda의 처리 속도에 맞춰서 결정)

로그 조회

Elasticsearch

• Lucene 기반의 분산 검색엔진
• 역인덱스를 이용한 빠른 검색 가능
• Kibana 시각화 도구 제공
• AWS Elasticsearch Service로 관리형으로 사용 가능

=> 로그가 늘어날수록 유지비용이 증가되므로 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용)

로그 분석

Apache Spark

• 클러스터 컴퓨팅 엔진
• 인 메모리 데이터 처리
• Python, Scala, R, Java 언어 지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)

Apache Zeppelin

• 대화식 분석이 가능한 웹 기반 노트북
• 다양한 인터프리터 사용 가능
• 쉬운 시각화

=> Ad-hoc 분석용으로만 사용

AWS EMR

• Spark 클러스터를 손쉽게 구성
• 스팟 인스턴스 사용 가능
• 쉬운 확장 및 축소

로그 파일은 보통 JSON으로 저장하는데 Lambda는 최대 1000개의 로그를 하나의 파일로 저장한다. 그러나 엄청나게 많은 파일 개수는 네트워크 오버헤드를 발생시킨다.

그래서 JSON을 Parquet으로 변환하는게 좋다.

Parquet

• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown